Abstract state machines and Joy

wtanksley@bigfoot.com — 2000-06-08 00:42:57

From: Louis Madon [mailto:madonl@...]

>Hello all,

>I just discovered the list. Its nice to see that Joy seems to be of
>interest to a number of people. I've also
>been inspired by Joy and have in fact been working on a Joy
>implementation for some time now. Anyway, I'll just jump
>into the current discussion with my 2 cents ...

It's great to hear this. I'm quite happy that this list is bringing
together some good efforts; I was worried that now was the wrong time for
this list, but it seems that it might serve a good purpose after all.

>Do you really think that having a totally extensible language syntax is
>a Good Thing? It adds a lot of conceptual mass to the language
>(syntactic macro systems tend to be complex) and it makes the
>distinction between core syntax and extended syntax blurry.

This is certainly true for languages which require partial parsing, such as
Tcl and Rebol; of course, when the embedded language matches the existing
language it's actually rather convenient.

>If I really needed to embed another language I would rather just
>parse strings, eg:

> "For x in <10,20,30> do Print x;" mylang_call
> => 10 20 30

>Here, the mylang_call function takes a string, compiles it into a
>program and executes it. There is a clear separation between the core
>language and the embedded syntax thanks to the quotes. Moreover, at
>least in my version of Joy which will support partial evaluation, the
>mylang_call function will get executed at compile time since all its
>inputs are available; so there is no additional runtime cost.

That's really interesting. It's also interesting that you're able to
determine what parameters are and are not available; my guess is that you do
that similarly to how Dr. Betcher carries out static type checking, correct?

As I've mentioned before, Forth adds an additional element to
concatenativity: Forth words can also access the source code which follows
their invocation, so that you can define words which arbitrarily manipulate
source. This is safe, because none of the source they manipulate has been
seen by the compiler or parser.

>Having said that, I do believe that Joy implements too much at the
>primitive level (lists, sets, strings, etc) though.

This makes sense to me, and I like primitive implementations.

>In my Joy-like
>language, the fundamental association primitive is the dynamic function
>(aka updatable, variable or mutable functions, a notion from Abstract
>State Machine
>theory - see http://www.eecs.umich.edu/gasm and in particular take a
>look at Martin Odersky's paper "Programming with variable functions" at
>http://www.eecs.umich.edu/gasm/papers.html#varfun).

Wow, a combination of GASMs and Joy -- now I'm really happy. I've been
impressed with ASMs since I first read about them. I look forward to
hearing more about your work.

There's one other language I've seen which attempts to model mutability in
the context of a purely functional language; it uses series. Your functions
are allowed to access future and past elements of any series (and that
access, of course, forces them to be computed). I was impressed with how
elegantly the language worked, but I've been unable to find it ever since.

>http://www.uni-ulm.de/~s_jschmi/AsmGofer).

This is quite facinating!

>Louis.

-Billy