Re: Euphoria bug (Robert)
--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--
|
Not Categorized, Please Help
|
|
