[Rd] capture "->"

Adrian Dușa du@@@@dr|@n @end|ng |rom gm@||@com
Fri Mar 1 17:37:31 CET 2024


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 <avi.e.gross using 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 <r-devel-bounces using r-project.org> On Behalf Of Duncan Murdoch
> Sent: Friday, March 1, 2024 9:23 AM
> To: Dmitri Popavenko <dmitri.popavenko using gmail.com>
> Cc: r-devel <r-devel using 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 <murdoch.duncan using gmail.com
> > <mailto:murdoch.duncan using 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 using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]



More information about the R-devel mailing list