Re: Euphoria bug (Robert)

new topic     » topic index » view thread      » older message » newer message

Michael Nelson wrote:
> 
> --0-1871626537-1127247426=:23661
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
> 
> This general issue has far reaching effects and is by no means unique to
> Euphoria.
> The case at hand is a pathological example of function side effects. 
>  
> The solution is simple: functions should not have any side effects. The theory
> behind
> this is called "Command Query Separation" which was stated by Betrand Meyer,
> the creator
> of Eiffel.
>  
> According to the theory, every routine should be either a command or a query.
> A command
> can change the program state (assign to a non-local variable, open a file,
> create a
> window, etc.) but cannot return a value. A query cannot change program state
> but can
> obtain and return information about program state. As a consequence of this, a
> query
> may be freely caqlled from within a command, but not the other way round.
>  
> No language I know of, not even Eiffel itself, enforces CQS. Sometimes a
> routine that
> both changes state and returns a value is just too convienent and too unlikely
> to be
> abused--for example open(). 
>  
> If Euphoria were to enforce CQS, functions could not have side effects, and
> many optimizations
> of function calls would be possible. Certain routines would have to be
> rewritten. For
> example, Eu could preding a global object result which a procedure (command)
> could
> set. So for example
>  
> fn=open("xxx.txt","a")
> if fn=-1 then --error handling
>  
> would become
>  
> open("xxx.txt","a")
> fn=result
> if fn=-1 then -- error handling
>  
> This added complexity is an agrument against CQS--and the reason I would not
> advocated
> it being enforced by the Eu interpreter.
>  
> However, using CQS as a design method with the freedom to disregard it in
> simple safe
> cases like open() can be quite beneficial. In the case at hand, a programmer
> using
> CQS methodology simply won't write code like this and needn't worry whether or
> how
> it works.
>  
> 
> --0-1871626537-1127247426=:23661
> Content-Type: text/html; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
> 
> <DIV>This general issue has far reaching effects and is by no means unique to
> Euphoria. The
> case at hand is a pathological example of function side effects. </DIV>
> <DIV> </DIV>
> <DIV>The solution is simple: functions should not have any side effects. The
> theory behind
> this is called "Command Query Separation" which was stated by Betrand Meyer,
> the creator of Eiffel.</DIV>
> <DIV> </DIV>
> <DIV>According to the theory, every routine should be either a command or a
> query. A command
> can change the program state (assign to a non-local variable, open a file,
> create a window, etc.)
> but cannot return a value. A query cannot change program state but can obtain
> and return information
> about program state. As a consequence of this, a query may be freely caqlled
> from within a command,
> but not the other way round.</DIV>
> <DIV> </DIV>
> <DIV>No language I know of, not even Eiffel itself, enforces CQS. Sometimes a
> routine that
> both changes state and returns a value is just too convienent and too unlikely
> to be abused--for
> example open(). </DIV>
> <DIV> </DIV>
> <DIV>If Euphoria were to enforce CQS, functions could not have side effects,
> and many optimizations
> of function calls would be possible. Certain routines would have to be
> rewritten. For example,
> Eu could preding a global object result which a procedure (command) could set.
> So for example</DIV>
> <DIV> </DIV>
> <DIV>fn=open("xxx.txt","a")</DIV>
> <DIV>if fn=-1 then --error handling</DIV>
> <DIV> </DIV>
> <DIV>would become</DIV>
> <DIV> </DIV>
> <DIV>open("xxx.txt","a")</DIV>
> <DIV>fn=result</DIV>
> <DIV>if fn=-1 then -- error handling</DIV>
> <DIV> </DIV>
> <DIV>This added complexity is an agrument against CQS--and the reason I would
> not advocated
> it being enforced by the Eu interpreter.</DIV>
> <DIV> </DIV>
> <DIV>However, using CQS as a design method with the freedom to disregard it
> in simple
> safe cases like open() can be quite beneficial. In the case at hand, a
> programmer using CQS methodology
> simply won't write code like this and needn't worry whether or how it
> works.</DIV>
> <DIV> </DIV>
> --0-1871626537-1127247426=:23661--
> 
> 

Hello Michael,


That's very interesting.  I tend to think there is a way around
everything though.  As Pete was saying, if you interpret the
initial function call line left hand side as constant, it all
falls into place.  Actually i think C is like this too; somewhere
in the docs i think it mentions LHS array subscripts.


Take care,
Al

And, good luck with your Euphoria programming!

My bumper sticker: "I brake for LED's"

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu