similar to: 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)

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

On 01/03/2024 8:51 a.m., Dmitri Popavenko wrote: > On Fri, Mar 1, 2024 at 1:00?PM Duncan Murdoch <murdoch.duncan at gmail.com > <mailto:murdoch.duncan at 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

Dear Duncan, On Fri, Mar 1, 2024 at 11:30?AM Duncan Murdoch <murdoch.duncan at gmail.com> 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)

On Fri, Mar 1, 2024 at 1:00?PM Duncan Murdoch <murdoch.duncan at 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

On 01/03/2024 5:25 a.m., Dmitri Popavenko wrote: > Dear?Duncan, > > On Fri, Mar 1, 2024 at 11:30?AM Duncan Murdoch <murdoch.duncan at gmail.com > <mailto:murdoch.duncan at gmail.com>> 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.

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

Dear Barry, In general, I believe users are already accustomed with the classical arrows "->" and "<-" which are used as such in quoted expressions. But I agree that "-.>" is a very neat trick, thanks a lot. A small dot, what a difference. All the best, Dmitri On Mon, Mar 4, 2024 at 11:40?AM Barry Rowlingson < b.rowlingson at lancaster.ac.uk> wrote:

Maybe someone has already suggested this, but if your functions accepted strings you could use sub or gsub to replace the -> with a symbol that parsed at the same precedence as <-, say <<-. Then parse it and deal with it. When it is time to display the parsed and perhaps manipulated formulae to the user, deparse it and do the reverse replacement. > encode <-

It seems like you want to use -> and <- as arrows with different meanings to "A gets the value of B" in your package, as a means of writing expressions in your package language. Another possibility would be to use different symbols instead of the problematic -> and <-, for example you could use <.~ and ~.> which are not at all flipped or changed before you get a chance

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 <dmitri.popavenko at gmail.com> wrote: > > Hi everyone, > > I am aware this is a parser issue, but is there any possibility to capture > the use of the inverse

Hi Thierry, Thanks for that, the trouble is functions are package specific so moving from one package to another could be a solution, but I would rather save that as a last resort. As mentioned, creating a package C with all the common functions could also be an option, but this strategy quickly inflates the number of packages on CRAN. If no other option is possible, that could be the way but I

Thanks all, I don't know either (for the moment). It's all in the design phase still. Generally, I would also like to keep specific functions in specific packages, if at all possible. On Fri, Apr 8, 2016 at 3:03 PM, Mark van der Loo <mark.vanderloo at gmail.com> wrote: > Well, I'm not saying that Dmitri _should_ do it. I merely mention it as an > option that I think is

Hi Mark, Uhm... sometimes this is not always possible. For example I have a package QCA which produces truth tables (all combinations of presence / absence of causal conditions), and it uses the venn package to draw a Venn diagram. It is debatable if one should assimilate the "venn" package into the QCA package (other people might want Venn diagrams but not necessarily the other QCA

A third possibility, which I use in my gtools and gdata packages, is to use soft-links to create a copy of the relevant functions from one package in the other. I make sure these functions are *not* exported, so no conflicts are created, and the use of soft-links mean the code never gets out of sync. -Greg -- Change your thoughts and you change the world. --Dr. Norman Vincent Peale > On

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

Hello all, I would like to build two packages (say A and B), for two different purposes. Each of them need one or two functions from the other, which leads to the problem of circular dependency. Is there a way for package A to import a function from package B, and package B to import a function from package A, without arriving to circular dependency? Other suggestions in the archive mention

Hi, Field RdMacros was introduced in file DESCRIPTION to allow users to import LaTeX-like macros from other packages. Currently 'R CMD Check --as-cran' gives a NOTE: > Unknown, possibly mis-spelled, field in DESCRIPTION: > ?RdMacros? A small package demonstrating this is available at http://www.maths.manchester.ac.uk/~gb/testRdMacro_0.0.2.tar.gz (and this is the source:

Another, perhaps slightly off the wall reframing of the 3-package possibility: Have packages B, a, and UserFacingA, as follows *a* contains all the functionality in your A package that *does not depend on B* *B* *imports from* *a* and is essentially unchanged *UserFacingA* *Depends* on *a* and *imports from* *B*, it implements all functionality from your package A that *does depend on* *B*, and

At the risk of stating the over-obvious: there's also the option of creating just a single package containing all functions. None of the functions that create the interdependencies need to be exported that way. Btw, his question is probably better at home at the r-package-devel list. Best, M On Thu, Apr 7, 2016, 22:24 Dmitri Popavenko <dmitri.popavenko at gmail.com> wrote: >