[Rd] question

[Patrick Burns]

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
patrick at 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
> <ggrothendieck at 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,  <ivowel at 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.Kusnierczyk at idi.ntnu.no> wrote:
>>>       
>>>> Mark.Bravington at 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>