choosing a language for your audience or macros vs syntax?

[Neel Krishnaswami <address@hidden>]

Ken Anderson writes:
> 
> Matz thought macros were too hard for average programmers, but
> call/cc was worth implementing.
> 
> This got me thinking about JScheme.  JScheme, is a simple Scheme
> dialect in Java, that has macros but no true call/cc.  [...]  Does
> Ruby's call/cc take a lot of work to implement?  I suspect macros
> would be a lot of work because of the syntax, but i suspect that
> culturally, macros were not important, for lack of experience.
> After all, Ruby makes a lot of things easier to program, so maybe
> that's enough.

These two issues seem like two facets of the same question to me. It's
not a cultural question, so much as a janitorial one.
 
If you have a runtime that allocates activation records on the heap,
as Ruby, Python and Perl all do, then getting a call/cc is not that
much code. Likewise, adding macros to an infix language with a
suitable syntax is not that much code: the macro expander for Gwydion
Dylan is about 3000 KLOC. However, maintainability is not just a
function of how much code a feature is, but how well understood the
implementation of it is.

The correct structure of a classical interpreter is very well known:
lexer/parser/bytecode compiler/VM/runtime. Adding call/cc to this
structure amounts to adding a single function to the runtime.  Adding
a macro expander adds a whole new phase to your implementation. You
need lexer/parser/MACRO-EXPANDER/compiler/..., and there's not really
a huge amount of literature on how to write this new phase, how it
affects the design of the parser, or what the right design (Hygienic
or not? Procedural or not?) for it is. Most of the literature that
does exist is for s-exps, which helps only modestly when you have a
language with a conventional syntax. So if you want to make the
implementation "open" to newcomers, you discover a strong bias against
pushing the state-of-the-art, and adding macros.
 
The same is also true for type checkers. There's surprisingly little
written about the pragmatics of writing typecheckers, as opposed to
type theory. I think with Needle that the typechecker implementation
is going to scare people off anyway. So the marginal cost of macros
(in terms of additional discouraged compiler hackers) is low, and the
marginal benefit (in terms of reducing the *need* for compiler
hacking) very large.

(As an aside: one of the things that jumped out at me on Saturday was
that so many of the language features discussed could be implemented
with macros and/or call/cc. Dynamic scoping, lightweight concurrency,
block/unblock, logic programming, checkpointing -- all of them!)


-- 
Neel Krishnaswami
neelk@alum.mit.edu