[erlang-questions] newbie: why c.erl is special?

[Anthony Kong]

Hi,

For some testing purpose, I have written some erlang code in a file c.erl.

I can compile the code using erlc alright. But then whenever I start
erl, I got these error:

============================================
$ erl
Erlang (BEAM) emulator version 5.6 [source] [async-threads:0] [hipe]
[kernel-poll:false]

{"init terminating in
do_boot",{undef,[{c,erlangrc,[]},{init,eval_script,7},{init,do_boot,3}]}}

Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
============================================

If I rename c.erl to something else, the problem goes away.

What is special about "-module(c)" ?

Cheers, Anthony

--
/*--*/
Don't EVER make the mistake that you can design something better than
what you get from ruthless massively parallel trial-and-error with a
feedback cycle. That's giving your intelligence _much_ too much
credit.

- Linus Torvalds
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions

[Rory Byrne]

On Sat, Mar 01, 2008 at 09:34:57AM +1100, Anthony Kong wrote:
>
> For some testing purpose, I have written some erlang code in a file c.erl.
>

Unlucky! There's a module called c in stdlib. See here:

http://www.erlang.org/doc/apps/stdlib/index.html

Cheers,

Rory

[Kostis Sagonas]

Anthony Kong wrote:
> Hi,
>
> For some testing purpose, I have written some erlang code in a file c.erl.
>
> I can compile the code using erlc alright. But then whenever I start
> erl, I got these error:
>
> ============================================
> $ erl
> Erlang (BEAM) emulator version 5.6 [source] [async-threads:0] [hipe]
> [kernel-poll:false]
>
> {"init terminating in
> do_boot",{undef,[{c,erlangrc,[]},{init,eval_script,7},{init,do_boot,3}]}}
>
> Crash dump was written to: erl_crash.dump
> init terminating in do_boot ()
> ============================================
>
> If I rename c.erl to something else, the problem goes away.
>
> What is special about "-module(c)" ?

As you can c below, there is already a system module named c:

Erlang (BEAM) emulator version 5.6.2 [source] [async-threads:0] [hipe]
[kernel-poll:false]

Eshell V5.6.2 (abort with ^G)
1> l(c).

=ERROR REPORT==== 1-Mar-2008::00:56:49 ===
Can't load module that resides in sticky dir
{error,sticky_directory}

Kostis

[Matt Stancliff]

On Feb 29, 2008, at 14:34, Anthony Kong wrote:

> If I rename c.erl to something else, the problem goes away.
>
> What is special about "-module(c)" ?

Welcome to the world of flat module namespaces.

The code module is your friend in these circumstances.
Look into code:clash() and code:which(module).

code:which(c) should return "<base path>/lib/erlang/lib/stdlib-
<ver>/ebin/c.beam"

-Matt
--
Matt Stancliff sy...@mindspring.com
AIM: seijimr iPhone: 678-591-9337
"The best way to predict the future is to invent it." --Alan Kay

[shiwei xu]

I think flat module namespaces is a defect of erlang design.

For example, I write a foo.erl, It works well. But maybe in a late erlang version (eg. R13B)  also write such  module named  foo.erl. Then,  you can see  my application goes wrong.

How to avoid things like this? Let's see the following ways:

1. Adjust module searching paths, and let user path (which contains my foo.erl) take precedence over erlang stdlib/otp path. But, this way can't always work well. If some other stdlib/otp modules use system foo.erl (not my foo.erl), Things goes wrong.

2. Write erlang modules always named with a prefix (a fake namespace. For example, projectname_foo.erl or organization_projectname_foo

.erl). This way really can solve the problem. But, It seems ugly.

Is there a way let's user still can call foo:func (not call foo.erl provied by stdlib/otp, but my projectname_foo.erl)? I have a suggestion:

Can erlang provide a 'module name alias'? That is, I can rename a module's name temporarily in a module? For example:

-module(a_module_that_call_my_foo).
-alias(foo, organization_projectname_foo). %% alias

some_func_call_foo() ->
    foo:func().  %% same as: organization_projectname_foo:func()

Currently I can do this by using the 'define' keyword. For example:

-module(a_module_that_call_my_foo).
-define(FOO, organization_projectname_foo). %% alias

some_func_call_foo() ->
    ?FOO:func().

It works well, but a bit ugly.

[Thomas Lindgren]

--- shiwei xu <xushi...@gmail.com> wrote:

> I think flat module namespaces is a defect of erlang
> design.

Richard Carlsson proposed java-like packages some
years ago, and the code for them might still be
provided in OTP. (I thought they had some flaws, but
they might be what you want.)

http://citeseer.ist.psu.edu/398052.html

The usual approach to handling name clashes without
packages is to use your 'approach 2', prefixing the
modules with their owner application.

Best,
Thomas

____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[Bengt Kleberg]

Greetings,

In the book "Object Oriented Software Construction" Bertrand Meyer
argues (successfully in my opinion) that you need to have the ability to
rename (alias) modules. He also shows that this ability must be outside
of the language/modules themselves.

Otherwise you are just hoping that your code will never be successfully
shared by many people.

bengt

[Christian S]

On Mon, Mar 3, 2008 at 8:53 AM, Bengt Kleberg
<bengt....@ericsson.com> wrote:
> In the book "Object Oriented Software Construction" Bertrand Meyer
> argues (successfully in my opinion) that you need to have the ability to
> rename (alias) modules. He also shows that this ability must be outside
> of the language/modules themselves.

Providing my own aliases for other modules that I use is something I
have been wishing for.

Not having read the book, what does he mean with the ability must be
outside of the language?

[Bengt Kleberg]

Greetings,

Sorry about the delay, but the book has > 1000 pages and it was
unfortunately a worst case search scenario. The explanation was not in
the book.

It was here:
http://se.inf.ethz.ch/projects/alan_fehr/report.pdf

And the part you want to read is "1.2.2 LACE" on page 2. It is only 6
lines, but I can not cut/paste so I hope you can read it.

bengt

[Anthony Kong]

Is it already implemented? Because I found this document:

http://www.erlang.se/publications/packages.html

Anyway, I was unable to get it to work according to this info.

Cheers, Anthony

--

/*--*/
Don't EVER make the mistake that you can design something better than
what you get from ruthless massively parallel trial-and-error with a
feedback cycle. That's giving your intelligence _much_ too much
credit.

- Linus Torvalds

[Anthony Kong]

I think it is the 'six-liner' you are referring to:

"1.2.2 LACE
One of the ideas behind Eiffel is to maximize reusability. For this
reason, the language doesn't
provide a mechanism for assembling a system. Some external mechanism
is therefore needed
to specify the entry-point for a program. One of these mechanisms is a
language called LACE
(Language for Assembling Classes in Eiffel).
Since the Eiffel knows nothing of assembling classes into systems it
doesn't provide a
mechanism for resolving name-clashes."

In a sense, it sounds like java classloader to me.

Cheers, Anthony

--

/*--*/
Don't EVER make the mistake that you can design something better than
what you get from ruthless massively parallel trial-and-error with a
feedback cycle. That's giving your intelligence _much_ too much
credit.

- Linus Torvalds

[Anthony Kong]

Sorry for the false alarm. It
(http://www.erlang.se/publications/packages.html) actually works.

Let's say I have this module is "a.b.c.d", defined in d.erl which
lives in directory, a/b/c,

What I need to make sure is that: when I use erlc to compile this
d.erl, I have to specify the -o flag in order to produce the d.beam in
the directory a/b/c.

Attached is my simple test setup script, which probably can explain
the above better.

Cheers, Anthony

[Richard Carlsson]

It was implemented a long time ago, but there was not a lot of
community enthusiasm for it, so it's not been made an official
part of the language yet. Still, it should work also in R12.

http://www.erlang.org/doc/man/packages.html

It was originally inspired by/ripped off from Java, but in
practice it's more similar to Lisp namespaces; see "The Complete
Idiot’s Guide to Common Lisp Packages" for details:
http://www.flownet.com/ron/packages.pdf

/Richard

Anthony Kong wrote:
> Is it already implemented? Because I found this document:
>
> http://www.erlang.se/publications/packages.html
>
> Anyway, I was unable to get it to work according to this info.
>
> Cheers, Anthony
>
> On Sun, Mar 2, 2008 at 12:38 AM, Thomas Lindgren
> <thomasl...@yahoo.com> wrote:
>> --- shiwei xu <xushi...@gmail.com> wrote:
>>
>> > I think flat module namespaces is a defect of erlang
>> > design.
>>
>> Richard Carlsson proposed java-like packages some
>> years ago, and the code for them might still be
>> provided in OTP. (I thought they had some flaws, but
>> they might be what you want.)
>>
>> http://citeseer.ist.psu.edu/398052.html
>>
>> The usual approach to handling name clashes without
>> packages is to use your 'approach 2', prefixing the
>> modules with their owner application.
>>
>> Best,
>> Thomas

[Anthony Kong]

Thanks, Richard,

Sorry again for the false alarm.

I think this "a.b.c.d" notation is a good idea. For once it allows us
to structure the source code tree better.

The catch are the erlc flag (which I just realised) and mandatory
explicit import of other top level modules such as io and lists.

Cheers, Anthony

--

/*--*/
Don't EVER make the mistake that you can design something better than
what you get from ruthless massively parallel trial-and-error with a
feedback cycle. That's giving your intelligence _much_ too much
credit.

- Linus Torvalds

[Anthony Kong]

Hi, Shiwei,

I'd concur that a capability to alias an imported module sounds like
an attractive idea.

I personally would prefer a new directive called "import_as".

======
-module(lists). %% I want to call my module lists too.
-import_as(lists, stdlib_lists).

...
lists:copycat() ->
stdlib_lists:reverse([a,b,c]). %% essentially calling lists:reverse([a,b,c])

======

Just the same as your idea of "-alias".

Until then, I probably have to learn to live in this namespace flatland :-)

Cheers, Anthony

2008/3/1 shiwei xu <xushi...@gmail.com>:

--

/*--*/
Don't EVER make the mistake that you can design something better than
what you get from ruthless massively parallel trial-and-error with a
feedback cycle. That's giving your intelligence _much_ too much
credit.

- Linus Torvalds

[Richard Carlsson]

Anthony Kong wrote:
> I personally would prefer a new directive called "import_as".
>
> ======
> -module(lists). %% I want to call my module lists too.
> -import_as(lists, stdlib_lists).
>
> ...
> lists:copycat() ->
> stdlib_lists:reverse([a,b,c]). %% essentially calling lists:reverse([a,b,c])

I planned to implement exactly this, but never got around to it.
I'll fix it if I can find some spare time.

/Richard

[Christian S]

On Wed, Mar 5, 2008 at 12:29 PM, Richard Carlsson <rich...@it.uu.se> wrote:
> I planned to implement exactly this, but never got around to it.
> I'll fix it if I can find some spare time.

A problem with aliases is that the expectation is that an atom will
identify the same module even when it crosses boundaries into code
from other modules.

Scenario:

I define a behaviour for creating/looking up cookie sessions in a
webserver. (With the intention that one could back end it in files,
mnesia or a sql rdbm.)

I tell the webserver to use the module stupidly identified by the name
'session' that implements this behaviour.

The webserver has a -import_as/-alias where 'session' is an alias for
a module that is not the same as my module.

...problems! Or at least confusion.

As I see it, there needs to be a first-class module-type to get around
it. A resolved module. Something that is not an atom.

"Module = module(session)" the same way there is "Fun = fun M:F/A"
(rather than the old {M,F} wart).

The value of module(Atom) would globally identify the module locally
known by the name in Atom.

Or is there some more clever way to get around the problems in
module-local aliases?

PS.
I think this name-space-discussion has occurred two-three times the
years I have been following the list.

[Thomas Lindgren]

--- Anthony Kong <anthony...@gmail.com> wrote:

> Is it already implemented? Because I found this
> document:
>
> http://www.erlang.se/publications/packages.html
>
> Anyway, I was unable to get it to work according to
> this info.

Sorry, I haven't tracked how this has evolved. Maybe
Richard knows more?

Best,
Thomas

____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

[Bengt Kleberg]

Greetings,

How does the erlang run time handle 2 modules called lists?

Which lists module will those other modules that have not done
-import_as(lists, stdlib_lists).
get?

bengt

[Richard Carlsson]

The compiler expands all module references to their fully qualified forms,
so at runtime, there is no aliasing problem.

The one thing programmers have to think about, is that if you pass "just
some atom" as an argument to some function, the compiler will not expand
that atom, so if you are giving the name of a module (e.g., as a callback),
you need to make sure to use the fully qualified form.

So yes, there is an assymetry: module names used in explicit calls are
expanded, but "plain atoms" are not. On the positive side: it's a rather
simple approach that works pretty well and is fully compatible with
existing code without adding new datatypes to the language.

But since parameterized modules (which came later) require adding a
first-class module data type (currently implemented as tuples), all the
code which currently assumes (and checks) that module callbacks are atoms
would need to be rewritten in any case, so encoding the namespace structure
in the (full) module names is not the only way.

But personally, I think I actually like the package system as it is. It is
straightforward and works, and does not add *too* much cruft to the
language. I know that some people consider it "inside out", but i think
it's an advantage to have each module clearly state its full name. That
provides stability and enables you to build a vocabulary of modules you
know, and you don't have to look in another file to find out what the
name used to access the module in the current file is supposed to be.

Sure, you can define a whole sub-language for specifying how modules
are composed out of other modules and how this module in that file over
there is actually called Brian who is known as Brian, but there is a
thing such as too much flexibility getting in the way of getting things
done. On the other hand, I loathe long module names such as
'megaco_per_bin_media_gateway_control_v2' (or nasty surprises for newbies,
such as 'c') , so some namespace control is definitely needed.

/Richard

[Richard Carlsson]

Just to hammer down the point: the runtime system never sees
two different modules called lists. The import_as would cause
the names to be substituted at compile time. Atoms that are
not necessarily module names by context would either have to
be written fully qualified from start, or be wrapped in some
construct that marks them for expansion, such as:

-import_as(foo, my_foo)
...
f() ->
gen_server:start(i_am_a_module_name(foo), ...)

(It would actually be a very good thing if all atoms that in
fact are used to name modules, would be marked up as such, in
one way or another. Dialyzer and other analyses would be much
helped by this. Currently, Erlang programs are way too liberally
sprinkled with random atoms which turn out to be a module name.)

The basic point is: you never pass an atom that represents a
module name to anyone else unless it is already fully qualified.

/Richard

[Daniel Luna]

On Wed, 5 Mar 2008, Bengt Kleberg wrote:
> Greetings,
>
> How does the erlang run time handle 2 modules called lists?
>
> Which lists module will those other modules that have not done
> -import_as(lists, stdlib_lists).
> get?

Even more interesting: What will happen if you have two (or three...)
modules all doing the below magic?

What module will you really call when you do lists:reverse/1?

(Or even worse; what module will you call when you do Mod:reverse(List)
inside one of these modules? (Mod was an argument coming from outside the
module))

Etc...

/Luna

--
Daniel Luna | Top reasons that I have a beard:
lu...@update.uu.se | a) Laziness.
http://www.update.uu.se/~luna/ | b) I can.
Don't look at my homepage (it stinks).| c) I can get away with it.

[David Mercer]

What am I missing from the description of Erlang packages that does not do
what everyone wants: namely, namespaces? I would think if I want to create
all my modules under my own "mercer" namespace, I'd just put them in a
directory called "mercer" and then name my modules "mercer.M" (where M is
the module name.

If this is what everyone seems to want, why hasn't the package notation
caught on?

Cheers,

David Mercer

[Vance Shipley]

On Wed, Mar 05, 2008 at 12:21:30PM -0600, David Mercer wrote:
} If this is what everyone seems to want, why hasn't the package notation
} caught on?

