New SID draft: Scala Specialization

scala-website@epfl.ch wrote:
> On date Nov 16, 2009 17:34:36, user 'dragos' submitted a new SID draft
> entitled: Scala Specialization
>
> You can find the new draft at: http://www.scala-lang.org/sid/9

Thanks for the new SID.

I noticed this:

"""None of the standard library classes are specialized yet, but the plan is to
specialize array-based collections and FunctionN traits up to two parameters
before the first release of Scala 2.8."""

Are there any plans to specialize Option/Some in 2.8? That seems like it would
be a big.

Regards,
Blair

On Tue, Nov 17, 2009 at 4:48 AM, Blair Zajac wrote:
> scala-website@epfl.ch wrote:
>>
>> On date Nov 16, 2009 17:34:36, user 'dragos' submitted a new SID draft
>> entitled: Scala Specialization
>>
>> You can find the new draft at: http://www.scala-lang.org/sid/9
>
> Thanks for the new SID.
>
> I noticed this:
>
> """None of the standard library classes are specialized yet, but the plan is
> to specialize array-based collections and FunctionN traits up to two
> parameters before the first release of Scala 2.8."""
>
> Are there any plans to specialize Option/Some in 2.8?  That seems like it
> would be a big.

Yes, I agree. -- Martin

On Tue, Nov 17, 2009 at 09:17:22AM +0100, martin odersky wrote:
> > Are there any plans to specialize Option/Some in 2.8?  That seems like it
> > would be a big.
>
> Yes, I agree. -- Martin

I thought that too and tried to specialize it a while ago, but I ran
into the roadblock that Option is sealed and Some is final. I haven't
found any explanation of how specialization works (if it does) in the
face of sealed and final classes, but based on my understanding of how
it works (and based on my naive attempt) it doesn't. And the
specialization papers didn't discuss this issue from what I saw.

Even if it doesn't work, I think we should hand-specialize Option.

On Tue, Nov 17, 2009 at 2:51 PM, Paul Phillips <paulp@improving.org> wrote:

On Tue, Nov 17, 2009 at 09:17:22AM +0100, martin odersky wrote:
> > Are there any plans to specialize Option/Some in 2.8?  That seems like it
> > would be a big.
>
> Yes, I agree. -- Martin

I thought that too and tried to specialize it a while ago, but I ran
into the roadblock that Option is sealed and Some is final.  I haven't
found any explanation of how specialization works (if it does) in the
face of sealed and final classes, but based on my understanding of how
it works (and based on my naive attempt) it doesn't.  And the
specialization papers didn't discuss this issue from what I saw.

I just tried it and it works fine. Final classes are not final in bytecode, but that happens after type checking, so from a user point of view they are still final. One thing that might have tripped you is that the scala script puts the standard library in the boot classpath, so compiling a special version of Option and running your program with 'scala' will end up loading classes from the standard library, where Some is still final.
let me know if there's something else that failsiulian

 

Even if it doesn't work, I think we should hand-specialize Option.

--
Paul Phillips      | One way is to make it so simple that there are
Imperfectionist    | obviously no deficiencies. And the other way is to make
Empiricist         | it so complicated that there are no obvious deficiencies.
i'll ship a pulp   |     -- Hoare

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

On Tue, Nov 17, 2009 at 03:30:40PM +0100, Iulian Dragos wrote:
> I just tried it and it works fine.

Great! I completely believe it was a PEBKAC issue. Tangent:

> One thing that might have tripped you is that the scala script puts
> the standard library in the boot classpath [...]

Depending on what you mean by "boot classpath", this is not true, but
the fact that this can mean two very different things is why I bring it
up. In java the bootclasspath is a whole separate thing, given special
treatment (verifier doesn't run etc.) and has to be supplied with the
-Xbootclasspath option at java invocation time.

Scala has not put anything on the boot classpath for a long time (it did
until somewhere early in the 2.7.x series) but appropriates the term
"boot classpath" and option -bootclasspath to mean something more like
"priority position on the application classpath for use by
scala-library.jar." It's quite confusing and it'd be a nice thing to
undo at some point.

On Tue, Nov 17, 2009 at 4:02 PM, Paul Phillips <paulp@improving.org> wrote:

On Tue, Nov 17, 2009 at 03:30:40PM +0100, Iulian Dragos wrote:
> I just tried it and it works fine.

Great! I completely believe it was a PEBKAC issue.  Tangent:

> One thing that might have tripped you is that the scala script puts
> the standard library in the boot classpath [...]

Depending on what you mean by "boot classpath", this is not true, but
the fact that this can mean two very different things is why I bring it
up.  In java the bootclasspath is a whole separate thing, given special
treatment (verifier doesn't run etc.) and has to be supplied with the
-Xbootclasspath option at java invocation time.

Scala has not put anything on the boot classpath for a long time (it did
until somewhere early in the 2.7.x series) but appropriates the term
"boot classpath" and option -bootclasspath to mean something more like
"priority position on the application classpath for use by
scala-library.jar." It's quite confusing and it'd be a nice thing to
undo at some point.

Thanks for clarifying this. Indeed, terminology is a bit confusing here, but a way to override the Scala standard library is useful from time to time. Maybe replace it by a way to prepend something to the default 'scala' classpath.
iulian  

--
Paul Phillips      | Every election is a sort of advance auction sale
Analgesic          | of stolen goods.
Empiricist         |     -- H. L. Mencken
ha! spill, pupil   |----------* http://www.improving.org/paulp/ *----------

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais