"J C Calvarese" <jcc7@cox.net> wrote in message news:bn79ud$1rmr$1@digitaldaemon.com...
> Matthew Wilson wrote:
> > Ok. Here's where I see the situation. We have several options
> >
> > 1. D
> > 2. d
> > 3. phobos
> > 4. std
> > 5. stdd
> > 6. lang
>
> 7. dee
> 8. drt (D RunTime)
> 9. dlib
>
>  > [10]. some other multi-letter prefix
>
>
> D/d:
> I don't think it's to anyone's benefit to turn all the individual
> letters into potential minefields (hey, we could also rename "if" to "i"
> and "for" to "f").

You're over egging your pudding here. No one's suggested doing this.

(It's not politics; there's no need to invent counter arguments to rail
against. ;)

> If we have to go this route, I prefer using "d" for
> the module prefix for the sake of having a consistent module naming
> convention.

Noted. Another one in the lowercase camp.

> >
> > The primary bifurcation on opinion is whether it is d/D or a
multi-letter.
> > Personally I'm still in two minds about this, although I lean towards
d/D
> >
> > Secondary to that, therefore, is whether on for former case we go for d
or
> > for D. I lean towards d, and think that in either case it's not
unreasonable
> > to reserve the name of the language (in both cases).
> >
> > For the case of multi-letter prefixes, phobos is ruled out because of
its
> > (Digital) Mars specificity, but the other contenders seem reasonable,
albeit
> > somewhat prosaic.
> >
>
> I think phobos is an interesting, distinctive name.  Don't we want it to be an interesting, distinctive library?

We do. It's not me who's having the strong objections to Phobos - IIRC that's Walter himself - but I can see it does make the language, or the library at least, look a little toy/juvenile. But it's not a strong impression.

> > It would be useful if everyone could express their opinions on the main question of d/D vs multi-letter, *and* the secondary questions.
> >
> > Is there a possibility that one of you web-enabled kinda guys could
organise
> > a vote? Helmut, what about a place on your wiki stuff?
> >
> > Anyway, it may well be that Walter's just decided, and that's it, but
until
> > he says he is immovable I would like to explore. This is a very
important
> > issue that, once fixed, cannot be changed, so it's worth a little of all
our
> > consideration.
> >
> > Cheers
>
> Justin

"Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bn79m9$1rdq$1@digitaldaemon.com...
> > I guess it just invites those NIH instincts to rise
> NIH ?

Not Invented Here. Apart from a propensity for thinking in binary, this is about the most innate aspect of all software engineers.

Walter wrote his own C++ compiler because he didn't want to use anyone else's. Then he wrote his own language because he didn't want to use anyone else's.

I released STLSoft because one of the Boost's core libraries (no names, no pack drill) said something so fundamentally stupid as a justification for a (wrong) implemetation strategy that I just completely lost faith in their ability to produce efficient and robust code. (Of course, they have produced a lot of robust code, don't get me wrong, just explaining the instincts.)

> > In any case, why is it only platforms that one should be independent of?
> One
> > could equally argue that XML stuff shouldn't be in there.
>
> I totally agree XML stuff should'nt be in there!
>
> > Do you really want to hold up the C runtime library as an example of the best libraries there can be? Surely not.
>
> Whats wrong with C library ?

Well, it's great that its got an ABI, but it gets that from C. There are many many bad things about it. People only don't notice because they compare it to the C++ standard libraries (STL, for the most part, excepted) against which it looks orthogonal, efficient and neat.

> But my main argument is not that we shouldn't have the functionality you mentioned, I think we defeintly need that but I don't think it should be
in
> the one library that MUST be linked in.  C's lib is small and effecient, thats where I was going with the C refrence.  All those other libs can be implemeneted apart from phobos, so we can choose wether or not we want to link them in ( and make our end executable larger) .

If it's a library against which one is linking it doesn't matter how much it has in it, does it? The linker will take what it needs. But that's beside the point, we should/must have a set of libraries that make sense, and are as interdependent as necessary, but no more. That's all still up in the air, and your comments of the previous paragraph are as valid as what anyone else thinks at this time.

> We can make them 'official' in some other respect ?  ( If thats a problem
> ? )

I think we're talking at cross purposes here. The standard library (AFAIUI) is what ships with the D compiler as standard, and not necessary what is in a specific .lib, or set of them. That's all still in the air

> C
>
> "Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bn781a$1pal$1@digitaldaemon.com...
> > > I vote phobos, its the name of the runtime library why cant other
> vendors
> > > call it that also ?
> >
> > I guess it just invites those NIH instincts to rise. I guess the
thinking
> is
> > it's nice how Java's std libraries are under java, so why can't D have
the
> > same?
> >
> > > Also, what is win32 / linux specifc stuff doing in the library ?
> >
> > Why shouldn't platform specific stuff be in the library? This is a
> language
> > about usability and efficiency, not some notional purity. If we want everything to be platform/technology independent, we're going to have
some
> > very unweidly and inefficient code, like .. erm .. Java.
> >
> > In any case, why is it only platforms that one should be independent of?
> One
> > could equally argue that XML stuff shouldn't be in there. Or UDP vs TCP: shouldn't it all be an invisible
> >
> > Of course no-one's saying that common functionality, like file-handling, should be implemented in a specific fashion, but do you not think there
> are
> > platform-specific features that we would want in?
> >
> > Consider the case of COM. Imagine for a moment that COM really had made
a
> > successful transition to Linux. In this case, when we implement the platform-independent D COM libraries we're a bit stuck. The Win32
versions
> > of the D.com modules will have to reference some "external" modules, in order to implement their registration functionality.
> >
> > Now maybe COM is not the best example, because the likelihood of our
doing
> a
> > Linux version is pretty slim (although maybe that's not the case for
> Mac!?),
> > but I'm sure you can extrapolate to other things. Networking, for
example.
> > We'd be idiotic to not support using IO Completion ports on Win32 implementations, but this doesn't work for UNIX.
> >
> >
> > >  Shouldn't phobos just contain platform indepenent functions, like C's
?
> >
> > Do you really want to hold up the C runtime library as an example of the best libraries there can be? Surely not.
> >
> > > I pray that D is not selected, although d gets my vote if we cant have phobos.
> >
> > Agreed
> >
> > >
> > > C
> > > "Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message
> > > news:bn75am$1lou$1@digitaldaemon.com...
> > > > Ok. Here's where I see the situation. We have several options
> > > >
> > > > 1. D
> > > > 2. d
> > > > 3. phobos
> > > > 4. std
> > > > 5. stdd
> > > > 6. lang
> > > > 7. some other multi-letter prefix
> > > >
> > > > The primary bifurcation on opinion is whether it is d/D or a
> > multi-letter.
> > > > Personally I'm still in two minds about this, although I lean
towards
> > d/D
> > > >
> > > > Secondary to that, therefore, is whether on for former case we go
for
> d
> > or
> > > > for D. I lean towards d, and think that in either case it's not
> > > unreasonable
> > > > to reserve the name of the language (in both cases).
> > > >
> > > > For the case of multi-letter prefixes, phobos is ruled out because
of
> > its
> > > > (Digital) Mars specificity, but the other contenders seem
reasonable,
> > > albeit
> > > > somewhat prosaic.
> > > >
> > > > It would be useful if everyone could express their opinions on the
> main
> > > > question of d/D vs multi-letter, *and* the secondary questions.
> > > >
> > > > Is there a possibility that one of you web-enabled kinda guys could
> > > organise
> > > > a vote? Helmut, what about a place on your wiki stuff?
> > > >
> > > > Anyway, it may well be that Walter's just decided, and that's it,
but
> > > until
> > > > he says he is immovable I would like to explore. This is a very
> > important
> > > > issue that, once fixed, cannot be changed, so it's worth a little of
> all
> > > our
> > > > consideration.
> > > >
> > > > Cheers
> > > >
> > > >
> > > > -- 
> > > > Matthew Wilson
> > > >
> > > > STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
> > > > Contributing editor, C/C++ Users Journal
> > > > (www.synesis.com.au/articles.html#columns)
> > > >
> > > > "If i'm curt with you it's because time is a factor. I think fast, I
> > talk
> > > > fast, and I need you guys to act fast" -- Mr Wolf
> > > >
> > >
> >
>
> --------------------------------------------------------------------------
> > > --
> > > > ---
> > > >
> > > >
> > > > "Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bn73fk$1jfo$1@digitaldaemon.com...
> > > > > In article <bn6tgo$1b4d$1@digitaldaemon.com>, Matthew Wilson
says...
> > > > > >
> > > > > >
> > > > > >"Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bn6skf$19si$1@digitaldaemon.com...
> > > > > >> In article <bn6sef$19kb$1@digitaldaemon.com>, Matthew Wilson
> > says...
> > > > > >> >
> > > > > >> >I've been thinking about this module naming stuff, and
> considering
> > > > C++'s
> > > > > >> >approach.
> > > > > >> >
> > > > > >> >Clearly one of the reasons they chose std was because it was
at
> > > least
> > > > a
> > > > > >bit
> > > > > >> >unambiguous (three letters!)
> > > > > >>
> > > > > >> HEY!   Why can't we use std?  standard-d?
> > > > > >
> > > > > >Well I guess no reason, other than Walter (and others, me
included)
> > > want
> > > > D.
> > > > > >The main contention is that it seems that Walter's the only one
> > (who's
> > > > > >publicly expressed, anyway) the preference for D over d, despite
> the
> > > > > >inconsistency. Do you have a preference in that regard?
> > > > >
> > > > > If you held my arm against my back and forced me to make a
decision
> > > > > I would say d.   But I really dislike using a one letter name.
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

As you can see from the group, everyone prefers d to D, irrespective of whether they prefer mutli-letter over d/D.

Can we start by changing D.win32.registry to d.win32.registry for 0.75, and move from there unless and until we encounter any bumps in the road?

"Walter" <walter@digitalmars.com> wrote in message news:bn79f8$1r4i$2@digitaldaemon.com...
>
> "Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bn6sef$19kb$1@digitaldaemon.com...
> > I've been thinking about this module naming stuff, and considering C++'s approach.
> >
> > Clearly one of the reasons they chose std was because it was at least a
> bit
> > unambiguous (three letters!)
> >
> > I'm starting to wonder whether Helmut's notion of the standard library's having something longer than D (or d) makes sense.
> >
> > Separately, I still don't see any difference between D and d, other than
D
> > is less consistent, which will be a permanent flaw on the language.
Having
> > people not be able to write d in a language called D doesn't seen a
great
> > hardship. It's not exactly difficult to do a global whole-word search
and
> > replace to change all d or D into d_ and D_ (or whatever).
> >
> > I know I'm wandering a bit, but *please* let us have d.win32.etc.
>
> It isn't cast in stone. All I've really done so far is name
D.win32.registry
> for your registry package. Let's wait and see a bit and the smoke may
clear
> on the best solution.
>
>

>If it's a library against which one is linking it doesn't matter how much
it
>has in it, does it? The linker will take what it needs.

Eeep your right.  Well that was my only real problem with it , so seeing as
its not an issue im for packing it full ( no xml please ;) ).

C


"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bn7ban$1tkg$1@digitaldaemon.com...
>
> "Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bn79m9$1rdq$1@digitaldaemon.com...
> > > I guess it just invites those NIH instincts to rise
> > NIH ?
>
> Not Invented Here. Apart from a propensity for thinking in binary, this is about the most innate aspect of all software engineers.
>
> Walter wrote his own C++ compiler because he didn't want to use anyone else's. Then he wrote his own language because he didn't want to use
anyone
> else's.
>
> I released STLSoft because one of the Boost's core libraries (no names, no pack drill) said something so fundamentally stupid as a justification for
a
> (wrong) implemetation strategy that I just completely lost faith in their
> ability to produce efficient and robust code. (Of course, they have
produced
> a lot of robust code, don't get me wrong, just explaining the instincts.)
>
> > > In any case, why is it only platforms that one should be independent
of?
> > One
> > > could equally argue that XML stuff shouldn't be in there.
> >
> > I totally agree XML stuff should'nt be in there!
> >
> > > Do you really want to hold up the C runtime library as an example of
the
> > > best libraries there can be? Surely not.
> >
> > Whats wrong with C library ?
>
> Well, it's great that its got an ABI, but it gets that from C. There are many many bad things about it. People only don't notice because they
compare
> it to the C++ standard libraries (STL, for the most part, excepted)
against
> which it looks orthogonal, efficient and neat.
>
> > But my main argument is not that we shouldn't have the functionality you mentioned, I think we defeintly need that but I don't think it should be
> in
> > the one library that MUST be linked in.  C's lib is small and effecient, thats where I was going with the C refrence.  All those other libs can
be
> > implemeneted apart from phobos, so we can choose wether or not we want
to
> > link them in ( and make our end executable larger) .
>
> If it's a library against which one is linking it doesn't matter how much
it
> has in it, does it? The linker will take what it needs. But that's beside the point, we should/must have a set of libraries that make sense, and are as interdependent as necessary, but no more. That's all still up in the
air,
> and your comments of the previous paragraph are as valid as what anyone
else
> thinks at this time.
>
> > We can make them 'official' in some other respect ?  ( If thats a
problem
> > ? )
>
> I think we're talking at cross purposes here. The standard library
(AFAIUI)
> is what ships with the D compiler as standard, and not necessary what is
in
> a specific .lib, or set of them. That's all still in the air
>
> > C
> >
> > "Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bn781a$1pal$1@digitaldaemon.com...
> > > > I vote phobos, its the name of the runtime library why cant other
> > vendors
> > > > call it that also ?
> > >
> > > I guess it just invites those NIH instincts to rise. I guess the
> thinking
> > is
> > > it's nice how Java's std libraries are under java, so why can't D have
> the
> > > same?
> > >
> > > > Also, what is win32 / linux specifc stuff doing in the library ?
> > >
> > > Why shouldn't platform specific stuff be in the library? This is a
> > language
> > > about usability and efficiency, not some notional purity. If we want everything to be platform/technology independent, we're going to have
> some
> > > very unweidly and inefficient code, like .. erm .. Java.
> > >
> > > In any case, why is it only platforms that one should be independent o
f?
> > One
> > > could equally argue that XML stuff shouldn't be in there. Or UDP vs
TCP:
> > > shouldn't it all be an invisible
> > >
> > > Of course no-one's saying that common functionality, like
file-handling,
> > > should be implemented in a specific fashion, but do you not think
there
> > are
> > > platform-specific features that we would want in?
> > >
> > > Consider the case of COM. Imagine for a moment that COM really had
made
> a
> > > successful transition to Linux. In this case, when we implement the platform-independent D COM libraries we're a bit stuck. The Win32
> versions
> > > of the D.com modules will have to reference some "external" modules,
in
> > > order to implement their registration functionality.
> > >
> > > Now maybe COM is not the best example, because the likelihood of our
> doing
> > a
> > > Linux version is pretty slim (although maybe that's not the case for
> > Mac!?),
> > > but I'm sure you can extrapolate to other things. Networking, for
> example.
> > > We'd be idiotic to not support using IO Completion ports on Win32 implementations, but this doesn't work for UNIX.
> > >
> > >
> > > >  Shouldn't phobos just contain platform indepenent functions, like
C's
> ?
> > >
> > > Do you really want to hold up the C runtime library as an example of
the
> > > best libraries there can be? Surely not.
> > >
> > > > I pray that D is not selected, although d gets my vote if we cant
have
> > > > phobos.
> > >
> > > Agreed
> > >
> > > >
> > > > C
> > > > "Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message
> > > > news:bn75am$1lou$1@digitaldaemon.com...
> > > > > Ok. Here's where I see the situation. We have several options
> > > > >
> > > > > 1. D
> > > > > 2. d
> > > > > 3. phobos
> > > > > 4. std
> > > > > 5. stdd
> > > > > 6. lang
> > > > > 7. some other multi-letter prefix
> > > > >
> > > > > The primary bifurcation on opinion is whether it is d/D or a
> > > multi-letter.
> > > > > Personally I'm still in two minds about this, although I lean
> towards
> > > d/D
> > > > >
> > > > > Secondary to that, therefore, is whether on for former case we go
> for
> > d
> > > or
> > > > > for D. I lean towards d, and think that in either case it's not
> > > > unreasonable
> > > > > to reserve the name of the language (in both cases).
> > > > >
> > > > > For the case of multi-letter prefixes, phobos is ruled out because
> of
> > > its
> > > > > (Digital) Mars specificity, but the other contenders seem
> reasonable,
> > > > albeit
> > > > > somewhat prosaic.
> > > > >
> > > > > It would be useful if everyone could express their opinions on the
> > main
> > > > > question of d/D vs multi-letter, *and* the secondary questions.
> > > > >
> > > > > Is there a possibility that one of you web-enabled kinda guys
could
> > > > organise
> > > > > a vote? Helmut, what about a place on your wiki stuff?
> > > > >
> > > > > Anyway, it may well be that Walter's just decided, and that's it,
> but
> > > > until
> > > > > he says he is immovable I would like to explore. This is a very
> > > important
> > > > > issue that, once fixed, cannot be changed, so it's worth a little
of
> > all
> > > > our
> > > > > consideration.
> > > > >
> > > > > Cheers
> > > > >
> > > > >
> > > > > -- 
> > > > > Matthew Wilson
> > > > >
> > > > > STLSoft moderator and C++ monomaniac
(http://www.stlsoft.org)
> > > > > Contributing editor, C/C++ Users Journal
> > > > > (www.synesis.com.au/articles.html#columns)
> > > > >
> > > > > "If i'm curt with you it's because time is a factor. I think fast,
I
> > > talk
> > > > > fast, and I need you guys to act fast" -- Mr Wolf
> > > > >
> > > >
> > >
> >
>
> --------------------------------------------------------------------------
> > > > --
> > > > > ---
> > > > >
> > > > >
> > > > > "Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bn73fk$1jfo$1@digitaldaemon.com...
> > > > > > In article <bn6tgo$1b4d$1@digitaldaemon.com>, Matthew Wilson
> says...
> > > > > > >
> > > > > > >
> > > > > > >"Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bn6skf$19si$1@digitaldaemon.com...
> > > > > > >> In article <bn6sef$19kb$1@digitaldaemon.com>, Matthew Wilson
> > > says...
> > > > > > >> >
> > > > > > >> >I've been thinking about this module naming stuff, and
> > considering
> > > > > C++'s
> > > > > > >> >approach.
> > > > > > >> >
> > > > > > >> >Clearly one of the reasons they chose std was because it was
> at
> > > > least
> > > > > a
> > > > > > >bit
> > > > > > >> >unambiguous (three letters!)
> > > > > > >>
> > > > > > >> HEY!   Why can't we use std?  standard-d?
> > > > > > >
> > > > > > >Well I guess no reason, other than Walter (and others, me
> included)
> > > > want
> > > > > D.
> > > > > > >The main contention is that it seems that Walter's the only one
> > > (who's
> > > > > > >publicly expressed, anyway) the preference for D over d,
despite
> > the
> > > > > > >inconsistency. Do you have a preference in that regard?
> > > > > >
> > > > > > If you held my arm against my back and forced me to make a
> decision
> > > > > > I would say d.   But I really dislike using a one letter name.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Matthew Wilson wrote:

> "J C Calvarese" <jcc7@cox.net> wrote in message
...

>>D/d:
>>I don't think it's to anyone's benefit to turn all the individual
>>letters into potential minefields (hey, we could also rename "if" to "i"
>>and "for" to "f").
> 
> 
> You're over egging your pudding here. No one's suggested doing this.
> 
> (It's not politics; there's no need to invent counter arguments to rail
> against. ;) 

I think this might have made more sense if I had typed out more of what I was thinking.

I was just trying to mention that there's probably a reason why we don't have any one-letter keywords -- being that terse when creating a language is a recipe for disaster.  I don't think it's too much to ask that a top-level package have at least a couple of letters in it.

My point was I think there's an implicit line drawn on how short a keyword can be, and I think we need to have expectations on how short a package name should be.

A while back I was working on a small project and suddenly these strange compile errors started popping up regarding a variable that seemed to work fine before (it happened to be named "c").  Then I realized the problem came from when I added "import c.something" to either that file or something that was imported by that file.  I didn't know it would cause a problem to use a variable named "c".  That name had been fair game before and now suddenly it was off-limits.  D will be more successful if newbies have fewer random brick walls to run into.

Okay, I've rambled enough at this point...

Justin

J C Calvarese <jcc7@cox.net> wrote in news:bn79ud$1rmr$1@digitaldaemon.com:

> Matthew Wilson wrote:
>> Ok. Here's where I see the situation. We have several options
>> 
>> 1. D
>> 2. d
>> 3. phobos
>> 4. std
>> 5. stdd
>> 6. lang
> 
> 7. dee
> 8. drt (D RunTime)
> 9. dlib

10. dsl ( D standard library )

Ok i change my vote to drt.

C


"J C Calvarese" <jcc7@cox.net> wrote in message news:bn79ud$1rmr$1@digitaldaemon.com...
> Matthew Wilson wrote:
> > Ok. Here's where I see the situation. We have several options
> >
> > 1. D
> > 2. d
> > 3. phobos
> > 4. std
> > 5. stdd
> > 6. lang
>
> 7. dee
> 8. drt (D RunTime)
> 9. dlib
>
>  > [10]. some other multi-letter prefix
>
>
> D/d:
> I don't think it's to anyone's benefit to turn all the individual
> letters into potential minefields (hey, we could also rename "if" to "i"
> and "for" to "f").  If we have to go this route, I prefer using "d" for
> the module prefix for the sake of having a consistent module naming
> convention.
>
> >
> > The primary bifurcation on opinion is whether it is d/D or a
multi-letter.
> > Personally I'm still in two minds about this, although I lean towards
d/D
> >
> > Secondary to that, therefore, is whether on for former case we go for d
or
> > for D. I lean towards d, and think that in either case it's not
unreasonable
> > to reserve the name of the language (in both cases).
> >
> > For the case of multi-letter prefixes, phobos is ruled out because of
its
> > (Digital) Mars specificity, but the other contenders seem reasonable,
albeit
> > somewhat prosaic.
> >
>
> I think phobos is an interesting, distinctive name.  Don't we want it to be an interesting, distinctive library?
>
> > It would be useful if everyone could express their opinions on the main question of d/D vs multi-letter, *and* the secondary questions.
> >
> > Is there a possibility that one of you web-enabled kinda guys could
organise
> > a vote? Helmut, what about a place on your wiki stuff?
> >
> > Anyway, it may well be that Walter's just decided, and that's it, but
until
> > he says he is immovable I would like to explore. This is a very
important
> > issue that, once fixed, cannot be changed, so it's worth a little of all
our
> > consideration.
> >
> > Cheers
>
> Justin
>

It's a fair point. But the neatness of d.xyz.abc is going to be hard to fight.


"J C Calvarese" <jcc7@cox.net> wrote in message news:bn7e9k$21dq$1@digitaldaemon.com...
> Matthew Wilson wrote:
>
> > "J C Calvarese" <jcc7@cox.net> wrote in message
> ...
>
> >>D/d:
> >>I don't think it's to anyone's benefit to turn all the individual
> >>letters into potential minefields (hey, we could also rename "if" to "i"
> >>and "for" to "f").
> >
> >
> > You're over egging your pudding here. No one's suggested doing this.
> >
> > (It's not politics; there's no need to invent counter arguments to rail
> > against. ;)
>
> I think this might have made more sense if I had typed out more of what I was thinking.
>
> I was just trying to mention that there's probably a reason why we don't have any one-letter keywords -- being that terse when creating a language is a recipe for disaster.  I don't think it's too much to ask that a top-level package have at least a couple of letters in it.
>
> My point was I think there's an implicit line drawn on how short a keyword can be, and I think we need to have expectations on how short a package name should be.
>
> A while back I was working on a small project and suddenly these strange compile errors started popping up regarding a variable that seemed to work fine before (it happened to be named "c").  Then I realized the problem came from when I added "import c.something" to either that file or something that was imported by that file.  I didn't know it would cause a problem to use a variable named "c".  That name had been fair game before and now suddenly it was off-limits.  D will be more successful if newbies have fewer random brick walls to run into.
>
> Okay, I've rambled enough at this point...
>
> Justin
>

J C Calvarese wrote:
> 
> Matthew Wilson wrote:
> > Ok. Here's where I see the situation. We have several options
> >
> > 1. D
> > 2. d
> > 3. phobos
> > 4. std
> > 5. stdd
> > 6. lang
> 
> 7. dee
> 8. drt (D RunTime)
> 9. dlib            <====

That's my favorite, because that's what it is, the "D library", in short.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

But its a contraction, rather than an initialism. Why not dli? or dlibr? See what I mean?

I'd rather dsl, for D standard library, than that, but I'd rather just "d"

"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3F976C76.5BCF6E5C@chello.at...
>
>
> J C Calvarese wrote:
> >
> > Matthew Wilson wrote:
> > > Ok. Here's where I see the situation. We have several options
> > >
> > > 1. D
> > > 2. d
> > > 3. phobos
> > > 4. std
> > > 5. stdd
> > > 6. lang
> >
> > 7. dee
> > 8. drt (D RunTime)
> > 9. dlib            <====
>
> That's my favorite, because that's what it is,
> the "D library", in short.
>
> -- 
> Helmut Leitner    leitner@hls.via.at
> Graz, Austria   www.hls-software.com