Hidden control flow with computed properties

[mrael2]

Perhaps my opinion is in the minority, but I've always thought that computed properties were a little odd. They behave much like a function/method in Objective-C and Swift, and I see in the Hylo language tour that they are a no-parameter subscript which will yield a value.

But when I'm reading code that has some dot notation without parentheses (or square brackets), I'm inclined to think that I'm dealing with a regular old property and its value, not a function call that might involve multiple statements being executed.

The folks working on the Zig language argue that no hidden control flow is a big, important feature that differentiates their systems programming language from others, and I'm decidedly in agreement with them.

I do like many things about Hylo so far, especially its claims of simplicity, but is there a chance that the language could be further simplified by removing computed properties to remove the hidden control flow found therein?

I'm willing to be educated about why computed properties are absolutely necessary to realize the goals of mutable value semantics if they would indeed play such a role.

[dabrahams]

They're not absolutely necessary. If we didn't have them, some places currently spelled foo.bar would be spelled foo.bar[].

I'm not dead set against the idea. At the same time, I do believe in abstraction, which means stuff gets hidden, one way or another; I therefore find the claim that no-hidden-control-flow is a huge win suspect. It's pretty clear to me that forcing people to add [] isn't going to improve code in all circumstances. Hylo is not trying to be a systems-programming-at-the-expense-of-everything-else language. I think one good compromise position might be to keep computed properties, but make trailing [] optional by default and provide a command-line option that requires them.

That said, there's very little Hylo code in existence right now, so we don't have a good way to assess the damage, if any, that might be caused by removing computed properties altogether, and I'm not certain they (or parameter-less subscripts) would be common in any code. My usual thought is to start conservatively by removing features and waiting for a real need to be demonstrated, and my suggested compromise position is pretty messy.

So, color me in favor of running an experiment where we remove computed properties and see what happens.

[kyouko-taiga]

In general, I don't think we can promise that accessing a value via dot-syntax is always as cheap as computing a pointer offset. That would be a contract very difficult to honor in a generic context.

Take a look at this API:

public trait Identifiable {
  property identity: Int { get }
}

public fun print_id<T: Identifiable>(_ x: T) { print(x.identity) }

Unless we can guarantee that this function is always monomorphized, there's no way to promise that accessing x.identity is just a pointer offset. That's because if we need to call it across a module boundary, we'll have to wrap the Identifiable instance into an existential and perform dynamic dispatch.

We could say that traits are not allowed to define property requirements, but that sounds like a frustrating restriction to me. I also think that it would impede on our ability to apply generic programming without introducing boilerplate when we see that two types share common properties. For example, say you're looking to refactor this code:

pubic type A: Regular {
  let identity: Int
  // some other stuff
}

pubic type B: Regular {
  let identity: Int
  // some other stuff
}

fun log(_ x: Union<A, B>) {
  match x {
    let a: A { print(a.identity) }
    let b: B { print(b.identity) }
  }
}

It looks quite tempting to say that both A and B are Identifiable, conclude that Union<A, B> is Identifiable too, and then use print_id in log. We can do that by just adding : Identifiable to the type declarations. If traits can't define properties, however, then we have to write functions or parameter-less subscripts that just reproduce the existing non-generic API.

That being said, I agree that it should probably be considered bad practice to have computed properties with non-constant time complexity. Such a rule would be difficult to enforce but we could make the effort to guide the community to exercise self-discipline.

[dabrahams]

In general, I don't think we can promise that accessing a value via dot-syntax is always as cheap as computing a pointer offset.

Sure we can. A trait author who wants to allow for a more expensive operation would just have to require a subscript instead of a property.

I'm not saying we want that world, but it's one we can have.

[kyouko-taiga]

Hmm, I'm not sure.

trait P {
  property x: Int { get }
}

type A: Regular, P {
  public memberwise init
  public let x: Int
}

// So far, so good but ...

fun recurse_randomly<T: P, U>(_ t: T, _ u: U) -> Int {
  if Bool.random() {
    recurse_randomly(t, (u, ()))
  } else {
    t.x.copy() // not a pointer offset computation
  }
}

public fun main() {
  let a = A()
  _ = recurse_randomly(a, ())
}

The problem is that recurse_randomly(_:_:) can't be monomorphized, so we'll have to create an existential around a. This existential is accompanied with a witness table that tells the runtime how to access x and using that witness table is more expensive than a pointer offset. There's nothing the trait author could say to avoid this situation.