This is another future-proofing question.
BitC originally supported some degree of pattern matching. It's a syntactic
feature that has become very popular, so I want to re-visit it.
Our rationale for removal went as follows:
- Compiling pattern matching efficiently is hard.
- Tuple patterns, in particular, seemed to have some
worrisome interactions with the logic of field mutability
inference. Given some later decisions, that would not
be an issue any more.
- As the number of fields in a structure rises, patterns become
much harder to write.
- If patterns are syntactically positional (count the
commas to select the desired field), they become
very fragile to errors resulting from field addition
or removal.
The last two points were important in our minds. We felt it would drive us
quickly to keyword arguments, and that the apparent naturalness of patterns
would deteriorate very quickly. Imagine a union leg with 20 fields, only one
of which you care about in the current switch statement:
switch x = union_value
case LegType(,,,,,,,,,, x, .....) in ...
This is unmaintainable, and it would drive us to something more like:
switch union_value
case LegType({ x = fieldName }) in ...
where I am using the {} notation here to indicate some variation of record
polymorphism. The implications of moving here take some thinking about, but
it may be motivated. I think, however, that this pushes us to named
arguments more generally, and that requires taking the position that (a)
function arity matters, and (b) argument names are significant in function
type declarations. Neither of those positions is a problem *per se*; I'm
just trying to get all the connected issues on the table in one place.
Just for comparison, here's the current alternative:
switch x = union_value
case LegType in ... x.fieldName ...
The minimal future-proofing change right now would be to make function
argument names significant when present in function declarations, though
there are interesting consequences for subtyping in function types that I
haven't considered adequately yet.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
