Re: [stack] syntax preference question

On Jun 16, 2008, at 4:55 PM, William Tanksley, Jr wrote:

> I _like_ Slava's code there.

Aye. A few times now I've asked him how he'd write something,  
typically after I'd already given it much thought, and the result has  
always been very impressive (and completed very quickly).

Anyway, regarding the syntax, I've settled on the c-expression  
approach (e.g. foo(a b, c d)) with nothing "special". We'll see how  
that goes for awhile. S-expressions just proved too painful, and to be  
realistic, I don't have nearly enough experience yet with a second  
order concatenative language like this to figure out which combining  
forms deserve special syntax.

> Keep in mind that these "cleave combinators" are not actually
> combinators in this little language... They're part of the language's
> syntax. As such, it might possibly _not_ be a bad idea to make them
> participate in the typesystem.

The problem is that a "type-directed" cleave combinator is just...  
weird. With a normal cleave, the expansion is straight-forward:

    cleave(a, b, c, d) == keep(a) keep(b) keep(c) d

And for '2cleave' which takes quotations that require two arguments:

    2cleave(a, b, c, d) == 2keep(a) 2keep(b) 2keep(c) d

You get the idea. With a type-directed cleave however, there's no way  
to give such a translation. This causes a real problem with type  
checking. Say I write this definition for a combining form:

    foo(a, b) = [a, b]

If cleave is type-directed, there's no way to give this a type. You'd  
need to require an annotation in such a case.

> By the way, are s-expressions the same as c-expressions, but with
> Scheme-like function positioning instead of C-like function
> positioning?

Unfortunately not; c-expressions are a bit more complicated. With s- 
expressions, you simply have lists that can contain atoms and other  
lists. With c-expressions, you have compositions (e.g. 'a b c d') that  
can contain atoms and lists (e.g. (e, f, g, h)) that can contain  
compositions. Lists can also be named. The syntax, very briefly, is  
something like this:

    composition ::= <atom> | <list>
           list ::= <optional_name>(<composition>, <composition>, ...)

This is more complex than the s-expression alternative:

           list ::= <atom> | list

I do think the extra complexity is worth it however, both in terms of  
brevity and clarity.

> (Frankly, I'm astounded to watch myself writing in favor of more  
> syntax.)

I feel the same way.

- John