Re: [Chicken-users] Re: YADT: yet another documentation thread

[Alaric Snell-Pym]

On 18 Feb 2008, at 8:05 pm, Mark Fredrickson wrote:

> I've been looking for my "go to" language for a long time. Ruby was
> a strong candidate, but Scheme takes what I like about Ruby and
> gives me more options. I looked at CL but found it weird and
> inconsistent. The little things matter. Now, I plan to plant myself
> firmly in Scheme and see where it takes me.


I guess I should say that I know I'd like to move on from Scheme one
day - but that day won't come until I've been able to implement the
thing myself ;-)

Pretty close to Scheme, though. Mainly, what I'd change is to
slightly extend s-expressions in a subtle way (introducing a
special syntax for records plus a means of namespacing symbols,
mainly), then drop mutability. Mutability is the main obstacle to
really kicking off with some of the more extreme optimisations and
interesting metaprogramming systems, and linear logic offers a far
cleaner approach to the concept of mutation in a pure functional
setting. However, Concurrent Clean, the only really extant linear
language at the moment, has a rather ugly syntax for complex multi-
step world-mutating operations, something roughly like:

someDialogue world::!World -> !World =
   let world' = print ("Hi, what's your name?" world) in
   let (world'', name) = input (world') in
   let world''' = print ("Hello, " . name, world'') in
   world'''

And don't even get me started on what happens when you have multiple
linear worldlines interacting.

What I propose instead, purely as syntactic sugar all done with
macros, is to have an 'algorithm' syntax that wraps a state machine
operating on one or more linear values, each of which has a name.
Each step in the algorithm is either a function call that may refer
to any number, N>=1 of linear state values, referred to by their
declared names, in which case the macros enforces that the first N
return values from that function are correctly typed to be the new
values of those linear state values, with the rest being available
for binding to names; or a control flow syntax. The result of the
algorithm macro is a function that accepts the initial values of the
linear state values and returns the final values, perhaps with extra
return values appended. So the above would be more like:

(define someDialogue
  (algorithm (world)
    (print "Hi, what's your name?" world)
    (let (name) (input world))
    (print (string-append "Hello, " name) world)))

...but I need to experiment a bit to make sure it works properly.
Mainly with how the control flow is handled...

I'd like to implement this on terms of a FORTH-inspired VM, with
implementations of the VM that interpret it or go to native code.
Basing it on a FORTHy system means, among other things, that we get
the ability to do runtime compilation to native code if so desired:
"(lambda (a b c) x)", if x contains d, e, and f as free variables,
can just be a macro that expands to "(insert-free-variable-values-
into-closure (compile-closure-with-free-variables '(a b c) '(d e f)
'x) d e f)", if the compiler is smart enough to spot that the
(compile ...) is a constant subexpression and evaluate it at compile
time, even.

The compilation process onto my VM would, however, be very similar to
how Chicken works, even with a foreign-lambda type construct that
lets you write low-level FORTH opcodes or inline assembler (embedded
in FORTH) for things that must be speedy. I know I'm losing a lot by
not just doing what Chicken does and using GCC, but for various
reasons, I want to avoid GCC...

But I'm unlikely to have the time to build it for a couple of years
yet... So, I guess scheme will do for now ;-)

ABS

--
Alaric Snell-Pym
Work: http://www.snell-systems.co.uk/
Play: http://www.snell-pym.org.uk/alaric/
Blog: http://www.snell-pym.org.uk/?author=4