New beta of macros

148 views
Skip to first unread message

Eugene Burmako

unread,
Apr 3, 2012, 7:25:36 PM4/3/12
to <scala-sips@googlegroups.com>
Hi folks,

I've just pushed a several weeks worth of work to https://github.com/scalamacros/kepler/commits/develop

This update features:
1) major additions to reflection and macro context APIs (positions, toolboxes with customizable settings and reporters, more powerful typechecking, programmable caches for macro expansions, error reporting, ability to inspect enclosing compilation units, current compilation runs and read/write access to compilation settings),   
2) implicit generation of typetags (by writing [T: TypeTag] you now get an implicit Type generated for you),
3) v2 of the reifier (core has been rewritten, now fully supports local definitions, nested reifications, cross-stage bindings, captures free types along with free terms),
4) transparent interaction with type inference (previously, in certain situations macros could be invoked upon arguments of non-inferred types, now this works correctly),
5) and a multitude of bugfixes. 

Not yet implemented:
1) migration from manifests to typetags (see updated SIP for the details),
2) typetags for complex types such as refinements and annotateds,
3) macro expansions with named and default arguments,
4) context hierarchy (for fine-grained control over macro power).

All the tests pass, so it should be safe to update and rebuild. I would be very grateful if you could test your experimental macro-thingies with the new build. If something goes wrong, please, drop me an email, and if something goes very wrong you can do "git reset HEAD~1 --hard" (downgrade to v1) or "git checkout scalamacros/kepler/stable" (downgrade to v1.5).

Cheers,
Eugene

Paul Phillips

unread,
Apr 3, 2012, 8:33:59 PM4/3/12
to scala...@googlegroups.com
So this commit will be stable right? I have a metric ton of work on symbols which is in good shape with everything except the reifier in trunk. It would be a great boon to be able to kick that aside and worry only about this branch.

Eugene Burmako

unread,
Apr 4, 2012, 3:56:00 AM4/4/12
to scala...@googlegroups.com
API-wise it's stable - I've added everything I wanted to reflection/context. However, the branch is still based on a month-ago trunk, which begs for a rebase that I'm planning to do after the manifest migration.

By the way, it'd be great if you could review reflection and macro context APIs. They work fine w.r.t exposing necessary features for macro writers, but the consistency and user-friendliness could definitely be improved.

Paul Phillips

unread,
Apr 4, 2012, 9:58:07 AM4/4/12
to scala...@googlegroups.com
On Wed, Apr 4, 2012 at 12:56 AM, Eugene Burmako <eugene....@epfl.ch> wrote:
> API-wise it's stable - I've added everything I wanted to reflection/context.
> However, the branch is still based on a month-ago trunk, which begs for a
> rebase that I'm planning to do after the manifest migration.

When I ask "is it stable" I'm asking if the commit will stay in the
history. When you say "rebase" you're saying no. It would be much,
much better if you would not rebase it.

Eugene Burmako

unread,
Apr 4, 2012, 10:42:42 AM4/4/12
to scala...@googlegroups.com
Well, I think that I still need to pull from trunk before you do any changes, because it's been a while since scalamacros/kepler/develop has been forked.

So even if I don't rebase, state of the art isn't very useful to you, as far as I understand. Right?

Paul Phillips

unread,
Apr 4, 2012, 12:01:53 PM4/4/12
to scala...@googlegroups.com
On Wed, Apr 4, 2012 at 7:42 AM, Eugene Burmako <eugene....@epfl.ch> wrote:
> Well, I think that I still need to pull from trunk before you do any
> changes, because it's been a while since scalamacros/kepler/develop has been
> forked.

As long as you don't rebase it doesn't make any difference. Merge
master into your branch, don't rebase.

> So even if I don't rebase, state of the art isn't very useful to you, as far
> as I understand. Right?

It is very useful if this commit will remain in the history of the work.

The difficulty of merging more than one person's work is proportional
to the distance to their common point of reference. If this commit is
stable, then that point of reference is this commit. If you rebase,
it is "never" since my work would then be based on a commit which is
not in your history.

Reply all
Reply to author
Forward
0 new messages