Higher order receieve anybody

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Higher order receieve anybody

Joe Williams-2

I've just been reading the discussion
"Re: plain_fsm - for beginners and purists"

and read the following:

> > Okay, what about
> >
> > receive
> >     .... %% normal clauses
> >     Msg ->
> >         plain_fsm:handle(State, Msg,
> > Fun_that_handles_non_system_messages)
> > end;
> >
> > It's a little ugly, but maybe not too much.
>

What Uffe and Vlad *really* need is a "higher order" receives ...

The idea is to rewrite:

        receive
           {a, X} -> ...
           b ->
           Y -> ...
        end

as

        F = fun({a,X}) -> ...
               (b) -> ...
               (Y) -> ...
            end,
        Z = receive F,
       

If we introduce an infix ? operator, we'd get:

        Z = ?F

Why is it not like this today? - Answer: a historical accident.

To begin with we had only first order functions, both functions
and receive patterns were first order.

We talked for a long time about "higher order patterns" in receives
without really understanding what this meant.

The notion of a pattern is intimately connected to the notion of an action
which must be performed when the pattern is matched - the *combination*
of a pattern and an action is expressed in the fun notation.

    Fun = fun(Pattern1) -> Actions1;
             (Pattern2) -> Actions2;
             ...
          end.

Now receive is first order - ie it only takes fixed patterns. We write

   receive
      Pattern1 -> Actions1;
      Pattern2 -> Actions2;
      ...
   end

This is very near but not quite the syntax of a Fun - so why not be consistent
and add higher order receive patterns, thus

   receive
     fun(Pattern1) -> Actions1;
        (Pattern2) -> Actions2;
        ...
     end.

Then receive becomes higher order and we can write

   Fun = fun(Pattern1) -> Actions1;
            (Pattern2) -> Actions2
            ...
         end
   receive Fun

and Uffe's plain_fsm becomes a simple higher order function.

   /Joe

So now all I'd like in Erlang is:

1) Higher order code
2) *Proper* structs
3) !!
4) Higher order receive
5) A *tiny* implementation (written 99% in Erlang and 1% in ANSI standard C)
   



Reply | Threaded
Open this post in threaded view
|

Higher order receieve anybody

Ulf Wiger (AL/EAB)
On Tue, 17 Feb 2004 10:10:31 +0100 (CET), Joe Armstrong <joe>
wrote:


> What Uffe and Vlad *really* need is a "higher order" receives ...
>
> The idea is to rewrite:
>
> receive
>   {a, X} -> ...
>   b ->
>   Y -> ...
> end
>
> as
>
> F = fun({a,X}) -> ...
>       (b) -> ...
>       (Y) -> ...
>    end,
> Z = receive F,
>
>
> If we introduce an infix ? operator, we'd get:
>
> Z = ?F

My first (*) version looked like this:

idle(S) ->
    plain_fsm:recv(
       fun({a, x}) -> ...;
          (b) -> ....
          (Y) -> ...
       end).

(*) in this iteration; I've attacked the problem a number of times
over the past years.

This happens to be quite similar to what you propose, except
of course that you propose a language change, while my hack
was just a way to trigger the parse_transform.

I changed it to

  plain_fsm:extended_receive(
    receive
        ...
    end)

because it was easier to introduce into legacy code.

3.5 years ago, I had the idea that one should be able
to extend the receive semantics using some "system directive"
(disregard the syntax):

$extend_receive(system_receive) ->
    receive
       {system, From, Msg} ->
          sys:handle_system_messages(...);
       $receive()
    end.

But with Joe's suggestion, no keyword redefinition or
parse_transform is needed.

(I also imagined the directives $inherit_api(FromModule) and
$fast_path(Function, Arity) -> hard | {slow_path, fun()}
(where 'hard' indicates EXIT if the fast-path code throws an
exception; and {slow_path, F} means, exit and run F instead.))

/Uffe
--
Ulf Wiger, Senior System Architect
EAB/UPD/S

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.



Reply | Threaded
Open this post in threaded view
|

Higher order receieve anybody

Vlad Dumitrescu-4
In reply to this post by Joe Williams-2
----- Original Message -----
From: "Joe Armstrong" <joe>

