A betterC modular standard library?

[Ilya Yaroshenko via Digitalmars-d]

On Sunday, 18 December 2016 at 17:41:31 UTC, Walter Bright wrote:
> On 12/18/2016 1:26 AM, Ilya Yaroshenko wrote:
>> We already have better `cpuid` and better `random` packages.
>
> Great! Please PR them for Phobos.

cpuid is used in Mir GLAS and it should be a betterC library. 
Without DRuntime dependency because DRuntime has not backward 
binary compatibility and has not compatibility between different 
compilers.

 From my reply to Andrei:

----
Linking compatibility. Assume A has builded a betterC library AA 
using GDC version XXX and B has builded a betterC library BB 
using LDC version YYY.

Question: how mister C can use BB and AA together in his 
C-library if both this libraries depends on different DRuntimes 
(compiler and version)?
----

mir-glas and mir-cpuid are libraries with extern(C) interface for 
all languages. It is silly to build a BLAS implementation only 
for one language.

>> The betterC
>> std.range and std.algorithm analogs would be released with new 
>> ndslice
>> implementation. Mir's algorithm would be faster then Phobos 
>> and will generate
>> less template bloat. Then lightweight threads, multithread 
>> GLAS, matrix
>> inversion. Fastest I/O and http2 ...
>>
>> (they all are betterC modular libraries)
>
> Propose them for Phobos!

First I need to implement them and announce for the community. 
Then community will say "What he is doing??? C++ iterators, 
really?" Hehe

This is reason why ndslice is deprecated in Phobos. It requires 
another std.algorithm and std.range. I am not able to implement 
all this ideas in Phobos PRs: it is requires too much time. In 
addition, I can not use Phobos for other reasons.

>> Andrei and probably 90% of existing D users don't want Phobos 
>> to move this
>> direction.
>
> I don't understand that point. What direction?

1. Modularity: D should provide a very slim library (like 
std.traits and may be default GC with old core, which can be 
turned off or replaced). Other parts or Phobos/Druntime should be 
split into parts and the parts should have their own 
repositories. They should be dub packages with D Foundation 
review / control.

2. Low-level API first! A high level OOP/GC-oriented API can be 
provided later or can be provided in DUB libraries.

3. betterC guaranties / No problems with backward binary 
compatibility for betterC libs. This means that code should be 
templated / inlined. Some parts, like Exceptions and GC may have 
this problems, but Exceptions and GC should be optional language 
features and they are not a part of betterC mode.

>> In other hand I need a commercial attractive D infrastructure 
>> for large and
>> heavy system projects. There is no commercial perspective for 
>> me to contribute
>> to Phobos because:
>>
>> 1. Phobos version depends on compiler version. Delay with LDC 
>> release is too
>> large. It should / can be one day.
>
> The language evolves over time, and the standard library must, 
> too. It happens with every language.

Agreed. Because that it is more flexible to have a very slim std 
library with good set of community supported libraries.

This is a reason why almost all portable multi-language numeric 
libraries are written in C. C runtime is slim and evaluates 
very-very slow.

>> 2. We can not do hot fixes in Phobos without compiling and 
>> deploying patched
>> libphobos. Mir's DUB package are much more flexible.
>>
>> 3. Dependencies should be clear. Modularity is a proper way 
>> for large std
>> library. In phobos everything integrated with everything. 
>> DRuntime -> Phobos
>> abstraction is weird for betterC because system modules can 
>> depends universal
>> algorithms, but universal algorithm are more portable if they 
>> have not system
>> dependencies.
>
> Not sure what you mean. Algorithms in Phobos are not dependent 
> on system idiosyncracies.

They are, for example they depends on RangeErrors. See
https://github.com/dlang/phobos/pull/4937

>> 4. Phobos does not provide and will not provide betterC 
>> guaranties. If something
>> works for betterC mode now it may not work in the future 
>> release.
>
> I've done a fair amount of work to remove such things. Clearly 
> more can and should be done.
>
> Generally, we do have a goal of making Phobos entirely "pay as 
> you go" instead of being so interconnected (which is what 
> betterC is really all about). We can definitely use help in 
> improving that and helping it along.

Great. Why not to go to the proposed direction:
     1 Modularity,
     2 Low-level API first,
     3 betterC guaranties?

Thank you,
Ilya