Re: Evaluation in groups:

[Chip Seraphine]

On Wednesday 21 July 2004 02:48, Armin Wolfermann wrote:
> * Chip Seraphine <chip@trdlnk.com> [20.07.2004 22:23]:
> > groups:
> >     sunos_5_9::
> >             sun_class= ( ReturnsZero(/bin/echo testing sun class) )
> >     linux::
> >             linux_class= ( ReturnsZero(/bin/echo testing linux class) )
> 
> You could rewrite it in pseudo-syntax like:
> 
>       sunos_5_9.ReturnsZero(/bin/echo testing sun class)::
>               sun_class = true
> 
>       linux.ReturnsZero(/bin/echo testing linux class)::
>               linux_class = true

That throws a 'Stray character (.)' syntax error on my 2.1.6 installation :-(.  
  
As far as I can recollect, evaluated classes in the evaluation:: clauses 
always do that.  (let me know if this is new behavior in 2.1.7).

BTW, if any of you CVS-commit types are reading this, it looks like that error 
message needs a newline on the end of it.  "cflex.l.in"  line 495.
 
> This is described in the documentation (although only with classes).
> 
> > Is this behavior correctable?  (Or is it desireable behavior that I am not 
> > understanding correctly?)
> 
> It is desireable (and useful) for classes. Functions with side effects
> are problematic, but different evaluation rules for classes and functions
> seem much more problematic.

I am assuming that the pseudocode you wrote above would refrain from executing 
the dynamic class on the right hand side of the AND operator if the LHS is 
not true.  What I don't understand is why that (very reasonable) behavior is 
desireable and yet executing class evaluations in code that shouldn't be hit 
at all is not?

I understand if it is just a limitation of the parsing code (after all, using 
classes:: in classes: is a new feature), but I don't understand why we would 
want  to evaluate 'unreachable' code under any circumstance (other than, 
perhaps, to detect syntax errors).

If I say:

        any::
                foo= ( bar )
        NEVER::
                qux= ( quux )

than I'd expect the qux line to never be evaluated at all, regardless of 
wether I have classes or functions in there (even if for no other reason than 
simple efficiency-- no need to evaluate what is destined to be ignored).

Could you give me an example of where evaluationg 'unreachable' code such as 
the qux line above is 'desireable and useful'?  I'm just not seeing it.  :-(


-- 

Chip Seraphine
Unix Administrator
TradeLink, LLC
312-264-2048
chip@trdlnk.com