Jack Waugh wrote:
> Are there any nillary words in Joy besides the literals?A few:
the implementation parameters maxint and setsize;
the state variables autoput, undeferror, and echo;
the environment enquiries stack, conts, clock, time, and rand;
the standard streams stdin, stdout, and stderr.
> 1. What are the other components of the state besides the stack?The file streams that are open, plus the values of the various operands
mentioned above.
> 2. Please simplify:No, it's 1 2 2. The behavior of the N-ary combinators is:
>
> 1 2 [swap swap] nullary
>
> I guess the answer is
>
> 1 2 1 2
1. Pop the quotation and save it.
2. Save the stack.
3. Execute the quotation.
4. Save the top stack entry (not the top k stack entries where k
has something to do with the quotation, as you seem to assume).
5. Restore the saved stack.
6. Pop N stack entries.
7. Push the saved entry on the stack.
So the effect of [swap swap] nullary, or [id] nullary, or [] nullary,
is to grab the top entry and push a copy of it on the stack.
There was a bug in the implementation, however; the top entry was
not being properly saved, but was being illegally mutated to
point to the right part of the stack. As a result, 1 2 [id] nullary
tied the stack in a knot: its value was 2 2 2 2 2 2 2 2 ....
The fixed version is at the usual place:
http://www.ccil.org/~cowan/joy.tar.gz
I also fixed another bug: the N-ary combinators were not verifying
that the topmost argument was a quotation, and dumped core if it was
not.
--
There is / one art || John Cowan <jcowan@...>
no more / no less || http://www.reutershealth.com
to do / all things || http://www.ccil.org/~cowan
with art- / lessness \\ -- Piet Hein
Hello Jack,
I usually lurk and just listen intently, but this (and the replies to
it) interested me.
>One could also propose JOOy, or Joy 1 +, by extending Joy's primitiveThis intrigues me because I have a language project on the
>data types to include an "object" type. A further extension would
>give a functional meaning to all possible words, over the domain of
>states where the stack has an "object" on top. Objects would contain
>mappings of words to functions. Applying a word to a state would
>mean popping the object from the top of the stack, looking up in the
>object the function to which the word maps, and applying that
>function to a state having the remaining stack (resulting from having
>popped off the object) and with the rest of the state being the same
>as the nonstack part of the original state. There would have to be
>means of literally specifying and/or constructing an object. Hmm, it
>would be necessary to decide what happens when a word occurs that has
>a primitive nillary meaning -- should it get its primitive
>interpretation, or should it be "sent" to any object on the stack?
>Are there any nillary words in Joy besides the literals? The
>interpretation of the literals should be obvious -- always the
>primitive meaning. Anyway it's a moot question unless someone thinks
>a JOOy would be worth using. (Another way to go is to say that a
>word consisting of an underline concatenated in front of a Joy
>function name has the meaning that that name has in Joy, but all
>words that don't begin with the underline get the OO treatment. Non-
>objects treated as objects would effectively add the underline.)
back-burner to do effectively this. It turns out that this language
will show up as a feature sub-set of what I am currently working on.
Anyway, if someone were to work out the details, particularly using
monads or co-monads or dyads, whichever is appropriate to Joy (er...
concatenative language) rewrite semantics requirements, I would love
to participate.
Incidentally, although Joy has no state, one can pass around values
in a purely functional language, and Haskell's monads *do* seem like
an effectively functional way to pass around the state. The downside
is the extra creation of types to handle this. Has anyone considered
a similar possibility for Joy? Keep in mind I am not fluent in Joy's
libraries, so I'm not sure how it would fit in.
>As soon as someone comes along and praises the elegance of yourI experience that all the time, when designing toy languages.
>language, he up and suggests ways to make it less elegant, eh?
Thanks for the interesting post.
~
[Non-text portions of this message have been removed]