[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

More on Full Specification

    This reader sees sharks in the water...

Me too.

There are those who like the idea of a simple, powerful, and dangerous,
language.  My introduction to Scheme was via the Dan Friedman approach.
Immersed in a sea of closures, continuations, assignments and macros,
I felt very much like shark bait.

I have grown to love the simple and powerful aspects of Scheme, and realize
that danger will always lurk where there be simple, powerful beasts.
However we should do what we can to tame them without declawing them.

Paul Hudak's response made many of the points I meant to imply.

I think we should recognize forthrightly that Scheme is not a
``functional'' language.  Along with first-class procedures, a feature now
shared with several languages, Scheme also has assignments and continuations.
This combination makes Scheme special.  It also makes Scheme dangerous,
in the sense that they can interact in surprising ways.

Because of its power, Scheme needs a complete and understandable semantics.
Because of its simplicity, Scheme can have one.

We have approached it, but fallen shy of the mark in key areas.  I should
like to see us head back in that direction ``before it is too late.''

I am not so much arguing for my specific proposals (although I did mean them 
seriously), as for a move toward full specification, whatever it entails.
I think it can lead us towards simplification.  As Hudak points out, the
unspecified must be specified as such.

It would perhaps be nice if procedures (and forms) done for effect did not
return values, as Pavel suggests.  This however does introduce real
command procedures into Scheme, and we should then enforce their no value 
status.  Is it better to deal with that complication or simply let them
return reasonable values?  At any rate I think it should be clear what is
returned.  One possibility, if one wants to preserve the for-effect-only status
of such procedures, would be for them to all return the same useless value: 
#f or #t or something new like #n (for no-value).

Would we ever really want to allow the evaluation of procedural expressions
to occur simultaneously?  I am not sure there is such a thing as 
``a small piece of nondeterminism,'' as Pavel also suggests.  
Do we want a non-deterministic semantics?  
I think the current ``arbitrary permutation'' in the semantics
is terrible, since it really doesn't reflect the intent, 
which I understand to be that procedure calls may be evaluated in different 
orders within the same program, and perhaps even concurrently.

As for internal definitions, one of the disturbing things about them is
that they look like top-level definitions but don't act like them.
One should remember that one of the big arguments for internal definitions
was convenience, particularly in lowering nesting levels.
Consequently such uses as
    (define x (car y))
cannot really be considered invalid, and something like
    (define y (z))
    (define x (car y))
looks perfectly reasonable, given that all other expressions in a body
are evaluated in order.

Finally a note about implementation issues.  Although, as one greatly involved
with implementing Scheme, I can understand their seduction, I think
we should fight it.  First-class procedures and continuations combined with
lexical scoping, assignments and indefinite extent for variables appeared 
to deliver a knockout blow to implementation efficiency.  The fact that 
good implementation techniques have appeared anyway is good reason not to
be too quick to worry about implementations.  After all, an implementation
can do what it pleases as long as no one can tell the difference.  Thus
if it can prove that order of evaluation doesn't matter, or that variables
can't be referenced before definition, it can make appropriate optimizations.
The next great step in Scheme efficiency will require extensive program
analysis anyway.  I think people are still attracted to Scheme by the
structure and semantics of its powerful features, and that is what we should 
concentrate on.