[erlang-questions] Erlang and Akka

[Joe Armstrong]

I'd thought for some time that Erlang ought to have a process declaration.

The problem is that processes have no names Pid = spawn( fun() -> ... end)
yields an anonymous process - we can't talk about the process Pid
since it has no name.

We *can* talk about modules since they have names, be we have to use a
circumlocution
to talk about a process, ie refer to the name of the function that
started the process.

Since this function can be a fun we have a double naming problem, not
only has the process no
name, but the start fun has no name.

We could make a process declaration (analogous to a module
declaration)  and tell the system
about the messages it can send and receive

     -process(mailbox).

     -sends(   Type of messages this process can receive)
    - receives (Type of messages this process can receive)
    - max_instances(124).
    - ... whatever ..

     start(X, Y, Z) -> ....
          obligatory start function

If we did this then we would be able to talk about "the process
mailbox/3" (meaning the process
started by spawn(mailbox, start, [X,Y,Z]).

Once we can name processes we can use the names in annotations in other modules.

so we could type functions with Pids

-spec foo( PId::process(mailbox)) -> ....

foo(Pid) ->
    receive
         {Pid, ...} ->
              ...
    end.

and type check the code.

It's difficult to infer this kind of stuff so we might as well not
bother, and just *tell* the
system what the Pids mean.

Cheers

/Joe





On Sun, Aug 31, 2014 at 11:47 PM, Richard A. O'Keefe <ok@REDACTED> wrote:
>
> On 30/08/2014, at 12:16 AM, Thomas Lindgren wrote:
>
>>
>> Second, Sven-Olof Nyström's old Erlang type analyzer was, at least in theory, capable of inferring types for erlang messages and processes.
>
> Is there a reference for that?
>
>> However, even if we remove a number of language features, an Erlang process can contain many receives connected by arbitrary control flow. Thus, I'd expect that a gen_fsm or suchlike where you essentially implement protocols could potentially yield a very complex type.
>
> Type systems aren't all-or-nothing.  For example, Haskell's type
> system seems pretty amazing and as precise as you could wish for,
> until you meet dependent type systems like the one in Idris.
>
> A process type need not be *precise* to be useful.  Indeed, when
> you think about the fact that the type of a pid is not going to
> change, while the precise set of messages it is ready to receive
> *will* change from time to time, it's not clear that a precise
> type would be useful at all.
>
> A process type that can tell you "you idiot, you're trying to
> send a message that this process will NEVER accept under any
> conditions" is enough to be useful.
>
>
>
>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions