If statement generates two outputs

From: Wacek Kusnierczyk <Waclaw.Marcin.Kusnierczyk_at_idi.ntnu.no>
>Date: Sun, 22 Mar 2009 22:58:49 +0100

 >just for fun, you could do this with multiassignment, e.g., using the 
 >(highly experimental and premature!) rvalues:

 >    source('http://miscell.googlecode.com/svn/rvalues/rvalues.r') 
 >if (TRUE)

 >       c(df1, df2) := list(4:8, 9:13)

 >    dput(df1)
 >    # 4:8
 >    dput(df2)
 >    # 9:13

-------
Now THAT's what I call an overloaded operator!   ^_^

But seriously:  can someone explain to me what's going on in the 
rvalues.r code?  I tried a simple experiment, replacing ":=" with a 
"colec" in the code, and of course the line

c(df1, df2) colec list(4:8, 9:13)

just gives me a "syntax error" response.   Clearly I need a pointer to 
some documentation about how the colon and equals sign get "special 
treatment somewhere inside R.

thanks
Carl
G'day Carl,

On Mon, 23 Mar 2009 20:11:19 -0400

 >From: Wacek Kusnierczyk <Waclaw.Marcin.Kusnierczyk_at_idi.ntnu.no>
 >Date: Sun, 22 Mar 2009 22:58:49 +0100

 >just for fun, you could do this with multiassignment, e.g., using
 >the (highly experimental and premature!) rvalues:

 >    source('http://miscell.googlecode.com/svn/rvalues/rvalues.r') 
 >if (TRUE)

 >       c(df1, df2) := list(4:8, 9:13)

 >    dput(df1)
 >    # 4:8
 >    dput(df2)
 >    # 9:13

-------
Now THAT's what I call an overloaded operator!   ^_^

But seriously:  can someone explain to me what's going on in the 
rvalues.r code?  I tried a simple experiment, replacing ":=" with a 
"colec" in the code, and of course the line

c(df1, df2) colec list(4:8, 9:13)

just gives me a "syntax error" response.   Clearly I need a pointer
to some documentation about how the colon and equals sign get
"special treatment somewhere inside R.
Not sure why := gets a special treatment, perhaps because it is not a
valid name and, hence, the parser deduces that it is an operator?

IIRC, the traditional way to define your own operator is to bound the
name by percentage signs, i.e. replacing ":=" by "%colec%" and then
issuing the command

	c(df1, df2) %colec% list(4:8, 9:13)

will work.

Cheers,

	Berwin

=========================== Full address =============================
Berwin A Turlach                            Tel.: +65 6516 4416 (secr)
Dept of Statistics and Applied Probability        +65 6516 6650 (self)
Faculty of Science                          FAX : +65 6872 3919       
National University of Singapore     
6 Science Drive 2, Blk S16, Level 7          e-mail: statba at nus.edu.sg
Singapore 117546                    http://www.stat.nus.edu.sg/~statba
G'day Carl,

On Mon, 23 Mar 2009 20:11:19 -0400
Carl Witthoft <carl at witthoft.com> wrote:

 >From: Wacek Kusnierczyk <Waclaw.Marcin.Kusnierczyk_at_idi.ntnu.no>
 >Date: Sun, 22 Mar 2009 22:58:49 +0100

 >just for fun, you could do this with multiassignment, e.g., using
 >the (highly experimental and premature!) rvalues:

 >    source('http://miscell.googlecode.com/svn/rvalues/rvalues.r') 
 >if (TRUE)

 >       c(df1, df2) := list(4:8, 9:13)

 >    dput(df1)
 >    # 4:8
 >    dput(df2)
 >    # 9:13

-------
Now THAT's what I call an overloaded operator!   ^_^

But seriously:  can someone explain to me what's going on in the 
rvalues.r code?  I tried a simple experiment, replacing ":=" with a 
"colec" in the code, and of course the line

c(df1, df2) colec list(4:8, 9:13)

just gives me a "syntax error" response.   Clearly I need a pointer
to some documentation about how the colon and equals sign get
"special treatment somewhere inside R.

Not sure why := gets a special treatment, perhaps because it is not a
valid name and, hence, the parser deduces that it is an operator?

possibly.  you'd have to look into the parser code, as it has, as duncan
explained, no documentation.  ?Syntax doesn't mention it either, as
doesn't the r language definition, as far as i can see.
IIRC, the traditional way to define your own operator is to bound the
name by percentage signs, i.e. replacing ":=" by "%colec%" and then
issuing the command

	c(df1, df2) %colec% list(4:8, 9:13)

will work.

... and which was precisely why i wanted the simple ':=' -- because all
those traditional %*% are so ugly (syntactically).

vQ
G'day Carl,

On Mon, 23 Mar 2009 20:11:19 -0400
Carl Witthoft <carl at witthoft.com> wrote:

 >From: Wacek Kusnierczyk <Waclaw.Marcin.Kusnierczyk_at_idi.ntnu.no>
 >Date: Sun, 22 Mar 2009 22:58:49 +0100

 >just for fun, you could do this with multiassignment, e.g., using
 >the (highly experimental and premature!) rvalues:

 >    source('http://miscell.googlecode.com/svn/rvalues/rvalues.r') 
 >if (TRUE)

 >       c(df1, df2) := list(4:8, 9:13)

 >    dput(df1)
 >    # 4:8
 >    dput(df2)
 >    # 9:13

-------
Now THAT's what I call an overloaded operator!   ^_^

it's not really overloaded, it's *loaded*.  if you type

    a :=  1

in an r session without defining '=', r cannot 'find such a function',
but it doesn't complain about invalid syntax.  so there is the operator,
only that it's not operational.
But seriously:  can someone explain to me what's going on in the 
rvalues.r code? 
i think i-the-sinner'd be the right person to ask.  i'd suggest to
discuss offline, because rvalues is really an experiment, a proof of
concept, and as such may not be of interest for wider audience.  (it
might be that it will be developed into something substantial, but no
guarantees.)

vQ
G'day Carl,

On Mon, 23 Mar 2009 20:11:19 -0400
Carl Witthoft <carl at witthoft.com> wrote:

But seriously:  can someone explain to me what's going on in the 
rvalues.r code?  I tried a simple experiment, replacing ":=" with a 
"colec" in the code, and of course the line

c(df1, df2) colec list(4:8, 9:13)

just gives me a "syntax error" response.   Clearly I need a pointer
to some documentation about how the colon and equals sign get
"special treatment somewhere inside R.

Not sure why := gets a special treatment, 
yet another bug??
perhaps because it is not a
valid name and, hence, the parser deduces that it is an operator?

well, you can't do it with, e.g., ':==', because you'd get a *syntactic*
error (while ':=' gives a semantic error):

    a :== 1
    # syntactic error: unexpected '=' in ':='

    ':==' = function(a, b) NULL
    a :== 1
    # syntactic error again, of course

it's indeed surprising that it works with ':=' but not with, e.g., ':>'.

and in cases like ':-' you'd in fact use two operators (so an
'overloading' won't work for these):

    ':-' = function(a, b) a - if(a > b) b else 0
    2 :- 1
    # 2 1 0 -1
    # not 1

it's interesting to note that

    a :< b
    # error: unexpected '<' in ':<'

will tell you what's unexpected, while

    a :% b
    # error: unexpected input in 'a :% b'

    a :_ b
    # error: unexpected input in 'a :_'

will leave you wondering what's wrong there.

vQ
Berwin A Turlach wrote:

G'day Carl,

On Mon, 23 Mar 2009 20:11:19 -0400
Carl Witthoft <carl at witthoft.com> wrote:

But seriously:  can someone explain to me what's going on in the 
rvalues.r code?  I tried a simple experiment, replacing ":=" with a 
"colec" in the code, and of course the line

c(df1, df2) colec list(4:8, 9:13)

just gives me a "syntax error" response.   Clearly I need a pointer
to some documentation about how the colon and equals sign get
"special treatment somewhere inside R.

Not sure why := gets a special treatment, 

yet another bug??

This is probably due to that in the gram.y file :

case ':':
    if (nextchar(':')) {
        if (nextchar(':')) {
        yylval = install(":::");
        return NS_GET_INT;
        }
        else {
        yylval = install("::");
        return NS_GET;
        }
    }
    if (nextchar('=')) {
        yylval = install(":=");
        return LEFT_ASSIGN;
    }
    yylval = install(":");
    return ':';

which gives a meaning to ":=", so that parsing x := 2 makes sense.

 > parse( text = "x := 2" )
expression(x := 2)
attr(,"srcfile")
<text>

Romain

perhaps because it is not a
valid name and, hence, the parser deduces that it is an operator?

well, you can't do it with, e.g., ':==', because you'd get a *syntactic*
error (while ':=' gives a semantic error):

    a :== 1
    # syntactic error: unexpected '=' in ':='

    ':==' = function(a, b) NULL
    a :== 1
    # syntactic error again, of course

it's indeed surprising that it works with ':=' but not with, e.g., ':>'.

and in cases like ':-' you'd in fact use two operators (so an
'overloading' won't work for these):

    ':-' = function(a, b) a - if(a > b) b else 0
    2 :- 1
    # 2 1 0 -1
    # not 1

it's interesting to note that

    a :< b
    # error: unexpected '<' in ':<'

will tell you what's unexpected, while

    a :% b
    # error: unexpected input in 'a :% b'

    a :_ b
    # error: unexpected input in 'a :_'

will leave you wondering what's wrong there.

vQ

______________________________________________
R-help at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
This is probably due to that in the gram.y file :

case ':':
   if (nextchar(':')) {
       if (nextchar(':')) {
       yylval = install(":::");
       return NS_GET_INT;
       }
       else {
       yylval = install("::");
       return NS_GET;
       }
   }
   if (nextchar('=')) {
       yylval = install(":=");
       return LEFT_ASSIGN;
   }
   yylval = install(":");
   return ':';
   which gives a meaning to ":=", so that parsing x := 2 makes sense.

parse( text = "x := 2" )
expression(x := 2)
attr(,"srcfile")
<text>
thanks.  so it seems to be intentionally parsable, though i wouldn't say
that this gives a meaning to ':=' -- the operator has a syntactic
category, but no semantics.  the syntactic category does not imply any
semantics, as in

    '<-' = function(a, b) NULL
    1 <- a
    # NULL

where '<-' is still parsed the original way (as a LEFT_ASSIGN, gram.y
again), but has now a completely different semantics.

it looks like a bug to me:  ':=' is parsed on par with '<-' as a
LEFT_ASSIGN, but apparently is not backed by any function.  it's a
zombie.  (unless rvalues is used, that is.)

vQ

thanks.  so it seems to be intentionally parsable, though i wouldn't say
that this gives a meaning to ':=' -- the operator has a syntactic
category, but no semantics.  the syntactic category does not imply any
semantics, as in

   '<-' = function(a, b) NULL
   1 <- a
   # NULL

where '<-' is still parsed the original way (as a LEFT_ASSIGN, gram.y
again), but has now a completely different semantics.

it looks like a bug to me:  ':=' is parsed on par with '<-' as a
LEFT_ASSIGN, but apparently is not backed by any function.  it's a
zombie.  (unless rvalues is used, that is.)
yes, it's a zombie. It used to assign to the R system environment rather than the global workspace (roughly what is the base namespace now).

     -thomas

Thomas Lumley			Assoc. Professor, Biostatistics
tlumley at u.washington.edu	University of Washington, Seattle
On Tue, 24 Mar 2009, Wacek Kusnierczyk wrote:

thanks.  so it seems to be intentionally parsable, though i wouldn't say
that this gives a meaning to ':=' -- the operator has a syntactic
category, but no semantics.  the syntactic category does not imply any
semantics, as in

   '<-' = function(a, b) NULL
   1 <- a
   # NULL

where '<-' is still parsed the original way (as a LEFT_ASSIGN, gram.y
again), but has now a completely different semantics.

it looks like a bug to me:  ':=' is parsed on par with '<-' as a
LEFT_ASSIGN, but apparently is not backed by any function.  it's a
zombie.  (unless rvalues is used, that is.)
yes, it's a zombie. It used to assign to the R system environment
rather than the global workspace (roughly what is the base namespace
now).

thanks for the explanation.  for the sake of rvalues, please do not fix
this bug.  i find it useful to avoid messing with = and <-.

vQ

thanks for the explanation.  for the sake of rvalues, please do not fix
this bug.  i find it useful to avoid messing with = and <-.

If you insist on calling it a bug, the chances of its getting fixed are higher.

     -thomas

Thomas Lumley			Assoc. Professor, Biostatistics
tlumley at u.washington.edu	University of Washington, Seattle
On Tue, 24 Mar 2009, Wacek Kusnierczyk wrote:

thanks for the explanation.  for the sake of rvalues, please do not fix
this bug.  i find it useful to avoid messing with = and <-.

If you insist on calling it a bug, the chances of its getting fixed
are higher.
no no, it's *NOT* a b(...)!

vQ