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

well, it's worth pointing out that

    5 [dup] first i
    5 [dup] i

both evaluate to 5 5 in XY because 'i' doesn't quite mean 
disquotation.  it means "take the top of the stack and 
prepend it to the head of the queue."  where Q is the queue
and S is the stack, the k code which implements this is
roughly:

    Q:(last S),Q
    S:-1_S

x,y is concatenation, x_y is drop from the head or tail.

suppose last S = dup, then Q = dup,Q.  suppose last S = [dup],
then Q = [dup],Q.  but Q is the same in both cases.  concatenation
of a unit list is the same as the concatenation of atom.

if i can remember what i was thinking at the time, it was 
something like this:  i want to be able to put naked functions
on the stack.  but i also want to be able to evaluate them
once they're there.  so reinterpret 'i' to mean 'move to the
queue'.



----- Original Message ----- 
From: "John Nowak" <[email protected]>
To: <[email protected]>
Sent: Thursday, February 26, 2009 3:08 PM
Subject: Re: [stack] function/object ambiguity + quotation alternative


> 
> On Feb 26, 2009, at 2:57 PM, Christopher Diggins wrote:
> 
>>>> the evaluator would not abide naked functions on the stack; it  
>>>> would apply repeatedly until that was not the case.
>>
>> Then you have a first order language. I don't really see what that
>> buys you. Why not allow functions on the stack?
> 
> I think you're misunderstanding what Stevan was saying. Stevan is not  
> suggesting anything that would eliminate quotations or make a language  
> first order.
> 
> Joy and XY have "open" quotations. You can modify them as if they were  
> lists. This causes two problems.
> 
> The first is that the language becomes non-extensional. For example,  
> say you know that 'a b == c d'. In Joy and XY, it does not follow that  
> '[a b] == [c d]' as it does in Cat.
> 
> The second problem is that, because you can take "things" out of a  
> quotation, you end up with weird problems. Factor has this problem too  
> with its array literals; or at least I'm pretty sure it does.
> 
> Take the program '5 [dup] first' for example. The result of this is '5  
> dup'. However, the 'dup' here is *not* a function the same way 'first'  
> was; it's a function object. Accordingly, the result of evaluation '5  
> [dup]' is a stack with two elements; the first is the value 5 and the  
> second is the value 'dup'.
> 
> What Stevan was suggesting was to evaluate "unquoted function objects"  
> like 'dup' in the example above. In this system '5 [dup] first' would  
> reduce to '5 dup', but then further reduce to '5 5' without the need  
> to explicitly re-quote 'dup' and call 'i'.
> 
>> It seems to me that higher-order languages are only a positive thing.
> 
> Certain forms of reasoning are a lot easier without higher order  
> functions. It's a tradeoff.
> 
> - John
>