Macro contexts in Scala come with two handy methods: reifyType and reifyTree which essentially generate code that, when executed at runtime, will return the Type or Tree being reified.
I wonder if there is some way to achieve something similar with Symbols - some kind of reifySymbol method?
We didn't implement reifySymbol yet, but it might be decently emulated by wrapping a symbol in an Ident and then reifying the resulting tree. Pull requests are welcome as well :)
Related
I am writing a macro to get the enclosing val/var definition. I can get the enclosing val/var symbol, but I can not get the defining tree. One solution here suggested using enclosingClass:
https://stackoverflow.com/a/18451114/11989864
But all the enclosing-tree style API is deprecated:
https://www.scala-lang.org/api/2.13.0/scala-reflect/scala/reflect/macros/blackbox/Context.html
Is there a way to implement the functionality of enclosingClass? Or to get a tree from a symbol?
Reasons for deprecation are
Starting from Scala 2.11.0, the APIs to get the trees enclosing by
the current macro application are deprecated, and the reasons for that
are two-fold. Firstly, we would like to move towards the philosophy of
locally-expanded macros, as it has proven to be important for
understanding of code. Secondly, within the current architecture of
scalac, we are unable to have c.enclosingTree-style APIs working
robustly. Required changes to the typechecker would greatly exceed the
effort that we would like to expend on this feature given the
existence of more pressing concerns at the moment. This is somewhat
aligned with the overall evolution of macros during the 2.11
development cycle, where we played with c.introduceTopLevel and
c.introduceMember, but at the end of the day decided to reject them.
If you're relying on the now deprecated APIs, consider using the new
c.internal.enclosingOwner method that can be used to obtain the names
of enclosing definitions. Alternatively try reformulating your macros
in terms of completely local expansion...
https://www.scala-lang.org/api/2.13.0/scala-reflect/scala/reflect/macros/Enclosures.html
Regarding getting a tree from a symbol
there's no standard way to go from a symbol to a defining tree
https://stackoverflow.com/a/13768595/5249621
Why do you need def macro to get the enclosing val/var definition?
Maybe macro annotatations can be enough
https://docs.scala-lang.org/overviews/macros/annotations.html
I have a relatively large Scala code base that does not use named parameters for any function/class calls. Rather than going in and manually entering it, which would be a very tedious process, I was looking at a formatter to do the job. The best I found is scalariform, but I'm not sure whether I can even write a rule for something so complex.
I'm curious if anyone has ran into a similar problem and found a powerful formatter.
The Scala Refactoring library might be something you could use. You will need some knowledge of Scala's Abstract Syntax Tree representation.
Why do you want to use named parameters throughout your code base? I like IntelliJ's default which is to suggest to name boolean arguments (only).
I'd really like to use case classes' copy feature in my project, but unfortunately I also need inheritance, which doesn't work well with case classes. So, I'm wondering if it's possible to write a macro which will generate a method for creating copy-with-changes object for an arbitrary class. What stops me there at the moment is the fact that AFAIK macros don't support named parameters. Has anyone found a way around that or, alternatively, can suggest other way for easy creating of copies which use inheritance?
That will be possible with type macros and/or annotation macros. The current macros do not support this.
Do look at lenses work, though. There's quite a few macro-based versions around, such as Shapeless.
You could also take a look at https://github.com/dicarlo2/ScalaEquals
When I return something of type Option, it seems useful to explain in the name of the function name that it is an option, not the thing itself. For example, seqs have reduceOption. Is there a standard naming convention? Things I have seen:
maybeFunctionName
functionNameOption
- neither seems to be all that great.
reduceOption and friends (headOption, etc.) are only named that way to distinguish them from their unsafe alternatives (which arguably shouldn't exist in the first place—i.e, there should just be a head that returns an Option[A]).
whateverOption isn't the usual practice in the standard library (or most other Scala libraries that I'm aware of), and in general you shouldn't need or want to use this kind of Hungarian notation in Scala.
Why would you want to make your function names longer? It doesn't contribute anything, as the fact that it returns an Option is obvious when looking at the function's type.
reduceOption is sort of a special case, since in most cases you really want to use reduce, except that it doesn't work on empty sequences.
In limited sense it is very easy to write out and ref classes on your own, but my question is not how to do it -- but are there some features (or classes) ready to use?
The closest thing I found is Reference trait (but it is a trait).
I need those, not tuple, not Option, and not Either as pure result, because only ref/out makes chaining ifs elegant.
No, Scala supports parameter passing by value or by name. Parameter passing by reference is actually quite difficult to accomplish correctly in the JVM, which is probably one reason why none of the popular JVM languages have it. Additionally, out and ref parameters encourage programming via side-effect, something the at design of Scala attempts to avoid wherever possible.
As for chaining of if's, there are a variety of ways to achieve some effects like that in Scala. "match" expressions are the most obvious, and you might also look into monadic compositions using Option or Either.