Re: writing a compiler...

"Conor O'Neill" <Conor.ONeill.NoSpamPlease@logicacmg.com> writes:


> m.a.ellis@ucsnew1.ncl.ac.uk writes
>>Mmph. In a round about, fudge it a bit here, kind of way....
>>
>>IIRC it's Pascal that allows something like:
>>if f(a) and g(b) then ...
>>to evaluate f() and g() in either order.
>>
>>But if f() and g() have side-effects such that the behaviour of the
>>program is determined by which executes first, then the program is
>>wrong. I don't think that's something that can be checked by a
>>compiler on an arbitrary program?
>
> This is entirely checkable, if the language distinguishes between
> 'functions', which have no side-effects, and 'procedures', which may
> have. Occam 2 has this property.




You can't check in general whether a "procedure" will truly cause a
side effect. You also can't check whether two procedures will cause
side effects where the order matters. Like most static analysis
problems, this one is at least as hard as the halting problem. (Take
any program and change all the exit()'s to printf's, remove all other
side effects, and then try to see if the program has a side effect.
If it does, then the original program halted.)


Thus any programming language specification that says such a construct
is illegal, as opposed to undefined, is a specification that can't be
implemented. It still may be an interesting language to talk about
and/or to use in an introductory classroom.


Anyway, having a predictable evaluation order can really make things
easier on the programmer. Further, it doesn't necessarily hurt the
compiler very much even when the optimal evaluation order for the
platform is different from the one specified in the language. This is
because the compiler can take advantage of the effects information you
talk about.




Lex

Return to the comp.compilers page.
Search the comp.compilers archives again.