Suggested Example/ emacs questions

[Joe Armstrong]

On Tue, 10 Oct 2000, Ulf Wiger wrote:

> On 10 Oct 2000, Luke Gorrie wrote:
> 
> >Yup. Lately I've been noticing that I don't write the receive loops of
> >many servers, because I just use gen_server. That seems like a shame
> >because what I really miss is the lovely "I communicate, therefore I
> >synchronise" style you get if you use guarded receive clauses to
> >decide in which order you'll receive messages, e.g.:
> >
> >  receive {push, Item} when Full == false ->
> >
> >to implicitly block push requests for a bounded stack while it's full,
> >and that sort of thing. The stuff I got excited about when reading
> >_communicating sequential processes_.
> >
> >Anyone empathise? :-) I'm not sure whether it's just that most of my
> >programs don't need guarded receives and fancy synchronisation, or
> >whether I'm just too far into the habbit of using gen_server to write
> >beautiful receive loops. I'm suspicious that it's the latter :)
> 
> 
> I certainly empathise.
> 
> I, too, miss the good old days when I wrote my own receive 
> statements. You can't really beat the vanilla Erlang FSM for beauty.
> What messes things up are those darn system messages, and trace
> and debug functionality.

    The reason  behind the gen_servers  FSM's, worker-supervisor trees
etc. was twofold

    1) Get everybody programming the same way

    We  observed  that  in  big  projects  with  lots  of  programmers
different programmers  used different ways of  programming things (say
client-server) -  we didn't want there  to be ten  ways of programming
client-server in one  project. So we made the  gen_server behaviour to
do this -  then all the programmers would use the  same way to program
client-server  and  it  would be  easy  (the  idea  was) for  them  to
understand each other's code.

    2) Give novice programmers access to expert code

    There      are     several     "gottcha's"      in     programming
client-server/worker-supervisor  (especaily if  you want  to  do fancy
stuff) - When  a novice programmer tries to  "roll-their-own" they can
made some fairly serious errors  (I've seen some examples posted here,
Non tail-recursive  code for example) -  so the idea was  to provide a
generic  framework where  novices  could plug  in  their own  callback
routines.

   The idea was "If you're an expert and know what you're doing then 
feel free to 'roll-your-own' otherwise use the appropriate generic code" -
Of course you loose the feeling of "seat of pants" control if you use the
generic methods but you gain convenience plus the fact that other people
can understand your code.

    For  small hacks  I always  "roll-my-own"  - but  for big  systems
programming I'd either use the  generic-methods OR write a new generic
method first and then use that.

> 
> As far as trace and debug is concerned, OTP R7 should give us an
> opportunity to achieve much more elegant debugging.
> 
> System messages are much harder. How to accomplish the suspend/
> code_change/resume functionality, as well as the ordered shutdowns,
> without messing up the normal program?
> 
> I've been wishing for some kind of "protected mode" section, where
> I can write hooks to modify message reception; system messages 
> would then be somehow pre-empted by OTP, unless I explicitly state
> that I want to see them.
> 
> ... or am I smoking something funny?

    Not in the slightest.

    OTP  was designed under  great time  pressure -  and was  the 2'nd
attempt at an architecture. It's roots  were the BOS (Basic OS) of the
ACS/Dunder project + diverse generic servers from the CS lab.

    It would be nice to do a 3'rd architecture and feed into it what was
learn't since OTP.

    Certain things are very wrong and  very deep :-( - I'd like to see
a *strict* pre-defined module structure and a strict OS ring structure to start
with - also a strict package  structure. If you, for example, plot the
intermodule call graph you get pure  spagetti - A strict tree would be
*much* nicer. The system should also have a stricter type structure -
For example, file names can still be atoms, strings or deep strings - 
this despite the fact we tried to encourage people to use only flat strings.

    Some of ROK's ideas on "flotillas" should be implemented (export_to) etc.


   /Joe

--
Joe Armstrong,                       
Alteon WebSystems,                     tel:  +46 8-545 550 00
S:t Eriksgatan 44, IV,                 fax:  +46 8-545 550 50
SE-112 32 Stockholm, Sweden            info: www.bluetail.com