Open archaephyrryx opened 1 month ago
Could the proposed const_enum
method be implemented with Map and Match now?
It would require a fair bit of boilerplate, I should expect.
But technically achievable.
Having thought about this a bit more, it may be difficult to actually get this working using existing primitives for the following reason:
Once the Map
is interpreted/evaluated, the original value of the parse is lost, and so any numerically-oriented operations will fail, leaving Match
as the sole avenue of value-introspection. This may be a bit annoying to deal with especially when the enum is large.
It may be appropriate to include, in any change-set that adds Format::ConstEnum
, a corresponding
pub enum Value {
/* ... */
NamedConst(Label, Box<Value>),
}
that we can pattern-match either using the Label or the inner value, but otherwise will be implicitly converted to the inner Value prior to any arithmetic or IntRel operations.
I'd be reluctant to add C-style enums (that can be used interchangeably with integers) without a good reason, do we have examples of enum values that we also need to perform arithmetic on?
Good question. A common pattern we might want to apply is ==
or !=
to a given Variant, in which case we wouldn't get the right behavior. This could, of course, be achieved using Match
instead, but it might be worth providing some mechanism for.
(Since IntRel
only works on Base-typed values, and not Variants)
We could add in a notion of structural-equality and -inequality, but that might be best achieved using Expr->Pattern conversions that then do a trivial Expr::Match
we could have a helper:
/// Expression that evaluates to `true` if the given Expr is any Variant with name `varname`, `false` otherwise.
pub fn is_variant(x: Expr, varname: impl IntoLabel) -> Expr {
Expr::Match(x,
vec![
(Pattern::Variant(varname.into(), Pattern::Wildcard), Expr::Bool(true)),
(Pattern::Wildcard, Expr::Bool(false)),
]
)
}
Yep that's a good approach I think.
While achievable through a modest amount of boilerplating with our current model, it may be useful going forward to have a first-class Format-variant for
const enum
values: an ad-hoc type consisting of nullary (C-Style enum) variants that are each associated with a specific non-negative integer constant.This proposal is for something of the form:
where the first argument specifies the 'raw' parsing of the integer value, and the BTreeMap encapsulates the associations between each valid integer value and the name of the variant to be constructed in-place the
Value
-level stand-in for the raw magic number.To provide an easier API, we propose the following helper-function:
Usage Example (from WIP ELF):
The intended interpretation of this primitive is that it should adhere to the rough operational semantics illustrated below: