Yes, I do.

I don't like that part. I think modules should be broken down logically, rather on implementation details.

I don't care if something is implemented in C or in D, rather what it can do for me.

There's a deeper aspect to this. I'm biased on this issue, so you'll have to take the following with a pinch of salt.

For those of you who do not know, I'm creating a platform-independent, source-supplied, recursive searching library called recls (http://recls.org/), and documented in my bi-monthly in-print CUJ column. It is implemented in C/C++, presents a C interface to the world, and it is to be mapped to just about any language you can think of (C++, D, Java, .NET, Perl, Python, Ruby, etc.). There's a beta D mapping available at the website.

I can't see any reason why recls, and similar libraries, can't become part of the standard distribution of D, since there're no royalty implications. However, since it is written in C/C++, it is not 100% pure D. This is absolutely no impediment to using D on Win32 or UNIX, and I would bet that recls will be ported to MAC and other platforms before D is. (Even if it's not, it would be a simple matter to do so.)

People who've used the library so far have said it's very useful (some have commented that it's the rec-search they always wanted, which is nice), but I think it will be rejected by the DLG (if we ever get one) because it's not D.

Anyway, feel free to dismiss this as a self-promotion rant, but I think it's a good example of an issue we're going to come up against a great deal. Why reject, or cause to be rewritten, or squirrel away in the "dirty C corner" libraries that already exist (and is tested), since D makes a big point of C compatibility in the first place?


-- 
Matthew Wilson

STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"You can tell a Yorkshireman, but you can't tell him much!" -- Uncle Michael

----------------------------------------------------------------------------
---



"Ant" <Ant_member@pathlink.com> wrote in message news:bns6d8$2gv2$1@digitaldaemon.com...
> In article <bnn9a0$1o09$1@digitaldaemon.com>, Walter says...
>
>
> >std.c
> > Contains D interfaces to standard C library functions, like std.c.stdio, std.c.stdlib, std.c.math.
>
> kinda like puting together stawberies and chilly peppers because they are the same color...
>
> (I know Walter will never change his mind (reverse psychology)
> but the rest of you has to agree ;)
>
> Ant
>
>

In article <bnn9a0$1o09$1@digitaldaemon.com>, Walter says...
>
>There have been a lot of good ideas and points made about this in the
>discussions here. The upshot is there isn't a single right answer,
>but there are a few clearly wrong ones <g>. So it's up to me to just pick
>one of the right answers.
>

Do you mean:

##########################

std
|-- c
|   |-- process.d
|   |-- stdio.d
|   `-- stdlib.d
|-- etc
|-- internal
|   |-- aaA.d
|   |-- achar.d
|   |-- adi.d
|   |-- alloca.d
|   |-- array.d
|   |-- arraycast.d
|   |-- arraycat.d
|   |-- assert.d
|   |-- cast.d
|   |-- critical.c
|   |-- dmain2.d
|   |-- errno.c
|   |-- gc.d
|   |-- gc2
|   |-- gcstats.d
|   |-- intrinsic.d
|   |-- invariant.d
|   |-- llmath.d
|   |-- mars.h
|   |-- memset.d
|   |-- minit.asm
|   |-- moduleinit.d
|   |-- monitor.c
|   |-- obj.d
|   |-- object.d
|   |-- outofmemory.d
|   |-- switch.d
|   `-- switcherr.d
|-- os
|   |-- linux
|   |   |-- linux.d
|   |   `-- linuxextern.d
|   |-- windows
|   |   |-- com.d
|   |   |-- iunknown.d
|   |   |-- registry.d
|   |   |-- syserror.d
|   |   `-- windows.d
|   |-- date.d
|   |-- file.d
|   |-- path.d
|   |-- system.d
|   |-- thread.d
|   `-- time.d
|-- typeinfo
|   |-- ti_AC.d
|   |-- ti_Aa.d
|   |-- ti_Adchar.d
|   |-- ti_Ag.d
|   |-- ti_Aint.d
|   |-- ti_Along.d
|   |-- ti_Ashort.d
|   |-- ti_Aubyte.d
|   |-- ti_Auint.d
|   |-- ti_Aulong.d
|   |-- ti_Aushort.d
|   |-- ti_Awchar.d
|   |-- ti_C.d
|   |-- ti_byte.d
|   |-- ti_cdouble.d
|   |-- ti_cfloat.d
|   |-- ti_char.d
|   |-- ti_creal.d
|   |-- ti_dchar.d
|   |-- ti_delegate.d
|   |-- ti_double.d
|   |-- ti_extended.d
|   |-- ti_float.d
|   |-- ti_idouble.d
|   |-- ti_ifloat.d
|   |-- ti_int.d
|   |-- ti_ireal.d
|   |-- ti_long.d
|   |-- ti_ptr.d
|   |-- ti_real.d
|   |-- ti_short.d
|   |-- ti_ubyte.d
|   |-- ti_uint.d
|   |-- ti_ulong.d
|   |-- ti_ushort.d
|   `-- ti_wchar.d
|-- cmath2.d
|-- compiler.d
|-- complex.c
|-- conv.d
|-- crc32.d
|-- ctype.d
|-- dateparse.d
|-- deh.c
|-- deh2.d
|-- linux.mak
|-- math.d
|-- math2.d
|-- outbuffer.d
|-- qsort.d
|-- random.d
|-- regexp.d
|-- stdint.d
|-- stream.d
|-- string.d
|-- unittest.d
|-- uri.d
|-- utf.d
`-- win32.mak

7 directories, 103 files

##########################

would makefiles for this be a good thing?
would a conversion for existing source files be a good thing
(same type as the makePrivate I made) ?

Ant

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bns6u8$2hnq$1@digitaldaemon.com...
> I don't care if something is implemented in C or in D, rather what it can
do
> for me.

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.

D conventions would be using exceptions for error notification, length'd (!) strings, garbage collection, COW, etc.

A typical C package can be 'wrapped' to give it D conventions, and then it would be suitable for inclusion in a non-C heirarchy. I am currently working on a D version of the popular zlib module for just that reason. The underlying implementation will remain in C (it's a pointless waste of time to convert that code to D).

> Anyway, feel free to dismiss this as a self-promotion rant, but I think
it's
> a good example of an issue we're going to come up against a great deal.
Why
> reject, or cause to be rewritten, or squirrel away in the "dirty C corner" libraries that already exist (and is tested), since D makes a big point of
C
> compatibility in the first place?

I'd call it the "C corner", not the "dirty C corner" <G>. All that would mean to the D user of the package would be he'd need to double check things like 0 terminated strings, returned error codes, storage allocation, and other C conventions.

That looks mostly right. Conversion of source would be a bit of a pain, but not too bad. I have a program that can do global search/replace across files.

"Ant" <Ant_member@pathlink.com> wrote in message news:bnsadc$2mk7$1@digitaldaemon.com...
> In article <bnn9a0$1o09$1@digitaldaemon.com>, Walter says...
> >
> >There have been a lot of good ideas and points made about this in the
> >discussions here. The upshot is there isn't a single right answer,
> >but there are a few clearly wrong ones <g>. So it's up to me to just pick
> >one of the right answers.
> >
>
> Do you mean:
>
> ##########################
>
> std
> |-- c
> |   |-- process.d
> |   |-- stdio.d
> |   `-- stdlib.d
> |-- etc
> |-- internal
> |   |-- aaA.d
> |   |-- achar.d
> |   |-- adi.d
> |   |-- alloca.d
> |   |-- array.d
> |   |-- arraycast.d
> |   |-- arraycat.d
> |   |-- assert.d
> |   |-- cast.d
> |   |-- critical.c
> |   |-- dmain2.d
> |   |-- errno.c
> |   |-- gc.d
> |   |-- gc2
> |   |-- gcstats.d
> |   |-- intrinsic.d
> |   |-- invariant.d
> |   |-- llmath.d
> |   |-- mars.h
> |   |-- memset.d
> |   |-- minit.asm
> |   |-- moduleinit.d
> |   |-- monitor.c
> |   |-- obj.d
> |   |-- object.d
> |   |-- outofmemory.d
> |   |-- switch.d
> |   `-- switcherr.d
> |-- os
> |   |-- linux
> |   |   |-- linux.d
> |   |   `-- linuxextern.d
> |   |-- windows
> |   |   |-- com.d
> |   |   |-- iunknown.d
> |   |   |-- registry.d
> |   |   |-- syserror.d
> |   |   `-- windows.d
> |   |-- date.d
> |   |-- file.d
> |   |-- path.d
> |   |-- system.d
> |   |-- thread.d
> |   `-- time.d
> |-- typeinfo
> |   |-- ti_AC.d
> |   |-- ti_Aa.d
> |   |-- ti_Adchar.d
> |   |-- ti_Ag.d
> |   |-- ti_Aint.d
> |   |-- ti_Along.d
> |   |-- ti_Ashort.d
> |   |-- ti_Aubyte.d
> |   |-- ti_Auint.d
> |   |-- ti_Aulong.d
> |   |-- ti_Aushort.d
> |   |-- ti_Awchar.d
> |   |-- ti_C.d
> |   |-- ti_byte.d
> |   |-- ti_cdouble.d
> |   |-- ti_cfloat.d
> |   |-- ti_char.d
> |   |-- ti_creal.d
> |   |-- ti_dchar.d
> |   |-- ti_delegate.d
> |   |-- ti_double.d
> |   |-- ti_extended.d
> |   |-- ti_float.d
> |   |-- ti_idouble.d
> |   |-- ti_ifloat.d
> |   |-- ti_int.d
> |   |-- ti_ireal.d
> |   |-- ti_long.d
> |   |-- ti_ptr.d
> |   |-- ti_real.d
> |   |-- ti_short.d
> |   |-- ti_ubyte.d
> |   |-- ti_uint.d
> |   |-- ti_ulong.d
> |   |-- ti_ushort.d
> |   `-- ti_wchar.d
> |-- cmath2.d
> |-- compiler.d
> |-- complex.c
> |-- conv.d
> |-- crc32.d
> |-- ctype.d
> |-- dateparse.d
> |-- deh.c
> |-- deh2.d
> |-- linux.mak
> |-- math.d
> |-- math2.d
> |-- outbuffer.d
> |-- qsort.d
> |-- random.d
> |-- regexp.d
> |-- stdint.d
> |-- stream.d
> |-- string.d
> |-- unittest.d
> |-- uri.d
> |-- utf.d
> `-- win32.mak
>
> 7 directories, 103 files
>
> ##########################
>
> would makefiles for this be a good thing?
> would a conversion for existing source files be a good thing
> (same type as the makePrivate I made) ?
>
> Ant
>
>

> > I don't care if something is implemented in C or in D, rather what it
can
> do
> > for me.
>
> 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.
>
> D conventions would be using exceptions for error notification, length'd
(!)
> strings, garbage collection, COW, etc.
>
> A typical C package can be 'wrapped' to give it D conventions, and then it would be suitable for inclusion in a non-C heirarchy. I am currently
working
> on a D version of the popular zlib module for just that reason. The underlying implementation will remain in C (it's a pointless waste of time to convert that code to D).
>
> > Anyway, feel free to dismiss this as a self-promotion rant, but I think
> it's
> > a good example of an issue we're going to come up against a great deal.
> Why
> > reject, or cause to be rewritten, or squirrel away in the "dirty C
corner"
> > libraries that already exist (and is tested), since D makes a big point
of
> C
> > compatibility in the first place?
>
> I'd call it the "C corner", not the "dirty C corner" <G>. All that would mean to the D user of the package would be he'd need to double check
things
> like 0 terminated strings, returned error codes, storage allocation, and other C conventions.

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?

In article <bnseuj$2t1h$2@digitaldaemon.com>, Walter says...
>
>That looks mostly right. Conversion of source would be a bit of a pain, but not too bad. I have a program that can do global search/replace across files.

Just forgot to create the gc2 dir.
All gc2 stuff will go under std.internal.gc2 (?).

To convert existing sources I was thinking of
a makefile with something like:

FILES=$(wildcard *.d)
$(FILES):
  sed -e 's/import com;/import os\.windows\.com;/g' \
      $@ > $(NEW_LOCATION)/$@

(unless your program is better)
that worked to convert all "import" in phobos to "private import"

Ant

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

I don't have sed, but yeah, something like that should cover about 90% of the work. std.internal.gc is probably the right place for the gc implementation.

"Ant" <Ant_member@pathlink.com> wrote in message news:bnshaa$30cd$1@digitaldaemon.com...
> In article <bnseuj$2t1h$2@digitaldaemon.com>, Walter says...
> >
> >That looks mostly right. Conversion of source would be a bit of a pain,
but
> >not too bad. I have a program that can do global search/replace across files.
>
> Just forgot to create the gc2 dir.
> All gc2 stuff will go under std.internal.gc2 (?).
>
> To convert existing sources I was thinking of
> a makefile with something like:
>
> FILES=$(wildcard *.d)
> $(FILES):
>   sed -e 's/import com;/import os\.windows\.com;/g' \
>       $@ > $(NEW_LOCATION)/$@
>
> (unless your program is better)
> that worked to convert all "import" in phobos to "private import"
>
> Ant
>
>

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

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.

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.

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.

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