Reflecting on things which are not values?

[Haoyi Li]

In my Ammonite REPL, I have a pair of functions which are very useful for poking at things and seeing what they are:

  /**
   * Get the `Type` object of [[T]]
   */
  def typeOf[T: WeakTypeTag]: Type

  /**
   * Get the `Type` object representing the type of `t`
   */
  def typeOf[T: WeakTypeTag](t: => T): Type

This works surprisingly well! I can throw at it types, values, objects, primitives, etc. and get useful reflective knowledge about what those things can do.

However, it fails in certain cases, because not everything in Scala is a value!

@ typeOf(scala)
Compilation Failed
Main.scala:15: package scala is not a value
            val res11 = (typeOf(scala))
                                ^
@ typeOf("".substring)
Compilation Failed
Main.scala:15: ambiguous reference to overloaded definition,
both method substring in class String of type (x$1: Int, x$2: Int)String
and  method substring in class String of type (x$1: Int)String
match expected type ?
            val res11 = (typeOf("".substring))
                                   ^

Ideally, I'd like people to be able to reflect on packages and methods just as they can reflect on types and objects. A package's type has useful information on what classes and sub-packages it contains, and a methods type is extremely useful in telling you what parameters that method takes, what it returns and what overloads it has

Now, clearly I can't do this in normal Scala, but is there any easy way I can hack the compiler to make this work? Or any easy workarounds that people can think of? I am very much trying to avoid all the magic-syntax-command the old Scala REPL has, and I could do so neatly, if not for this irregularity in the language for things that aren't values.

[Jon Pretty]

Hi Haoyi,

Would you be content to write:

  typeOf(packages.scala)

?

That could be made to work with an object `packages` extending `Dynamic`, implemented by a macro. I'll agree it's not ideal, but it's an idea.

As for overloaded methods, I don't really know... But is it right that you should be able to pass in an unapplied overloaded method back and get a `Type` value? Shouldn't you be forced to disambiguate, not least for making `typeOf` consistent with other methods? Unless you want to propose a new way of handling overloading? ;)

Cheers,
Jon

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Adriaan Moors]

You could make that work by special casing the type checking of your typeOf method, kind of like what we do for classOf now. Before resolution, substring's symbol's info is an OverloadedType, and, although a package is not a value for the purpose of argument passing, the internal representation is the same as for anything else that has members, it's a ClassInfoType.

Happy to give some more pointers when I have a keyboard within reach.  

[Haoyi Li]

The dynamic idea sounds cool. I'd miss out a bunch of things tough, e.g. autocomplete of the package hierarchy while I'm trying to type it out and pass it in =) 

The method thing seems weird, but it really comes down to what I want. I want typeOf("".substring) to spit out information about that method signature, and if it means typeOf needs to return a Seq[Type] or something then so be it. It's kind of like hitting dir(...) in Python, except better =P

@adriaan How would one go about special casing type-checking like that? That sounds really cool. Also, I have no idea what special casing we do for classOf: isn't it just a normal method taking a type param? 

More pointers would be cool! Ideally I'd be able to do this without forking the compiler, but I already have a custom subclass of global, as well as a plugin that cuts in after the typer phase, so some amount of mess is no big deal...

[Adriaan Moors]

Hey Haoyi,

On Sun, Feb 22, 2015 at 5:07 PM, Haoyi Li <haoy...@gmail.com> wrote:

@adriaan How would one go about special casing type-checking like that? That sounds really cool.

You could add a special case for type checking the arguments to your typeOf macro.

The general area is doTypedApply. Jason recently added support for signature-polymorphic methods in Java 8 here:

https://github.com/scala/scala/blob/2.11.x/src/compiler/scala/tools/nsc/typechecker/Typers.scala#L3302

I can't think of any precedent for changing the typing of arguments like this (using FUNmode so overloading is not resolved, and omitting check), although I'm sure Eugene has experimented with it for untyped macros.

`stabilize` is a key method in this area

Also, I have no idea what special casing we do for classOf: isn't it just a normal method taking a type param? 

Yep!

cheers

adriaan