OpenEuphoria

Re: Goto (Was Re: Open Source)

• Posted by CChris <christian.cuvier at ?griculture.?ouv.fr> Oct 28, 2007
• 764 views

Chris Bensler wrote:
> 
> CChris wrote:
> 
> > Simple examples like this always convert nicely. "hello world" programs
> > almost
> > always look simple in any language. Then real programming comes in and makes
> > a difference.
> >
> > etc...
> > 
> > CChris
> 
> Well said CChris.
> I'm a firm beleiver that development speed and corelation between
> design and code are paramount traits of a quality programming language.
> 
> While I do not advocate the use of goto, debating it's validity based on 
> 'poor programming habit' is an extremely moot point. Good programmers will
> write
> good code
> and bad programmers will write bad code, regardless of what tools are
> available
> to them.
> I see no reason why it is any of my business if someone else chooses to use
> it.
> I still have the choice if I want to use their code or not.
> For the end-user, it's pretty much irrelevant what language is used to
> create a program, nevermind what constructs are used in the underlying code.
> 
> The issue of goto is more of a debate on coding style than anything to do with
> practical programming. In my mind it equates to the same argument as code
> formatting.
> 
> I do think that the use of goto should be discouraged, but it is not my place
> to dictate
> how others should write their code.
> 
> The real issue is 'does goto belong in Euphoria?'
> 
> My thoughts are that we should address the desire for arbitrary jumps as much
> as possible
> with high level constructs first, before we consider the addition of goto.
> I don't feel that goto really fits into the Euphoria language.
> 
> In a nutshell, I beleive implementing goto before we explore more appropriate,
> higher level constructs, is putting the cart before the horse.
> 
> 
> Chris Bensler
> Code is Alchemy

I'll try submitting shortly a set of Eu front end files that add a number of
imho needed enhancements to the language. The additions are:
* forward routine calls allowed, using

forward function f(integer z)
n=f(3)
--- some code here
function f
-- usual routine body here

* new scope keyword, to declare variables local to part of a routine/top level
code, possibly shadowing existing symbols;
* nested routines are now supported. For consistency reasons, you can call only
a routine which is a direct descendant of any ancestor of te current routine.
* new loop

loop do
-- some code
until some_condition
end loop

* exif exits an if block;
* inside a oop, next skips the rest of the current iteration and performs any
code prepring the next;
* retry jumps to top of loop, without executing the code that prepares next
iteration;
* all loops can have a label attached to it, like this

for i=1 to n by 2 label "my string" do

* exif/exit/next/retry now have an optional parameter, either
+ a nuber of loop above current one (1 = loop above, 2=loop above the
latter,...)
+ a negative number, to count loop levels backward (-1 = topmost loop, -2 = all
but topmist,...)
+ a string, which must have been defined as a label prior;
+ the name of a for loop index.
* defaulted routine parameters, with ability to default any parameter, not only
the last one(s)

The only mod to backend would be to update be_syncolor.c so that the trace
screen displays the new keywords as such.

I'll submit this to user contributions spùewhere in november. If I ever write
some new code in Eu, I'll probably use and require that new interpreter. I'll
attempt to also implement pass by reference, but this may or may not work. An
earlier implementation I had just does no longer work with multitasking.

CChris