March 30, 2005
Anders F Björklund wrote:
> Walter wrote:
> 
>>> etc.c.zlib -> std.c.zlib (i.e. just the zlib.d module, not the rest)
>>
>>
>> The idea behind putting zlib in etc rather than std is that part of the zlib
>> code is not part of the standard interface to the zlib library. The std part
>> is the standard interface.
> 
> 
> I'm not sure I follow... Surely std.zlib could still remain, even
> if the etc.c.zlib import module was moved to std.c.zlib instead ?
> 
> Just as std.stdio and std.c.stdio are able to co-exist right now ?
> I just thought it was bad that a std module linked to an etc one...
> 
> --anders

What I understand is, that if you can implement std.zlib and std.recls by other means than depending on etc.c.zlib, etc.c.recls, etc.c.stlsoft, then go on and do it. The end user shouldn't rely on etc.* existing.

Once I asked something related to this, and Walter said that every D distribution must have the std.* modules. The etc.* are optional (it's not a quote, it's what I remember).

_______________________
Carlos Santander Bernal
March 31, 2005
"Anders F Björklund" <afb@algonet.se> wrote in message news:d2f226$20ig$1@digitaldaemon.com...
> But first, the compiler internals and garbage collector should be split off from the D standard library itself.

But they already are! They're in the 'internal' package.


March 31, 2005
Walter wrote:

>>But first, the compiler internals and garbage collector
>>should be split off from the D standard library itself.
> 
> But they already are! They're in the 'internal' package.

I meant as separate libraries, so that one could use
a different standard library (such as Ares) and/or
minimize compiler dependencies (i.e. with GDC compiler),
and use a different garbage collector implementation
without recompiling the main library archive (phobos) ?

But I'll try to sum it up in a more step-by-step suggestion.

--anders
March 31, 2005
In article <d2gd56$dpk$1@digitaldaemon.com>, Walter says...
>
>"Anders F Björklund" <afb@algonet.se> wrote in message news:d2f226$20ig$1@digitaldaemon.com...
>> But first, the compiler internals and garbage collector should be split off from the D standard library itself.
>
>But they already are! They're in the 'internal' package.

But everything compiles as a unit.  This wouldn't be a big deal in itself if the code in internal didn't import anything from std, but it does.  So while the different bits are logically separate, they are functionally intertwined.  This isn't an issue for the average D programmer, but it is for someone looking to write a standard library for a D compiler.  One of the fundamental goals for Ares, IMO, was to remove these dependencies when possible, and to document them when not.  Ideally, it should be possible to code a new standard library or garbage collector from the spec and drop it into any D compiler with a minimum of effort.  I don't believe that this is currently possible with Phobos.


Sean


March 31, 2005
"Sean Kelly" <sean@f4.ca> wrote in message news:d2h6tm$19qr$1@digitaldaemon.com...
> In article <d2gd56$dpk$1@digitaldaemon.com>, Walter says...
> >
> >"Anders F Björklund" <afb@algonet.se> wrote in message news:d2f226$20ig$1@digitaldaemon.com...
> >> But first, the compiler internals and garbage collector should be split off from the D standard library itself.
> >
> >But they already are! They're in the 'internal' package.
>
> But everything compiles as a unit.  This wouldn't be a big deal in itself
if the
> code in internal didn't import anything from std, but it does.  So while
the
> different bits are logically separate, they are functionally intertwined.
This
> isn't an issue for the average D programmer, but it is for someone looking
to
> write a standard library for a D compiler.  One of the fundamental goals
for
> Ares, IMO, was to remove these dependencies when possible, and to document
them
> when not.  Ideally, it should be possible to code a new standard library
or
> garbage collector from the spec and drop it into any D compiler with a
minimum
> of effort.  I don't believe that this is currently possible with Phobos.

Ok, I understand now.


April 01, 2005
J C Calvarese wrote:
> David Barrett wrote:
> 
>> "J C Calvarese" <jcc7@cox.net> wrote in message news:d2cnr6$2jvv$2@digitaldaemon.com...
> 
> ...
> 
>> In preparation for this day, I think we should figure out what the "real" name is, and start getting used to it.
> 
> 
> I'm not opposed to that. I've already suggested "D Standard Library" as the official name. (http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/20275)
> 
> Do you like it? (Yes) (No) (Maybe)
> 
> If you prefer another name, please make a counter-suggestion.
> 
>> Does anyone agree with this position?  What's Walter's position?
> 
> 
> Often Walter prefers to sit back in the background and wait for us to "gang up" on him. I respect that.
> 
(Maybe)
I have nothing against the name phobos.  It would be better were the language actually named Mars, but it's ok anyway.

People who judge a language based on the name used to refer to the library are basically hopeless anyway.  If that's not their objection, then they'll find another.  (You may need to find out what their real objections are.)
1 2 3
Next ›   Last »