A very good question. There have been very few user contributions
written with packages. Package support is not official yet either.
So we seem to have a chicken and egg situation. If it were supported
folks would adopt it. If folks adopted it it would get supported.

There were arguments against the concept however. I'll leave it
to the CS types to argue that one. I found packages really useful
to handle authentication plugins in a project I did several years ago.

-Vance

[Hal Snyder]

IIRC there was a problem with systools, building .boot and .script
with packages in the picture. That was a few years ago, not sure what
the situation is now.

[Richard A. O'Keefe]

> On Wed, Mar 05, 2008 at 12:21:30PM -0600, David Mercer wrote:
> } If this is what everyone seems to want, why hasn't the package
> notation
> } caught on?
>

But *is* it what everyone wants?
I have argued at some length that the whole thing is back to front,
inside out,
and even upside down. I believe that you should be able to
- move an entire group of closely related modules around in the
module universe
by changing one line in one place
- incorporate (the façade of) a cluster of modules
by writing one line in one place
- be able to retrospectively bundle up a cluster of related modules
without touching their source code
- be able to have two versions of a cluster at the same time
without modifying their source code
and a whole lot of things like that, which the Java-envious dotted
names just
make harder, and I have proposed a LACE-like means of accomplishing
this.

Not the least of the problems is that Java-envious dotted package
names aren't
really hierarchical; they are just flat strings with funny spelling.

