[gameprogrammer] Re: More scripting engines

At 09:49 AM 30-04-04 +0200, you wrote:
>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!?" :-)

Yeah, the wording of the error messages is pretty important. Please make
them relate to what the programmer has done, rather than what the compiler
has just done! But in this case:

"Error: goto at line xxx, target label zzzzzz at line xxx are in different
scopes (name of offended scope and its starting and ending line numbers)".

>> 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...

Yes, that would likely do it.

> (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,

Well, then come the initializations, what's the problem? Gimme example.

> or even (if the 
>language supports mixing declarations with other statements, like C99 
>or C++) jump over initializations. 

Far as i'm concerned, u can leave that out. That kind of stuff leads to
"cute code", which IMO is deadlier than gotos.

>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. ;-)

In the sense that "2 + 2 = 5, for sufficiently large values of 2" ?

>> 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.

It isn't if it's done right, neither is "bad". But if u have a complex wad
of blocks, say a do while around several more do's containing multiple
switch statements each containing nested do's, and somewhere down in the
mess u say "break", i have more than a few times gotten wrong (or worse,
compiler-dependent) ideas about where that break was gonna take me.
Sometimes it was in my own code, which is a bit unworthy, but $hit happens
during mods. 

>> 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. 

Error messages, or string parsing, are two examples that come to mind. A
really squeaky-clean C coder will sometimes deal with multiple error
conditions in a way that has the main functions of the module indented 12
times and pushed 'way off to the side. In my experience, that coding style
may result in subtle dependencies between multiple errors, and is hard to
read. I want to look at a module and say "look, here's what it does, and
'way down here is where it deals with exceptions", not "Migawd, what a
clever nesting of if's and while's, ummm, what does it _do_?"

To me, a good coding environment lets the programmer spend more time
thinking about the problem, the module's mission, and less time thinking
about the language, like how to get a fatal error condition noted and get
the heck out.

>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.

Exactly what i'm saying. If u make it C-like, it will be easy to pick up.
Heck, we're scripting, right? This is not a tool for some ivory-tower comp
sci prof who's never had to support other people's code for a living. We
need a bulldozer and a pickup truck, not a limo. "Blue Collar Coding" :)

cheers - grant

Other related posts: