(not sure how issues are received at this stage of developpement, i try anyway)
i suggest to change the syntax of effect declaration:
effect E : a -> b
to the more regular:
effect E : a -> b eff
why?
it stays in line with the existing syntax for GADTs and exceptions; in particular the keyword effect can be thought as a textual macro for type _ eff +=.
it simplifies the parser (i guess).
the current syntax is confusing: in effect E : int, E is actually an int eff, not an int; as the type of perform shows, perform E is the promised int.
the current syntax is error‐prone: i have already been bitten several times by two common mistakes, namely:
effect E : a eff
forgetting that that eff is already appended by the system, which leads to the wrong type a eff eff; and
effect E : a -> b -> c
which yields a syntax error on the second arrow; i guess the aim to catch the common trapper of the uncurried style for constructors, just as with regular OCaml; but if i think about it, i would rather expect this piece of code te be exactly
effect E : a -> (b -> c)
(* i·e· *) type _ eff += E : a -> (b -> c) eff
the regular syntax allows the error spotting without discrepancy of that kind.
cons:
incompatible syntax change, but well.
(in case it matters: i’m testing effects on the opam switch 4.02.1+multicore, as 4.03.0+effects does not compile for me.)
hello,
(not sure how issues are received at this stage of developpement, i try anyway)
i suggest to change the syntax of effect declaration:
to the more regular:
why?
effect
can be thought as a textual macro fortype _ eff +=
.effect E : int
, E is actually anint eff
, not anint
; as the type ofperform
shows,perform E
is the promisedint
.the current syntax is error‐prone: i have already been bitten several times by two common mistakes, namely:
forgetting that that
eff
is already appended by the system, which leads to the wrong typea eff eff
; andwhich yields a syntax error on the second arrow; i guess the aim to catch the common trapper of the uncurried style for constructors, just as with regular OCaml; but if i think about it, i would rather expect this piece of code te be exactly
the regular syntax allows the error spotting without discrepancy of that kind.
cons:
(in case it matters: i’m testing effects on the opam switch
4.02.1+multicore
, as4.03.0+effects
does not compile for me.)