Re: [stack] stackless fixed-arity concatenative languages

> It's important to remember that 'dup dip dip' works fine for our
> expected use case, but has some very strange behaviors lurking about!
> The new type system I'm working on does capture this by giving 'dup
> dip dip' the type '[$A] => $A [$A] dip'. Essentially, it types 'dup
> dip', realizes there's no most general way to proceed, and stops and
> waits for more information about $A (the quotation passed in).
> Unfortunately, this type system is undecidable, expensive, and yields
> ugly types. What fun!

On the other hand this looks like a turing-complete programming
language at the type level. Perhaps if you go that route, and not
worry about decidability, you will arrive at something interesting.

That Cat type issues you have identified are appreciated. They are
related to the inability to properly assign the correct level of
nesting of nested forall qualifiers, and to do renaming properly. This
is still something that I have on my to-do list, to try and improve.

Oh, and for the record, I still want variable arity functions in
concatenative langauges, where the arity depends on the arity of
function parameters. However, some of the Joy primitives have a little
too much flexibility with stack access: I don't want all of my list
processing functions to have access to the stack, because it seriously
impedes performance. What I am doing in Cat is making multiple
versions of the list processing functions (like Map and Fold): ones
that allows unfettered access to the stack (and thus is order
dependent) and others that don't.

- Christopher