On the design of generic value parameters

[kyouko-taiga]

As I started implementing generic (aka compile-time) value parameters (see #1211), I realized that our design has many rough edges that we should fix. I'm starting this thread to discuss them. The following are a semi-organized description of my observations so far.

The passing convention of compile-time parameters

Run-time parameters have one of 4 passing conventions: set, let, inout, or sink. The precise meaning of these conventions is strongly related to some notion of temporality, which is a little tricky to define at compile-time.

I think it would be simpler, at least to start, to say that the passing convention of all generic value parameters is let. The idea is that when we write this:

fun foo<n: Int>() -> Int { n.copy() }

We're writing a family of functions that all access some global constant, distinct for each member of that family. Global constants are always let bindings, and therefore so are generic value parameters.

This interpretation may clash with some ideas that have been discussed for type parameters. In particular, if static sink subscripts are allowed. The rationale was that an expression of the form T.property was notionally creating an instance of T and then consuming it to produce some property. I don't think this model doesn't work if generic parameters have the let convention.

The lifetime of compile-time parameters

If compile-time arguments are understood as global constant, then they are "immortal" and never deinitialized.

The initialization of compile-time parameters

When compile-time arguments are initialized?

I think we should not promise any particular evaluation order, on any compile-time expression.

If we go that route, then I think one way to represent compile-time values is to have some trait that explains to the compiler how they can be serialized and then deserialized in the monomorphized form of a function, or at run-time before we call an existentialized function.

[dabrahams]

My instinct is that compile-time value parameters should act like rvalue expressions wherever they appear in expression context. That makes them a little different to deal with than regular parameters, but at the same time, making the user call out .copy() (and .move()) seems silly, since there need be no such operation. If we go with the "global constant" view, in addition to the static sink problem, won't there be some generic parameters that can't be returned from functions because they are immovable?

Brain slowing down; may answer the rest later…

[dabrahams]

I think global constants are far, far simpler to implement. You don't even need to do this serialization thing; you can just initialize them the way other global constants would be initialized, at runtime.

[kyouko-taiga]

Ah, indeed. Expressed as a source to source transformation it would look like this:

// Before
fun foo<n: Int>() -> Int { n + n }

public fun main() {
  print(foo<20 + 1>())
  print(foo<90 + 7>())
}

// After
let _n1 = 20 + 1
let _n2 = 90 + 7

fun foo1() -> Int { _n1 + _n1 }
fun foo2() -> Int { _n2 + _n2 }

public fun main() {
  print(foo1())
  print(foo2())
}

That is even simpler than what I had in mind.

[kyouko-taiga]

But no, wait. That defeats the purpose of compile-time evaluation. We don't want to compute 90 + 7 at run-time, not even once. We can write the resulting value as a global constant, but the whole point is that it has to be already computed. I think we still need deserialization, otherwise we're just providing syntax to define generic constants (which might also be useful but is a different feature IMO).

For example:

// Before
fun some_formula<log: LogTable>(n: Float64) -> Float64 { n * log(n) }

public fun main() {
  let f = some_formula<LogTable(up_to: 500)>
  for let n in some_work_list {
    print(f(n))
  }
}

// After
let _logtable1 = deserialize_some_bytes() // presumably faster than re-computing a log table
...

[dabrahams]

I think there are two separate things here. One is how compile-time constants will make the bridge to runtime, the other, if we choose to make them lvalues, is to constant-fold the initializations. I fully expect that in some cases, for some types, the latter will be impossible, or at least beyond our initial capabilities.

[dabrahams]

The serialization scheme seems like a way to declaratively ensure that some types can be almost-constant-folded. As you point out, it won't always be free, and in the end the deserialization is a computation, too, so it doesn't really achieve our goal for many types where we would like it to.