One idea of program design is that users
should be protected against themselves.
It is my experience that users, especially
novices, tend to over-split items rather than
over-clump items. The fact that items are
returned by the same function call would
argue to me that there is a connection between
the items.
Patrick Burns
patr...@burns-stat.com
+44 (0)20 8525 0696
http://www.burns-stat.com
(home of "The R Inferno" and "A Guide for the Unwilling S User")
ivo welch wrote:
hi gabor: this would be difficult to do. I don't think you want to
read my programs. it would give you an appreciation of what ugly
horror programs end users can write in the beautiful R language ;-).
clearly, one can work around the lack of such a feature.
multiple-return values are syntax sugar. but maybe it helps to
explain how I got to my own view. I had to send an R program to
someone who had never used it before. without knowing R, he could
literally read the entire program. the only thing that stumped him
was the multiple return values. In my program, he saw
f= function() { return(list(a=myvector1, b=myvector2)) }
result=f()
a= result$a
b= result$a
rm(result)
I had picked this method up over the years reading r-help. of course,
I had 10 return values, not two, each return value with its own long
name. I think it would have been a whole lot nicer if I could have
written FOR HIM simply
f= function() { return(myvector1,myvector2); }
(a,b)= f()
again, its syntax sugar. I would find such syntax a whole lot more
appealing. and I often write functions that pass back a main program,
but also some debug or other information. maybe I am the only one...
regards,
/iaw
On Sat, Mar 7, 2009 at 9:28 AM, Gabor Grothendieck
<ggrothendi...@gmail.com> wrote:
Why? Can you demonstrate any situations where its useful? Despite
having my own facility for this I've found that over the years I
have never used it.
On Sat, Mar 7, 2009 at 9:23 AM, <ivo...@gmail.com> wrote:
Gentlemen---these are all very clever workarounds, but please forgive me for
voicing my own opinion: IMHO, returning multiple values in a statistical
language should really be part of the language itself. there should be a
standard syntax of some sort, whatever it may be, that everyone should be
able to use and which easily transfers from one local computer to another.
It should not rely on clever hacks in the .Rprofile that are different from
user to user, and which leave a reader of end user R code baffled at first
by all the magic that is going on. Even the R tutorials for beginners should
show a multiple-value return example right at the point where function calls
and return values are first explained.
I really do not understand why the earlier implementation of "multiple-value
returns" was deprecated. then again, I am a naive end user, not a computer
language expert. I probably would not even understand the nuances of syntax
ambiguities that may have arisen. (this is my shortcoming.)
regards,
/iaw
On Mar 7, 2009 4:34am, Wacek Kusnierczyk
<waclaw.marcin.kusnierc...@idi.ntnu.no> wrote:
mark.braving...@csiro.au wrote:
The syntax for returning multiple arguments does not strike me as
particularly appealing. would it not possible to allow syntax like:
f= function() { return( rnorm(10), rnorm(20) ) }
(a,d$b) = f()
FWIW, my own solution is to define a "multi-assign operator":
'%
# a must be of the form '{thing1;thing2;...}'
a
e
stopifnot( length( b) == length( a))
for( i in seq_along( a))
eval( call( '
NULL
}
you might want to have the check less stringent, so that rhs may consist
of more values that the lhs has variables. or even skip the check and
assign NULL to a[i] for i > length(b). another idea is to allow %
be used with just one variable on the lhs.
here's a modified version:
'%
a
if (length(a) > 1)
a
if (length(a) > length(b))
b
e
for( i in seq_along( a))
eval( call( '
NULL }
{a; b} %
# a = 1; b = 2
a %
# a = 3
{a; b} %
# a = 5; b = NULL
vQ
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
