I would start with something like:
map :: (ForwardIterator i, Readable i, ForwardIterator j, Writeable j, UnaryFunction f, Domain f == ValueType i, Codomain f == ValueType j) => f -> (i, i)-> j -> () map fn (f1, l1) dst = ... Keean, On 9 January 2015 at 09:49, William ML Leslie <[email protected]> wrote: > 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 >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
