RE: Eu's poor design
Derek Parnell wrote:
>
>
> On Mon, 18 Aug 2003 06:54:02 +0000 (08/18/03 16:54:02)
> , Andreas Rumpf <pfropfen at gmx.net> wrote:
>
> >
> > 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...)
>
> I agree with the idea that using global variables is minefield - bugs
> just
> waiting to happen. However, the lack of PBR does NOT force globals
If you want easy coding, you are forced to use globals in Eu. Think
about the stack example.
Remember
> that shared variables can be restricted in scope to a source file. Thus
> a
> source file that implements stacks can use shared variables that are not
>
> global.
Yes, I can't see the globals outside the library, but they are there and
won't be garbage-collected.
>
> > So it seems to me, Eu is a language that wants to be functional but
> > isn't.
>
> Can't see this myself. I don't believe the designers of Euphoria wanted
> it
> to be a functional language.
By the way, there is only one designer - Rob.
>
> > I don't see why using global variables is a better solution.
>
> Neither do I. And I can also see that globals are not the only solution.
>
> I'll send you an implementation of stacks, if you like that demonstrates
> my
> assertion.
I guess, I already know your implementation: You use a global sequence
which contains all the stacks and use an index to access a particular
one. We had this.
>
> >> 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).
>
> Which is the same as saying that we can optimise all variables if none
> are
> ever passed by reference.
NO! That way I have to update the values myself and efficiency is WORSE.
|
Not Categorized, Please Help
|
|
