Re: [stack] Define statements

On 22/8/06 5:19 AM, "John Cowan" <cowan <at> ccil.org> wrote:

>  
>  
>  
> 
> Manfred Von Thun scripsit:
> 
>> > The argument starts with a hashtable somewhere on the stack, and ends with
a
>> > bare single value somewhere on the stack. That bare single value  might be
>> > just a number, say 5, on top of the stack. We can change it with an
>> operator
>> > (by doing taking its square, say) , thus updating what is on top of the
>> > stack. That's just purely functional concatenative programming without a
>> > separate state. So a bare single value does not add state. If there is a
>> > flaw in my argument, it must be in one of the earlier (conditional)
>> > premises.
> 
> 0The flaw is that a hashtable cannot be reduced to a single unboxed value on
> the stack; at best it can be reduced to a pointer to a boxed and mutable
> value.  Currently all the things that can be pushed on the stack are
> immutable, being either atomic values or immutable lists (no set-car! or
> set-cdr! operations in Joy).

First, let me make it clear that I was not arguing against implementing
hashtables 
somewhere on the stack. Such facility would make a lot of programming in Joy
much
easier and clearer.

Ignoring get and put and other file manipulations, Joy programs compute
functions 
from stacks to stacks. The programs can change the stack in its entirety.
But the
changes are not like assignment  or set-car! or set-cdr!, as you rightly
observe,
so Joy is purely functional., and not procedural.

My argument had the conclusion: adding hashtable(s) somewhere on the stack
does not destroy the purely functional nature of Joy. The first step was
this:
hashtables are an efficient way to implement name/value associations, but
the efficiency is just a welcome bonus. Another way to implement such
associations is by a  crude list of pairs, such as
    [ [year 2006] [pi 3.16] [greeting ³hello my friend²] ...]
Anything hashtables can do can be done by such lists of association pairs,
initialisation, lookup, redefinition (!),  undefine ...
Of some interest might be redefinition:
assuming the list  has been taken to the top of the stack, here is how you
change the value of pi:
    uncons unswons uncons pop [3.14] cons swons uncons
alternatively, you might use a search to find the pair that starts with pi
and then change to 3.14.

Since  hashtables and lists of pairs differ only in their efficiency, not in
their
semantics, I maintain:

The first conditional:
    if adding hashtables somewhere on the stack makes Joy procedural,
    then adding lists of association pairs on the stack makes Joy
procedural.

Are we at least agreed on this conditional?

I am a little puzzled by what you meant by ³reduced² here ­ I was only
concerned with the question whether hashtables change the nature of Joy.

But thanks for the comment, John. I have finally been thrown off
the old mainframe (they had to kill it to get me off, screaming loud
protests). Now somebody here is going to implant gcc into this
dreadful eMac that I have been condemned to use, for sins that
I must have committed. I still dread the entire transplant, and fear
the worst. But one day I shall be ready to try out your Scheme
implementation of Joy. In the meantime I wish you luck with it.

As I mentioned some time ago, I have sold my house and emptied
it of more than 3 decades of accumulated junk, and that has kept
me rather busy. I hope to be around uni a bit more.

Best wishes to all

  - Manfred

[Non-text portions of this message have been removed]

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/concatenative/

<*> To unsubscribe from this group, send an email to:
    concatenative-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/