Re: imagining a programming language with a capability calling convention

On Mon, Sep 14, 2015 at 12:09 PM, Raoul Duke <[email protected]> wrote:

> > None of the problems with those languages are with their mechanisms for
> > calling or creation. As an ocap call mechanism, their calling mechanisms
> are
> > all fine.
>
> I always had it in my (thick, slow) head that
> {java,javascript,ruby,c++,younameit}'s unrestricted (other than e.g.
> class visibility modifiers, which aren't going to stop me from using
> reflection anyway) 'new()' was bad ambient authority. I'd always
> imagined that a "real" ocap system would have to pass around a Factory
> (of Factories, or whatever).


What I've settled on in my armchair designing is, a two-stage invocation in
which a function call with arguments must occur in two stages: the first
stage, with the args, returns a capability to do whatever the request is,
and the second stage, that has no args, executes the option returned by the
first stage. Cacheable "pure" functions with no side effects would be
exempt as they are essentially table lookups that can be optimized away
when building the invokable argless capability.

           MyPureFunction(A)       would yield a result,
but      MyActingFunction(A)     would compile that into a capability to
execute it with its side effects, which must be invoked in the second step.

I think I'm pretty close to Haskell's monads; I came up with the two-stage
idea after watching Crockford's lecture on using Haskell-like monads in
Javascript.

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk