[gameprogrammer] Re: More scripting engines

gotos may be evil but at the core of computers that's pretty much all you
got (:

jmp
jnz
call (special case yeah...)

etc :P

----- Original Message ----- 
From: "David Olofson" <david@xxxxxxxxxxx>
To: <gameprogrammer@xxxxxxxxxxxxx>
Sent: Thursday, April 29, 2004 1:52 AM
Subject: [gameprogrammer] Re: More scripting engines


> On Monday 26 April 2004 08.41, grant hallman wrote:
> > At 06:39 PM 24-04-04 +0200, you wrote:
> > >On Saturday 24 April 2004 17.18, Bernhard Bliem wrote:
> > >> That's an interesting idea. However, wouldn't a goto be actually
> > >> sufficient?
> > >
> > >Sufficient, but not adequate. In fact, I'm probably not going to
> > >support goto at all, considering the horrible mess it tends to
> > > create when mixed with higher level flow control constructs. (Etc
> > > etc.)
> > >
> > >In short, goto is plain evil. :-)
> >
> > Personally, i suspect brainwashing ;)
>
> Dunno if that has anything to do with it, but I'm a mostly self taught
> programmer, and I just plain don't like goto in languages that
> provide higher level control flow constructs. It makes the code
> confusing and easier to break when refactoring.
>
> I used gotos for error handling in C until not too long ago, but I
> never liked it, so I stopped. (And this is in a language without
> try...except blocks or similar... EEL will have those, of course.)
>
>
> > Goto can be part of hideous code, no doubt about it. But according
> > to the NRA, goto's don't hurt programs, it's programmers who hurt
> > programs ;-D
> >
> > IOW, if a programmer does not think and code clearly, nothing the
> > language does can save the results, and if (s)he does, (s)he will
> > write good code whether goto is available or not.
>
> Of course, that's a good point. :-)
>
> Either way, it's my language, and I don't use goto. If you really want
> it, you can submit a patch and see if you can convince me that it's
> useful. ;-)
>
> More seriously; I'd prefer it if the control flow constructs actually
> did the job, so you don't have to "fix" them by using goto. High
> level control flow constructs are *nested*, but goto totally violates
> that whole idea, even if that's not what the programmer intends.
>
>
> > A good clean goto
>
> IMNSHO, a goto can never be clean if it jumps across nesting levels.
> Right; not that I really care about rules just for the h*ll of it,
> but this one is actually important. Funky stuff easily happens when
> you start bypassing the native constructs of a language...
>
>
> > with a sensibly-labelled target in plain view, is far easier to
> > read, support etc. than the eleventy-deep-nested "break"
>
> How is the goto any less deeply nested than the break...? The break
> would refer to a nesting level by name, and the goto would refer to
> some labelled location in that nesting level.
>
>
> > which the
> > compiler will turn into an asmb goto anyways.
>
> If the generated code had anything to do with anything, I'd just drop
> all the high level control flow constructs and throw in conditional
> goto instead. ;-)
>
>
> > It's better, because
> > it's explicit.
>
> I disagree. The "break <name>" is *more* explicit than a goto.
>
> * The block name referenced is explicitly a block name,
>   and not just some place where the coder happens to put
>   a label.
>
> * You can't accidentally place some code on the wrong
>   side of the label, because the name is associated
>   with a nesting level; not a code position.
>
> * "break some_level;" explains more accurately what
>   you want to do than "goto some_label;". It actually
>   means "keep break;ing until we're on some_level",
>   which is *exactly* what I mean when I use such a
>   construct.
>
>
> > >However, "break <n>", while rather nice and useful in cases, is
> > > pretty evil as well. The biggest issue is that you can't clearly
> > > see where you land, and it's easy to mix up ordinary {...} blocks
> > > with breakable blocks and land totally off without even getting a
> > > compiler warning.
> >
> > Hey, if u have a clear goto label, u see just where u land.
>
> Yeah, but I don't want to tell the compiler where I want to land.
> "break;" means "leave the current breakable control flow block." I
> don't want to use some completely different construct just to say
> "leave the current block, and then leave the block I land in as
> well".
>
>
> [...]
> > >So, I figured if I reference outer scopes by name when breaking
> > > more than the current level, the code gets more readable, you
> > > can't accidentally land on the wrong level, and the risk of
> > > breaking stuff when you modify the code is lower.
> >
> > A close runner-up, IMHO, and rather more tedious to implement.
>
> No big deal. I just support explicitly naming code blocks (as opposed
> to giving them an internal dummy name), and then I put a loop around
> the code that prepares for leaving a code block. (That's where local
> reference variables and stuff is dealt with, so you don't leak
> objects when backing down the stack.) And finally, the jump
> instruction. :-)
>
> Implementing goto is actually harder in a language with automatic
> memory management, it seems... The biggest issue isn't this part
> (dealing with leaving "contexts"), but the fact that you can also
> jump over initializations. It's hairy enough as it is to verify that
> conditional code can't leave variables uninitialized.
>
>
> //David Olofson - Programmer, Composer, Open Source Advocate
>
> .- Audiality -----------------------------------------------.
> |  Free/Open Source audio engine for games and multimedia.  |
> | MIDI, modular synthesis, real time effects, scripting,... |
> `-----------------------------------> http://audiality.org -'
>    --- http://olofson.net --- http://www.reologica.se ---
>
>

Other related posts: