HPInc / HP-Digital-Microfluidics

HP Digital Microfluidics Software Platform and Libraries
MIT License
2 stars 0 forks source link

Distinguish between `None` and "no value" in macro language #223

Closed EvanKirshenbaum closed 5 months ago

EvanKirshenbaum commented 5 months ago

Currently statements that don't return a value and parallel blocks return None and are typed to return Type.NONE. This is also the value of the constant none and the value a MaybeType has when there's no value (since the rep type is an Optional[T]).

Once we rework the way macros work to allow return statements and return type declarations (#140), it would be a good idea to add a new type, Type.NO_VALUE to handle the first use. A value of that type

Splitting Type.NO_VALUE from Type.NONE will make type conversions with macro types (#222) more straightforward. Currently, a macro declared to return Type.NONE usually means one that doesn't return a meaningful value, and so is covariant to one that does, logically putting Type.NONE at the top of the hierarchy. But it could also mean one that returns none, which should be a normal type (though one below all "maybe" types). Since the former case is more common, I'm going to special case it in CallableType's conversion logic, but it would be nice to revisit that. It would also be nice to not allow the creation of variables that can't hold meaningful values.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jan 26, 2023 at 9:28 AM PST. Closed on Jan 28, 2023 at 4:33 PM PST.
EvanKirshenbaum commented 5 months ago

This issue was referenced by the following commit before migration:

EvanKirshenbaum commented 5 months ago

Type.NONE is now Type.NO_VALUE, above Type.ANY at the top of the hierarchy. There is also a Type.MISSING underneath all MissingTypes, to handle "maybes" (#151).

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