Walter wrote:
> You're right, it doesn't matter if the library is implemented in C or D. But
> it *does* matter if it follows C or D conventions. For example, if a module
> uses errno or error numbers, 0 terminated strings, expects the caller to use
> malloc/free on data passed through its interface, etc., I'd prefer to put it
> under a C package so that gives the potential user of it some extra
> notification that it does not follow D conventions.


Good point. This made me think about the following:

Is it possible to import a module without adding its symbols directly to the current namespace?

Since C functions require different handling than D functions I would like to import such modules in a way so that I have to explicitly type std.c.func() instead of func(). Just as a reminder to myself and the people reading my code that one has to take care how to use them.

This would be especially important for string functions, I expect, since  forgetting to add the null-terminator can cause a crash.

Any way to do this?

Hauke

> I guess where I disagree with you is that putting something that uses C conventions under a package named 'std.c' is some undesirable place. I
don't
> think it's some unfavored place at all, it just acknowledges that it uses different conventions. I also feel that there should be some style consistency in standard D library code. Having one module use errno and another use exceptions just makes it look like a hodgepodge. If one
package
> does something unconventional, it needs to have a strong reason for the divergence.

One man's hodgepodge is another man's freedom of expression.

> The D way is using exceptions for error notification rather than error codes, but is not necessarilly OO. Several D modules, such as std.string
and
> std.math, are not OO at all.

I really don't think obliging people to always favour exceptions is going to fly. Exception-handling is the emporer's new clothes; nobody dares to speak their qualms. That's not to say I don't use it, or believe it is useful, but I've got both feet firmly in the Kernighan and Pike camp. Exceptions are for exceptional circumstances. I don't think all that is error-handling falls within that description.

But, sure, other people have different opinions, and paradigms of work. But that backs up my argument that we should support multiple programming paradigms.

As to the consistency issue, I think that modules that are exclusively free functions should not use exceptions for error-handling. Those that are class-based are another matter.

> BTW, the etc.c.zlib is just as usable or unusable as the C zlib library
is,
> as that's all it is. I find it more complex than necessary (there are a number of parameters you basically have to read the source code to zlib to figure out what they're good for and how to use them, that's
unacceptable),
> it has a bunch of stuff related to storage allocation, and it uses error codes rather than exceptions. Hence, I decided a D wrapper that put an
easy
> face on it made sense, and the result is std.zlib.

I've got no problem with this. I couldn't agree more. C libs should have user friendly layers put over them. But they should also be available for use, since virtually any layer adds stuff that may not be necessary under all circumstances.

I see three levels of APIs.

1. Raw C APIs
2. D-ified C APIs, and D free functions
3. Classes

I am not arguing for much, if any, of 1, but I am arguing strongly that 2 is just as valid as 3.

