float: left; background-image: radial-gradient(red, blue);
case class Thing(s: String){def :=(t: Thing) = s + ": " + t.s}val float = Thing("float")val left = Thing("left")val backgroundImage = Thing("background-image")def radialGradient(s: String) = Thing(s"radialGradient($s)")val red = Thing("red")val blue = Thing("red")float:=leftbackgroundImage:=radialGradient(red, blue)
case class Thing(s: String){def :=(t: Thing) = s + ": " + t.s}val float = Thing("float")object Float{val left = Thing("left")}val backgroundImage = Thing("background-image")object Image{def radialGradient(s: String) = Thing(s"radialGradient($s)")}object Color{val red = Thing("red")val blue = Thing("red")}float:=Float.leftbackgroundImage:=Image.radialGradient(Color.red, Color.blue)
case class Thing(s: String){def :=(t: Thing) = s + ": " + t.s}object float extends Thing("float"){val left = this := Thing("left")}val backgroundImage = Thing("background-image")object Image{def radialGradient(s: Thing*) = Thing(s"radialGradient(${s.mkString(',')})")}object Color{val red = Thing("red")val blue = Thing("red")}float.leftbackgroundImage.radialGradient(Color.red, Color.blue)
case class Thing[T](s: String){def :=(t: T => Thing) = s + ": " + t.s}val float = Thing[Float]("float")object Float{val left = this := Thing("left")}val backgroundImage = Thing[Image]("background-image")object Image{def radialGradient(s: Thing*) = Thing[Color](s"radialGradient($s)")}object Color{val red = Thing("red")val blue = Thing("red")}float:=(_.left)backgroundImage:=(_.radialGradient(_.red, _.blue))
float:=leftbackgroundImage:=radialGradient(red, blue)
object Src{val stuff}func(thunk: @binds[Src.type] => T) = {... thunk(Src) ... // thunk itself has a type Src.type => T}// but at the callsite, does some magic, like magic stuff// scoped lexically to that argumentfunc("" + stuff)// because it basically desugars intofunc({ $src =>import $src._"" + stuff})
// this desugaring would allow fully-qualified// names too, as well as external namesfunc("" + Src.stuff)
For example:
Events.loop[B] { self =>val es = loopUntil(outer) {self << (self await inner)self.pause}inner = isEvents(es)}
Events.loop[B] {val es = loopUntil(outer) {<< (await inner)pause}inner = isEvents(es)}
--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Has anyone else ever needed/wanted something like this? I remember reading an something from martin a while ago (http://www.infoq.com/news/2012/07/scala-macros), when macros were first announced, saying that he hoped that they would solve this use case.
CD._instances -> _sort(Artist) -> _bulleted
div(backgroundColor:=hex"ababab") div(color:=rgb(0, 255, 255)) div(color.red)
--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
> And if the `apply` method which I've overloaded 334 times doesn't make you feel queasy, nothing will..I've tried and failed to understand the code, but would love to hear more about how that works =)
» And if the `apply` method which I've overloaded 334 times doesn't make you feel queasy, nothing will...Jon, this would make an epic signature!
In many cases, numerous (sometimes literally hundreds) of overloaded `apply` methods are included to support all variations on the ways CSS offers to specify the values of that particular property. Types (*lots* of types) and instances of those types are provided to ensure that you can't use a value which doesn't make sense for a particular property. If I remember correctly, this does a reasonably complete job of representing all styles, except possibly some lesser-used CSS3 styles which I never got round to finishing.
an email to scala-debate+unsubscribe@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
Great idea! I've been long considering something similar for macros, but it is indeed applicable more widely.
Isn't there something like a CSS spec which could be used by a type macro to generate the actual code from it? :-)
--
You received this message because you are subscribed to a topic in the Google Groups "scala-debate" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-debate/f4CLmYShX6Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-debate...@googlegroups.com.
To reply to Jon's factual questions:
Adriaan, Jason, Greg, what do you think about this discussion?The problem outlined by the OP does exist, and its manifestations are plentiful. The solutions discussed here look quite interesting and seem to generalize well beyond the original use case. Do you think that's something that Scala would benefit from? What would be our next step here?
Hi Haoyi, Eugene et al,
On Wednesday, 8 January 2014 10:26:42 UTC, Eugene Burmako wrote:Great idea! I've been long considering something similar for macros, but it is indeed applicable more widely.
I proposed something similar to Haoyi's small, "small local scope" idea ages ago. I tried to find it on the Gmane archives, but all I could find was this other idea for implicits I had, almost seven years ago... ;)
http://thread.gmane.org/gmane.comp.lang.scala/3455
...but that was when ideas were cheap and implementations were less so.
I read various discussions on SAM a while ago, but I feel like I've missed a definitive conclusion wrt the SAM implementation, so hopefully someone can fill in the blanks for me, in particular:
1. Is the SAM implementation in a (pre-)release build somewhere where I can try it out?
2. Do I need to enable any flags to use it (e.g. -Xexperimental)?
3. What was the final decision on accessing class members within a SAM definition?
So this is in fact a similar proposal, but is rewritten like this:decl-site || def f(a: A witnessing implicit x: X) → def f(xa: X ⇒ A), a = xa(x)use-site || f(a) → f(implicit x ⇒ a)It also bears some similarity to the existing “⇒ A” sugar:decl-site || def f(a: ⇒ A) → def f(ѳa: () ⇒ A), a = ѳa()use-site || f(a) → f(() ⇒ a)With that in mind, here’s another take on it:decl-site || def f(a: (x: X = foo) ⇒ A) → def f(xa: X ⇒ A), a = xa(foo)use-site || f(a) → f(implicit x ⇒ a)
This would basically reify the concept of an Enum in the type system: I could specify a function that takes a value that is no longer just of a type, but which is assumed to come from a specified container object, and in doing so remove the boilerplate of declaring "where" those values come from.
I feel this is a need that spans beyond just CSS DSLs. Spray, for example, documents its HTTP API as follows:For example:
- The defined HttpMethod instances live in the HttpMethods object.
- The defined HttpCharset instances live in the HttpCharsets object.
- The defined HttpEncoding instances live in the HttpEncodings object.
- ...
with either importing everything into the local namespace (i.e. Solution 1 above) or not (Solution 2). That sort of API could also benefit from the @binds annotation shown about, which would provide both short names *and* no-namespace-pollution by streamlining the intended use case: You want the parameter to only take a member of a type, whose members only live in one object.
Hi,
I like the import syntax very much! Excellent idea. And nice summary and unification of the two proposals, even if I feel uneasy about deprecating => A.
Cheers,
Sébastien
--
You received this message because you are subscribed to a topic in the Google Groups "scala-debate" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-debate/f4CLmYShX6Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-debate...@googlegroups.com.
One more thing I don’t like is that by-name values are not representable on their own.
def f(g: => (Int => Int)) = g(5)I would call it withf(x => x+1)
If I now define f as
f(g: () => (Int => Int)) = g()(5)it would still kind of work, but you start to feel the issue.
The former is the meaning it has with current Scala. The latter would be a possible meaning with the automatic conversion of A into () => A. And now we have an ambiguity.
I'm not sure auto-implicit and auto-import values would not be any more representable.
I am not sure I see what’s wrong with this (besides explicit `()`).
The former is the meaning it has with current Scala. The latter would be a possible meaning with the automatic conversion of A into () => A. And now we have an ambiguity.That’s a good point. I was expecting there would be caveats :)However, I believe that can be easily solved. `A` does not equal `() ⇒ A`. It is only forcefully converted, when `() ⇒ A` type is expected. Inference remains as it was.To draw an analogy with numeric conversions (which are being killed, but for other reasons), in `def f[A](x: A) = 1; f(1)` `A` is `Int` and not e.g. `Long`.
There is another problem, however:def f(a: () ⇒ Any) = 9f(() ⇒ 1) // is it f(() ⇒ 1) or f(() ⇒ () ⇒ 1)?Not sure what to do with this one.
I'm not sure auto-implicit and auto-import values would not be any more representable.The thing is, `[ ⇒ A]` does not exists, so `[() ⇒ A]` has to be used. However, you cannot simply supply `() ⇒ A` to `⇒ A`. So once you need to pass a thunk around,you have to quit using `⇒ A` in all places anyway.
`(implicit X) ⇒ A` and `(import X) ⇒ A` are compatible with `X ⇒ A`.
I would apply the same reasoning as you did above: convert only if needed. Hence it would mean f(() => 1) since it typechecks.
Not necessarily. You can "convert" an `x` of type `() => A` into a `=> A` by writing `x()`. Conversely, you can "convert" a `=> A` into a `() => A` by writing `() => x`.
--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
2) The declaration syntax seems noisy to me, and => is already overloaded in many people's minds. What about "def foo(bar: Bar, import baz: Baz)"? It wouldn't help with implicits though.
This proposal does not overload the meaning of =>: such parameters would indeed be functions, and in particular, within the defining method, they would be used exactly as function values, without any "magic". If at all, it overloads the meaning of import and implicit.
I made it work for primitives (Int @Implicit => X), but then it turned out the annotation was not preserved the same way for ref types. Sadly, now I'm loaded with other stuff too :( Hopefully, I'll have some time to go further in about 1.5 weeks. You can look for details here: https://github.com/dsl-paradise/dsl-paradise/issues/9
Nick