Home

PLOT: Programming Language for Old Timers

PLOT: Programming Language for Old Timers by David Moon, 2006-2008.

Programming Language for Old Timers (PLOT) is a new dialect of Lisp designed by Dave Moon in February 2006, and thoroughly revised and simplified November 2007 and March 2008. I have been developing PLOT as a hobby, with the idea of for once having a programming language which does everything the right way. You know it is right when both simplicity and power are maximized, while at the same time confusion and the need for kludges are minimized.

By Luke Gorrie at 2009-03-29 08:19 | General | other blogs | 23843 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Macros

Dave presented an invited speaker talk at the International Lisp Conference entitled "Genuine, full-power, hygienic macro system for a language with syntax". It's somewhat like the Dylan macro system, but radically new. It provides the full power of Lisp macros, but for languages with actual syntax (which Lisp does not have).

In my opinion, this is a very promising approach. It's certainly the best thing I've seen. I discussed it with other Lisp experts after the talk, and the general feeling is that we all understood what Dave said, but the emergent implications are not obvious and would be fun to experiment with.

This talk focused on the macro feature, providing just some basic introductory material about PLOT so that the macro feature can be explained. Dave has in fact designed a whole language, but hasn't published about the rest of it yet.

This was an invited talk. There isn't a written paper, but the slides from the talk are at:

http://users.rcn.com/david-moon/PLOT/Moon-ILC09.pdf

I'm sure Dave would appreciate comments and criticisms.

By Daniel Weinreb at Sun, 2009-03-29 13:56 | login or register to post comments

Is syntax the key?

Many lispers I talk to are constantly amazed that the language is not more widely adopted. Of course, the lack of syntax is at once a revered part of the language, and at the same time, singled out as the most prominent barrier to entry.

I have briefly reviewed Dave's documentation, and short of being able to play with PLOT, I have to say it 'seems' very elegant and holds great promise; I at least am suitably impressed.

But Lisp with syntax has been tried before (Dylan) without success, although having said that, the PLOT syntax does appear somewhat more regular, if I can get away with being that vague. -- Can python structural syntax be considered regular --

Is this how Lisp finally breaks out? I for one hope so; what say you?

By jhenzie at Mon, 2009-03-30 15:34 | login or register to post comments

The problem with Dylan

Besides bad timing, Dylan also suffered from quite a bit of verbosity.

Am I missing something or where are some bits we can play with?

By Dave Lopez at Tue, 2009-03-31 01:55 | login or register to post comments

Might other languages borrow this?

Although it's exciting to think of PLOT's macro system as a breakthrough for Lisp, it might instead be picked up by other languages (just like so many other Lisp features).

The basic idea is that any token can trigger a macro, which then starts reading from the token stream and returns an AST node (or possibly more than one?). Once the macro is finished, the normal parser takes over.

This should be easy to do in any language which can run user functions at compile time—which is probably most dynamic languages. I can see one or more non-Lisp languages adopting this and depriving Lisp of one of its last exclusive strengths.

I'd love to be able to modify Python to give me a macro for "for x in g(): yield x".

By John Stracke at Tue, 2009-03-31 17:41 | login or register to post comments

Dylan verbosity

Perhaps a little verbose, but nothing we couldn't have lived with.

Personally I think Dylan did not make it because of the implosion at Apple and the defacto adoption of Objective-C on acquisition of NeXT.

Thereafter, the world and his dog picked up Java as the next big thing, I think it wouldn't be too much of a stretch to say that, with the same marketing budget, dylan could have cleaned its clock.

Not that Objective-c is a bad language. I just prefer multiple dispatch.

By jhenzie at Tue, 2009-03-31 23:59 | login or register to post comments

Not Objective-C

Personally I think Dylan did not make it because of the implosion at Apple and the defacto adoption of Objective-C on acquisition of NeXT.

The implosion, yes—a company bleeding money didn't need a research project working on a language which only supported a CPU they weren't using any more. But it couldn't have had anything to do with Objective-C: Apple stopped working on Dylan in 1995, and didn't acquire NeXT until late 1996.

By John Stracke at Wed, 2009-04-01 16:08 | login or register to post comments

Still a viable candidate

You are absolutely correct that the development of Dylan and the acquisition of NeXT are separate events, however, my point is that the acquisition effectively crowned Objective-C and eliminated Dylan , and arguably any other language, from the debate.

Of course it can be argued that the discontinuation of Dylan at Apple already achieved that end but I like to think that, had there been an open question, the reasons behind the termination of Dylan would not have excluded it from consideration.