[Lövei László]

Richard A. O'Keefe wrote:
>> On Wed, Mar 05, 2008 at 12:21:30PM -0600, David Mercer wrote:
>> } If this is what everyone seems to want, why hasn't the package
>> notation
>> } caught on?
>>
> But *is* it what everyone wants?

It seems to me (after reading the list archive) that everyone wants
this, only some people want even more. But this notation is here, and it
works, only some encouragement is missing for it to become widespread
(like mentioning it in the reference manual and the tutorial).

Personally I would very much like it to be an officially supported
feature (with related bugs fixed). Maybe that would make way for later
enhancements too.

Laszlo

[Bengt Kleberg]

Greetings,

While I do not know what everybody wants I have a question about the
lack of hierarchy in the existing (unsupported) erlang dotted package
name.
Given a module a.b.c and another module a.b.d, is it not possible to say
d:fun() in a.b.c and get a.b.d:fun()? If the system is flat strings I
would expect to have to write a.b.d:fun() in a.b.c.

Even so I would still like to have a LACE like system for erlang. It
would be able to handle more situations with less work for me.

bengt

[Sean Hinde]

On 6 Mar 2008, at 09:59, Lövei László wrote:
>
> It seems to me (after reading the list archive) that everyone wants
> this, only some people want even more. But this notation is here,
> and it
> works, only some encouragement is missing for it to become widespread
> (like mentioning it in the reference manual and the tutorial).