> What Uffe and Vlad *really* need is a "higher order" receives ...
>
> The idea is to rewrite:
>
> receive
>    {a, X} -> ...
>    b ->
>    Y -> ...
> end
>
> as
>
> F = fun({a,X}) -> ...
>        (b) -> ...
>        (Y) -> ...
>     end,
> Z = receive F,

Hi Joe,

I have a headache today, so I am not sure I understand what you mean (when it
comes to what we discussed before). If you have some time to explain, I wil be
very happy :-)

What we need is to be able to dynamically insert clauses in the fun (or
receive), so that system messages get processed.

If matching incoming messages is done just on F's clauses (i.e. {a, X}, b and
Y), then I don't see any difference from what we have today. If however the
compiler would expand

 G = fun({m,X}) -> ...
        (z) -> ...
        (Y) -> ...
     end,
 F = fun({a,X}) -> ...
        (b) -> ...
        (Y) -> G(Y)
     end,
 receive F,

into something equivalent to

 receive
    {a,X} -> ...
    b -> ...
    {m,X} -> ...
    z -> ...
    Y -> ...
 end,

then I clearly see the point. I think it would work only if G is a fun (or
possibly a local function), because ordinary external functions may change at
runtime and we'd need to recompile dependent modules.

Was it something like this you meant?

best regards,
Vlad



Reply | Threaded
Open this post in threaded view
|

Higher order receieve anybody

Chris Pressey
In reply to this post by Joe Williams-2
On Tue, 17 Feb 2004 10:10:31 +0100 (CET)
Joe Armstrong <joe> wrote:

> What Uffe and Vlad *really* need is a "higher order" receives ...
>
> The idea is to rewrite:
>
> receive
>   {a, X} -> ...
>   b ->
>   Y -> ...
> end
>
> as
>
> F = fun({a,X}) -> ...
>       (b) -> ...
>       (Y) -> ...
>    end,
> Z = receive F,
>
>
> If we introduce an infix ? operator, we'd get:
>
> Z = ?F

s/infix/prefix/g

Does this mean that funs will be able to have an 'after' clause?  :)

-Chris


Reply | Threaded
Open this post in threaded view
|

Higher order receieve anybody

Shawn Pearce
In reply to this post by Joe Williams-2
Joe Armstrong <joe> wrote:
> 1) Higher order code

Then we'd have LISP.  :-)

> 2) *Proper* structs

Ah, yes, this debate.  When will they be ready?  :-)

> 3) !!

Timeouts are a concern.  Perhaps the timeout can be set as a
process flag: process_flag(default_rpc_timeout, Ms).  With the timeout
throwing an exit:  exit({rpctimeout, To, Message}).  This is really just
a parse transform:

        begin
                Tag = make_ref(),
                To ! {rpc, Tag, Message},
                receive
                {reply, Tag, Response} ->
                        Response;
                after process_flag(default_rpc_timeout) ->
                        exit({rpctimeout, To, Message})
                end
        end

We just need the process flag.  :-)

But, if !! ever comes into Erlang/OTP, it better work with the gen_server
call format.  :)

> 4) Higher order receive

Well, a better receive over all that does everything we're all wishing
receive could do would be great.  Especially if I could write:

        receive
        {java, WorkingProgram} ->
                {no_more_work_for_shawn, WorkingProgram}
        end

and quit my day job.  :-)

> 5) A *tiny* implementation (written 99% in Erlang and 1% in
> ANSI standard C)

Ever since I was introduced to Erlang right after the initial open
source release, I've thought about doing this for fun.  Squeak (the
Smalltalk created by Disney I believe) is built like this.  Most of
the Squeak runtime is actually Smalltalk code compiled with a simple
compiler.  Only some of the language and its features is supported
when the low level parts of the runtime get built, but I've heard that
even the GC in Squeak is written in Smalltalk.

I've often thought over the years that an Erlang runtime could be
built by creating a primitive Erlang language that was a subset of
most of the language, with perhaps destructive updates allowed against
binaries (and only binaries).  This would let you map the memory of
your host into the runtime, then write the entire GC, tuple BIFs, etc
in Erlang code.  When that turns into native machine code, it should
come out close to what the hand written C would have been.  Clearly
destructive updates would be limited to only a very small segment of
code, and would be disallowed by the real code loader used at runtime,
to prevent users from trying to use the really low level feature.

