[Rd] Assignment to string

[Wacek Kusnierczyk]

Stavros Macrakis wrote:
> On Wed, Apr 1, 2009 at 5:11 PM, Wacek Kusnierczyk <
> Waclaw.Marcin.Kusnierczyk at idi.ntnu.no> wrote:
>
>   
>> Stavros Macrakis wrote:
>> ...
>> i think this concords with the documentation in the sense that in an
>> assignment a string can work as a name.  note that
>>
>>    `foo bar` = 1
>>    is.name(`foo`)
>>    # FALSE
>>
>> the issue is different here in that in is.name("foo") "foo" evaluates to
>> a string (it works as a string literal), while in is.name(`foo`) `foo`
>> evaluates to the value of the variable named 'foo' (with the quotes
>> *not* belonging to the name).
>>
>>     
>
> Wacek, surely you are joking here.  The object written `foo` (a name)
> *evaluates to* its value.  

yes, which is the value of a variable named 'foo' (quotes not included
in the name), or with other words, the value of the variable foo.

> The object written "foo" (a string) evaluates to
> itself.  This has nothing to do with the case at hand, since the left-hand
> side of an assignment statement is not evaluated in the normal way.
>   

yes.  i did support your point that the documentation is confusing wrt.

    "foo" = 1

because "foo" is not a name (and in particular, not a quoted name).


>
>   
>> ...with only a quick look at the sources (src/main/envir.c:1511), i guess
>> the first element to an assignment operator (i mean the left-assignment
>> operators) is converted to a name
>>     
>
>
> Yes, clearly when the LHS of an assignment is a string it is being coerced
> to a name.  I was simply pointing out that that is not consistent with the
> documentation, which requires a name on the LHS.
>   

... but there is probably something going on in do_set (in
src/main/eval.c) before do_assign is called.

> - maclisp was designed by computer scientists in a research project,
>   
>> - r is being implemented by statisticians for practical purposes.
>>
>>     
>
> Well, I think it is overstating things to say that Maclisp was designed at
> all.  Maclisp grew out of PDP-6 Lisp, with new features being added
> regularly. Maclisp itself wasn't a research project -- 

didn't say that;  it was, as far as i know (and that's little) developed
as part, or in support of, the MIT research project MAC.


> there are vanishingly
> few papers about it in the academic literature, unlike contemporary research
> languages like Planner, EL/1, CLU, etc. In fact, there are many parallels
> with R -- it was in some sense a service project supporting AI and symbolic
> algebra research, with ad hoc features (a.k.a. hacks) 

that's a parallel to r, i guess?

> being added regularly
> to support some new idea in AI or algebra.  To circle back to the current
> discussion, Maclisp didn't even have strings as a data type until the
> mid-70's -- before that, atoms ('symbols' in more modern terminology) were
> the only way to represent strings. (And that lived on in Maxima for many
> decades...)  See http://www.softwarepreservation.org/projects/LISP/ for
> documentation on the history of many different Lisps.
>   

interesting, thanks.

> We learned many lessons with Maclisp.  Well, actually two different sets of
> lessons were learned by two different communities.  The Scheme community
> learned the importance of minimalist, clean, principled design.  

and scheme is claimed to be the inspiration for r...

> The Common
> Lisp community learned the importance of large, well-designed libraries.
> Both learned the importance of standardization and clear specification.
> There is much to learn.
>   
yes...

best,
vQ