Read again. Some people (myself included) thought it was an ugly wart
solving a problem that only a few newbies stumble across and making
erlang code harder to read and maintain.

One of the worst aspects of this would be the endless traversing up
and down interminable directory hierarchies. Soon we would need a full
IDE just to help us find the definition of a module in the filesystem.

Sean

[Bengt Kleberg]

Greetings,

I would like to be hammered a little bit more, please. Since it sounds
difficult to handle at compile time I would like to ask how this will
work. We have the following:
stdlib-0/ebin/lists.beam
a/ebin/lists.beam
b/ebin/b.beam

Erlang is started and lists.beam from directory a is loaded. Then b.beam
is loaded.
b contains a call to lists:reverse/1.
Will b get lists from a or stdlib-0/ebin ?

I know which lists b want, but how does the erlang run time know?

bengt

[Steve Vinoski]

On 3/6/08, Sean Hinde <sean....@gmail.com> wrote:
> One of the worst aspects of this would be the endless traversing up
> and down interminable directory hierarchies. Soon we would need a full
> IDE just to help us find the definition of a module in the filesystem.

YES! I was about to point out the same thing, and I'm very glad to
know I'm not alone in my thinking. Java's abuse of the filesystem in
this manner is very annoying, for example, and pushing Erlang to that
model would be a huge mistake IMO.

--steve

[Richard A. O'Keefe]

On 6 Mar 2008, at 9:59 pm, Lövei László wrote:

> Richard A. O'Keefe wrote:
>>> On Wed, Mar 05, 2008 at 12:21:30PM -0600, David Mercer wrote:
>>> } If this is what everyone seems to want, why hasn't the package
>>> notation
>>> } caught on?
>>>
>> But *is* it what everyone wants?
>
> It seems to me (after reading the list archive) that everyone wants

> this, only some people want even more.\

Let me offer an analogy:
people want yummy food.
they are offered seafloor ooze (which some organisms flourish on).
I complain that I want real human food.
It is suggested that people really want seafloor ooze, but some
people want more.

I say that the dotted package names not only don't solve most of our
problems,
they entrench problematic practice (package prefix = directory) and
would make
it much harder to provide a good solution later.

In the mean time, life could get a lot simpler for people if they
realised that .erl files
don't have to be the very beginning of the build process (hint hint).

[Brian Cully]

On 6-Mar-2008, at 17:03, Richard A. O'Keefe wrote:
> In the mean time, life could get a lot simpler for people if they
> realised that .erl files
> don't have to be the very beginning of the build process (hint hint).

Don't get me wrong: I hate package.names being tied to directories as
well, and the idea of having to type foo.bar.baz:quux() every time i
ref an external package would drive me up a wall. I /also/ like the
M:F(A) style of external function call for code understandability, so
"import" is not an ideal solution. Hell, I wish there wasn't an
"import" directive at all, but that's for another day.

However the only solution I can think of that's worse than that is
one which destroys my ability to type C-c C-k in Emacs and do
something useful. To that extent, any solution should probably be
contained in the .erl itself, or on the outside a single-use bootstrap
for loading a system (akin to asdf from CL land).

I'm actually reasonably happy w/ the current system. It strikes a
good balance between readability (M:F(A)) and writability (flat
namespace).

-bjc

[Robert Virding]

On 06/03/2008, Steve Vinoski <vin...@ieee.org> wrote:

On 3/6/08, Sean Hinde <sean....@gmail.com> wrote:
>  One of the worst aspects of this would be the endless traversing up
>  and down interminable directory hierarchies. Soon we would need a full
>  IDE just to help us find the definition of a module in the filesystem.


YES! I was about to point out the same thing, and I'm very glad to
know I'm not alone in my thinking. Java's abuse of the filesystem in
this manner is very annoying, for example, and pushing Erlang to that
model would be a huge mistake IMO.

One of our original goals, which is seldom mentioned today, was that we wanted to keep the language *simple*! Then many programmers in Ericsson, who were out potential users, were not very experienced and not well trained in the art/science of programming. This is one reason why features considered standard were added later. This may not have been a good design decision but it did result in a small simple base language. I have read on the net discussions about designing languages for the masses, or not.

And, whatever its warts, a flat module system is easy to comprehend. If you call module foo there is only one module foo to which it can refer, irrespective of from where it is called. And you can always use naming conventions to handle the case of many modules in an application or sub-system.

Robert

[Richard A. O'Keefe]

1. Given that the module for lists is called 'lists', not 'list',
it is rather confusing that the module for binaries is called
'binary',
instead of the expected 'binaries'.

On the other hand, given that the module for strings is called
"string",
maybe it's 'lists' that has the wrong name. Something needs to
be done
about naming consistency in modules for data types.

2. What do you return if you look for something and it isn't there?
For some reason, people seem to like returning an out-of-range
index
at the wrong end. BASIC does this, Smalltalk does it, but that
does not
make it right. Life gets *so* much simpler if match(Haystack,
Needle)
returns an index past the *right* end of the haystack. Suppose,
for
example, we have input with an optional comment; we want to
remove it.
[Mind you, EEP 9 is handicapped by starting from a system where
binary slicing uses just about the worst possible convention,
but that is
another and sadder story.]
[Oh yes, the documentation for the erlang: module gets
erlang:split_bionary/2
wrong. It says that the range for Pos is 1..size(Bin), but 0 is
*rightly*
allowed. Pos is actually the size of the first part, which is
just right.]

Example. Suppose we are given a line of text from some
configuration file
as a binary. It might contain a # comment or it might not. Our
only interest is
in getting rid of it. In a rational design, where
match(Haystack, Needle)
returns the length of the longest prefix of Haystack *not*
containing Needle,
we just do
{Wanted,_} = split_binary(Given, match(Given, <<"#">>))
With the scheme actually proposed, we have to do
case match(Given, <<"#">>)
of 0 -> Wanted = Given
; N -> {Wanted,_} = split_binary(Given, N-1)
end

3. I appreciate that slicing binaries is supposed to be cheap, but I
still
think it would be nice if match had a 3rd argument, saying how
many bytes
at the beginning of Haystack to skip. If it weren't 4pm on a
Friday with
my office floor still to tidy up, I could give examples of why
this can
make life simpler.

4. I agree that the proposed binary:split/2 function is useful, but
the name
is far too close to split_binary/2 for comfort. A longer name
such as
binaries:split_with_separator(Binary, Separator_Binary)
might make for less confusion. Better still, why not make this
like
string:tokens/2, which really has exactly the same purpose except
for the
data type it applies to?

5. Ever since I met SNOBOL 4, I have known the operation of removing
outer
blanks from a string as trimmming. It's a little odd to find it
called
stripping. By analogy with ecdysiasis (hem hem) I would expect
stripping
to remove visible outer stuff. I wish string:strip/[1,2,3] could
be
renamed.

6. In the functions
unsigned_to_bin/1
bin_to_unsigned/1
why is the word "binary" abbreviated to "bin"?

7. "nth" is a very strange name for a substring operation.
I would prefer
subbinary(Binary, Offset[, Length])
0 =< Offset =< byte_size(Binary)
0 =< Length =< byte_size(Binary) - Offset
which would make this compatible with the existing
split_binary(Binary, Offset)
function.

While I have been picky about some of the details, it seems to me
that this is a good beginning in a good direction.

[David Mercer]

Maybe we should name all our modules with a GUID.  That would reduce the likelihood of module name clashes down close to zero.

 

J

 

Cheers,

 

DBM

 

---

From: erlang-quest...@erlang.org [mailto:erlang-quest...@erlang.org] On Behalf Of Robert Virding

Sent: Thursday, March 06, 2008 17:57
To: Steve Vinoski
Cc: erlang-questions

[David Mercer]

You know, I sent this in jest, but now that I think about it, it’s not such a bad idea.  You can define a macro giving a better name for the module so you don’t have to keep using the GUID.  Howzat?

 

-define(stringlib, 'a613fd8b-647c-4b1a-9f4c-810f0b99993a')

. . .

?stringlib:reverse(…)

 

DBM

 

---

From: David Mercer [mailto:dme...@gmail.com]
Sent: Friday, March 07, 2008 11:09
To: 'erlang-questions'
Subject: RE: [erlang-questions] packages (was: newbie: why c.erl is special?)

 

Maybe we should name all our modules with a GUID.  That would reduce the likelihood of module name clashes down close to zero.

 

J

 

Cheers,

 

DBM

 

---

From: erlang-quest...@erlang.org [mailto:erlang-quest...@erlang.org] On Behalf Of Robert Virding

Sent: Thursday, March 06, 2008 17:57
To: Steve Vinoski

Cc: erlang-questions
Subject: Re: [erlang-questions] packages (was: newbie: why c.erl is special?)

 

On 06/03/2008, Steve Vinoski <vin...@ieee.org> wrote:

[Thomas Lindgren]

--- David Mercer <dme...@gmail.com> wrote:

> You know, I sent this in jest, but now that I think
> about it, it's not such
> a bad idea. You can define a macro giving a better
> name for the module so
> you don't have to keep using the GUID. Howzat?
>
>
>
> -define(stringlib,
> 'a613fd8b-647c-4b1a-9f4c-810f0b99993a')
>
> . . .
>

> ?stringlib:reverse(.)

For what it's worth, I tend to use ?mod:f(X) when I'm
trying out multiple implementations of some facility.
A poor man's parametrized modules, in way.

When I wrote a cross-module optimizer (EUC'01), I used
a variant of the above GUID technique for renaming
_records_, which got rid of a big practical problem:
record name clashes.

Adding the hash of the code to your beam file is
probably a good principle too.

So I'm basically with you :-)

Best,
Thomas

____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[Jim McCoy]

On Thu, Mar 6, 2008 at 7:32 PM, Richard A. O'Keefe <o...@cs.otago.ac.nz> wrote:

> 5. Ever since I met SNOBOL 4, I have known the operation of removing
> outer
> blanks from a string as trimmming. It's a little odd to find it
> called
> stripping.

Perl probably started this particular terminology shift, and Python
and Ruby finished the job. Sorry, but arguing this one is a lost
cause...

jim

[Fredrik Svahn]

Thanks for looking at the EEP. Please see comments below:

On Fri, Mar 7, 2008 at 4:32 AM, Richard A. O'Keefe <o...@cs.otago.ac.nz> wrote:
> 1. Given that the module for lists is called 'lists', not 'list',
> it is rather confusing that the module for binaries is called
> 'binary',
> instead of the expected 'binaries'.
>
> On the other hand, given that the module for strings is called
> "string",
> maybe it's 'lists' that has the wrong name. Something needs to
> be done
> about naming consistency in modules for data types.

I have noted the same thing and decided to make it like string, queue
and array rather than like lists or sets. Binary/binary_string has the
added advantage of also being slightly shorter than
binaries/binary_strings.

There are already two different return values in two different library
modules for the "not found scenario".

regexp:match/2 -> nomatch
string:[r]str/2 -> 0
string:[r]chr/2 -> 0

I am afraid that adding a third way of marking "not found" in a third
library is only going to add to the confusion.

> 3. I appreciate that slicing binaries is supposed to be cheap, but I
> still
> think it would be nice if match had a 3rd argument, saying how
> many bytes
> at the beginning of Haystack to skip. If it weren't 4pm on a
> Friday with
> my office floor still to tidy up, I could give examples of why
> this can
> make life simpler.

I am not sure I understand. There is already a match function in the
EEP where you can specify where to start the matching.

<eep>
match(Haystack, Needles, {StartIndex, EndIndex}) -> Return
</eep>

> 4. I agree that the proposed binary:split/2 function is useful, but
> the name
> is far too close to split_binary/2 for comfort. A longer name
> such as
> binaries:split_with_separator(Binary, Separator_Binary)
> might make for less confusion. Better still, why not make this
> like
> string:tokens/2, which really has exactly the same purpose except
> for the
> data type it applies to?

The proposed split function is actually more like regexp:split/2 than
string:tokens/2. As you know string:tokens/2 takes a list of separator
chars and splits by any of the chars, which I usually find is *not*
what I want it to do. Thus naming it tokens will give the wrong
associations since it is already implemented in another way in the
string library.

string:tokens("cat and dog", "and").
["c","t "," ","og"]
regexp:split("cat and dog", "and").
{ok,["cat "," dog"]}

Then again as the function is specified you could mimic the behaviour
of tokens by giving binary:split/2 a list of binaries [<<"a">>,
<<"n">>, <<"d">>], although you would end up with some empty binaries
as well, just like you have the empty lists in regexp:split():
2> regexp:split("cat and dog","a|n|d").
{ok,["c","t ",[],[]," ","og"]}

Maybe split_with/2 or split_by/2 to keep it reasonable short?

> 5. Ever since I met SNOBOL 4, I have known the operation of removing
> outer
> blanks from a string as trimmming. It's a little odd to find it
> called
> stripping. By analogy with ecdysiasis (hem hem) I would expect
> stripping
> to remove visible outer stuff. I wish string:strip/[1,2,3] could
> be
> renamed.

This is analogous to string:strip/1. While I agree trim is a better
name I think that calling it trim in one library and strip in another
will only add confusion and strange questions to erlang-questions in
the future.

>
> 6. In the functions
> unsigned_to_bin/1
> bin_to_unsigned/1
> why is the word "binary" abbreviated to "bin"?

Agreed. I will change bin to binary.

> 7. "nth" is a very strange name for a substring operation.
> I would prefer
> subbinary(Binary, Offset[, Length])
> 0 =< Offset =< byte_size(Binary)
> 0 =< Length =< byte_size(Binary) - Offset
> which would make this compatible with the existing
> split_binary(Binary, Offset)
> function.

Agreed, I was not pleased with the name myself. It is a leftover from
the first version where it picked out one byte at the nth position
(similar to lists:nth/2 operating on a string). I am planning (as per
the suggestions here on the mailing list) to split the module into
two, where one should be called binary_string or similar. In that
module it should be named and behave like string:sub_string/2,3.

BR /Fredrik

[Jay Nelson]

> > 7. "nth" is a very strange name for a substring operation.
> > I would prefer
> > subbinary(Binary, Offset[, Length])
> > 0 =< Offset =< byte_size(Binary)
> > 0 =< Length =< byte_size(Binary) - Offset
> > which would make this compatible with the existing
> > split_binary(Binary, Offset)
> > function.

> Agreed, I was not pleased with the name myself. It is a leftover from
> the first version where it picked out one byte at the nth position
> (similar to lists:nth/2 operating on a string). I am planning (as per
> the suggestions here on the mailing list) to split the module into
> two, where one should be called binary_string or similar. In that
> module it should be named and behave like string:sub_string/2,3.

Be careful in choosing the name for the function which extracts a
subsequence from a binary. There is already a concept in erlang of a
'subbinary' (not sure if there is a dash or underscore but I think
the docs and code refer to it all jammed together as one word), which
specifically represents a minimal structure which points into another
binary (or subbinary) so that there is no copying of contiguous
elements to create a new binary.

Whatever nomenclature is chosen, the semantics of subbinary should be
preserved (possibly even to the point of having a separate module
called subbinary which guarantees to operate on them in an efficient
manner and identifies explicitly when a binary is returned and when a
subbinary is returned).

So, I am proposing that if a function such as binary:subbinary/2,3 is
provided, it be documented and guaranteed that it doesn't copy the
binary elements in constructing a result. If a new binary with copy
semantics is the desired result, a different function name (for
example, binary:copy_slice/2,3 or binary:copy_subseq/2,3) be provided.

Likewise binary_string:subbinary/2,3 would not copy, while
binary_string:sub_string/2,3 would.

I'm not sure if the distinction of copying is necessary by having two
sets of functions, or whether a binary:copy_binary/1 function could
do the dirty work when needed, thereby only requiring all subseq
operations to return a real 'subbinary' and the user explicitly
copying when desired. In general, this approach would be the best I
think by keeping the module signature to a minimal set of function.

------

A scenario I currently use is to read a text file as a single binary,
scan it to create a list of subbinaries (for example, of all the
configuration terms and values), then filter for some subset of the
list which I want to continue using. I then would like to discard
the large binary and all the unused binaries. It is almost an
explicit garbage collect on one structure using application specific
knowledge.

A BIF should be provided which guarantees the return of a deep list
of fresh copies of the binaries passed to it in a deep list:

binary:copy_binaries(DeepListOfBinaries)

The application code would be something like this:

get_config_params() ->
BigBin = load_binary(...),
ParsedBins = parse_binary(BigBin),
Keepers = filter_config_params(ParsedBins),
FreshBins = binary:copy_binaries(Keepers).

On return, the references to BigBin and all subbinaries parsed out
are dropped, so only the FreshBins will be kept on the next garbage
collection sweep. The key is to guarantee all references to BigBin
are eliminated by copying the subbinaries to fresh memory.

jay

[Dominic Williams]

> If this is what everyone seems to want, why hasn't the package
> notation caught on?

The package notation is not what everyone wants.

> It seems to me (after reading the list archive) that everyone
> wants this, only some people want even more.

No, some people (myself included) have repeatedly argued that
packages are fundamentally wrong. We want something completely
different, not just better packages. Even having nothing would
be better than having packages.

In addition to recent posts from Richard O'Keefe and others, I
would like to point out two other fundamental flaws with
packages:

1) Packages don't actually prevent name clashes: they only reduce
the probability of a name clash. Accepting this, as a language
feature, would be like accepting that Pid ! Msg sends Msg to Pid,
but only most of the time.

2) Packages reduce referential transparency, and by way of
consequence, make it harder to move code around or experiment
with it in the shell.

I elaborated on this and other flaws here:

http://www.erlang.org/pipermail/erlang-questions/2006-November/023768.html

In addition to the Eiffel-inspired solution described there,
Richard O'Keefe outlined an even more elegant solution here:

http://www.erlang.org/pipermail/erlang-questions/2006-November/023879.html

Regards,

Dominic Williams
http://dominicwilliams.net

----