| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It’s almost 1am, so I’m only scratching the surface, mechanistically
applying the renames that I’ve written down in my notebook:
* typeSignature => info
* declarations => decls
* nme/tpnme => termNames/typeNames
* paramss => paramLists
* allOverriddenSymbols => overrides
Some explanation is in order so that I don’t get crucified :)
1) No information loss happens when abbreviating `typeSignature` and `declarations`.
We already have contractions in a number of our public APIs (e.g. `typeParams`),
and I think it’s fine to shorten words as long as people can understand
the shortened versions without a background in scalac.
2) I agree with Simon that `nme` and `tpnme` are cryptic. I think it would
be thoughtful of us to provide newcomers with better names. To offset
the increase in mouthfulness, I’ve moved `MethodSymbol.isConstructor`
to `Symbol.isConstructor`, which covers the most popular use case for nme’s.
3) I also agree that putting `paramss` is a lot to ask of our users.
The double-“s” convention is very neat, but let’s admit that it’s just
weird for the newcomers. I think `paramLists` is a good compromise here.
4) `allOverriddenSymbols` is my personal complaint. I think it’s a mouthful
and a shorter name would be a much better fit for the public API.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reflection API exhibits a tension inherent to experimental things:
on the one hand we want it to grow into a beautiful and robust API,
but on the other hand we have to deal with immaturity of underlying mechanisms
by providing not very pretty solutions to enable important use cases.
In Scala 2.10, which was our first stab at reflection API, we didn't
have a systematic approach to dealing with this tension, sometimes exposing
too much of internals (e.g. Symbol.deSkolemize) and sometimes exposing
too little (e.g. there's still no facility to change owners, to do typing
transformations, etc). This resulted in certain confusion with some internal
APIs living among public ones, scaring the newcomers, and some internal APIs
only available via casting, which requires intimate knowledge of the
compiler and breaks compatibility guarantees.
This led to creation of the `internal` API module for the reflection API,
which provides advanced APIs necessary for macros that push boundaries
of the state of the art, clearly demarcating them from the more or less
straightforward rest and providing compatibility guarantees on par with
the rest of the reflection API.
This commit does break source compatibility with reflection API in 2.10,
but the next commit is going to introduce a strategy of dealing with that.
|
| |
|
|
|
|
|
|
|
|
| |
Performs the following renamings:
* scala.reflect.macros.BlackboxContext to scala.reflect.macros.blackbox.Context
* scala.reflect.macros.BlackboxMacro to scala.reflect.macros.blackbox.Macro
* scala.reflect.macros.WhiteboxContext to scala.reflect.macros.whitebox.Context
* scala.reflect.macros.WhiteboxMacro to scala.reflect.macros.whitebox.Macro
https://groups.google.com/forum/#!topic/scala-internals/MX40-dM28rk
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first commit in the series. This commit only:
1) Splits Context into BlackboxContext and WhiteboxContext
2) Splits Macro into BlackboxMacro and WhiteboxMacro
3) Introduces the isBundle property in the macro impl binding
Here we just teach the compiler that macros can now be blackbox and whitebox,
without actually imposing any restrictions on blackbox macros. These
restrictions will come in subsequent commits.
For description and documentation of the blackbox/whitebox separation
see the official macro guide at the scaladoc website:
http://docs.scala-lang.org/overviews/macros/blackbox-whitebox.html
Some infrastructure work to make evolving macros easier:
compile partest-extras with quick so they can use latest library/reflect/...
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Restrictions regarding how non-value types can be used have
generally not been enforced explicitly, depending instead on
the fact that the compiler wouldn't attempt to use them in
strange ways like offering a method type as a type argument.
Since users can now create most types from scratch, it has
become important to enforce the restrictions in a more
direct fashion.
This was a lot harder than it probably should have been
because there are so many types which go unmentioned by the
specification. Hopefully a useful exercise in any case.
|
|
|
If we're reifying non-value types (e.g. MethodTypes), we can't use them
as type arguments for TypeTag/WeakTypeTag factory methods, otherwise
the macro expansion won't typecheck:
http://groups.google.com/group/scala-internals/browse_thread/thread/2d7bb85bfcdb2e2
This situation is impossible if one uses only reify and type tags, but
c.reifyTree and c.reifyType exposes in the macro API let anyone feed
anything into the reifier.
Therefore I now check the tpe that is about to be used in TypeApply
wrapping TypeTag/WeakTypeTag factory methods and replace it with AnyTpe
if it doesn't fit.
|
