Wow, a flurry of response.  It sounds like there's a lot of interest in this topic.  However, I haven't heard any clear consensus on what action to take as a result.

Thus rather than worrying about the details (library X should be put in module Y), can I get a "sense of the senate" on the following two proposals:


1) Eliminate all reference to "Phobos" in favor of its "formal name". (Let's not debate *what* that name is quite yet; let's just figure out if there's consensus that the name should change at all.)

2) Add something like the following passage to the <formal name> Philosphy section:

"No special-purpose modules.  Don't add modules to the <formal name> package that accomplish specific, high-level functions.  Rather, <formal name> is reserved for modules that provide universal, low-level functionality that almost all applications require, irrespective of problem domain.  <formal name> modules are supported with a priority equal to the compiler itself. The namespace is big.  Use it."


Again, there's plenty of time to worry about the details of which should go where and what precisely it's called.  And there are plenty more proposals to debate than just these two.  But let's try to focus on these two big decisions before getting tangled up in the little ones (or the other big ones).

-david

PS: I didn't hear Walter weigh in.  Given that his vote is equal  to or greater than the sum of all other votes, I'd be interested in his opinion.

On Mon, 28 Mar 2005 15:12:58 -0800, David Barrett wrote:

> Wow, a flurry of response.  It sounds like there's a lot of interest in this topic.  However, I haven't heard any clear consensus on what action to take as a result.
> 
> Thus rather than worrying about the details (library X should be put in module Y), can I get a "sense of the senate" on the following two proposals:
> 
> 
> 1) Eliminate all reference to "Phobos" in favor of its "formal name". (Let's not debate *what* that name is quite yet; let's just figure out if there's consensus that the name should change at all.)

I have no objections to the name "Phobos". To me, that *is* the formal name for the D standard library.

> 2) Add something like the following passage to the <formal name> Philosphy section:
> 
> "No special-purpose modules.  Don't add modules to the <formal name> package that accomplish specific, high-level functions.  Rather, <formal name> is reserved for modules that provide universal, low-level functionality that almost all applications require, irrespective of problem domain.  <formal name> modules are supported with a priority equal to the compiler itself. The namespace is big.  Use it."
> 

I think the terms "high-level", and "low-level" need to be removed from passage. Mainly because different people have different ideas about which is which, and what falls into either. In short, they are subjective, relative, terms and we need more absolutism for a definition of what the library ought to contain. Also, emphasize what it should contain rather than what it should omit. Is there a need to state that all implementation of D must support all the standard library?

"<formal name> is reserved for modules that provide functionality that the majority of applications are likely to require, irrespective of problem domain. <formal name> modules are supported with a priority equal to the compiler itself, and must be implemented by all D compiler implementations. Modules that accomplish specific functionality, that are not likely to be required by the majority of application, must be placed in other namespaces."

-- 
Derek Parnell
Melbourne, Australia
29/03/2005 9:24:50 AM

David Barrett wrote:
> Wow, a flurry of response.  It sounds like there's a lot of interest in this topic.  However, I haven't heard any clear consensus on what action to take as a result.

There was a flurry of response the last time these issues were brought up (when the Phobos-alternative project was launched). And not much resulted from it. I'm still pretty burned out from that discussion.

> Thus rather than worrying about the details (library X should be put in module Y), can I get a "sense of the senate" on the following two proposals:
> 
> 
> 1) Eliminate all reference to "Phobos" in favor of its "formal name". (Let's not debate *what* that name is quite yet; let's just figure out if there's consensus that the name should change at all.)

I don't see how we can decide the name won't be Phobos if we don't get to discuss what it might be. There are worse names than Phobos out there. I propose we can it the "D Standard Library". (We can say the "code name" was Phobos if that makes Walter feel better.)

> 
> 2) Add something like the following passage to the <formal name> Philosphy section:
> 
> "No special-purpose modules.  Don't add modules to the <formal name> package that accomplish specific, high-level functions.  Rather, <formal name> is reserved for modules that provide universal, low-level functionality that almost all applications require, irrespective of problem domain.  <formal name> modules are supported with a priority equal to the compiler itself. The namespace is big.  Use it."

I think it's more important to better organize the contents of the standard library than to bicker about what gets included and what doesn't. Let's have a broad umbrella, but keep every person in his own corner.

Perhaps something like this (it doesn't have to be this I'm just throwing out some ideas)...

std.*
(general purpose stuff)
std.date
std.format
std.math
std.path
std.string
std.stream
std.thread

std.misc.*
(more specialized stuff)
std.misc.base64
std.misc.md5
std.misc.random
std.misc.recls
std.misc.zip
std.misc.zlib

std.internal.*
(internal compiler stuff)
std.internal.gc
std.internal.compiler
std.internal.object (Why does object have to be in the root?)
std.internal.asserterr

std.classic.*
(C stuff)
std.classic.stdio
std.classic.windows

...

> 
> -david
> 
> PS: I didn't hear Walter weigh in.  Given that his vote is equal  to or greater than the sum of all other votes, I'd be interested in his opinion. 
> 
> 

He often waits for us to come up with some sort of prevailing idea before he drops in and tells us what he doesn't like about the concept (unless he likes the idea and then it'll magically appear in the next release of DMD).


-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Derek Parnell wrote:
> 
> I think the terms "high-level", and "low-level" need to be removed from
> passage. Mainly because different people have different ideas about which
> is which, and what falls into either.

Till we find other words for these two, I suggest we use them.

We could also use "directly-useful" and "nuts-and-bolts", respectively (or some such).

The main thing is that the "low-level" things would be stuff that programmers doing regular stuff would not usually use directly. In the same spirit, probably most named packages would use these extensively, as the bricks out of which to build the railway station, hospital, or residential buildings.

On Tue, 29 Mar 2005 12:50:54 +0300, Georg Wrede wrote:

> Derek Parnell wrote:
>> 
>> I think the terms "high-level", and "low-level" need to be removed from passage. Mainly because different people have different ideas about which is which, and what falls into either.
> 
> Till we find other words for these two, I suggest we use them.
> 
> We could also use "directly-useful" and "nuts-and-bolts", respectively (or some such).

True, but does that help? In fact, I was trying to say that such terms, subjective as they are, are actually harmful to the discussion at hand. I think this because they can be twisted in an attempt to justify all sorts of unjustifiable inclusions and exclusions. A better approach might be to have a clearly unambiguous definition of the properties and attributes of functions that ought to be included in the standard library, and if required an ancillary library. Then, with the minimum of subjective adjudication, we can all agree on whether or not a specific function needs to be included in the standard library, or in an ancillary library, or excluded altogether.

When we have a list of standard library functions and a set of grouping criteria, we can then decide how to group these together into modules. Additional functions can be processed in the same manner when they are submitted for inclusion.

All of this discussion presupposes that there exists, or will exist, a body of people that can have authority to define and enforce the standard. I'm not so sure we have that settled yet.

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
29/03/2005 8:43:40 PM

Derek Parnell wrote:
> On Tue, 29 Mar 2005 12:50:54 +0300, Georg Wrede wrote:
> 
> 
>>Derek Parnell wrote:
>>
>>>I think the terms "high-level", and "low-level" need to be removed from
>>>passage. Mainly because different people have different ideas about which
>>>is which, and what falls into either.
>>
>>Till we find other words for these two, I suggest we use them.
>>
>>We could also use "directly-useful" and "nuts-and-bolts", respectively (or some such).
> 
> 
> True, but does that help? In fact, I was trying to say that such terms,
> subjective as they are, are actually harmful to the discussion at hand. I
> think this because they can be twisted in an attempt to justify all sorts
> of unjustifiable inclusions and exclusions. A better approach might be to
> have a clearly unambiguous definition of the properties and attributes of
> functions that ought to be included in the standard library, and if
> required an ancillary library. Then, with the minimum of subjective
> adjudication, we can all agree on whether or not a specific function needs
> to be included in the standard library, or in an ancillary library, or
> excluded altogether. 
> 
> When we have a list of standard library functions and a set of grouping
> criteria, we can then decide how to group these together into modules.
> Additional functions can be processed in the same manner when they are
> submitted for inclusion.
> 
> All of this discussion presupposes that there exists, or will exist, a body
> of people that can have authority to define and enforce the standard. I'm
> not so sure we have that settled yet.

And that we also have it somewhere "on the wall", where everybody can see the "this hour" version. A wiki or some such comes to mind.

Georg Wrede wrote:
> Till we find other words for these two, I suggest we use them.

"runtime library", things that are vital to the compiler and without which the language described in the docs (outside of the phobos docs) does not "work", things like the GC and the exception infrastructure; vs "utility library", things like files and utf and string handling... ?


-ben

Benjamin Herr wrote:

>>Till we find other words for these two, I suggest we use them.
> 
> "runtime library", things that are vital to the compiler and without
> which the language described in the docs (outside of the phobos docs)
> does not "work", things like the GC and the exception infrastructure; vs
> "utility library", things like files and utf and string handling... ?

There are actually four parts of Phobos:

- the runtime library ("rt"), object.d, std/typeinfo/ and internal/

- the garbage collector ("gc") gcstats.d and internal/gc/ (pluggable ?)

- the main library ("std"), should be modules all written in D

- the extras library ("etc"), currently partly written in C/C++
  etc.c.recls and etc.c.zlib (possibly additional libs in the future ?)

--anders