Skip to content

Add Constant and replace transparent parameters #4942

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

Closed
wants to merge 2 commits into from

Conversation

nicolasstucki
Copy link
Contributor

Introduce the type Constant which is a subtype of Singleton but only allows constants (e.i. known values).

Use Constant to mark parameters of transparent methods that must be passed as constants or inlined constants.

Constant is s subtype of Singleton types that only allow constants
for which the value is known at compile time.
Copy link
Member

@smarter smarter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Singleton is already fishy and should ideally be replaced by something else (keyword, annotation, ...), I don' think we should introduce more magic types like it unless we have a very good reason and we can prove that they respect the subtyping laws. (Singleton cannot: if A <: X and B <: X then we expected A | B <: X but 1 | 2 is not a singleton).

@smarter
Copy link
Member

smarter commented Aug 14, 2018

Maybe @Blaisorblade can tell us how bad this would be :)

@Blaisorblade
Copy link
Contributor

Blaisorblade commented Aug 14, 2018

Why this change?

Using a type for Singleton is already fishy. If A <: Singleton and B <: Singleton, it follows that A | B <: Singleton, but for instance 1 | 2 is not actually a singleton type. The same applies here: if A <: Constant and B <: Constant then A | B <: Constant. And neither is easy to special-case, since you can write e.g.

def f[Bound, A <: Bound, B <: Bound](a: A, b: B): C = if (...) a else b

And if you manage to make it work, you'll have recreated a way to check programs which is syntax-directed, not type-directed.

Constant seems to also have a more basic problem: since 1: Constant, then it should be possible to write

val x: 1 & Constant = 1
x: Constant // should work

but your examples suggest otherwise.

EDIT: LOL, ninjaed by @smarter.

Copy link
Contributor

@Blaisorblade Blaisorblade left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm concerned about the design, see objections in comment and by @smarter.

@Blaisorblade
Copy link
Contributor

We talked about this also with Martin today, and we agreed to think harder about it. He agreed Singleton is problematic, but actually Constant is muddier. Singleton clearly breaks because it describes types; but Constant describes "compile-time values", and it seems to me that Int & Constant resembles a bit quoted.Expr[Int].

@nicolasstucki
Copy link
Contributor Author

I agree. The main idea was to express constantness of a parameter of an inlined method (for macros). As singleton already covered constants I explored this design that clearly has issues.

@nicolasstucki
Copy link
Contributor Author

To be more precise Int & Constant would represent a quoted.LiftedExpr[Int], one of the implementations of quoted.Expr in which the quoted code is represented as its runtime value.

@nicolasstucki
Copy link
Contributor Author

We should first solve the issue with Singleton

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

Successfully merging this pull request may close these issues.

3 participants