A Joeish Erlang distribution (long)
Tue Jan 28 12:42:58 CET 2003
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
- 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
The following modules are *removed*
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
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 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.
More information about the erlang-questions