Re: choosing a language for your audience or macros vs syntax?

[Ken Anderson <address@hidden>]

Thanks, Neel and Shriram,
I should have remembered that Guy Steele sent out a little example of an interpreter with call/cc to this list a while back, so call/cc can be easy if you designed for it.

Neel, is it really "3000 KLOC" ie 3,000,000 lines of code?

Shriram,
JScheme does have Dori's macros by example < 500 lines, as well as a much larger macro system.  I agree that we should use them to be a good example, but my first attempt failed, and it was too easy to fall back on old Blub ways.  I'll try again.

At 12:26 PM 11/14/2002, Neel Krishnaswami wrote:
>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