[gameprogrammer] Re: More scripting engines

On Thu, 2004-04-29 at 11:30, Alan Wolfe wrote:
> gotos may be evil but at the core of computers that's pretty much all you
> got (:
> 
> jmp
> jnz
> call (special case yeah...)

Yep, which is why we pretty much gave up coding in assembler.

                Bob Pendleton

> 
> 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 ---
> >
> >
> 
-- 
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: Bob@xxxxxxxxxxxxx             +
+ blog:  www.Stonewolf.net             +
+ web:   www.GameProgrammer.com        +
+--------------------------------------+

Other related posts: