Re: [CORRECTION] lua_concat right-associates! (Was: lua_concat left-associates: bug or feature?

[Jay Carlson <nop@...>]

(Dirk may note with some satisfaction I think I managed to confuse myself too.)

On Dec 9, 2012, at 5:44 PM, Andres Perera wrote:

> On Sun, Dec 9, 2012 at 3:34 PM, Jay Carlson <nop@nop.com> wrote:
>> 
>> I can't remember which Scheme (Dylan?) proposal had a deterministic but
>> pointedly unintuitive order, something like:
>> 
>>  1. Even-numbered arguments are evaluated left-to-right;
>>  2. The function expression ("0th arg") is evaluated.
> 
> Presumably car isn't a macro? Or a fexpr in lisp-jabroni?

Fexprs? Are those like http://en.wikipedia.org/wiki/Luminiferous_aether , or more like http://en.wikipedia.org/wiki/Ultraviolet_catastrophe ?

This might be a generational thing. Serious Lisp implementations were expensive or just not available on hardware I could conceivably use. By the time I took Lisp seriously, R4RS was out and Scheme had distilled decades of irregular, path-dependent trivia into thirty crystalline pages, available via anonymous ftp rather than expensive technical bookstore. Kent Pitman doesn't need the egoboo, but I grew up in a world where fexprs had been discarded--and "of course" car was just a function.

> However, would I care about the order of
> evaluation for a commutative operator, coming from the same naive
> mindset? I wouldn't be on a position to make assessments about what's
> pure and what's not; realistically speaking, I wouldn't be familiar
> with the subject! So I can say, `..` and `+` are commutative, why do I
> care about the order *anyway*

Aha, we're back to Lua. Since numbers are floating point[1], they are commutative but not associative. So if we have:

    a() + b() + c()

it really does make a difference whether this is grouped as (a() + b())+c() or a()+(b() + c()). That's what we get out of left-associative or right-associative grammar rules. In Scheme we could write (+ (a) (b) (c)) and because + is not a special form, the documentation of + would say what order the *addition operations* were performed in, but the language itself would pick which functions to evaluate first.

> Once I understand side effects, my posturing becomes disingenuous. :)

It's an interesting issue and it confused me too. lua_concat is like the Scheme + function I described, but ".." is not.

   -- Perhaps it is not defined which order these occur in?
   local addend1 = a()
   local addend2 = b()
   local addend3 = c()

    -- But it is defined which of these it parses to.
    return (addend1+addend2)+addend3
    -- not return addend1+(addend2+addend3)

But wait, there is obviously a causal ordering on evaluation if these were regular functions:

      return plus( plus(a(),b()), c() )

I agree it would be perverse to allow evaluation of addend3 to raise an error before both addend1 and addend2 were evaluated. (Standard C is perverse?) What can remain undefined in Lua is whether addend1 was calculated before addend2.

Jay

[1]: Yes yes, numbers are *usually* floating point, I'm aware.