2010/11/11 Jonathan S. Shapiro <[email protected]>:
> 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.
about the (new) syntax of ocaml:
a record:
# type x = { a : int; b : int };;
type x = { a : int; b : int }
simple pattern matching, binding a
# let { a } = k;;
value a : int = 1
binding q
# let { a = q } = k;;
value q : int = 1
binding a and q
# let { a; b = q } = k;;
value a : int = 1
value q : int = 2
binding a and b
# let { a; b } = k;;
value a : int = 1
value b : int = 2
using lambdas
# (function { a; b } -> a + b) k;;
- : int = 3
the syntactic difference for your proposed scheme seems to be that in
ocaml it's { fieldName = x }, not { x = fieldName }, and also the
possibility of { fieldName }
> Our rationale for removal went as follows:
>
> - Compiling pattern matching efficiently is hard.
this is not a issue for most programs. (but I understand that adding a
feature and banning it for a large use case might not work well)
> - 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.
you don't need to specify all fields, if the members are named. (but
pattern matching with large tuples might become messy)
> - 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.
again, the tuple thing.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev