Packages in Erlang: new documentation

[Richard Carlsson]

On Wed, 3 Sep 2003, WILLIAMS Dominic wrote:

> There is just one problem, from my point of view: they force one to
> import everything global (lists, io, etc.), or add a . in front of
> these modules [...] As I am sick of keeping track of #includes and
> imports, I enjoyed this not being necessary in Erlang.

An Erlang system without packages is very much like a Unix system
with a command shell and its search path - a single, global namespace.
It has its points - you can access a huge number of commands/modules
with a small amount of typing - if you can remember the names for
everything. This is one reason why many people like Unix. And also
one of the main reasons why many people hate it.

And even in Unix, you typically do not include _all_ possible
directories that contain executables in your standard path.
Lesser-used executables are usually referred to via their full path,
such as /usr/sbin/ifconfig. But in Erlang, everything needs to be
in the code path.

The main points with a package system are:

	- you can use short, natural names for "local things"
	- you don't have to import local names

and my motivation was to not have to see any more horrible module
names such as:

	CosEventChannelAdmin_ProxyPushConsumer_impl
	oe_CosEventComm_CAdmin_impl
	sys_core_fold
	sasl_report_file_h
	orber_iiop_tracer_silent
	mnesia_frag_old_hash
	tool_file_dialog
	io_lib_fread
	inet_gethost_native
	hipe_sparc_ra_post_ls_fp
	hipe_x86_ra_ls_postconditions

(also the long file names - add a ".beam" to the above),
not to mention obscurities such as:

	pg2
	sofs
	c
	si
	rb
	i
	uri

(Hands up all of you who knew that these short names were already
in use, and extra points if you can tell me what applications they
belong to - no peeking!)

For instance, how is anyone supposed to know that the name
"tool_file_dialog" is already being used by the GS application,
so you can't use it in your new wonderful 'tool' application?

And why shouldn't I be able to use a local module called
"vector" just because that name is already used in stdlib?
I don't _want_ to have to name it "my_bloody_own_vector" (and
type that name each time I make a call to it).

Or reversely, why should the Erlang/OTP people not be able to
add a module called "array" (for example) to stdlib, just because
some customer already has a module by that name, and does not want
to change their code in order to upgrade to the latest OTP release?

I know that you can get a long way without a package system, but
at the same time, these naming issues have always been annoying me.


> And I did not much like the look of code peppered with the . prefix
> (just a matter of taste).

I absolutely agree: the . prefix notation is not recommended unless you
really need it. Using -import(Module) is much better. Maybe we should
also add a declaration -import_as(Module, Alias).

	/Richard


Richard Carlsson (richardc@REDACTED)   (This space intentionally left blank.)
E-mail: Richard.Carlsson@REDACTED	WWW: http://user.it.uu.se/~richardc/
 "Having users is like optimization: the wise course is to delay it."
   -- Paul Graham