D: A language without focus

[Anders F Björklund]

gabe wrote:

> Second:
> I've heard back from a few people about having a small core library.  I can
> certainly respect that: coming from Java, I know what it feels like to have a
> glut of options.  On the other hand, one of the undeniable draws for a language
> is a substantial library of well-tested code.  The functionality of a language
> is, in this sense, directly reflected in the composition of its libraries.  To
> that end, I would propose a two-tiered solution.  On the first tier, there sits
> two basic libraries: 'lang' and 'sys'.  Unlike Java, which hides much of the
> implementation details of the system, D users should be allowed the freedom to
> deal directly with the hardware and the underlying system when needed.  For this
> reason, the sys and the lang packages will supply all of the basic functionality
> needed for D to run in any environment.  This should especially appeal to
> systems programmers and library implementers, as one can hide a good deal of
> existing c code behind some carefully constructed interfaces or superior
> packaging.  The 'lang' package, in particular, needs the 'sys' libs in order to
> deliver all of the low-level coding required by each operating system, thus, I
> believe, releiving even some of the lower details from language implementors.

Q: How is this different from how D things currently work ?
We have Phobos/Ares ('lang') calling the C library ('sys')

All that is needed to use C libraries is to write an import
module, for C++ you need to export it as extern "C" {} first.

So I think it already works this way, it's how I am using it.

> It should be the case that these two packages are automatically searched and
> compiled into any running program, though the top level DPATH may only refer to
> '/usr/include/d/', or whatnot.  

The standard install of GDC uses e.g. /usr/include/d/3.3.6,
(where the version signifies the GCC that it was built with)
for including the std Phobos/runtime files from the compiler.

It used to search /usr/include/d as well, for user libraries,
but I think it doesn't anymore (had to add: -I/usr/include/d)
I think /usr/include/d is good, the same as /usr/include/c++

The C library is used automatically, and then it adds: -lphobos
(DMD uses "gcc" to link, while GDC normally uses "gdc" there too)

So both the C and D libraries are searched and included already ?

> The second part of this teir delivers everything else that the core library
> lacks, including complicated IO, data structures, utilities, ui components, and
> parsers.  I've given a rough outline of what the library might looklike below.
> Of course, much of my model liberally samples (i.e. outright steals) from the
> Java and C# library implementations.  This is the way I feel that it should be
> -- each language should stand on the shoulders of the one that came before it --
> and I think each of those languages are quite good at packaging together
> disparate pieces.  Of course, we wouldn't import from d.xxx -- we can drop the
> 'd.' syntax entirely once the compiler supports native library builds; I always
> did resent the whole 'import java....' fiasco.  This seems to be an ok solution
> as long as we make sure that we don't conflict with URL domains in these
> top-level directories.  

Adding all those features to *one* single library / project,
would make it quite heavy and rather big - don't you think ?

But Mango does cover a fair lot of the "server" ones now...
DWT was supposed to cover GUI, but it seems to be in trouble.

> ----- ERL - Extended Runtime Library ------
[...]
> os (or 'kaos', for nameing conflicts [kernel and o/s] -- hsa mythic overtones)
> posix
> c
> windows
> c
> ..
> com
> ..
> dotnet
> linux
> c

GDC is currently divided into Windows and Unix (*not* Posix !),
which I think is an improvement over what DMD has (only linux)

std.windows.*
std.unix.*

std.c.windows.*
std.c.unix.*

The different Unix platforms are available too, mostly empty:
linux/darwin/freebsd/cygwin/aix/solaris, plus any future ones.

> ui 
> curses
> thea (D language graphical system based on the qt framework)
> opengl
> window
> ..
> ..

Another UI framework ? Didn't know there was a working Qt->D wrapper ?
(then again the DIUP port looks promising, for any simple interfaces)

> One last thing before I slip off to bed: I really want to rally around an open
> source license for this project, particularly one that strives for complete
> transparency.  Not only does this really promote a sense of sharing and
> community, but I feel that it also gives newcomers and old hackers some ideals
> to really identify with.  To that end I would suggest the GPL as the starting
> point -- possibly even liscenesed under some kind of dual GPL/LGPL liscense.
> This kind of transparency, I feel, really invites people to the table in an
> egalitarian and communal way.  (Not to mention the fact that putting it under
> the GPL opens up the floodworks for linking into other GPL code -- and there's
> tons of it.)

But many people hate the GPL with a passion... So a common solution is a
dual GPL/proprietary license (like DMD), or a BSD license (like Phobos)

And both Public Domain and LGPL/wxWidgets licenses are used for some big 
D existing projects, too. (e.g. MinWin, wxD) There's lots of options...

--anders