Design ideas

[romainfrancois]

I think the initial version should be written in R. For things like code generation, we can be much more expressive in R. And this is not something performance critical.

I'd like a mechanism for package to register attribute handlers. So we need a way to go from:

// [[foo::bar(...)]]

to the bar handler shipped by package foo.

Code between // [[ and ]] should be parseable as R code. We'll have to implement making sense of the parsed expression, but it should be fairly trivial.

[kevinushey]

Some other ideas:

• // [[foo]] can be interpreted as an attributes function, e.g. as an alias for // [[attributes::foo]]. This way attributes can come pre-shipped with common handlers, ie, the ones we wish to port from Rcpp, and also with automatic function registration for packages (e.g. // [[register]]).

(re // [[register]], I have an example of that in my 'playground' package as Kmisc::registerFunctions, but it only handles the .Call interface.)

• We can translate // [[Rcpp::foo]] to // [[attributes::foo]], since I think we want to maintain some backwards compatibility with Rcpp's attributes.

How should we handle multiple attributes for a single function? Eg.

// [[Rcpp::export, attributes::register]]
int foo() { ... }

A hiccup there is that it's not interpretable as R code unless we split on ", " (but we might have to be careful for things like the following):

// [[foo::bar("one", "two"), attributes::foo]]
...

I guess we would split on something like (,\s+)\w+::.

[johnmchambers]

(Coming at this from an outsider's view, of course.)

How do you want to regard the basic "// [[ expression ]]" syntax? If you
want to think of it as mapping into an R expression the most basic would
map "expression" into just that. In that case multiple attributes could
be "{expr1; expr1}".

If that seems too verbose, you could implicitly interpret "expression"
as an argument list to some implied function. If that function took ...
as its argument, you get your comma separated attributes. I.e., in
effect, parse the value of
paste0("DUMMYFUN(", expression, ")").

(This is all assuming you want some link to R syntax.)

John

On 3/4/14, 12:08 PM, Kevin Ushey wrote:

Some other ideas:

|// [[foo]]| can be interpreted as an |attributes| function, e.g.
as an alias for |// [[attributes::foo]]|. This way |attributes|
can come pre-shipped with common handlers, ie, the ones we wish to
port from |Rcpp|, and also with automatic function registration
for packages (e.g. |// [[register]]|). I have an example of that
in my 'playground' package as Kmisc::registerFunctions
<https://github.com/kevinushey/Kmisc/blob/master/R/registerFunctions.R>,
but it only handles the |.Call| interface.

We can translate |// [[Rcpp::foo]]| to |// [[attributes::foo]]|,
since I think we want to maintain some backwards compatibility
with Rcpp's attributes.

How should we handle multiple attributes for a single function? Eg.

// [[Rcpp::export, attributes::register]]
int foo() { ... }

A hiccup there is that it's not interpretable as R code unless we
split on ", " (but we might have to be careful for things like the
following):

// [[foo::bar("one", "two"), attributes::foo]]
...

I guess we would split on something like |(,\s+)\w+::|.

—
Reply to this email directly or view it on GitHub
#3 (comment).

[romainfrancois]

We use parse( text = ) on whatever is between [[ and ]] so we could separate attributes with ;

If we start to have more attributes, perhaps we can have multi line comments, e.g

/* [[
export
register
]] */

Envoyé de mon iPhone

Le 5 mars 2014 à 00:27, johnmchambers notifications@github.com a écrit :

(Coming at this from an outsider's view, of course.)

How do you want to regard the basic "// [[ expression ]]" syntax? If you
want to think of it as mapping into an R expression the most basic would
map "expression" into just that. In that case multiple attributes could
be "{expr1; expr1}".

If that seems too verbose, you could implicitly interpret "expression"
as an argument list to some implied function. If that function took ...
as its argument, you get your comma separated attributes. I.e., in
effect, parse the value of
paste0("DUMMYFUN(", expression, ")").

(This is all assuming you want some link to R syntax.)

John

On 3/4/14, 12:08 PM, Kevin Ushey wrote:

Some other ideas:

|// [[foo]]| can be interpreted as an |attributes| function, e.g.
as an alias for |// [[attributes::foo]]|. This way |attributes|
can come pre-shipped with common handlers, ie, the ones we wish to
port from |Rcpp|, and also with automatic function registration
for packages (e.g. |// [[register]]|). I have an example of that
in my 'playground' package as Kmisc::registerFunctions
https://github.com/kevinushey/Kmisc/blob/master/R/registerFunctions.R,
but it only handles the |.Call| interface.

We can translate |// [[Rcpp::foo]]| to |// [[attributes::foo]]|,
since I think we want to maintain some backwards compatibility
with Rcpp's attributes.

How should we handle multiple attributes for a single function? Eg.

// [[Rcpp::export, attributes::register]]
int foo() { ... }

A hiccup there is that it's not interpretable as R code unless we
split on ", " (but we might have to be careful for things like the
following):

// [[foo::bar("one", "two"), attributes::foo]]
...

I guess we would split on something like |(,\s+)\w+::|.

—
Reply to this email directly or view it on GitHub
#3 (comment).

—
Reply to this email directly or view it on GitHub.

[jjallaire]

I think it would be nice to stay within the spec for C++11 attributes. The
good news is that the only thing required is this the form [[]]
or [[()]] (where can actually take any syntactic
form whatsoever (so it could be R code).

J.J.

On Tue, Mar 4, 2014 at 11:33 PM, Romain François
notifications@github.comwrote:

We use parse( text = ) on whatever is between [[ and ]] so we could
separate attributes with ;

If we start to have more attributes, perhaps we can have multi line
comments, e.g

/* [[
export
register
]] */

Envoyé de mon iPhone

Le 5 mars 2014 à 00:27, johnmchambers notifications@github.com a écrit
:

(Coming at this from an outsider's view, of course.)

How do you want to regard the basic "// [[ expression ]]" syntax? If you
want to think of it as mapping into an R expression the most basic would
map "expression" into just that. In that case multiple attributes could
be "{expr1; expr1}".

If that seems too verbose, you could implicitly interpret "expression"
as an argument list to some implied function. If that function took ...
as its argument, you get your comma separated attributes. I.e., in
effect, parse the value of
paste0("DUMMYFUN(", expression, ")").

(This is all assuming you want some link to R syntax.)

John

On 3/4/14, 12:08 PM, Kevin Ushey wrote:

Some other ideas:

|// [[foo]]| can be interpreted as an |attributes| function, e.g.
as an alias for |// [[attributes::foo]]|. This way |attributes|
can come pre-shipped with common handlers, ie, the ones we wish to
port from |Rcpp|, and also with automatic function registration
for packages (e.g. |// [[register]]|). I have an example of that
in my 'playground' package as Kmisc::registerFunctions
https://github.com/kevinushey/Kmisc/blob/master/R/registerFunctions.R,

but it only handles the |.Call| interface.

We can translate |// [[Rcpp::foo]]| to |// [[attributes::foo]]|,
since I think we want to maintain some backwards compatibility
with Rcpp's attributes.

How should we handle multiple attributes for a single function? Eg.

// [[Rcpp::export, attributes::register]]
int foo() { ... }

A hiccup there is that it's not interpretable as R code unless we
split on ", " (but we might have to be careful for things like the
following):

// [[foo::bar("one", "two"), attributes::foo]]
...

I guess we would split on something like |(,\s+)\w+::|.

Reply to this email directly or view it on GitHub
#3 (comment).

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-36716945
.