Re: [stack] sweetening concatenative syntax

Don Groves <[email protected]>
Newsgroups gmane.comp.lang.concatenative
Message-ID <[email protected]>
On Mar 8, 2008, at 19:14 , William Tanksley, Jr wrote:

> John Nowak <[email protected]> wrote:
>>  William Tanksley, Jr wrote:
>>> John Nowak <[email protected]> wrote:
>>>> William Tanksley, Jr wrote:
>>>>> 'f' is referred to twice; that's nonlinear.
>
>>>> Keep in mind that the pointful version gets translated to pointfree
>>>> code. It's just syntactic sugar.
>
>>> We're comparing lambda notation to pure concatenative notation. Your
>>> claim is that lambda notation is "objectively" superior.
>
>>  My claim was that it was superior for a particular case, to be  
>> clear.
>>  I certainly don't believe this is true in the general case.
>
> I didn't notice that claim; if I had I wouldn't have responded. I
> agree that there are situations and needs for which lambdas are better
> than stack shuffles. I don't think this is one.
>
>>> You can't have it both ways, using lambda notation to make something
>>> look good (subjectively) and then converting it to a concatenative
>>> notation to make it meet some objectively measurable property.
>
>>  I don't understand. It seems I can indeed have it both ways. Isn't
>>  converting a language to a simpler language what compilers do all  
>> the
>>  time? Maybe I'm misunderstanding.
>
> But you can't measure the readability of a language NOTATION in
> comparison to a different notation by converting the first one into
> the second. By that standard Brainf**k and Haskell have the same
> readability (they can both be converted to x86 machine code).
>
>>> It's objectively true that lambda notation freely allows nonlinear
>>> references.
>
>>  This is incorrect. "Linear" means that *values* have at most one
>>  reference to them. It has nothing to do really with how often a  
>> given
>>  variable shows up the source code. Take a look at Henry Baker's  
>> Linear
>>  Lisp. It certainly has lambdas, but it is also certainly linear.  
>> There
>>  are also languages like Clean that enforce linearity through the  
>> type
>>  system.
>
> I'm trying to find where linear lisp or Clean's uniqueness types allow
> multiple uses of the same variable. I'm not finding that; it appears
> to me that the opposite of what you claim is true: those languages
> claim to be linear BECAUSE they enforce only one use of each variable.
>
> What am I missing?


My understanding of linearity is that a value have only a single  
reference
at any one instant. So, for example, if a value is pushed on the stack,
it may not be held anywhere else simultaneously as it is now referenced
by the stack. This seems to rule out the possibility of pushing a  
variable's
value onto the stack, then doing it again later from the same variable.

Unless I'm missing something...
--
don



>> Likewise, you can have non-linear languages that do not have
>>  variables. Look at Joy for example.
>
> Joy appears to be linear. What am I missing?
>
>>> It's also true that this can be optimized away, but it's
>>> NOT clear how expensive that will be (the expense is always up-front
>>> with a concatenative notation, which is sometimes uncomfortable but
>>> always clear).
>
>>  There actually are clear rules for determining how many times  
>> copying
>>  will be necessary when using lambda expressions. The rule is that a
>>  variable will be copied N-1 times where N is the number of times  
>> it is
>>  used. There is only one exception to this rule: Uses in separate
>>  functions "directly applied" to a sum deconstructor (unlist, if,  
>> etc)
>>  do not require copying. The implementation may choose to eliminate
>>  additional copies if possible as well, just as it may do when you
>>  write code in a purely pointfree form, but that's besides the point.
>>  One of my requirements for introducing lambdas is that there be very
>>  clear rules for when copying will occur, so you can be sure this  
>> will
>>  be formally specified, simple, and not implementation-dependent.
>
> I think that would be excellent. Objectively so :-).
>
>>  - John
>
> -Wm
>
>
>
> Yahoo! Groups Links
>
>
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.