Add maybe types to the macro language

[EvanKirshenbaum]

This is simply a matter of allowing, e.g., maybe drop as a parameter or variable type, with Type.DROP.maybe as its corresponding Type. This would allow, e.g., pad.drop to be passed on without dying on the attempt to convert to a drop.

One wrinkle is that in the current implementation, when it is a problem, it's caught at the point at which we know what the object and attribute are and can print a useful value. So we'll probably want to pass along some information that will allow that to happen. If have lvals (#132), we will still be able to do that if the attribute is converted to a drop, but if it's converted to a maybe drop, we'd lose that. This is probably correct, as if we held onto the lval after the value had been converted to an rval maybe drop, it might be the case that by the time we try (and fail) to use it as a drop, the actual source of the missing value is no longer empty.

In order for this to be useful, we'll also want a missing predicate a la:

foo = macro(maybe drop d) {
   if d is missing { ... }
   ...
}

We'd also want missing to be a value you can use as a value.

Ideally, we'd do the same sort of type reasoning that MyPy does, trying to figure out whether the value can (or must) be missing at each point in its scope (including after boolean operators). But that's probably something best left to union types (#152) and for now simply say that you can always try to use the maybe value as a real one, but it might fail.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jun 05, 2022 at 4:26 PM PDT. Closed on Jan 28, 2023 at 4:33 PM PST.

[EvanKirshenbaum]

This issue was referenced by the following commit before migration:

• 50b3c9c3b0a2c5dfaa223ed8dd7fe7762f0da296 by @EvanKirshenbaum on Jan 28, 2023 at 12:00 PM PST

[EvanKirshenbaum]

Note that if we do this with lvals (#132) we will probably want the lval getter to take the desired type as a parameter and do the conversion. This will allow maybe lvals to pass on a MaybeNotSatisfied if they are none and trying to go to an rval.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jun 05, 2022 at 4:34 PM PDT.

[EvanKirshenbaum]

As part of splitting the uses of Type.NONE (#223), I took care of this.

• none has become missing, of Type.MISSING (distinct from Type.NO_VALUE), which is convertible to any MaybeType.
• MaybeTypes are now first class, and you can say, e.g.,

  maybe int i = f();
  macro(a maybe drop){ ... }
  (maybe) drop 2 = ...

  • The parens around maybe are optional.
  • A type-named variable or parameter shares its name with its un-maybe variant, so you can say

    macro(maybe drop) {
      if the drop exists {
          ...
      }
    }

• You can ask about a maybe value's existence:

  if d exists { ... }
  if d does not exist { ... }
  if d doesn't exist { ... }
  if d is missing { ... }
  if d is not missing { ... }
  if d isn't missing { ... }

  along, of course, with

  if d == missing { ... }
  if d != missing { ... }

• p's drop still gets a drop and throws an exception if it doesn't exist, but you can say

  p's maybe drop
  p's (maybe) drop

  to get a maybe drop value that's guaranteed to succeed.

• To satisfy the PLA,

  if p's drop exists { ... }

  checks the existence of the value as a maybe rather than throwing an error. All of the other variants work, as well.

  • Note that

    if p's drop == missing { ... }

    doesn't work, since that's a normal equality expression, and you can't compare a drop against missing.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jan 28, 2023 at 4:33 PM PST.