"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

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

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

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

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

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

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

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

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

Generalized templates look to me like a solution that will have nearly all of the vices of an interpreted language with few of the benefits.  A parsing preprocessor would be a better solution...and it should generate D code with the comments included to facilitate intelligibility.  (OTOH, I'm not a compiler writer.  These are merely my opinions.  But, FWIW, I've seen many flops over the years where someone attempted what I understand you to be asking for.)

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.

On Fri, 01 Apr 2005 16:12:15 -0800, Charles Hixson <charleshixsn@earthlink.net> wrote:
> Regan Heath wrote:
>> On Wed, 30 Mar 2005 18:47:11 -0800, Walter <newshound@digitalmars.com>  wrote:
>>
>>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>>> news:opsog6g1f323k2f5@nrage.netwin.co.nz...
>>>
>>>> At the present time:
>>>> 1. D's compiler has bugs, stopping me from writing my/a library.
>>>
>>>
>>> Which bug(s) in particular?
>>   Actually I just discovered today that my bug, might not be a bug, but a  known limitation, specifically:
>>  http://www.digitalmars.com/d/template.html
>>  Limitations
>> Templates cannot be used to add non-static members or functions to  classes. For example:
>>  class Foo
>> {
>>     template TBar(T)
>>     {
>> T xx;// Error
>> int func(T) { ... }// Error
>>  static T yy;// Ok
>> static int func(T t, int y) { ... } // Ok
>>     }
>> }
>>  I was trying to use templates to write various operator overloads. See:
>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3213
>>  I was doing this for a BitArray class to replace bit[] due to the problems  I had with it, see my post:
>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3210
>>  Another I found in that 'session' of coding:
>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3214
>>  On the grand sceme of things my little BitArray library/module/thing  probably isn't the most important piece of work going on in D at the  moment. It's just, well, every time I go to write something in D I hit  these sorts of bugs or limitations. It's disheartening, but, I'm patient  and not what you'd call serious about development in D (yet) so I can  handle it.
>>  Regan
>
> Is that even a right (worthy) thing to do?

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

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

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

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

Note "generic programming".

> You could write a Python preprocessor to generate all your special cases, and then compile the resultant with D.  Of course, this would mean that you needed a D parser, so it might be better to start with the publically available D parser.
>
> I can understand that this isn't what you want to be doing (I wouldn't either), but Walter specifically decided that he didn't want to include a pre-processor in D.  Certainly not one like the C preprocessor.  (I think that templates are a compromise.)

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

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

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

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

What other methods are there for generic programming?

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

In this instance I don't need recursion.

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

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

> OTOH, this is no doubt due to the amount of time I've been spending with Python and Ruby.  I would like to see a languge which is to D as Python is to Pyrex (only coming from the other direction, of course), but I don't see any development of templates as getting us even close to that.
>
> I understand the efficiency gains of static linking at compile time, but I frequently desire the flexibility gains of languages that bind at run time, and have run time type awareness (again, like Python or Ruby).  But I don't see templates as addressing this problem.

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

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

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

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

IIRC interpreted languages use "variant" types.

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

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

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

Regan

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.