[R] The end of Matlab

[Duncan Murdoch]

On 12/12/2008 1:06 PM, hadley wickham wrote:
>>> Oh yes, that's a good point.  But wouldn't the following do the job?
>>>
>>> "&.selector" <- function(a, b) {
>>>  function(n) a(n) & b(n)
>>> }
>>>
>>> or
>>>
>>> "&.selector" <- function(a, b) {
>>>  function(n) intersect(a(n), b(n))
>>> }
>>>
>>> depending on whether selectors return logical or numeric vectors.
>>> Writing functions for | and ! would be similarly easy.  Or am I
>>> missing something?
>>
>> No, I think those definitions would be fine, but I'd be concerned about
>> speed issues if we start messing with primitives.
> 
> Speed or expressiveness: pick one? ;)  People could always use the
> regular subsetting mechanisms if they want the best speed - any
> changes to support selectors wouldn't affect the speed of the other
> methods of subsetting, would they?
> 
>> While we're at it, we might as well do the same sort of thing for :, and
>> define a selector named end, and then 3:end would give a selector from 3 to
>> the end, which brings us back to the original question.  So it's not nearly
>> as intrusive as I thought it would be.
> 
> 3:end() do you mean?  Or do you mean extending seq so that it uses
> unevaluted input?

My end would be the output of your end().  If there are no args and no 
local context, I don't see the need for it to be a function call.  It 
would just be defined as something like

end <- structure( function(n) c(rep(FALSE, n-1), TRUE), class="selector")

I'm not sure what the definition of : should be if one of the args is a 
selector.

Duncan