View mode: basic / threaded / horizontal-split · Log in · Help
April 01, 2005
Re: Phobos: What's in a name?
"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
April 01, 2005
Re: Phobos: What's in a name?
"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.
April 01, 2005
Re: Phobos: What's in a name?
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 
> 
>
April 01, 2005
Re: Phobos: What's in a name?
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
April 02, 2005
Re: Phobos: What's in a name?
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.)
April 02, 2005
Re: Phobos: What's in a name?
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.
April 02, 2005
Re: Phobos: What's in a name?
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
April 02, 2005
Re: Phobos: What's in a name?
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.
Next ›   Last »
4 5 6 7 8
Top | Discussion index | About this forum | D home