Re: [Rd] capture "->"

[Dmitri Popavenko]

On Sat, Mar 2, 2024 at 7:58 PM Gabor Grothendieck 
wrote:

> Would it be good enough to pass it as a formula?  Using your definition of
> foo
>
>   foo(~ A -> result)
>   ## result <- ~A
>
>   foo(~ result <- A)
>   ## ~result <- A
>

Yes, to pass as a formula would be the idea.
It's just that the parser inverses "~A -> result" into "result <- ~A".
We are seeking for any way possible to flag this inversion.

Avi, thank you for your efforts too. Wrapping symbols into percent signs is
an option, but as Duncan says it is much more intuitive to just quote the
expression.
The challenge is to somehow flag the parser inversion, otherwise a quoted
expression seems to be the only solution possible.

Regards,
Dmitri

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture "->"

[Gabor Grothendieck]

Would it be good enough to pass it as a formula?  Using your definition of foo

  foo(~ A -> result)
  ## result <- ~A

  foo(~ result <- A)
  ## ~result <- A

On Fri, Mar 1, 2024 at 4:18 AM Dmitri Popavenko
 wrote:
>
> Hi everyone,
>
> I am aware this is a parser issue, but is there any possibility to capture
> the use of the inverse assignment operator into a formula?
>
> Something like:
>
> > foo <- function(x) substitute(x)
>
> gives:
>
> > foo(A -> B)
> B <- A
>
> I wonder if there is any possibility whatsoever to signal the use of ->
> instead of <-
>
> Thank you,
> Dmitri
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture "->"

[avi.e.gross]

Duncan, Adrian and all,

I decided to look a bit at how various operators are seen by typeof() in light 
of this discussion and it seems there are quite a few categories as shown below 
and I suspect more exist. R, like many languages was not initially designed to 
have some object-oriented aspects and some have been cobbled on over the years 
including multiple emulations of what it means to be an object. So, explicit or 
implicit functions may be of different kinds.

> typeof(`<-`)
[1] "special"
> typeof(`->`)
Error: object '->' not found
> typeof(`+`)
[1] "builtin"
> typeof(`=`)
[1] "special"
> typeof(`|>`)
Error: object '|>' not found
> typeof(`%>%`)
[1] "closure"

In principle, and someone can probably point to languages that do something 
like this, all assignments could be centralized into some kind of primitive 
function call along the lines of:

assign("A", 5)

Then you could build on that so that the definition of = and <- and even <-- 
would mean that the following might result in something like the above:

A = 5
A <- 5

Bothe become an assign statement like the above meaning a function with a side 
effect.

A <- 5

Would simply be an assign with an added argument specifying the global 
environment.

The other two forms would just invert it so that

5 -> A
5 --> A

Simply generate the same assignment statement.

I am not sure if such a system would work well for all needs but I can see a 
language doing that even if it makes it slower. And, in such a system, you 
could create your own assignment operators or redirect the ones already 
existing as I considered a possibility.

But for some purposes, it may be way easier to have the ability to have some 
elements of absolutely fixed syntax that allow functionality even before an 
expression is fully evaluated. As one example, a comma that is not hidden in 
quotes is generally considered to be a way to determine how to break an 
expression into parts. Otherwise, how would you know that f(a,b,c) has three 
arguments. So what happens if your country uses a comma like other use a period 
as in numbers? Yes, in some environments you can specify that this is being 
done but it is really not trivial to make a system that is completely flexible 
in all aspects and allows you to flip from one way of using numbers to the 
other while also changing any other places the symbols are used in different 
ways.

So the problem becomes whether you can graft the mini language required for 
dealing with graphs that can include A -> B and A <- B and perhaps A <-> B in 
ways that are either not seen as they are parsed or even evaluated or that 
over-ride normal behavior.

One obvious idea is to avoid re-using the same symbols. R frequently just wraps 
symbols in percent signs so you might consider transforming anything to be A 
%->% B or maybe something like A %_>% or other notations that the parser does 
not see. It may be a pain but %FORWARD% versus %BACKWARD% or other gimmicks 
might work enough and you can always substitute out to the original version 
after you pass this danger zone.

And if your formulas are wrapped into some kind of object, they can store 
several versions or have the ability to do conversions.

But those ideas belong in  a more mainstream R mailing list.



-Original Message-
From: Duncan Murdoch  
Sent: Saturday, March 2, 2024 6:32 AM
To: Adrian Dușa ; avi.e.gr...@gmail.com
Cc: r-devel 
Subject: Re: [Rd] capture "->"

You can't change the parser.  Changes like `+` <- `-` change the 
function that is called when the expression contains a function call to 
`+`; this happens in `eval()`, not in `parse()`.  There are never any 
function calls to `->`, because the parser outputs a call to `<-` with 
the operands reversed when it sees that token.

Duncan Murdoch

On 02/03/2024 6:06 a.m., Adrian Dușa wrote:
> That would have been an elegant solution, but it doesn't seem to work:
> 
>> `->` <- `+`
>> 1 -> 3 # expecting 4
> Error in 3 <- 1 : invalid (do_set) left-hand side to assignment
> 
> It is possible to reassign other multiple character operators:
>> `%%` <- `+`
>> 1 %% 3
> [1] 4
> 
> The assignment operator `->` is so special for the R parser, that it seems
> impossible to change.
> 
> On Fri, Mar 1, 2024 at 11:30 PM  wrote:
> 
>> Adrian,
>>
>> That is indeed a specialized need albeit not necessarily one that cannot
>> be done by requiring an alternate way of typing a formula that avoids being
>> something the parser sees as needed to do at that level.
>>
>> In this case, my other questions become moot as I assume the global
>> assignment operator and somethings like assign(“xyz”, 5) will not be in the
>> way.
>>
>> What I was wondering about is wh

Re: [Rd] capture "->"

[Dmitri Popavenko]

On Sat, Mar 2, 2024 at 1:31 PM Duncan Murdoch 
wrote:

> You can't change the parser.  Changes like `+` <- `-` change the
> function that is called when the expression contains a function call to
> `+`; this happens in `eval()`, not in `parse()`.  There are never any
> function calls to `->`, because the parser outputs a call to `<-` with
> the operands reversed when it sees that token.
>

Another idea would have been to use "=>", which is disabled by default:
> substitute(A => B)
Error: '=>' is disabled; set '_R_USE_PIPEBIND_' envvar to a true value ...

> Sys.setenv(`_R_USE_PIPEBIND_` = TRUE)
> substitute(A => B)
Error in substitute(`=>`(A, B)) :
  invalid use of pipe bind symbol (:1:0)

The quest is to obtain a valid expression to get past substitute(), but it
proves to be more difficult than I initially thought.
Dmitri

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture "->"

[Duncan Murdoch]

You can't change the parser.  Changes like `+` <- `-` change the 
function that is called when the expression contains a function call to 
`+`; this happens in `eval()`, not in `parse()`.  There are never any 
function calls to `->`, because the parser outputs a call to `<-` with 
the operands reversed when it sees that token.


Duncan Murdoch

On 02/03/2024 6:06 a.m., Adrian Dușa wrote:

That would have been an elegant solution, but it doesn't seem to work:


`->` <- `+`
1 -> 3 # expecting 4

Error in 3 <- 1 : invalid (do_set) left-hand side to assignment

It is possible to reassign other multiple character operators:

`%%` <- `+`
1 %% 3

[1] 4

The assignment operator `->` is so special for the R parser, that it seems
impossible to change.

On Fri, Mar 1, 2024 at 11:30 PM  wrote:


Adrian,

That is indeed a specialized need albeit not necessarily one that cannot
be done by requiring an alternate way of typing a formula that avoids being
something the parser sees as needed to do at that level.

In this case, my other questions become moot as I assume the global
assignment operator and somethings like assign(“xyz”, 5) will not be in the
way.

What I was wondering about is what happens if you temporarily disable the
meaning of the assignment operator <- and turn it back on after.

In the following code, for no reason, I redefine + to mean – and then undo
it:



temp <- `+`
`+` <- `-`
5 + 3

[1] 2

`+` <- temp
5 + 3

[1] 8



[[alternative HTML version deleted]]

__
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

Re: [Rd] capture "->"

[Adrian Dușa]

That would have been an elegant solution, but it doesn't seem to work:

> `->` <- `+`
> 1 -> 3 # expecting 4
Error in 3 <- 1 : invalid (do_set) left-hand side to assignment

It is possible to reassign other multiple character operators:
> `%%` <- `+`
> 1 %% 3
[1] 4

The assignment operator `->` is so special for the R parser, that it seems
impossible to change.

On Fri, Mar 1, 2024 at 11:30 PM  wrote:

> Adrian,
>
> That is indeed a specialized need albeit not necessarily one that cannot
> be done by requiring an alternate way of typing a formula that avoids being
> something the parser sees as needed to do at that level.
>
> In this case, my other questions become moot as I assume the global
> assignment operator and somethings like assign(“xyz”, 5) will not be in the
> way.
>
> What I was wondering about is what happens if you temporarily disable the
> meaning of the assignment operator <- and turn it back on after.
>
> In the following code, for no reason, I redefine + to mean – and then undo
> it:
>
>
> > temp <- `+`
> > `+` <- `-`
> > 5 + 3
> [1] 2
> > `+` <- temp
> > 5 + 3
> [1] 8
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture "->"

[avi.e.gross]

Adrian,
 
That is indeed a specialized need albeit not necessarily one that cannot be 
done by requiring an alternate way of typing a formula that avoids being 
something the parser sees as needed to do at that level.
 
In this case, my other questions become moot as I assume the global assignment 
operator and somethings like assign(“xyz”, 5) will not be in the way.
 
What I was wondering about is what happens if you temporarily disable the 
meaning of the assignment operator <- and turn it back on after.
 
In the following code, for no reason, I redefine + to mean – and then undo it:
 
 
> temp <- `+`
> `+` <- `-`
> 5 + 3
[1] 2
> `+` <- temp
> 5 + 3
[1] 8
 
I have no idea if a similar technique could save and later restore the meaning 
of <- and replace it with something appropriate so that an expression using it 
is not evaluated the same way and leaves it alone long enough …
 
Of course, even if this works, it could cause side effects if anything else is 
done between changes that invokes it (maybe not likely) or the change back is 
not done perhaps due to an error interruption.
 
 
Avi
 
From: Adrian Dușa  
Sent: Friday, March 1, 2024 11:38 AM
To: avi.e.gr...@gmail.com
Cc: r-devel ; Dmitri Popavenko 

Subject: Re: [Rd] capture "->"
 
I would also be interested in that.
For me, this is interesting for my QCA package, over which Dmitri and I have 
exchanged a couple of messages.
The "<-" operator is used to denote necessity, and the "->" is used for 
sufficiency.
 
Users often make use of Boolean expressions such as A*B + C -> Y
(to calculate if the expression A*B + C is sufficient for the outcome Y)
 
The parser inverses it into Y <- A*B + C, as if the outcome Y is necessary for 
the expression A*B + C, which changes the nature of the expression.
 
Quoting such expressions is already possible and it works as expected. We were 
trying to avoid the quotes, if at all possible, to simplify the command use in 
the manuals.
 
Best wishes,
Adrian
 
On Fri, Mar 1, 2024 at 4:33 PM mailto:avi.e.gr...@gmail.com> > wrote:
I am wondering what the specific need for this is or is it just an exercise?

Where does it matter if a chunk of code assigns using "<-" beforehand or "->" 
after hand, or for that matter assigns indirectly without a symbol?

And whatever you come up with, will it also support the global assignment of 
"->>" as compared to ""<<-" too?

I do wonder if you can re-declare the assignment operators or would that mess 
up the parser.

-Original Message-
From: R-devel mailto:r-devel-boun...@r-project.org> > On Behalf Of Duncan Murdoch
Sent: Friday, March 1, 2024 9:23 AM
To: Dmitri Popavenko mailto:dmitri.popave...@gmail.com> >
Cc: r-devel mailto:r-devel@r-project.org> >
Subject: Re: [Rd] capture "->"