> "Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bnsse5$j54$1@digitaldaemon.com...
> > I totally agree that users of std.zlib should not have to care about etc.c.zlib
> >
> > However, where we seem to disagree (and not just here) is that the D
way,
> > which is (reading between the lines) an OO + exceptions way, is the only way. This is what I rail against.
> >
> > I want etc.c.filesystem.recls to be accessible to programmers and just
as
> > valid and supported as std.filesystem.recls, or whatever, and the sames probably goes for etc.c.zlib (unless you've made it pretty ugly and unusable).
> >
> > If we have to program in only one way in D, then people will be
(rightly)
> > turned off. If not, then the thin C=>D translator layers should be accessible, and not in a curious corner, but in a logical place.
> >
> > The world is a rich place, and the "one way or the highway" is that
> popular
> > and efficient language Java. It's horses for courses, and D should
support
> > all models, and prescribe as little as possible.
> >
> > Don't you agree?
> >
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:bnsrb4$h4o$1@digitaldaemon.com...
> > >
> > > "Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bnsfit$2tsp$1@digitaldaemon.com...
> > > > Ok, I see that. But in that case, you'll have the hierarchies on
their
> > > heads
> > > >
> > > > std.c.filesystem.recls - the C stuff
> > > > std.filesystem.recls - the D stuff
> > > >
> > > > whereas what we should see is
> > > >
> > > > std.filesystem.recls.c - the C stuff
> > > > std.filesystem.recls - the D stuff
> > > >
> > > > (I realise that recls.c.d is not going to work, under the current
> naming
> > > > system)
> > > >
> > > > How've you done the zlib module naming? I assume the C interface and
a
> D
> > > > layer are both provided?
> > >
> > > Here's what I did. First, I did a simple module with declarations to
> make
> > > the C zlib functions accessible from D. It makes no attempt to hide
> zlib's
> > C
> > > conventions. This will not be an official D package, but is still
> useful,
> > so
> > > I stuffed it in etc.c.zlib. Then I build a D version that implements a conventional D interface to the zlib functionality. I called this
> > std.zlib.
> > > Now, it works out that std.zlib is implemented by calling the
functions
> in
> > > etc.c.zlib, but that is quite irrelevant to (and hidden from) the user
> of
> > > std.zlib.
> > >
> > > In the future, I can see porting the zlib C code to D and implementing
> > them
> > > directly in std.zlib. But that won't affect the user of std.zlib,
except
> > > that it might be a little smaller and faster.
> > >
> > >
> >
> >
> >
>
>

In article <bntd28$1k51$1@digitaldaemon.com>, Walter says...
>
[...]
>
>BTW, the etc.c.zlib is just as usable or unusable as the C zlib library is, as that's all it is. I find it more complex than necessary (there are a number of parameters you basically have to read the source code to zlib to figure out what they're good for and how to use them, that's unacceptable), it has a bunch of stuff related to storage allocation, and it uses error codes rather than exceptions. Hence, I decided a D wrapper that put an easy face on it made sense, and the result is std.zlib.

BTW, have you thougt about making also a zip-file handling library in the D
standard libraries?
I find this very useful to be included by default in every Java implementation,
for example.

Ciao

P.S.: I deduce that my proposal of renaming etc.* to ext.* was refused, right?

"Walter" <walter@digitalmars.com> wrote in news:bnsrb4$h4o$1@digitaldaemon.com:
> Here's what I did. First, I did a simple module with declarations to make the C zlib functions accessible from D. It makes no attempt to hide zlib's C conventions. This will not be an official D package, but is still useful, so I stuffed it in etc.c.zlib. Then I build a D version that implements a conventional D interface to the zlib functionality. I called this std.zlib. Now, it works out that std.zlib is implemented by calling the functions in etc.c.zlib, but that is quite irrelevant to (and hidden from) the user of std.zlib.
> 
> In the future, I can see porting the zlib C code to D and implementing them directly in std.zlib. But that won't affect the user of std.zlib, except that it might be a little smaller and faster.

Why not std.zlib and std.zlib.c?  This make more sense
to me from a packageing standpoint.  Everything needed for the zlib
module is in one directory hierarchy instead of two.

Roberto Mariottini wrote:
> ...
> What does 'etc' stand for?
> I'd prefer 'ext', that means extension.
> 
> Ciao
> 
> 

etc stands for "et cetera", approx the same as "and other stuff" (with the normal implication "and other similar stuff").  Orig. from the latin, but now common in English, and rather like the German z.b. (which I can't quite remember the expansion of).

In the context of computers, /etc is the root level directory where Linux/Unix programs get their configuration files, and where System V descendand versions of Unix (also Linux) systems get their boot time information about what services should be started, etc.

I'm not sure whether Walter was saying that there would literally be a library directory named etc, or whether he was saying the other similar directory names would exist.  (Both are plausible.)

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bntjhh$1srj$2@digitaldaemon.com...
> One man's hodgepodge is another man's freedom of expression.

Sure. But nobody using D is censored or constrained by the std conventions. D is a multiparadigm language.

> I really don't think obliging people to always favour exceptions is going
to
> fly. Exception-handling is the emporer's new clothes; nobody dares to
speak
> their qualms. That's not to say I don't use it, or believe it is useful,
but
> I've got both feet firmly in the Kernighan and Pike camp.

I'm not familiar with the reference.

> Exceptions are for
> exceptional circumstances.

Yes, I agree.

> I don't think all that is error-handling falls
> within that description.

There's certainly a grey area between clear errors and what is expected behavior.

> But, sure, other people have different opinions, and paradigms of work.
But
> that backs up my argument that we should support multiple programming paradigms.
>
> As to the consistency issue, I think that modules that are exclusively
free
> functions should not use exceptions for error-handling. Those that are class-based are another matter.

Why? Consider std.file.read(). It's a free function that reads the contents of a file into an array. It throws an exception if the file doesn't exist or if the read failed in some way. I use this function all the time, and find it very handy to rely on the exception mechanism to report errors rather than the C way of testing the result every time.

> I see three levels of APIs.
>
> 1. Raw C APIs
> 2. D-ified C APIs, and D free functions
> 3. Classes
>
> I am not arguing for much, if any, of 1, but I am arguing strongly that 2
is
> just as valid as 3.

I think we're misunderstanding each other, then, because I am in full agreement with you there!

"Roberto Mariottini" <Roberto_member@pathlink.com> wrote in message news:bntlcf$1v5t$1@digitaldaemon.com...
> In article <bntd28$1k51$1@digitaldaemon.com>, Walter says...
> >BTW, the etc.c.zlib is just as usable or unusable as the C zlib library
is,
> >as that's all it is. I find it more complex than necessary (there are a number of parameters you basically have to read the source code to zlib
to
> >figure out what they're good for and how to use them, that's
unacceptable),
> >it has a bunch of stuff related to storage allocation, and it uses error codes rather than exceptions. Hence, I decided a D wrapper that put an
easy
> >face on it made sense, and the result is std.zlib.
> BTW, have you thougt about making also a zip-file handling library in the
D
> standard libraries?
> I find this very useful to be included by default in every Java
implementation,
> for example.

Yes, I have thought of it, and I've already implemented std.zip. <g>. It will be in the next release. Great minds think alike!

> P.S.: I deduce that my proposal of renaming etc.* to ext.* was refused,
right?

When I see 'ext' I think 'external'. I kinda like 'etc', it is only 3 letters long and is a very common abbreviation for 'etcetera' and is not likely to be confused with anything else.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns94255512CA292patcodemooncom@63.105.9.61...
> Why not std.zlib and std.zlib.c?  This make more sense
> to me from a packageing standpoint.  Everything needed for the zlib
> module is in one directory hierarchy instead of two.

Because I don't see the raw zlib interface as being useful enough to be in the std heirarchy. I think of it as "it's there if you want it, but it isn't a core feature of the D library".

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bntgtv$1pdn$1@digitaldaemon.com...
> Good point. This made me think about the following:
>
> Is it possible to import a module without adding its symbols directly to the current namespace?
>
> Since C functions require different handling than D functions I would like to import such modules in a way so that I have to explicitly type std.c.func() instead of func(). Just as a reminder to myself and the people reading my code that one has to take care how to use them.
>
> This would be especially important for string functions, I expect, since
>   forgetting to add the null-terminator can cause a crash.
>
> Any way to do this?

No, there currently isn't a way to do that. BTW, import doesn't exactly add a symbol to the current namespace, it just adds a search of the import module if the name isn't already in the current namespace. In other words, any names in the current namespace override imported names.

Hmm, that does suggest a way to do it ... define a bunch of dummy symbols with the same name, then anyone using the import will be forced to qualify it!

In article <bnsadc$2mk7$1@digitaldaemon.com>, Ant says...
>
>std
>|-- c
>|   |-- process.d
>|   |-- stdio.d
>|   `-- stdlib.d
>|-- etc
>|-- internal
>|   |-- aaA.d
>|   |-- achar.d
>|   |-- adi.d
>|   |-- alloca.d
>|   |-- array.d

So, I made a script to move the lib files to the new structure.
I started to split the linux.mak
and I'm planing to create a couple of makefiles (or scripts) to:
- change the module declarations.
- change the import statments (should work both for the lib and apps)

Please stop me if it's not usefull!

All this on linux. I guess most of the conversions can be run
on linux and then the windows.mak would be easy to change
either from the old version or the new linux version (?).
windows users without make or sed are doomed as they will have to
convert their applications some other way.

I don't know if it possible to have a phobos set of files with just the import statments - for instance phobos/string.d would be just: /*public*/ import std.string;

that would keep things going for existing applications.

BTW are we going to make all imports on the lib "private"? (I already posted a makefile that does that)

Ant