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

[Shriram Krishnamurthi <address@hidden>]

Dan Weinreb wrote:

> It's not clear to me that "having a read-eval-print loop" has
> something to do with the "weight" of a language.

No, clearly not.  Indeed, our student, Paul Graunke, has provided a
REPL for Java since about 3 years ago, and I refuse to sign off on any
definition of LL that includes Java. (-:

> So, the big question that didn't actually get addressed at the LL
> conference: what is the criterion (or what are the criteria) for
> distinguishing between a "lightweight" language and other kinds of
> languages?

Let me offer a few thoughts:

1. I should be able to write expressions without wrapping them.  That
   is, no publicstaticvoidmainmumbojumbo.  This may be the single most
   important property.  It distinguishes LLs from the Pascal mindset.
   Cue Brian Harvey of Berkeley: "Pascal is part of the same machinery
   as hall passes, dress codes, advisors' signatures, single-sex
   dorms, and so on."

2. I should not have to declare types most of the time.  This is NOT
   the same as saying the language does not enforce type boundaries
   statically: in this sense, ML counts.

3. I should be allowed to submit, but not run, buggy programs.  That
   is, for rapid prototyping, I should be able to write a program with 
   3 functions, A, B, and C; C can be buggy, but so long as I use A
   and B only, I shouldn't be prevented from running the code.  ML
   fails at this.  The ML-like type systems for Scheme succeed.

4. Implementations must be safe, ie, they should catch mis-application 
   of primitives to values of the wrong kind.

5. I'll cross the line from language to implementation (hit me hard on 
   the head, Simon!): it needs to provide a rapid execution
   environment.  The Perl folks prefer the command line; us paren
   wankers like a REPL.  Whatever.  I shouldn't be forced to go
   through some sort of compilation process.  As you point out,
   however, this is a property even C enjoys (indeed, I remember
   using a C interpreter as far back as high school (~1985)), and Java 
   can support.  So it's not sufficient, but it sure is necessary.

6. Arguably, a good LL must also provide useful libraries for
   practical tasks, maybe even a nutshell book (if not under the
   O'Reilly imprint), etc.  But I would not include those in the
   definition of LL.  They merely determine whether the LL is useful,
   and whether you'd want to use it.

>						    Or that having
> lexical scoping is a "weight" thing.  

No, except inasmuch as wanton disregard of the canons of lexical scope 
seems to be a common attribute of LLs. <-;

>					I'm also not sure whether
> "weight" is more a property of the language definition in the abstract
> as opposed to a property of a particular implementation.

I do think it's a property of the language.  I think #1 is
definitional, but #4 is a key player.  We don't want seg faults from
our LL, so we want safe implementations.  On the other hand, some
languages compromise this property by making just about every
syntactically legal program have some meaning.

Hence, I'll propose that weight is inversely proportional to the
number of syntactically legal expressions that execute correctly.  In
that respect, Arc is like Lisp on a diet.

Shriram