Summary: E / Erlang integration

Michael FIG fig@REDACTED
Mon Jun 19 20:55:21 CEST 2006


Also sorry for the long delay... I missed your message in an e-mail filter somewhere.

>> To answer more about MarkM's comments, I'm talking about Erlang-E (E semantics
>> embedded in Erlang)
>waht are your thoughts about handling the non-blocking receive of E?
>do you want all e:when_catch() (made up name) to be non blocking?

Yes.  "promise_case" is my proposal to replace when/catch, since that way Erlang users can take advantage of pattern matching in their non-blocking receives.

>> without sugar:
>>> 
>>     e:pcase(e:send(RaceTrack, getPolePositionCar),
>>             fun (SomeFreshName) ->
>>                  case SomeFreshName of
>>                     FarPolePositionCar ->
>>                         io:format("My car is in pole position~n"),
>>                         matched;
>>                     _ ->
>>                         notmatched
>>                  end
>>             end,
>>             3000, fun () -> io:format("Timed out~n"),
>>             fun (E) -> ok end).

>could you explain how the 'notmatched case clause will be reached?

You're right, it wouldn't.  In my example, I was giving what I would consider to be automatically generated code.  The notmatched clause would only be reached if the caller did more restrictive patterns.

>also, perhaps it would be simpler to understand e:pcase/5 if you wrote 
>it like in edoc: @spec my_function(X::integer()) -> integer()

I'll do this.  I'm almost done a first implementation of the library, and intend to fully document the meaning and usage of all the functions.  This would give people a much better picture (i.e. working prototype) of what I have in mind.

>perhaps that would be:
>@spec pcase( Promise::promise(), Receive::function(), 
>Timeout_time::integer(), Timeout::function(), Error::function() ) -> atom()
>	promise() = ???

That's very close... the difference is that the first argument is an arbitrary term that can contain promises as deeply nested as you like.  So you could pass a tuple of promises, a list of promises, etc.

Thanks for your reply,
Michael.




More information about the erlang-questions mailing list