View mode: basic / threaded / horizontal-split · Log in · Help
March 30, 2005
Re: Phobos, the Standard Library, and Process
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
Re: Phobos, the Standard Library, and Process
"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
Re: Phobos, the Standard Library, and Process
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
Re: Phobos, the Standard Library, and Process
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
Re: Phobos, the Standard Library, and Process
"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
Re: Phobos, the Standard Library, and Process
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.)
Next ›   Last »
1 2 3
Top | Discussion index | About this forum | D home