Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

some refinement-typed expressions can be refactored to avoid dynamic calls #3975

Open
scabug opened this issue Nov 3, 2010 · 3 comments
Open

Comments

@scabug
Copy link

scabug commented Nov 3, 2010

Regarding ticket #3974, one favored practice to deal with dynamic calls involves:

a) know where they occur: -Ylog:cleanup -Ydebug

b) manually create a named class/interface, and use that as the explicit return type of the expression instead of a refinement type.

Should the refactoring in (b) above be part of the compiler, or is it for lint? In some cases a block-local class would be added, othertimes a template-level one (with the same visibility as the LHS of the assignment?). And, after adding a named type (before CleanUp) retyping is needed. Any cons other than that?

@scabug
Copy link
Author

scabug commented Nov 3, 2010

@scabug
Copy link
Author

scabug commented Nov 3, 2010

@magarciaEPFL said:
Replying to [ticket:3975 magarcia]:

The example in ticket #3974 does not show method-chaining of dynamic calls, but they are also amenable to refactoring as the following example shows:

    new AnyRef {
      def abc { ... }
    }.abc

formulated using "atomic evaluation" becomes

  {
    val tmp = new AnyRef {
      def abc { ... }
    }
    tmp.abc
  }

thus making room for the class definition:

  {
    class Boilerplate extends AnyRef {
      def abc { ... }
    }
    val tmp = new Boilerplate
    tmp.abc
  }

@scabug
Copy link
Author

scabug commented Nov 4, 2010

@magarciaEPFL said:
The recipe above does away with reflective calls in several situations, but some remain. For them, a refinement type reference can sometimes be traced back to a single allocation site, thus guaranteenig that a named class can be inserted instead. Looks like deciding whether one such usage can be "traced back to a single allocation site" is a task for points-to analysis. For example, the following POPL 2011 accepted paper presents recent ideas on that:

Smaragdakis Y., Bravenboer M., Lhot�k O., [[BR]]
Pick Your Contexts Well: Understanding Object-Sensitivity.[[BR]]
http://www.cs.umass.edu/~yannis/typesens-prelim.pdf

Just for those students reading this who might be looking for a thesis topic :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants