Probably the issue here is I am not a fan of subtyping. I would rather
handle all that using type-classes, for example:
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
