Park - Park is, is not, is too, is not Arc

Shlomi Fish

This document is copyrighted by Shlomi Fish under the Creative Commons Attribution License version 2.5 (or at your option a greater version). The code samples are under the Public Domain.

Revision History
Revision 321 June 2006shlomif
Started working on this document after forking the template of an older one.

Table of Contents

Park - Park is, is not, is too, is not Arc
Why am I Doing it?
Why a new Dialect?
What Park is based on
Elements of Design
Arc is Object Oriented (Everything is an Object)
Lexical Scoping and Dynamic Scoping
Park would be Fully POSIX
Thoughts about using Monads for Files
Bootstrapping, Self Hosting and C Hosting
Constants in Park
Strings, Quoting and Interpolation
String Constants
String Interpolation

Park - Park is, is not, is too, is not Arc

Park [1] is a new dialect of Lisp, based on Paul Graham's Arc effort. Park is in fact a malicious and incompatible fork of Arc. A fork not of the code, which is still not available to the public, but of the concept and motivation.

The origin of the name is with an initial implementation for Arc that I wanted to write for Parrot, called PArc or Parc. However, then I realised I disagree with Graham about some of his language design elements. A few days ago I came with a revelation that it was hopeless waiting for Mr. Graham to actually release either a final spec to the public of Arc or a actual working code. Arc was announced at the LL1 conference at November 2001. It's been almost 5 years from now, and there's still not a working code or a coherent spec. Furthermore, Graham stopped adding the ideas people sent him to the emails collection containing them (including one that I sent a few years ago, which I know he is aware of because he responded to my message).

Thus enter Park. The name stems from "Parc" but is actually an English world. One can say that Park is a LISP that starts with "P", or that working with it is like a stroll in the Park. Park has the design goals of Arc but:

  1. Is different and incompatible.

  2. Has a working (albeit so far informal) spec.

  3. Encourages participation from the community (using such web resources as a Subversion repository, a Wiki, etc.)

  4. Encourages people to create and hack on implementations for it.

  5. Would try to get version 0.2.0 of the SPEC (the first stable version of the language) out of the door as soon as possible, so people can create implementations that they can rely on.

One note about myself. My name is Shlomi Fish and I'm a software enthusiast and a writer. I am not the ideal person to design Park, but I believe and hope that I have the right attitude. If you happen to know better about some things, please post your corrections to the mailing lists to the mailing list. Corrections in the form of patches against the Docbook/XML source are preferable. Several of them or even just one that is accepted will get you a Subversion commit access. And naturally everyone can edit the wiki.

Why am I Doing it?


All language designers are arrogant. Comes with the territory.

 --Larry Wall

Why am I doing it? For several reasons:

  1. Because it's fun. This is by itself a good reason.

  2. Because I found that designing your own language is one of the best ways to learn more about the original languages it is based on. When I designed the Perl dialect "Rindolf", I learned that some features I suggested for it were already doable in Perl 5.

  3. Because something good may eventually come out of it. The existing popular dialects of LISP are Common LISP, Scheme (which some people claim is not entirely Lispy) and some domain-specific Lisp dialects like Emacs Lisp and Autolisp, which are not useful for general programming.

    The Common Lisp and Scheme standards still exhibit some relics of the Lisp distant past, where it was expected to run on such now obscure systems as the PDP-10 and ITS or the LISP Machine. They do not correspond to the modern's world "All the world is a VAX" and "Everything on top is a UNIX" reality. (Which has persisted for better or for worse).

    The implementations themselves do little to solve this problem, as they differ in the APIs they provide for such basic mechanisms that programmers of other dynamic languages (like Perl, Python, PHP, Ruby or Tcl) take for granted like Random File I/O, Sockets, Regular Expressions, CGI Programming and Web Automation, Graphical User-interface, Database Connectivity etc.

Why a new Dialect?

Paul Graham explains it very well in the Arc FAQ, and in "Being Popular". Park is Arc done faster, and hopefully also better.

[1] The "Park - Park is, is not, is too, is not Arc" slogan is temporary. The permanent slogan so far seems like it would be "Park - a LISP that starts with P".