xtra one.
>
> Also, I think several small packages are preferable to one large one
> because attaching a big one just to get the one or two functions you
> want is also a waste.
>
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
> On Thu, Apr 7, 2016 at 1:22 PM,
The plural of anecdote is not data. ~ Roger Brinner
> The combination of some data and an aching desire for an answer does not
> ensure that a reasonable answer can be extracted from a given body of data.
> ~ John Tukey
>
> 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko <dmitri.popave...@
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
gt;> mark.vander...@gmail.com> wrote:
>>
>>> 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 wa
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
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 <-
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,
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 `->`,
gt; [1] "A < . ~ B"
>
> The <.~ form has an advantage over the <.- form if you want to do complex
> expressions with more than one arrow, since the ~ form is syntactically
> correct but the - form isnt:
>
> > textex(A <.~ B ~.> C)
> [1] "A &
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
10 matches
Mail list logo
