[Candidate] Contexts and CoEffects

[fredemmott]

HIP:

https://github.com/facebook/hhvm/blob/master/hphp/hack/doc/HIPs/contexts_and_coeffects.md

Related HIPs:

• https://github.com/facebook/hhvm/blob/master/hphp/hack/doc/HIPs/pure_functions.md

[fredemmott]

There is now some early stage documentation at https://docs.hhvm.com/hack/contexts-and-capabilities/introduction - the feature has not been implemented yet, but this should be more approachable than the HIP - but with less precision and detail.

[azjezz]

Thanks for working on this @DavidSnider.

While I love this feature, I have 3 major concerns, and I hope my feedback doesn't feel too hursh

syntax

The syntax, is a bit weird, which might feel familiar to people writing C++, it doesn't for most people that would use hack ( people using higher-level programming languages: PHP, JavaScript .. etc )

But I don't really see an alternative syntax 😥

another issue is the const ctx, why do we need:

class WithConstant {
  const ctx C = [io];
  public function has_io()[self::C]: void {
    echo "I have IO!";
  }
}

instead of:

class WithContextKeyword {
  context C = [io];
  public function has_io()[self::C]: void {
    echo "I have IO!";
  }
}

why use ctx instead of the full keyword context? why does const need to be present?

const feel like declaring a constant value, at least that is what I'm used to in other languages; so having it here used to declare a context is a bit weird. when it can be removed, and replaced with context keyword. ( this is also true for const type A = string; )

caller needs the same context

I'm working on a framework now, and from what I see, if I start adding context to all functions/methods, every application using this framework would need to list every single possible context on its entry point because the framework itself might call a function down the road that has that context, even if your application might now hit that code branch.

This is in my opinion is weird, why do I need to define rand context in my entry point, even tho my application doesn't use any random functions, just because the assets component of the framework shuffles the list of provided CDNs to select which one to use, when my application is actually an API that doesn't even deal with assets.

Pure functions, and immutable objects.

Another issue I have with this feature is the way to declare "pure" functions and immutable objects.

For example, I have the following immutable object:

final class NamedAddress {
  public function __construct(
    private string $name,
    private string $email,
  ) {}

  public function withName(string $name): this {
    $clone = clone $this;
    $clone->name = $name; 
    return $clone;
  }

  public function withEmail(string $email): this {
    $clone = clone $this;
    $clone->email= $email; 
    return $clone;
  }

  public function getName(): string { return $this->name; }
  public function getEmail(): string { return $this->email; }
}

and the following pure function

function address_to_string(NamedAddress $address): string {
  return $address->getName().' <'.$address->getEmail().'>';
}

I say "immutable" and "pure" without any declaration in the code because I know they are
unless reflections are involved.

My question here, what context would I need to put to make hack understand that my object is immutable?
Assuming getters have the context to read properties, wouldn't that mean the address_to_string function would need to define
the same context? resulting in the function not being pure anymore?

---

I think declaring a pure context shouldn't be a thing, and immutability and purity should be a separate feature that probably
uses immutable, readonly, pure keywords to make it easier for people coming from other high-level programming languages to understand what they are.

e.g:

final immutable class NamedAddress {
  public function __construct(
    public readonly string $name,
    public readonly string $email,
  ) {}

  public function withName(string $name): this {
    $clone = clone $this; // creating a clone,
    $clone->name = $name;  // writing to readonly clone is okay, as long as the clone was created here.
    return $clone; // returning a clone, means it properties are now locked back to readonly.
  }

  public function withEmail(string $email): this {
    $clone = clone $this;
    $clone->email= $email; 
    return $clone;
  }
}

pure function address_to_string(NamedAddress $address): string {
  return $address->getName().' <'.$address->getEmail().'>';
}

Regards.

[fredemmott]

Purity

This is covered in the user docs in a few places - do you have suggestions for how they could be improved for clarity here?

AIUI The closest thing to a pure function is function foo[]() {} - the empty set of capabilities. This is distinct to function foo() {}

This is not (yet) actually pure, because some unpure actions do not (yet) require capabilities.

I think declaring a pure context shouldn't be a thing, and immutability and purity should be a separate feature that probably

I'm not quite sure what you mean, and this might be another case of us needing feedback to improve the docs.

The 'pure context' is not declared - almost as a side effect of the system as a whole, [] is pretty close, and we call it the pure context sometimes. It's not special, it's just the empty set of permissions.

caller needs the same context

This is largely what 'default' is for, but yeah, it does look like frameworks/entrypoints would currently need everything possible, which isn't great

Immutability

    $clone = clone $this;
    $clone->name = $name; 

This would be invalid in an immutable class. Even if you just created the instance, you're still mutating it. This (common) pattern would need new syntax.

For the other examples: the class-level question you have here isn't really part of this feature - that's #8780

If a ReadProp capability were added, this would probably be addressed as part of that discussion

[DavidSnider]

Hi,

At present all available caps are within the default capability set. When we add a capability that does not fall within the set, we will make it clear how we intend to allow for entering a context with that capability. Most likely it will involve invoking a magic function that specifies you're entering a specific context.