A few notes:
f :: a -> b -> Eff e a
Eff is a special datatype that represents 'effectful-function-call' as such
it is the deconstruction that actually makes the call. The unit
construction just injects the return value 'a' into the datatype. 'e' is a
phantom type representing the effects inferred.
If we accept all side-effects with no distinction (like Haskell's IO monad)
we can remove the 'e' parameter to leave something like:
f :: a -> b -> Fn a
As you can see there is not a 'Fn' on the right of every arrow, only the
one where side-effects (the actual function is called). In this case it
indicates that both arguments 'a' and 'b' must be accumulated before the
call can be made. The call can be explicit, for example:
data Fn a = Fn {call :: a}
call (f x y)
Of course you can have syntactic sugar for this.
This allows us to distinguish between tuples and calling. Consider the
differences between:
f :: a -> b -> Fn a -- curried
g :: (a, b) -> Fn a -- pass a tuple
h :: a -> Fn (b -> Fn a) -- multiple calls / explicit partial evaluation
In all cases arguments are provided / accumulated, but the final nullary
function is not evaluated until the result datatype is deconstructed. In
this model the function is a sequence of pure operations and all the
impurity is in the the datatype deconstruction.
Keean.
On 15 February 2015 at 21:22, Jonathan S. Shapiro <[email protected]> wrote:
> On Sun, Feb 15, 2015 at 12:11 PM, Keean Schupke <[email protected]> wrote:
>
>> I guess one could consider a set of pre-defined resources passed as a
>> context to a co-monad, as opposed to a set of generated effects, but I at
>> least understand what is going on in the monadic case better. So I would
>> probably prefer:
>>
>> x y z -> Fn (a b -> Fn w)
>>
>> to
>>
>> Fn x y z -> Fn a b -> w
>>
>> but I would be persuaded otherwise...
>>
>
> From a parsing perspective, the reason that the infix -> notation works in
> OCaml/Haskell is that all functions have arity 1. In a language having a
> variable number of arguments, clean parsing requires some form of
> bracketing keyword. This is true in the same way that LET acts as a leading
> bracketing keyword in LET <binding*> IN <body>
>
> Going back to *your* syntax, I confess that I am puzzled. It appears to me
> that the "Fn" in this notation appears, by necessity, on the right side of
> every arrow. If so, then isn't it syntactically redundant?
>
>
> shap
>
> _______________________________________________
> 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
