View mode: basic / threaded / horizontal-split · Log in · Help
March 28, 2005
D Standard Modules
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.
March 28, 2005
Re: D Standard Modules
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
March 29, 2005
Re: D Standard Modules
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/
March 29, 2005
Re: D Standard Modules
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.
March 29, 2005
Re: D Standard Modules
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
March 29, 2005
Re: D Standard Modules
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.
March 29, 2005
Re: D Standard Modules
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
March 29, 2005
Re: D Standard Modules
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
Top | Discussion index | About this forum | D home