R-alpha: Playing the tag game

[Ross Ihaka]

	Here are a handful of oddities in pre0.50-7 (at some risk of reprisals
	from people waiting for the real 0.50...):

I don't know that these will even be looked at before 0.49 :-) comes
out.  I'm checking portabity and configuration at present.  It would
be REALLY nice if commercial vendors could stick to the standards
(ANSI, POSIX ...) as well as the free software developers do.

	I was mucking about trying to figure out how to know which tags has
	been used in a function call, and some weird stuff happened.

	----------
	A call with tagged arguments is something like a list, the tags
	can be used to access elements, but the names attribute is absent,
	until the call is coerced to a list. (Attempting to set the names()
	causes evaluation. Changing "list" to "blipblop" causes an 'Error:
	couldn't find function "blipblop"' at that point.)

	> j<-substitute(list(a=1,b=2))
	> j
	list(a = 1, b = 2)
	> j$b
	[1] 2
	> names(j)
	NULL
	> names(j)<-NULL
	> j
	[[1]]
	[1] 1

	[[2]]
	[1] 2

This is an oversight, and should have a one line fix (add extra cases
to an existing switch).

	[Previously saved workspace restored]

	> j<-as.call(list(a=1,b=2))
	> j
	Segmentation fault (core dumped)
	------------
	Strange... as.call should return its argument if is.call is true?

	> j<-substitute(list(a=1,b=2))
	> j
	list(a = 1, b = 2)
	> as.call(j)
	Error in as.call(j) : invalid argument list
	> is.call(j)
	[1] TRUE

"as.call" is pretty new and unexercised.

	Ok, the right solution seems to be names(as.list(j)), but then we run
	into some other fun with NA's... Shouldn't the real NA print without
	quotes?

	> ch[1]<-paste("N","A",sep="") 
	> is.na(ch)
	[1] FALSE FALSE FALSE
	> ch
	[1] "NA" "a"  "b" 
	> ch[1]=="NA"
	[1] TRUE
	> ch[1]<-"NA"                 
	> is.na(ch)
	[1]  TRUE FALSE FALSE
	> 

You naughty boy! :-)  I've have always thought that using "NA" to
indicate a missing string value was asking for problems.  What happens
when some poor unsuspecting user starts abbreviating "North America"
for example.

We use a bottleneck at string creation time to check whether the string
being stored is "NA".  If it is, we return the address of a special
unique string.  That way we can check for NA by simply doing an address
comparison rather than a string comparison (this is the same trick we
use for comparing variable names).  This doesn't catch "NA" strings
made in the underhand fashion above.

I see a couple of possible solutions.

1.  Remain compatible with S and just unoptimise our detection of
    string NAs.

2.  Be incompatible with S and introduce a real NA for strings.
    This would print as NA rather than "NA".  I like this second
    solution, but its does violate the "prime directive" (be
    compatible).

Ross
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-