A few times I've theorized to myself that it may be possible to do this
in pure Erlang, without destructive update, so long as a copying
garbage collector is used to manage the heap.  One implementation might
be to model each half-heap as a binary.  Allocation is performed by
splitting the half-heap binary in two parts, with the A part being the
space used by the new cons cell, tuple, binary, etc. and the B part
being the remaining free space, which is now just a slightly smaller
binary.  The problem is, how do you update the A part and fill in the
tuple's data, or the cons cell data, etc. initially in a single
assignment, non-desctructive language.  :)

I've just never gotten to this project, I've always had something else
that was distracting me.  I wish I had, because I'm getting into
Erlang more, and wondering why I didn't try to do this several years
ago instead of screwing around with Java.

--
Shawn.

  share, n.:
  To give in, endure humiliation.


Reply | Threaded
Open this post in threaded view
|

Higher order receieve anybody

Robert Virding-5
In reply to this post by Joe Williams-2
----- Original Message -----
From: "Joe Armstrong" <joe>
To: <erlang-questions>
Sent: Tuesday, February 17, 2004 10:10 AM
Subject: Higher order receieve anybody


> What Uffe and Vlad *really* need is a "higher order" receives ...
>
> The idea is to rewrite:
>
> receive
>    {a, X} -> ...
>    b ->
>    Y -> ...
> end
>
> as
>
> F = fun({a,X}) -> ...
>        (b) -> ...
>        (Y) -> ...
>     end,
> Z = receive F,
>
>
> If we introduce an infix ? operator, we'd get:
>
> Z = ?F

I think this would be a very good idea, and quite easy to implement as well.
Though there area few potentially difficult points. If I understand what you
mean then for

receive F end

you would evaluate F for each message in the queue with the message as
argument. If the function returns a value then that message is "received"
and receive returns the function return value. If the functions exits then
the message is put back in the queue and we go to the next message. Simple.

A few points:

1. Syntactically you still want receive ... end, the syntax of catch was a
big mistake so don't repeat it. We don't need more operators.
2. Timeouts would not be handled within the fun but instead have
    receive F after ... end
as before. Having timeouts in the fun would be difficult to define, explain
and implement.
3. You wouldn't need to implement this by expanding the fun, you would call
it every time.

Now for the really tough bit. Semantically this is a nightmare when you
really look into it. You get exactly the same problems as for evaluating
user defined functions in a guard. A simple example, what happens if you d
receive in the receive fun, where do you start in the message queue and
where do you stop? Choosing and extracting the message is "guard like" and
within it it is difficult to handle user functions.

OK, you could say that you handle just just the clause selection bit of the
fun as the message selection part and then handle the rhs as the rhs of the
fun. This is difficult as the fun was meant to be a general fun and not
specially compled. Well set a flag and test at commit time, easy. I think
the current compiler has done away with commit, there is no need for.

My point is that when you really delve into it it becomes difficult in most
respects. Sorry to be a wouser.

> So now all I'd like in Erlang is:
>
> 1) Higher order code
> 2) *Proper* structs
> 3) !!
> 4) Higher order receive
> 5) A *tiny* implementation (written 99% in Erlang and 1% in ANSI standard
C)

Definitely yes to 1,2 and 5. I don't really see the point of having !!, if I
understand it correctly it is just syntactic sugar so why bother. How about
replacing ! with erlang:send/2?

Robert



Reply | Threaded
Open this post in threaded view
|

Higher order receieve anybody

Thomas Lindgren-5

--- Robert Virding <robert.virding> wrote:

> If I understand what you
> mean then for
>
> receive F end
>
> you would evaluate F for each message in the queue
> with the message as
> argument. If the function returns a value then that
> message is "received"
> and receive returns the function return value. If
> the functions exits then
> the message is put back in the queue and we go to
> the next message. Simple.

Maybe there should just be an operation to reify the
mailbox (e.g., empty it and make it a list of terms)
as well as the other way around (e.g., prepend a list
to your own message queue). Then programmers could
write receive (with suitable extra operations to code
after-clauses) any way they liked and provide those as
library functions.

However, to grouch a bit, I'd say receive F end seems
like tinkering. I'd prefer something with more oomph.
(Likewise for !!. And probably structs as well.)

> How about replacing ! with erlang:send/2?

Nowadays, my code tends to use gen_server:call/2 and
suchlike, so I wouldn't mind. Much.

Best,
Thomas


__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools


Reply | Threaded
Open this post in threaded view
|

Higher order receieve anybody

Robert Virding-5
----- Original Message -----
From: "Thomas Lindgren" <thomasl_erlang>
To: <erlang-questions>
Sent: Saturday, February 21, 2004 10:48 PM
Subject: Re: Higher order receieve anybody


>
> --- Robert Virding <robert.virding> wrote:
> > If I understand what you
> > mean then for
> >
> > receive F end
> >
> > you would evaluate F for each message in the queue
> > with the message as
> > argument. If the function returns a value then that
> > message is "received"
> > and receive returns the function return value. If
> > the functions exits then
> > the message is put back in the queue and we go to
> > the next message. Simple.
>
> Maybe there should just be an operation to reify the
> mailbox (e.g., empty it and make it a list of terms)
> as well as the other way around (e.g., prepend a list
> to your own message queue). Then programmers could
> write receive (with suitable extra operations to code
> after-clauses) any way they liked and provide those as
> library functions.

That would probably be a cleaner way of doing it. Though it would be a
little tricky to handle timeouts. I can't see that there would be real
problems with it, though I will have to think abit.

How much oomph do you want?

Robert



Reply | Threaded
Open this post in threaded view
|

Higher order receieve anybody

Thomas Lindgren-5

--- Robert Virding <robert.virding> wrote:
> That would probably be a cleaner way of doing it.
> Though it would be a
> little tricky to handle timeouts. I can't see that
> there would be real
> problems with it, though I will have to think abit.
>
> How much oomph do you want?

Personally, I'm not convinced receive needs much
beyond what we already have. Messing around with
mailboxes (as I proposed) sounds like a typical "under
the hood" issue. (Or are there cases where this is a
huge help to the programmer? It might come in handy
for erlang-in-erlang, but for application
programmers?)

Best,
Thomas


__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools


Reply | Threaded
Open this post in threaded view
|

Higher order receieve anybody

Ulf Wiger (AL/EAB)
On Mon, 23 Feb 2004 23:42:00 -0800 (PST), Thomas Lindgren
<thomasl_erlang> wrote:

>
> --- Robert Virding <robert.virding> wrote:
>> That would probably be a cleaner way of doing it.
>> Though it would be a little tricky to handle timeouts.
>> I can't see that there would be real problems with it,
>> though I will have to think abit.
>>
>> How much oomph do you want?
>
> Personally, I'm not convinced receive needs much
> beyond what we already have. Messing around with
> mailboxes (as I proposed) sounds like a typical "under
> the hood" issue. (Or are there cases where this is a
> huge help to the programmer? It might come in handy
> for erlang-in-erlang, but for application
> programmers?)

I do not see much need for application programmers messing
around with the mailbox. There are almost always fairly
simple workarounds in the cases where it might be warranted.

Handling system messages is the one area where I've found it
necessary to raise the abstraction level above what 'receive'
provides. There are workarounds -- they are called gen_server
and gen_fsm, but they have the unfortunate side-effect of
imposing an un-erlangish message reception paradigm on the
unsuspecting user.

