Functionality of Treehugger

[Eric Christiansen]

Hey, it's a bit unclear to me, just having skimmed the docs, what Treehugger can and can't do:

1) Can Treehugger evaluate the trees it creates? If so, it should be example code, augmenting the code here. If not, it's confusing to say "treehugger.scala is a library to code Scala programmatically", because that makes me think it's a metaprogramming library.

2) Does Treehugger generate code dynamically or at compile-time? Eg, could I use it to rewrite my code before it's compiled?

Thanks.

[eugene yokota]

Hi Eric,

On Sun, Nov 4, 2012 at 6:26 PM, Eric Christiansen
<ericmartinc...@gmail.com> wrote:
> Hey, it's a bit unclear to me, just having skimmed the docs, what Treehugger
> can and can't do:
>
> 1) Can Treehugger evaluate the trees it creates? If so, it should be example
> code, augmenting the code here.

No, treehugger doesn't evaluate the tree. The evaluation should be
handled by Scala, or other libraries.

> If not, it's confusing to say
> "treehugger.scala is a library to code Scala programmatically", because that
> makes me think it's a metaprogramming library.

It's a code generation library. If someone wants to call that staging
or metaprogramming, it is, but treehugger is not macro.

> 2) Does Treehugger generate code dynamically or at compile-time? Eg, could I
> use it to rewrite my code before it's compiled?

At the moment treehugger supports only runtime generation, which you
can integrate into the build process using sbt.
If you want AST transformation of your Scala code, that's what Scala
2.10's macro does. I have an experimental subproject of treehugger
called trehugger-bridge. Using that I was able to port Scala Macro's
"getting started" example to treehugger:
https://github.com/eed3si9n/scalamacros-getting-started/blob/treehugger/library/Macros.scala

There I convert Scalac tree given by macro to treehugger tree,
manipulate it, and then convert it back to Scalac tree. It seems like
too much work to implement complete conversion, so treehugger-bridge
will remain experimental until I need it myself, or someone else want
to give it a shot.

Hope this helps.

-eugene

[Julian Peeters]

At the moment treehugger supports only runtime generation, which you 
can integrate into the build process using sbt. 

Hi,

 

Forgive an ignorant question, but what are the benefits of the Treehugger DSL over generating code by simply printing strings directly? 

Thanks,

Julian

[eugene yokota]

Hi Julian,

On Mon, Aug 5, 2013 at 4:51 PM, Julian Peeters <julian...@gmail.com> wrote:

At the moment treehugger supports only runtime generation, which you 
can integrate into the build process using sbt. 

 what are the benefits of the Treehugger DSL over generating code by simply printing strings directly? 

I wrote treehugger since writing String-based code generating in scalaxb was getting messy.

I later found out that jaxb guys did something similar: http://codemodel.java.net/

The benefits are similar to those of using any case class structure over manipulating raw String.

Instead of String, with treehugger you first build trees. 

For some small code generation, using String could be sufficient, but it's gets messy if you want to incorporate

user data to generate code etc.

treehugger gives you a way to organize the code with types, and it provides better type safety to the code generating code.

The type safety of the generated code is somewhat arguable since both String and treehugger can generate bad code,

but generally treehugger should prevent certain class of bad code like unmatching parens.

Also, since you deal with pure trees, you let treehugger worry about layout issues like indentation.

-eugene

[Julian Peeters]

Wonderful answer, thanks.