A Joeish Erlang distribution (long)

[Robert Virding]

Yes Joe I completley agree! This is a change I have been pushing for years.

The core should be small, correct and not contain gen_* etc. Put these 
in a separate package which people can include when needed. They should 
also be rewritten only to use the stuff in the core. It is very 
important to get proper layering so as not to have the all-or-nothing 
situation of today. especially when it is not needed.

I think the lower layers should be something like:

Layer 0 - the emulator and BIF modules (BIFs are part of the language
           when you think about it)

Layer 1 - small basic kernel + stdlib

Layer 2 - this would contain other orthogonal groups which only use
           layer 0+1, e.g.
         - compiler
         - gen_* supervisor etc

Layer 3 - applications built on layer 0+1+2

etc.

I use groups here instead of calling them applications or packages so as 
not to clash with the existing ue of the words.

It is very important that different groups in a layer only depend on 
lower layers and not on other groups within the same layer.

Strict layering like this would make it easier to build streamlined 
applications as dependencies would be easy to trace. Now it is a mess, 
look at all the modules loaded just to get a prompt. Joe found he needed 
something like 30 modules just to run the compiler.

Note that this in no way stops Richard Carlssons packages, the groups 
above could be packages.

Robert


----- Original Message -----
From: "Joe Armstrong" <joe@REDACTED>


 > On Mon, 27 Jan 2003, Vance Shipley wrote:
 >
 > > On Mon, Jan 27, 2003 at 05:32:33PM +0100, Kenneth Lundin wrote:
 > > }
 > > }  Here are some comments from the Erlang/OTP Product Manager at 
Ericsson.
 > > }
 > > }  1) We have plans to divide the Erlang/OTP distribution into s 
number of
 > > }  separate packages. Preliminary we are thinking of 3 packages:
 > > }  - Core package 
(erts,kernel,stdlib,sasl,mnesia,os_mon,inets,compiler,..)
 > > }  - Tools&Utilities (parse_tools, tools, debugger, observer, et, 
tv, ...
 > > }  - Telecom/protocols (snmp, asn1, orber, megaco, ...
 > >
 > > I would suggest that the core package be even more limited.  All 
you really
 > > need to run Erlang is erts, kernel and stdlib.  A "Development" 
package
 > > would be appropriate.  If you think in terms of embedded systems 
and what
 > > they require it makes a cleaner seperation.
 >
 >   I  entirely agree  - snmp  mensia etc  are *applications  that are
 > written in Erlang - they should not therefore be in the core release.
 >
 >   The core should be:
 >
 > 1) The compiler
 > 2) The run time
 > 3) A minimal set of libraries to do something "useful"
 >
 >   Think C - a minimal set of stuff is
 >
 > - A compiler that runs "out of the box"
 > - A minimal set of libraries (libc) so you can do something.
 >
 >   IMHO we should have:
 >
 > - A compiler that runs "out of the box"
 > - Minimal library support
 >   Somewhere you have to "draw the line"
 >
 > My "minimal support" really means device drivers - so support
 > for files, sockets, binary filers, ... etc. is in - everything else 
is out.
 > also ets is so low level that it can be considered "part of the language"
 >
 >    We have to be pragmatic as well so I'd include
 >
 > - dets
 > - dynamic code loading
 > - the shell
 >
 >    As well in the core.
 >
 >    (But no snmp, mnesia, .... asn1 etc.) these are *applications* 
written in
 > Erlang - and no gen_server ... etc.)
 >
 >   IMHO  gen_tcp  etc.  dets  should  be  written  so  they  don't  use
 > gen_severer etc.  - BTW my stand-alone Erlang broke just when I wanted
 > to use dets and gen_tcp - the reason was the dets and gen_tcp uses all
 > the application stuff and the gen_* stuff.
 >
 >   One  of the  basic design  principles  underlying the  system is  (as
 > Martin Björkland said)
 >
 >   "There is stuff  that has to be right, and stuff  that doesn't - you
 > have to make you mind up."
 >
 >   IMHO the core should NOT be able to recover from errors - you get 
the core
 > right - period.
 >
 >   Applications  outside the  core can  if they  wish build  upon gen_*
 > modules  to make the  apps. fault-tolerant  - but  the core  should be
 > A. Priori assumed correct - and have no such code.
 >
 >   This is *why* the core should be as small as possible and include as
 > much pure code as possible (i.e code like in lists etc.)
 >
 >   I think the discussion should proceed upon a module per. module basis.
 >
 >   We should not be talking about which component lives in the core
 > (i.e. do we include snmp, corba etc.) but the discussion should be ...
 >
 >   The core is compiler+stdlib+sasl+kernel with the following
 > changes:
 >
 >   The following modules are *removed*
 >
 > supervisor_bridge.erl
 > sos.erl
 > supervisor.erl
 >      gen_*.erl
 > ...       etc.
 >
 >   Then  all the  remaining modules  should  be re-written  so that  NO
 > references are made to the stuff that is removed.
 >
 >   Finally we  will be able  to give an  exact and final list  of every
 > module in  the core with  a written argument that  motivates *exactly*
 > why it in the core.
 >
 >   When this has been done I will be happy.
 >
 >   IMHO the  average programmer should  be able to easily  remember all
 > the Erlang primitive and know about *all* the core modules do - Erlang
 > should and must be  a *small* langauge - that is easy  top learn - the
 > core libraries should have the same properties.
 >
 >   I can  volunteer to do this (I  can't do Jocke's big  project) - but
 > I'd need help (i.e.  volunteers to *remove* non core-dependencies from
 > dets and gen_tcp etc.).
 >
 >   All this  pre-supposes that the OTP  people like the idea  - since I
 > don't want to get into the "two systems" argument.
 >
 >   For those  people who like the  "big and everything  release" we can
 > bundle the  core with  *all* the applications  - if that's  what turns
 > them on.
 >
 >   I view  recoding and re-organizing the  core as *essential*  - in so
 > much as this will yield a tighter and more easily maintained system.
 >
 >   Actually the  job is easier  than you imaging  - you first  throw out
 > *everything* you cannot explicitly motivate  - then run - xref - this
 > tells you  which modules  you have to  re-write. The modules  you have
 > removed you  move to a  set of libraries  outside the core,  and then
 > re-write them using stuff *inside* core.
 >
 >   Comments?
 >
 >
 >
 > /Joe
 >
 >
 > >
 > > It would be nice if the build process asked what you wanted to 
build.  It
 > > is a pain to be waiting for your shiny new emulator to arrive and 
see that
 > > it's wasting your time building Corba tools.  I've adopted the 
procedure
 > > of first touching lib/cosEvent/SKIP etc.
 > >
 > > -Vance
 > >
 >
 >