[erlang-questions] Time to update programming rules?
Richard A. O'Keefe
Mon Sep 8 04:21:16 CEST 2008
On 5 Sep 2008, at 4:10 pm, Benjamin Tolputt wrote:
> I understand the possibility of errors. Possibility of error is a
> point, but one that can (and has) been made about other parts of the
> Erlang system.
That's pretty much of a straw man position.
It's not a question of a mere *possibility* of errors,
but of a "feature" that makes errors *especially* likely,
and which offers no compensating advantages.
> As I understand it then, this is an "opinion" exclusion
> of use rather than one endorsed by the developers of Erlang (given
> implemented it and have yet to remove it from the system).
The developers of Erlang have so far refrained from announcing
dotted module names as a permanent feature of the language.
There was a lot of discussion back in 2003 and it does not appear
that the dotted names "feature" has been significantly revised since
to address any of the issues that were seen five years ago.
> The "extra" functionality it offers is that the beams are split out
> nicely such that "xyz.abc.mymod" is compiled to a "mymod.beam" file
> will not conflict with a "abc.def.mymod" module.
Actually, no. There never ever was anything whatsoever in Erlang
to stop you writing module names like 'a.b.c' and thereby having
the beam file placed as 'a.b.c.beam', which quite naturally never
did conflict with an 'e.f.c.beam' file or 'e.f.c' module.
Allowing you to write dotted names without quotation marks is no
big deal either: we ALWAYS had the ability to write module names
with @ signs in them.
> This (in my mind) is a Good Thing.
I am not saying one word against the idea of compound names.
(Although I note that the compound name features originally
present in SETL and ZetaLisp were dropped in SETL2 and
Common Lisp. It would be very interesting to know why.)
I am, as it happens, a big fan of 'child modules' in Ada,
but unlike Java, Ada does child modules *well*.
> Like Java, the multi-folder thing is likely to be a moot
> issue given a decent IDE. One that I have admittedly not yet found for
> Erlang - beyond a good text editor (ScITE) and the Erlang shell.
You should not need a Gargantuan cycle-hogging "IDE" to paper over
mistakes in a design. Have you studied Meyer's LACE at all?
The mapping of module names to file names, whether simple or
compounds, is inherently problematic in Haskell (which does it)
and Erlang (which does it) and Prolog (which does it), in that
names (including module names) are case sensitive in those languages,
but in certain popular operating systems file names are not.
Off hand I can think of four "POSIX-compatible" file systems that
do not distinguish alphabetic case, so
might, or might not, be distinguishable in BEAM file names.
Then too, there are characters that can be present in an Erlang
module name (like 'date/time mgmt') that are not allowed in a
file name (Unix or Windows).
"if you insist on mapping Erlang module names directly to file names,
NOBODY CAN EVER KNOW WHAT THE SET OF PORTABLE ERLANG MODULE NAMES IS!
Nobody can even know how long an Erlang module name may be:
is the limit 8 or 10 or 27 or 251 or what?"
Aside from the mapping to file names, the only genuinely new
thing that the "packages" "feature" for Erlang gives you is
the ability to have more than one name for the same module,
and to use the wrong one in a context where it matters.
We can, and should, do MUCH MUCH better.
For example, if a module is going to be referred to elsewhere as
a.b.c, and if we compile a module M by invoking "erlc M.erl",
then erlc a.b.c.erl should work. (It doesn't.) Certainly if a
module announces itself as "-module(a.b.c)" then compiling it
should not produce a simple c.beam. (It does.)
> Auto Generated Mail Footer
> If this email is requesting your password then it is a HOAX.
> DO NOT reply to the email.
> Validate this footer at the
> Otago University web site keyword search: information security phish
If stupidity were a crime, who'd 'scape hanging?
More information about the erlang-questions