Re: [stack] function/object ambiguity + quotation alternative

John Nowak <[email protected]>
Newsgroups gmane.comp.lang.concatenative
Message-ID <[email protected]>
On Feb 27, 2009, at 11:52 AM, William Tanksley wrote:

> John Nowak wrote:
>
>> More the other way around. I think it's important to treat the object
>> [dup] and the object dup differently.
>
> Why? In what way are they different?

I'll be using Joy for all of these examples.

dup and [dup] are not the same object. I'd hope you'd agree that this  
holds:

    [dup]  !=  [dup] first

If the above functions produced the same object, then this would be  
true:

    [dup] first  ==  [dup] first first

And obviously it is not; the right side will cause an error.

> Is there any function that should return a different result when  
> called on one than another?

Sure. Calling 'quote' on the object dup should yield the object [dup].  
Calling it on the object [dup] should yield the object [[dup]]. I'm  
sure you'd agree that [dup] and [[dup]] are not the same object, and  
hence it follows that dup and [dup] are not the same object.

The whole problem is that, in my opinion, "open" quotations suck. For  
example, this rule always holds true in Cat:

    quote i == id  (note: Cat renames 'i' to 'apply')

However, this does not hold in Joy. Here's an example of why taken  
straight from the Joy REPL (where 'quote' is defined as '[] cons'):

    5 [dup] first stack .
    [dup 5]

    5 [dup] first quote i stack .
    [5 5]

If you were to disallow open quotations, the 'quote i == id' rule  
would hold in Joy.

That's not really the main reason open quotations suck; the real  
problems are:

1. You can no longer factor code indiscriminately.
2. You have these ugly naked function objects to deal with!

Forgive me for continuing to make this same point. It is the cause of  
this naked function dilemma however, so I can't really avoid  
mentioning it.

- John
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.