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

i appreciate your forebearance.  i may have a useful analogy from
planet k.

consider

    2+3

we say that this expression is an nvn -- a noun-verb-noun -- which
is a proposition about the grammar of an expression.  

in the context of expressions like 2+3 "+" is a verb.  speaking
loosely, in the context of 2+3, "+" denotes the addition function,
although strictly speaking, it doesn't really denote anything.

now, when i assign a name to + as in:

    a:+

or pass + to a function as in:

    f[+;10]

then i say that + is a piece of data, and has the grammatical form
of a noun.  the verb has been "nominalized."

why a noun?  because to apply the function + i say:

    a . 10 20
  30

which is an nvn - a noun a, a verb ., and a noun 10 20.  a is clearly
not a verb, since i can't say

    2 a 3

so, i would say, when you claim that

    [dup] first != dup

you're equivocating between two contexts, one in which the function
is a piece of data on the stack (what you call a function object), and 
one in which "dup" a term in an expression.

in other words, this equivocation is leading you to reify a categorial
distinction between syntax and semantics as a semantic distinction between 
two kinds of objects, functions and function-objects.  this is similar to 
the predicament k programmers get themselves into by asking why they can't
say:

    a:+
    2 a 3

or

    + . 2 3

(in the first case, the grammar is nnn, in the second it's vvnn)

in XY it's very clear that what's on the stack after [dup]first is
evaluated, what's on the queue when dup is moved from the stack to
to the queue by i, and what's on the stack after the user enters
2 dup, is the very same object.  call it a function, call it a function-
object, call it a symbol - it doesn't really matter. 

apologies if this only adds to the confusion.

----- Original Message ----- 
From: "John Nowak" <[email protected]>
To: <[email protected]>
Sent: Friday, February 27, 2009 2:03 PM
Subject: Re: [stack] function/object ambiguity + quotation alternative


> 
> On Feb 27, 2009, at 1:46 PM, Stevan Apter wrote:
> 
>> i guess i don't see the problem here.  f, [f], [[f]], ...  seems
>> quite intuitive to me.
> 
> Last try. Please don't take the list format below as exasperation,  
> condescension, or anything of the like; I just want to convince you  
> I'm not nuts at this point:
> 
> 1. '[dup] first' returns the *function object* 'dup'.
> 2. '[dup] first != dup' because the 'dup' on the right is a *function*  
> and not a *function object* as it was in 1.
> 3. I want a notation to avoid this confusion.
> 4. I have proposed '[dup] first == `dup', where '`dup' is a *function*  
> that pushes the *function object* 'dup' onto the stack.
> 5. '`dup' must be a *function*, not a *function object*, because all  
> terms in a concatenative language denote functions; if they weren't  
> functions, you couldn't concatenate them to compose them.
> 
> - John
>