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@...)
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 <bkerby@...> wrote:
> Hello folks...[snip]
>
> 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 ...
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
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 wasActually, I think this is the right way to go for Forth. Joy is fine the
>thinking that
>program quotations could be unified with text strings (so no
>more need for ""s). Sound cheap? maybe. just a thought ...
way it is, of course, but there's little reason to store a concatenative
program as anything but a string.
>- Brent Kerby-Billy
--- In concatenative@y..., Brent L Kerby <bkerby@e...> wrote:
> [...]all be
> The notion of variables, system dictionary, and return stack can
> 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 wasthinking that
> program quotations could be unified with text strings (so no moreneed for
> ""s). Sound cheap? maybe. just a thought ...There are some problems with this approach:
>
> [Hello world] put
>
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...)