[plt-scheme] conventional syntax (was: Scheme contradictions)

At Fri, 5 May 2006 10:22:21 +0200, Erich Rast wrote:
> I shouldn't jump in, since this is a rather worn-out topic

My hesitation is even greater, I think. But I feel obligated to point
out that we (i.e., the core PLT Scheme developers) are experimenting
seriously with a more conventional syntax. In the coming months, a lot
of my effort will go in this direction.

> Some of the suggestions for alternative, usually ALGOL style syntax for 
> LISP I've seen so far in my opinion were too half-harted or too much 
> focused on elegancy instead of practical usefulness. If a block syntax 
> is used, it should be as conventional as possible.

Yes.

> In my personal opinion, the 
> only sane choices would be Python syntax or VB/RB-style implicit block 
> syntax (with an end statement).

Your definition of "conventional" surprises me. In a world dominated by
C, C++, Java, C#, and Javascript, I think "conventional" means curly
braces and semi-colons.


In the current version of DrScheme in the SVN repository, if you use
DrScheme's "(module ...)" language, you can run the program

 #honu

 function len(lst) {
   if (isEmpty(lst))
     return 0;
   else
     return 1+len(rest(lst));
 }

 var myList = list(1, 2, 3, 4);

 len(myList);

You'll see the result 4.

The function `len' and the list `myList' above are Scheme values ---
and they're values in this new language, as are all Scheme values.

You can import into #honu from any Scheme library, though you may have
to use the #sx escape to write a Scheme name, perhaps in the process of
switching to a "conventional" identifier:

 #honu
 require rename(lib("mred.ss", "mred"),
                getFontFromUser,
                #sx get-font-from-user);
 getFontFromUser();

Obviously, a long-term solution involves either renaming Scheme imports
automatically or writing a translation for common libraries.

The new language will extensible in the same way as Scheme. I haven't
written the new version of `define-syntax', but much of the
infrastructure is already in place (and it's used to implement the
forms above).

We've only barely started, and there's a long way to go before it's
useful: completing the core language, building a suitable pattern
matcher for macros, re-writing all of the documentation so that it can
be viewed from either world, adjusting error messages for different
contexts, and more. I'm not sure that it will work, and I think we'll
have to invest a lot of effort to find out.


To be clear, I am *not*

 * suggesting that you try to use #honu right now;

 * planning to post more about the design in the near future; 

 * receptive to advice against the experiment;

 * soliciting design opinions; or

 * planning on reduced support for Scheme-style syntax --- though, if
   all goes well, I will eventually switch my primary mode of
   expression.

For now, I just want to let you know what we're trying.

Matthew


P.S. - If you're curious how #honu works, try inserting a ' before
#honu. See also the "Honu" chapter in the MzScheme manual.