- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Soruces for Value Classes
Thu, 2010-09-09, 09:25
While looking at #3791 I tried to add source files for the Value Classes,which would (hopefully) simplify the compiler, allow to look at the codeand make Scaladoc comments easier.
The reasons for failing are described in my commithttp://github.com/soundrabbit/scala/commit/759e2d4df67305d1fe4c3edbb0f86911ccfacc24 in branchhttp://github.com/soundrabbit/scala/commits/anyValSource
Feel free to fix the problems :) Lukas
The reasons for failing are described in my commithttp://github.com/soundrabbit/scala/commit/759e2d4df67305d1fe4c3edbb0f86911ccfacc24 in branchhttp://github.com/soundrabbit/scala/commits/anyValSource
Feel free to fix the problems :) Lukas
Fri, 2010-09-10, 10:37
#2
Re: Soruces for Value Classes
ok, somehow it worked for me yesterday but today i got the same error as you..
please try again withhttp://github.com/soundrabbit/scala/commit/0ab9f85fa1c38e9c8e1519e828a433412181b57e
lukas
On Thu, Sep 9, 2010 at 19:43, Paul Phillips <paulp@improving.org> wrote:
please try again withhttp://github.com/soundrabbit/scala/commit/0ab9f85fa1c38e9c8e1519e828a433412181b57e
lukas
On Thu, Sep 9, 2010 at 19:43, Paul Phillips <paulp@improving.org> wrote:
On Thu, Sep 09, 2010 at 10:25:14AM +0200, Lukas Rytz wrote:
> While looking at #3791 I tried to add source files for the Value
> Classes, which would (hopefully) simplify the compiler, allow to look
> at the code and make Scaladoc comments easier.
Hey, that's something I've always wanted to do too. Following your
instructions I didn't get anywhere: moved those files, built locker, put
them back, tried to build quick, got the following:
[mkdir] Created dir: /scratch/trunk1/build/quick/classes/library
[javac] Compiling 25 source files to /scratch/trunk1/build/quick/classes/library
[javac] Compiling 41 source files to /scratch/trunk1/build/quick/classes/library
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[scalacfork] Compiling 625 files to /scratch/trunk1/build/quick/classes/library
[scalacfork] No class file for /scratch/trunk1/src/library/scala/Boolean.scala was found
[scalacfork] (This file cannot be loaded as a source file)
[scalacfork] scala.tools.nsc.FatalError: No class file for /scratch/trunk1/src/library/scala/Boolean.scala was found
[scalacfork] (This file cannot be loaded as a source file)
[scalacfork] at scala.tools.nsc.Global$Run.compileLate(Global.scala:834)
[scalacfork] at scala.tools.nsc.symtab.SymbolLoaders$SourcefileLoader.doComplete(SymbolLoaders.scala:265)
[scalacfork] at scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:61)
[scalacfork] at scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:35)
[scalacfork] at scala.tools.nsc.symtab.Symbols$Symbol.info(Symbols.scala:733)
[scalacfork] at scala.tools.nsc.symtab.Definitions$definitions$.newMethod(Definitions.scala:569)
[scalacfork] at scala.tools.nsc.symtab.Definitions$definitions$.newParameterlessMethod(Definitions.scala:591)
[scalacfork] at scala.tools.nsc.symtab.Definitions$definitions$.initValueClasses(Definitions.scala:690)
[scalacfork] at scala.tools.nsc.symtab.Definitions$definitions$.init(Definitions.scala:845)
[scalacfork] at scala.tools.nsc.Global$Run.<init>(Global.scala:604)
[scalacfork] at scala.tools.nsc.Main$.process(Main.scala:105)
[scalacfork] at scala.tools.nsc.Main$.main(Main.scala:120)
[scalacfork] at scala.tools.nsc.Main.main(Main.scala)
[scalacfork] error: fatal error: No class file for /scratch/trunk1/src/library/scala/Boolean.scala was found
[scalacfork] (This file cannot be loaded as a source file)
--
Paul Phillips | Eschew mastication.
Analgesic |
Empiricist |
up hill, pi pals! |----------* http://www.improving.org/paulp/ *----------
Fri, 2010-09-10, 10:57
#3
Re: Soruces for Value Classes
or better http://github.com/soundrabbit/scala/commit/c13c67dda7c96c290d76a9b8763e559493704b9d
On Fri, Sep 10, 2010 at 11:34, Lukas Rytz <lukas.rytz@epfl.ch> wrote:
On Fri, Sep 10, 2010 at 11:34, Lukas Rytz <lukas.rytz@epfl.ch> wrote:
ok, somehow it worked for me yesterday but today i got the same error as you..
please try again withhttp://github.com/soundrabbit/scala/commit/0ab9f85fa1c38e9c8e1519e828a433412181b57e
lukas
On Thu, Sep 9, 2010 at 19:43, Paul Phillips <paulp@improving.org> wrote:
On Thu, Sep 09, 2010 at 10:25:14AM +0200, Lukas Rytz wrote:
> While looking at #3791 I tried to add source files for the Value
> Classes, which would (hopefully) simplify the compiler, allow to look
> at the code and make Scaladoc comments easier.
Hey, that's something I've always wanted to do too. Following your
instructions I didn't get anywhere: moved those files, built locker, put
them back, tried to build quick, got the following:
[mkdir] Created dir: /scratch/trunk1/build/quick/classes/library
[javac] Compiling 25 source files to /scratch/trunk1/build/quick/classes/library
[javac] Compiling 41 source files to /scratch/trunk1/build/quick/classes/library
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[scalacfork] Compiling 625 files to /scratch/trunk1/build/quick/classes/library
[scalacfork] No class file for /scratch/trunk1/src/library/scala/Boolean.scala was found
[scalacfork] (This file cannot be loaded as a source file)
[scalacfork] scala.tools.nsc.FatalError: No class file for /scratch/trunk1/src/library/scala/Boolean.scala was found
[scalacfork] (This file cannot be loaded as a source file)
[scalacfork] at scala.tools.nsc.Global$Run.compileLate(Global.scala:834)
[scalacfork] at scala.tools.nsc.symtab.SymbolLoaders$SourcefileLoader.doComplete(SymbolLoaders.scala:265)
[scalacfork] at scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:61)
[scalacfork] at scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:35)
[scalacfork] at scala.tools.nsc.symtab.Symbols$Symbol.info(Symbols.scala:733)
[scalacfork] at scala.tools.nsc.symtab.Definitions$definitions$.newMethod(Definitions.scala:569)
[scalacfork] at scala.tools.nsc.symtab.Definitions$definitions$.newParameterlessMethod(Definitions.scala:591)
[scalacfork] at scala.tools.nsc.symtab.Definitions$definitions$.initValueClasses(Definitions.scala:690)
[scalacfork] at scala.tools.nsc.symtab.Definitions$definitions$.init(Definitions.scala:845)
[scalacfork] at scala.tools.nsc.Global$Run.<init>(Global.scala:604)
[scalacfork] at scala.tools.nsc.Main$.process(Main.scala:105)
[scalacfork] at scala.tools.nsc.Main$.main(Main.scala:120)
[scalacfork] at scala.tools.nsc.Main.main(Main.scala)
[scalacfork] error: fatal error: No class file for /scratch/trunk1/src/library/scala/Boolean.scala was found
[scalacfork] (This file cannot be loaded as a source file)
--
Paul Phillips | Eschew mastication.
Analgesic |
Empiricist |
up hill, pi pals! |----------* http://www.improving.org/paulp/ *----------
Fri, 2010-09-10, 14:37
#4
Re: Soruces for Value Classes
On Fri, Sep 10, 2010 at 11:50:46AM +0200, Lukas Rytz wrote:
> or better
> http://github.com/soundrabbit/scala/commit/c13c67dda7c96c290d76a9b8763e5...
OK - I still crash building quick.lib, but in the expected way?
(Yes/no?) Your commit message references crashing somewhere in Mixin.
Just want to verify we're coming from the same starting blocks.
quick.lib:
[mkdir] Created dir: /scratch/rytz/build/quick/classes/library
[javac] Compiling 25 source files to /scratch/rytz/build/quick/classes/library
[javac] Compiling 41 source files to /scratch/rytz/build/quick/classes/library
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[scalacfork] Compiling 625 files to /scratch/rytz/build/quick/classes/library
[scalacfork] Exception in thread "main" java.lang.AssertionError: assertion failed: class Boolean
[scalacfork] at scala.Predef$.assert(Predef.scala:91)
[scalacfork] at scala.tools.nsc.transform.Mixin.addMixedinMembers(Mixin.scala:221)
[scalacfork] at scala.tools.nsc.transform.Mixin$MixinTransformer.preTransform(Mixin.scala:475)
[scalacfork] at scala.tools.nsc.transform.Mixin$MixinTransformer.transform(Mixin.scala:1075)
[scalacfork] at scala.tools.nsc.ast.Trees$Transformer.transformTemplate(Trees.scala:853)
[scalacfork] at scala.tools.nsc.ast.Trees$Transformer$$anonfun$transform$2.apply(Trees.scala:745)
[scalacfork] at scala.tools.nsc.ast.Trees$Transformer$$anonfun$transform$2.apply(Trees.scala:744)
[scalacfork] at scala.tools.nsc.ast.Trees$Transformer.atOwner(Trees.scala:877)
[scalacfork] at scala.tools.nsc.ast.Trees$Transformer.transform(Trees.scala:743)
[scalacfork] at scala.tools.nsc.transform.Mixin$MixinTransformer.transform(Mixin.scala:1075)
Fri, 2010-09-10, 14:47
#5
Re: Soruces for Value Classes
yes, that's the crash i meant.
On Fri, Sep 10, 2010 at 15:28, Paul Phillips <paulp@improving.org> wrote:
On Fri, Sep 10, 2010 at 15:28, Paul Phillips <paulp@improving.org> wrote:
On Fri, Sep 10, 2010 at 11:50:46AM +0200, Lukas Rytz wrote:
> or better
> http://github.com/soundrabbit/scala/commit/c13c67dda7c96c290d76a9b8763e559493704b9d
OK - I still crash building quick.lib, but in the expected way?
(Yes/no?) Your commit message references crashing somewhere in Mixin.
Just want to verify we're coming from the same starting blocks.
quick.lib:
[mkdir] Created dir: /scratch/rytz/build/quick/classes/library
[javac] Compiling 25 source files to /scratch/rytz/build/quick/classes/library
[javac] Compiling 41 source files to /scratch/rytz/build/quick/classes/library
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[scalacfork] Compiling 625 files to /scratch/rytz/build/quick/classes/library
[scalacfork] Exception in thread "main" java.lang.AssertionError: assertion failed: class Boolean
[scalacfork] at scala.Predef$.assert(Predef.scala:91)
[scalacfork] at scala.tools.nsc.transform.Mixin.addMixedinMembers(Mixin.scala:221)
[scalacfork] at scala.tools.nsc.transform.Mixin$MixinTransformer.preTransform(Mixin.scala:475)
[scalacfork] at scala.tools.nsc.transform.Mixin$MixinTransformer.transform(Mixin.scala:1075)
[scalacfork] at scala.tools.nsc.ast.Trees$Transformer.transformTemplate(Trees.scala:853)
[scalacfork] at scala.tools.nsc.ast.Trees$Transformer$$anonfun$transform$2.apply(Trees.scala:745)
[scalacfork] at scala.tools.nsc.ast.Trees$Transformer$$anonfun$transform$2.apply(Trees.scala:744)
[scalacfork] at scala.tools.nsc.ast.Trees$Transformer.atOwner(Trees.scala:877)
[scalacfork] at scala.tools.nsc.ast.Trees$Transformer.transform(Trees.scala:743)
[scalacfork] at scala.tools.nsc.transform.Mixin$MixinTransformer.transform(Mixin.scala:1075)
--
Paul Phillips | It is hard to believe that a man is
Stickler | telling the truth when you know that you
Empiricist | would lie if you were in his place.
up hill, pi pals! | -- H. L. Mencken
Fri, 2010-09-10, 21:17
#6
Re: Soruces for Value Classes
On Fri, Sep 10, 2010 at 11:50:46AM +0200, Lukas Rytz wrote:
> or better
> http://github.com/soundrabbit/scala/commit/c13c67dda7c96c290d76a9b8763e5...
OK, if you're up for it take a look at this:
http://github.com/paulp/scala-rytz/commit/1b1d2445435542b52c503d69c3ee07...
Having the box and unbox method maps swapped put a little wrinkle in
things, and the parser thinks anything in any scala package is in
"inScalaPackage" with the result that it thought
scala.dbc.datatype.Boolean was an AnyVal. Beyond that I suppressed some
assertions, falsified some mixin info, and rerouted some scala.runtime.*
references to scala.*
At the above commit it builds and works to a first approximation. I was
able to plug it in as starr and build from scratch without doing the
"Boolean.scala/etc shuffle."
There's a scala.Byte classfile with the right methods:
public boolean $bang$eq(byte);
public boolean $bang$eq(char);
public boolean $bang$eq(double);
public boolean $bang$eq(float);
public boolean $bang$eq(int);
public boolean $bang$eq(long);
public boolean $bang$eq(short);
public boolean $eq$eq(byte);
public boolean $eq$eq(char);
public boolean $eq$eq(double);
public boolean $eq$eq(float);
public boolean $eq$eq(int);
public boolean $eq$eq(long);
public boolean $eq$eq(short);
[etc etc]
And a scala.Byte$ containing:
public final class scala.Byte$ extends java.lang.Object implements scala.runtime.AnyValCompanion,scala.ScalaObject
public static final scala.Byte$ MODULE$;
public static {};
public java.lang.Byte box(byte);
public byte unbox(java.lang.Object);
public byte MinValue();
public byte MaxValue();
It comes shockingly close to passing the test suite: three failures,
probably trivial.
java.lang.RuntimeException: Test suite finished with 3 cases failing:
/scratch/rytz2/test/files/pos/bug404.scala [FAILED]
/scratch/rytz2/test/files/neg/overload-msg.scala [FAILED]
/scratch/rytz2/test/files/run/absoverride.scala [FAILED]
[partest] java.lang.AssertionError: assertion failed: type error: can't convert from CHAR to REFERENCE(java.lang.Object) in unit bug404.scala
[partest] at scala.Predef$.assert(Predef.scala:91)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase.adapt(GenICode.scala:1134)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:1118)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:126)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:81)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:81)
[partest] testing: [...]/files/neg/overload-msg.scala [FAILED]
[partest] overload-msg.scala:3: error: overloaded method value + with alternatives:
[partest] (x: Double)Double
[partest] (x: Float)Float
[partest] (x: Long)Long
[partest] (x: scala.Int)scala.Int
[partest] (x: Char)scala.Int
[partest] (x: Short)scala.Int
[partest] (x: Byte)scala.Int
[partest] (x: String)String
[partest] cannot be applied to (Int(in method f))
[partest] def f[Int](y: Int) = x + y
[partest] ^
[partest] one error found
[partest] java.lang.AssertionError: assertion failed: type error: can't convert from CHAR to REFERENCE(java.lang.Object) in unit absoverride.scala
[partest] at scala.Predef$.assert(Predef.scala:91)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase.adapt(GenICode.scala:1134)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:1118)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:126)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:81)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:81)
Sun, 2010-09-12, 15:17
#7
Re: Soruces for Value Classes
cool
summing up, what is the list of hacks we did? 1. special-case the parser to not add "ScalaObject" (i think the adding of AyVal in the parser could just be done in the sources) 2. special-case the typer to allow value classes to extend from (otherwise sealed) AnyVal 3. add artificial constructor method to AnyVal for typechecking constructor of value classes 4. made AnyValCompanion non-sealed (could be fixed by putting all value classes and companion objects into one file) 5. disabled some assertion in Mixin 6. special case for value classes in the Mixin type transformer
what's different than before? 7. value classes have a constructor 8. MaxValue et al. will probably be method calls from now on (not compiler-inserted constants anymore)
i don't know if that's acceptable. 2 and 3 look ugly, 6 also..let me know what i forgot and what you think. i'll bring it up in the next meeting.
lukas
On Fri, Sep 10, 2010 at 22:07, Paul Phillips <paulp@improving.org> wrote:
summing up, what is the list of hacks we did? 1. special-case the parser to not add "ScalaObject" (i think the adding of AyVal in the parser could just be done in the sources) 2. special-case the typer to allow value classes to extend from (otherwise sealed) AnyVal 3. add artificial constructor method to AnyVal for typechecking constructor of value classes 4. made AnyValCompanion non-sealed (could be fixed by putting all value classes and companion objects into one file) 5. disabled some assertion in Mixin 6. special case for value classes in the Mixin type transformer
what's different than before? 7. value classes have a constructor 8. MaxValue et al. will probably be method calls from now on (not compiler-inserted constants anymore)
i don't know if that's acceptable. 2 and 3 look ugly, 6 also..let me know what i forgot and what you think. i'll bring it up in the next meeting.
lukas
On Fri, Sep 10, 2010 at 22:07, Paul Phillips <paulp@improving.org> wrote:
On Fri, Sep 10, 2010 at 11:50:46AM +0200, Lukas Rytz wrote:
> or better
> http://github.com/soundrabbit/scala/commit/c13c67dda7c96c290d76a9b8763e559493704b9d
OK, if you're up for it take a look at this:
http://github.com/paulp/scala-rytz/commit/1b1d2445435542b52c503d69c3ee070b74a393a8
Having the box and unbox method maps swapped put a little wrinkle in
things, and the parser thinks anything in any scala package is in
"inScalaPackage" with the result that it thought
scala.dbc.datatype.Boolean was an AnyVal. Beyond that I suppressed some
assertions, falsified some mixin info, and rerouted some scala.runtime.*
references to scala.*
At the above commit it builds and works to a first approximation. I was
able to plug it in as starr and build from scratch without doing the
"Boolean.scala/etc shuffle."
There's a scala.Byte classfile with the right methods:
public boolean $bang$eq(byte);
public boolean $bang$eq(char);
public boolean $bang$eq(double);
public boolean $bang$eq(float);
public boolean $bang$eq(int);
public boolean $bang$eq(long);
public boolean $bang$eq(short);
public boolean $eq$eq(byte);
public boolean $eq$eq(char);
public boolean $eq$eq(double);
public boolean $eq$eq(float);
public boolean $eq$eq(int);
public boolean $eq$eq(long);
public boolean $eq$eq(short);
[etc etc]
And a scala.Byte$ containing:
public final class scala.Byte$ extends java.lang.Object implements scala.runtime.AnyValCompanion,scala.ScalaObject
public static final scala.Byte$ MODULE$;
public static {};
public java.lang.Byte box(byte);
public byte unbox(java.lang.Object);
public byte MinValue();
public byte MaxValue();
It comes shockingly close to passing the test suite: three failures,
probably trivial.
java.lang.RuntimeException: Test suite finished with 3 cases failing:
/scratch/rytz2/test/files/pos/bug404.scala [FAILED]
/scratch/rytz2/test/files/neg/overload-msg.scala [FAILED]
/scratch/rytz2/test/files/run/absoverride.scala [FAILED]
[partest] java.lang.AssertionError: assertion failed: type error: can't convert from CHAR to REFERENCE(java.lang.Object) in unit bug404.scala
[partest] at scala.Predef$.assert(Predef.scala:91)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase.adapt(GenICode.scala:1134)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:1118)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:126)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:81)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:81)
[partest] testing: [...]/files/neg/overload-msg.scala [FAILED]
[partest] overload-msg.scala:3: error: overloaded method value + with alternatives:
[partest] (x: Double)Double <and>
[partest] (x: Float)Float <and>
[partest] (x: Long)Long <and>
[partest] (x: scala.Int)scala.Int <and>
[partest] (x: Char)scala.Int <and>
[partest] (x: Short)scala.Int <and>
[partest] (x: Byte)scala.Int <and>
[partest] (x: String)String
[partest] cannot be applied to (Int(in method f))
[partest] def f[Int](y: Int) = x + y
[partest] ^
[partest] one error found
[partest] java.lang.AssertionError: assertion failed: type error: can't convert from CHAR to REFERENCE(java.lang.Object) in unit absoverride.scala
[partest] at scala.Predef$.assert(Predef.scala:91)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase.adapt(GenICode.scala:1134)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:1118)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:126)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:81)
[partest] at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:81)
--
Paul Phillips | It's better to have gloved and tossed than never to
Protagonist | have played baseball.
Empiricist |
i'll ship a pulp |----------* http://www.improving.org/paulp/ *----------
Sun, 2010-09-12, 18:17
#8
Re: Soruces for Value Classes
On Sun, Sep 12, 2010 at 04:12:24PM +0200, Lukas Rytz wrote:
> summing up, what is the list of hacks we did?
At the memont there's also at least:
* disabled an assertion in ScalaPrimitives since a bunch of methods were
being added twice.
> 7. value classes have a constructor
> 8. MaxValue et al. will probably be method calls from now on (not
> compiler-inserted constants anymore)
We also now have a scala.runtime.Boolean and a scala.Boolean for no
reason I can think of - they should be consolidated.
> i don't know if that's acceptable. 2 and 3 look ugly, 6 also..
I don't think it's at all acceptable the way it is, just a proof of
concept. But hopefully it's proofy enough that we can get an opinion
from martin about what an acceptable variation would look like.
Fri, 2010-09-17, 10:17
#9
Re: Soruces for Value Classes
Paul,
our conclusion on this one was that it's a good thing to do in general, notonly scaladoc would profit but also other tools (colladoc, all the IDEs, etc).
According to Martin the hacks are not show-stoppers, so if we clean up the implementation this could go in.
I'm not very happy about the artificial constructor symbol in AnyVal, maybewe better special-case the Constructors phase for children of AnyVal.
The companion objects in runtime (runtime.Boolean etc) can go, they areused only as arguments to @specialized.
How do we move on with the code? My git-fu is not up to date for this kind of collaboration :)
Lukas
On Sun, Sep 12, 2010 at 19:08, Paul Phillips <paulp@improving.org> wrote:
our conclusion on this one was that it's a good thing to do in general, notonly scaladoc would profit but also other tools (colladoc, all the IDEs, etc).
According to Martin the hacks are not show-stoppers, so if we clean up the implementation this could go in.
I'm not very happy about the artificial constructor symbol in AnyVal, maybewe better special-case the Constructors phase for children of AnyVal.
The companion objects in runtime (runtime.Boolean etc) can go, they areused only as arguments to @specialized.
How do we move on with the code? My git-fu is not up to date for this kind of collaboration :)
Lukas
On Sun, Sep 12, 2010 at 19:08, Paul Phillips <paulp@improving.org> wrote:
On Sun, Sep 12, 2010 at 04:12:24PM +0200, Lukas Rytz wrote:
> summing up, what is the list of hacks we did?
At the memont there's also at least:
* disabled an assertion in ScalaPrimitives since a bunch of methods were
being added twice.
> 7. value classes have a constructor
> 8. MaxValue et al. will probably be method calls from now on (not
> compiler-inserted constants anymore)
We also now have a scala.runtime.Boolean and a scala.Boolean for no
reason I can think of - they should be consolidated.
> i don't know if that's acceptable. 2 and 3 look ugly, 6 also..
I don't think it's at all acceptable the way it is, just a proof of
concept. But hopefully it's proofy enough that we can get an opinion
from martin about what an acceptable variation would look like.
--
Paul Phillips | The most dangerous man to any government is the man who
Caged Spirit | is able to think things out [...] Almost inevitably he
Empiricist | comes to the conclusion that the government he lives under
all hip pupils! | is dishonest, insane, intolerable. -- H. L. Mencken
Fri, 2010-09-17, 11:27
#10
Re: Soruces for Value Classes
On Fri, Sep 17, 2010 at 11:14 AM, Lukas Rytz <lukas.rytz@epfl.ch> wrote:
Paul,
our conclusion on this one was that it's a good thing to do in general, notonly scaladoc would profit but also other tools (colladoc, all the IDEs, etc).
According to Martin the hacks are not show-stoppers, so if we clean up the implementation this could go in.
I'm not very happy about the artificial constructor symbol in AnyVal, maybewe better special-case the Constructors phase for children of AnyVal.
The companion objects in runtime (runtime.Boolean etc) can go, they areused only as arguments to @specialized.
The arguments to @specialized are the companion objects of primitive types (scala.Int and so on). The runtime objects existed only for the JVM, so that scala.Int is truly an object that can be passed around. If now you have scala.Int as a top level object that can be instantiated, that's all right.
How do we move on with the code? My git-fu is not up to date for this kind of collaboration :)
Lukas
On Sun, Sep 12, 2010 at 19:08, Paul Phillips <paulp@improving.org> wrote:
On Sun, Sep 12, 2010 at 04:12:24PM +0200, Lukas Rytz wrote:
> summing up, what is the list of hacks we did?
At the memont there's also at least:
* disabled an assertion in ScalaPrimitives since a bunch of methods were
being added twice.
> 7. value classes have a constructor
> 8. MaxValue et al. will probably be method calls from now on (not
> compiler-inserted constants anymore)
We also now have a scala.runtime.Boolean and a scala.Boolean for no
reason I can think of - they should be consolidated.
> i don't know if that's acceptable. 2 and 3 look ugly, 6 also..
I don't think it's at all acceptable the way it is, just a proof of
concept. But hopefully it's proofy enough that we can get an opinion
from martin about what an acceptable variation would look like.
--
Paul Phillips | The most dangerous man to any government is the man who
Caged Spirit | is able to think things out [...] Almost inevitably he
Empiricist | comes to the conclusion that the government he lives under
all hip pupils! | is dishonest, insane, intolerable. -- H. L. Mencken
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
Wed, 2010-09-22, 06:27
#11
Re: Soruces for Value Classes
On Fri, Sep 17, 2010 at 11:14:03AM +0200, Lukas Rytz wrote:
> How do we move on with the code? My git-fu is not up to date for this
> kind of collaboration :)
Sorry this got a little caught in the shuffle. You could simplify the
fu for both of us by cloning the repo at
and git-am-ing in your existing branches. You're working off your own
private git-svn clone, right? I don't have any real experience working
with other people either (isn't that much obvious?) but I will set the
code blender to "frappe", and all we need are the ingredients.
Wed, 2010-09-22, 09:37
#12
Re: Soruces for Value Classes
if i clone or fork from there, can i still commit to svn?
On Wednesday, September 22, 2010, Paul Phillips wrote:
> On Fri, Sep 17, 2010 at 11:14:03AM +0200, Lukas Rytz wrote:
>> How do we move on with the code? My git-fu is not up to date for this
>> kind of collaboration :)
>
> Sorry this got a little caught in the shuffle. You could simplify the
> fu for both of us by cloning the repo at
>
> http://github.com/scala/scala
>
> and git-am-ing in your existing branches. You're working off your own
> private git-svn clone, right? I don't have any real experience working
> with other people either (isn't that much obvious?) but I will set the
> code blender to "frappe", and all we need are the ingredients.
>
> --
> Paul Phillips | Christ died for our sins. Dare we make his martyrdom
> Imperfectionist | meaningless by not committing them?
> Empiricist | -- Jules Feiffer
> pull his pi pal! |----------* http://www.improving.org/paulp/ *----------
>
Wed, 2010-09-22, 10:07
#13
Re: Soruces for Value Classes
On Wed, Sep 22, 2010 at 10:28:24AM +0200, Lukas Rytz wrote:
> if i clone or fork from there, can i still commit to svn?
You surely can. You might need to tweak a setting so it knows where: or
here are two aliases I get a lot of mileage out of. If you put these
lines in .git/config then "git gpdry" will show you what would be
committed and "git gp" will do it.
[alias]
gp = !git svn dcommit --commit-url https://lampsvn.epfl.ch/svn-repos/scala/scala/trunk
gpdry = !git svn --dry-run dcommit --commit-url https://lampsvn.epfl.ch/svn-repos/scala/scala/trunk
Wed, 2010-09-22, 15:47
#14
Re: Soruces for Value Classes
OK, thanks, but somehow it doesn't work for me, i get after 1 minute of waiting
don't I need to add some git-svn metadata?
Another question: how & how often is github/scala/scala updated to svn trunk?because right now it's not up to date and thus I guess committing to svn would fail ayway.
Back to the topic: see the following :) http://lampsvn.epfl.ch/trac/scala/changeset/7063
Lukas
On Wed, Sep 22, 2010 at 11:06, Paul Phillips <paulp@improving.org> wrote:
lamppc11:git luc$ git svn dcommit --commit-url https://lampsvn.epfl.ch/svn-repos/scala/scala/trunk Unable to determine upstream SVN information from HEAD history.Perhaps the repository is empty. at /usr/local/git/libexec/git-core/git-svn line 519.
don't I need to add some git-svn metadata?
Another question: how & how often is github/scala/scala updated to svn trunk?because right now it's not up to date and thus I guess committing to svn would fail ayway.
Back to the topic: see the following :) http://lampsvn.epfl.ch/trac/scala/changeset/7063
Lukas
On Wed, Sep 22, 2010 at 11:06, Paul Phillips <paulp@improving.org> wrote:
On Wed, Sep 22, 2010 at 10:28:24AM +0200, Lukas Rytz wrote:
> if i clone or fork from there, can i still commit to svn?
You surely can. You might need to tweak a setting so it knows where: or
here are two aliases I get a lot of mileage out of. If you put these
lines in .git/config then "git gpdry" will show you what would be
committed and "git gp" will do it.
[alias]
gp = !git svn dcommit --commit-url https://lampsvn.epfl.ch/svn-repos/scala/scala/trunk
gpdry = !git svn --dry-run dcommit --commit-url https://lampsvn.epfl.ch/svn-repos/scala/scala/trunk
--
Paul Phillips | Christ died for our sins. Dare we make his martyrdom
Future Perfect | meaningless by not committing them?
Empiricist | -- Jules Feiffer
i pull his palp! |----------* http://www.improving.org/paulp/ *----------
Wed, 2010-09-22, 18:47
#15
Re: Soruces for Value Classes
On Wed, Sep 22, 2010 at 04:45:18PM +0200, Lukas Rytz wrote:
> don't I need to add some git-svn metadata?
Oh shoot. I forgot about the non-transitivity of the svn aspects.
People like to handwavily suggest that git-svn is about as good as a
real git master, but we are now hurtling toward the zone of untruth.
I offer these links but I'm not in the least suggesting you do any of
it, because I know from tearful experience what a time sink this kind of
fiddling can be and it's not that big a deal to work off your repo.
https://git.wiki.kernel.org/index.php/GitSvnSwitch
http://thread.gmane.org/gmane.comp.version-control.git/59271
> Another question: how & how often is github/scala/scala updated to svn
> trunk?
It's not automated right now. I do it at least once a day, usually. I
could automate it but it hasn't seemed pressing. Clearly that would be
an issue to resolve if you could actually use the repo and it stood in
the way of your ability to commit.
> Back to the topic: see the following :)
> http://lampsvn.epfl.ch/trac/scala/changeset/7063
I will!
Fri, 2010-09-24, 15:37
#16
Re: Soruces for Value Classes
Looking at the level of hacking required I go back to my repo...
After fiddling around I merged your changes into my repo, let'scontinue from here (you need to fork again, it's a different tree):
http://github.com/soundrabbit/scala/commits/anyValSource
That was more for the entertainment, I still think we should do it.Cheers: Lukas
After fiddling around I merged your changes into my repo, let'scontinue from here (you need to fork again, it's a different tree):
http://github.com/soundrabbit/scala/commits/anyValSource
> Back to the topic: see the following :)
> http://lampsvn.epfl.ch/trac/scala/changeset/7063
I will!
That was more for the entertainment, I still think we should do it.Cheers: Lukas
Fri, 2010-11-12, 15:37
#17
Re: Re: Soruces for Value Classes
Speaking on the AnyVal companion objects, (support for which just
landed in IntelliJ): why are Double.MaxValue et al defs rather than
vals?
It would seem natural to use these as stable ids in pattern matching.
val (Double.MaxValue, a) = (Double.MaxValue, 0)
-jason
On Fri, Sep 24, 2010 at 4:35 PM, Lukas Rytz wrote:
> Looking at the level of hacking required I go back to my repo...
> After fiddling around I merged your changes into my repo, let's
> continue from here (you need to fork again, it's a different tree):
> http://github.com/soundrabbit/scala/commits/anyValSource
>>
>> > Back to the topic: see the following :)
>> > http://lampsvn.epfl.ch/trac/scala/changeset/7063
>>
>> I will!
>
> That was more for the entertainment, I still think we should do it.
> Cheers: Lukas
Thu, 2011-01-20, 07:57
#18
Re: Soruces for Value Classes
Some implementation notes that I can think of:
On Sun, Sep 12, 2010 at 04:12:24PM +0200, Lukas Rytz wrote:
> summing up, what is the list of hacks we did?
> 1. special-case the parser to not add "ScalaObject" (i think the
> adding of AyVal in the parser could just be done in the sources)
I am extending AnyVal at source level, but still had to special case the
parser, because otherwise it acquires an AnyRef parent as well. This
actually had me confused the longest of anything; I couldn't pin down
why AnyRef wouldn't go away. Finally I kicked it like this, in
Definitions.init.
private def setParents(sym: Symbol, parents: List[Type]): Symbol = sym.rawInfo match {
case ClassInfoType(_, scope, clazz) =>
sym setInfo ClassInfoType(parents, scope, clazz)
case _ =>
sym
}
setParents(AnyValClass, anyparam)
ScalaValueClasses foreach { sym =>
setParents(sym, anyvalparam)
}
> 2. special-case the typer to allow value classes to extend from
> (otherwise sealed) AnyVal
Still special-cased.
if (context.unit.source.file == psym.sourceFile || isValueClass(context.owner))
psym addChild context.owner
else
error(parent.pos, "illegal inheritance from sealed "+psym)
> 3. add artificial constructor method to AnyVal for typechecking
> constructor of value classes
This one I was able to avoid. No fake constructors.
> 4. made AnyValCompanion non-sealed (could be fixed by putting all
> value classes and companion objects into one file)
I figure to fold it into the check for 2. above, and say if
isValueClassOrCompanion. If we're going to leave 2 as-is then it's a
no-brainer; or whatever we do for that we can do for this.
> 5. disabled some assertion in Mixin
That is all back the way it was without failing, as is the assertion in
ScalaPrimitives which was kicking over duplicate primitives.
> 6. special case for value classes in the Mixin type transformer
I ditched that as well. I confirmed that the baseTypeSeqs are as they
were, which I show for AnyVal and for 1/9 value types here.
scala> power.atAllPhases(global.definitions.IntClass.tpe.baseTypeSeq) foreach println
(parser,BTS(Int,AnyVal,Any))
(namer,BTS(Int,AnyVal,Any))
(packageobjects,BTS(Int,AnyVal,Any))
(typer,BTS(Int,AnyVal,Any))
(superaccessors,BTS(Int,AnyVal,Any))
(pickler,BTS(Int,AnyVal,Any))
(refchecks,BTS(Int,AnyVal,Any))
(selectiveanf,BTS(Int,AnyVal,Any))
(liftcode,BTS(Int,AnyVal,Any))
(selectivecps,BTS(Int,AnyVal,Any))
(uncurry,BTS(Int,AnyVal,Any))
(tailcalls,BTS(Int,AnyVal,Any))
(specialize,BTS(Int,AnyVal,Any))
(explicitouter,BTS(Int,AnyVal,Any))
(erasure,BTS(Int,AnyVal,Any))
(lazyvals,BTS(Int))
(lambdalift,BTS(Int))
(constructors,BTS(Int))
(flatten,BTS(Int))
(mixin,BTS(Int))
(cleanup,BTS(Int))
(icode,BTS(Int))
(inliner,BTS(Int))
(closelim,BTS(Int))
(dce,BTS(Int))
(jvm,BTS(Int))
(terminal,BTS(Int))
scala> power.atAllPhases(global.definitions.AnyValClass.tpe.baseTypeSeq) foreach println
(parser,BTS(AnyVal,Any))
(namer,BTS(AnyVal,Any))
(packageobjects,BTS(AnyVal,Any))
(typer,BTS(AnyVal,Any))
(superaccessors,BTS(AnyVal,Any))
(pickler,BTS(AnyVal,Any))
(refchecks,BTS(AnyVal,Any))
(selectiveanf,BTS(AnyVal,Any))
(liftcode,BTS(AnyVal,Any))
(selectivecps,BTS(AnyVal,Any))
(uncurry,BTS(AnyVal,Any))
(tailcalls,BTS(AnyVal,Any))
(specialize,BTS(AnyVal,Any))
(explicitouter,BTS(AnyVal,Any))
(erasure,BTS(AnyVal,Any))
(lazyvals,BTS(AnyVal,java.lang.Object,Any))
(lambdalift,BTS(AnyVal,java.lang.Object,Any))
(constructors,BTS(AnyVal,java.lang.Object,Any))
(flatten,BTS(AnyVal,java.lang.Object,Any))
(mixin,BTS(AnyVal,java.lang.Object,Any))
(cleanup,BTS(AnyVal,java.lang.Object,Any))
(icode,BTS(AnyVal,java.lang.Object,Any))
(inliner,BTS(AnyVal,java.lang.Object,Any))
(closelim,BTS(AnyVal,java.lang.Object,Any))
(dce,BTS(AnyVal,java.lang.Object,Any))
(jvm,BTS(AnyVal,java.lang.Object,Any))
(terminal,BTS(AnyVal,java.lang.Object,Any))
> 7. value classes have a constructor
No constructors.
> 8. MaxValue et al. will probably be method calls from now on (not
> compiler-inserted constants anymore)
Right now that is true, but only because your source files have them
declared like
val MinValue: Long = jl.Long.MIN_VALUE
If we declare them as
final val MinValue = jl.Long.MIN_VALUE
then they will be inlined as I presume they were before.
Thu, 2011-01-20, 09:27
#19
Re: Soruces for Value Classes
Cool, thanks Paul for picking up this one!
Note that the source files are generated by a modified genprod, so you can easily make changes (i.e. from "def MaxValue" to"final val MaxValue"). Or, assuming that you are aware of that,why is there no modified genprod in your commit?
Otherwise the changes look good to me at a first glance.
Lukas
On Thu, Jan 20, 2011 at 07:53, Paul Phillips <paulp@improving.org> wrote:
Note that the source files are generated by a modified genprod, so you can easily make changes (i.e. from "def MaxValue" to"final val MaxValue"). Or, assuming that you are aware of that,why is there no modified genprod in your commit?
Otherwise the changes look good to me at a first glance.
Lukas
On Thu, Jan 20, 2011 at 07:53, Paul Phillips <paulp@improving.org> wrote:
Some implementation notes that I can think of:
On Sun, Sep 12, 2010 at 04:12:24PM +0200, Lukas Rytz wrote:
> summing up, what is the list of hacks we did?
> 1. special-case the parser to not add "ScalaObject" (i think the
> adding of AyVal in the parser could just be done in the sources)
I am extending AnyVal at source level, but still had to special case the
parser, because otherwise it acquires an AnyRef parent as well. This
actually had me confused the longest of anything; I couldn't pin down
why AnyRef wouldn't go away. Finally I kicked it like this, in
Definitions.init.
private def setParents(sym: Symbol, parents: List[Type]): Symbol = sym.rawInfo match {
case ClassInfoType(_, scope, clazz) =>
sym setInfo ClassInfoType(parents, scope, clazz)
case _ =>
sym
}
setParents(AnyValClass, anyparam)
ScalaValueClasses foreach { sym =>
setParents(sym, anyvalparam)
}
> 2. special-case the typer to allow value classes to extend from
> (otherwise sealed) AnyVal
Still special-cased.
if (context.unit.source.file == psym.sourceFile || isValueClass(context.owner))
psym addChild context.owner
else
error(parent.pos, "illegal inheritance from sealed "+psym)
> 3. add artificial constructor method to AnyVal for typechecking
> constructor of value classes
This one I was able to avoid. No fake constructors.
> 4. made AnyValCompanion non-sealed (could be fixed by putting all
> value classes and companion objects into one file)
I figure to fold it into the check for 2. above, and say if
isValueClassOrCompanion. If we're going to leave 2 as-is then it's a
no-brainer; or whatever we do for that we can do for this.
> 5. disabled some assertion in Mixin
That is all back the way it was without failing, as is the assertion in
ScalaPrimitives which was kicking over duplicate primitives.
> 6. special case for value classes in the Mixin type transformer
I ditched that as well. I confirmed that the baseTypeSeqs are as they
were, which I show for AnyVal and for 1/9 value types here.
scala> power.atAllPhases(global.definitions.IntClass.tpe.baseTypeSeq) foreach println
(parser,BTS(Int,AnyVal,Any))
(namer,BTS(Int,AnyVal,Any))
(packageobjects,BTS(Int,AnyVal,Any))
(typer,BTS(Int,AnyVal,Any))
(superaccessors,BTS(Int,AnyVal,Any))
(pickler,BTS(Int,AnyVal,Any))
(refchecks,BTS(Int,AnyVal,Any))
(selectiveanf,BTS(Int,AnyVal,Any))
(liftcode,BTS(Int,AnyVal,Any))
(selectivecps,BTS(Int,AnyVal,Any))
(uncurry,BTS(Int,AnyVal,Any))
(tailcalls,BTS(Int,AnyVal,Any))
(specialize,BTS(Int,AnyVal,Any))
(explicitouter,BTS(Int,AnyVal,Any))
(erasure,BTS(Int,AnyVal,Any))
(lazyvals,BTS(Int))
(lambdalift,BTS(Int))
(constructors,BTS(Int))
(flatten,BTS(Int))
(mixin,BTS(Int))
(cleanup,BTS(Int))
(icode,BTS(Int))
(inliner,BTS(Int))
(closelim,BTS(Int))
(dce,BTS(Int))
(jvm,BTS(Int))
(terminal,BTS(Int))
scala> power.atAllPhases(global.definitions.AnyValClass.tpe.baseTypeSeq) foreach println
(parser,BTS(AnyVal,Any))
(namer,BTS(AnyVal,Any))
(packageobjects,BTS(AnyVal,Any))
(typer,BTS(AnyVal,Any))
(superaccessors,BTS(AnyVal,Any))
(pickler,BTS(AnyVal,Any))
(refchecks,BTS(AnyVal,Any))
(selectiveanf,BTS(AnyVal,Any))
(liftcode,BTS(AnyVal,Any))
(selectivecps,BTS(AnyVal,Any))
(uncurry,BTS(AnyVal,Any))
(tailcalls,BTS(AnyVal,Any))
(specialize,BTS(AnyVal,Any))
(explicitouter,BTS(AnyVal,Any))
(erasure,BTS(AnyVal,Any))
(lazyvals,BTS(AnyVal,java.lang.Object,Any))
(lambdalift,BTS(AnyVal,java.lang.Object,Any))
(constructors,BTS(AnyVal,java.lang.Object,Any))
(flatten,BTS(AnyVal,java.lang.Object,Any))
(mixin,BTS(AnyVal,java.lang.Object,Any))
(cleanup,BTS(AnyVal,java.lang.Object,Any))
(icode,BTS(AnyVal,java.lang.Object,Any))
(inliner,BTS(AnyVal,java.lang.Object,Any))
(closelim,BTS(AnyVal,java.lang.Object,Any))
(dce,BTS(AnyVal,java.lang.Object,Any))
(jvm,BTS(AnyVal,java.lang.Object,Any))
(terminal,BTS(AnyVal,java.lang.Object,Any))
> 7. value classes have a constructor
No constructors.
> 8. MaxValue et al. will probably be method calls from now on (not
> compiler-inserted constants anymore)
Right now that is true, but only because your source files have them
declared like
val MinValue: Long = jl.Long.MIN_VALUE
If we declare them as
final val MinValue = jl.Long.MIN_VALUE
then they will be inlined as I presume they were before.
--
Paul Phillips | If this is raisin, make toast with it.
In Theory |
Empiricist |
ha! spill, pupil |----------* http://www.improving.org/paulp/ *----------
Thu, 2011-01-20, 09:47
#20
Re: Soruces for Value Classes
On Thu, Jan 20, 2011 at 09:17:24AM +0100, Lukas Rytz wrote:
> Or, assuming that you are aware of that, why is there no modified
> genprod in your commit?
Yeah, I knew they were generated but I forgot exactly where they came
from. No doubt they should be sucked upward a level.
Thu, 2011-01-20, 10:27
#21
Re: Soruces for Value Classes
`def MaxValue` correctly describes the synthetic member.
scala> val (Double.MaxValue, a) = (Double.MaxValue, 0)
:5: error: stable identifier required, but scala.Double.MaxValue found.
val (Double.MaxValue, a) = (Double.MaxValue, 0)
I would prefer it to be a final val. But wouldn't this require a
corresponding change elsewhere in the compiler?
-jason
On Thu, Jan 20, 2011 at 9:17 AM, Lukas Rytz wrote:
> Cool, thanks Paul for picking up this one!
> Note that the source files are generated by a modified genprod,
> so you can easily make changes (i.e. from "def MaxValue" to
> "final val MaxValue"). Or, assuming that you are aware of that,
> why is there no modified genprod in your commit?
> Otherwise the changes look good to me at a first glance.
> Lukas
>
>
>
> On Thu, Jan 20, 2011 at 07:53, Paul Phillips wrote:
>>
>> Some implementation notes that I can think of:
>>
>> On Sun, Sep 12, 2010 at 04:12:24PM +0200, Lukas Rytz wrote:
>> > summing up, what is the list of hacks we did?
>>
>> > 1. special-case the parser to not add "ScalaObject" (i think the
>> > adding of AyVal in the parser could just be done in the sources)
>>
>> I am extending AnyVal at source level, but still had to special case the
>> parser, because otherwise it acquires an AnyRef parent as well. This
>> actually had me confused the longest of anything; I couldn't pin down
>> why AnyRef wouldn't go away. Finally I kicked it like this, in
>> Definitions.init.
>>
>> private def setParents(sym: Symbol, parents: List[Type]): Symbol =
>> sym.rawInfo match {
>> case ClassInfoType(_, scope, clazz) =>
>> sym setInfo ClassInfoType(parents, scope, clazz)
>> case _ =>
>> sym
>> }
>>
>> setParents(AnyValClass, anyparam)
>> ScalaValueClasses foreach { sym =>
>> setParents(sym, anyvalparam)
>> }
>>
>> > 2. special-case the typer to allow value classes to extend from
>> > (otherwise sealed) AnyVal
>>
>> Still special-cased.
>>
>> if (context.unit.source.file == psym.sourceFile ||
>> isValueClass(context.owner))
>> psym addChild context.owner
>> else
>> error(parent.pos, "illegal inheritance from sealed "+psym)
>>
>> > 3. add artificial constructor method to AnyVal for typechecking
>> > constructor of value classes
>>
>> This one I was able to avoid. No fake constructors.
>>
>> > 4. made AnyValCompanion non-sealed (could be fixed by putting all
>> > value classes and companion objects into one file)
>>
>> I figure to fold it into the check for 2. above, and say if
>> isValueClassOrCompanion. If we're going to leave 2 as-is then it's a
>> no-brainer; or whatever we do for that we can do for this.
>>
>> > 5. disabled some assertion in Mixin
>>
>> That is all back the way it was without failing, as is the assertion in
>> ScalaPrimitives which was kicking over duplicate primitives.
>>
>> > 6. special case for value classes in the Mixin type transformer
>>
>> I ditched that as well. I confirmed that the baseTypeSeqs are as they
>> were, which I show for AnyVal and for 1/9 value types here.
>>
>> scala> power.atAllPhases(global.definitions.IntClass.tpe.baseTypeSeq)
>> foreach println
>> (parser,BTS(Int,AnyVal,Any))
>> (namer,BTS(Int,AnyVal,Any))
>> (packageobjects,BTS(Int,AnyVal,Any))
>> (typer,BTS(Int,AnyVal,Any))
>> (superaccessors,BTS(Int,AnyVal,Any))
>> (pickler,BTS(Int,AnyVal,Any))
>> (refchecks,BTS(Int,AnyVal,Any))
>> (selectiveanf,BTS(Int,AnyVal,Any))
>> (liftcode,BTS(Int,AnyVal,Any))
>> (selectivecps,BTS(Int,AnyVal,Any))
>> (uncurry,BTS(Int,AnyVal,Any))
>> (tailcalls,BTS(Int,AnyVal,Any))
>> (specialize,BTS(Int,AnyVal,Any))
>> (explicitouter,BTS(Int,AnyVal,Any))
>> (erasure,BTS(Int,AnyVal,Any))
>> (lazyvals,BTS(Int))
>> (lambdalift,BTS(Int))
>> (constructors,BTS(Int))
>> (flatten,BTS(Int))
>> (mixin,BTS(Int))
>> (cleanup,BTS(Int))
>> (icode,BTS(Int))
>> (inliner,BTS(Int))
>> (closelim,BTS(Int))
>> (dce,BTS(Int))
>> (jvm,BTS(Int))
>> (terminal,BTS(Int))
>>
>> scala> power.atAllPhases(global.definitions.AnyValClass.tpe.baseTypeSeq)
>> foreach println
>> (parser,BTS(AnyVal,Any))
>> (namer,BTS(AnyVal,Any))
>> (packageobjects,BTS(AnyVal,Any))
>> (typer,BTS(AnyVal,Any))
>> (superaccessors,BTS(AnyVal,Any))
>> (pickler,BTS(AnyVal,Any))
>> (refchecks,BTS(AnyVal,Any))
>> (selectiveanf,BTS(AnyVal,Any))
>> (liftcode,BTS(AnyVal,Any))
>> (selectivecps,BTS(AnyVal,Any))
>> (uncurry,BTS(AnyVal,Any))
>> (tailcalls,BTS(AnyVal,Any))
>> (specialize,BTS(AnyVal,Any))
>> (explicitouter,BTS(AnyVal,Any))
>> (erasure,BTS(AnyVal,Any))
>> (lazyvals,BTS(AnyVal,java.lang.Object,Any))
>> (lambdalift,BTS(AnyVal,java.lang.Object,Any))
>> (constructors,BTS(AnyVal,java.lang.Object,Any))
>> (flatten,BTS(AnyVal,java.lang.Object,Any))
>> (mixin,BTS(AnyVal,java.lang.Object,Any))
>> (cleanup,BTS(AnyVal,java.lang.Object,Any))
>> (icode,BTS(AnyVal,java.lang.Object,Any))
>> (inliner,BTS(AnyVal,java.lang.Object,Any))
>> (closelim,BTS(AnyVal,java.lang.Object,Any))
>> (dce,BTS(AnyVal,java.lang.Object,Any))
>> (jvm,BTS(AnyVal,java.lang.Object,Any))
>> (terminal,BTS(AnyVal,java.lang.Object,Any))
>>
>> > 7. value classes have a constructor
>>
>> No constructors.
>>
>> > 8. MaxValue et al. will probably be method calls from now on (not
>> > compiler-inserted constants anymore)
>>
>> Right now that is true, but only because your source files have them
>> declared like
>>
>> val MinValue: Long = jl.Long.MIN_VALUE
>>
>> If we declare them as
>>
>> final val MinValue = jl.Long.MIN_VALUE
>>
>> then they will be inlined as I presume they were before.
>>
>> --
>> Paul Phillips | If this is raisin, make toast with it.
>> In Theory |
>> Empiricist |
>> ha! spill, pupil |----------* http://www.improving.org/paulp/
>> *----------
>
>
Thu, 2011-01-20, 10:47
#22
Re: Soruces for Value Classes
On Thu, Jan 20, 2011 at 10:18:08AM +0100, Jason Zaugg wrote:
> scala> val (Double.MaxValue, a) = (Double.MaxValue, 0)
> :5: error: stable identifier required, but scala.Double.MaxValue found.
> val (Double.MaxValue, a) = (Double.MaxValue, 0)
>
> I would prefer it to be a final val. But wouldn't this require a
> corresponding change elsewhere in the compiler?
That's the beauty of the patch. Those are the actual anyval companion
implementations in the source files. One change only. Where would be
the corresponding change you envision?
Thu, 2011-01-20, 10:57
#23
Re: Soruces for Value Classes
On Thu, Jan 20, 2011 at 10:44 AM, Paul Phillips wrote:
> On Thu, Jan 20, 2011 at 10:18:08AM +0100, Jason Zaugg wrote:
>> I would prefer it to be a final val. But wouldn't this require a
>> corresponding change elsewhere in the compiler?
>
> That's the beauty of the patch. Those are the actual anyval companion
> implementations in the source files. One change only. Where would be
> the corresponding change you envision?
Somewhere in the Dark Ages, it would seem.
Thanks for clarifying!
-jason
Thu, 2011-01-20, 17:07
#24
Re: Soruces for Value Classes
On Thu, Jan 20, 2011 at 04:53, Paul Phillips <paulp@improving.org> wrote:
I do wonder if the semantics of "sealed" wouldn't be just as fine if the restriction was weakened to just files compiled at the same time. I mean, say A is a sealed trait on file A.scala, then:
scalac A.scala # Only stuff inside A.scala can extend A
scalac A.scala B.scala C.scala # Anything on A.scala, B.scala or C.scala can extend A
--
Daniel C. Sobral
I travel to the future all the time.
Some implementation notes that I can think of:
On Sun, Sep 12, 2010 at 04:12:24PM +0200, Lukas Rytz wrote:
> summing up, what is the list of hacks we did?
> 2. special-case the typer to allow value classes to extend from
> (otherwise sealed) AnyVal
Still special-cased.
if (context.unit.source.file == psym.sourceFile || isValueClass(context.owner))
psym addChild context.owner
else
error(parent.pos, "illegal inheritance from sealed "+psym)
I do wonder if the semantics of "sealed" wouldn't be just as fine if the restriction was weakened to just files compiled at the same time. I mean, say A is a sealed trait on file A.scala, then:
scalac A.scala # Only stuff inside A.scala can extend A
scalac A.scala B.scala C.scala # Anything on A.scala, B.scala or C.scala can extend A
--
Daniel C. Sobral
I travel to the future all the time.
Thu, 2011-01-20, 17:27
#25
Re: Soruces for Value Classes
On Thu, Jan 20, 2011 at 5:03 PM, Daniel Sobral <dcsobral@gmail.com> wrote:
On Thu, Jan 20, 2011 at 04:53, Paul Phillips <paulp@improving.org> wrote:Please no! It's a meta-requirement that Scala's spec should not depend on compilation order or the question what is compiled together.Some implementation notes that I can think of:
On Sun, Sep 12, 2010 at 04:12:24PM +0200, Lukas Rytz wrote:
> summing up, what is the list of hacks we did?
> 2. special-case the typer to allow value classes to extend from
> (otherwise sealed) AnyVal
Still special-cased.
if (context.unit.source.file == psym.sourceFile || isValueClass(context.owner))
psym addChild context.owner
else
error(parent.pos, "illegal inheritance from sealed "+psym)
I do wonder if the semantics of "sealed" wouldn't be just as fine if the restriction was weakened to just files compiled at the same time. I mean, say A is a sealed trait on file A.scala, then:
scalac A.scala # Only stuff inside A.scala can extend A
scalac A.scala B.scala C.scala # Anything on A.scala, B.scala or C.scala can extend A
-- Martin
Thu, 2011-01-20, 23:47
#26
Re: Soruces for Value Classes
On Thu, Jan 20, 2011 at 14:22, martin odersky <martin.odersky@epfl.ch> wrote:
That's fine, but please note that having the meaning of "sealed" depend on a particular detail of storage unit isn't all that different -- it still depends on something that is not part of the source code, but rather on how the programmer is doing it. In one case, the programmer puts different pieces of code in the same file to achieve the result he wants, and in the other case he compiles the same different pieces at the same time to achieve that result. Which reminds me of Java's directory/filename rules either.
I can see that, if sealed was more like a package statement (and, in particular, accepted {} as scope delimiters), I'd too dislike the idea I proposed.
I guess the thing is that I don't much care about sealed's semantic properties as much as I care about how it affects the effectiveness of errors and warnings produced by the compiler. There's a small difference in what is achieved (file scope vs compilation scope), but the only practical result that is of relevance to me -- that it can make guarantees in exhaustiveness of pattern matching -- is preserved.
--
Daniel C. Sobral
I travel to the future all the time.
I do wonder if the semantics of "sealed" wouldn't be just as fine if the restriction was weakened to just files compiled at the same time. I mean, say A is a sealed trait on file A.scala, then:
scalac A.scala # Only stuff inside A.scala can extend A
scalac A.scala B.scala C.scala # Anything on A.scala, B.scala or C.scala can extend A
Please no! It's a meta-requirement that Scala's spec should not depend on compilation order or the question what is compiled together.
That's fine, but please note that having the meaning of "sealed" depend on a particular detail of storage unit isn't all that different -- it still depends on something that is not part of the source code, but rather on how the programmer is doing it. In one case, the programmer puts different pieces of code in the same file to achieve the result he wants, and in the other case he compiles the same different pieces at the same time to achieve that result. Which reminds me of Java's directory/filename rules either.
I can see that, if sealed was more like a package statement (and, in particular, accepted {} as scope delimiters), I'd too dislike the idea I proposed.
I guess the thing is that I don't much care about sealed's semantic properties as much as I care about how it affects the effectiveness of errors and warnings produced by the compiler. There's a small difference in what is achieved (file scope vs compilation scope), but the only practical result that is of relevance to me -- that it can make guarantees in exhaustiveness of pattern matching -- is preserved.
--
Daniel C. Sobral
I travel to the future all the time.
On Thu, Sep 09, 2010 at 10:25:14AM +0200, Lukas Rytz wrote:
> While looking at #3791 I tried to add source files for the Value
> Classes, which would (hopefully) simplify the compiler, allow to look
> at the code and make Scaladoc comments easier.
Hey, that's something I've always wanted to do too. Following your
instructions I didn't get anywhere: moved those files, built locker, put
them back, tried to build quick, got the following:
[mkdir] Created dir: /scratch/trunk1/build/quick/classes/library
[javac] Compiling 25 source files to /scratch/trunk1/build/quick/classes/library
[javac] Compiling 41 source files to /scratch/trunk1/build/quick/classes/library
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[scalacfork] Compiling 625 files to /scratch/trunk1/build/quick/classes/library
[scalacfork] No class file for /scratch/trunk1/src/library/scala/Boolean.scala was found
[scalacfork] (This file cannot be loaded as a source file)
[scalacfork] scala.tools.nsc.FatalError: No class file for /scratch/trunk1/src/library/scala/Boolean.scala was found
[scalacfork] (This file cannot be loaded as a source file)
[scalacfork] at scala.tools.nsc.Global$Run.compileLate(Global.scala:834)
[scalacfork] at scala.tools.nsc.symtab.SymbolLoaders$SourcefileLoader.doComplete(SymbolLoaders.scala:265)
[scalacfork] at scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:61)
[scalacfork] at scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:35)
[scalacfork] at scala.tools.nsc.symtab.Symbols$Symbol.info(Symbols.scala:733)
[scalacfork] at scala.tools.nsc.symtab.Definitions$definitions$.newMethod(Definitions.scala:569)
[scalacfork] at scala.tools.nsc.symtab.Definitions$definitions$.newParameterlessMethod(Definitions.scala:591)
[scalacfork] at scala.tools.nsc.symtab.Definitions$definitions$.initValueClasses(Definitions.scala:690)
[scalacfork] at scala.tools.nsc.symtab.Definitions$definitions$.init(Definitions.scala:845)
[scalacfork] at scala.tools.nsc.Global$Run.(Global.scala:604)
[scalacfork] at scala.tools.nsc.Main$.process(Main.scala:105)
[scalacfork] at scala.tools.nsc.Main$.main(Main.scala:120)
[scalacfork] at scala.tools.nsc.Main.main(Main.scala)
[scalacfork] error: fatal error: No class file for /scratch/trunk1/src/library/scala/Boolean.scala was found
[scalacfork] (This file cannot be loaded as a source file)