A Joeish Erlang distribution (long)
Wed Jan 29 01:25:34 CET 2003
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.
- gen_* supervisor etc
Layer 3 - applications built on layer 0+1+2
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.
----- Original Message -----
From: "Joe Armstrong" <>
> 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
> > }
> > } 1) We have plans to divide the Erlang/OTP distribution into s
> > } separate packages. Preliminary we are thinking of 3 packages:
> > } - Core package
> > } - Tools&Utilities (parse_tools, tools, debugger, observer, et,
> > } - Telecom/protocols (snmp, asn1, orber, megaco, ...
> > I would suggest that the core package be even more limited. All
> > need to run Erlang is erts, kernel and stdlib. A "Development"
> > would be appropriate. If you think in terms of embedded systems
> > 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
> 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*
> 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
> 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
> The following modules are *removed*
> ... 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.
> > It would be nice if the build process asked what you wanted to
> > is a pain to be waiting for your shiny new emulator to arrive and
> > it's wasting your time building Corba tools. I've adopted the
> > of first touching lib/cosEvent/SKIP etc.
> > -Vance
More information about the erlang-questions