nteetor / tinsel Goto Github PK

• simple example
• consecutive decorators
• test coverage

Within the parser class, the expected() function returns a token if the token was expected, otherwise an error is thrown.

Within scanner expected() was removed from the traversal class, is now part of the scanner class, and behaves similarly to the parser expected function. However, the methods of scanner do not currently utilize the return value of expected(). Reviewing and refactoring scanner to utilize the return value of expected could prove useful.

The current grammar used by the parser does not handle multiple decorators well, if at all.

Create class to represent the nodes of the parse tree.

You might want to create a vignette and/or modify your description to make it more obvious that decorators operate on source files rather than say in an interactive session. Can tinsel be used in package authorship or is it just for files you would directly source?

When parsing variable names one might safely assume "^\\s*[^ ]+" could do the trick.

However, if a variable is assigned to ` (yep)` or `white space` the regular expression above will fail to parse correctly. I want to believe white space would not get used in a variable name, but the possibility exists.

The problem will not be addressed until numerous complaints flood in.

I tried to use this library in a Shiny environment but is quite complex to integrate the current special comments syntax.

Have a look to this:
https://github.com/klmr/decorator

Maybe it would be great to have both options in only one library.

Another but much more complex solution is to make an environment aware of decorated functions like in data.table. Have no idea how to start this.

• string literals
• numeric literals
• negative numeric literals
• arguments to decorators
• assignments

add test coverage for #6

The initial release of tinsel (0.0.1), source_decoratees expects decorators to be defined in the same file as their decoratee. Allowing decorators to live in a separate file would be beneficial for the programmer and would allow flexible file organization.

In python one can import a decorator buzz like so,

import bazz

@bazz.buzz
class fizz:
    pass

If we consider using something of this fashion for tinsel the following operators are already used for a similar, but not indentical, task: ::, :::. Using :::: seems excessive: #. bazz::::buzz. Note that there would not be an import bazz equivalent. One could already work around this definition issue using source if they felt inclined to do so.

Is there an alternative symbol we could use?

If a connection object is passed to source_decoratees and the connection text references a decorator found in a separate file an error occurs,

source_decoratees(
  textConnection("
    #. fizz$bar
    example <- function() 'minimal'
  ")
)

The immediate error is a result of passing a connection object to dirname(), a character string is expected. The larger issue is connection objects have no information regarding file location. In general they would not need to, but in the case of the new source selection addin the text connection is from a specific file and we need to know which file.

• scanner (see #9)
• parser (see #13)
• generator

1. What are best practices for documenting decorated functions?

   • How do other languages handle documenting decorated functions?

2. How to double check documented decorators against actual function decorators?

   • Add roxygen tag?