On Sat, Dec 27, 2014 at 10:14 AM, Jonathan S. Shapiro <[email protected]>
wrote:
> But I think David isn't entirely right that this is a separate compilation
> issue. I think the real issue lies in the fact that the type system that
> survives to the late binding stage doesn't admit all of the constraints you
> might want.
>
Yes, this is a late-biding issue, not a separate compilation issue, though
the two travel hand-in-hand.
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.
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 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.
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#.
Expressed in C#/CLR-ish, I wish I could do:
static internal enum Foo { A, B, C } // only exists inside the CLR assembly
unit
void handle(Foo a_foo) {
static_switch(a_foo) {
case A: /// some code...
case B: /// some code..
<<--- compiler error because case C is missing
<<--- no default case allowed
}
}
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
