Re: Idle musings on doing E over again

David-Sarah Hopwood <[email protected]> Sun, 14 Oct 2012 17:09:43 +0100
Newsgroups gmane.comp.lang.e.general
Message-ID <[email protected]>
On 13/10/12 15:49, Kevin Reid wrote:
> On Oct 12, 2012, at 2:16, Thomas Leonard wrote:
>> It's generally useful to support backwards-compatible updates. e.g. a future version
>> of the service might declare:
>>
>> struct User {
>>   name :String,
>>   email :Email,
>>   phone :nullOk[Phone] := null,
>> }
>>
>> If a user registers with extra details that an old version doesn't need then it can
>> just store them in the database anyway. No need to reject the message.
> 
> What comes to mind now is that there could be a pattern for extensible records: add a
> single field for extra data,
>     unknowns :Map[String, Data],
> such that the User (version 1) guard coerces (using placeholder syntax!)
>     struct [
> 	name = "Alice",
> 	email = <mailto:[email protected]>,
> 	phone = <tel:+5555555>,
>     ]
> into the typed struct
>     User [
> 	name = "Alice",
> 	email = <mailto:[email protected]>,
> 	unknowns = ["phone" => <tel:+5555555>],
>     ]
> . That is, all unknown fields are stuffed into a plain Map (hm, or perhaps an untyped
> record). This keeps the record semantics simple for applications that don't want
> extensibility, and makes it easy to process extra fields if wanted. What do you think?

I prefer full 'row polymorphism'. The difference between that and an 'unknown' field
is that you can extend the record with new fields that are treated in exactly the same
way as old fields, which I think is important particularly for evolution of library
interfaces.

The type system complication is worth it since the main source of the complication is
in supporting subtyping at all, not in supporting this particular kind of subtyping.
In particular, if you have row polymorphism for fields then you can use it for
methods, approximately [*] as in OCaml
(http://caml.inria.fr/pub/docs/u3-ocaml/ocaml-objects.html), and potentially other
things like effects, as in Koka (http://lambda-the-ultimate.org/node/4589).


[*] As shown on the caml.inria.fr page, object types in OCaml are actually distinct
    from record types, although using much of the same type system machinery.
    I think this is overcomplicated. OCaml also tries to do too much inference on
    object types IMHO. The general idea, though, is sound.

-- 
David-Sarah Hopwood ⚥

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang
signature.asc (application/pgp-signature, 554 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQeuPKAAoJEAZ/SSCYzydidioIAIXwoAOBwIp5OiyzlpsU4y0T
Nnm3ueQv7nbDZpcW5VZPSpy4wnS9umkvT9gvm0vI1PAON+cUC6St3U2E3Y3qAQNA
3cGC2iIow6GzfefR26Todq88UkoNut1IQTvWal6dQ/CaE/y9CcIpkLZhzrP7Clzn
3z9FhEoIueGkoEBWyrPlNCxbjReu/lFsbvPImn6Dri+ggbhDuBXdmNM/rflRgoOu
DUja5+BV8bMj/0aqSd0Us9mefcT/X+UAaybYhJg0mL9+fGEi74nt8roGMfbLRB9m
/cmH08mddQ9uscFT1841YovU66k6uwocsjWplLI1/J4x+7Ysjh0fKXbCMTkKRHk=
=mV0k
-----END PGP SIGNATURE-----