Structs (was RE: Record selectors)

Mikael Karlsson mikael.karlsson@REDACTED
Sun Jan 19 23:49:57 CET 2003


söndag 19 januari 2003 19:28 skrev Ulf Wiger:
> On Sun, 19 Jan 2003, Sven-Olof Nystr|m wrote:
.
.
> >Implementing this without selective (matching) receive
> >would require the ability to create a new channel,
> >something like this:
> >
> >stop_tone() ->
> >    Ch = new_channel()  % Create a new channel
> >    <some hardware> ! {stop, Ch},
> >    receive(Ch) of      % Read message from channel Ch
> >        ok ->
> >            true
> >    after ...
> >    end.
>
> Yes, except I would still call it selective receive.
>
> >As far as I can see, the second solution introduces no new
> >complications in the state machine nor any new
> >dependencies. I don't know anything about the Haskell
> >solution, but I wouldn't be surprised if they are doing
> >something similar.
>
> They might well be doing it like that (it was not obvious to
> me how they do it.) I agree that being able to create
> temporary channels solves the lim:stop_tone() problem
>

Well,
actually it seems they are "cheating" and just send an asynchrounous
stop_tone message without expecting any return and then immediately 
set the state to Idle:
....
                 on_hook' = do
                     if null nr then
                         tele_os.stop_tone myaddr
                     state := idle
...
Timber ( or O'Haskell ) actually have both asynchronous (Actions)  and 
synchronous (Requests) methods, so making stop_tone a synchronous
request would make it more similar to the Erlang way. The synchronous calls
I have seen seem only to access and return internal state variables though.
I guess in order to avoid deadlock :-). The normal way when things take time
seems to be to install callbacks.
The point about selective receive from the message queue is quite a good one,
but if you want to simulate digital circuits which was Chris intention, I
think that reactive objects are quite appropriate. It is quite difficult to do 
a selective receive of whathever the state changes on the pins are.

I just finish up with a small Queue example from the O'Haskell distro , 
were you can see their solution on records, destructive assignment (yes,
you are allowed to do it on state variables), encapsulation, 
message passing and typing. 

And then I'll resume only asking questions about Erlang :-)
Thanks
Mikael
---------------------------
module Queue where

record Queue a =
   insert   :: a -> Action
   announce :: (a -> Action) -> Action
   
queue =
   template
      packets := []
      servers := []
   in record
      insert p = action
         case servers of
            []   -> do packets := packets ++ [p]
            s:ss -> do s p; servers := ss
      announce s = action
         case packets of
            []   -> do servers := servers ++ [s]
            p:ps -> do s p; packets := ps




More information about the erlang-questions mailing list