Sharpie wrote:
> Currently, the only Curry implementation I know of is in the roxygen
> package which is kind of a weird dependency to install just for this
> one function.
I end up using Curry so much outside of Roxygen that I spun it off
into the `functional' package:
https://r-forge.r-projec
Quoth William Dunlap on Setting Orange, the 72nd of Discord:
> > f <- function(...) {
> + dotArgList <- substitute(list(...))
> + dotArgList
> + }
> > f(cat("foo\n"), stop("Oops"), warning("Hmm"))
> list(cat("foo\n"), stop("Oops"), warning("Hmm"))
> > # i.e., no argument was evaluated
Than
> However, if you don't want to evaluate the arguments, just pass
> substitute(arg) to your function instead of arg.
Thanks, Duncan; the problem is, I'm trying to substitute on `...' and
I don't think I can access `...' without inadvertently evaluating it.
I'm trying to write a debugging function
Is it possible to define an external special function (SPECIALSXP)?
I'm trying to do some language-level work, and don't want my arguments
evaluated before they hit C.
It looks like the only way to define a SPECIALSXP is by using XX0 in
the `eval' field of R_FunTab; is there any way to make this a
> One thing that I dislike about scoping in R is the fact that even in a
> namespace, searches eventually get to the global environment. I'd prefer
> if namespace searches went through the imported namespaces and nothing
> else. If that were the case, then the a$z example would never find a z
> Also other object systems which are alternatives to proto seem less
> relevant than basic scoping and free variable lookup in functions.
Sorry, but that seems absurd; object systems are less relevant to each
other than the totally orthogonal question of scope?
> proto does that but uses the con
> Your preference is inconsistent with how the rest of R works and is
> inflexible since everything inherits from Object.
Really? Here are a couple of counterexamples in S3 and S4 objects:
> z <- 1
>
> ## S4
> setClass('A', representation(a='numeric'))
[1] "A"
> a <- new('A', a=z)
>
> > I think you are looking for a different object model than proto
> > offers. There aren't many languages that offer the prototype object
> > model.
>
> Yes, your probably right---I don't have much experience using the
> prototype model. This is the way I expected it to work:
>
> > z <- 1
> >
Quoth Gabor Grothendieck on Sweetmorn, the 56th of Chaos:
> I think his objection is really only that he must specify baseenv()
> to get the behavior he prefers but from what I understand (I am
> basing this on my understanding that mutatr works like io language)
> in mutatr one must use Object whi
Quoth hadley wickham on Sweetmorn, the 56th of Chaos:
> You might want to have a look at the mutatr package which implements
> prototype OO with the behaviour you're looking for (I think).
Hey, Hadley; I remember your prototype stuff from DSC 2009. I saw some
slides of yours that discussed proto,
Quoth Ben Escoto on Sweetmorn, the 56th of Chaos:
> I'm new to proto, but it seems like this is also a big drawback:
>
> > z <- 1
> > proto(baseenv(), expr={a=z})$a
> Error in eval(expr, envir, enclos) : object "z" not found
Ouch, good point; it may be that parent pollution is the lesser of two
e
I understand why the following happens ($.proto delegates to get,
which ascends the parent hierarchy up to globalenv()), but I still
find it anti-intuitive:
> z <- 1
> y <- proto(a=2)
> y$z
[1] 1
Although this is well-documented behavior; wouldn't it uphold the
principle of least surprise
> IIRC, because there were always cases where they were attached to
> the wrong expression, and we were more or less convinced, there was
> no to do it "right" in all cases.
Doxygen and Javadoc seem to have solved the problem of comment-object
association, implying that it's not generally intracta
> They aren't "cannibalized", they are still there, where the source
> ref says they are.
I was thinking along the lines of using parse() to unambiguously
associate a comment block with a code object; sure, srcref() retains
them: but that's no different than parsing a text file.
If I can't associ
> The source references achieve something similar.
Thanks, Duncan; it seems like SkipComment cannibalizes comments before
they get to srcref, though.
I had to go back as far as 1999, actually, to find a version of gram.y
that implemented AddComment; would anyone object to bringing it back?
_
AddComment in gram.y would have been an extremely useful feature, but
it's been #if-0'd out; is it unimplemented?
It should have attached a comment attribute to any SEXP associated
with a comment.
__
R-devel@r-project.org mailing list
https://stat.ethz.
> parse() currently does nothing with comments, but it does tell you
> where each parsed expression came from . . .
That's exactly what I was looking for, Duncan; thanks. In fact, I used
parse() recently to write a telnet frontend to R.
__
R-devel@r-pro
> No, we want a solution in R.
Would it suffice, by the way, to source() a file and introspect upon
its objects with ls(), formals(), typeof(), mode(), and the like; or
should we formalize, say, a BNF and write the accompanying automaton?
__
R-devel@r-p
> You might also want to look at the Rdoc setup in the R.oo package.
Hmm; Rdoc seems thorough enough. What remains to be desired?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
> It is desirable that these tags and their syntax and semantics be
> compatible with those used by Doxygen and Javadoc, but extended with
> tags important for R specific things.
Doxygen, in particular, has some tags that are meaningless in R
(@category and @protocol come to mind); wouldn't it be
> I do not see the Roclets as mini-parsers, but as small R programs
> working on the parse tree/list returned by one big parser/lexer.
So I imagine that coming up with the intermediate parse-tree
representation would be part of the contract.
What would you think, by the way, of writing the parser
> You should probably also survey existing attempts - I have written
> something with ruby that suggest some ideas.
Fascinating, Hadley; do you have a link to the source, by any chance?
I imagine doing it in Scheme, Ruby or any language, for that matter,
where creating DSLs is cheap; would be a j
> The R Foundation has not acted as a mentoring organization before,
> so everything is a little bit experimental for us . . .
Is R-devel an appropriate place for GSoC communication, Fritz? My
message specific to Roxygen went unanswered.*
---
* https://stat.ethz.ch/pipermail/r-devel/2008
Is this the appropriate place for GSoC conversations?
If I understand the proposal correctly, there should be a lexer
(written in R) that exposes an API; that API would be used by
segregated mini-parsers (Roclets) which do the dirty work of Roxygen
-> {html, LaTeX, DocBook, ...} translation.
The
I never got a response from pcalg's maintainer, so I thought I'd
publisher a patch here that allows you to specify optional
node-labels; when no labels are specified, `plot' falls back on the
default behaviour of labelling nodes sequentially.
diff -Naur pcalg-orig/R/pcalg.R pcalg/R/pcalg.R
--- pcal
25 matches
Mail list logo
