# Unifying variables, dictionary, return stack

## Brent L Kerby — 2001-10-16 17:30:43

    Hello folks...

    I haven't posted anything for a while because my internet has been

    a bit weird, having trouble connecting with my TUNES email account. But

    I've been watching the discussion still via the web. You guys are great;

    it is nice to know that people are still interested in Joy.

    Well, there's some ideas that have been floating through my head that

    last while that I'd like to share. I've been wanting to make a little

    operating system based on Joy ideas ...

    What I was thinking is that, in a complex system, it is going to be expedient

    to have the ability to use variables of some kind, or else a return stack,

    as in FORTH (some sort of thing to make the stack manageable in difficult

    situations). What I realized is that variables could be added to Joy without

    adding complexity to the system, because:

      The notion of variables, system dictionary, and return stack can all be

      unified.

    How is this possible? Well, normally a variable is thought of as a named

    slot holding a value; but instead, try thinking of it holding a stack of

    values. The purpose of this is for scoping, so that if some subprogram uses

    the same name for a variable, it will not interfere, because the variable

    is a stack. Now, if we have variables, then a system dictionary is not really

    necessary, because a definition in the dictionary can just be thought of

    as a variable holding a program (and then, we define the act of naming

    a variable to run the program that is in it).

    Here's a suggestion for notation using this system:

      x    (run the program that is on the top of variable x)

      x/   (push a value from the main stack onto x)

      x\   (pop a value from x onto the main stack)

      x<   (read a value from x onto the main stack)

      x>   (write a value to x from the main stack)

    And then, we might conveniently allow there to be the blank variable "" which

    would act as a return stack (sort of), so that you could use just plain

    "/" and "\" to push and pop things off the return stack.

    Well, that's the idea. What do you all think about it?

    I may add one more thought ... technically, a definition could be made like

    this:

      [definition body here] foo/

    But for convenience I was thinking of using sugar, so that you could do this:

    foo: definition body here

         possibly multiple lines

    bar: another definition

    And then, a blank line would be used to end a definition, if you wanted to

    do immediate instructions.

    One final thought (this one is a little more bizarre). I was thinking that

    program quotations could be unified with text strings (so no more need for

    ""s). Sound cheap? maybe. just a thought ...

      [Hello world] put

    - Brent Kerby

    (bkerby@...)

## Brent L Kerby — 2001-10-16 17:30:26

    Hello folks...

    I haven't posted anything for a while because my internet has been

    a bit weird, having trouble connecting with my TUNES email account. But

    I've been watching the discussion still via the web. You guys are great;

    it is nice to know that people are still interested in Joy.

    Well, there's some ideas that have been floating through my head that

    last while that I'd like to share. I've been wanting to make a little

    operating system based on Joy ideas ...

    What I was thinking is that, in a complex system, it is going to be expedient

    to have the ability to use variables of some kind, or else a return stack,

    as in FORTH (some sort of thing to make the stack manageable in difficult

    situations). What I realized is that variables could be added to Joy without

    adding complexity to the system, because:

      The notion of variables, system dictionary, and return stack can all be

      unified.

    How is this possible? Well, normally a variable is thought of as a named

    slot holding a value; but instead, try thinking of it holding a stack of

    values. The purpose of this is for scoping, so that if some subprogram uses

    the same name for a variable, it will not interfere, because the variable

    is a stack. Now, if we have variables, then a system dictionary is not really

    necessary, because a definition in the dictionary can just be thought of

    as a variable holding a program (and then, we define the act of naming

    a variable to run the program that is in it).

    Here's a suggestion for notation using this system:

      x    (run the program that is on the top of variable x)

      x/   (push a value from the main stack onto x)

      x\   (pop a value from x onto the main stack)

      x<   (read a value from x onto the main stack)

      x>   (write a value to x from the main stack)

    And then, we might conveniently allow there to be the blank variable "" which

    would act as a return stack (sort of), so that you could use just plain

    "/" and "\" to push and pop things off the return stack.

    Well, that's the idea. What do you all think about it?

    I may add one more thought ... technically, a definition could be made like

    this:

      [definition body here] foo/

    But for convenience I was thinking of using sugar, so that you could do this:

    foo: definition body here

         possibly multiple lines

    bar: another definition

    And then, a blank line would be used to end a definition, if you wanted to

    do immediate instructions.

    One final thought (this one is a little more bizarre). I was thinking that

    program quotations could be unified with text strings (so no more need for

    ""s). Sound cheap? maybe. just a thought ...

      [Hello world] put

    - Brent Kerby

    (bkerby@...)

