Also now that dip1008 is implemented (using exceptions in @nogc) what is preventing it from happening?

On 22/04/2019 7:23 AM, Igor wrote:
> Also now that dip1008 is implemented (using exceptions in @nogc) what is preventing it from happening?

Classes.

On Sunday, 21 April 2019 at 19:23:19 UTC, Igor wrote:
> Also now that dip1008 is implemented (using exceptions in @nogc) what is preventing it from happening?

The fundamental problem with having Exceptions in betterC is that Exceptions are classes, and classes require runtime support in D.  I think the stack unwinding implementations are also in druntime.

betterC imports druntime, but doesn't link to it.  Therefore, anything in druntime that is not implemented as a template is not going to be available to betterC.

There is a GSoC project that is planned for this year to convert many runtime features to templates.  That could potentially make more features of D available to betterC builds, but the templates themselves will also need to be modified to use templates all the way down the stack.

There is another GSoC project planned for this year to convert some of that low level code to templates as well, so that could help.

There is also talk of a new class hierarchy that may be lighter weight and may allow exception handling with less runtime support:  http://dconf.org/2019/talks/staniloiu.html  We'll have to wait until DConf to know more.

All of that work will eventually bring us closer to the "opt-in continuum" that Andrei mentioned here:  https://forum.dlang.org/post/q7j4sl$17pe$1@digitalmars.com

But, that is going to take years with current manpower and governance practices.  I don't know if we'll ever have classes or throw and catch facilities in betterC.  I think if the aforementioned opt-in continuum were achieved we wouldn't even need betterC.

Anyway, there are plans to make light-weight opt-in programming in D better (a betterD rather than a betterC), but it's going to take time to get there.  We need more people able and willing to do the work to accelerate it.  If you have the skills and want to help, let me know.  I can at least help reduce the barrier to entry for new contributors.

Mike

On Monday, 22 April 2019 at 01:58:34 UTC, Mike Franklin wrote:
> Anyway, there are plans to make light-weight opt-in programming in D better (a betterD rather than a betterC), but it's going to take time to get there.  We need more people able and willing to do the work to accelerate it.  If you have the skills and want to help, let me know.  I can at least help reduce the barrier to entry for new contributors.
>
> Mike

Hello Mike,

I'm interested in making D suitable for bare metal programming.
Currently I am slowly finishing my toy project: porting RISC-V emulator from C to D. And later I want to use it to run D programs.

It would be good to synchronize all related work. If I understood you correctly, Andrei statement means green light to refinement of the D standard library in the spirit you were advocating?

Cheers,
Piotrek

On Friday, 3 May 2019 at 11:34:11 UTC, Piotrek wrote:

> It would be good to synchronize all related work. If I understood you correctly, Andrei statement means green light to refinement of the D standard library in the spirit you were advocating?

The only thing I know of that Andrei has green-lighted is converting runtime hooks to templates.  I think it's something he's been trying to get done for years.  The first PRs I saw for it were from Lucia Cojocaru.  She did the `__equals` and `__cmp` templates and gave a presentation for it at DConf (https://www.youtube.com/watch?v=endKC3fDxqs)

Since Lucia left, there hasn't really been anyone else working on it except me.  Unfortunately, I had a lot to learn and couldn't do anything until I figured a few things out.  I feel that I finally have a pretty good understanding of what to do and how, but I'm trying to clean up some unfinished business before I get back to it.  If you want to start working converting the remaining runtime hooks to templates, let me know and I'll share what I know.

The 2nd task that I think is important right now is to make a dependency-less utility library.  I have never discussed this with anyone except on the forum, so I don't know what Andrei or anyone else thinks of it.  I wish I had more of an opportunity to discuss things like this on a regular basis with other D developers, but I don't know how to facilitate that.

You can get a basic understanding of what needs to be done by looking at the following module pairs:
std.traits  core.internal.traits
std.conv    core.internal.convert
std.utf     core.internal.utf
{... there are others ...}
Next, see this discussion (https://forum.dlang.org/post/mailman.6241.1546722791.29801.digitalmars-d@puremagic.com) about creating a `core.traits` module to get a better perspective.

Do you see the redundancy?

What you'll likely notice is that there are many utilities in Phobos that could also be utilized to implement things in druntime, DMD, and bare-metal programs.  Candidates include `std.meta`, `std.traits`, `std.conv`, and many more.

Therefore, I propose pulling all of those useful utilities, that don't require druntime for their implementation, out of Phobos and into their own library that can be imported by druntime, DMD, and bare-metal projects.  I'm calling this library "utiliD".

The rules for this library are simple:
1.  No dependencies whatsoever.  No dependencies on C standard library, druntime, OS bindings, etc...
2.  No dynamic heap memory allocation.  Dynamic stack memory allocation is ok.

Finally, the 3rd thing I have in mind is to re-implement `memcpy`, `memcmp`, `malloc`, `free` and friends in D.  Here's a little exploration I did for `memcpy` (https://github.com/JinShil/memcpyD).  Note how it utilizes D's metaprogramming features.  I can elaborate further on this if you're interested.

GSoC proposals were submitted for the 1st and 3rd tasks.  Accepted proposals are to be announced May 6th, so if you're interested in either one of them, you'll want to be sure not to duplicate or interfere with those tasks, should they be accepted.

That's where I'm at right now.  I don't know if that's of any use to you, but I'm here if you wish to discuss these topics or others further.  You can find me on Slack and Discord under the handle JinShil should you wish to have more of a dialog.

Mike

On Fri, May 03, 2019 at 01:30:01PM +0000, Mike Franklin via Digitalmars-d wrote: [...]
> The 2nd task that I think is important right now is to make a dependency-less utility library.  I have never discussed this with anyone except on the forum, so I don't know what Andrei or anyone else thinks of it.  I wish I had more of an opportunity to discuss things like this on a regular basis with other D developers, but I don't know how to facilitate that.

Have the forums become so toxic that we can no longer use them for what they're supposed to be used for -- to discuss exactly these sorts of things??


> You can get a basic understanding of what needs to be done by looking
> at the following module pairs:
> std.traits  core.internal.traits
> std.conv    core.internal.convert
> std.utf     core.internal.utf
> {... there are others ...}
> Next, see this discussion (https://forum.dlang.org/post/mailman.6241.1546722791.29801.digitalmars-d@puremagic.com)
> about creating a `core.traits` module to get a better perspective.
> 
> Do you see the redundancy?
[...]

Didn't Andrei say recently that these two should be merged into one? The Phobos/druntime divide is an artifact of the historical Phobos vs. Tango spat, and really shouldn't be that way.  Phobos should be made (much, much) more pay-as-you-go, and druntime should be a subset of it, not a separate thing from which it's taboo to import Phobos.


T

-- 
Why have vacation when you can work?? -- EC

On Friday, 3 May 2019 at 15:09:34 UTC, H. S. Teoh wrote:
> Have the forums become so toxic that we can no longer use them for what they're supposed to be used for -- to discuss exactly these sorts of things??

Sorry if that came across the wrong way.  What I meant is that I find it difficult and sluggish to do much productive back-and-forth on the forums. What I really need is to be able to quickly bounce ideas back and forth with like-minding, interested participants, and eventually arrive at a common understanding.  I find that difficult on the forums.  Chatting is better, and verbal communication is even better.  I don't find the forums toxic, I just haven't found a way to utilize the forums to bring together common interests and arrive at a common understanding.  I'm ready to engage any one who's willing.

> Didn't Andrei say recently that these two should be merged into one? The Phobos/druntime divide is an artifact of the historical Phobos vs. Tango spat, and really shouldn't be that way.  Phobos should be made (much, much) more pay-as-you-go, and druntime should be a subset of it, not a separate thing from which it's taboo to import Phobos.

Yes, I think that's an accurate interpretation.  I'll paraphrase further by saying users would essentially `import` the language features they want or need.  Or, they would opt-in to a language feature simply by choosing to use it.

DRuntime and Phobos is currently a big pot of spaghetti with each noodle being one of language implementation, compiler intrinsics, common utilities, garbage collection, thread-local storage, threads, fibers, stack unwinding, debug symbols, algorithms, ranges, C standard library bindings, OS bindings, C++ standard library bindings (unfortunately), and much more.  To achieve the opt-in continuum Andrei mentioned, I believe we need more modularity and less coupling.  The first step towards that, IMO, is to create a utility library that has no dependencies whatsoever.  All other libraries, language implementations, and even the compiler itself could then begin their implementations by importing that fundamental utility library.  Of course, you wouldn't have to import it if you didn't want to, but it would be highly productive and idiomatic-D to do so.

Mike

On 04/05/2019 4:01 AM, Mike Franklin wrote:
> On Friday, 3 May 2019 at 15:09:34 UTC, H. S. Teoh wrote:
>> Have the forums become so toxic that we can no longer use them for what they're supposed to be used for -- to discuss exactly these sorts of things??
> 
> Sorry if that came across the wrong way.  What I meant is that I find it difficult and sluggish to do much productive back-and-forth on the forums. What I really need is to be able to quickly bounce ideas back and forth with like-minding, interested participants, and eventually arrive at a common understanding.  I find that difficult on the forums.  Chatting is better, and verbal communication is even better.  I don't find the forums toxic, I just haven't found a way to utilize the forums to bring together common interests and arrive at a common understanding. I'm ready to engage any one who's willing.

So a workgroup? ;)

We have the graphics workgroup over on Discord, and we can add another channel if you want to setup there.

On Fri, May 03, 2019 at 04:01:57PM +0000, Mike Franklin via Digitalmars-d wrote:
> On Friday, 3 May 2019 at 15:09:34 UTC, H. S. Teoh wrote:
> > Have the forums become so toxic that we can no longer use them for what they're supposed to be used for -- to discuss exactly these sorts of things??
> 
> Sorry if that came across the wrong way.  What I meant is that I find it difficult and sluggish to do much productive back-and-forth on the forums.  What I really need is to be able to quickly bounce ideas back and forth with like-minding, interested participants, and eventually arrive at a common understanding.  I find that difficult on the forums.  Chatting is better, and verbal communication is even better. I don't find the forums toxic, I just haven't found a way to utilize the forums to bring together common interests and arrive at a common understanding.  I'm ready to engage any one who's willing.
[...]

Fair enough.


> [...]  To achieve the opt-in continuum Andrei mentioned, I believe we need more modularity and less coupling.

Yes.  Phobos, in my mind, ought to be maximally pay-as-you-go, meaning, if you don't use a particular feature, you pay nothing -- no new symbols are imported, no functions or data ends up in the executable, no TypeInfo's, etc..  Even the functions themselves should be designed in a minimalistic way: if the user only needs the bare basics of an algorithm without any frills, then there should be no hidden dependencies on said frills.  (They can still be optionally available for those who want them.)

An anti-example is std.format.format: the bare act of using format!"%s"(str) pulls in *all sorts* of dependencies, like floating-point formatting code, number-parsing code, and, last time I checked, even std.bigint and/or std.complex, for whatever reason. Given that we know the format string at compile-time, in theory we ought to be able to eliminate all but the bare minimum required for that particular format string to work.  If all we use is "%s", then it should translate more-or-less to a single `write(fd, buf, buf.length)` call to the OS. None of the other stuff like floating-point formatting code, needless to say std.bigint / std.complex, should be pulled in.


> The first step towards that, IMO, is to create a utility library that has no dependencies whatsoever.  All other libraries, language implementations, and even the compiler itself could then begin their implementations by importing that fundamental utility library.  Of course, you wouldn't have to import it if you didn't want to, but it would be highly productive and idiomatic-D to do so.
[...]

I've given a lot of thought to reusable components lately. More and more, I'm coming to the conclusion that proper API design is absolutely essential.  If designed wrongly, an API will essentially *force* dependencies upon all of its users, and this effect compounds across multiple nested APIs, the end result being an inseparable hairball of dependency hell that you have to either import all of it, or not at all.

There's too much to write about on this topic and I don't have the time right now, but basically, APIs should as much as possible stick to universal data representations (i.e., use built-in types as much as possible, and avoid custom types unless absolutely indispensible; prefer simple representations over complex, frilly ones); prefer no hidden state or global state except where said state is the raison d'etre of the module; be maximally decoupled: avoid exposing any data or functions from dependencies (if module X depends on module Y for its implementation, module Y should be completely invisible in module X's public API), and be as composable as possible. If there's an existing idiom for modules of similar functionality, use the existing idiom rather than inventing a new one (don't reinvent the range API). As much as possible, unify the style and structure of your APIs so that any primitive X can serve as a drop-in for any other primitive Y. Minimize special cases -- because they add complexity that compounds with every additional API you use.  Make the absolutely minimal number of assumptions you need to get your job done, and no more.  Etc.. Prefer not having any dependencies at all, unless you absolutely cannot get the job done without.  Remember, dependency resolution is NP-complete; avoid dependency hell.

Preferably, the data you get from module X should be completely usable with unrelated module Y, modulo trivial interconversion (though no conversion at all is preferred). Similarly, an arbitrary function from module X should be arbitrarily composable with any function from unrelated module Y. Function signatures should be designed for maximum composability and universality, and should avoid quirky parameter ordering (e.g., std.algorithm.reduce vs. std.algorithm.fold) or idiosyncrasies peculiar to that module.  As far as possible, every function should be independently testable with minimal setup and no global side-effects.

Gotta go, but there's a LOT to say on this topic.


T

-- 
Political correctness: socially-sanctioned hypocrisy.

On Friday, 3 May 2019 at 16:43:10 UTC, rikki cattermole wrote:

> So a workgroup? ;)
>
> We have the graphics workgroup over on Discord, and we can add another channel if you want to setup there.

Perhaps that would work.  But who's willing to meet me there?  A workgroup of 1 isn't much of a workgroup.

Mike