www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Standard Modules

reply "David Barrett" <dbarrett quinthar.com> writes:
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. 
Mar 28 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
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
Mar 28 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
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.
Mar 29 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
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
Mar 29 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
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.
Mar 29 2005
prev sibling parent reply Benjamin Herr <ben 0x539.de> writes:
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
Mar 29 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Mar 29 2005
prev sibling parent J C Calvarese <jcc7 cox.net> writes:
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/
Mar 28 2005