Re: [stack] Jon Purdy: Why Concatenative Programming Matters

John Nowak <[email protected]> wrote:
> William Tanksley, Jr wrote:
>  > You're right that any arbitrary function must be able to access
>  > all of the state; but it need not be true that any specific
>  > function must be able to access all the state. Modern
>  > concatenative languages use typechecking to make sure that no
>  > function attempts to consume stack state that doesn't match the
>  > function's declaration;

> This is certainly true; or at least it would be if the languages
> actually excited.

Fair point. (I misread this word as "exited", and thought you were
talking about termination proofs. Yow.)

> With types, something like 'bi' can be
> restricted so that the second function uses no more than one
> element and thus you can consider both functions independently.
> (For the record, I mistakenly referred to 'bi@' in a previous
> email. I meant 'bi'.)

Well, you can also copy the needed elements into place -- type
checking can handle the rest. That way you can provide every branch
with the data it needs according to the documented semantics of the
forking word (whether each branch sees the same stack, or the branches
see sequential data from the initial stack).

And you're right that the easy way is to use "infra"... Much less
infrastructure.

>  > Were you the one who designed a concatenative language with
>  > side-effect checking?)
> Yes, although it is just a little trick of attaching a variable
> to function types that can either be "effectful" or "not
> effectful". You can infer it via unification. Not much to it.
> It's a bit coarse though because it doesn't offer any form of
> local effects with a pure interface as you can get with the ST
> monad or with linear or uniqueness types (though they could be
> added if you wanted).

Ah, I see. Yes, I was thinking more of defining structures on which
effects could occur, and checking those effects.

Forth has a dictionary on which effects can occur, for example.

> - jn

-Wm