Re: [Rd] assign(FALSE, TRUE)
PD == Peter Dalgaard [EMAIL PROTECTED]
on Tue, 18 Nov 2008 15:07:04 +0100 writes:
PD Martin Maechler wrote:
PD == Peter Dalgaard [EMAIL PROTECTED] on
Tue, 18 Nov 2008 00:00:40 +0100 writes:
PD Martin Maechler wrote:
But in spite of all that I agree that I'd have liked
`FALSE` - whatever to signal an error about the
fact that it is a reserved word.
RT This is clearly not a very important issue, but it might
RT bear some thinking about.
Yes. I'd propose that R-core look into how to make
assignment to a reserved word an error.
PD I disagree. In a sense, this is the point of having the
PD backtick operator: allowing you to work with names that
PD would otherwise be syntax errors (notice that such names
PD are sometimes created outside your control, e.g. via
PD column names in data frames). If you start disallowing
PD some of them again, well, that way lies madness!
No, no. I'm not against allowing names that are otherwise
syntax errors. They were always possible via assign().
I just am convinced we should not allow reserved words.
PD Please unconvince yourself then... You are solving a
PD problem that isn't there: In R, you can assign to
PD `FALSE` and access it as `FALSE`. You can not access it
PD as FALSE because that is a keyword and you cannot assign
PD to FALSE either.
I now have been unconvinced,
((so the following is just some clarification ...))
but notably not mainly by the above. I'd consider the backtick
operator as -- very nice -- syntactic sugar for
assign() and get().
And, for normal identifiers,
foo - 1
`foo` - 1
assign(foo, 1)
and
foo
`foo`
get(foo)
are each three-fold equivalent. If a user does not *know* about
keywords/reserved words, (s)he can get a bit confused by
how e.g. break or `break` e.g. are handled:
Recall that Joe Average User does not know about assign, get,
`..` etc, but does know about ls() and typing an object name:
If he does ls(), sees break (which stems from previous
assign(break, 3) or `break` - 3)
and then types
break
or
str(break)
into the R console to inspect the variable he has seen in
ls(), the result will be a bit confusing to such
a user, and I had wanted that we'd evade that confusion.
The example with FALSE or `FALSE` is different but with similar
potential confusion.
{ S / S-plus does not either and gives a nice error
message:
S assign(FALSE, TRUE)
Problem: The name FALSE is reserved -- assignments to
it are not allowed }
PD But FALSE is not a keyword in S. In R this would
PD correspond to locking down F and T.
Hmm,... maybe. Brian has already answered to that.
Martin
PD There's another issue, namely that some keywords do have
PD associated functions; e.g., `if` exists as a variable,
PD and walls do come tumbling down if you redefine it (to a
PD different function). However, that is a completely
PD different thing, more related to redefining +.
PD (Incidentally, how hard would it be to ensure that such
PD symbols were always looked up in the base namespace?).
PD -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
PD c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014
PD Cph. K (*) \(*) -- University of Copenhagen Denmark Ph:
PD (+45) 35327918 ~~ - ([EMAIL PROTECTED])
PD FAX: (+45) 35327907
PD __
PD R-devel@r-project.org mailing list
PD https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assign(FALSE, TRUE)
Martin Maechler wrote: but notably not mainly by the above. I'd consider the backtick operator as -- very nice -- syntactic sugar for assign() and get(). And, for normal identifiers, foo - 1 `foo` - 1 assign(foo, 1) foo - 1 # same effect as above and foo `foo` get(foo) foo # not 1? (that is to say, i find this a tiny little bit incoherent, but perhaps useful for assignments, as is easier to get from my keyboard than `) are each three-fold equivalent. If a user does not *know* about keywords/reserved words, (s)he can get a bit confused by how e.g. break or `break` e.g. are handled: Recall that Joe Average User does not know about assign, get, `..` etc, but does know about ls() and typing an object name: If he does ls(), sees break (which stems from previous assign(break, 3) or `break` - 3) and then types break or str(break) btw. i find the following sequence of error messages a tiny little bit confusing: break(1) # Error: no loop to break from, jumping to top level break = function(arg) arg break(1) # Error in break : argument arg is missing, with no default break = function(arg=1) arg break(1) # Error: attempt to apply non-function if = function(arg) arg if(1) # keeps waiting for more input if(1) 2 # Error in if (1) 2 : unused argument(s) (2) vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assign(FALSE, TRUE)
On 18/11/2008, at 11:11 AM, Martin Maechler wrote:
snip
Yes. I'd propose that R-core look into how to make assignment to a
reserved word an error.
That's good news. Thanks.
cheers,
Rolf Turner
##
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assign(FALSE, TRUE)
PD == Peter Dalgaard [EMAIL PROTECTED]
on Tue, 18 Nov 2008 00:00:40 +0100 writes:
PD Martin Maechler wrote:
But in spite of all that I agree that I'd have liked
`FALSE` - whatever to signal an error about the fact
that it is a reserved word.
RT This is clearly not a very important issue, but it might
RT bear some thinking about.
Yes. I'd propose that R-core look into how to make
assignment to a reserved word an error.
PD I disagree. In a sense, this is the point of having the
PD backtick operator: allowing you to work with names that
PD would otherwise be syntax errors (notice that such names
PD are sometimes created outside your control, e.g. via
PD column names in data frames). If you start disallowing
PD some of them again, well, that way lies madness!
No, no. I'm not against allowing names that are otherwise syntax
errors. They were always possible via assign().
I just am convinced we should not allow reserved words.
{ S / S-plus does not either and gives a nice error message:
S assign(FALSE, TRUE)
Problem: The name FALSE is reserved -- assignments to it are not allowed
}
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assign(FALSE, TRUE)
Martin Maechler wrote:
PD == Peter Dalgaard [EMAIL PROTECTED]
on Tue, 18 Nov 2008 00:00:40 +0100 writes:
PD Martin Maechler wrote:
But in spite of all that I agree that I'd have liked
`FALSE` - whatever to signal an error about the fact
that it is a reserved word.
RT This is clearly not a very important issue, but it might
RT bear some thinking about.
Yes. I'd propose that R-core look into how to make
assignment to a reserved word an error.
PD I disagree. In a sense, this is the point of having the
PD backtick operator: allowing you to work with names that
PD would otherwise be syntax errors (notice that such names
PD are sometimes created outside your control, e.g. via
PD column names in data frames). If you start disallowing
PD some of them again, well, that way lies madness!
No, no. I'm not against allowing names that are otherwise syntax
errors. They were always possible via assign().
I just am convinced we should not allow reserved words.
Please unconvince yourself then... You are solving a problem that isn't
there: In R, you can assign to `FALSE` and access it as `FALSE`. You can
not access it as FALSE because that is a keyword and you cannot assign
to FALSE either.
{ S / S-plus does not either and gives a nice error message:
S assign(FALSE, TRUE)
Problem: The name FALSE is reserved -- assignments to it are not allowed
}
But FALSE is not a keyword in S. In R this would correspond to locking
down F and T.
There's another issue, namely that some keywords do have associated
functions; e.g., `if` exists as a variable, and walls do come tumbling
down if you redefine it (to a different function). However, that is a
completely different thing, more related to redefining +.
(Incidentally, how hard would it be to ensure that such symbols were
always looked up in the base namespace?).
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assign(FALSE, TRUE)
On Tue, 18 Nov 2008, Peter Dalgaard wrote:
Martin Maechler wrote:
PD == Peter Dalgaard [EMAIL PROTECTED]
on Tue, 18 Nov 2008 00:00:40 +0100 writes:
PD Martin Maechler wrote:
But in spite of all that I agree that I'd have liked
`FALSE` - whatever to signal an error about the fact
that it is a reserved word.
RT This is clearly not a very important issue, but it might
RT bear some thinking about.
Yes. I'd propose that R-core look into how to make
assignment to a reserved word an error.
PD I disagree. In a sense, this is the point of having the
PD backtick operator: allowing you to work with names that
PD would otherwise be syntax errors (notice that such names
PD are sometimes created outside your control, e.g. via
PD column names in data frames). If you start disallowing
PD some of them again, well, that way lies madness!
No, no. I'm not against allowing names that are otherwise syntax
errors. They were always possible via assign().
I just am convinced we should not allow reserved words.
Please unconvince yourself then... You are solving a problem that isn't
there: In R, you can assign to `FALSE` and access it as `FALSE`. You can
not access it as FALSE because that is a keyword and you cannot assign
to FALSE either.
{ S / S-plus does not either and gives a nice error message:
S assign(FALSE, TRUE)
Problem: The name FALSE is reserved -- assignments to it are not allowed
}
But FALSE is not a keyword in S. In R this would correspond to locking
down F and T.
I think both F and FALSE are 'keywords' in S, as that appears to say.
There's another issue, namely that some keywords do have associated
functions; e.g., `if` exists as a variable, and walls do come tumbling
down if you redefine it (to a different function). However, that is a
completely different thing, more related to redefining +.
(Incidentally, how hard would it be to ensure that such symbols were
always looked up in the base namespace?).
You mean they are primitives, so 'variable' for some meaning such as
'object'? The obvious idea is for the parser to do the lookup, but then
the deparser would need to be altered. Otherwise the evaluator needs to
special-case them, with a slight performance hit.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assign(FALSE, TRUE)
RT == Rolf Turner [EMAIL PROTECTED] on Tue, 18 Nov 2008 08:49:21 +1300 writes: RT It was recently pointed out by Wacek Kusnierczyk that RT although one is prevented from doing RT FALSE - TRUE RT one *can* do RT assign(FALSE,TRUE) RT and have an object named ``FALSE'' with value TRUE in RT one's workspace. RT This apparently has no deleterious effects; e.g. doing RT sample(1:7,replace=FALSE) RT gives a random permutation of 1:7 as expected and RT desired. I.e. the local object named ``FALSE'' is not RT used. RT Still, this seems counterintuitive and a bit confusing. RT Is it the intended state of affairs? I would have RT thought that RT FALSE - whatever RT and RT assign(FALSE,whatever) RT would be completely equivalent. Yes, such thoughts are understandable but wrong as you now know. Clearly assign(a b c, abc) does work, but a b c - abc does not; only `a b c` - abc does, as well as `FALSE` - TRUE and Wacek did mention the backticks. But in spite of all that I agree that I'd have liked `FALSE` - whatever to signal an error about the fact that it is a reserved word. RT This is clearly not a very important issue, but it might RT bear some thinking about. Yes. I'd propose that R-core look into how to make assignment to a reserved word an error. Thank you, Rolf, Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assign(FALSE, TRUE)
Rolf Turner wrote: It was recently pointed out by Wacek Kusnierczyk that although one is prevented from doing FALSE - TRUE one *can* do assign(FALSE,TRUE) and have an object named ``FALSE'' with value TRUE in one's workspace. This apparently has no deleterious effects; e.g. doing sample(1:7,replace=FALSE) gives a random permutation of 1:7 as expected and desired. I.e. the local object named ``FALSE'' is not used. Still, this seems counterintuitive and a bit confusing. Is it the intended state of affairs? I would have thought that FALSE - whatever and assign(FALSE,whatever) would be completely equivalent. No, FALSE is a _keyword_ representing the logical value. e - quote(`FALSE` FALSE) e[[2]] `FALSE` e[[3]] [1] FALSE mode(e[[3]]) [1] logical mode(e[[2]]) [1] name The thing that is equivalent to assign(FALSE,whatever) is `FALSE`-whatever. There are a couple of other keywords: TRUE, if, else, for, while, repeat, next, break, function. Did I forget any? The stuff you can do with FALSE isn't really any stranger than `2` - pi 2+2 [1] 4 so that two and two remains four for any value of `2`. You can't do 2-pi anymore than you can do FALSE-foo. This is clearly not a very important issue, but it might bear some thinking about. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assign(FALSE, TRUE)
Martin Maechler wrote: But in spite of all that I agree that I'd have liked `FALSE` - whatever to signal an error about the fact that it is a reserved word. RT This is clearly not a very important issue, but it might RT bear some thinking about. Yes. I'd propose that R-core look into how to make assignment to a reserved word an error. I disagree. In a sense, this is the point of having the backtick operator: allowing you to work with names that would otherwise be syntax errors (notice that such names are sometimes created outside your control, e.g. via column names in data frames). If you start disallowing some of them again, well, that way lies madness! -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
