Re: [stack] stackless fixed-arity concatenative languages

John Nowak <[email protected]> wrote:
> William Tanksley, Jr wrote:
>> At this point, it would seem convenient to add some syntax for
>> staticly-known (and required) parameters. Perhaps (i 4 4) would be an
>> example of such syntax.

> That's certainly possible. I already have that syntax for special
> forms anyway. It might be nice to not require the numbers to be given
> when the effect is inferable though. For example, I often do things
> like '[+] dip', and it would be rather annoying to have to do '[+]
> (dip 2 1)' instead.

Agreed; this should tie in with type inference and annotation. This
stack effect notation is really an abbreviated form of type notation
and static polymorphism / function overloading, so perhaps it should
be clearly annotated as such (rather than simply looking like a macro,
as I suggested).

> Once you start inferring that sort of thing though, you have a
> situation (again) where you can't split definitions cleanly because
> there might not be enough information to infer stack effects. Perhaps
> instead, you could have a 'dip-with' form that takes a quotation
> directly. You could then do something like '(dip-with +)'. This way,
> it is at least clear that you can't split between '+' and 'dip-with'.

For that to work consistently, the type system would have to produce
an error whenever annotation was missing, even if the inference could
theoretically be made.

> In any case, it should be possible to figure out some nice way of
> doing all this.

Perhaps :-).

>>> Does anyone think such a language would be feasible? What might the
>>> benefits be? What useful features would be lost?

>> Well, you'd also need to remove Joy's stack-preservation semantics. As
>> long as that's present, you simply have to implement a stack, no way
>> around it.

> It's important
> to be able to remove assertions from a program without changing the
> program's meaning, and preserving the stack takes care of that.
> However, a fixed arity restriction does that as well, as it is known
> at compile time how many elements of the stack need to be saved and
> restored for the call to assert. Since we're not longer dealing with a
> stack though, you just call assertion with the arguments it needs and
> ignore the result. Very easy.

Yes, it seems like fixing the arity is the correct action (really, you
don't ignore the result; you make sure the result is always 'true').

> - John

-Wm