[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Var-free programming (slightly off-topic)
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
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.