This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Rationale for vars in Definitions?

7 replies
odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.

I am in train of making reflection thread-safe. This means in
particular that there can be no public mutable field anywhere in the
reflect.* hierarchy. One headache here is Definitions
which has a bunch of variables such as Any_==. Object_eq, String_+. Is
there are reason these can't be lazy vals, like the other symbols? I
would include them in the `forced` list of course.

Cheers

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Rationale for vars in Definitions?


On Wed, Jan 25, 2012 at 6:36 AM, martin odersky <martin.odersky@epfl.ch> wrote:
I am in train of making reflection thread-safe. This means in
particular that there can be no public mutable field anywhere in the
reflect.* hierarchy. One headache here is Definitions
which has a bunch of variables such as Any_==. Object_eq, String_+. Is
there are reason these can't be lazy vals, like the other symbols? I
would include them in the `forced` list of course.

Yes, cycles.  You might be able to get some of them; no way you can get all of them. There are tons of symbols with directly and indirectly pointing arrows like BooleanClass, IntClass, AnyClass, ObjectClass, you see the problem.
However the good news is that I do have work on this in progress.  I distilled out all the symbols necessary for bootstrapping and was separating them from definitions.  I was going to load those in a more formalized way, because lazy val unrolling only takes you so far.
odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Rationale for vars in Definitions?

On Wed, Jan 25, 2012 at 4:20 PM, Paul Phillips wrote:
>
>
> On Wed, Jan 25, 2012 at 6:36 AM, martin odersky
> wrote:
>>
>> I am in train of making reflection thread-safe. This means in
>> particular that there can be no public mutable field anywhere in the
>> reflect.* hierarchy. One headache here is Definitions
>> which has a bunch of variables such as Any_==. Object_eq, String_+. Is
>> there are reason these can't be lazy vals, like the other symbols? I
>> would include them in the `forced` list of course.
>
>
> Yes, cycles.  You might be able to get some of them; no way you can get all
> of them. There are tons of symbols with directly and indirectly pointing
> arrows like BooleanClass, IntClass, AnyClass, ObjectClass, you see the
> problem.
>
> However the good news is that I do have work on this in progress.  I
> distilled out all the symbols necessary for bootstrapping and was separating
> them from definitions.  I was going to load those in a more formalized way,
> because lazy val unrolling only takes you so far.
>
I don't understand. You mean, we create cycles my making these lazy
vals? Or rather: we mask cycles?

Cheers

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Rationale for vars in Definitions?


On Wed, Jan 25, 2012 at 7:28 AM, martin odersky <martin.odersky@epfl.ch> wrote:
I don't understand. You mean, we create cycles my making these lazy
vals? Or rather: we mask cycles?

We create them.  I see it's less obvious now because the value class method signatures are read from source files rather than being directly constructed with symbols.  I haven't thought about it much since then so maybe it's more tractable.  We would have to do some more post-init symbol surgery like the kind you can see being done on the value classes, where I replace the parent it came up with on its own with AnyVal.
odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Rationale for vars in Definitions?

On Wed, Jan 25, 2012 at 4:38 PM, Paul Phillips wrote:
>
>
> On Wed, Jan 25, 2012 at 7:28 AM, martin odersky
> wrote:
>>
>> I don't understand. You mean, we create cycles my making these lazy
>> vals? Or rather: we mask cycles?
>
>
> We create them.  I see it's less obvious now because the value class method
> signatures are read from source files rather than being directly constructed
> with symbols.  I haven't thought about it much since then so maybe it's more
> tractable.  We would have to do some more post-init symbol surgery like the
> kind you can see being done on the value classes, where I replace the parent
> it came up with on its own with AnyVal.

I don't think it's an issue anymore. I replaced them all with lazy
vals in my local version and the build proceeds fine.

