OpenEuphoria

Re: voting on GOTO

• Posted by Chris Bensler <eu at cr?ativepo?tal.ca> Jun 05, 2008
• 795 views

Mario Steele wrote:
> 
> Heh, Chris, I remember a time, when you believed Euphoria's Memory Management
> libraries we no where near what it needed to be.  So you wrote your own memory
> routines.  Were they absolutely nesscary?
> 
> allocate_string()  = allocate(length(string)+1)
> poke(mem,string,length(string))
> 
> You created the library, was it absolutely nesscary, just on the off chance
> that someone else would find it useful?  That it, as you said, "might be
> implemented"
> ?
> 
> Mario Steele
> <a
> href="http://enchantedblade.trilake.net">http://enchantedblade.trilake.net</a>
> Attaining World Dominiation, one byte at a time...

Hi Mario :)

First, I never indicated that Eu's memory management wasn't adequate for the
language. The reason I developed heaps.e was to accomodate grouping allocations
together for the sake of the structs.e library, since a struct could contain
pointers to other structs which could contain pointers to other data, etc.

In the end, I found heaps.e was too cumbersome to be useful and resorted to a
more manual approach.

I can in fact totally turn your argument around. Yes I did try to create
something to enhance the programmers productivity, and I spent alot of effort to
try to make it work well, in the end I realized that it was not worthwhile even
if it did work well on the back-end, it was not very friendly for the programmer
front-end. Fortunately I had the luxury of it being a library that nobody was
using, so it was easy to scrap the idea.

Going back to the discussion of goto. As I said before, I'm not really for or
against it. I voted no because nobody has been able to show a legitimate need for
it and because it's always easier to add it later than to take it out when/if
it's regretted. I'm just not about to say yes, toss it in there, because some
people say 'why not!?'.

There is a plethora of things that could be added to presumably increase Eu's
flexibility. Should they all be added just because they can be?

Why is goto even being considered at this timeanyways, if there is no real need
for it? We should be trying to fill in gaps in the language, not put sprinkles on
the cake.

I would much rather see oop, named sequence elements and better C interfaces to
name a few things off the top of my head which I do miss DAILY.


Chris Bensler
Code is Alchemy