[gameprogrammer] Re: More scripting engines
- From: David Olofson <david@xxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Fri, 30 Apr 2004 09:49:39 +0200
On Friday 30 April 2004 07.32, grant hallman wrote:
[...]
> >Implementing a goto into a block structured language is a real
> > pain. Gotos always cross block boundaries and interfere with
> > variable scope. So, a goto has to clean up the stack for the
> > appropriate number of levels and then do the jump. It is hard to
> > handle properly in C. In languages with scope exit rules for
> > invoking destructors, like C++, goto become a serious
> > implementation problem.
>
> Yikes, who uses gotos that way?
How do you prevent it? (Preferably without having the programmer go
"Why the H*LL do I get an incomprehensible compiler error for putting
that goto there!?" :-)
> I'd think a goto statement would be
> restricted to targets within the same block(s), which should avoid
> entirely those issues.
You mean, labels follow the same scope rules as local variables? Yeah,
that makes sense... (In my compiler, I'd pretty much have to bypass
the whole symbol table logic to do anything else. The "table" is
actually a tree, and symbol lookups only climb towards the root.)
However, it doesn't really avoid the problem, as it's still possible
to jump back and land before initializations, or even (if the
language supports mixing declarations with other statements, like C99
or C++) jump over initializations. If the compiler is required to
insert code for automatic memory management and stuff, that means a
real flow analysis system is pretty much *required* to ensure, not
only optimal, but *correct* code generation. That sort of reduces the
chances of ever seeing more than approximately one correct
implementation, I think. ;-)
> It's a mixed bag, and while gotos can be misused, a break deeply
> nested in a complex structure can be just as deadly.
Sure, but what I don't quite get is how a break to a named block is
worse than a goto.
> But the bigger
> point is, their use is a style issue.
Indeed. Some would even tell me to drop break altogether. ;-)
> It's a language's job to
> offer features, not to try to impose a programming style. That's
> just annoying, and leads to even clumsier workarounds.
Right, but as it is, I personally don't find goto very useful - and I
prefer to leave things out until I can prove they're needed, rather
than throwing in everything but the kitchen sink "just in case".
I'll reconsider goto when I see a problem that can't be handled nicely
with higher level constructs. I'd look into inventing "new" high
level flow control constructs before resorting to bypassing them. The
point is not to dictate how things should be done, but to provide
truly useful high level features that really get the job done.
> If OO had
> lived up to the promises of its early advocates to impose good
> style, we'd live in a better, more robust, more efficient
> programming world. It doesn't work.
Well, I suppose that depends on what you mean by OO, but indeed, the
"purist" versions generally map well only to a limited set of
problems. OO, imperative, functional, table oriented etc all have
their use, and mixing them to some extent is often the optimal
solution.
Problem is that if a explicitly language supports *everything*, you
get something that takes ages to learn, and makes it hard to
understand other people's code. Just look at C++ - and I believe it
can get h*lluva' lot worse than that if you throw in dynamic typing,
"call-by-name" and stuff like that as well... I believe there has to
be both upper and lower bounds to the level of native language
features to make a sensible language.
//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:
