headers
John Nowak | 13 Feb 2012 22:23
Gravatar

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

 

On 02/13/2012 03:20 PM, 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. 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 <at> ' in a previous
email. I meant 'bi'.)

Even without types, this is possible if you have 'infra' to run a
function on a stack-on-the-stack and some sort of 'concat'
operation to join a stack-on-the-stack onto the main stack
itself. Assuming curly braces denote stacks, we need only the
following primitives:

{A} [B] infra == {A B}
A {B} concat == A B
{A} B push == {A B}

This is enough to write a "safe" 'bi':

bi = [keep] dip [{} swap push] dip infra concat

With this version of 'bi', you'll get a stack underflow error if
the second quotation to 'bi' attempts to use more than one
element. Since we're not using types, you might as well pass an
argument to some generic version of 'bi' that says how many
arguments to reserve for the second function; just push that
many onto the stack before calling 'infra'.

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

- jn

__._,_.___
Recent Activity:
    .

    __,_._,___
    Permalink | Reply |
    headers
    John Nowak | 13 Feb 2012 22:25
    Gravatar

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

     

    On 02/13/2012 04:23 PM, John Nowak wrote:

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

    Existed. Sorry.

    - jn

    __._,_.___
    Recent Activity:
      .

      __,_._,___
      Permalink | Reply |
      headers
      William Tanksley, Jr | 13 Feb 2012 23:05
      Picon

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

       

      John Nowak <john <at> johnnowak.com> 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 <at> ' 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

      __._,_.___
      Recent Activity:
        .

        __,_._,___
        Permalink | Reply |

        Gmane