Hi Doug,
Many people have wished for nicer syntax for specifying Byte and Short
literals (I know I have). And I don't think the relevant changes to the
compiler are that hard--I'm confident that I or someone else could
create a patch to add them.
But the last time that I remember someone (Paul Phillips) bringing up a
new literal syntax for Byte/Short Martin was strongly against it. See
this email thread:
http://thread.gmane.org/gmane.comp.lang.scala.internals/1858/focus=1867
I'm not saying you shouldn't push for this, but be aware that it has
been discussed before.
-- Erik
P.S. If anyone wants to chime in about how nice a literal syntax for
Byte/Short would be, and/or how much the current numeric coercions
suck, please feel free. :)
But the last time that I remember someone (Paul Phillips) bringing up a
new literal syntax for Byte/Short Martin was strongly against it.
I'm not sure it this is the right list to be posting to but I found myself this evening hankering for a byte literal in scala that didn't need type hints to tell the compiler I want a byte, i.e.val b: Byte = 1
I wanted to get some thoughts appending to section 1.3.1 of http://www.scala-lang.org/docu/files/ScalaReference.pdf (Numeric literals) with a new literal specifically for bytes.
I don't think I have britches big enough to fork scala and try this myself yet, but I wanted to get some commentary from the list on the general idea first.
On Wed, Dec 28, 2011 at 8:22 PM, Doug Tangren <d.ta...@gmail.com> wrote:I'm not sure it this is the right list to be posting to but I found myself this evening hankering for a byte literal in scala that didn't need type hints to tell the compiler I want a byte, i.e.val b: Byte = 1One thing you can do is:scala> def b(x: Byte): Byte = xb: (x: Byte)Bytescala> val b0 = b(55)b0: Byte = 55
Similarly, you can (ab)use implicits to get something a bit closer to
the 13b syntax with:
scala> implicit def xyz(i:Int) = new { def b = i.toByte; def s = i.toShort }
xyz: (i: Int)java.lang.Object{def b: Byte; def s: Short}
scala> (1.b, 2.s, 3)
res0: (Byte, Short, Int) = (1,2,3)
If you don't sweat the implicits or the object allocations then this
almost starts to look nice...
-- Erik
scala> implicit def xyz(i:Int) = new { def b = i.toByte; def s = i.toShort }
xyz: (i: Int)java.lang.Object{def b: Byte; def s: Short}
Would it be overkill to go through the sip processes [1]?
What is wrong with x.asInstanceOf[Byte]?
On Fri, Dec 30, 2011 at 2:04 PM, Jack Viers <jack....@t8webware.com> wrote:What is wrong with x.asInstanceOf[Byte]?
Casting in Scala is like cursing in Church. ;-)
scala> 5.asInstanceOf[Long] res0: Long = 5 scala> (5: AnyVal).asInstanceOf[Long] java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long at scala.runtime.BoxesRunTime.unboxToLong(Unknown Source) at .<init>(<console>:8)
scala> class A1 { def f[T <: Int](x: T) = x.toLong } defined class A1 scala> class A2 { def f[T <: Int](x: T) = x.asInstanceOf[Long] } defined class A2 scala> (new A1) f 5 res1: Long = 5 scala> (new A2) f 5 java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long at scala.runtime.BoxesRunTime.unboxToLong(Unknown Source) scala> class A3[T] { def f(x: T) = x.asInstanceOf[Long] } defined class A3 scala> class A4[@specialized T] { def f(x: T) = x.asInstanceOf[Long] } defined class A4 scala> (new A3[Int]) f 5 java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long at scala.runtime.BoxesRunTime.unboxToLong(Unknown Source)scala> (new A4[Int]) f 5 res1: Long = 5
2011/12/30 √iktor Ҡlang <viktor...@gmail.com>On Fri, Dec 30, 2011 at 2:04 PM, Jack Viers <jack....@t8webware.com> wrote:What is wrong with x.asInstanceOf[Byte]?
Casting in Scala is like cursing in Church. ;-)asInstanceOf on primitives doesn't even rise to the level of cursing in church.
Hi Jon,
In my view, there are no conceptual obstacles to allowing multiple
levels of quasiquotes (just a few days ago we had a discussion about
multi-level code quasiquotes). However, there are some syntactic trade-
offs to be made.
Basically there are two design options w.r.t. nesting: 1) allow nested
quotes in single-line quotes (e.g. s"foo${s"bar"}"), 2) only allow
nested quotes in multi-line quotes (e.g. s"""foo${s"bar"}"""). The
latter is more in line with the look of vanilla string literals,
however the former supports arbitrary levels of nesting.
At the moment sorting this out is more of a low-priority task, since
some fundamental thingies (e.g. matching against code quasiquotes)
aren't yet in place. However, nesting is definitely on my task list
(and I even wrote a unit test for that =)).