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.
>>> 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).

> It seems to me that the way to handle this is to simply require a
> normal type annotation that provides enough information to figure
> these things out.

I agree; for a language with static typechecking, this makes complete
sense. If you don't have static typechecking but you want to do static
stack depths, you have to check and annotate arities.

> Specifying arities directly seems like it would be too much of a pain.

Sure, if you also have to specify types it's a waste of time. If you
don't have types it's easier to add arities than it is to add types.

> I'm possibly just talking to myself at this point, but it seems like I
> should just give up on the idea of preserving cut-and-paste factoring
> in all cases, use a simpler yet highly expressive type system that
> occasionally requires annotations like Leijen's HMF or HML,

In some cases disallowing cut-and-paste is the right thing to do
(specifically, when the associative property doesn't hold due to side
effects)... Unfortunately, our type theory isn't sophisticated enough
to differentiate between those legitimate cases and other less
legitimate ones.

> drop macros (since we have no binding forms to deal with, we have a
> lightweight syntax for quotations, we don't build abstractions around
> things like SET!, postfix syntax is already quite good for DSLs, etc),

I suppose that makes sense. Perhaps macros can be a design goal... Or
perhaps they'll have to be a feature for Sixth.

> and just get on with writing an implementation already.

I got no complaints. I still haven't published my 'tworing' language.

> - John

-Wm