On 01/03/2024 8:51 a.m., Dmitri Popavenko wrote:
> On Fri, Mar 1, 2024 at 1:00 PM Duncan Murdoch  <mailto:murdoch.dun...@gmail.com>  
> <mailto:murdoch.dun...@gmail.com <mailto:murdoch.dun...@gmail.com> >> wrote:
> 
> ...
> I was thinking more of you doing something like
> 
>parse(text = "A -> B", keep.source = TRUE)
> 
> I forget what the exact rules are for attaching srcrefs to arguments of
> functions, but I do remember they are a little strange, because not
> every possible argument can accept a srcref attribute.  For example,
> you
> can't attach one to NULL, or to a name.
> 
> Srcrefs are also fairly big and building them is slow, so I think we
> tried to limit them to where they were needed, we didn't try to attach
> them to every subexpression, just one per statement.  Each expression
> within {} is a separate statement, so we get srcrefs attached to the {.
> But in "foo(A -> B)" probably you only get one on the foo call.
> 
> In some circumstances you could get the srcref on that call by looking
> at sys.call().  But then things are complicated again, because R
> doesn't
> attach srcrefs to things typed at the console, only to things that are
> sourced from files or text strings (and parsed with keep.source=TRUE).
> 
> So I think you should probably require input from a string or a
> file, or
> not expect foo(A -> B) to work without some decoration.
> 
> 
> Indeed, the more challenging task is to identify "->" at the console
> (from a script or a string, seems trivial now).
> 
> I would be willing to decorate as much as it takes to make this work, I 
> am just empty on more ideas how to persuade the parser.

By "decorate", I meant putting it in quotes and parsing it using 
parse(text=...), or putting it in braces as you found.  I think parsing 
a s

Re: [Rd] capture "->"

[Adrian Dușa]

I would also be interested in that.
For me, this is interesting for my QCA package, over which Dmitri and I
have exchanged a couple of messages.
The "<-" operator is used to denote necessity, and the "->" is used for
sufficiency.

Users often make use of Boolean expressions such as A*B + C -> Y
(to calculate if the expression A*B + C is sufficient for the outcome Y)

The parser inverses it into Y <- A*B + C, as if the outcome Y is necessary
for the expression A*B + C, which changes the nature of the expression.

Quoting such expressions is already possible and it works as expected. We
were trying to avoid the quotes, if at all possible, to simplify the
command use in the manuals.

Best wishes,
Adrian

On Fri, Mar 1, 2024 at 4:33 PM  wrote:

> I am wondering what the specific need for this is or is it just an
> exercise?
>
> Where does it matter if a chunk of code assigns using "<-" beforehand or
> "->" after hand, or for that matter assigns indirectly without a symbol?
>
> And whatever you come up with, will it also support the global assignment
> of "->>" as compared to ""<<-" too?
>
> I do wonder if you can re-declare the assignment operators or would that
> mess up the parser.
>
> -Original Message-
> From: R-devel  On Behalf Of Duncan Murdoch
> Sent: Friday, March 1, 2024 9:23 AM
> To: Dmitri Popavenko 
> Cc: r-devel 
> Subject: Re: [Rd] capture "->"
>
> On 01/03/2024 8:51 a.m., Dmitri Popavenko wrote:
> > On Fri, Mar 1, 2024 at 1:00 PM Duncan Murdoch  > <mailto:murdoch.dun...@gmail.com>> wrote:
> >
> > ...
> > I was thinking more of you doing something like
> >
> >parse(text = "A -> B", keep.source = TRUE)
> >
> > I forget what the exact rules are for attaching srcrefs to arguments
> of
> > functions, but I do remember they are a little strange, because not
> > every possible argument can accept a srcref attribute.  For example,
> > you
> > can't attach one to NULL, or to a name.
> >
> > Srcrefs are also fairly big and building them is slow, so I think we
> > tried to limit them to where they were needed, we didn't try to
> attach
> > them to every subexpression, just one per statement.  Each expression
> > within {} is a separate statement, so we get srcrefs attached to the
> {.
> > But in "foo(A -> B)" probably you only get one on the foo call.
> >
> > In some circumstances you could get the srcref on that call by
> looking
> > at sys.call().  But then things are complicated again, because R
> > doesn't
> > attach srcrefs to things typed at the console, only to things that
> are
> > sourced from files or text strings (and parsed with
> keep.source=TRUE).
> >
> > So I think you should probably require input from a string or a
> > file, or
> > not expect foo(A -> B) to work without some decoration.
> >
> >
> > Indeed, the more challenging task is to identify "->" at the console
> > (from a script or a string, seems trivial now).
> >
> > I would be willing to decorate as much as it takes to make this work, I
> > am just empty on more ideas how to persuade the parser.
>
> By "decorate", I meant putting it in quotes and parsing it using
> parse(text=...), or putting it in braces as you found.  I think parsing
> a string is most likely to be reliable because someone might turn off
> `keep.source` and then the braced approach would fail.  But you have
> control over it when you call parse() yourself.
>
> Duncan Murdoch
>
> __
> 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
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture "->"

[avi.e.gross]

I am wondering what the specific need for this is or is it just an exercise?

Where does it matter if a chunk of code assigns using "<-" beforehand or "->" 
after hand, or for that matter assigns indirectly without a symbol?

And whatever you come up with, will it also support the global assignment of 
"->>" as compared to ""<<-" too?

I do wonder if you can re-declare the assignment operators or would that mess 
up the parser.

-Original Message-
From: R-devel  On Behalf Of Duncan Murdoch
Sent: Friday, March 1, 2024 9:23 AM
To: Dmitri Popavenko 
Cc: r-devel 
Subject: Re: [Rd] capture "->"

On 01/03/2024 8:51 a.m., Dmitri Popavenko wrote:
> On Fri, Mar 1, 2024 at 1:00 PM Duncan Murdoch  <mailto:murdoch.dun...@gmail.com>> wrote:
> 
> ...
> I was thinking more of you doing something like
> 
>parse(text = "A -> B", keep.source = TRUE)
> 
> I forget what the exact rules are for attaching srcrefs to arguments of
> functions, but I do remember they are a little strange, because not
> every possible argument can accept a srcref attribute.  For example,
> you
> can't attach one to NULL, or to a name.
> 
> Srcrefs are also fairly big and building them is slow, so I think we
> tried to limit them to where they were needed, we didn't try to attach
> them to every subexpression, just one per statement.  Each expression
> within {} is a separate statement, so we get srcrefs attached to the {.
> But in "foo(A -> B)" probably you only get one on the foo call.
> 
> In some circumstances you could get the srcref on that call by looking
> at sys.call().  But then things are complicated again, because R
> doesn't
> attach srcrefs to things typed at the console, only to things that are
> sourced from files or text strings (and parsed with keep.source=TRUE).
> 
> So I think you should probably require input from a string or a
> file, or
> not expect foo(A -> B) to work without some decoration.
> 
> 
> Indeed, the more challenging task is to identify "->" at the console
> (from a script or a string, seems trivial now).
> 
> I would be willing to decorate as much as it takes to make this work, I 
> am just empty on more ideas how to persuade the parser.

By "decorate", I meant putting it in quotes and parsing it using 
parse(text=...), or putting it in braces as you found.  I think parsing 
a string is most likely to be reliable because someone might turn off 
`keep.source` and then the braced approach would fail.  But you have 
control over it when you call parse() yourself.

Duncan Murdoch

__
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

Re: [Rd] capture "->"

[Duncan Murdoch]

On 01/03/2024 8:51 a.m., Dmitri Popavenko wrote:
On Fri, Mar 1, 2024 at 1:00 PM Duncan Murdoch > wrote:


...
I was thinking more of you doing something like

   parse(text = "A -> B", keep.source = TRUE)

I forget what the exact rules are for attaching srcrefs to arguments of
functions, but I do remember they are a little strange, because not
every possible argument can accept a srcref attribute.  For example,
you
can't attach one to NULL, or to a name.

Srcrefs are also fairly big and building them is slow, so I think we
tried to limit them to where they were needed, we didn't try to attach
them to every subexpression, just one per statement.  Each expression
within {} is a separate statement, so we get srcrefs attached to the {.
But in "foo(A -> B)" probably you only get one on the foo call.

In some circumstances you could get the srcref on that call by looking
at sys.call().  But then things are complicated again, because R
doesn't
attach srcrefs to things typed at the console, only to things that are
sourced from files or text strings (and parsed with keep.source=TRUE).

So I think you should probably require input from a string or a
file, or
not expect foo(A -> B) to work without some decoration.


Indeed, the more challenging task is to identify "->" at the console
(from a script or a string, seems trivial now).

I would be willing to decorate as much as it takes to make this work, I 
am just empty on more ideas how to persuade the parser.


By "decorate", I meant putting it in quotes and parsing it using 
parse(text=...), or putting it in braces as you found.  I think parsing 
a string is most likely to be reliable because someone might turn off 
`keep.source` and then the braced approach would fail.  But you have 
control over it when you call parse() yourself.


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture "->"

[Dmitri Popavenko]

On Fri, Mar 1, 2024 at 1:00 PM Duncan Murdoch 
wrote:

> ...
> I was thinking more of you doing something like
>
>   parse(text = "A -> B", keep.source = TRUE)
>
> I forget what the exact rules are for attaching srcrefs to arguments of
> functions, but I do remember they are a little strange, because not
> every possible argument can accept a srcref attribute.  For example, you
> can't attach one to NULL, or to a name.
>
> Srcrefs are also fairly big and building them is slow, so I think we
> tried to limit them to where they were needed, we didn't try to attach
> them to every subexpression, just one per statement.  Each expression
> within {} is a separate statement, so we get srcrefs attached to the {.
> But in "foo(A -> B)" probably you only get one on the foo call.
>
> In some circumstances you could get the srcref on that call by looking
> at sys.call().  But then things are complicated again, because R doesn't
> attach srcrefs to things typed at the console, only to things that are
> sourced from files or text strings (and parsed with keep.source=TRUE).
>
> So I think you should probably require input from a string or a file, or
> not expect foo(A -> B) to work without some decoration.
>

Indeed, the more challenging task is to identify "->" at the console
(from a script or a string, seems trivial now).

I would be willing to decorate as much as it takes to make this work, I am
just empty on more ideas how to persuade the parser.
Dmitri

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture "->"

[Duncan Murdoch]

On 01/03/2024 5:25 a.m., Dmitri Popavenko wrote:

Dear Duncan,

On Fri, Mar 1, 2024 at 11:30 AM Duncan Murdoch > wrote:


...
If you parse it with srcrefs, you could look at the source.  The parser
doesn't record whether it was A -> B or B <- A anywhere else.


Thank you, this gets me closer but it still needs a little push:

 > foo <- function(x) {
   x <- substitute(x)
   return(attr(x, "srcref")[[2]])
}

 > foo(A -> B)
NULL

This seems to work, however:
 > foo({A -> B})
A -> B

Is there a way to treat the formula as if it was enclosed between the 
curly brackets?

Dmitri


I was thinking more of you doing something like

 parse(text = "A -> B", keep.source = TRUE)

I forget what the exact rules are for attaching srcrefs to arguments of 
functions, but I do remember they are a little strange, because not 
every possible argument can accept a srcref attribute.  For example, you 
can't attach one to NULL, or to a name.


Srcrefs are also fairly big and building them is slow, so I think we 
tried to limit them to where they were needed, we didn't try to attach 
them to every subexpression, just one per statement.  Each expression 
within {} is a separate statement, so we get srcrefs attached to the {. 
But in "foo(A -> B)" probably you only get one on the foo call.


In some circumstances you could get the srcref on that call by looking 
at sys.call().  But then things are complicated again, because R doesn't 
attach srcrefs to things typed at the console, only to things that are 
sourced from files or text strings (and parsed with keep.source=TRUE).


So I think you should probably require input from a string or a file, or 
not expect foo(A -> B) to work without some decoration.


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture "->"

[Dmitri Popavenko]

Dear Duncan,

On Fri, Mar 1, 2024 at 11:30 AM Duncan Murdoch 
wrote:

> ...
> If you parse it with srcrefs, you could look at the source.  The parser
> doesn't record whether it was A -> B or B <- A anywhere else.
>

Thank you, this gets me closer but it still needs a little push:

> foo <- function(x) {
  x <- substitute(x)
  return(attr(x, "srcref")[[2]])
}

> foo(A -> B)
NULL

This seems to work, however:
> foo({A -> B})
A -> B

Is there a way to treat the formula as if it was enclosed between the curly
brackets?
Dmitri

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture "->"

[Duncan Murdoch]

On 01/03/2024 4:17 a.m., Dmitri Popavenko wrote:

Hi everyone,

I am aware this is a parser issue, but is there any possibility to capture
the use of the inverse assignment operator into a formula?

Something like:


foo <- function(x) substitute(x)


gives:


foo(A -> B)

B <- A

I wonder if there is any possibility whatsoever to signal the use of ->
instead of <-


If you parse it with srcrefs, you could look at the source.  The parser 
doesn't record whether it was A -> B or B <- A anywhere else.


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] capture "->"

[Dmitri Popavenko]

Hi everyone,

I am aware this is a parser issue, but is there any possibility to capture
the use of the inverse assignment operator into a formula?

Something like:

> foo <- function(x) substitute(x)

gives:

> foo(A -> B)
B <- A

I wonder if there is any possibility whatsoever to signal the use of ->
instead of <-

Thank you,
Dmitri

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture error messages from loading shared objects

[Adrian Dușa]

Thanks Henrik and Bill,

Indeed, but I do have a function called tryCatchWEM() in package admisc
that captures all that.

My use case was to test for different architectures (for instance, arm64 vs
Intel MacOS) embedding R in cross-platform applications.
I needed to test if the package could be loaded, and previously used
requireNamespace() being unaware, as Ivan pointed out, that internally that
function already does tryCatch() with loadNamespace().

That was the reason why my own function tryCatchWEM() could not capture
that specific error message.
I now do:
> admisc::tryCatchWEM(loadNamespace("foobar"))
$error
[1] "there is no package called ‘foobar’"

(and the error message is captured just fine).

All the best,
Adrian

On Tue, Nov 28, 2023 at 7:45 PM Henrik Bengtsson 
wrote:

> Careful; tryCatch() on non-error conditions will break out of what's
> evaluated, e.g.
>
> res <- tryCatch({
>   cat("1\n")
>   message("2")
>   cat("3\n")
>   42
> }, message = identity)
>
> will output '1' but not '3', because it returns as soon as the first
> message() is called.
>
> To "record" messages (same for warnings), use withCallingHandlers()
> instead, e.g.
>
> msgs <- list()
> res <- withCallingHandlers({
>   cat("1\n")
>   message("2")
>   cat("3\n")
>   42
> }, message = function(m) {
>   msgs <<- c(msgs, list(m))
>   invokeRestart("muffleMessage")
> })
>
> This will output '1', muffle '2', output '3', and return 42, and 'msgs'
> holds
>
> > msgs
> [[1]]
> 
> /Henrik
>
> On Tue, Nov 28, 2023 at 10:34 AM Bill Dunlap 
> wrote:
> >
> > If you would like to save the error message instead of suppressing it,
> you
> > can use tryCatch(message=function(e)e, ...).
> >
> > -BIll
> >
> > On Tue, Nov 28, 2023 at 3:55 AM Adrian Dusa 
> wrote:
> >
> > > Once again, Ivan, many thanks.
> > > Yes, that does solve it.
> > > Best wishes,
> > > Adrian
> > >
> > > On Tue, Nov 28, 2023 at 11:28 AM Ivan Krylov 
> > > wrote:
> > >
> > > > В Tue, 28 Nov 2023 10:46:45 +0100
> > > > Adrian Dusa  пишет:
> > > >
> > > > > tryCatch(requireNamespace("foobar"), error = function(e) e)
> > > >
> > > > I think you meant loadNamespace() (which throws errors), not
> > > > requireNamespace() (which internally uses
> tryCatch(loadNamespace(...))
> > > > and may or may not print the error depending on the `quietly`
> argument).
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan
> > > >
> > >
> > > [[alternative HTML version deleted]]
> > >
> > > __
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > 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
>


-- 
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr. 90-92
050663 Bucharest sector 5
Romania
https://adriandusa.eu

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture error messages from loading shared objects

[Henrik Bengtsson]

Careful; tryCatch() on non-error conditions will break out of what's
evaluated, e.g.

res <- tryCatch({
  cat("1\n")
  message("2")
  cat("3\n")
  42
}, message = identity)

will output '1' but not '3', because it returns as soon as the first
message() is called.

To "record" messages (same for warnings), use withCallingHandlers()
instead, e.g.

msgs <- list()
res <- withCallingHandlers({
  cat("1\n")
  message("2")
  cat("3\n")
  42
}, message = function(m) {
  msgs <<- c(msgs, list(m))
  invokeRestart("muffleMessage")
})

This will output '1', muffle '2', output '3', and return 42, and 'msgs' holds

> msgs
[[1]]
 wrote:
>
> If you would like to save the error message instead of suppressing it, you
> can use tryCatch(message=function(e)e, ...).
>
> -BIll
>
> On Tue, Nov 28, 2023 at 3:55 AM Adrian Dusa  wrote:
>
> > Once again, Ivan, many thanks.
> > Yes, that does solve it.
> > Best wishes,
> > Adrian
> >
> > On Tue, Nov 28, 2023 at 11:28 AM Ivan Krylov 
> > wrote:
> >
> > > В Tue, 28 Nov 2023 10:46:45 +0100
> > > Adrian Dusa  пишет:
> > >
> > > > tryCatch(requireNamespace("foobar"), error = function(e) e)
> > >
> > > I think you meant loadNamespace() (which throws errors), not
> > > requireNamespace() (which internally uses tryCatch(loadNamespace(...))
> > > and may or may not print the error depending on the `quietly` argument).
> > >
> > > --
> > > Best regards,
> > > Ivan
> > >
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> [[alternative HTML version deleted]]
>
> __
> 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

Re: [Rd] capture error messages from loading shared objects

[Bill Dunlap]

If you would like to save the error message instead of suppressing it, you
can use tryCatch(message=function(e)e, ...).

-BIll

On Tue, Nov 28, 2023 at 3:55 AM Adrian Dusa  wrote:

> Once again, Ivan, many thanks.
> Yes, that does solve it.
> Best wishes,
> Adrian
>
> On Tue, Nov 28, 2023 at 11:28 AM Ivan Krylov 
> wrote:
>
> > В Tue, 28 Nov 2023 10:46:45 +0100
> > Adrian Dusa  пишет:
> >
> > > tryCatch(requireNamespace("foobar"), error = function(e) e)
> >
> > I think you meant loadNamespace() (which throws errors), not
> > requireNamespace() (which internally uses tryCatch(loadNamespace(...))
> > and may or may not print the error depending on the `quietly` argument).
> >
> > --
> > Best regards,
> > Ivan
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture error messages from loading shared objects

[Adrian Dusa]

Once again, Ivan, many thanks.
Yes, that does solve it.
Best wishes,
Adrian

On Tue, Nov 28, 2023 at 11:28 AM Ivan Krylov  wrote:

> В Tue, 28 Nov 2023 10:46:45 +0100
> Adrian Dusa  пишет:
>
> > tryCatch(requireNamespace("foobar"), error = function(e) e)
>
> I think you meant loadNamespace() (which throws errors), not
> requireNamespace() (which internally uses tryCatch(loadNamespace(...))
> and may or may not print the error depending on the `quietly` argument).
>
> --
> Best regards,
> Ivan
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture error messages from loading shared objects

[Ivan Krylov]

В Tue, 28 Nov 2023 10:46:45 +0100
Adrian Dusa  пишет:

> tryCatch(requireNamespace("foobar"), error = function(e) e) 

I think you meant loadNamespace() (which throws errors), not
requireNamespace() (which internally uses tryCatch(loadNamespace(...))
and may or may not print the error depending on the `quietly` argument).

-- 
Best regards,
Ivan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] capture error messages from loading shared objects

[Adrian Dusa]

Fellow R developers,

I can capture usual error message using the normal way:
> tc <- tryCatch(1 + a, error = function(e) e)
> tc


However I have troubles capturing the error message from this type of error:

> tc <- tryCatch(requireNamespace("foobar"), error = function(e) e)
Loading required namespace: foobar
Failed with error:  ‘there is no package called ‘foobar’’
> tc
[1] FALSE

Is there any way to capture that specific error message?

Thank you in advance,
Adrian

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Capture output of install.packages (pipe system2)

[Jeroen Ooms]

On Mon, Sep 23, 2013 at 6:50 PM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
 x - system2(Rscript, -e \install.packages('MASS',
 repos='http://probability.ca/cran')\, stdout=TRUE, stderr=TRUE)

Thank you, this suggestion seems to work (although I agree that
starting 3 procs to install a single package seems suboptimal). One
additional question: is it safe to assume that the Rscript
executable can always be found by the R process (cross platform), or
do I need to modify the example in case Rscript is not in the system
search path?

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Capture output of install.packages (pipe system2)

[Hadley Wickham]

You shouldn't assume - use file.path(R.home(bin), R)

Hadley

On Tue, Sep 24, 2013 at 9:37 AM, Jeroen Ooms jeroen.o...@stat.ucla.edu wrote:
 On Mon, Sep 23, 2013 at 6:50 PM, Duncan Murdoch
 murdoch.dun...@gmail.com wrote:
 x - system2(Rscript, -e \install.packages('MASS',
 repos='http://probability.ca/cran')\, stdout=TRUE, stderr=TRUE)

 Thank you, this suggestion seems to work (although I agree that
 starting 3 procs to install a single package seems suboptimal). One
 additional question: is it safe to assume that the Rscript
 executable can always be found by the R process (cross platform), or
 do I need to modify the example in case Rscript is not in the system
 search path?

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Chief Scientist, RStudio
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Capture output of install.packages (pipe system2)

[Jeroen Ooms]

On Mon, Sep 23, 2013 at 6:34 PM, Simon Urbanek
simon.urba...@r-project.org wrote:
 On top of my head for full capture I can only think of custom C code that 
 will re-direct stderr/out FDs as desired (it's really trivial to re-direct to 
 files, for dynamic capture it's a little more involved but there are examples 
 that do that).

I had secretly been hoping that system2(whoami, stdout=stdout(),
stderr=stderr()) would capture output streams from the child process
and concatenate to stdout() and stderr() in the parent just as if they
were sent by cat(foo, file=stdout()) and cat(bar, file=stderr())
such that they could be captured from sink() in the parent. However
thinking twice about this, it is probably very difficult to implement
without threads. The event loop in the parent process would need to
poll for buffered output in the child while waiting for it to return
or something.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Capture output of install.packages (pipe system2)

[Duncan Murdoch]

On 13-09-24 10:37 AM, Jeroen Ooms wrote:

On Mon, Sep 23, 2013 at 6:50 PM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:

x - system2(Rscript, -e \install.packages('MASS',
repos='http://probability.ca/cran')\, stdout=TRUE, stderr=TRUE)


Thank you, this suggestion seems to work (although I agree that
starting 3 procs to install a single package seems suboptimal).



For something that I only do every few weeks or months, I'd rather 
optimize the use of the programmer's time than that of the processor.  I 
get paid more per hour!


Duncan Murdoch

 One

additional question: is it safe to assume that the Rscript
executable can always be found by the R process (cross platform), or
do I need to modify the example in case Rscript is not in the system
search path?



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Capture output of install.packages (pipe system2)

[Jeroen Ooms]

Is there any way to capture output (both stdout and stderr) from
install.packages? Solutions like sink and capture.output don't work
because the install.packages calls out to system2 which is executed in
a separate process:

test - capture.output(install.packages(MASS))

The system2 function does have arguments stdout and stderr but afaik
these cannot be controlled via install.packages. I'm a bit reluctant
to start rolling my own version of install.packages just for this
reason.

Is there any way to somehow grab this output? Or alternatively, is
there a way to make R pipe stdout and stderr from system2 in such a
way that they can be captured with sink or capture.output in the R
parent process?

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Capture output of install.packages (pipe system2)

[Duncan Murdoch]

On 13-09-23 2:17 PM, Jeroen Ooms wrote:

Is there any way to capture output (both stdout and stderr) from
install.packages? Solutions like sink and capture.output don't work
because the install.packages calls out to system2 which is executed in
a separate process:

 test - capture.output(install.packages(MASS))

The system2 function does have arguments stdout and stderr but afaik
these cannot be controlled via install.packages. I'm a bit reluctant
to start rolling my own version of install.packages just for this
reason.

Is there any way to somehow grab this output? Or alternatively, is
there a way to make R pipe stdout and stderr from system2 in such a
way that they can be captured with sink or capture.output in the R
parent process?


See the recent thread 
https://mailman.stat.ethz.ch/pipermail/r-devel/2013-September/067552.html 
for an approach to this.


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Capture output of install.packages (pipe system2)

[Simon Urbanek]

Duncan,

On Sep 23, 2013, at 10:20 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote:

 On 13-09-23 2:17 PM, Jeroen Ooms wrote:
 Is there any way to capture output (both stdout and stderr) from
 install.packages? Solutions like sink and capture.output don't work
 because the install.packages calls out to system2 which is executed in
 a separate process:
 
 test - capture.output(install.packages(MASS))
 
 The system2 function does have arguments stdout and stderr but afaik
 these cannot be controlled via install.packages. I'm a bit reluctant
 to start rolling my own version of install.packages just for this
 reason.
 
 Is there any way to somehow grab this output? Or alternatively, is
 there a way to make R pipe stdout and stderr from system2 in such a
 way that they can be captured with sink or capture.output in the R
 parent process?
 
 See the recent thread 
 https://mailman.stat.ethz.ch/pipermail/r-devel/2013-September/067552.html 
 for an approach to this.
 

Can you, please, elaborate on how it is that relevant? The linked thread is 
talking about sink() which it irrelevant here (to quote the original e-mail 
Solutions like sink and capture.output don't work because the install.packages 
calls out to system2 which is executed in a separate process:). Something I 
missed?

Re original question: there is keep_outputs which allows to re-direct a copy of 
the output into a file - at least for the actual install part of it. 
On top of my head for full capture I can only think of custom C code that will 
re-direct stderr/out FDs as desired (it's really trivial to re-direct to files, 
for dynamic capture it's a little more involved but there are examples that do 
that).

Cheers,
Simon

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Capture output of install.packages (pipe system2)

[Duncan Murdoch]

On 13-09-23 6:34 PM, Simon Urbanek wrote:

Duncan,

On Sep 23, 2013, at 10:20 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote:


On 13-09-23 2:17 PM, Jeroen Ooms wrote:

Is there any way to capture output (both stdout and stderr) from
install.packages? Solutions like sink and capture.output don't work
because the install.packages calls out to system2 which is executed in
a separate process:

 test - capture.output(install.packages(MASS))

The system2 function does have arguments stdout and stderr but afaik
these cannot be controlled via install.packages. I'm a bit reluctant
to start rolling my own version of install.packages just for this
reason.

Is there any way to somehow grab this output? Or alternatively, is
there a way to make R pipe stdout and stderr from system2 in such a
way that they can be captured with sink or capture.output in the R
parent process?


See the recent thread 
https://mailman.stat.ethz.ch/pipermail/r-devel/2013-September/067552.html for 
an approach to this.



Can you, please, elaborate on how it is that relevant? The linked thread is talking about 
sink() which it irrelevant here (to quote the original e-mail Solutions like sink 
and capture.output don't work because the install.packages calls out to system2 which is 
executed in a separate process:). Something I missed?


Brian Ripley's reply describes how it is done in the tools package.  For 
example, as I sent privately to Jeroen,


x - system2(Rscript, -e \install.packages('MASS',
repos='http://probability.ca/cran')\, stdout=TRUE, stderr=TRUE)

captures all of the output from installing MASS.  As Jeroen pointed out, 
that isn't identical to running install.packages() in the current 
session; a real version of it should fill in more of the arguments, not 
leave them at their defaults.


Duncan Murdoch




Re original question: there is keep_outputs which allows to re-direct a copy of 
the output into a file - at least for the actual install part of it.
On top of my head for full capture I can only think of custom C code that will 
re-direct stderr/out FDs as desired (it's really trivial to re-direct to files, 
for dynamic capture it's a little more involved but there are examples that do 
that).

Cheers,
Simon




__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Capture output of install.packages (pipe system2)

[Hadley Wickham]

 Brian Ripley's reply describes how it is done in the tools package.  For
 example, as I sent privately to Jeroen,

 x - system2(Rscript, -e \install.packages('MASS',
 repos='http://probability.ca/cran')\, stdout=TRUE, stderr=TRUE)

 captures all of the output from installing MASS.  As Jeroen pointed out,
 that isn't identical to running install.packages() in the current session; a
 real version of it should fill in more of the arguments, not leave them at
 their defaults.

It does seems a little crazy that you're in a R process, then open
another one, which then opens a 3rd session! (often indirectly by
calling R CMD install which then calls an internal function in tools)

Hadley

-- 
Chief Scientist, RStudio
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Capture output of install.packages (pipe system2)

[Paul Gilbert]

On 13-09-23 08:20 PM, Hadley Wickham wrote:

Brian Ripley's reply describes how it is done in the tools package.  For
example, as I sent privately to Jeroen,

x - system2(Rscript, -e \install.packages('MASS',
repos='http://probability.ca/cran')\, stdout=TRUE, stderr=TRUE)

captures all of the output from installing MASS.  As Jeroen pointed out,
that isn't identical to running install.packages() in the current session; a
real version of it should fill in more of the arguments, not leave them at
their defaults.


It does seems a little crazy that you're in a R process, then open
another one, which then opens a 3rd session! (often indirectly by
calling R CMD install which then calls an internal function in tools)


It does seem very much more straight forward to do this in the process 
above R:


  R --vanilla --slave -e install.packages('whatever',
   repo='http://cran.r-project.org') R.out  21

(Omit mailer wrap.) Your mileage may vary depending on your OS.

Paul



Hadley



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel