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