[erlang-questions] Ideas for a new Erlang

[Sven-Olof Nystr|m]

Ulf Wiger writes:
 > 2008/7/22 Sven-Olof Nystr|m <svenolof@REDACTED>:
 > > Ulf Wiger writes:
 > 
 > >  >
 > >  > A good place to start might be the POTS control program, which was
 > >  > presented in the Erlang book, and also used (in a slightly different form)
 > >  > in the Introductory Erlang course.
 > >  >
 > >  > I used it in my "Structured Network Programming" presentation to
 > >  > show the consequences of different programming styles in multiway
 > >  > signaling:
 > >  >
 > >  > http://www.erlang.se/euc/05/1500Wiger.ppt
 > >  >
 > >  > I'm not convinced that it will be sufficient to reveal significant differences
 > >  > between the standard erlang style and channels, but it's a good place to
 > >  > start, and the code can be expanded in a number of interesting ways.
 > >  >
 > >  > BR,
 > >  > Ulf W
 > >  >
 > >  > (There's a working simulator to go with the program, but the OTP team
 > >  > would have to give permission to release it in public. I'm sure you can
 > >  > get your hands on it anyway.)
 > >
 > >
 > > Sorry about disappearing from the discussion for so long.
 > >
 > > I took a look at the POTS program in the Erlang book. It is actually
 > > easy to rewrite it to use neither channels nor selective receive.
 > >
 > > I also looked at the gen-server module.
 > >
 > > Detailed comments follow. (A non-selective receive is one that always
 > > pick the first message in the mailbox.)
 > >
 > > Sven-Olof
 > >
 > >
 > >
 > > The book's implementation of POTS only contains four receive
 > > expressions. Among these, only one (in the function make_call_to_B/3)
 > > is selective.
 > 
 > You should also take a look at the presentation that I referred to.
 > 
 > Just looking at the example in the book, you are making the same
 > mistake as the Nordlander thesis on OHaskell. The POTS system
 > also uses messages to control the switch hardware, and this control
 > is stateful and synchronous. Furthermore, I believe that the MD110
 > hardware had no way to queue requests, so the control system must
 > take care to issue only one request at a time.
 >
 > The OHaskell example assumed that functions like start_tone()
 > were atomic and non-blocking - they are not.

OK, I actually wrote a simple framework to be able to run the
code. The framework used a process to simulate the hardware and
naturally there were some receive expressions, for example in
analyse(). But the function start_tone and other similar functions
were not blocking. I saw those as being outside the POTS example, so I
did not comment on them. (The communications followed the simple
pattern I discussed in the example with the counter program.)

 > In my presentation, I also made the number analysis asynchronous,
 > which may seem far-fetched in the limited POTS example, but is quite
 > realistic when one considers modern IP-based telephone. The
 > idea was to convert synchronous requests into explicit asynchronous
 > request-reply pairs, and having at least two such protocols that could
 > interleave.

I noted a slide with the comment "simple main event loop with fifo
semantics". Seems to be similar to what I am trying to do.

You bring up some interesting issues in your presentation but the code
you show don't seem to make much use of selective receive.

I am not sure what you mean by synchronous and unsynchronous. In
an Erlang context, I thought synchronous meant a communication
implemented as a send-request pair, but you seem to be making a
distinction here. Also, aren't all Erlang programs event-based
(event=message)?

 > A SIP signaling control system can make as much as 5-10 network-
 > based (or more) requests for one call, for things like billing,
 > admission control, location lookup, resource allocation, etc.
 > All conceptually synchronous,  but the SIP signaling is asynchronous.
 > The interleaving of all signals make a global state-event matrix
 > impossibly complicated, so conceptual layering is essential.

This is interesting stuff. I suppose one can't simply split one side
of a communication into several processes? 


Sven-Olof