## Ocie Mitchell — 2001-10-16 18:06:14

    --- Brent L Kerby <bkerby@...> wrote:

     > Hello folks...

    >

    > I haven't posted anything for a while because my

    > internet has been

    > a bit weird, having trouble connecting with my TUNES

    > email account. But

    > I've been watching the discussion still via the web.

    > You guys are great;

    > it is nice to know that people are still interested

    > in Joy.

    >

    > Well, there's some ideas that have been floating

    > through my head that

    > last while that I'd like to share. I've been wanting

    > to make a little

    > operating system based on Joy ideas ...

     [snip]

    Interesting ideas.  I was going over some exercises

    from an AI class I took a while back and ran into a

    bit of a problem.  What I wanted to do was come up

    with a generalized search function that would take an

    initial state, a state-generating quotation and a

    termination quotation.  It would use the

    state-generator to figure out which states can be

    reached from the current state, and the termination

    state to figure out if a desired element has been

    found.

    I didn't want to place any restrictions on the state

    generator, and I want this to be an exhaustive search,

    so the search function needs to keep track of which

    states have already been visited.  I would normally do

    this with a hash, but Joy doesn't really have this

    facility.

    I was thinking about a hash type:

    hash : pushes a new hash object onto the stack

    H I hashkey : returns true iff hash H has key I

    H I hashget : retrieves value associated with key I

    H I V hashstore : stores value V in hash H with key I

    H I hashdel : deletes key I from hash H

    H hashkeys : creates a list of the keys of H

    Has anyone tried do do something like this?

    Ocie

    __________________________________________________

    Do You Yahoo!?

    Make a great connection at Yahoo! Personals.

    http://personals.yahoo.com

## Billy Tanksley — 2001-10-16 18:16:30

    From: Brent L Kerby [mailto:bkerby@...]

     >Well, that's the idea. What do you all think about it?

     That's the semantics of Forth, although Forth does it without the complex

    syntax (which I'm not saying is a bad thing).

    The Forth dictionary is kind of like a linked list; you can define new

    instances of the same word, and that acts similarly to pushing a new value

    onto a variable-stack.

    Although in Forth, words defined after a given definition has been pushed

    have an implicit, assumed dependancy on the new definition -- the only way

    in Forth to remove that definition is to also remove all the definitions

    which chronologically follow it.

     >One final thought (this one is a little more bizarre). I was

    >thinking that

    >program quotations could be unified with text strings (so no

    >more need for ""s). Sound cheap? maybe. just a thought ...

     Actually, I think this is the right way to go for Forth.  Joy is fine the

    way it is, of course, but there's little reason to store a concatenative

    program as anything but a string.

     >- Brent Kerby

     -Billy

## dmitry_n_petrov@yahoo.com — 2001-10-17 07:00:29

    --- In concatenative@y..., Brent L Kerby <bkerby@e...> wrote:

     > [...]

    >   The notion of variables, system dictionary, and return stack can

     all be

     >   unified.

    > [...]

     This leads to some kond of "multy-stack automaton programming", and

    sounds quite good (imho). Maybe, some "dynamic" features are better to

    be removed for a compiled version.

    If "pop from stack X to main stack" is a separate operation, where X

    is an argument, it may cause some trouubles with type-checking; I will

    think more about this later.

     > One final thought (this one is a little more bizarre). I was

     thinking that

     > program quotations could be unified with text strings (so no more

     need for

     > ""s). Sound cheap? maybe. just a thought ...

    >

    >   [Hello world] put

    >

     There are some problems with this approach:

    1.) Some characters are likely to be ignored by lexer (spaces,

    tabs...): a group of such characters can be treated as a one single

    "delimiter". [a <space> <space> b] in this case is equal to [a <space>

    b].

    2.) How must one understand

    [abc] uncons

    - as an operation applied to a string or to a list of 1 element?

    3.) This feature can allow one to treat programs as strings,

    dynamically created, modified, interpreted. It is not a good feature

    for a compiled language. If one uses an interpreter, it is not good,

    either, beacause it makes possible some very dirty programs, which

    tend to loose the readability of "pure" applicational languages. It is

    better to use higher-level tools (combinators) to manipulate programs

    as data.

     > - Brent Kerby

    > (bkerby@e...)