By jhenzie at Wed, 2009-04-01 16:57 | login or register to post comments

Apple's Language Choice

From an outside developer's view, Objective-C had to get through some friction at Apple. Java had its run (not dynamic enough for Cocoa) and the C++ people at Apple hanged on for a long time. The iPhone OS and no 64-bit Carbon finally crowned Objective-C, but the fighting left us with C++ device drivers as opposed to the Objective-C drivers from NeXT.

I think there is still room for other languages at Apple. MacRuby shows the blueprint. If a language can deal well with the Cocoa libraries and call C functions and use C structures, it can bridge to Cocoa.

By Matthew McCowan at Thu, 2009-04-09 15:40 | login or register to post comments

Dylan macro system

While I really appreciate the complete power of a macro system (procedural vs the Dylan one), I still think that debugging this macro system will be quite hard. I have used Dylan for several years now (yes, there are still working open source compilers around), and have to admit that writing macros and debugging them is hard once you do more complicated stuff with macros.

Maybe it is only a question of "having the right tools", so far there is only macroexpand-1 available, no macro stepper, no information what macro variable gets bound to which token and which rule was selected.

(btw, there are also full (Lisp) power Dylan macros, dexprs.pdf, done by Jonathan Bachrach and Keith Playford)

By hannes at Wed, 2009-04-01 13:25 | login or register to post comments

This is a problem with Dylan...

...not with macros in general.

Dylan's macros are basically a slight variation of Scheme's syntax-rules macros. This means that macro expansion is done in a head-driven style: you look for a macro name in the source, and then invoke the macro expander on the form.

The trouble is that this makes writing macros in a compositional style very difficult -- you can't easily build abstractions, because you can't easily write a syntax function and pass it some syntax to expand.

However, Oleg figured that out that if you CPS-convert your macros(!), you can encode the evaluation order you really want, and use this as a strategy to build compositional macros. He wrote a nice paper and several informal articles about this.

By neelk at Wed, 2009-04-01 15:32 | login or register to post comments

thank you

for the reference, interesting paper.

By hannes at Wed, 2009-04-01 17:05 | login or register to post comments

Thanks for this extremely

Thanks for this extremely interesting post! I've always been curious about the various sorts of lispy macro systems, their pros and cons and why certain kinds get implemented certain ways. Did this CPS-converted style of macros ever get implemented as, say, an SRFI in scheme? I'm particularly curious because I want to get comfortable with something like Liskell in Haskell, and I think a large part of proficiency with lisp/lispy syntax is macros.

By Rabi Alam at Thu, 2009-04-02 01:18 | login or register to post comments

Lispy syntax and macros

Well, an important part of mastering Lisp is macros, but it's only one aspect. You can go pretty far without digging too deeply into macros.

As for proficiency with lispy syntax, I'm not sure macros really have much to do with it, unless you want to extend the syntax a bit. Honestly it's easy enough to understand the core forms in terms of simpler concepts, like how to express let in terms of a lambda application. It's instructive to implement your own let in a macro system, less for insight into let per se, but rather more for your own understanding of macros. (Though admittedly that one example doesn't take you nearly far enough, it's only a starting point.)

The most important aspect to proficiency with Lispy syntax is to use the right text editor: you absolutely need one that can, at minimum, automatically handle indentation and re-indentation, and visually indicate which parenthesis you currently closing.

Once you have that, Lisp syntax truly is indentation-based, just like Python.

By Leon P Smith at Thu, 2009-04-02 02:16 | login or register to post comments

Ehh

As for PLOT, I'm skeptical and going to have to play the curmudgeon for a little bit. What's really so terribly wrong with, say for example, R6RS? What are the shortcomings of Common LISP? And how is PLOT really going to fix any of this?

I'd recall Frank Antanassow's "Some words of advice on language design". While I basically agree with his sage advice, there are a couple of points of disagreement; namely that cleaning stuff up might be worthwhile, but probably isn't. And Frank was being a bit overly hyperbolic in grouping Perl, PHP, and TCL in with Python, Ruby, and Lisp. (Although Perl 6 will join the latter group)

Ok, after thinking about things a bit, I guess I sort of see where David Moon is coming from. I'm still skeptical. His macros seem horrendously complex to me... and I wonder if it's really a good move from an implementation point of view. I would think that sometimes it's easiest, and perhaps best, to simply add a few core forms to the language.

By Leon P Smith at Thu, 2009-04-02 02:41 | login or register to post comments