i am studying scala and have been trying to learn as much as i can. After reading the scala programming book i am reading the source code of several projects while trying some examples myself.
I am really struggling to understand what this method does. I understand that this defines a Json value such as type : value or something.
And also it expects a parametrized T that is a subtype of Product (<:), the way it uses the hashtags is completely magic to me. I cannot fathom its meaning.
def jsonFormat1[[#P1 :JF#], T <: Product :ClassManifest](construct: ([#P1#]) => T): RootJsonFormat[T] = {
val Array([#p1#]) = extractFieldNames(classManifest[T])
jsonFormat(construct, [#p1#])
}
Here is the Full Source for the trait, you might need it to fully understand
PS: This example is taken from project spray-json.
Related
I am new to scala and trying to support an application written in scala using ciris package.
I want to understand the is ciris ConfigDecoder and what the below code is trying to do.
#inline implicit def sourceTopicsConfigDecoder(implicit ev: ConfigDecoder[String, NonEmptyString]): ConfigDecoder[String, SourceTopics] =
ev.map(_.value.split(",").toSet.map(NonEmptyString.unsafeFrom)) map SourceTopics.apply
#inline implicit val sourceTopicsShow: Show[SourceTopics] =
_.unMk.mkString(",")
I've never used (or even heard of) Ciris before, but a quick visit to the documentation informs me that ConfigDecoder is the means by which the received configuration type (usually a String) is cast to a more useful type. Something like: env("SIZE_LIMIT").as[Long]
I also learned that, while many useful ConfigDecoders are supplied, you can also make your own for decoding configuration values into application specific types, and that's what sourceTopicsConfigDecoder appears to be doing. It pulls an existing String-to-NonEmptyString decoder from the implicit scope and uses it to build a String-to-SourceTopics decoder. (SourceTopics must be previously defined.)
The new decoder is made implicit so that elsewhere in the code you can do something like: env("SRC_TOPICS").as[SourceTopics]
I am really struggling a lot to understand this line of code. can someone please explain in detail?
def sequence[A](aos: List[Option[A]]): Option[List[A]] =
aos.foldRight[Option[List[A]]](Some(Nil))((a,acc) => map2(a,acc)(_ :: _))
It is hard to explain with only a small piece of code, but I'll give it a try.
Explanation: That function is trying to implement a sequence operation on List[Option[A]]. This operation is really common in FP (I recommend you look at a general implementation found in cats. In general it converts type F[G[A]] to G[F[A]], in your example it specifically converts List[Option[A]] to a Option[List[A]].
Update: You have to specify Option[List[A]] to make sure the compiler will infer the correct type. Due to how ADTs are implemented in Scala, if you don't specify the return type the compiler will infer Some[List[Nothing]] as your return type.
Sometimes one might want to declare x to be of the same type as y. With vals type inference handles this very well, but this does not work in some other areas, like with function types.
A solution which seems obvious to a programmer with some C++ experience would be a decltype. No such facility seems to be present in current Scala.
An answer to the linked questions tells:
because types are not first class citizens
I have to admit I do not understand this. I do not think types are a first class citizens in C++, but still it can have the decltype. I am not asking about anything like decltype for type parameters in generics or anything like that (I understand generics are not templates and the types are erased in them). Still, I think an operator which would allow me to use a type of an expression in a place where a type is expected - certainly the compiler must be able to evaluate an expression type, otherwise type inference for val definition would not be possible.
A decltype could be used like below - the code is not trying to do anything anything useful, just to illustrate the syntax and basic usage:
case class A(x:Int = 0)
val a = new A(10)
val b = new decltype(a)
def f(c:decltype(a)) : decltype(a.x+a.x)
Is absence of decltype a deliberate decision, or are there some specific reasons why Scala cannot have it? Is there perhaps some solution using compile time reflection which would allow this?
My first stab:
class Decl[T] { type Type = T }
object Decl { def apply[T](x: T) = new Decl[T] }
For example, if we have some variable x whose type we don't want to state explicitly:
val d = Decl(x)
type TypeOfX = d.Type
Currently, I am learning generic or meta programming in Shapeless. I am facinated about the feature which can check the logic during compilation instead of runtime. There are 2 amazing examples:
1. Checksum: https://gist.github.com/travisbrown/3763016
2. TowersOfHanoi: https://gist.github.com/jrudolph/66925
However, I think those 2 examples thrust me so quickly into the deeper areas of this feature. Only I know so far is some tricks as follow:
1: define the context bound to use implicit to make sure class has correct constraint. I think that is reason we have to lift some primitive types into class type like int, so compiler know what type is (I am not sure about my argument). Code:
object bla {
implicitly[A <:< B]
}
2: using macros.
Are there other magic tricks to fulfill that ?
Many thanks in advance
We are pretty familiar with implicits in Scala for now, but macros are pretty undiscovered area (at least for me) and, despite the presence of some great articles by Eugene Burmako, it is still not an easy material to just dive in.
In this particular question I'd like to find out if there is a possibility to achieve the analogous to the following code functionality using just macros:
implicit class Nonsense(val s: String) {
def ##(i:Int) = s.charAt(i)
}
So "asd" ## 0 will return 'a', for example. Can I implement macros that use infix notation? The reason to this is I'm writing a DSL for some already existing project and implicits allow making the API clear and concise, but whenever I write a new implicit class, I feel like introducing a new speed-reducing factor. And yes, I do know about value classes and stuff, I just think it would be really great if my DSL transformed into the underlying library API calls during compilation rather than in runtime.
TL;DR: can I replace implicits with macros while not changing the API? Can I write macros in infix form? Is there something even more suitable for this case? Is the trouble worth it?
UPD. To those advocating the value classes: in my case I have a little more than just a simple wrapper - they are often stacked. For example, I have an implicit class that takes some parameters, returns a lambda wrapping this parameters (i.e. partial function), and the second implicit class that is made specifically for wrapping this type of functions. I can achieve something like this:
a --> x ==> b
where first class wraps a and adds --> method, and the second one wraps the return type of a --> x and defines ==>(b). Plus it may really be the case when user creates considerable amount of objects in this fashion. I just don't know if this will be efficient, so if you could tell me that value classes cover this case - I'd be really glad to know that.
Back in the day (2.10.0-RC1) I had trouble using implicit classes for macros (sorry, I don't recollect why exactly) but the solution was to use:
an implicit def macro to convert to a class
define the infix operator as a def macro in that class
So something like the following might work for you:
implicit def toNonsense(s:String): Nonsense = macro ...
...
class Nonsense(...){
...
def ##(...):... = macro ...
...
}
That was pretty painful to implement. That being said, macro have become easier to implement since.
If you want to check what I did, because I'm not sure that applies to what you want to do, refer to this excerpt of my code (non-idiomatic style).
I won't address the relevance of that here, as it's been commented by others.