Thoughts on erasure

On Tue, Aug 3, 2010 at 2:37 PM, Silvio Bierman
wrote:
> Would it not be nice for people who want to go 100% Scala to circumvent the
> type erasure limitation? I would love a compiler switch or something that
> will implement a name mangling scheme to circumvent name clashes caused by
> type erasure.

+1

On Tue, Aug 3, 2010 at 2:51 PM, Johannes Rudolph
wrote:
> On Tue, Aug 3, 2010 at 2:37 PM, Silvio Bierman
> wrote:
>> Would it not be nice for people who want to go 100% Scala to circumvent the
>> type erasure limitation? I would love a compiler switch or something that
>> will implement a name mangling scheme to circumvent name clashes caused by
>> type erasure.
>
> +1

I think controlling this with an annotation would be appropriate.

@reified compiler plugin, anyone?

On Tue, Aug 3, 2010 at 2:51 PM, Johannes Rudolph <johannes.rudolph@googlemail.com> wrote:

On Tue, Aug 3, 2010 at 2:51 PM, Johannes Rudolph
<johannes.rudolph@googlemail.com> wrote:
> On Tue, Aug 3, 2010 at 2:37 PM, Silvio Bierman
> <sbierman@jambo-software.com> wrote:
>> Would it not be nice for people who want to go 100% Scala to circumvent the
>> type erasure limitation? I would love a compiler switch or something that
>> will implement a name mangling scheme to circumvent name clashes caused by
>> type erasure.
>
> +1

I think controlling this with an annotation would be appropriate.

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

I am quite hostile to annotations since I consider them language pollution. I
hated them in java and still hate them in Scala. Annotations where invented
to attach above-language meta-info to classes etc for the sole purpose of
libraries/frameworks. I think they are a poor choice for selecting different
implementation strategies for core language constructs.

I would prefer a compiler switch or anything else that can be set globally.
I would hate to have to annotate every val/var to express I want true
generics.

I could live with true generics as the default and an annotation for the
reified version though :-))

Silvio

On Tuesday August 3 2010, Silvio Bierman wrote:
> I am quite hostile to annotations since I consider them language
> pollution. ...
>
> I would prefer a compiler switch or anything else that can be set
> globally. I would hate to have to annotate every val/var to express I
> want true generics.

You're talking about changing the language's semantics. An annotation is
appropriate, especially because can travel with the compiled code, if
you will, and might obviate problems when not all of the code is
compiled with consistent compiler options.

> I could live with true generics as the default and an annotation for
> the reified version though :-))
>
> Silvio

Randall Schulz

I don't see that we need any annotation or compiler-option at all.As Manifest-awareness works itself deeper into the language and libraries, this is the sort of thing that I'd expect to see arising naturally - even in the presence of erasure.
Of course there are corner-cases where a manifest isn't always available,but I'm currently working on a way to rebuild them from the "scala signature" at runtime for scalaj-spring.

On 3 August 2010 14:29, Silvio Bierman <sbierman@jambo-software.com> wrote:

I am quite hostile to annotations since I consider them language pollution. I
hated them in java and still hate them in Scala. Annotations where invented
to attach above-language meta-info to classes etc for the sole purpose of
libraries/frameworks. I think they are a poor choice for selecting different
implementation strategies for core language constructs.

I would prefer a compiler switch or anything else that can be set globally.
I would hate to have to annotate every val/var to express I want true
generics.

I could live with true generics as the default and an annotation for the
reified version though :-))

Silvio

--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/Thoughts-on-erasure-tp2311773p2311861.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Kevin Wright

mail/google talk: kev.lee.wright@gmail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

Randall R Schulz wrote:
>
> You're talking about changing the language's semantics. An annotation is
> appropriate, especially because can travel with the compiled code, if
> you will, and might obviate problems when not all of the code is
> compiled with consistent compiler options.
>
> Randall Schulz
>
>

Sure, but that was also true when Scala Array was changed from 2.7 to 2.8.
The problem I have with an annotation is that it has to be repeated for
every class created which I consider source pollution. If that can be hidden
inside libraries like the specialization in the standard collections than
that is sort of OK. This is, by the way, also a partial breakage of the Java
interop for generics.

I would as a second best solution welcome a special syntactical construct to
express this as was done with the manifest syntax. On the other hand, I
would prefer by default breaking part of the Java interop. Being able to use
Java libraries/legacy code is IMHO 90% of the interop added value so that
should be preserved.

We have an anotation to generate Java compatible getters/setters, I think
having the same for Java compatible generics makes sense. In my view
sacrificing orthogonality for a sideline feature like generics interop is a
bad deal. I do understand, however, that others may have different
priorities.

That is why I am asking people about their thoughts on the subject.

Gr. Silvio

This whole question of overloading for implementing different instantiations of the same type constructor is strongly reminiscent of specialization, isn't it?
-0xe1a

Well, overloading in itself is not really seen as one of the areas
where Scala wants to innovate. It's rather that we have to implement
what Java does. Some people would recommend to do away with
overloading altogether (I'm not one of them, but still...). So I do
not see a lot of support for a language change like this.

Cheers

The alternative to overloading here would be multimethods, otherwise known as multiple dispatchIn fact, you can already do a double-dispatch by hand: pattern-match on an implicit manifest then delegate through to IntSeqFoo, DoubleSeqFoo, etc. as appropriate
That's not the nicest solution though
A better way to handle this in Scala is a typeclass/monoid approach, where each variant of Foo is wrapped in an implicit object, which is then selected implicitly
Like this: http://www.scala-lang.org/node/114

On 3 August 2010 21:20, martin odersky <martin.odersky@epfl.ch> wrote:

Well, overloading in itself is not really seen as one of the areas
where Scala wants to innovate. It's rather that we have to implement
what Java does. Some people would recommend to do away with
overloading altogether (I'm not one of them, but still...). So I do
not see a lot of support for a language change like this.

Cheers

Martin Odersky wrote:
>
> Well, overloading in itself is not really seen as one of the areas
> where Scala wants to innovate. It's rather that we have to implement
> what Java does. Some people would recommend to do away with
> overloading altogether (I'm not one of them, but still...). So I do
> not see a lot of support for a language change like this.
>

I am surely not one of them either. Methods I tend to want to overload are
apply/update and in some cases xxx_= etc. I am not fond of using function
names like writeInt/writeDouble/writeXXX which gets especially awkward if
either the parameter types are compound (like Seq[Option[Int]]) or there are
two or more parameters.

I like minimal interfaces and overloading helps to reduce the perceived size
of a classes interface.

I understand that overloading is not a key focus for Scala but the language
comes closest to the ideal language for writing libraries and frameworks of
all languages I have ever used. The fact that Scala runs on the JVM only
amplifies that.

I have never liked Java generics because of type erasure and the lack of
specialization. I would love it if Scala would solve both problems.

Understand me correctly: I am already sold on the language as it is. This is
just an area where it could be more orthogonal. As I said, I was just
curious what other people think about this.

Thanks for the comments, everyone.

Kind regards,

Silvio

On Wed, Aug 4, 2010 at 12:35 AM, Silvio Bierman <sbierman@jambo-software.com> wrote:

Martin Odersky wrote:
>
> Well, overloading in itself is not really seen as one of the areas
> where Scala wants to innovate. It's rather that we have to implement
> what Java does. Some people would recommend to do away with
> overloading altogether (I'm not one of them, but still...). So I do
> not see a lot of support for a language change like this.
>

I am surely not one of them either. Methods I tend to want to overload are
apply/update and in some cases xxx_= etc. I am not fond of using function
names like writeInt/writeDouble/writeXXX which gets especially awkward if
either the parameter types are compound (like Seq[Option[Int]]) or there are
two or more parameters.

I like minimal interfaces and overloading helps to reduce the perceived size
of a classes interface.

I understand that overloading is not a key focus for Scala but the language
comes closest to the ideal language for writing libraries and frameworks of
all languages I have ever used. The fact that Scala runs on the JVM only
amplifies that.

I have never liked Java generics because of type erasure and the lack of
specialization. I would love it if Scala would solve both problems.

Understand me correctly: I am already sold on the language as it is. This is
just an area where it could be more orthogonal. As I said, I was just
curious what other people think about this.

I really recommendthe typeclass pattern for the writeTypeName problem,
you need not pollute the class with expected types to write and you don't force what's being written to extend some interface or such.

 

Thanks for the comments, everyone.

Kind regards,

Silvio

--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/Thoughts-on-erasure-tp2311773p2312702.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang

On 3 August 2010 23:39, Viktor Klang <viktor.klang@gmail.com> wrote:

On Wed, Aug 4, 2010 at 12:35 AM, Silvio Bierman <sbierman@jambo-software.com> wrote:

Martin Odersky wrote:
>
> Well, overloading in itself is not really seen as one of the areas
> where Scala wants to innovate. It's rather that we have to implement
> what Java does. Some people would recommend to do away with
> overloading altogether (I'm not one of them, but still...). So I do
> not see a lot of support for a language change like this.
>

I am surely not one of them either. Methods I tend to want to overload are
apply/update and in some cases xxx_= etc. I am not fond of using function
names like writeInt/writeDouble/writeXXX which gets especially awkward if
either the parameter types are compound (like Seq[Option[Int]]) or there are
two or more parameters.

I like minimal interfaces and overloading helps to reduce the perceived size
of a classes interface.

I understand that overloading is not a key focus for Scala but the language
comes closest to the ideal language for writing libraries and frameworks of
all languages I have ever used. The fact that Scala runs on the JVM only
amplifies that.

I have never liked Java generics because of type erasure and the lack of
specialization. I would love it if Scala would solve both problems.

Understand me correctly: I am already sold on the language as it is. This is
just an area where it could be more orthogonal. As I said, I was just
curious what other people think about this.

I really recommendthe typeclass pattern for the writeTypeName problem,
you need not pollute the class with expected types to write and you don't force what's being written to extend some interface or such.

Not to mention the advantage of bragging rights for being able to achieve something, in complete type safety, that neither C# nor F# are capable of :)
 

 

Thanks for the comments, everyone.

Kind regards,

Silvio

--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/Thoughts-on-erasure-tp2311773p2312702.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang

--
Kevin Wright

mail/google talk: kev.lee.wright@gmail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

Viktor Klang wrote:
>
> I really recommendthe typeclass pattern for the writeTypeName problem,
> you need not pollute the class with expected types to write and you don't
> force what's being written to extend some interface or such.
>

Yes, that is a cool language feature that I have already used once or twice.
But in most cases it still requires quite some boilerplate code that
clutters up both the definition side and the call side. Not to mention that
the people I write the libraries for will have trouble understanding the
interface.

Silvio

On Wed, Aug 4, 2010 at 6:18 AM, Silvio Bierman <sbierman@jambo-software.com> wrote:

Viktor Klang wrote:
>
> I really recommendthe typeclass pattern for the writeTypeName problem,
> you need not pollute the class with expected types to write and you don't
> force what's being written to extend some interface or such.
>

Yes, that is a cool language feature that I have already used once or twice.
But in most cases it still requires quite some boilerplate code that
clutters up both the definition side and the call side. Not to mention that
the people I write the libraries for will have trouble understanding the
interface.

 Agreed, solving the boiler-issue with type classes in Scala would be beneficial.
 

Silvio

--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/Thoughts-on-erasure-tp2311773p2312912.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang

[moved to debate]

On Wed, Aug 4, 2010 at 10:39 AM, Viktor Klang <viktor.klang@gmail.com> wrote:

Agreed, solving the boiler-issue with type classes in Scala would be beneficial.

speaking of which, we haven't eradicated that boilerplate yet, but it is highlighted in gray in the final version of a paper that we just finished, which compares haskell type classes and scala's implicits in detail
that said, is that boilerplate really that bad in practice?
the boilerplate boils down to: 

• "instance" --> "implicit def"
• instances must be named (a perk)
• context bounds must be named (cost: one "implicit" keyword in the last argument list and the names of the implicit arguments, as, strictly speaking, only the type of the corresponding implicit argument is necessary, except when you want to access the dictionary directly, hence: sometimes a perk)
• context bounds are not inferred (most of the extra typing goes here, but that's not something that we can solve in the language, given how type inference is "local" in Scala vs "global" in Haskell, roughly speaking)

cheersadriaan
ps: we also save you some typing: "where" + spacing --> "{}", but that's a whole different debate (not to mention "::" becoming just ":")

On Wed, Aug 4, 2010 at 4:44 PM, Adriaan Moors <adriaan.moors@epfl.ch> wrote:

[moved to debate]

On Wed, Aug 4, 2010 at 10:39 AM, Viktor Klang <viktor.klang@gmail.com> wrote:

Agreed, solving the boiler-issue with type classes in Scala would be beneficial.

speaking of which, we haven't eradicated that boilerplate yet, but it is highlighted in gray in the final version of a paper that we just finished, which compares haskell type classes and scala's implicits in detail

Paper seems to be unreachable at the moment, will read and reply later.
Thanks
 

that said, is that boilerplate really that bad in practice?
the boilerplate boils down to: 

• "instance" --> "implicit def"
• instances must be named (a perk)
• context bounds must be named (cost: one "implicit" keyword in the last argument list and the names of the implicit arguments, as, strictly speaking, only the type of the corresponding implicit argument is necessary, except when you want to access the dictionary directly, hence: sometimes a perk)
• context bounds are not inferred (most of the extra typing goes here, but that's not something that we can solve in the language, given how type inference is "local" in Scala vs "global" in Haskell, roughly speaking)

cheersadriaan
ps: we also save you some typing: "where" + spacing --> "{}", but that's a whole different debate (not to mention "::" becoming just ":")

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang

Silvio,
Type erasure in Scala exists because the JVM does not support reified generics... the JVM forces type erasure.  Scala isn't going to change that.
There was some talk of type erasure at the JVM language summit this year.  The net-net is that if the JVM had reified generics (no type erasure), it would not be possible to implement Scala's type system... Scala's type system is more complex than Java's and if the JVM had generics based on Java generics, we'd still have problems in Scala.  On the other hand, type erasure allows the compiler to implement a complex type system, even if all the type information is not available at runtime.
In terms of the challenge you're facing, there are a few current work-arounds (you can search the Scala mailing list for answers.)  If there was a ground-swell of complaint about the issue, Scala could take the C++ route of method name mangling (yuck!).  But as the implementer of more lines of library code in Scala than anyone else, I don't see the issue you're presenting.  It's just not been a problem for me.
Thanks,
David

On Tue, Aug 3, 2010 at 5:37 AM, Silvio Bierman <sbierman@jambo-software.com> wrote:

I use Scala 2.8. My projects rely heavily on generic classes. I would like to
know the stand on type erasure.

Most discussions about this topic I have seen lately have been centred
around manifests. Although I sometimes use them they solve only a small part
of the problems caused by type erasure. For me, the biggest problem with
type erasure is the limitations it poses on overloading:

trait A
{
 def foo(items : Seq[Int])
 def foo(items : Int*)
 def foo(items : Seq[Double])
 // This will not work, of course
}

Scala is a great language for writing libraries and frameworks and that is
what we are primarily doing at the moment. However, the limitation on
overloading is really painfull. I know that sometimes there are workarounds
but these are usually awkward to use on large scale.

We do use Java classes from Scala but have no ambition to use Scala classes
from Java. Java is our legacy and we are moving away from that to Scala so
everything will eventually become Scala. I can even live with not being able
to use generic Java classes from Scala (or perhaps only by a special
syntax/annotation).
I understand the desire for Java interop and the decision to make Scala
generic classes equal to Java generic classes. However, that seems to imply
we will be stuck with this until the end of times.

Would it not be nice for people who want to go 100% Scala to circumvent the
type erasure limitation? I would love a compiler switch or something that
will implement a name mangling scheme to circumvent name clashes caused by
type erasure.

What can we expect in this area for the coming future?

Regards,

Silvio Bierman

--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/Thoughts-on-erasure-tp2311773p2311773.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

speaking of which, we haven't eradicated that boilerplate yet, but it is highlighted in gray in the final version of a paper that we just finished, which compares haskell type classes and scala's implicits in detail

Paper seems to be unreachable at the moment, will read and reply later.

I've also added it to LAMP's publications page:
Oliveira, B.C.d.S., Moors, A. and Odersky, M. (2010) Type Classes as Objects and Implicits. To appear. [detailed record] [pdf] [bibtex]
hope .ch is more available to you than .kr :-)
cheers adriaan 

Hello David,

Thank you for the reply.

I do know about the workarounds and have used them. If you are writing
library code like the Scala standard library then the workarounds are
effective and have few drawbacks. The library is primarily documented by
ScalaDoc and use cases and not by the source itself. But I am sure you have
heard the complaints of the Scala adopters who decided to dive into the
library sources anyway and found them very hard to comprehend. The end
result stays the same: brilliant in design and a delight for the users.

If the library is for internal use and its source is its primary
documentation (yes, that sounds bad but for our small team it usually works
quite good) then for example the typeclass pattern really helps throwing
people off. That is why I usually do not choose for the workarounds but
revert to renaming.

I am not saying that the limitations on overloading (or any other
consequence of type erasure) are in any way a show stopper. They are
probably just annoying in some cases forcing the library designer to work
around them in some way. Scala being a language that feels and smells
academic I have seen many frowning upon this by Java programmers who where
very accustomed to the same issues in Java. Somehow they expected Scala to
be so orthogonal that it would make this go away.

If forced to choose between the negative side effects/consequences of
changes to "repair" this and keeping things as they are I would probably
choose the latter in retrospect. I was just curious about what others think
of this aspect of Scala. For that matter the thread has been very useful to
me.

Thanks again,

Silvio