Type Tags vs. Value Classes

[Stefan Hoeck]

Dear all

scalaz 7 uses Type Tags to implement different type class instances for the same data types. This is similar to Haskell's newtypes. The same could be achieved with Scala 2.10 Value Classes. Has anybody compared the two approaches (type tags vs. value classes). Does one of the two have advantages over the other one? Which one would be used in scalaz if backwards compatibility was not an issue?

Cheers

Stefan

[Stefan Hoeck]

sorry, it should be 'tagged types' instead of TypeTags. ah, the confusion!

[Jason Zaugg]

Value Classes are still boxed whenever they are used in generic collections / code. Tagged Types are not, but unfortunately are prone to compiler bugs (e.g. https://issues.scala-lang.org/browse/SI-5183)

-jason

[Stefan Hoeck]

Thanks for this info, Jason. Do you know whether there is a fix in sight for these issues with tagged types?

Also, if I got that correctly, with tagged types you can still use the functions define for untagged data type on the tagged ones. For instance, you can still do the following:

  val a: Int @@ SomeTag = ...
  val b: Int @@ SomeTag = ...

  val c = a + b  //inferred type of c is Int

While with Value Classes you'd need to define some implicit conversions to do this, no?

Cheers, Stefan

[Jason Zaugg]

On Wed, May 1, 2013 at 2:58 PM, Stefan Hoeck <efasc...@gmail.com> wrote:

Thanks for this info, Jason. Do you know whether there is a fix in sight for these issues with tagged types?

One or two things have been fixed, but the remaining ones look pretty tough to fix (related to arrays, erasure, varargs, etc.) It's hard to prioritize work in that area, because with Tagged Types you sort of are asking for trouble with the asInstanceOf.

 

Also, if I got that correctly, with tagged types you can still use the functions define for untagged data type on the tagged ones. For instance, you can still do the following:

  val a: Int @@ SomeTag = ...
  val b: Int @@ SomeTag = ...

  val c = a + b  //inferred type of c is Int

While with Value Classes you'd need to define some implicit conversions to do this, no?

Yep, Tagged Types in Scalaz subtype the underlying type. 

-jason

[Stephen Compall]

On May 1, 2013 7:18 AM, "Jason Zaugg" <jza...@gmail.com> wrote:
> Value Classes are still boxed whenever they are used in generic collections / code. Tagged Types are not, but unfortunately are prone to compiler bugs (e.g. https://issues.scala-lang.org/browse/SI-5183)

As are value classes (https://issues.scala-lang.org/browse/SI-6260).

This alone makes them unusable for generic code, since you have to walk on eggshells to use them on unconstrained generic types of any kind, whereas "I've got an A, I want an A @@ tag" is entirely reasonable.

--
Stephen Compall
If anyone in the MSA is online, you should watch this flythrough.

--
You received this message because you are subscribed to the Google Groups "scalaz" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalaz+un...@googlegroups.com.
To post to this group, send email to sca...@googlegroups.com.
Visit this group at http://groups.google.com/group/scalaz?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Alec Zorab]

Bear in mind that TaggedTypes are also prone to doing slightly odd things when interacting with Implicits. See https://github.com/scalaz/scalaz/issues/338

[Miles Sabin]

On Wed, May 1, 2013 at 1:58 PM, Stefan Hoeck <efasc...@gmail.com> wrote:
> Thanks for this info, Jason. Do you know whether there is a fix in sight for
> these issues with tagged types?
>
> Also, if I got that correctly, with tagged types you can still use the
> functions define for untagged data type on the tagged ones. For instance,
> you can still do the following:
>
> val a: Int @@ SomeTag = ...
> val b: Int @@ SomeTag = ...
>
> val c = a + b //inferred type of c is Int

Correct ... that's why it's not quite correct to call this mechanism
"newtype". It is possible to get a little bit closer to newtype in
Scala however,

https://github.com/milessabin/shapeless/blob/master/core/src/main/scala/shapeless/typeoperators.scala#L70

But in many important cases it's really tagging that's wanted rather
than newtype.

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
skype: milessabin
gtalk: mi...@milessabin.com
g+: http://www.milessabin.com
http://twitter.com/milessabin

[Ben Hutchison]

Tagged primitives are not boxed in arrays, whereas value classes are
(as at 2.10). Given that arrays are key to performance in many cases,
that's quite an advantage for tagged-values-with-typeclasses.

Currently, primitive arrays that are tagged cause a compiler crash.
https://issues.scala-lang.org/browse/SI-7088

(there is a workaround: wrap the primitive array in a tagged object)


Broadly, it's not clear to me whether unboxed tagged types are an
"officially supported" Scala feature, or a useful 'accident' that
might change at some future time.
Eg see paulp's comments here:
https://groups.google.com/d/msg/shapeless-dev/TOGq0QZnIvQ/IzDqEJHKZ9AJ

-Ben