Re: "Effect Capabilities for Haskell"
Matt Rice <[email protected]> Tue, 8 Dec 2015 21:19:08 -0800
| Newsgroups | gmane.comp.capabilities.general,gmane.comp.lang.e.general |
|---|---|
| Message-ID | <CACTLOFrHJvuh8BNdBJ7VbxNJs9vnQpBk-T8wahkY8mBoOtrwww@mail.gmail.com> |
--001a113ecbeed40d1e0526703aa7 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 7, 2015 at 8:12 PM, Mark S. Miller <[email protected]> wrote: > http://pleiad.dcc.uchile.cl/papers/2014/figueroaAl-sblp2014.pdf FWIW i've never managed to convince myself to learn haskell so, I don't get the emphasis on effects, when caps seem useful to me effect-free as well, i can't be certain that there isn't a effect-free capability and this is extending capabilities to effects as well, I do seem to recall a long thread about capabilities to immutable values in the past on list, but don't recall any concensus :) In the introduction it references sml's exceptions [6], I was made aware of this through Andreas Rossberg, when discussing Marc Stiegler's implementation of sealer/unsealers for Emily which used effects on boolean references, Attached is Andreas's makeSealer implementation for standard ML, including my attempts at explaining/breaking it, Ocaml implementation at the bottom of the email inline... The condensed compiler output from SML/nj of various runsj: val makeSealer = fn : unit -> ('a -> exn) * (exn -> 'a) datatype Mode = BadUnseal | GoodUnseal | RaiseSealed val foo = fn : 'a * Mode -> 'a * 'a val a = ("secret1","secret1") : string * string val b = ("?","?") : string * string val c = ("??","??") : string * string val bar = fn : string -> exn * (exn -> string) val d = "secret6..." : string uncaught exception Seal raised at: mkseal.sml:18.43-18.50 /bin/sml: Fatal error -- Uncaught exception Seal with "secret4" raised at ... uncaught exception Seal raised at: mkseal.sml:18.43-18.50 /bin/sml: Fatal error -- Uncaught exception Seal with <unknown> raised at ... uncaught exception Seal raised at: mkseal.sml:91.14-91.16 /bin/sml: Fatal error -- Uncaught exception Seal with "secret7" raised at ... Anyhow I had found this use of exceptions both surprising and non-obvious, and i hadn't seen or found any examples of it anywhere, the reference from the paper talks about it but doesn't provide examples. I've found searching for this particular usage of ML difficult due to the ubiquity of the terms involved, e.g. 'let polymorphism', 'polymorphic exceptions' ;) The issue with the top-level exception was with the SML/NJ compiler, the other compiler I tested with, mlton produces just "unhandled exception: Seal" which seems acceptable the reference states that this is a property of SML exceptions but not ocaml ones, the ocaml variation mentioned earlier, it appears to get the same behaviour through the combination of modules and exceptions, I haven't tested this one to the same extent (e.g. mixing calls to instances of sealers/unsealer modules which share the same type) though... apologies for the wall of text. module type SEALED = sig type t val seal : t -> exn val unseal : exn -> t end module MakeSealer (X : sig type t end) : SEALED with type t = X.t = struct type t = X.t exception Seal of t let seal x = Seal x let unseal = function Seal x -> x | _ -> failwith "unseal" end module S = MakeSealer (struct type t = int end) let n = S.unseal (S.seal 7) --001a113ecbeed40d1e0526703aa7 Content-Type: application/smil; name="mkseal.sml" Content-Disposition: attachment; filename="mkseal.sml" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ihyb8z9x0 ZnVuICdhIG1ha2VTZWFsZXIoKSA9CmxldAogIGV4Y2VwdGlvbiBTZWFsIG9mICdiIAogIGZ1biB1 bnNlYWwgKFNlYWwgeCkgPSB4IHwgdW5zZWFsIF8gPSByYWlzZSBEb21haW4KaW4gKFNlYWwsIHVu c2VhbCkgZW5kCgpkYXRhdHlwZSBNb2RlID0gQmFkVW5zZWFsIHwgUmFpc2VTZWFsZWQgfCBHb29k VW5zZWFsCgpmdW4gZm9vKHgsIG1vZGUpID0gCmxldCB2YWwgKHMxLCB1MSkgPSBtYWtlU2VhbGVy KCkKICAgIHZhbCAoczIsIHUyKSA9IG1ha2VTZWFsZXIoKQogICAgdmFsIChzZWFsZWQxLCBzZWFs ZWQyKSA9IChzMSh4KSwgczIoeCkpCiAgaW4gY2FzZSBtb2RlIG9mCiAgICAgICBHb29kVW5zZWFs ID0+ICh1MShzZWFsZWQxKSwgdTIoc2VhbGVkMikpCiAgICAgICB8IEJhZFVuc2VhbCA9PiAodTEo c2VhbGVkMiksIHUyKHNlYWxlZDEpKQogICAgICAgfCBSYWlzZVNlYWxlZCA9PiBsZXQgdmFsIF8g PSByYWlzZSBzZWFsZWQxCgkJCWluICh1MShzZWFsZWQxKSwgdTIoc2VhbGVkMikpIGVuZAplbmQK CnZhbCBhID0gZm9vKCJzZWNyZXQxIiwgR29vZFVuc2VhbCkKKCogSWYgd2UgcmFpc2UgdGhlIHNl YWxlZCB2YWx1ZSwKICAgd2UgY2FuIGhhbmRsZSB0aGUgZXhjZXB0aW9uLAogICBidXQgc3RpbGwg Y2Fubm90IGdldCB0aGUgdmFsdWUKICAKICAgdGhhdCB3b3VsZCByZXF1aXJlIGhhbmRsZSBTZWFs IHggPT4gLi4uCiAgIHdoaWNoIGlzIGNvbmZpbmVkIHRvIHRoZSAnbGV0JyBpbiBtYWtlU2VhbGVy IGZ1bmN0aW9uCiAgIHdoZXJlIHRoZSB0eXBlIGNvbnN0cnVjdG9ycyByZXNpZGUsIGhhdmluZyB0 aGUgcmV0dXJuIHZhbHVlcwogICBvZiBtYWtlU2VhbGVyIGlzIG5vdCBlbm91Z2guCgogICBZb3Ug Y291bGQgYWRkIGEgZnVuY3Rpb24gaW4gbWFrZVNlYWxlcigpIHN1Y2ggYXM6CiAgIGZ1biBoYW5k bGVyIChmKSA9IGYoKSBoYW5kbGUgU2VhbCB4ID0+IHgKICAgd2hpY2ggaGFuZGxlcywgdGhlIGV4 Y2VwdGlvbiBidXQgaXQgcHJlc2VudHMgbm90aGluZyBtb3JlCiAgIHRoYW4gYW4gYXdrd2FyZCB2 YXJpYXRpb24gb2YgdGhlIGZ1bmN0aW9uICd1bnNlYWwnLAogICBhcyB0aGUgcmV0dXJuIHZhbHVl IG9mICdmJyBhbmQgdGhlIHR5cGUgb2YgJ3gnLCBtdXN0IG1hdGNoCgoqKQp2YWwgYiA9IGZvbygi c2VjcmV0MiIsIFJhaXNlU2VhbGVkKSBoYW5kbGUgU2VhbCA9PiAoIj8iLCI/IikKCgoKKCogU3dh cHBpbmcgdGhlIHVuc2VhbGVycy9zZWFsZWQgdmFsdWVzCiAgIHJhaXNlcyB0aGUgRG9tYWluIGV4 Y2VwdGlvbiBhZ2FpbiBnaXZpbmcgdXMgbm8gc2VhbGVkIHZhbHVlCiopCnZhbCBjID0gZm9vKCJz ZWNyZXQzIiwgQmFkVW5zZWFsKSBoYW5kbGUgRG9tYWluID0+ICgiPz8iLCI/PyIpCgooKiBUaGVy ZSBpcyBvbmUgcHJvYmxlbSBob3dldmVyIHByZXNlbnRlZCBieSB0aGUgdG9wLWxldmVsCiAgIGV4 Y2VwdGlvbiBoYW5kbGVyIHByaW50aW5nIG91dCB0aGUgdW5jYXVnaHQgZXhjZXB0aW9uCiAgIGFu ZCByZXZlYWxpbmcgdGhlIHZhbHVlCiAgIAogICAvYmluL3NtbDogRmF0YWwgZXJyb3IgLS0KCVVu Y2F1Z2h0IGV4Y2VwdGlvbiBTZWFsIHdpdGggInNlY3JldDQiIHJhaXNlZCBhdCAuLi4KCndoaWNo IGlzIHByb2R1Y2VkIGJ5IHRoZSBmb2xsb3dpbmcgY29tbWVudGVkIG91dCBjb2RlOgp2YWwgXyA9 IGZvbygic2VjcmV0NCIsIFJhaXNlU2VhbGVkKQoqKQoKICAKKCogU28gaGlkZSB0aGUgc2VhbGVk IHZhbHVlcyB0eXBlIHdpdGhpbiBhbm90aGVyIHR5cGUKICAgdGhlIGNvbXBpbGVyIGRvZXNuJ3Qg a25vdyBob3cgdG8gcHJpbnQuLgoKICAgcHJvYmFibHkgc2hvdWxkIHdyYXAgbWFrZVNlYWxlciBp biBhIG1vZHVsZSB0byBpbmNsdWRlIHRoZQogICAnYSBzb21ldGhpbmcsIGhpZGluZyB0aGUgZXhj ZXB0aW9uIGFsbCB0b2dldGhlcgogICB0aGlzIHNob3VsZCBzb2x2ZSB0aGUgJ3JhaXNlJyBwcm9i bGVtIG9uY2UgYW5kIGZvciBhbGwuCgogICB0byBnZXQgc29tZXRoaW5nIGxpa2U6CiAgIC9iaW4v c21sOiBGYXRhbCBlcnJvciAtLQogICAgIFVuY2F1Z2h0IGV4Y2VwdGlvbiBTZWFsIHdpdGggPHVu a25vd24+IHJhaXNlZCBhdCAuLi4KCndoaWNoIGlzIHByb2R1Y2VkIGJ5IHRoZSBmb2xsb3dpbmcg Y29tbWVudGVkIG91dCBjb2RlOgoKZGF0YXR5cGUgJ2Egc29tZXRoaW5nID0gVGhpbmcgb2YgJ2EK dmFsIF8gPSBmb28oVGhpbmcoInNlY3JldDUiKSwgUmFpc2VTZWFsZWQpCiopCgoKZnVuIGJhcih4 KSA9CiAgbGV0IHZhbCAoc2VhbGVyLCB1bnNlYWxlcikgPSBtYWtlU2VhbGVyKCkKICAgICAgZnVu IGYoeSkgPSB1bnNlYWxlcih5KSBeICIuLi4iCiAgICBpbiAoc2VhbGVyKHgpLCBmKQplbmQKCnZh bCBkID0gbGV0IHZhbCAoczMsIHUzKSA9IGJhcigic2VjcmV0NiIpCgkgIGluIHUzKHMzKSBlbmQK CigqIFdlIGNhbiByYWlzZSB0aGlzIHNlYWxlZCB2YWx1ZSBldmVuIGlmIGFsbCB3ZSBoYXZlIGlz IHRoZSBzZWFsZWQgdmFsdWUgc2luY2Ugd2UgaGF2ZSBhIGNvbnN0cnVjdGVkIGV4Y2VwdGlvbi4K Ci9iaW4vc21sOiBGYXRhbCBlcnJvciAtLQogICAgVW5jYXVnaHQgZXhjZXB0aW9uIFNlYWwgd2l0 aCAic2VjcmV0NyIgcmFpc2VkIGF0IC4uLgoKdmFsIGUgPSBsZXQgdmFsIChzNCwgdTQpID0gYmFy KCJzZWNyZXQ3IikKCSAgaW4gKHJhaXNlIHM0OyB1NChzNCkpIGVuZAoqKQo= --001a113ecbeed40d1e0526703aa7 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ cap-talk mailing list [email protected] http://www.eros-os.org/mailman/listinfo/cap-talk --001a113ecbeed40d1e0526703aa7--