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