www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Phobos: What's in a name?

reply "David Barrett" <dbarrett quinthar.com> writes:
Ok, sounds like the tally is as follows:

[For renaming Phobos to "D Standard Library"] J C Calvarese, David Barrett
[For renaming Phobos, but to something else (Diesel)] Derek Parnell, Matthew
[Ambivalent] Ben Hinkle
[Against renaming] David L. Davis

[Unknown] Anders F Björklund, Carlos Santander B, Sean Kelly, Walter, 
Benjamin Herr,  Georg Wrede, Trevor Parscal, everyone else

I apologize in advance if I've mis-categorized anyone; please correct me.

-david
Mar 29 2005
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"David Barrett" <dbarrett quinthar.com> wrote in message
news:d2d505$3029$1 digitaldaemon.com...

 Ok, sounds like the tally is as follows:

 [For renaming Phobos to "D Standard Library"] J C Calvarese, David Barrett
 [For renaming Phobos, but to something else (Diesel)] Derek Parnell, Matthew
 [Ambivalent] Ben Hinkle
 [Against renaming] David L. Davis

 [Unknown] Anders F Björklund, Carlos Santander B, Sean Kelly, Walter, Benjamin
Herr,  Georg Wrede, Trevor Parscal, 
 everyone else

 I apologize in advance if I've mis-categorized anyone; please correct me.


I'm not allied to the one you've put me on. If I have to be somewhere, I think
I'm probably with Ben. (Which makes a 
nice change <g>)

But I really think this is an irrelevance, c/w the real issues with Phobos
itself. We could have Phobos renamed, 
including all documentation and all code, in virtually a single sweep, and
certainly within a week from decision to 
release. But it seems like Phobos itself hasn't got any closer to being ready
in at least a year and a half.

And I have to disagree with Walter's recent assertion (or maybe my
interpretation of it) that bug fixing in the 
language/compiler is more important than fixing Phobos. I think unless and
until D has a good library that has been well 
and widely tested, it makes advances in and improvement of the
language/compiler somewhat moot. To me, they're 50-50, 
not 80-20 (or 70-30 or whatever figure might be induced from Walter's post).
Mar 29 2005
next sibling parent "David Barrett" <dbarrett quinthar.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message 
news:d2d5s9$30mq$1 digitaldaemon.com...

 But I really think this is an irrelevance, c/w the real issues with Phobos 
 itself. We could have Phobos renamed, including all documentation and all 
 code, in virtually a single sweep, and certainly within a week from 
 decision to release. But it seems like Phobos itself hasn't got any closer 
 to being ready in at least a year and a half.


I've only been paying attention for about eight months, but I concur.


 And I have to disagree with Walter's recent assertion (or maybe my 
 interpretation of it) that bug fixing in the language/compiler is more 
 important than fixing Phobos. I think unless and until D has a good 
 library that has been well and widely tested, it makes advances in and 
 improvement of the language/compiler somewhat moot. To me, they're 50-50, 
 not 80-20 (or 70-30 or whatever figure might be induced from Walter's 
 post).


I totally agree with Matthew here.

-david
Mar 30 2005
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 30 Mar 2005 13:21:29 +1000, Matthew <admin.hat stlsoft.dot.org>  
wrote:

 "David Barrett" <dbarrett quinthar.com> wrote in message  
 news:d2d505$3029$1 digitaldaemon.com...

 Ok, sounds like the tally is as follows:

 [For renaming Phobos to "D Standard Library"] J C Calvarese, David  
 Barrett
 [For renaming Phobos, but to something else (Diesel)] Derek Parnell,  
 Matthew
 [Ambivalent] Ben Hinkle
 [Against renaming] David L. Davis

 [Unknown] Anders F Björklund, Carlos Santander B, Sean Kelly, Walter,  
 Benjamin Herr,  Georg Wrede, Trevor Parscal,
 everyone else

 I apologize in advance if I've mis-categorized anyone; please correct  
 me.


 I'm not allied to the one you've put me on. If I have to be somewhere, I  
 think I'm probably with Ben. (Which makes a
 nice change <g>)

 But I really think this is an irrelevance, c/w the real issues with  
 Phobos itself.


I am with you here.


 And I have to disagree with Walter's recent assertion (or maybe my  
 interpretation of it) that bug fixing in the
 language/compiler is more important than fixing Phobos. I think unless  
 and until D has a good library that has been well
 and widely tested, it makes advances in and improvement of the  
 language/compiler somewhat moot. To me, they're 50-50,
 not 80-20 (or 70-30 or whatever figure might be induced from Walter's  
 post).


I'm not with you here. In my recent experience, of having tried to write  
some "library" code using templates and mixins, I found that until the  
bugs/problems in the compiler are resolved I cannot write the "library"  
code in the way it "should" be written. At best I could produce something  
that worked in some hackish or ungainly manner. I am loath to produce code  
for a library that is hackish. It's what is currently stopping me from  
producing large amounts of code in D (that and spare time), every time I  
get started I hit these bumps in the road.

Regan
Mar 30 2005
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
 And I have to disagree with Walter's recent assertion (or maybe my 
interpretation of it) that bug fixing in the
 language/compiler is more important than fixing Phobos. I think unless  and
until D has a good library that has been 
 well
 and widely tested, it makes advances in and improvement of the 
language/compiler somewhat moot. To me, they're 
 50-50,
 not 80-20 (or 70-30 or whatever figure might be induced from Walter's  post).


 I'm not with you here. In my recent experience, of having tried to write  some
"library" code using templates and 
 mixins, I found that until the  bugs/problems in the compiler are resolved I
cannot write the "library"  code in the 
 way it "should" be written. At best I could produce something  that worked in
some hackish or ungainly manner. I am 
 loath to produce code  for a library that is hackish. It's what is currently
stopping me from  producing large amounts 
 of code in D (that and spare time), every time I  get started I hit these
bumps in the road.


Are you suggesting that your aims and experience - common to us all, I'm sure -
are representative of the broad mass of 
putative D users come a 1.0 release? That's the only really important audience,
and if they're not catered for, then D 
won't prosper.
Mar 30 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 30 Mar 2005 21:06:38 +1000, Matthew <admin.hat stlsoft.dot.org>  
wrote:

 And I have to disagree with Walter's recent assertion (or maybe my   
 interpretation of it) that bug fixing in the
 language/compiler is more important than fixing Phobos. I think  
 unless  and until D has a good library that has been
 well
 and widely tested, it makes advances in and improvement of the   
 language/compiler somewhat moot. To me, they're
 50-50,
 not 80-20 (or 70-30 or whatever figure might be induced from Walter's   
 post).


 I'm not with you here. In my recent experience, of having tried to  
 write  some "library" code using templates and
 mixins, I found that until the  bugs/problems in the compiler are  
 resolved I cannot write the "library"  code in the
 way it "should" be written. At best I could produce something  that  
 worked in some hackish or ungainly manner. I am
 loath to produce code  for a library that is hackish. It's what is  
 currently stopping me from  producing large amounts
 of code in D (that and spare time), every time I  get started I hit  
 these bumps in the road.


 Are you suggesting that your aims and experience - common to us all, I'm  
 sure - are representative of the broad mass of
 putative D users come a 1.0 release?


I'm suggesting that before we can write a good library (standard or  
otherwise) we need a solid bug-free compiler which compiles everything the  
spec suggests it should compile.


 That's the only really important audience, and if they're not catered  
 for, then D
 won't prosper.


If D reaches 1.0, gets a lot of exposure and is not "ready" that will  
likely harm it's chances of success at least in the short term, long  
term.. people are generally willing to give something a second chance.

Regan
Mar 30 2005
next sibling parent =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Regan Heath wrote:


 Are you suggesting that your aims and experience - common to us all, 
 I'm  sure - are representative of the broad mass of
 putative D users come a 1.0 release?


 
 I'm suggesting that before we can write a good library (standard or  
 otherwise) we need a solid bug-free compiler which compiles everything 
 the  spec suggests it should compile.


Wouldn't we need a solid bug-free specification, before that
compiler can be written ? :-)

I'm afraid they would all have to evolve in parallell,
the way it is now...


But as a part of a release procedure, what you are suggesting
sounds like a reasonable approach... First finalize the spec,
then make sure the compiler follows the spec (e.g. Dstress)
then make sure the standard library is reasonably bug-free
(e.g. by using all of : warnings, contracts, and unittests)

Made a list on the Wiki4D, feel free to add to it:
http://www.prowiki.org/wiki4d/wiki.cgi?HelpDProgress

--anders
Mar 30 2005
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsof7f4jz23k2f5 nrage.netwin.co.nz...

 On Wed, 30 Mar 2005 21:06:38 +1000, Matthew <admin.hat stlsoft.dot.org>  wrote:

 And I have to disagree with Walter's recent assertion (or maybe my  
interpretation of it) that bug fixing in the
 language/compiler is more important than fixing Phobos. I think  unless  and
until D has a good library that has 
 been
 well
 and widely tested, it makes advances in and improvement of the  
language/compiler somewhat moot. To me, they're
 50-50,
 not 80-20 (or 70-30 or whatever figure might be induced from Walter's   post).


 I'm not with you here. In my recent experience, of having tried to  write 
some "library" code using templates and
 mixins, I found that until the  bugs/problems in the compiler are  resolved I
cannot write the "library"  code in 
 the
 way it "should" be written. At best I could produce something  that  worked in
some hackish or ungainly manner. I am
 loath to produce code  for a library that is hackish. It's what is  currently
stopping me from  producing large 
 amounts
 of code in D (that and spare time), every time I  get started I hit  these
bumps in the road.


 Are you suggesting that your aims and experience - common to us all, I'm  sure
- are representative of the broad mass 
 of
 putative D users come a 1.0 release?


 I'm suggesting that before we can write a good library (standard or 
otherwise) we need a solid bug-free compiler 
 which compiles everything the  spec suggests it should compile.


And I'm suggesting that a concurrent approach is more sensible, and far more
likely to lead to success for all 
concerned.


 That's the only really important audience, and if they're not catered  for,
then D
 won't prosper.


 If D reaches 1.0, gets a lot of exposure and is not "ready" that will  likely
harm it's chances of success at least in 
 the short term, long  term.. people are generally willing to give something a
second chance.


Don't follow. Can you rephrase?
Mar 30 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 30 Mar 2005 22:03:08 +1000, Matthew <admin.hat stlsoft.dot.org>  
wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message  
 news:opsof7f4jz23k2f5 nrage.netwin.co.nz...

 On Wed, 30 Mar 2005 21:06:38 +1000, Matthew  
 <admin.hat stlsoft.dot.org>  wrote:

 And I have to disagree with Walter's recent assertion (or maybe my    
 interpretation of it) that bug fixing in the
 language/compiler is more important than fixing Phobos. I think   
 unless  and until D has a good library that has
 been
 well
 and widely tested, it makes advances in and improvement of the    
 language/compiler somewhat moot. To me, they're
 50-50,
 not 80-20 (or 70-30 or whatever figure might be induced from  
 Walter's   post).


 I'm not with you here. In my recent experience, of having tried to   
 write  some "library" code using templates and
 mixins, I found that until the  bugs/problems in the compiler are   
 resolved I cannot write the "library"  code in
 the
 way it "should" be written. At best I could produce something  that   
 worked in some hackish or ungainly manner. I am
 loath to produce code  for a library that is hackish. It's what is   
 currently stopping me from  producing large
 amounts
 of code in D (that and spare time), every time I  get started I hit   
 these bumps in the road.


 Are you suggesting that your aims and experience - common to us all,  
 I'm  sure - are representative of the broad mass
 of
 putative D users come a 1.0 release?


 I'm suggesting that before we can write a good library (standard or   
 otherwise) we need a solid bug-free compiler
 which compiles everything the  spec suggests it should compile.


 And I'm suggesting that a concurrent approach is more sensible, and far  
 more likely to lead to success for all concerned.


I agree that a concurrent or parallel approach is the most  
likely/sensible. However I think that the compiler is holding the library  
back, so needs to be improved *before* we can improve the library.


 That's the only really important audience, and if they're not catered   
 for, then D
 won't prosper.


 If D reaches 1.0, gets a lot of exposure and is not "ready" that will   
 likely harm it's chances of success at least in
 the short term, long  term.. people are generally willing to give  
 something a second chance.


 Don't follow. Can you rephrase?


By 1.0:
1. D needs a solid bug free compiler.
2. D needs a good standard library.

We all seem to agree here. But, we're not talking about being at 1.0 now,  
we're talking about how to get there. Logically it doesn't matter which  
you do first, so long as both are complete before 1.0. Realistically they  
will likely be done concurrently/in parallel (as you say), my experience  



At the present time:
1. D's compiler has bugs, stopping me from writing my/a library.
2. D's standard library is piecemeal.

Regan
Mar 30 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsog6g1f323k2f5 nrage.netwin.co.nz...

 At the present time:
 1. D's compiler has bugs, stopping me from writing my/a library.


Which bug(s) in particular?
Mar 30 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 30 Mar 2005 18:47:11 -0800, Walter <newshound digitalmars.com>  
wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsog6g1f323k2f5 nrage.netwin.co.nz...

 At the present time:
 1. D's compiler has bugs, stopping me from writing my/a library.


 Which bug(s) in particular?


Actually I just discovered today that my bug, might not be a bug, but a  
known limitation, specifically:

http://www.digitalmars.com/d/template.html

Limitations
Templates cannot be used to add non-static members or functions to  
classes. For example:

class Foo
{
     template TBar(T)
     {
T xx;// Error
int func(T) { ... }// Error

static T yy;// Ok
static int func(T t, int y) { ... } // Ok
     }
}

I was trying to use templates to write various operator overloads. See:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3213

I was doing this for a BitArray class to replace bit[] due to the problems  
I had with it, see my post:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3210

Another I found in that 'session' of coding:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3214

On the grand sceme of things my little BitArray library/module/thing  
probably isn't the most important piece of work going on in D at the  
moment. It's just, well, every time I go to write something in D I hit  
these sorts of bugs or limitations. It's disheartening, but, I'm patient  
and not what you'd call serious about development in D (yet) so I can  
handle it.

Regan
Mar 30 2005
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Regan Heath wrote:

 On the grand sceme of things my little BitArray library/module/thing  
 probably isn't the most important piece of work going on in D at the  
 moment. It's just, well, every time I go to write something in D I hit  
 these sorts of bugs or limitations. It's disheartening, but, I'm 
 patient  and not what you'd call serious about development in D (yet) so 
 I can  handle it.


OT: I find that kind of positive. (For everyone except you, that is.)

Point being, you must definitely belong to the group of guys who really 
utilise D and its capabilities to the max. And that is a Good Thing. And 
a plus if I ever hire folks. :-)

As for me, I find myself using constructs and phrases that could mostly 
be used in any C-family language, and only occasionally I use the more 
"modern" features. That's sad. 20 years ago I would've been like you. By 
the time I start regularly using them, others have already had to bang 
their heads into bugs, and cut through the jungle, giving me a sunny 
path at it.

BACK to topic, I always thought that using templates to add the 
non-static stuff was so hard to implement, that Walter was going to do 
it later. I mean, this lack sticks in the eye, and even I have wished to 
use it already (in spite of my "conservative" coding style :-) ).

Off hand, one might say that using inheritance would be better, but it 
isn't. Not at all for this thing anyway.
Mar 31 2005
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Regan Heath wrote:

 On Wed, 30 Mar 2005 18:47:11 -0800, Walter <newshound digitalmars.com>  
 wrote:
 

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsog6g1f323k2f5 nrage.netwin.co.nz...


 At the present time:
 1. D's compiler has bugs, stopping me from writing my/a library.



 Which bug(s) in particular?


 
 
 Actually I just discovered today that my bug, might not be a bug, but a  
 known limitation, specifically:
 
 http://www.digitalmars.com/d/template.html
 
 Limitations
 Templates cannot be used to add non-static members or functions to  
 classes. For example:
 
 class Foo
 {
     template TBar(T)
     {
 T xx;// Error
 int func(T) { ... }// Error
 
 static T yy;// Ok
 static int func(T t, int y) { ... } // Ok
     }
 }
 
 I was trying to use templates to write various operator overloads. See:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3213
 
 I was doing this for a BitArray class to replace bit[] due to the 
 problems  I had with it, see my post:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3210
 
 Another I found in that 'session' of coding:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3214
 
 On the grand sceme of things my little BitArray library/module/thing  
 probably isn't the most important piece of work going on in D at the  
 moment. It's just, well, every time I go to write something in D I hit  
 these sorts of bugs or limitations. It's disheartening, but, I'm 
 patient  and not what you'd call serious about development in D (yet) so 
 I can  handle it.
 
 Regan


Is that even a right (worthy) thing to do?  It sounds like you 
want a language to write a language in, not bad, necesarily, but 
not D's main target.  You could write a Python preprocessor to 
generate all your special cases, and then compile the resultant 
with D.  Of course, this would mean that you needed a D parser, 
so it might be better to start with the publically available D 
parser.

I can understand that this isn't what you want to be doing (I 
wouldn't either), but Walter specifically decided that he didn't 
want to include a pre-processor in D.  Certainly not one like the 
C preprocessor.  (I think that templates are a compromise.)

Personally, I find the idea of templates about as much fun as C 
macros (i.e., not much at all), and think of places where they 
are needed as weaknesses in the underlying language.  OTOH, they 
can definitely be useful at times (but see previous sentence). 
I'm not at all certain that they should be developed into a full 
scale language, complete with recursion.  My real feeling is that 
more of their current functions should be pushed down into the 
basic language.  (See Eiffel's handling of limited generics, 
etc.)  OTOH, this is no doubt due to the amount of time I've been 
spending with Python and Ruby.  I would like to see a languge 
which is to D as Python is to Pyrex (only coming from the other 
direction, of course), but I don't see any development of 
templates as getting us even close to that.

I understand the efficiency gains of static linking at compile 
time, but I frequently desire the flexibility gains of languages 
that bind at run time, and have run time type awareness (again, 
like Python or Ruby).  But I don't see templates as addressing 
this problem.

Generalized templates look to me like a solution that will have 
nearly all of the vices of an interpreted language with few of 
the benefits.  A parsing preprocessor would be a better 
solution...and it should generate D code with the comments 
included to facilitate intelligibility.  (OTOH, I'm not a 
compiler writer.  These are merely my opinions.  But, FWIW, I've 
seen many flops over the years where someone attempted what I 
understand you to be asking for.)
Apr 01 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 01 Apr 2005 16:12:15 -0800, Charles Hixson  
<charleshixsn earthlink.net> wrote:

 Regan Heath wrote:

 On Wed, 30 Mar 2005 18:47:11 -0800, Walter <newshound digitalmars.com>   
 wrote:


 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsog6g1f323k2f5 nrage.netwin.co.nz...


 At the present time:
 1. D's compiler has bugs, stopping me from writing my/a library.



 Which bug(s) in particular?


   Actually I just discovered today that my bug, might not be a bug, but  
 a  known limitation, specifically:
  http://www.digitalmars.com/d/template.html
  Limitations
 Templates cannot be used to add non-static members or functions to   
 classes. For example:
  class Foo
 {
     template TBar(T)
     {
 T xx;// Error
 int func(T) { ... }// Error
  static T yy;// Ok
 static int func(T t, int y) { ... } // Ok
     }
 }
  I was trying to use templates to write various operator overloads. See:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3213
  I was doing this for a BitArray class to replace bit[] due to the  
 problems  I had with it, see my post:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3210
  Another I found in that 'session' of coding:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3214
  On the grand sceme of things my little BitArray library/module/thing   
 probably isn't the most important piece of work going on in D at the   
 moment. It's just, well, every time I go to write something in D I hit   
 these sorts of bugs or limitations. It's disheartening, but, I'm  
 patient  and not what you'd call serious about development in D (yet)  
 so I can  handle it.
  Regan


 Is that even a right (worthy) thing to do?


To what are you referring?
- writing a bitarray class.
- using template/mixin to reuse generic code.
- uwing template/mixin to write opCat operators.


 It sounds like you want a language to write a language in, not bad,  
 necesarily, but not D's main target.


No, I simply want to be able to write a function/process generically and  
apply it where appropriate.

http://www.digitalmars.com/d/overview.html
"Major Goals of D"
"Support multi-paradigm programming, i.e. at a minimum support imperative,  
structured, object oriented, and generic programming paradigms."

Note "generic programming".


 You could write a Python preprocessor to generate all your special  
 cases, and then compile the resultant with D.  Of course, this would  
 mean that you needed a D parser, so it might be better to start with the  
 publically available D parser.

 I can understand that this isn't what you want to be doing (I wouldn't  
 either), but Walter specifically decided that he didn't want to include  
 a pre-processor in D.  Certainly not one like the C preprocessor.  (I  
 think that templates are a compromise.)


I do not want a pre-processor. It is not type safe like templates/mixins.


 Personally, I find the idea of templates about as much fun as C macros  
 (i.e., not much at all)


Templates and mixins have several advantages over macros. Notably type  
checking.


 , and think of places where they are needed as weaknesses in the  
 underlying language.


What other methods are there for generic programming?


 OTOH, they can definitely be useful at times (but see previous  
 sentence). I'm not at all certain that they should be developed into a  
 full scale language, complete with recursion.


In this instance I don't need recursion.


 My real feeling is that more of their current functions should be pushed  
 down into the basic language.  (See Eiffel's handling of limited  
 generics, etc.)


I've never used Eiffel, do you have a link to what you're referring?


 OTOH, this is no doubt due to the amount of time I've been spending with  
 Python and Ruby.  I would like to see a languge which is to D as Python  
 is to Pyrex (only coming from the other direction, of course), but I  
 don't see any development of templates as getting us even close to that.

 I understand the efficiency gains of static linking at compile time, but  
 I frequently desire the flexibility gains of languages that bind at run  
 time, and have run time type awareness (again, like Python or Ruby).   
 But I don't see templates as addressing this problem.


Given that D is statically linked, what solution would you use instead of  
templates to allow generic programming techniques?


 Generalized templates look to me like a solution that will have nearly  
 all of the vices of an interpreted language with few of the benefits.


A generalised templates has all the benefits of generic programming  
centering around code reuse.
Templates and mixins are type safe, and type rigid, unlike some  
interpreted languages which simply convert types on the fly. See Walters  
comment here:

http://www.digitalmars.com/d/overview.html
"Templates. Templates are a way to implement generic programming. Other  
ways include using macros or having a variant data type. Using macros is  
out. Variants are straightforward, but inefficient and lack type checking."

IIRC interpreted languages use "variant" types.


 A parsing preprocessor would be a better solution...and it should  
 generate D code with the comments included to facilitate  
 intelligibility.  (OTOH, I'm not a compiler writer.  These are merely my  
 opinions.  But, FWIW, I've seen many flops over the years where someone  
 attempted what I understand you to be asking for.)


All I am asking for is the ability to use templates and mixins to apply a  
generic function for several types. It's already possible provided the  
method is static, or a stand-alone function.

I'm not a compiler writer either but I can imagine why it's harder to  
implement, probably got something to do with the vtable and in my case  
operator overloading may add more complexity.

Regan
Apr 01 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Regan Heath wrote:

 On Fri, 01 Apr 2005 16:12:15 -0800, Charles Hixson  

 It sounds like you want a language to write a language in, not bad,  
 necesarily, but not D's main target.


 
 No, I simply want to be able to write a function/process generically 
 and  apply it where appropriate.
 
 http://www.digitalmars.com/d/overview.html
 "Major Goals of D"
 "Support multi-paradigm programming, i.e. at a minimum support 
 imperative,  structured, object oriented, and generic programming 
 paradigms."
 
 Note "generic programming".
 

 You could write a Python preprocessor to generate all your special  
 cases, and then compile the resultant with D.  Of course, this would  
 mean that you needed a D parser, so it might be better to start with 
 the  publically available D parser.

 I can understand that this isn't what you want to be doing (I 
 wouldn't  either), but Walter specifically decided that he didn't want 
 to include  a pre-processor in D.  Certainly not one like the C 
 preprocessor.  (I  think that templates are a compromise.)


 
 I do not want a pre-processor. It is not type safe like templates/mixins.
 

 Personally, I find the idea of templates about as much fun as C 
 macros  (i.e., not much at all)


 
 Templates and mixins have several advantages over macros. Notably type  
 checking.
 

 , and think of places where they are needed as weaknesses in the  
 underlying language.


 
 What other methods are there for generic programming?
 

 OTOH, they can definitely be useful at times (but see previous  
 sentence). I'm not at all certain that they should be developed into 
 a  full scale language, complete with recursion.


 
 In this instance I don't need recursion.
 

 My real feeling is that more of their current functions should be 
 pushed  down into the basic language.  (See Eiffel's handling of 
 limited  generics, etc.)


 
 I've never used Eiffel, do you have a link to what you're referring?
 

 OTOH, this is no doubt due to the amount of time I've been spending 
 with  Python and Ruby.  I would like to see a languge which is to D as 
 Python  is to Pyrex (only coming from the other direction, of course), 
 but I  don't see any development of templates as getting us even close 
 to that.

 I understand the efficiency gains of static linking at compile time, 
 but  I frequently desire the flexibility gains of languages that bind 
 at run  time, and have run time type awareness (again, like Python or 
 Ruby).   But I don't see templates as addressing this problem.


 
 
 Given that D is statically linked, what solution would you use instead 
 of  templates to allow generic programming techniques?
 

 Generalized templates look to me like a solution that will have 
 nearly  all of the vices of an interpreted language with few of the 
 benefits.




Done wrong, it might.

I want a template system that is "complete", coherent, logical, 
flexible, and simple both logically and to use.


 A generalised templates has all the benefits of generic programming  
 centering around code reuse.
 Templates and mixins are type safe, and type rigid, unlike some  
 interpreted languages which simply convert types on the fly. See 
 Walters  comment here:
 
 http://www.digitalmars.com/d/overview.html
 "Templates. Templates are a way to implement generic programming. Other  
 ways include using macros or having a variant data type. Using macros 
 is  out. Variants are straightforward, but inefficient and lack type 
 checking."
 
 IIRC interpreted languages use "variant" types.


That, or implicit casts (or conversions) whenever needed. Depending on 
the language. Which all of course are slower than not doing it. And, the 
programmers using these languages tend to rely heavily on this, 
exacerbating this slowness.


 A parsing preprocessor would be a better solution...and it should  
 generate D code with the comments included to facilitate  
 intelligibility.  (OTOH, I'm not a compiler writer.  These are merely 
 my  opinions.  But, FWIW, I've seen many flops over the years where 
 someone  attempted what I understand you to be asking for.)




That's where I seem to be headed. Although my dream is that (IF) the 
syntax and functionality somehow get accepted, all that would be somehow 
merged into the compiler, to gain robustness, again not needing "a 
preporcessor", and if it can be done without slowing compiling too much.

And if not, then I just hope it will gain popularity enough to be 
adopted as "a genuine part of 'D'". But only if it becomes powerful 
enough to "do things not possible in other language/preprocessor 
combinations"! If not, then we'll only use it for trying out possible 
suggestions for new syntax, etc., and not distribute it widely.


 All I am asking for is the ability to use templates and mixins to apply 
 a  generic function for several types. It's already possible provided 
 the  method is static, or a stand-alone function.
 
 I'm not a compiler writer either but I can imagine why it's harder to  
 implement, probably got something to do with the vtable and in my case  
 operator overloading may add more complexity.
Apr 02 2005
prev sibling parent bobef <bobef_member pathlink.com> writes:
In article <d2frkv$2ns2$1 digitaldaemon.com>, Walter says...

"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsog6g1f323k2f5 nrage.netwin.co.nz...

 At the present time:
 1. D's compiler has bugs, stopping me from writing my/a library.


Which bug(s) in particular?


The GC aligment or whatever it was ;]
Mar 31 2005
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
David Barrett wrote:

 Ok, sounds like the tally is as follows:
 
 [For renaming Phobos to "D Standard Library"] J C Calvarese, David Barrett


To call it the "D Standard Library" isn't even really renaming it. It's 
just calling it what it is.


 [For renaming Phobos, but to something else (Diesel)] Derek Parnell, Matthew


Actually, I like Diesel as a name, too. (Even though the other 
pro-"Diesel" commentators were most likely joking.)


 [Ambivalent] Ben Hinkle


And I don't think Phobos is an awful name, so I have a pretty ambivalent 
position.


 [Against renaming] David L. Davis


Phobos definitely makes sense from a historical perspective.

All-in-all it sounds like a hung jury. Perhaps we should move on to a 
less "controversial" topic? ;)

-- 
jcc7
http://jcc_7.tripod.com/d/
Mar 29 2005
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message
news:d2d663$310n$1 digitaldaemon.com...

 David Barrett wrote:

 Ok, sounds like the tally is as follows:

 [For renaming Phobos to "D Standard Library"] J C Calvarese, David Barrett


 To call it the "D Standard Library" isn't even really renaming it. It's just
calling it what it is.


Indeed.


 [For renaming Phobos, but to something else (Diesel)] Derek Parnell, Matthew


 Actually, I like Diesel as a name, too. (Even though the other pro-"Diesel"
commentators were most likely joking.)


I wasn't joking that I like the name, and I don't think Derek was either. The
thing I wasn't taking seriously was the 
import given to this issue by David.


 [Ambivalent] Ben Hinkle


 And I don't think Phobos is an awful name, so I have a pretty ambivalent
position.


 [Against renaming] David L. Davis


 Phobos definitely makes sense from a historical perspective.

 All-in-all it sounds like a hung jury. Perhaps we should move on to a less
"controversial" topic? ;)


As someone with little/no knowledge of Ares, I want to hear from _this_
community whether people who care about 
contributing to a material jump in quality of D's libraries (DSL included)
should persevere here and try to push reform 
of Phobos, or should give up and move over to DSource and work on Ares.

Furthermore, if it's the latter, is there any structure/agreement/plan for how
the presumed advances in Ares would be 
married back into D(MD) before 1.0? (Naturally, if the D language improves to a
merchantable level, and the D compiler 
improves to a merchantable level, and Ares is at a merchantable level, and the
library that ships with the 
language/compiler is at the current scrappy state, there's going to be huge WTF
from potential D users.)
Mar 29 2005
parent Sean Kelly <sean f4.ca> writes:
In article <d2d7hh$jf$1 digitaldaemon.com>, Matthew says...

As someone with little/no knowledge of Ares, I want to hear from _this_
community whether people who care about 
contributing to a material jump in quality of D's libraries (DSL included)
should persevere here and try to push reform 
of Phobos, or should give up and move over to DSource and work on Ares.


I've (quite obviously) decided to go the Ares route.  While I like the official
stamp of approval of having something in Phobos, contributing to Phobos often
feels like pissing in the wind.  It's a crapshoot whether a submission will be
accepted and how long it will take.  I understand that a lot of this is because
Walter is busy with other things, but I'm impatient :)


Furthermore, if it's the latter, is there any structure/agreement/plan for how
the presumed advances in Ares would be 
married back into D(MD) before 1.0?


Not really.  I'm hoping that if Ares shapes up nicely then it will be accepted.
But if it isn't then I plan to use it anyway.  Either way, if D is standardized
then Phobos will undergo a similar process that Ares is now, so perhaps Ares
could be considered the Boost of the D world :p


Sean
Mar 30 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
J C Calvarese wrote:


 Actually, I like Diesel as a name, too. (Even though the other 
 pro-"Diesel" commentators were most likely joking.)


Great, then we can have one library called "DSL" and one called "VIN".
And change the language name to "Riddick" :-) (as in the Chronicles of)

Put me in the "whatever" category, if you must categorize us people...
I'll be dusting off all my patches, and emailing them to Walter instead.

--anders
Mar 29 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 29 Mar 2005 19:04:35 -0800, David Barrett wrote:


 [For renaming Phobos, but to something else (Diesel)] Derek Parnell


It was a joke, David, though its growing on me. Truthfully, I don't really
give a dam about the name. Its the content and structure that is much,
much, more important. I'm not greatly swayed by the names people give to
things, and the "Phobos" moniker has never brought to my mind the idea of a
toy language or library. Actually, I think its rather clever. But like I
said, call it whatever, and it'll still be its contents rather than its
name.

-- 
Derek
Melbourne, Australia
30/03/2005 1:59:05 PM
Mar 29 2005
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:flusmieh5ey1$.1vupt1onsq15r$.dlg 40tude.net...

 It was a joke, David, though its growing on me. Truthfully, I don't really
 give a dam about the name. Its the content and structure that is much,
 much, more important. I'm not greatly swayed by the names people give to
 things, and the "Phobos" moniker has never brought to my mind the idea of


a

 toy language or library. Actually, I think its rather clever. But like I
 said, call it whatever, and it'll still be its contents rather than its
 name.


I like the name Phobos. I don't think it's cute, certainly it's less cute
than 'Boost' which is a silly name that hasn't impeded it in the slightest.
Nobody thinks Boost is a toy. I've seen endless 3 letter acronyms, and would
like to just be a bit more creative than "DSL" or other boring acronym.

I've had thoughts of naming all D libraries after moons. <g>

I like "Diemos" very much as the etc library.

"Java" is another name for a major product that is not impeded by its name.

"Euphoria", well, it sounds like a designer drug. I wouldn't be surprised if
it is held back by that name.

I agree that what the library does is far more important than its name.
Mar 30 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


 "Java" is another name for a major product that is not impeded by its name.


"A" major product? These days, Sun are using the Java name for ANYTHING!

- Java 2 Platform, Standard Edition (platform and language)
- Java 2 Platform, Enterprise Edition
- Java 2 Platform, Micro Edition

- Sun Java System Web Server (briefly known as Sun ONE)
- Sun Java System Directory Server
- Sun Java System Portal Server
- Sun Java System Web Proxy Server

- Sun Java System Active Server Pages (an ASP emulator !)

- Sun Java Desktop System, Release 2 (Linux distribution)

- Sun Java Workstation W1100z (a "Java Actual Machine" ?)
- Sun Java Workstation W2100z

No, I am not making these up... They are. (on a daily basis, feels like)


Then again, people "on the street" can't separate Java and JavaScript...
(which probably also have a lot to do with old buggy web page applets ?)

So I'm not sure that Java sets a very good example of non-confusion ?

--anders
Mar 30 2005
parent "Walter" <newshound digitalmars.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d2dutv$p1n$1 digitaldaemon.com...

 Walter wrote:


 "Java" is another name for a major product that is not impeded by its




name.

 So I'm not sure that Java sets a very good example of non-confusion ?


I didn't mean it that way, just that naming a language after a country seems
to have worked fine for Sun.
Mar 30 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 30 Mar 2005 01:46:07 -0800, Walter wrote:


 "Derek Parnell" <derek psych.ward> wrote in message
 news:flusmieh5ey1$.1vupt1onsq15r$.dlg 40tude.net...

 It was a joke, David, though its growing on me. Truthfully, I don't really
 give a dam about the name. Its the content and structure that is much,
 much, more important. I'm not greatly swayed by the names people give to
 things, and the "Phobos" moniker has never brought to my mind the idea of


 a

 toy language or library. Actually, I think its rather clever. But like I
 said, call it whatever, and it'll still be its contents rather than its
 name.


 
 I like the name Phobos. I don't think it's cute, certainly it's less cute
 than 'Boost' which is a silly name that hasn't impeded it in the slightest.
 Nobody thinks Boost is a toy. I've seen endless 3 letter acronyms, and would
 like to just be a bit more creative than "DSL" or other boring acronym.


I'm sorry...did I use the word "cute" somewhere? I don't think so. Did I
imply that I thought D/Phobos was a toy? I don't think so. In fact, I said
the opposite! Did I suggest a TLA, eg. DSL? I don't think so. Are you
reading my words or making my words? I'm now very confused.


 I've had thoughts of naming all D libraries after moons. <g>

 I like "Diemos" very much as the etc library.


Me too, though I spell it differently. There are heaps of Solar moons out
there so we shouldn't run out of names too quickly. I guess the module for
input-output functions should be called Io ;-)
 

 "Java" is another name for a major product that is not impeded by its name.


Where *did* that name come from. I suppose they couldn't really have used
Sumatra, or Suluwasi, or Irian Jaya, or Kalamantan, ...


 "Euphoria", well, it sounds like a designer drug. I wouldn't be surprised if
 it is held back by that name.


You know, I've heard a lot of people say or imply that, but I have never
actually thought that. In fact, I can't see the connection at all - must be
my innocent upbringing ;-) Actually its being held back because its
controlled by a single person who is extremely slow to upgrade it, refuses
to consider anything that goes against his programming philosophy, and
refuses all attempts at outside assistance - but I could be totally wrong.


 I agree that what the library does is far more important than its name.


Nice.

-- 
Derek Parnell
Melbourne, Australia
30/03/2005 10:14:50 PM
Mar 30 2005
next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
Derek Parnell wrote:

 On Wed, 30 Mar 2005 01:46:07 -0800, Walter wrote:



"Java" is another name for a major product that is not impeded by its name.


 
 
 Where *did* that name come from. I suppose they couldn't really have used
 Sumatra, or Suluwasi, or Irian Jaya, or Kalamantan, ...
 


Originally, it was called Oak internally at Sun. I read somewhere once 
that, when they decided to release it to the public, there was a meeting 
to brainstorm a new name for the language. Someone had a coffee cup from 
a local coffee shop the team often visited, and the name of the shop 
contained the word "Java".
Mar 30 2005
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:1nb20obbzmw4h$.1sphbdak9p50o.dlg 40tude.net...

 On Wed, 30 Mar 2005 01:46:07 -0800, Walter wrote:

 I like the name Phobos. I don't think it's cute, certainly it's less




cute

 than 'Boost' which is a silly name that hasn't impeded it in the




slightest.

 Nobody thinks Boost is a toy. I've seen endless 3 letter acronyms, and




would

 like to just be a bit more creative than "DSL" or other boring acronym.


 I'm sorry...did I use the word "cute" somewhere? I don't think so. Did I
 imply that I thought D/Phobos was a toy? I don't think so. In fact, I said
 the opposite! Did I suggest a TLA, eg. DSL? I don't think so. Are you
 reading my words or making my words? I'm now very confused.


I apologize for making the insinuation. I was essentially replying to all
the posts in this thread, not just yours.
Mar 30 2005
prev sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <d2dsn9$n7k$1 digitaldaemon.com>, Walter says...


[...]

 I've seen endless 3 letter acronyms, and would
like to just be a bit more creative than "DSL" or other boring acronym.

I've had thoughts of naming all D libraries after moons. <g>

I like "Diemos" very much as the etc library.

"Java" is another name for a major product that is not impeded by its name.


And don't forget "swing". Swing was the internal code name for the project, and
at some point in time it was renamed to "JFC". Still today nobody uses JFC and
everybody keeps calling it swing.

[...]

I agree that what the library does is far more important than its name.


Me too.

Ciao



 Mar 31 2005



  parent reply "David Barrett" <dbarrett quinthar.com>  writes:


"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message 
news:d2go14$pno$1 digitaldaemon.com...

 In article <d2dsn9$n7k$1 digitaldaemon.com>, Walter says...

"Java" is another name for a major product that is not impeded by its 
name.


 And don't forget "swing". Swing was the internal code name for the 
 project, and
 at some point in time it was renamed to "JFC". Still today nobody uses JFC 
 and
 everybody keeps calling it swing.


I don't think those are fair comparisons because "java" and "swing" both use 
the same word as the name of the technology, and the name of the namespace:




Thus it's to be expected that nobody calls Swing JFC, because no Swing 
programmer actually types, reads about, or discusses the letters "JFC". 
There is no class named JFC.  The compiler doesn't recognize JFC.  It's 
"swing" because the compiler, class structure, and namespace all agree it's 
called Swing.  Even the closest the documentation gets to calling it "JFC" 
is "JFC/Swing".

In fact, I think you've argued my *exact* point in reverse.  Phobos is to 
JFC as STD is to Swing.

So if your point is that "successful technologies can have cool names", I'll 
grant that.

But you've only reinforced my core notion that "successful technologies have 
*one* name that is used by programmer and compiler alike".  Same goes for 
Boost, Xiph, and others (STL is a bit funky, but at least it has the word 
"standard" in the name).

I'm not totally against Phobos.  I'm just totally for a sensible namespace 
where everything is called by it's right name.  If the right name is Phobos, 
let's call it that.  If the right name is STD, then great.  But my mind is 
grappling with how they're both right names, at the same time.

-david



 Mar 31 2005



  parent reply "Ben Hinkle" <ben.hinkle gmail.com>  writes:


 I'm not totally against Phobos.  I'm just totally for a sensible namespace 
 where everything is called by it's right name.  If the right name is 
 Phobos, let's call it that.  If the right name is STD, then great.  But my 
 mind is grappling with how they're both right names, at the same time.


Phobos (the library) includes std, etc and internal (the packages). 



 Mar 31 2005



  parent reply J C Calvarese <jcc7 cox.net>  writes:


Ben Hinkle wrote:

I'm not totally against Phobos.  I'm just totally for a sensible namespace 
where everything is called by it's right name.  If the right name is 
Phobos, let's call it that.  If the right name is STD, then great.  But my 
mind is grappling with how they're both right names, at the same time.


 
 
 Phobos (the library) includes std, etc and internal (the packages). 


Except that non-standard things can also supposedly go in etc and it's 
somewhat debatable whether the contents of internal are
(1) actually part of the standard library
or
(2) internal compiler thingees that if missing would cause the compiler 
to explode.

Sometimes it's hard to tell where the compiler ends and the library 
begins. The original Mars and Phobos don't have this problem (the black 
stuff in between makes it pretty obvious).

I hope my confusion isn't contagious. Everybody be sure to wash your hands.

-- 
jcc7
http://jcc_7.tripod.com/d/



 Mar 31 2005



 next sibling parent reply "David Barrett" <dbarrett quinthar.com>  writes:


"J C Calvarese" <jcc7 cox.net> wrote in message 
news:d2ila5$2rle$1 digitaldaemon.com...

 Ben Hinkle wrote:

 Phobos (the library) includes std, etc and internal (the packages).


 Except that non-standard things can also supposedly go in etc and it's 
 somewhat debatable whether the contents of internal are
 (1) actually part of the standard library
 or
 (2) internal compiler thingees that if missing would cause the compiler to 
 explode.


Hence my confusion.  In my ideal world, "phobos" would be a formal package, 
and not the nickname (true name, alternate name, etc.) of the "std" package. 
In this world, the package hierarchy would look like:








It would be patently obvious whether "etc" was "in" or "out" of Phobos.  The 
answer would be "out".

In fact, I think it'd be even better if the package hierarchy were:










Then "std" could be defined as "the minimum set of modules required to 
compile a standalone application".  Phobos could be defined as "Official, 
core modules dependent only on 'std'".  Deimos could be defined as 
"Unofficial modules proposed for inclusion in Phobos, dependent only on 
Phobos and std".  And finally, "etc" could be "anything else".

As a programmer, this would give me confidence.  If I'm doing embedded 
programming, I just look at "std" and never worry about anything else.  If 
I'm risk-adverse, I just use Phobos and "std".  If I'm on the edge, I can 
use Deimos, with reasonable confidence it'll be around for a while.  And if 
I'm on the bleeding edge, I can dabble with "etc".

Unfortunately, I have no such confidence today because everything is lumped 
together under the vague notion of "Phobos".  I have no idea what's solid, 
what's proposed, what I need, and what's going to be gone tomorrow.

-david 



 Mar 31 2005



  parent reply Georg Wrede <georg.wrede nospam.org>  writes:


David Barrett wrote:

 "J C Calvarese" <jcc7 cox.net> wrote in message 
 news:d2ila5$2rle$1 digitaldaemon.com...
 

Ben Hinkle wrote:


Phobos (the library) includes std, etc and internal (the packages).


Except that non-standard things can also supposedly go in etc and it's 
somewhat debatable whether the contents of internal are
(1) actually part of the standard library
or
(2) internal compiler thingees that if missing would cause the compiler to 
explode.




I really think that what David wrote here below, should be taken seriously!

Even more so, because those very familiar and used to the current 
"state" of Phobos et al., _should_ have a hard time seeing the issue 
like David puts it here. (Precisely _because_ they are too familiar, not 
for being thick or anything.)


 Hence my confusion.  In my ideal world, "phobos" would be a formal package, 
 and not the nickname (true name, alternate name, etc.) of the "std" package. 
 In this world, the package hierarchy would look like:
 






 
 It would be patently obvious whether "etc" was "in" or "out" of Phobos.  The 
 answer would be "out".
 
 In fact, I think it'd be even better if the package hierarchy were:
 








 
 Then "std" could be defined as "the minimum set of modules required to 
 compile a standalone application".  Phobos could be defined as "Official, 
 core modules dependent only on 'std'".  Deimos could be defined as 
 "Unofficial modules proposed for inclusion in Phobos, dependent only on 
 Phobos and std".  And finally, "etc" could be "anything else".
 
 As a programmer, this would give me confidence.  If I'm doing embedded 
 programming, I just look at "std" and never worry about anything else.  If 
 I'm risk-adverse, I just use Phobos and "std".  If I'm on the edge, I can 
 use Deimos, with reasonable confidence it'll be around for a while.  And if 
 I'm on the bleeding edge, I can dabble with "etc".
 
 Unfortunately, I have no such confidence today because everything is lumped 
 together under the vague notion of "Phobos".  I have no idea what's solid, 
 what's proposed, what I need, and what's going to be gone tomorrow.
 
 -david 
 
 





 Apr 01 2005



  parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org>  writes:


Since inconsistency is bad, and Phobos feels like a big hodge-podge that is
very inconsistent, I'd be open to a 
rationalisation of module names as part of a wholesale rationalisation.
However, I don't believe the name 
rationalisation on its own is worth anything, since it'd address only a tiny
portion of the issues, and it'd also paint 
a dissembling veneer of completedness over the rest.



"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:424D4C90.5040808 nospam.org...

 David Barrett wrote:

 "J C Calvarese" <jcc7 cox.net> wrote in message
news:d2ila5$2rle$1 digitaldaemon.com...


Ben Hinkle wrote:


Phobos (the library) includes std, etc and internal (the packages).


Except that non-standard things can also supposedly go in etc and it's somewhat
debatable whether the contents of 
internal are
(1) actually part of the standard library
or
(2) internal compiler thingees that if missing would cause the compiler to
explode.




 I really think that what David wrote here below, should be taken seriously!

 Even more so, because those very familiar and used to the current "state" of
Phobos et al., _should_ have a hard time 
 seeing the issue like David puts it here. (Precisely _because_ they are too
familiar, not for being thick or 
 anything.)


 Hence my confusion.  In my ideal world, "phobos" would be a formal package,
and not the nickname (true name, 
 alternate name, etc.) of the "std" package. In this world, the package
hierarchy would look like:








 It would be patently obvious whether "etc" was "in" or "out" of Phobos.  The
answer would be "out".

 In fact, I think it'd be even better if the package hierarchy were:










 Then "std" could be defined as "the minimum set of modules required to compile
a standalone application".  Phobos 
 could be defined as "Official, core modules dependent only on 'std'".  Deimos
could be defined as "Unofficial modules 
 proposed for inclusion in Phobos, dependent only on Phobos and std".  And
finally, "etc" could be "anything else".

 As a programmer, this would give me confidence.  If I'm doing embedded
programming, I just look at "std" and never 
 worry about anything else.  If I'm risk-adverse, I just use Phobos and "std". 
If I'm on the edge, I can use Deimos, 
 with reasonable confidence it'll be around for a while.  And if I'm on the
bleeding edge, I can dabble with "etc".

 Unfortunately, I have no such confidence today because everything is lumped
together under the vague notion of 
 "Phobos".  I have no idea what's solid, what's proposed, what I need, and
what's going to be gone tomorrow.

 -david 







 Apr 01 2005



  parent  Georg Wrede <georg.wrede nospam.org>  writes:


Matthew wrote:

 Since inconsistency is bad, and Phobos feels like a big hodge-podge
 that is very inconsistent, I'd be open to a rationalisation of module
 names as part of a wholesale rationalisation. However, I don't
 believe the name rationalisation on its own is worth anything, since
 it'd address only a tiny portion of the issues, and it'd also paint a
 dissembling veneer of completedness over the rest.


Yes. It can be argued that some of the frustration appearing about the 
name Phobos, can actually be attributed to the need to rationalize the 
entire "standard library".

Ideally, the "standard library" (or what the *** everybody wants to call 
it), should be consistent, have a structure that everybody (especially 
the professionals -- but new to D) would understand off-hand and 
intuitively, and that any Names appearing in this context should not be 
distractions.

This makes a bigger diffenence than any of "us insiders" can possibly 
imagine.



 Apr 01 2005



prev sibling  parent  "Ben Hinkle" <ben.hinkle gmail.com>  writes:


"J C Calvarese" <jcc7 cox.net> wrote in message 
news:d2ila5$2rle$1 digitaldaemon.com...

 Ben Hinkle wrote:

I'm not totally against Phobos.  I'm just totally for a sensible 
namespace where everything is called by it's right name.  If the right 
name is Phobos, let's call it that.  If the right name is STD, then 
great.  But my mind is grappling with how they're both right names, at 
the same time.



 Phobos (the library) includes std, etc and internal (the packages).


 Except that non-standard things can also supposedly go in etc and it's 
 somewhat debatable whether the contents of internal are
 (1) actually part of the standard library
 or
 (2) internal compiler thingees that if missing would cause the compiler to 
 explode.


Where's the confusion? Phobos is the run-time library. Looking at the web 
site I see either the phrase "standard runtime library" or "runtime 
library". The runtime library contains a bunch of packages. People sometimes 
refer to phobos as the "standard library" but that's because the most used 
part of the runtime library is the standard package.


 Sometimes it's hard to tell where the compiler ends and the library 
 begins. The original Mars and Phobos don't have this problem (the black 
 stuff in between makes it pretty obvious).


That's true with any language. In Java the runtime is called "rt.jar" and it 
contains the java (including java.lang), org, com.sun, sun, javax packages 
and probably more.



 Apr 01 2005



prev sibling  parent  "Carlos Santander B." <csantander619 gmail.com>  writes:


Derek Parnell wrote:

 Truthfully, I don't really
 give a dam about the name. Its the content and structure that is much,
 much, more important. I'm not greatly swayed by the names people give to
 things, and the "Phobos" moniker has never brought to my mind the idea of a
 toy language or library. Actually, I think its rather clever. But like I
 said, call it whatever, and it'll still be its contents rather than its
 name.
 


Totally agree.

_______________________
Carlos Santander Bernal



 Mar 30 2005



prev sibling next sibling parent reply "David Barrett" <dbarrett quinthar.com>  writes:


As for the final tally, it sounds like nobody's passionate for changing the 
name except for me.  That said, nobody's passionately (mildly, but not 
passionately) against changing it either.  The bulk just don't seem to care 
one way or the other.

So Walter, if I just went ahead and updated all the documentation and 
library code to standardize on the term "D Standard Library", would you 
integrate that with the main tree?

To repeat my reasoning, I think that Phobos is a great codename, and should 
serve its place in history.  But codenames, by definition, are not public 
names.  By referring to the D standard library by codename (or worse, with a 
variety of names), it confuses new users and reinforces the notion that D is 
messy and incomplete.



place to start in helping D along in its path to greatness.

-david



 Mar 30 2005



 next sibling parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


David Barrett wrote:


 So Walter, if I just went ahead and updated all the documentation and 
 library code to standardize on the term "D Standard Library", would you 
 integrate that with the main tree?


The current documentations says : "Phobos, D Runtime Library".
http://www.digitalmars.com/d/phobos.html


When (if) the runtime library (internal) and gc and the standard library
have been separated, then "D Standard Library" is probably a good name
to use for the documentation of the classes within the "std" dir tree...

The regular enduser and newcomer probably won't care about the runtime.
They will, however, care about the standard library for the D language.
Especially the documentation thereof... (need I say Doxygen once again?)


There has been work done in the Ares project, to separate the three:
http://www.dsource.org/forums/viewtopic.php?t=378
(the idea is to cut out the "rt" and the "gc" from the "std" library)

So me too think it's a good idea to rename Phobos the "Standard Library"
(I'm not sure if the runtime and trashman need any special code names ?
If they do, I submit "Mariner" and "Viking". No idea which is which :-))


For *special* uses, the standard library shouldn't even be required...
(i.e. the D runtime should be enough to compile a program, without std)

--anders



 Mar 30 2005



prev sibling next sibling parent reply Mike Parker <aldacron71 yahoo.com>  writes:


David Barrett wrote:

 As for the final tally, it sounds like nobody's passionate for changing the 
 name except for me.  That said, nobody's passionately (mildly, but not 
 passionately) against changing it either.  The bulk just don't seem to care 
 one way or the other.
 
 So Walter, if I just went ahead and updated all the documentation and 
 library code to standardize on the term "D Standard Library", would you 
 integrate that with the main tree?
 
 To repeat my reasoning, I think that Phobos is a great codename, and should 
 serve its place in history.  But codenames, by definition, are not public 
 names.  By referring to the D standard library by codename (or worse, with a 
 variety of names), it confuses new users and reinforces the notion that D is 
 messy and incomplete.
 


 place to start in helping D along in its path to greatness.
 
 -david


I guess then I should speak up, as I like the name Phobos. I would very 
much hate to see it named to 'D Standard Library', even if you did 
somehow persuade Walter to do so. I've never viewed Phobos as a 
codename, but as the *real* name. That is, in fact, how it is presented 
in the documentation. And did Walter ever say he intended it to be a 
'codename'? Anyway, I disagree completely with your reasoning and see 
the name Phobos as a boon rather than a hindrance. It adds a bit of 
pinache to things.



 Mar 30 2005



  parent reply "David Barrett" <dbarrett quinthar.com>  writes:


"Mike Parker" <aldacron71 yahoo.com> wrote in message 
news:d2e013$qls$1 digitaldaemon.com...

 I guess then I should speak up, as I like the name Phobos. I would very 
 much hate to see it named to 'D Standard Library', even if you did somehow 
 persuade Walter to do so. I've never viewed Phobos as a codename, but as 
 the *real* name. That is, in fact, how it is presented in the 
 documentation. And did Walter ever say he intended it to be a 'codename'? 
 Anyway, I disagree completely with your reasoning and see the name Phobos 
 as a boon rather than a hindrance. It adds a bit of pinache to things.


That's a fair comment.  Would you support renaming the "std" namespace to be 
"phobos"?

I think it's that discrepancy that bothers me the most.  It's like "Hi, my 
name is David, spelled B-O-B".

I'll admit, "Phobos" doesn't excite me.  But I'd be much happier if the name 
of the package and, well, the name of the package were the same.

Given that changing "std" would break a lot of code and changing "Phobos" 
would break almost none, I favor changing Phobos, though I'd be happy with 
either.

Changing neither leaves D in what I believe is a confusing and 
unprofessional state.

-david 



 Mar 30 2005



 next sibling parent reply Trevor Parscal <Trevor_member pathlink.com>  writes:


I am, for the record, despite the categoriztion of my view in a recent post.

FOR changing the name Phobos to something else.
FOR keeping std as the namespace of the Standard Library
FOR reorganizing things, a bit more structure
and
FOR getting rid of the annoying package/module problem

This last one was the most dissapointing thing to me when learning D. I feel
like my code has to be organized in a way that I do not prefer, and when a
language takes that freedom from a programmer, that is a bad thing.

I know we all just deal with it, but it can cause annoying problems, and I must
suggest some alternative ideas of handling packages and modules.

Example Structure

[/] source
---[-] string.d
---[/] string
------[-] convert.d

1: Automatic recursive module inclusion.
This would cause "import string;" to import string.d and the contents of the
string package, like convert.d. If you only wanted string.d, you would be out of
luck, this is the downside...

2: Manual recursive module inclusion.
This gives you more control, but requires new language. For instance, "import
string;" would only import the string.d module, but "import.string.*;" could
grab the contents of the string package. Also, you can acutally say "import
string.convert;" which you cant do with D right now, which sucks.

3: Clarification of module vs package
This would make it so you are using a different manner to include just the
string module (string.d) or the entire string package (including string.d if
present). So, "import string;" would include just the module, and "imports
string;" does everything. I guess the naming could be different. Depends on
whether you see "import module" as a command like "do this" or a definition like
"type name". If the latter is your opinion, than imports makes sense, because it
is the plurar version of import, however as a command, it's confusing, which is
bad.

Other ideas on how to solve this problem are out there, and we should look at
them too. All I know is it's really annoying to have to name things the way I
have to. I think it breaks the object orientation concept when you cant have a
module have submodues (string = module and string.convert = module)..

Reorganizing things of course makes things break, but lets do it NOW while the
code we are breaking is minimal.

Also, ideas other than phobos are not a bad idea. I mean, if you don't think
that the D Standard Library being in the std namespace makes sense, that you
could come up with SOMETHING more professional than Phobos. Naming things IS
important, even though it doesn't change the way the code works. I agree that
Java's name stuck, but Java is at least a word in most people's vocabulary.

Finally, this forum system is pretty lame. I am glad it is here, but honestly,
how hard is it to grab a copy of PhpBB? If Digital Mars doesn't want to make the
upgrade, I would be glad to host a modern board on my own server... And if you
think this board is fine, and wonder why I think it is lame, here are my
complaints, that would all be fixed if you used a modern (FREE AND OPEN SOURCE)
board like PhpBB.

1: Posts take too long to show up
2: Posts are not organized by topic
3: The interface is ugly
4: Users cannot register and settings/identity be recalled
5: No search tools

PLEASE considder using a modern board! It would really help get questions
answered, things decided, a community grown.

Thanks,
Trevor Parscal
www.trevorparscal.com



 Mar 30 2005



 next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Trevor Parscal wrote:


 Finally, this forum system is pretty lame. I am glad it is here, but honestly,
 how hard is it to grab a copy of PhpBB? If Digital Mars doesn't want to make
the
 upgrade, I would be glad to host a modern board on my own server...


[...]

 PLEASE considder using a modern board! It would really help get questions
 answered, things decided, a community grown.


This is not a web forum but a newsgroup. It's still old and such, but
if you use a newsreader like Mozilla Thunderbird it's not *that* lame.

The stuff on http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D
is more like what "webmail" is to regular email, if you see what I mean.


There's a "modern" forum on http://www.dsource.org/forums/
(but be aware that a lot of us old-timers prefer newsgroups
and mailing lists over web forums, just like we prefer email
over chat messages and other such newfangled inventions ;-) )

--anders



 Mar 30 2005



  parent  Trevor Parscal <Trevor_member pathlink.com>  writes:


There's a "modern" forum on http://www.dsource.org/forums/
(but be aware that a lot of us old-timers prefer newsgroups
and mailing lists over web forums, just like we prefer email
over chat messages and other such newfangled inventions ;-) )

--anders


Thanks for the link. I will take a look at Thunderbird.

Thanks,
Trevor Parscal
www.trevorparscal.com



 Mar 30 2005



prev sibling next sibling parent  Sean Kelly <sean f4.ca>  writes:


In article <d2e710$11s8$1 digitaldaemon.com>, Trevor Parscal says...

Finally, this forum system is pretty lame. I am glad it is here, but honestly,
how hard is it to grab a copy of PhpBB? If Digital Mars doesn't want to make the
upgrade, I would be glad to host a modern board on my own server... And if you
think this board is fine, and wonder why I think it is lame, here are my
complaints, that would all be fixed if you used a modern (FREE AND OPEN SOURCE)
board like PhpBB.


Perhaps I'm from the old school in this regard, but I love usenet.  And some
clients, web and otherwise, are quite good.  Check out groups.google.com to see
a good web client.  In fact, petition Google to add the digitalmars.* to its
list.  I've already done so and plan to do so again.


Sean



 Mar 30 2005



prev sibling next sibling parent reply "Walter" <newshound digitalmars.com>  writes:


"Trevor Parscal" <Trevor_member pathlink.com> wrote in message
news:d2e710$11s8$1 digitaldaemon.com...

 FOR getting rid of the annoying package/module problem

 This last one was the most dissapointing thing to me when learning D. I


feel

 like my code has to be organized in a way that I do not prefer, and when a
 language takes that freedom from a programmer, that is a bad thing.


I read your post, but I just didn't understand what the problem you're
seeing is. Can you please try again?



 Mar 30 2005



  parent reply "Carlos Santander B." <csantander619 gmail.com>  writes:


Walter wrote:

 "Trevor Parscal" <Trevor_member pathlink.com> wrote in message
 news:d2e710$11s8$1 digitaldaemon.com...
 

FOR getting rid of the annoying package/module problem

This last one was the most dissapointing thing to me when learning D. I


 
 feel
 

like my code has to be organized in a way that I do not prefer, and when a
language takes that freedom from a programmer, that is a bad thing.


 
 
 I read your post, but I just didn't understand what the problem you're
 seeing is. Can you please try again?
 
 


I think he means the inability (sp?) of doing this:

/some/path/mylibrary.d
/some/path/mylibrary/foo.d
/some/path/mylibrary/bar.d

_______________________
Carlos Santander Bernal



 Mar 30 2005



  parent reply "Walter" <newshound digitalmars.com>  writes:


"Carlos Santander B." <csantander619 gmail.com> wrote in message
news:d2f4dj$236r$7 digitaldaemon.com...

 I think he means the inability (sp?) of doing this:

 /some/path/mylibrary.d
 /some/path/mylibrary/foo.d
 /some/path/mylibrary/bar.d


To make that work would introduce a huge kludge into the symbol table lookup
rules, as mylibrary would have to be *both* a module name and a package
name, and disambiguating the two cases would likely be an endless source of
weird bugs. It'd be like trying to make:

    int foo;
    void foo();

work.



 Mar 30 2005



  parent reply Derek Parnell <derek psych.ward>  writes:


On Wed, 30 Mar 2005 13:56:54 -0800, Walter wrote:


 "Carlos Santander B." <csantander619 gmail.com> wrote in message
 news:d2f4dj$236r$7 digitaldaemon.com...

 I think he means the inability (sp?) of doing this:

 /some/path/mylibrary.d
 /some/path/mylibrary/foo.d
 /some/path/mylibrary/bar.d


 
 To make that work would introduce a huge kludge into the symbol table lookup
 rules, as mylibrary would have to be *both* a module name and a package
 name, and disambiguating the two cases would likely be an endless source of
 weird bugs. It'd be like trying to make:
 
     int foo;
     void foo();
 
 work.


You slacker! ;-) What a cop out... You already decorate symbol names for
object files, so why not decorate the internal symbols for packages and
modules.

  import some.path.library;

uses symbols "some~P", "path~P", "library"

  import some.path.library.foo;
 
uses symbols "some~P", "path~P", "library~P", "foo"

   some.path.library.funcA();

uses symbols "some~P", "path~P", "library", "funcA"

   some.path.library.foo.funcA();

uses symbols "some~P", "path~P", "library~P", "foo", "funcA"

Even if my suggestion is absurd, I'm sure you can come up with something
that is not stupid to implement.

-- 
Derek
Melbourne, Australia
31/03/2005 10:45:24 AM



 Mar 30 2005



  parent reply "Ben Hinkle" <ben.hinkle gmail.com>  writes:


"Derek Parnell" <derek psych.ward> wrote in message 
news:tkxprbvhzw3r.126jttcaxfh3d$.dlg 40tude.net...

 On Wed, 30 Mar 2005 13:56:54 -0800, Walter wrote:


 "Carlos Santander B." <csantander619 gmail.com> wrote in message
 news:d2f4dj$236r$7 digitaldaemon.com...

 I think he means the inability (sp?) of doing this:

 /some/path/mylibrary.d
 /some/path/mylibrary/foo.d
 /some/path/mylibrary/bar.d


 To make that work would introduce a huge kludge into the symbol table 
 lookup
 rules, as mylibrary would have to be *both* a module name and a package
 name, and disambiguating the two cases would likely be an endless source 
 of
 weird bugs. It'd be like trying to make:

     int foo;
     void foo();

 work.


 You slacker! ;-) What a cop out...


I think he means it would be a source of user bugs - not compiler bugs. For 
example it would be impossible to tell if, for example, "mylibrary.foo.x" 
means "package mylibrary module foo class x" or "module mylibrary class foo 
field x". There would be no way for the user to specify which they meant. 
One might be tempted to say "use an alias" but the alias would say something 
like "alias mylibrary.foo bar" which does not help. So the language would 
need reworking - most likely by using a different token to distinguish 
between field access and package access and maybe other kinds of access (eg 
mylibrary::foo.x). Needless to say that would be a big change.



 Mar 30 2005



  parent  "Walter" <newshound digitalmars.com>  writes:


"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d2fi69$2gbj$1 digitaldaemon.com...

 I think he means it would be a source of user bugs - not compiler bugs.


It'd be a source of bugs for both.


 For
 example it would be impossible to tell if, for example, "mylibrary.foo.x"
 means "package mylibrary module foo class x" or "module mylibrary class


foo

 field x". There would be no way for the user to specify which they meant.
 One might be tempted to say "use an alias" but the alias would say


something

 like "alias mylibrary.foo bar" which does not help. So the language would
 need reworking - most likely by using a different token to distinguish
 between field access and package access and maybe other kinds of access


(eg

 mylibrary::foo.x). Needless to say that would be a big change.


Consider the kludge-o-matic means C++ uses to distinguish struct names from
other names with the same spelling. I was hoping to leave all that behind
<g>.



 Mar 30 2005



prev sibling next sibling parent reply Derek Parnell <derek psych.ward>  writes:


On Wed, 30 Mar 2005 12:45:20 +0000 (UTC), Trevor Parscal wrote:


 I am, for the record, despite the categoriztion of my view in a recent post.
 
 FOR changing the name Phobos to something else.
 FOR keeping std as the namespace of the Standard Library
 FOR reorganizing things, a bit more structure
 and
 FOR getting rid of the annoying package/module problem
 
 This last one was the most dissapointing thing to me when learning D. I feel
 like my code has to be organized in a way that I do not prefer, and when a
 language takes that freedom from a programmer, that is a bad thing.
 
 I know we all just deal with it, but it can cause annoying problems, and I must
 suggest some alternative ideas of handling packages and modules.
 
 Example Structure
 
 [/] source
 ---[-] string.d
 ---[/] string
 ------[-] convert.d


I does seem odd to me too that DMD disallows a source file to have the same
basic name as the directory its in. The file system handles this quite well
so why DMD doesn't is still a mystery to me.


 1: Automatic recursive module inclusion.
 This would cause "import string;" to import string.d and the contents of the
 string package, like convert.d. If you only wanted string.d, you would be out
of
 luck, this is the downside...
 
 2: Manual recursive module inclusion.
 This gives you more control, but requires new language. For instance, "import
 string;" would only import the string.d module, but "import.string.*;" could
 grab the contents of the string package. Also, you can acutally say "import
 string.convert;" which you cant do with D right now, which sucks.


Another possible syntax for including an entire package, rather than just
individual modules might be ...

   import package string;

Though why one would need to import an entire package is not clear to me.


 3: Clarification of module vs package
 This would make it so you are using a different manner to include just the
 string module (string.d) or the entire string package (including string.d if
 present). So, "import string;" would include just the module, and "imports
 string;" does everything. I guess the naming could be different. Depends on
 whether you see "import module" as a command like "do this" or a definition
like
 "type name". If the latter is your opinion, than imports makes sense, because
it
 is the plurar version of import, however as a command, it's confusing, which is
 bad.
 
 Other ideas on how to solve this problem are out there, and we should look at
 them too. All I know is it's really annoying to have to name things the way I
 have to. I think it breaks the object orientation concept when you cant have a
 module have submodues (string = module and string.convert = module)..


As I said above, I think that the problem is just that one can't have a
source file with the same base name as the directory its in. Why not? 

The way I see it, 

 import string;  // means get the contents of "string.d"
 import string.convert; // means get the contents of "string/convert.d"
 import string.convert.russian; // means get the contents of
"string/convert/russian.d"

But DMD doesn't agree with me :-(


 Reorganizing things of course makes things break, but lets do it NOW while the
 code we are breaking is minimal.
 
 Also, ideas other than phobos are not a bad idea. I mean, if you don't think
 that the D Standard Library being in the std namespace makes sense, that you
 could come up with SOMETHING more professional than Phobos. 


Why is the collection of characters in the sequence 'P','h','o','b','o','s'
necessarily unprofessional? I just don't get it? If it was generally
recognised as a swear word then I could understand your concern. I know it
is the transliteration of the Greek word for 'fear', but it is also the
name of a moon - so what? 


 Naming things IS
 important, even though it doesn't change the way the code works. I agree that
 Java's name stuck, but Java is at least a word in most people's vocabulary.


The people of Indonesia(the Javanese anyway) are very happy to have such
global use of their main island ;-)
 

 Finally, this forum system is pretty lame. I am glad it is here, but honestly,
 how hard is it to grab a copy of PhpBB? If Digital Mars doesn't want to make
the
 upgrade, I would be glad to host a modern board on my own server... And if you
 think this board is fine, and wonder why I think it is lame, here are my
 complaints, that would all be fixed if you used a modern (FREE AND OPEN SOURCE)
 board like PhpBB.


I use a good news reader (40Tude) and have none (zero) of the problems you
mention below.
 

 1: Posts take too long to show up


Instantaneous. No sooner do I press 'send' that the post is visible in the
list.


 2: Posts are not organized by topic


I can organize posts by topic, author, date, etc... at nearly instantaneous
speeds. If you use Opera's news reader, there is almost unlimited ways to
organise and categorise posts.


 3: The interface is ugly


The web interface to DMD newsgroups is not great. But I never use that
anyway.


 4: Users cannot register and settings/identity be recalled


Using a news reader, you can.


 5: No search tools


I have useful searching facilities in the news reader.
 

 PLEASE considder using a modern board! It would really help get questions
 answered, things decided, a community grown.


IMO, web based boards are generally a lot slower to use, more cumbersome,
and less flexible. 

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build/
http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage
31/03/2005 9:38:07 AM



 Mar 30 2005



  parent reply "Walter" <newshound digitalmars.com>  writes:


"Derek Parnell" <derek psych.ward> wrote in message
news:hmt0w1vqr6kt$.sb6zy77ta9k4.dlg 40tude.net...

 I does seem odd to me too that DMD disallows a source file to have the


same

 basic name as the directory its in. The file system handles this quite


well

 so why DMD doesn't is still a mystery to me.


I agree with the rest of your post. But the file system doesn't handle it at
all. No file system I know of allows both a file and a directory to have the
same name. Try creating a file named 'foo' and a subdirectory 'foo' at the
same time!



 Mar 30 2005



 next sibling parent  Trevor Parscal <trevorparscal hotmail.com>  writes:


Walter wrote:

 
 I agree with the rest of your post. But the file system doesn't handle it at
 all. No file system I know of allows both a file and a directory to have the
 same name. Try creating a file named 'foo' and a subdirectory 'foo' at the
 same time!
 


foo.d = file
foo = dir

These do NOT have the same name.. I have no idea why you posted that...

Thanks
Trevor Parscal
www.trevorparscal.com



 Mar 30 2005



prev sibling  parent reply Derek Parnell <derek psych.ward>  writes:


On Wed, 30 Mar 2005 18:23:30 -0800, Walter wrote:


 "Derek Parnell" <derek psych.ward> wrote in message
 news:hmt0w1vqr6kt$.sb6zy77ta9k4.dlg 40tude.net...

 I does seem odd to me too that DMD disallows a source file to have the


 same

 basic name as the directory its in. The file system handles this quite


 well

 so why DMD doesn't is still a mystery to me.


 
 I agree with the rest of your post. But the file system doesn't handle it at
 all. No file system I know of allows both a file and a directory to have the
 same name. Try creating a file named 'foo' and a subdirectory 'foo' at the
 same time!


I'm sorry I didn't highlight the important word in my post. See how I said
"*basic* name" and not "file name". By that I meant the file name excluding
the 'extension' portion. Sorry I didn't make that clearer. So what I meant
was 'foo.d' is allowed inside a directory called 'foo'.

-- 
Derek
Melbourne, Australia
31/03/2005 12:50:59 PM



 Mar 30 2005



  parent reply Derek Parnell <derek psych.ward>  writes:


On Thu, 31 Mar 2005 12:53:42 +1000, Derek Parnell wrote:


 On Wed, 30 Mar 2005 18:23:30 -0800, Walter wrote:
 

 "Derek Parnell" <derek psych.ward> wrote in message
 news:hmt0w1vqr6kt$.sb6zy77ta9k4.dlg 40tude.net...

 I does seem odd to me too that DMD disallows a source file to have the


 same

 basic name as the directory its in. The file system handles this quite


 well

 so why DMD doesn't is still a mystery to me.


 
 I agree with the rest of your post. But the file system doesn't handle it at
 all. No file system I know of allows both a file and a directory to have the
 same name. Try creating a file named 'foo' and a subdirectory 'foo' at the
 same time!


 
 I'm sorry I didn't highlight the important word in my post. See how I said
 "*basic* name" and not "file name". By that I meant the file name excluding
 the 'extension' portion. Sorry I didn't make that clearer. So what I meant
 was 'foo.d' is allowed inside a directory called 'foo'.


Oops, pressed send to quickly (again).

So what I meant was 'foo.d' is allowed along side a directory called 'foo'.
-- 
Derek
Melbourne, Australia
31/03/2005 12:55:55 PM



 Mar 30 2005



  parent reply "Walter" <newshound digitalmars.com>  writes:


"Derek Parnell" <derek psych.ward> wrote in message
news:v4mch8wqquaz.9l4p82iew48u.dlg 40tude.net...

 On Thu, 31 Mar 2005 12:53:42 +1000, Derek Parnell wrote:


 On Wed, 30 Mar 2005 18:23:30 -0800, Walter wrote:


 "Derek Parnell" <derek psych.ward> wrote in message
 news:hmt0w1vqr6kt$.sb6zy77ta9k4.dlg 40tude.net...

 I does seem odd to me too that DMD disallows a source file to have the


 same

 basic name as the directory its in. The file system handles this quite


 well

 so why DMD doesn't is still a mystery to me.


 I agree with the rest of your post. But the file system doesn't handle






it at

 all. No file system I know of allows both a file and a directory to






have the

 same name. Try creating a file named 'foo' and a subdirectory 'foo' at






the

 same time!


 I'm sorry I didn't highlight the important word in my post. See how I




said

 "*basic* name" and not "file name". By that I meant the file name




excluding

 the 'extension' portion. Sorry I didn't make that clearer. So what I




meant

 was 'foo.d' is allowed inside a directory called 'foo'.


 Oops, pressed send to quickly (again).

 So what I meant was 'foo.d' is allowed along side a directory called


'foo'.

Of course. But the filesystem doesn't allow you to refer to "foo.d" as
"foo".



 Mar 30 2005



  parent reply Georg Wrede <georg.wrede nospam.org>  writes:


Walter wrote:

So what I meant was 'foo.d' is allowed along side a directory called
 
 'foo'.


 
 Of course. But the filesystem doesn't allow you to refer to "foo.d" as
 "foo".


Ehhhhhh, I'm totally at a loss here. 8-/

I see no reason for this need or not need to have files and directories 
with the same name. And probably there's never been a good reason for it 
for anybody else either, otherwise unix would already have it.

The FILESYSTEM doesn't have to allow it. The COMPILER may allow it (to 
look as if). IF that is what we want. (I don't.)

-----------------

I think we should just concentrate on the syntax, and its usability and 
the various proposals or suggestions.

Actually, the very discussion about file/dir here is a sign of the 
current package/module semantics being, at the very least, unobvious.



 Mar 31 2005



  parent reply "Walter" <newshound digitalmars.com>  writes:


"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:424BD4C1.5090109 nospam.org...

 Walter wrote:

So what I meant was 'foo.d' is allowed along side a directory called

 'foo'.


 Of course. But the filesystem doesn't allow you to refer to "foo.d" as
 "foo".


 Ehhhhhh, I'm totally at a loss here. 8-/

 I see no reason for this need or not need to have files and directories
 with the same name. And probably there's never been a good reason for it
 for anybody else either, otherwise unix would already have it.


I agree. I am at a loss as well why this is perceived as a problem, which is
why I'd asked for a clarification.


 The FILESYSTEM doesn't have to allow it. The COMPILER may allow it (to
 look as if). IF that is what we want. (I don't.)

 -----------------

 I think we should just concentrate on the syntax, and its usability and
 the various proposals or suggestions.

 Actually, the very discussion about file/dir here is a sign of the
 current package/module semantics being, at the very least, unobvious.


Just a thought - it might be too obvious. Sometimes, people impute
complexity where there isn't any, because they are expecting it to be
complicated. D has very simple name scoping and lookup rules, which can be
baffling at first when coming from C++ where nothing is straightforward
about symbol lookup.



 Mar 31 2005



  parent reply Derek Parnell <derek psych.ward>  writes:


On Thu, 31 Mar 2005 10:33:26 -0800, Walter wrote:


 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:424BD4C1.5090109 nospam.org...

 Walter wrote:

So what I meant was 'foo.d' is allowed along side a directory called

 'foo'.


 Of course. But the filesystem doesn't allow you to refer to "foo.d" as
 "foo".


 Ehhhhhh, I'm totally at a loss here. 8-/

 I see no reason for this need or not need to have files and directories
 with the same name. And probably there's never been a good reason for it
 for anybody else either, otherwise unix would already have it.




Huh? Who is asking for files and directories to have the same name? I'm
not. 
 

 I agree. I am at a loss as well why this is perceived as a problem, which is
 why I'd asked for a clarification.


The "perceived" problem is that one is unable to have the file "foo.d" and
the directory "foo" both in the same directory *and* have your application
import "foo.d" or anything from inside "foo". In other words, one cannot
code ...

  import foo.bar;

if "foo.d" happens to exist.

Why would somebody want to do this? Ask Arcane Jill. She wanted to have
"BigInteger.d" contain imports for all the modules inside the BigInteger
package to make it easier for coders to import the entire package. Not
realizing this restriction, she used names that seemed natural to use. The
best way around this problem is to rename "BigInteger.d" to something else.

-- 
Derek Parnell
Melbourne, Australia
1/04/2005 6:43:14 AM



 Mar 31 2005



 next sibling parent  "Jamboree" <jam bor.ee>  writes:


 The "perceived" problem is that one is unable to have the file "foo.d" and
 the directory "foo" both in the same directory *and* have your application
 import "foo.d" or anything from inside "foo". In other words, one cannot
 code ...

  import foo.bar;

 if "foo.d" happens to exist.

 Why would somebody want to do this? Ask Arcane Jill. She wanted to have
 "BigInteger.d" contain imports for all the modules inside the BigInteger
 package to make it easier for coders to import the entire package. Not
 realizing this restriction, she used names that seemed natural to use. The
 best way around this problem is to rename "BigInteger.d" to something else.


I wanted to use this in DTL.



 Mar 31 2005



prev sibling  parent reply "Regan Heath" <regan netwin.co.nz>  writes:


On Fri, 1 Apr 2005 06:59:33 +1000, Derek Parnell <derek psych.ward> wrote:

 On Thu, 31 Mar 2005 10:33:26 -0800, Walter wrote:


 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:424BD4C1.5090109 nospam.org...

 Walter wrote:

 So what I meant was 'foo.d' is allowed along side a directory called

 'foo'.


 Of course. But the filesystem doesn't allow you to refer to "foo.d" as
 "foo".


 Ehhhhhh, I'm totally at a loss here. 8-/

 I see no reason for this need or not need to have files and directories
 with the same name. And probably there's never been a good reason for  
 it
 for anybody else either, otherwise unix would already have it.




 Huh? Who is asking for files and directories to have the same name? I'm
 not.


 I agree. I am at a loss as well why this is perceived as a problem,  
 which is
 why I'd asked for a clarification.


 The "perceived" problem is that one is unable to have the file "foo.d"  
 and
 the directory "foo" both in the same directory *and* have your  
 application
 import "foo.d" or anything from inside "foo". In other words, one cannot
 code ...

   import foo.bar;

 if "foo.d" happens to exist.

 Why would somebody want to do this? Ask Arcane Jill. She wanted to have
 "BigInteger.d" contain imports for all the modules inside the BigInteger
 package to make it easier for coders to import the entire package. Not
 realizing this restriction, she used names that seemed natural to use.  
 The
 best way around this problem is to rename "BigInteger.d" to something  
 else.


The problem seems to me to be that if you say:

import a.b;

and you have:
   a.d
   a\b.d

does the import import the file b.d, or does it import a symbol called "b"  
 from the module "a" (file a.d).

[clarification of terms:
   symbol  == class, struct, enum, instance?
   module  == file
   package == directory
]

My questions are:
  - is it important that the above is possible?
  - does it make sense to import a symbol from within a module?
  - if not, then there is no problem.
  - if so, how do we disambiguate the above?

Suggestions to disambiguate.

1. Use "" eg.
   import "a.b"  <- imports a symbol "a.b"
   import a.b    <- imports the module "b" from package "a"

This breaks no existing code. Unquoted is the same as it's always been.

2. Require file extensions
   import a.b    <- imports a symbol "a.b"
   import a.b.d  <- imports the module "b" from package "a"

This breaks all current code/behaviour.

3. Use a different seperator for directories
   import a.b  <- imports a symbol "a.b"
   import a/b  <- imports the module "b" from package "a"

Either / or \ could be used or allow both interchangably.
This breaks all current code/behaviour.


solution that does not break existing behaviour/code.

Regan



 Mar 31 2005



  parent reply Derek Parnell <derek psych.ward>  writes:


On Fri, 01 Apr 2005 10:16:28 +1200, Regan Heath wrote:


[snip]

 
 The problem seems to me to be that if you say:
 
 import a.b;
 
 and you have:
    a.d
    a\b.d
 
 does the import import the file b.d, or does it import a symbol called "b"  
  from the module "a" (file a.d).


 
Huh? I don't think that D allows one to import symbols from a module.

  import a.b;

Always means "access the file whose path is 'a/b.d' 

-- 
Derek
Melbourne, Australia
1/04/2005 9:10:14 AM



 Mar 31 2005



  parent reply "Regan Heath" <regan netwin.co.nz>  writes:


On Fri, 1 Apr 2005 09:12:06 +1000, Derek Parnell <derek psych.ward> wrote:

 On Fri, 01 Apr 2005 10:16:28 +1200, Regan Heath wrote:


 [snip]

 The problem seems to me to be that if you say:

 import a.b;

 and you have:
    a.d
    a\b.d

 does the import import the file b.d, or does it import a symbol called  
 "b"
  from the module "a" (file a.d).


 Huh? I don't think that D allows one to import symbols from a module.

   import a.b;

 Always means "access the file whose path is 'a/b.d'


Just checking.

Actually I think I just recalled Walters reasoning earlier. The problem is  
this:

[a.d]
class foo {
   int i;
}
foo b;

[a\b.d]
float i;

import a;
import a.b;

a.b.i = 6; //which 'i' is set?

Regan



 Mar 31 2005



  parent  "Regan Heath" <regan netwin.co.nz>  writes:


On Fri, 01 Apr 2005 12:10:38 +1200, Regan Heath <regan netwin.co.nz> wrote:

 On Fri, 1 Apr 2005 09:12:06 +1000, Derek Parnell <derek psych.ward>  
 wrote:

 On Fri, 01 Apr 2005 10:16:28 +1200, Regan Heath wrote:


 [snip]

 The problem seems to me to be that if you say:

 import a.b;

 and you have:
    a.d
    a\b.d

 does the import import the file b.d, or does it import a symbol called  
 "b"
  from the module "a" (file a.d).


 Huh? I don't think that D allows one to import symbols from a module.

   import a.b;

 Always means "access the file whose path is 'a/b.d'


 Just checking.

 Actually I think I just recalled Walters reasoning earlier. The problem  
 is this:

 [a.d]
 class foo {
    int i;
 }
 foo b;

 [a\b.d]
 float i;


[another.d]


 import a;
 import a.b;

 a.b.i = 6; //which 'i' is set?


Correction/addition  above.
Regan



 Mar 31 2005



prev sibling  parent  Dejan Lekic <leka entropy.tmok.com>  writes:


 This last one was the most dissapointing thing to me when learning D. I
 feel like my code has to be organized in a way that I do not prefer, and
 when a language takes that freedom from a programmer, that is a bad thing.


I agree, but what I hate even more is when I am forced to use God-hated JAVA
code-style ( variableNames , methodNames() , ...) . IMHO D's standard
library - Phobos should follow STD C naming scheme and use simple
method_names() ... Who knows, maybe D's community is full of JAVA
programmers... Than I would understand current D direction.

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
  



 Mar 30 2005



prev sibling next sibling parent reply "Regan Heath" <regan netwin.co.nz>  writes:


On Wed, 30 Mar 2005 03:54:15 -0800, David Barrett <dbarrett quinthar.com>  
wrote:

 "Mike Parker" <aldacron71 yahoo.com> wrote in message
 news:d2e013$qls$1 digitaldaemon.com...

 I guess then I should speak up, as I like the name Phobos. I would very
 much hate to see it named to 'D Standard Library', even if you did  
 somehow
 persuade Walter to do so. I've never viewed Phobos as a codename, but as
 the *real* name. That is, in fact, how it is presented in the
 documentation. And did Walter ever say he intended it to be a  
 'codename'?
 Anyway, I disagree completely with your reasoning and see the name  
 Phobos
 as a boon rather than a hindrance. It adds a bit of pinache to things.


 I'll admit, "Phobos" doesn't excite me.  But I'd be much happier if the  
 name of the package and, well, the name of the package were the same.


I think this is where/why we disagree. (I use "we" loosely to mean myself  
and others who have voiced an opinion not to mind, or to like calling the  
"D Standard Library" Phobos).

--these opinions are my own, not 'we' as used above--

In my mind, "Phobos" is the name of something, this something is the "D  
Standard Library". The phrase "D Standard Library" is a description of  
what it is, "Phobos" is the name/short descriptor for it.

I see no reason to change "std" to "Phobos" or vice-versa, in my mind  
"std" is a package inside the library which is called "Phobos" i.e.

[Phobos]
   |-[std]
   |   |-string.d
   |-[etc]
   |   |-[c]
   |      |-recls
   |-? others may appear later

So.

Library == "Phobos"
Package == "std"

"Phobos" is a collection of packages, a library, not a package itself.

Just as "Ares" is a collection of packages, a library, not a package  
itself.

Regan



 Mar 30 2005



  parent  Derek Parnell <derek psych.ward>  writes:


On Thu, 31 Mar 2005 12:20:34 +1200, Regan Heath wrote:


 On Wed, 30 Mar 2005 03:54:15 -0800, David Barrett <dbarrett quinthar.com>  
 wrote:

 "Mike Parker" <aldacron71 yahoo.com> wrote in message
 news:d2e013$qls$1 digitaldaemon.com...

 I guess then I should speak up, as I like the name Phobos. I would very
 much hate to see it named to 'D Standard Library', even if you did  
 somehow
 persuade Walter to do so. I've never viewed Phobos as a codename, but as
 the *real* name. That is, in fact, how it is presented in the
 documentation. And did Walter ever say he intended it to be a  
 'codename'?
 Anyway, I disagree completely with your reasoning and see the name  
 Phobos
 as a boon rather than a hindrance. It adds a bit of pinache to things.


 I'll admit, "Phobos" doesn't excite me.  But I'd be much happier if the  
 name of the package and, well, the name of the package were the same.


 
 I think this is where/why we disagree. (I use "we" loosely to mean myself  
 and others who have voiced an opinion not to mind, or to like calling the  
 "D Standard Library" Phobos).
 
 --these opinions are my own, not 'we' as used above--
 
 In my mind, "Phobos" is the name of something, this something is the "D  
 Standard Library". The phrase "D Standard Library" is a description of  
 what it is, "Phobos" is the name/short descriptor for it.
 
 I see no reason to change "std" to "Phobos" or vice-versa, in my mind  
 "std" is a package inside the library which is called "Phobos" i.e.
 
 [Phobos]
    |-[std]
    |   |-string.d
    |-[etc]
    |   |-[c]
    |      |-recls
    |-? others may appear later
 
 So.
 
 Library == "Phobos"
 Package == "std"
 
 "Phobos" is a collection of packages, a library, not a package itself.


Exactly how I would say it too! :D 

Phobos is the name of the library that is distributed with DMD. 'std' is
the name of one of the packages in that library (though I'd prefer 'core'
but its too late for that). If we need standardization, it with the names
of the packages and modules within the library, so that developers need not
be (too) worried about changing D vendors.

-- 
Derek
Melbourne, Australia
31/03/2005 10:36:59 AM



 Mar 30 2005



prev sibling  parent  J C Calvarese <jcc7 cox.net>  writes:


David Barrett wrote:

 "Mike Parker" <aldacron71 yahoo.com> wrote in message 
 news:d2e013$qls$1 digitaldaemon.com...
 


...

 That's a fair comment.  Would you support renaming the "std" namespace to be 
 "phobos"?
 
 I think it's that discrepancy that bothers me the most.  It's like "Hi, my 
 name is David, spelled B-O-B".


I made that very suggestion a couple years ago (before we had even had 
the std package). It was an idea ahead of its time. :)
http://www.digitalmars.com/drn-bin/wwwnews?D/18412

The idea of calling phobos "phobos" still makes an immense amount of 
sense to me, but I've pretty much given the argument. Just because it's 
obvious to me doesn't guarantee that anyone else will agree with my 
logic. ;)


 Given that changing "std" would break a lot of code and changing "Phobos" 
 would break almost none, I favor changing Phobos, though I'd be happy with 
 either.


Renaming "std" would be a problem easily solved with "Find and Replace", 
but the powers-that-be are happy with most of Phobos in the "std" 
package (with the rest in etc.*, internal.*, and a few hanging around 
without a package), so that's how it'll remain for the immediate future. 
At least the folder is called "phobos".

-- 
jcc7
http://jcc_7.tripod.com/d/



 Mar 30 2005



prev sibling  parent reply "Walter" <newshound digitalmars.com>  writes:


"David Barrett" <dbarrett quinthar.com> wrote in message
news:d2duij$p6p$1 digitaldaemon.com...

 As for the final tally, it sounds like nobody's passionate for changing


the

 name except for me.  That said, nobody's passionately (mildly, but not
 passionately) against changing it either.  The bulk just don't seem to


care

 one way or the other.

 So Walter, if I just went ahead and updated all the documentation and
 library code to standardize on the term "D Standard Library", would you
 integrate that with the main tree?

 To repeat my reasoning, I think that Phobos is a great codename, and


should

 serve its place in history.  But codenames, by definition, are not public
 names.  By referring to the D standard library by codename (or worse, with


a

 variety of names), it confuses new users and reinforces the notion that D


is

 messy and incomplete.



 place to start in helping D along in its path to greatness.


I understand your passion, but I respectfully disagree.  I just don't see it
as unprofessional to give the standard D library a name.



 Mar 30 2005



  parent  "David Barrett" <dbarrett quinthar.com>  writes:


"Walter" <newshound digitalmars.com> wrote in message 
news:d2ejt9$1geh$1 digitaldaemon.com...

 I understand your passion, but I respectfully disagree.  I just don't see 
 it
 as unprofessional to give the standard D library a name.


Excellent, I'm happy to hear the final word. 



 Mar 30 2005



prev sibling  parent reply "Unknown W. Brackets" <unknown simplemachines.org>  writes:


Ehm?  Someone call?  I post here so little I'm surprised I was mentioned...

Frankly, I don't think it matters, since someone asked me (?).  Wars 
have been won and lost and no one remembers the names of the people who 
made the weapons waged.  Or maybe I just didn't pay good attention in 
Social Studies.

-[Unknown]



 [Unknown] Anders F Björklund, Carlos Santander B, Sean Kelly, Walter, 
 Benjamin Herr,  Georg Wrede, Trevor Parscal, everyone else





 Mar 30 2005



  parent reply J C Calvarese <jcc7 cox.net>  writes:


Unknown W. Brackets wrote:

 Ehm?  Someone call?  I post here so little I'm surprised I was mentioned...


I'm sure he wants to hear as many voices as possible, but I'm fairly 
certain that "[Unknown]" was intended to be the name of the category 
(see also [Ambivalent], [Against renaming], etc.).

...

 [Unknown] Anders F Björklund, Carlos Santander B, Sean Kelly, Walter, 
 Benjamin Herr,  Georg Wrede, Trevor Parscal, everyone else





-- 
A. Nonymous



 Mar 30 2005



  parent reply "Unknown W. Brackets" <unknown simplemachines.org>  writes:


I'll remember not to joke in the future.  No one gets it.

-[Unknown]



 Unknown W. Brackets wrote:
 

 Ehm?  Someone call?  I post here so little I'm surprised I was 
 mentioned...


 
 
 I'm sure he wants to hear as many voices as possible, but I'm fairly 
 certain that "[Unknown]" was intended to be the name of the category 
 (see also [Ambivalent], [Against renaming], etc.).
 
 ...
 

 [Unknown] Anders F Björklund, Carlos Santander B, Sean Kelly, Walter, 
 Benjamin Herr,  Georg Wrede, Trevor Parscal, everyone else




 
 
 





 Mar 30 2005



 next sibling parent  zwang <nehzgnaw gmail.com>  writes:


I admit that I chuckled.

Unknown W. Brackets wrote:

 I'll remember not to joke in the future.  No one gets it.
 
 -[Unknown]
 
 

 Unknown W. Brackets wrote:


 Ehm?  Someone call?  I post here so little I'm surprised I was 
 mentioned...




 I'm sure he wants to hear as many voices as possible, but I'm fairly 
 certain that "[Unknown]" was intended to be the name of the category 
 (see also [Ambivalent], [Against renaming], etc.).

 ...


 [Unknown] Anders F Björklund, Carlos Santander B, Sean Kelly, 
 Walter, Benjamin Herr,  Georg Wrede, Trevor Parscal, everyone else











 Mar 30 2005



prev sibling next sibling parent  "Regan Heath" <regan netwin.co.nz>  writes:


I got it!
:)

Regan

On Wed, 30 Mar 2005 23:13:41 -0800, Unknown W. Brackets  
<unknown simplemachines.org> wrote:

 I'll remember not to joke in the future.  No one gets it.

 -[Unknown]



 Unknown W. Brackets wrote:


 Ehm?  Someone call?  I post here so little I'm surprised I was  
 mentioned...


   I'm sure he wants to hear as many voices as possible, but I'm fairly  
 certain that "[Unknown]" was intended to be the name of the category  
 (see also [Ambivalent], [Against renaming], etc.).
  ...


 [Unknown] Anders F Björklund, Carlos Santander B, Sean Kelly, Walter,  
 Benjamin Herr,  Georg Wrede, Trevor Parscal, everyone else











 Mar 31 2005



prev sibling next sibling parent  Georg Wrede <georg.wrede nospam.org>  writes:


Ahhh, go on. We all need a giggle now and then.

Besides, those who got it giggled and never posted.

Unknown W. Brackets wrote:

 I'll remember not to joke in the future.  No one gets it.
 
 -[Unknown]
 
 

 Unknown W. Brackets wrote:


 Ehm?  Someone call?  I post here so little I'm surprised I was 
 mentioned...




 I'm sure he wants to hear as many voices as possible, but I'm fairly 
 certain that "[Unknown]" was intended to be the name of the category 
 (see also [Ambivalent], [Against renaming], etc.).

 ...


 [Unknown] Anders F Björklund, Carlos Santander B, Sean Kelly, 
 Walter, Benjamin Herr,  Georg Wrede, Trevor Parscal, everyone else











 Mar 31 2005



prev sibling  parent  J C Calvarese <jcc7 cox.net>  writes:


Unknown W. Brackets wrote:

 I'll remember not to joke in the future.  No one gets it.
 
 -[Unknown]


You won't believe me now, but I really did think of you a split second 
when I saw the [Unknown] line in the OP. If you had asked who 
"[Ambivalent]" was I might've figured it out.

My real name is "the" (but my friends all call me "a").

-- 
jcc7
http://jcc_7.tripod.com/d/



 Mar 31 2005