Re: Euphoria bug (Robert)
- Posted by Al Getz <Xaxo at aol.com> Sep 20, 2005
- 521 views
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"