Re: Eu's poor design
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 and
implementing PBR does not FORCE globals either. The use of globals is a
choice that the implementer may use. They are not forced into it. 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.
> 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.
> 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.
>> 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.
>>
>> 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!)
Probability! I'm talking about probability not certainty. I'm sure you are
not extrapolating your statement to suggest that because you have never
detected a bug caused by PBR in your code that it means that you will never
find one in your code, or that no-one ever has bugs caused by PBR. I know
they exist because I have found them in my code and in other people's code.
I recently read somebody saying that garbage collection is a waste of time
and effort because they have always "deleted" everything they "new'd". The
implication was that it was for lazy or incompetent coders only.
--
cheers,
Derek Parnell
|
Not Categorized, Please Help
|
|
