RE: Eu's poor design
Derek Parnell wrote:
>
>
> On Sun, 17 Aug 2003 22:32:45 +0000 (08/18/03 08:32:45)
> , Andreas Rumpf <pfropfen at gmx.net> wrote:
> [snip]
>
> >> I don't think you know the best way to do it Euphoria, because you are
> >> forcing un-Euphorian concepts onto it.
> > Using loops is an un-Euphorian concept? Using pbr is an un-Euphorian
> > concept? I don't think so.
>
> PBR is not a Euphoria concept because Euphoria tries to minimise side-
> effects.
Yes, but this design is not practical. It forces the programmer to use
global variables all over the place which have their own problems (think
of gargabe collection...)
So it seems to me, Eu is a language that wants to be functional but
isn't.
I don't see why using global variables is a better solution.
> In Euphoria, a routine is a code construct that is used to do a
> unit of work, possibly utilizing the data passed to it. If the routine
> returns any data, that returned data is independant of the data passed
> to
> it.
>
> By having this restriction, the interpreter can make some optimisations
> (assumptions) about the variables in scope. If PBR were allowed, then
> the
> interpreter must not assume that the routine has left its variables
> untouched. Which means that subsequent references to the variables must
> be
> re-read by the interpreter IN CASE they have been modified.
Hm. The compiler knows when a parameter is passed in by reference. So we
can optimize all variables which aren't passed by reference (at least).
>
> integer a,b
> a = 1
> b = someFunc(a)
> someProc(&a, &b) -- I'm using the '&' to indicate PBR
> -- At this point, 'a', or 'b' or both may or may not have been changed.
> -- The interpreter cannot cache the value of 'a' or 'b' but is forced
> -- to fetch them again.
> if b = a then
> ...
> end if
>
> PBR always increases the probability of side-effects. To counteract
> those,
> extra code is required, adding to the maintenance effort and further
> increasing the probability of bugs.
I've never had a bug because of pbr. (I've had lots of bugs via pointers
& lack of garbage collection!)
>
> So, why does PBR exist as a concept and why do we need it?
>
> PBR came about as a practical solution to a physical problem. Before we
> had
> compilers, parameters were passed to routines by placing their values
> into
> a CPU register. The routine would also pass back values in CPU
> registers.
> This gave rise to 'calling conventions' - a protocol about which
> registers
> to use for what. It soon transpired that some data was too big to place
> into registers. Sometimes multiple registers were used, and other times
> the
> data was placed into RAM and a register was loaded with the RAM address
> of
> the data value. In other words, a reference to the parameter was passed
> instead of the parameter itself.
>
> Later, when compilers were devised and espectially the concept of a
> stack
> frame reference, passing large data values by value was made easier. But
>
> all that copying to RAM and back could slow things down. So, in general,
>
> when it came to passing a large dataitem, coders would tend to pass its
> RAM
> address (because that was small). This was also helpful for dataitems of
>
> arbitary sizes, as the address length is always the same size,
> regardless
> of the actual dataitem's size.
>
> So, in general, PBR is used to avoid copying large dataitems, and/or to
> make using arbitary sized dataitems easier. Another use is when the
> decision to update a dataitem is not known by the routine until runtime.
> A
> fourth reason is because its easier to code it that way.
>
> In Euphoria, large dataitems are repesented by sequences. When Euphoria
> passes a sequence to a routine, it actually does pass a reference to the
>
> sequence - there is no big copying going on. The first time that the
> sequence is updated by the routine, a copy is made of the sequence. This
>
> means that routines that do not update sequences are not penalized by
> receiving sequences.
>
> Now comes the Euphoria philosophy - who owns the data; the caller or the
>
> callee? Euphoria believes that the caller owns the data. That it is the
> caller who is responsible for a dataitem being consistent and correct.
> As
> such, it assumes that the callee knows nothing about the dataitem other
> than its current contents. Thus if the callee needs to change the data,
> it
> must tell the caller what the new values should be. It is then the
> caller
> that decides how to apply these changes.
>
> PBR would break this philosophy.
>
> However, what we find over and over again in Euphoria programs is a
> coding
> idiom along the lines of ...
>
> x = func(x, ...)
>
> There maybe a case for adding some syntactic sugar to Euphoria that
> makes
> coding this commonly used idiom easier.
>
> func( &x, ... )
>
> for example. This idiom is particularly irksome when 'x' is really a
> rather
> long name reference. If this syntax were allowed in Euphoria, then
>
> append( &stack_space[lThisStack], pData )
>
> would be interpreted as if I had actually written ...
>
> stack_space[lThisStack] = append( stack_space[lThisStack], pData )
>
>
> Back to the PBR usages...
>
> Again, sequences nicely implement arbitary-length dataitems. Passing
> these
> to 'read-only' routines incurs no penalty in terms of copying data. And
> again, the data ownership philosophy would apply to changing the
> dataitems.
>
> When it comes to the run-time decisions about whether or not elements
> need
> updating, Euphoria's data ownership philosophy means that the caller may
>
> know that a dataitem might need updating but not what nor how the new
> values are to be derived. So it would need to pass the dataitem to the
> routine that does know how to determine if updating is required, etc...
<snip>
|
Not Categorized, Please Help
|
|
