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

Reply via email to