first class byte literals (no hints required)

On Wed, Dec 28, 2011 at 11:22:53PM -0500, Doug Tangren wrote:
> 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.
>
> Is having an explicit literal for bytes worth implementing or is it too
> rare of a usecase? What brought this up was defining constants in binary
> protocols, the memcache binary protocol [2] in this instance. Having a byte
> literal for these constants instead of lots of n.toByte and :Byte = ...
> typing would make my fingers happier patrons of scala's campground.

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.

But the last time that I remember someone (Paul Phillips) bringing up a
new literal syntax for Byte/Short Martin was strongly against it.

On Wed, Dec 28, 2011 at 8:54 PM, Erik Osheim <erik@plastic-idolatry.com> wrote:

But the last time that I remember someone (Paul Phillips) bringing up a
new literal syntax for Byte/Short Martin was strongly against it.

That's true, and he still would be I expect, but the context was a million miles away: at the time we were still on the crazy train of "5l != 5" and I was trying to find a way to avoid that world (such as making different numerics incomparable, which made literal syntax seem more urgent.)

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 09:02:36PM -0800, Paul Phillips wrote:
> One thing you can do is:
>
> scala> def b(x: Byte): Byte = x
> b: (x: Byte)Byte

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...

On Wed, Dec 28, 2011 at 8:22 PM, Doug Tangren <d.tangren@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 = 1

One thing you can do is:

scala> def b(x: Byte): Byte = xb: (x: Byte)Byte
scala> val b0 = b(55) b0: Byte = 55

 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 Dec 29, 12:07 pm, Todd Vierling wrote:
> On Thursday, December 29, 2011 1:12:09 AM UTC-5, softprops wrote:
>
> > Would it be overkill to go through the sip processes [1]?
>
> That would definitely be the best way to go about it.
>
> Prior art: There isn't such a syntax in jdk7 AFAIK; the latest proposal for
> byte/short literals dates to 2009 (though the gdocs link in this post still
> works):http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000905.html
>
> That said, I do find the ideal of byte/short literals a little "weird". The
> reason I actually prefer explicit type hinting is that Byte and Short types
> are somewhat strange at the JVM level compared to Int and Long. (See the
> "scala numeric meta-sip" thread over on scala-language for details.)

What is wrong with x.asInstanceOf[Byte]?

On Dec 29, 12:07 pm, Todd Vierling <t...@duh.org> wrote:
> On Thursday, December 29, 2011 1:12:09 AM UTC-5, softprops wrote:
>
> > Would it be overkill to go through the sip processes [1]?
>
> That would definitely be the best way to go about it.
>
> Prior art: There isn't such a syntax in jdk7 AFAIK; the latest proposal for
> byte/short literals dates to 2009 (though the gdocs link in this post still
> works):http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000905.html
>
> That said, I do find the ideal of byte/short literals a little "weird". The
> reason I actually prefer explicit type hinting is that Byte and Short types
> are somewhat strange at the JVM level compared to Int and Long. (See the
> "scala numeric meta-sip" thread over on scala-language for details.)

On Fri, Dec 30, 2011 at 2:04 PM, Jack Viers <jack.viers@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.klang@gmail.com>

On Fri, Dec 30, 2011 at 2:04 PM, Jack Viers <jack.viers@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.

Excerpts from https://issues.scala-lang.org/browse/SI-4437 .

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

Hi guys! Martin's recent string interpolation proposal provides
generic syntax for various external domain-specific languages:
https://docs.google.com/document/d/1NdxNxZYodPA-c4MLr33KzwzKFkzm9iW9POex....

The proposal mentions using this syntax to implement string
interpolation (s"hello, $s") and code quasiquotations (c"$x + $y").
However, the domain of possibilities is much wider. For example, we
can write regexes and not struggle with escapes (since quasiquotes do
not interpret escape characters). Also, one could try to embed HTML
and JS with deep integration into the host Scala program (e.g.
transparent, but typesafe references to variables in lexical scope).

The very same approach can be used to implement pretty syntax for byte
literals. For example, b"0a" would stand for 10 of type byte.

In case you wonder about performance implications. There won't be any
if you use a macro to implement the "b" quasiquote provider. Here's
how it works. This macro will take some representation of a quasiquote
(say, a tree that contains a constructor of new Quasiquote("0a")).
Then during macro expansion, it will extract the "0a" string literal
from the AST, parse it and emit the AST you need, e.g.
Select(Literal(Constant(10)), newTermName("toByte")). The resulting
AST will be inlined into the callsite, so there won't be any overhead
in comparison with writing the code manually.

Exact details of the quasiquoting API are still in flux. This is
something I've been actively working during the last week, and in a
few days I'm going to present a prototype and some refinements to the
SID. Stay tuned.

On Dec 30 2011, 9:08 pm, √iktor Ҡlang wrote:
> On Fri, Dec 30, 2011 at 9:01 PM, Paul Phillips wrote:
>
> > 2011/12/30 √iktor Ҡlang
>
> >> On Fri, Dec 30, 2011 at 2:04 PM, Jack Viers 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.
>
> Schrödinger told us of the dangers of putting things into boxes.
>
>
>
>
>
> > Excerpts fromhttps://issues.scala-lang.org/browse/SI-4437.
>
> > 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 .(: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
>
> --
> Viktor Klang
>
> Akka Tech Lead
> Typesafe - Enterprise-Grade Scala from the
> Experts
>
> Twitter: @viktorklang

Hi guys! Martin's recent string interpolation proposal provides
generic syntax for various external domain-specific languages:
https://docs.google.com/document/d/1NdxNxZYodPA-c4MLr33KzwzKFkzm9iW9POexT9PkJsU/edit?hl=en_US.

The proposal mentions using this syntax to implement string
interpolation (s"hello, $s") and code quasiquotations (c"$x + $y").
However, the domain of possibilities is much wider. For example, we
can write regexes and not struggle with escapes (since quasiquotes do
not interpret escape characters). Also, one could try to embed HTML
and JS with deep integration into the host Scala program (e.g.
transparent, but typesafe references to variables in lexical scope).

The very same approach can be used to implement pretty syntax for byte
literals. For example, b"0a" would stand for 10 of type byte.

In case you wonder about performance implications. There won't be any
if you use a macro to implement the "b" quasiquote provider. Here's
how it works. This macro will take some representation of a quasiquote
(say, a tree that contains a constructor of new Quasiquote("0a")).
Then during macro expansion, it will extract the "0a" string literal
from the AST, parse it and emit the AST you need, e.g.
Select(Literal(Constant(10)), newTermName("toByte")). The resulting
AST will be inlined into the callsite, so there won't be any overhead
in comparison with writing the code manually.

Exact details of the quasiquoting API are still in flux. This is
something I've been actively working during the last week, and in a
few days I'm going to present a prototype and some refinements to the
SID. Stay tuned.

On Dec 30 2011, 9:08 pm, √iktor Ҡlang <viktor.kl...@gmail.com> wrote:
> On Fri, Dec 30, 2011 at 9:01 PM, Paul Phillips <pa...@improving.org> wrote:
>
> > 2011/12/30 √iktor Ҡlang <viktor.kl...@gmail.com>
>
> >> On Fri, Dec 30, 2011 at 2:04 PM, Jack Viers <jack.vi...@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.
>
> Schrödinger told us of the dangers of putting things into boxes.
>
>
>
>
>
> > Excerpts fromhttps://issues.scala-lang.org/browse/SI-4437.
>
> > 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
>
> --
> Viktor Klang
>
> Akka Tech Lead
> Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the
> Experts
>
> Twitter: @viktorklang

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 =)).

Cheers,
Eugene

On Jan 1, 9:01 pm, Jon Steelman wrote:
> Hi Eugene,
>
> Does this mean the proposal will support multiple levels of nesting?
>
> Thanks,
> Jon
>
>
>
> On Sun, Jan 1, 2012 at 8:49 AM, Eugene Burmako wrote:
> > Hi guys! Martin's recent string interpolation proposal provides
> > generic syntax for various external domain-specific languages:
>
> >https://docs.google.com/document/d/1NdxNxZYodPA-c4MLr33KzwzKFkzm9iW9P...
> > .
>
> > The proposal mentions using this syntax to implement string
> > interpolation (s"hello, $s") and code quasiquotations (c"$x + $y").
> > However, the domain of possibilities is much wider. For example, we
> > can write regexes and not struggle with escapes (since quasiquotes do
> > not interpret escape characters). Also, one could try to embed HTML
> > and JS with deep integration into the host Scala program (e.g.
> > transparent, but typesafe references to variables in lexical scope).
>
> > The very same approach can be used to implement pretty syntax for byte
> > literals. For example, b"0a" would stand for 10 of type byte.
>
> > In case you wonder about performance implications. There won't be any
> > if you use a macro to implement the "b" quasiquote provider. Here's
> > how it works. This macro will take some representation of a quasiquote
> > (say, a tree that contains a constructor of new Quasiquote("0a")).
> > Then during macro expansion, it will extract the "0a" string literal
> > from the AST, parse it and emit the AST you need, e.g.
> > Select(Literal(Constant(10)), newTermName("toByte")). The resulting
> > AST will be inlined into the callsite, so there won't be any overhead
> > in comparison with writing the code manually.
>
> > Exact details of the quasiquoting API are still in flux. This is
> > something I've been actively working during the last week, and in a
> > few days I'm going to present a prototype and some refinements to the
> > SID. Stay tuned.
>
> > On Dec 30 2011, 9:08 pm, √iktor Ҡlang wrote:
> > > On Fri, Dec 30, 2011 at 9:01 PM, Paul Phillips
> > wrote:
>
> > > > 2011/12/30 √iktor Ҡlang
>
> > > >> On Fri, Dec 30, 2011 at 2:04 PM, Jack Viers > >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.
>
> > > Schrödinger told us of the dangers of putting things into boxes.
>
> > > > Excerpts fromhttps://issues.scala-lang.org/browse/SI-4437.
>
> > > > 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 .(: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
>
> > > --
> > > Viktor Klang
>
> > > Akka Tech Lead
> > > Typesafe - Enterprise-Grade Scala from the
> > > Experts
>
> > > Twitter: @viktorklang

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 =)).

Yep, so far scalamacros.org is the only resource on macros for Scala.
There's not so much content, but the main points are covered. After I
defense my semester project I'm looking forward to updating the site
with the info about recent developments.

Speaking of the difference between macros and compiler plugins. Macros
are less powerful (macro expansion only happens in Typers, there is no
way to customize the compilation pipeline), but are much more
lightweight (writing a "macro def" function is all that it takes to
write a macro).

On Jan 2, 12:28 am, Doug Tangren wrote:
> On Sun, Jan 1, 2012 at 5:41 PM, Eugene Burmako wrote:
> > 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 =)).
>
> Thanks for following up with the macro pointers guys. I'm not very familiar
> with macros in scala. Ishttp://scalamacros.org/a good place to start
> looking? It looks interesting. How does it differ from a compiler plugin
> where you can already manipulate streams of terms?