On Sat, Apr 4, 2015 at 5:59 AM, Keean Schupke <[email protected]> wrote: > On 4 April 2015 at 10:47, Matt Oliveri <[email protected]> wrote: >> On Sat, Apr 4, 2015 at 4:37 AM, Keean Schupke <[email protected]> wrote: >> > A further thought on type-level-Booleans for function arrows. I like the >> > principle of using enumerations with specific names to avoid domain >> > problems. Really classifying a 'call' as a true boolean allows it to be >> > compared and assigned to other Booleans which are from a different >> > domain. >> >> Technically, there's no domain problem. A Bool is a Bool, no matter >> what meaning we attach to its elements in a particular context. >> Special-purpose names are clearer though, since so far, it's all we're >> using Bools for. > > The domain problem occurs like this: > > we have a kind for "is a hare" and a kind for "is a rabbit". If we have Hare > as a variable of kind "is a hare" and Rabbit of kind "is a rabbit", then: > > Hare := Rabbit > > is not allowed (quite correctly as this would create a logical error). > > If both Hare and Rabbit share the same Boolean kind, then we can do such > illogical things.
We are now arguing about programming style, which is kind of silly, 'cause Shap's gonna code it up how _he_ wants. I'm saying if we used Bool-isomorphic things for multiple reasons, we'd just define Bool. Bool would have the canonical forms true and false. There would be no "Hare" or "Rabbit" in the first place. (Or "NotHare" or "NotRabbit".) Nominal distinctions can be helpful sometimes. But not necessary. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
