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

----- Original Message ----- 
From: "William Tanksley" <[email protected]>
To: <[email protected]>
Sent: Friday, February 27, 2009 1:29 PM
Subject: Re: [stack] function/object ambiguity + quotation alternative


> John Nowak wrote:
>> 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.
> 
>> The whole problem is that, in my opinion, "open" quotations suck. For  
>> example, this rule always holds true in Cat:
> 
> So you want to treat them differently because treating them differently
> sucks? :-)
> 
> Yes, I agree that open quotations are a problem. If you don't have them,
> [dup] and `dup are equivalent by any test.
> 
>> That's not really the main reason open quotations suck; the real  
>> problems are:
>> 1. You can no longer factor code indiscriminately.

i don't want to spoil the party, but the fact is, i'm rarely in
the position where i *want* to factor my code.  my building blocks
are not words or code-fragments, they're *functions*.  typically,
a function evolves over time in response to demands from the
environment by acquiring new arguments and/or producing results
with new components.  the large-scale "topography" of the system
is relatively stable.  (come to think of it, this is a pretty 
good metaphor for how systems grow in the real world.)  if i have
to dig into the functions and move snippets of code around into
a new functional architecture, then my original design was pitched
at the wrong "level."  the kind of refactoring i want to avoid
(because it is the most painful kind) is *renaming*.  going from
a set of several hundred functions a,b,c,... to a different set
x,y,z,... .  code is committed to a function with a name when 
a judgement is made that that functionality will endure for the
lifetime of the system, and that changes will for the most part
be extensions rather than revisions.

>> 2. You have these ugly naked function objects to deal with!

i guess i don't see the problem here.  f, [f], [[f]], ...  seems
quite intuitive to me.

> 
> Quotations, whether open or closed, ARE "naked function objects".
> 
>> - John
> 
> -Wm
> 
> 
>