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

Re: bindings and assignments (was: Re: continuations)

Scott McKay wrote:

>       It's the huge gap between what Java could have
> been and what it actually is [...]

Part of the problem is the idea that a language is a monolithic
entity.  In this respect, languages do not match the means we use for
describing them (manuals) and teaching them (texts, tutorials,
courses), which are layered like onions.  Indeed, there is a general
sense that a language not only includes a set of features but also
proscribes others, at least until the governing force gets around to
considering these features in his (this megalomania is usually a "his",
isn't it) ambit.  So we get a linear progression through time --

  Java 1, Java 1.1, Java 1.2, etc

-- but not through (linguistic) space:

  Java x, Java x + tail calls, Java x + tail calls + continuations, ...

You don't even need a full mix-and-match capability for features;
that's tough, anyway (see my message earlier this week re. this).  But
one could imagine a different notion of version numbering where the
multiple versions refer to different feature sets.  So a new release
would result in a shift from

  Java 1.1, Java 1.1t, Java 1.1tk, ...


  Java 1.2, Java 1.2t, Java 1.2tk, ...

So Java could continue to look decipherable to most programmers, yet
some would one day venture into the t or tk language and find a whole
new world of expression.  (There are good reasons for Java to have
been more conservative early on, but now that its keepers must be
feeling the hot breath of C# on their backs, they could take back some
initiative with such a set of releases.  In my dreams, of course.)

A module mechanism like PLT Scheme's MODULE construct, a simple
version of which could be added to most any language (my dissertation
provides a model for this), would make it easy for programmers to
specify which linguistic version (orthogonal to the temporal version)
their program was written in.