On Sat, Dec 27, 2014 at 4:06 PM, David Jeske <[email protected]> wrote:
> What I did a a poor job of articulating, is that working in classical land
> (Java/C#/Python), I miss *exhaustive*checking* more than I miss complex
> pattern matching.
Yes, I assumed that's what you're talking about.
> I don't frequently miss complex pattern matching, as it's just syntactic
> sugar for something I can already do with conditionals. However, there is no
> way to "emulate" exhaustive checking if it isn't present.
I agree.
> I believe separate-compilation/late-binding languages tend to forgo an
> exhaustive switch/match construct because there is no type whose form is
> guaranteed to be statically known at compile time.
What? The whole point of a variant type is to tell the programmer and
compiler what forms you need to deal with. If you haven't put an upper
bound on the forms, then of course you can't do exhaustiveness
checking.
> Whole program compilers don't have this problem, because everything is
> statically known at compile-time. Consider a simple Ocaml match example.
>
> type expr_t =
> | Var of string
> | Plus of expr_t * expr_t
>
> let rec str_of_expr expr =
> match expr with
> | Var v -> v
> | Plus (a, b) ->
> "(" ^ (str_of_expr a) ^ "+" ^ (str_of_expr b) ^ ")"
>
> OCaml knows this match is exhaustive is because the form of expr_t is bound
> at compile time. If expr_t were defined in a separate module, and could be
> dynamically loaded (or altered), there would be no way for Ocaml to reason
> about the exhaustiveness of the match, and thus a "default" match clause
> would always be required, the way it is in CLR/C#/F#.
Yes and no. No, because you cannot hope to leave a variant type
definition abstract and then use it for pattern matching. The set of
constructors _is_ the external interface.
Yes, in that I assume you're right that CLR languages do not provide
true (closed) variants. Inheritance provides open variants, sort of,
and you are right that these do not permit correct exhaustiveness
checks.
Scala provides not-really-correct exhaustiveness checks on JVM. If you
change things just right, you'll expose failing default cases.
Interestingly, the visitor pattern really does implement
exhaustiveness checking. I assume there must be some horrible problem
with it which is why it doesn't get used when targeting CLI/JVM.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
