Re: Var-free programming (slightly off-topic)

[Scott McKay <address@hidden>]

At 11:13 PM 12/4/01, Dan Weinreb wrote:
>    Date: Tue, 04 Dec 2001 18:44:18 -0500
>    From: Scott McKay <swm@hotdispatch.com>

I notice that you omitted the sentence from my mail which says that I
have no yet rigorously defined these terms, so perhaps your reply is
meant to stimulate this?

>      (1) It should have a small, reasonably orthogonal core that has 
> extensibility
>           built in from the start.
>
>What counts as extensibility?  Does this mean macros in the sense of
>Lisp, Dylan, Jonathan's JSE?

Extensibility includes being able to extend classes, functions, and syntax.

A language with powerful macros but no extensible object system doesn't
count.  Java does poorly at this, because extending many useful classes
is too difficult, due to its class-centric notion of OO modularity.  Common 
Lisp
breaks down in the end because the built-in types eventually nail you.  Dylan
does better, but the fact is that "sealing" is complicated.

>      (2) Dynamically typed.
>
>That really needs to be defined.  Does it mean that type declarations on
>variables are not required?

Yes, it means they are not required.  They might be optional, but if so,
they should fit neatly into both the semantics and syntax, not be shoved
in as a kludgy after-thought.

It also means that objects should carry type information, and that
variables should not be required to carry type information.

It also means that there should be no need for casting.

>      (3) Highly layered approach to adding functionality.
>
>I honestly don't know what you're getting at here.

It means that it should be easy to add "libraries" that integrate well
with the rest of the language.  It means that the core language should
not be cluttered with things that belong in libraries.  This, as I said,
is partly a matter of good expository writing.

Common Lisp is especially bad: many things that should be libraries
(streams, pathnames, advanced math functions) just got crammed into
the core language.  They should have been, at the very least, in their
own package and/or described as "higher layers".

>      (4) It should be easy to provide interactive compilation.  This 
> should not
>         stand in the way of being able to compile reasonably efficiently.
>
>Easy for the implementor?  Is this really a property of the language?

Beyond being possible to implement, ease of implementation is a
non-goal.  "Easy to provide interactive compilation" means that the
user model of the language should make it simple for a user to figure
out what interactive compilation will do.

>      (5) Simple programs should require no extraneous boilerplate.
>
>I think I know what you mean here, although even here I'd like to get
>a bit more specific.  Shriram made this point too and I'll comment on
>it when I reply to his mail.

It means that having to worry about libraries/modules (a la Dylan) or
packages/classes (a la Java) before you write your first line of code,
is a burden that a light-weight language should not have.

Again, even a light-weight language should have these mechanisms
in place, you just shouldn't have to dick around with them right out
of starting gate.

>    Here are some failures:
>
>What succeeds?  Only Scheme?

Maybe Scheme.  I can't think of anything else, but for all I know the
best known example is Visual Basic.  :-)

BTW, I think that the scheme of writing special-purpose languages to
address some little task and then growing the language incrementally
as new needs arise, is always doomed to lose.  It's better to get a
good light-weight core in place, and then layer on a special-purpose
library to address what you need now.  Of course, this requires more
initial work.

>    I think the both the language definition and its *exposition* contribute
>    to its light-weight-ness.  Thus, Common Lisp could be described in a
>    fashion that makes it appear more light-weight.
>
>That's an interesting point; I hadn't thought of that.

Oh, I left out the following because it is too obvious:

  (6) Automatic memory management