- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
:power mode imports in trunk and 2.9.x
Thu, 2011-04-07, 11:50
I'm very much liking the :power mode updates in 2.9.x and trunk, but
there's one thing that I'm not so sure about,
Welcome to Scala version 2.10.0.r24669-b20110404020218 (Java
HotSpot(TM) Server VM, Java 1.6.0_24).
Type in expressions to have them evaluated.
Type :help for more information.
scala> :type error("foo")
Nothing
scala> error("foo")
warning: there were 1 deprecation warnings; re-run with -deprecation for details
java.lang.RuntimeException: foo
at scala.sys.package$.error(package.scala:27)
at scala.Predef$.error(Predef.scala:63)
at .(:8)
at .()
at .(:11)
at .()
at $export()
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at scala.tools.nsc.interpreter.IMain$ReadEvalPrint.call(IMain.scala:686)
at scala.tools.nsc.interpreter.IMain$Request$$anonfun$11.apply(IMain.scala:920)
at scala.tools.nsc.interpreter.Line$$anonfun$1.apply$mcV$sp(Line.scala:43)
at scala.tools.nsc.io.package$$anon$2.run(package.scala:31)
at java.lang.Thread.run(Thread.java:662)
So far so unsurprising ... however,
scala> :power
** Power User mode enabled - BEEP BOOP WHIR **
** scala.tools.nsc._ has been imported **
** global._ and definitions._ also imported **
** New vals! Try repl, intp, global, power **
** New cmds! :help to discover them **
** New defs! Type power. to reveal **
scala> :type error("foo")
Unit
scala> error("foo")
error: foo
The problem is that Predef.error (aka sys.error) has been shadowed by
global.error (see that "** global._ and definitions._ also imported
**" in the :power banner above). Now I know that Predef.error is
deprecated, but still, it seems a little unfortunate that something
which is so widely used unqualified should get it's meaning changed in
this way by engaging :power mode.
In some ways, things get worse if you respect the deprecation of Predef.error,
Welcome to Scala version 2.10.0.r24669-b20110404020218 (Java
HotSpot(TM) Server VM, Java 1.6.0_24).
Type in expressions to have them evaluated.
Type :help for more information.
scala> import sys.error
import sys.error
scala> :type error("foo")
Nothing
scala> :power
** Power User mode enabled - BEEP BOOP WHIR **
** scala.tools.nsc._ has been imported **
** global._ and definitions._ also imported **
** New vals! Try repl, intp, global, power **
** New cmds! :help to discover them **
** New defs! Type power. to reveal **
scala> :type error("foo")
Failed to determine type.
scala> error("foo")
:31: error: reference to error is ambiguous;
it is imported twice in the same scope by
import global._
and import sys.error
error("foo")
Clearly there's going to be lots of other stuff pulled in by the
imports of global._ and definitions._ so there are plenty of other
opportunities for surprising shadowings. I can't help feeling that it
would be better not to have these imports added automatically. What do
other people think?
Cheers,
Miles
Fri, 2011-04-08, 10:17
#2
Re: :power mode imports in trunk and 2.9.x
On Thu, Apr 7, 2011 at 6:52 PM, Paul Phillips wrote:
> On 4/7/11 3:49 AM, Miles Sabin wrote:
>>
>> I'm very much liking the :power mode updates in 2.9.x and trunk, but
>> there's one thing that I'm not so sure about,
>
> There's no question power mode is more like "paulp's mode" and has not
> properly been smoothed out for general usage. However given where we are in
> the 2.9 cycle and how many non-power things I'm still staring down, the best
> I can offer in the short term is what I just checked in.
>
> // file to interpret when entering power mode instead of default
> -Dscala.repl.power.initcode=/path/to/file
> // file holding banner to display instead of default
> -Dscala.repl.power.banner=/path/to/file
Understood ... and, thanks, that helps.
>> scala> error("foo")
>> :31: error: reference to error is ambiguous;
>> it is imported twice in the same scope by
>> import global._
>> and import sys.error
>> error("foo")
>
> Yeah, I have suffered through every variation of this. The other thing
> which you will encounter (if you haven't yet) are path dependent type
> conflicts for members of Global. I have yet to come up with a workable
> mechanism for keeping scalac informed that everyone is using the same
> freaking global and it doesn't have to get on my case about the path. It
> still happens, but it's presently better than it ever has been (knock on
> wood) due to this approach.
I agree that import global._ is a must whenever you're directly
interacting with the Global. It's just that I'm not sure that this is
the best default behaviour, given that definitions can be imported
later, but not unimported later.
How about not doing the imports for :power, but adding a switch to
enable that, ie :power -i
> trait SharesGlobal[G <: Global] {
> val global: G
>
> // This business gets really old:
> //
> // found : power.intp.global.Symbol
> // required: global.Symbol
Yes, I agree that this kind of thing can be a pain.
Cheers,
Miles
On 4/7/11 3:49 AM, Miles Sabin wrote:
> I'm very much liking the :power mode updates in 2.9.x and trunk, but
> there's one thing that I'm not so sure about,
There's no question power mode is more like "paulp's mode" and has not
properly been smoothed out for general usage. However given where we
are in the 2.9 cycle and how many non-power things I'm still staring
down, the best I can offer in the short term is what I just checked in.
// file to interpret when entering power mode instead of default
-Dscala.repl.power.initcode=/path/to/file
// file holding banner to display instead of default
-Dscala.repl.power.banner=/path/to/file
> scala> error("foo")
> :31: error: reference to error is ambiguous;
> it is imported twice in the same scope by
> import global._
> and import sys.error
> error("foo")
Yeah, I have suffered through every variation of this. The other thing
which you will encounter (if you haven't yet) are path dependent type
conflicts for members of Global. I have yet to come up with a workable
mechanism for keeping scalac informed that everyone is using the same
freaking global and it doesn't have to get on my case about the path.
It still happens, but it's presently better than it ever has been (knock
on wood) due to this approach.
(The type parameter is not accomplishing much anymore, I used to have a
bound like Global with Singleton, and then have the type of the global
was exposed in the type of the thing implementing the trait.)
trait SharesGlobal[G <: Global] {
val global: G
// This business gets really old:
//
// found : power.intp.global.Symbol
// required: global.Symbol
//
// Have tried many ways to cast it aside, this is the current winner.
// Todo: figure out a way to abstract over all the type members.
type AnySymbol = Global#Symbol
type AnyType = Global#Type
type AnyName = Global#Name
type AnyTree = Global#Tree
type Symbol = global.Symbol
type Type = global.Type
type Name = global.Name
type Tree = global.Tree
implicit def upDependentSymbol(x: AnySymbol): Symbol =
x.asInstanceOf[Symbol]
implicit def upDependentType(x: AnyType): Type = x.asInstanceOf[Type]
implicit def upDependentName(x: AnyName): Name = x.asInstanceOf[Name]
implicit def upDependentTree(x: AnyTree): Tree = x.asInstanceOf[Tree]
}
There is always the implicit blanket cast, which I'm resisting at least
for general usage for obvious reasons.