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--