🚀 go-pugleaf

(Can you keep your lines to ~70 characters instead of 80?  Thanks)

In article <4321kd$cne@news0.rain.rg.net> Paul Long <plong@perf.com> writes:

...

> Actually, there is more to Zahn's construction. He and Knuth allow multiple
> indicators and an optional _then_ clause that follows the statement. In C, the
> entire thing might look like this:

>     until (<identifier1>, <identifier2>, ... <<identifierN>)
>         <statement>
>     then {
>         <identifier1> => <statement>
>         <identifier2> => <statement>
>         ...
>         <identifierN> => <statement>
>     }

> The _then_ clause provides separate "post-until" logic for each situation.


As someone who has hacked around with scheme, this entire setup
screams a need for a compiler that
	a) handles tail-recursion properly, and
	b) provides "escape procedure" continuations.
In scheme, the until...then syntax can be emulated with something
like:

(call-with-current-continuation
  (lambda (cont)
    (letrec ((ident1 (lambda () (statement1)))
	     (ident2 (lambda () (statement2))))
      (body))))

This binds ident1 and ident2 as thunks within body, in a manner
similar to the binding of <identifier1> ... <identifierN> in the first
<statement> above.  By ending the both of the thunk bodies (statement1
and statement2) end with calls to cont, they can emulate the exit
behavior of the until...then syntax.


That said...

I actually like the looks of the until...then syntax.  Yes, it's
syntactic sugar.  So's most the rest of C or any other language.  I
like it because it's a relatively clear method for describing a
many->many flow control, as opposed to a combination of the one->many
'if' and many->one 'break' and 'goto'.



> I dunno. Looks kinda awkward, but then C's for and switch syntax is
> pretty ugly, too. I'd vote no on multiple situation indicators. It
> would really be nice for robust structure exception handling,
> though, where each exception could be identified separately in the
> code, such as end_of_file and read_error, and each could have
> separate error-handling code. The above example could be written
> like this:


While this syntax is overtly similar to C++'s catch/throw syntax, the
different objectives lead to a huge differance in the power and ease
of implementation of the two syntacies.  C++'s catch/throw has dynamic
scope (as opposed to until...then's static/lexical scope), and thus
requires a runtime-stack of catches, while until..then is rather
easily analyzed at compile time, though it could really make
optimization (flow analysis in particular) difficult.


<deleted>

> Knuth also allows situation indicators to pass arguments to their counterparts
> in the then clause. Nice, but we gotta draw the line somewhere. :-)


Of course, if the basic until...then syntax was in standard C, passing
arguments to the indicators would be a gcc extension.  :-)

This actually wouldn't be particularly more difficult to implement
than the basic syntax.  It's much closer to initialized local
variables then a function call.

BTW, it was this that originally made me think of scheme, and this
extension is trivial to add (and obvious) in the scheme fragment I
gave above.



> Although situation indicators would be really nifty, I'm also inclined to
> reject them because they just make C a bigger language. There is some value in
> not having a zillion ways to do something. What do you think?


#define PHILOSOPHICAL_DIATRIBE

The criteria for what should be in a language is not size or
necessity, but rather usability and implementability, where usability
encompasses power, ease of programming, debugability, readability,
predictability, etc.  Something like orthogonality is important
because it (usually) supports both of these.  Simplicity on the other
hand may be downplayed if it decreases the ease of programming too
much, or stressed if it makes the language easier to compile.  The
language designer(s) choose(s) the line he/she/they will walk.

#undef PHILOSOPHICAL_DIATRIBE

In designing C, dmr choose a set of language features that were all
well within the range of implentability on the machines of the time.
While the numerical extensions groups is working to remove the
vestiges of its implementation roots on the arithmetic side, the core
ideas of flow control and the like haven't really changed.  IMNSHO,
that's because the next step up in 'power' (expressability, whatever)
in flow control are things like continuations and exceptions, both of
which are fundamental changes to the language, and pretty tough to get
right.  I think until...then is very close to the spirit of the
language (it's not a leap in paradigm), and that it could improve
legibilty of many pieces of code, if just in it's "local error
handler" usage.  Would it lead to spaghetti code?  Got me.  Were it to
be added to the language, I'm sure there would be people who would
misuse it.  However, those people can (and probably do) write
spaghetti code with the existing syntax.  The only language which
doesn't have spaghetti code is the language with one valid
program... "stop".  :-)

#undef_for_real PHILOSOPHICAL_DIATRIBE		/* dang, try again */

:-)


Philip Guenther

----------------------------------------------------------------
Philip Guenther			UNIX Systems and Network Administrator
Internet: guenther@gac.edu	Phonenet: (507) 933-7596
Gustavus Adolphus College	St. Peter, MN 56082-1498
I am _not_ a representative sample of the Gustavus Community.  Yeah, right...
Source code never lies (it just misleads).  (Programming by Purloined Letter?)