Stavros Macrakis wrote:
> On Wed, Apr 1, 2009 at 5:11 PM, Wacek Kusnierczyk <
> waclaw.marcin.kusnierc...@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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
