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

at this point i'd just like to reflect on the cost one pays
for designing a language which tries to (i'm not sure how to
say this) maximize refactorability.  i'm tempted to say that
such a language will send the programmer down a path where
refactoring is more often required, even in cases where the
necessary changes are trivial.  this is probably not a good
thing.  to give the first reason that occurs to me:  refactoring
(and i've done a fair bit of it in developing examples for 
the various concatenative languages i've written over the 
years) seems to me to be inherently error-prone, more so than
adding new arguments to functions or modifying what they 
return.  now it may be that most of the problems i've encountered
in refactoring exercises are due to the fact that my languages
use "open quotation," but if so, that isn't immediately obvious
to me.

----- Original Message ----- 
From: "Stevan Apter" <[email protected]>
To: <[email protected]>
Sent: Friday, February 27, 2009 1:46 PM
Subject: 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
>> 
>> 
>>
>