I would like to see the possibility to divide messages into
two separate categories: administrative (such as suspend,
resume, inspect, upgrade) and operative (whatever the program
is _really_ supposed to do. And I would like to be able to keep
them separated without messing up the programming semantics.

/Uffe
--
Ulf Wiger, Senior System Architect
EAB/UPD/S

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.



Reply | Threaded
Open this post in threaded view
|

Higher order receieve anybody

Vlad Dumitrescu-4
From: "Ulf Wiger" <ulf.wiger>
> Handling system messages is the one area where I've found it
> necessary to raise the abstraction level above what 'receive'
> provides. There are workarounds -- they are called gen_server
> and gen_fsm, but they have the unfortunate side-effect of
> imposing an un-erlangish message reception paradigm on the
> unsuspecting user.

I agree fully.

> I would like to see the possibility to divide messages into
> two separate categories: administrative (such as suspend,
> resume, inspect, upgrade) and operative (whatever the program
> is _really_ supposed to do. And I would like to be able to keep
> them separated without messing up the programming semantics.

I could even imagine such a separation hard-wired into the language (i.e. the
normal receive would work like Ulf's extended receive). Yes, there would be a
change in semantics, but almost no one would notice it because normal uses are
not affected. Handling system messages would be done behind the scenes by a
default handler, but this should be customizable.

Then the next generation of gen_server and friends will look a lot more like
regular processes! :-)

regards,
Vlad




Reply | Threaded
Open this post in threaded view
|

Higher order receieve anybody

Shawn Pearce
In reply to this post by Ulf Wiger (AL/EAB)
This is a pretty good idea.  Except that the 'system' category should
be extensible, so behaviors can add their own notion of what 'system'
is.  For example, some of my behaviors I'd like to have inspect messages
that the end-developer doesn't have to get involved in; as the behavior
offers those services to the developer.

If receive F end was possible, it might be nice to register a fun in a
process_flag, e.g. process_flag(system_message_handler, F).  When the
user application wants to accept system messages, the receive call adds
another keyword:

        receive
        system;
        ... -> ...
        end.

The runtime scans the mailbox for the first message that matches either
the current receive pattern, or the fun set as the
system_message_handler.  The only issue is where do you resume execution
after the sys module has processed the message...

I think higher order receive is a lot like my "why aren't modules just
sets of variables bound to funs" question.  :)  Sure its nice and all,
but the reality is, most developers would prefer to write:

        receive
        {foo, ...} -> ...
        end

over

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

any day.  But it does at least allow usage like:

        plain_fsm_receive(fun({foo, ...}) -> ... end)

assuming that the higher order receive allowed multiple funs at once:

        plain_fsm_receive(F) ->
                SytemHandler = fun(...) -> ... end,
                receive SystemHandler, F end.

But then I'd have to just ask for erlang:receive([F]), as in:

        receive([SystemHandler, F]).

and say forget keywords.  The receive keyword is only nice as a
syntatic sugar form of the receive BIF and a list of 0 argument funs,
created from the body of the keyword.


One problem with system messages is how processing resumes.  In fact,
I think that is the more difficult part of this discussion; as there
is no one way to behave after a system message is processed...

Ulf Wiger <ulf.wiger> wrote:

> I do not see much need for application programmers messing
> around with the mailbox. There are almost always fairly
> simple workarounds in the cases where it might be warranted.
>
> Handling system messages is the one area where I've found it
> necessary to raise the abstraction level above what 'receive'
> provides. There are workarounds -- they are called gen_server
> and gen_fsm, but they have the unfortunate side-effect of
> imposing an un-erlangish message reception paradigm on the
> unsuspecting user.
>
> I would like to see the possibility to divide messages into
> two separate categories: administrative (such as suspend,
> resume, inspect, upgrade) and operative (whatever the program
> is _really_ supposed to do. And I would like to be able to keep
> them separated without messing up the programming semantics.

--
Shawn.

  While riding in a train between London and Birmingham, a woman
  inquired of Oscar Wilde, "You don't mind if I smoke, do you?"
  Wilde gave her a sidelong glance and replied, "I don't mind if
  you burn, madam."


Reply | Threaded
Open this post in threaded view
|

Higher order receieve anybody

Tony Rogvall-3
In reply to this post by Ulf Wiger (AL/EAB)

On Tuesday, Feb 24, 2004, at 09:48 Europe/Stockholm, Ulf Wiger wrote:
>
> I would like to see the possibility to divide messages into
> two separate categories: administrative (such as suspend,
> resume, inspect, upgrade) and operative (whatever the program
> is _really_ supposed to do. And I would like to be able to keep
> them separated without messing up the programming semantics.

One idea (tested and implemented) is to use a primitive
erlang:signal(Pid,Sig, Info) to send
a primitive form of messages.  For example message passing could be
implemented as
erlang:signal(Pid, 'MESSAGE', Message). In Multi Pro Erlang we did the
signal dispatcher in C code.
In retrospect we should have implemented a signal dispatcher /
signal_handler in Erlang. This way
all signals (including messages) would be processed by Erlang code.
Then one could implement
the link semantics and message reception etc in Erlang code!
The signal handler should be called in the context of the receiving
process with some kind of
interrupt semantics (when it comes to receive).


-module(signal_handler).
-export([handle_signal/3]).

handle_signal(From, 'MESSAGE', Message) ->
        erlang:queue_message(Message);
handle_signal(From, 'LINK', _) ->
          erlang:add_link(From);
...
       

/Tony



> /Uffe
> --
> Ulf Wiger, Senior System Architect
> EAB/UPD/S
>
> This communication is confidential and intended solely for the
> addressee(s). Any unauthorized review, use, disclosure or distribution
> is prohibited. If you believe this message has been sent to you in
> error, please notify the sender by replying to this transmission and
> delete the message without disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data corruption,
> interruption, unauthorized amendment, tampering and viruses, and we
> only send and receive e-mails on the basis that we are not liable for
> any such corruption, interception, amendment, tampering or viruses or
> any consequences thereof.



Reply | Threaded
Open this post in threaded view
|

Higher order receieve anybody

Ulf Wiger (AL/EAB)
On Tue, 24 Feb 2004 15:11:46 +0100, Tony Rogvall <tony> wrote:

> One idea (tested and implemented) is to use a primitive
> erlang:signal(Pid,Sig, Info) to send a primitive form of messages. For
> example message passing could be implemented as erlang:signal(Pid,
> 'MESSAGE', Message). In Multi Pro Erlang we did the signal dispatcher in
> C code. In retrospect we should have implemented
> a signal dispatcher / signal_handler in Erlang. This way
> all signals (including messages) would be processed by Erlang code. Then
> one could implement the link semantics and message reception etc in
> Erlang code!
> The signal handler should be called in the context of the receiving
> process with some kind of interrupt semantics (when it comes to receive).
>
>
> -module(signal_handler).
> -export([handle_signal/3]).
>
> handle_signal(From, 'MESSAGE', Message) ->
> erlang:queue_message(Message);
> handle_signal(From, 'LINK', _) ->
>           erlang:add_link(From);
> ...


Very nice!  (:

/Uffe
--
Ulf Wiger, Senior System Architect
EAB/UPD/S

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.



Reply | Threaded
Open this post in threaded view
|

Higher order receieve anybody

Vlad Dumitrescu-4
In reply to this post by Shawn Pearce
From: "Shawn Pearce" <spearce>

> One problem with system messages is how processing resumes.  In fact,
> I think that is the more difficult part of this discussion; as there
> is no one way to behave after a system message is processed...

Could you please elaborate a little? I only see one way that is "natural" -
handling system messages is transparent and processing stays in the receive
loop.

<blurb>
> ... and say forget keywords.  The receive keyword is only nice as a
> syntatic sugar form of the receive BIF and a list of 0 argument funs,
> created from the body of the keyword.

I say: let's get rid of all keywords! :-) What do we get then? No, not Forth,
but Lisp.
Seriously.

regards,
Vlad


Reply | Threaded
Open this post in threaded view
|

Higher order receieve anybody

Vlad Dumitrescu-4
In reply to this post by Tony Rogvall-3
From: "Tony Rogvall" <tony>

>
> One idea (tested and implemented) is to use a primitive
> erlang:signal(Pid,Sig, Info) to send
> a primitive form of messages.  For example message passing could be
> implemented as
> erlang:signal(Pid, 'MESSAGE', Message). In Multi Pro Erlang we did the
> signal dispatcher in C code.
> In retrospect we should have implemented a signal dispatcher /
> signal_handler in Erlang. This way
> all signals (including messages) would be processed by Erlang code.
> Then one could implement
> the link semantics and message reception etc in Erlang code!
> The signal handler should be called in the context of the receiving
> process with some kind of
> interrupt semantics (when it comes to receive).
>
>
> -module(signal_handler).
> -export([handle_signal/3]).
>
> handle_signal(From, 'MESSAGE', Message) ->
> erlang:queue_message(Message);
> handle_signal(From, 'LINK', _) ->
>           erlang:add_link(From);
> ...

Super cool!

/Vlad