Cheers

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Rationale for vars in Definitions?
I tried replacing three of them with lazy vals and hit 75 errors in quick.lib.  I've wrestled with this sort of thing every time I've attempted anything interesting in Definitions.
quick.lib:     [mkdir] Created dir: /scratch/trunk3/build/quick/classes/library    [javac] Compiling 25 source files to /scratch/trunk3/build/quick/classes/library    [javac] Compiling 41 source files to /scratch/trunk3/build/quick/classes/library     [javac] Note: Some input files use unchecked or unsafe operations.    [javac] Note: Recompile with -Xlint:unchecked for details.[scalacfork] Compiling 692 files to /scratch/trunk3/build/quick/classes/library [scalacfork] /scratch/trunk3/src/library/scala/Console.scala:224: error: type mismatch;[scalacfork]  found   : obj.type (with underlying type Any)[scalacfork]  required: ?{val toString: ?} [scalacfork]  possible cause: missing arguments for method or constructor[scalacfork] Note: Any is not implicitly converted to AnyRef.  You can safely[scalacfork] pattern match `x: AnyRef` or cast `x.asInstanceOf[AnyRef]` to do so. [scalacfork]     out.print(if (null == obj) "null" else obj.toString())[scalacfork]                                            ^[scalacfork] /scratch/trunk3/src/library/scala/MatchError.scala:28: error: type mismatch; [scalacfork]  found   : MatchError.this.obj.type (with underlying type Any)[scalacfork]  required: ?{val toString: ?}[scalacfork] Note: Any is not implicitly converted to AnyRef.  You can safely [scalacfork] pattern match `x: AnyRef` or cast `x.asInstanceOf[AnyRef]` to do so.[scalacfork]     else obj.toString() + " (of class " + obj.getClass.getName + ")"[scalacfork]          ^ [scalacfork] /scratch/trunk3/src/library/scala/Product1.scala:38: error: type mismatch;[scalacfork]  found   : n.type (with underlying type Int)[scalacfork]  required: ?{val toString: ?} [scalacfork]  possible cause: missing arguments for method or constructor[scalacfork] Note: an implicit exists from scala.Int => java.lang.Integer, but[scalacfork] methods inherited from Object are rendered ambiguous.  This is to avoid [scalacfork] a blanket implicit which would convert any scala.Int to any AnyRef.[scalacfork] You may wish to use a type ascription: `x: java.lang.Integer`.[scalacfork]     case _ => throw new IndexOutOfBoundsException(n.toString()) [scalacfork]                                                   ^[scalacfork] /scratch/trunk3/src/library/scala/Product10.scala:47: error: type mismatch;[scalacfork]  found   : n.type (with underlying type Int) [scalacfork]  required: ?{val toString: ?}[scalacfork]  possible cause: missing arguments for method or constructor[scalacfork] Note: an implicit exists from scala.Int => java.lang.Integer, but [scalacfork] methods inherited from Object are rendered ambiguous.  This is to avoid[scalacfork] a blanket implicit which would convert any scala.Int to any AnyRef.[scalacfork] You may wish to use a type ascription: `x: java.lang.Integer`. [scalacfork]     case _ => throw new IndexOutOfBoundsException(n.toString())[scalacfork]                                                   ^[scalacfork] /scratch/trunk3/src/library/scala/Product11.scala:48: error: type mismatch; [scalacfork]  found   : n.type (with underlying type Int)[scalacfork]  required: ?{val toString: ?}[scalacfork]  possible cause: missing arguments for method or constructor[scalacfork] Note: an implicit exists from scala.Int => java.lang.Integer, but [scalacfork] methods inherited from Object are rendered ambiguous.  This is to avoid[scalacfork] a blanket implicit which would convert any scala.Int to any AnyRef.[scalacfork] You may wish to use a type ascription: `x: java.lang.Integer`. [scalacfork]     case _ => throw new IndexOutOfBoundsException(n.toString())[scalacfork]                                                   ^[scalacfork] /scratch/trunk3/src/library/scala/Product12.scala:49: error: type mismatch; [scalacfork]  found   : n.type (with underlying type Int)[scalacfork]  required: ?{val toString: ?}[scalacfork]  possible cause: missing arguments for method or constructor[scalacfork] Note: an implicit exists from scala.Int => java.lang.Integer, but [scalacfork] methods inherited from Object are rendered ambiguous.  This is to avoid[scalacfork] a blanket implicit which would convert any scala.Int to any AnyRef.[scalacfork] You may wish to use a type ascription: `x: java.lang.Integer`. [scalacfork]     case _ => throw new IndexOutOfBoundsException(n.toString())[scalacfork]                                                   ^[scalacfork] /scratch/trunk3/src/library/scala/Product13.scala:50: error: type mismatch; [scalacfork]  found   : n.type (with underlying type Int)[scalacfork]  required: ?{val toString: ?}[scalacfork]  possible cause: missing arguments for method or constructor[scalacfork] Note: an implicit exists from scala.Int => java.lang.Integer, but [scalacfork] methods inherited from Object are rendered ambiguous.  This is to avoid[scalacfork] a blanket implicit which would convert any scala.Int to any AnyRef.[scalacfork] You may wish to use a type ascription: `x: java.lang.Integer`. [scalacfork]     case _ => throw new IndexOutOfBoundsException(n.toString())
extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Rationale for vars in Definitions?


On Wed, Jan 25, 2012 at 7:58 AM, martin odersky <martin.odersky@epfl.ch> wrote:
I don't think it's an issue anymore. I replaced them all with lazy
vals in my local version and the build proceeds fine.

That's great news if so.  I trust you tried bootstrapping from all.clean -- because this is just the kind of place where things might to build on the surface but come apart when trying from ground zero.  I'll give it a whirl.
extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Rationale for vars in Definitions?
Replacing all of them:

[scalacfork] 607 errors found

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland