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 is that #1 is holding #2 back, and therefore #1 needs to be improved before #2 can improve. 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: 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: digitalmars.D.bugs/3210 Another I found in that 'session' of coding: 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: 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: digitalmars.D.bugs/3210 Another I found in that 'session' of coding: 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?

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: 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: digitalmars.D.bugs/3210 Another I found in that 'session' of coding: 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

 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


 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

 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


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


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


 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: # import java.lang.Object; # import javax.swing.*; 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: # phobos # phobos.windows # phobos.linux # phobos.c.windows # phobos.c.linux # etc 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: # std # phobos # phobos.windows # phobos.linux # phobos.c.windows # phobos.c.linux # deimos # etc 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:
 
 # phobos
 # phobos.windows
 # phobos.linux
 # phobos.c.windows
 # phobos.c.linux
 # etc
 
 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:
 
 # std
 # phobos
 # phobos.windows
 # phobos.linux
 # phobos.c.windows
 # phobos.c.linux
 # deimos
 # etc
 
 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:

 # phobos
 # phobos.windows
 # phobos.linux
 # phobos.c.windows
 # phobos.c.linux
 # etc

 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:

 # std
 # phobos
 # phobos.windows
 # phobos.linux
 # phobos.c.windows
 # phobos.c.linux
 # deimos
 # etc

 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.

And as for the source of my passion, I don't think this is the #1 issue 
facing D.  Not even #10.  But it is an issue, and it seemed like the best 
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.
 
 And as for the source of my passion, I don't think this is the #1 issue 
 facing D.  Not even #10.  But it is an issue, and it seemed like the best 
 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

 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

 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

 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

 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

list.
 2: Posts are not organized by topic

speeds. If you use Opera's news reader, there is almost unlimited ways to organise and categorise posts.
 3: The interface is ugly

anyway.
 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.

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

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

 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

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

 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

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

 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

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

 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



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



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



 same time!

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


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


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


 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

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. To me, #3 is the clearest, #2 is actually more confusing, #1 is the only 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).

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).

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. :) 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

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

 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

 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

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

 messy and incomplete.

 And as for the source of my passion, I don't think this is the #1 issue
 facing D.  Not even #10.  But it is an issue, and it seemed like the best
 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...

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