On 9 January 2015 at 20:33, Keean Schupke <[email protected]> wrote: > Probably the issue here is I am not a fan of subtyping. I would rather > handle all that using type-classes, for example:
You've not really represented the problem I described. You might say: -- immutable values can be treated as read-only instance (Immutable x) => DeepReadOnly x where ... -- mutable values can be treated as read-only instance (Mutable x) => DeepReadOnly x where ... These are really subtyping, and are required when doing this: f :: DeepReadOnly Foo => Foo -> Bar xs :: Mutable Foo => List Foo map f xs -- apply a function that does not mutate its argument to a mutable value which I should of course be able to do. the question is, what does the signature of map have to look like to be able to preserve all of these invariants? > > > class Readable x where > type ValueType x :: * > source :: x -> ValueType x > > class Writeable x where > type ValueType x :: * > sink :: x -> ValueType x > > class (Readable x, Writeable x) => Mutable x where > type ValueType x :: * > deref :: x -> ValueType x > > newtype MutInt = Mut Int > > instance Readable MutInt where > ValueType MutInt = Int > source (Mut i) = i > > instance Writeable MutInt where > ValueType MutInt = Int > sink (Mut i)= i > > instance Mutable Int where > ValueType MutInt = Int > deref (Mut i) = i > > newtype ReadOnlyInt = ReadOnly Int > > instance Readable ReadOnlyInt where > ValueType ReadOnlyInt = Int > source (ReadOnlyInt i) = i > > etc... > > Obviously not ideal for values because the code will be cluttered, but it > works well for pointers, where source, sink ad deref replace '*'. > > > Keean > > > > > On 9 January 2015 at 09:16, William ML Leslie <[email protected]> > wrote: >> >> On 9 January 2015 at 19:55, Keean Schupke <[email protected]> wrote: >> >> They do need to be part of the type system because their misuse leads >> >> to unsoundness, but requiring that different classifications of >> >> mutability be distinct types seems to lead to awkwardness when you're >> >> just trying to implement something with reasonable variance over >> >> mutability. >> > >> > >> > Surely you just need a 'const' type as in C++, and if you cannot cast >> > away >> > const (you can only cast to const) it seems safe. >> >> We (probably) want to support both mutability (weather the value can >> change) and writability (weather we can change the value, annotated >> 'read-only' here), as well as how this transitively affects usage of >> fields. >> >> In any case, the limits of variance tend to look like edge cases until >> you actually hit them yourself. >> >> See, even map looks odd in this situation. I should be able to map a >> function over a list with read-only elements, and have the result be >> mutable. The type system must be able to check (and hopefully, in the >> case of something as trivial as map, infer) each of the mutability >> invariants required. And yet I don't think I should have to describe >> this when I write a function like map. >> >> It's not that we don't know what the subtyping relationships are >> (although we did get them wrong initially), it's that the cognitive >> burden of having to maintain them as part of the types of values is >> unneccesary. >> >> -- >> William Leslie >> >> Notice: >> Likely much of this email is, by the nature of copyright, covered >> under copyright law. You absolutely MAY reproduce any part of it in >> accordance with the copyright law of the nation you are reading this >> in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without >> prior contractual agreement. >> _______________________________________________ >> bitc-dev mailing list >> [email protected] >> http://www.coyotos.org/mailman/listinfo/bitc-dev > > > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely MAY reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior contractual agreement. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
