www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Any estimates on having exceptions in betterC?

reply Igor <stojkovic.igor gmail.com> writes:
Also now that dip1008 is implemented (using exceptions in  nogc) 
what is preventing it from happening?
Apr 21
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
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.
Apr 21
prev sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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
Apr 21
parent reply Piotrek <none invalidnone.pl> writes:
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
May 03
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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.digitalm rs-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
May 03
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
May 03
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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
May 03
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
May 03
parent Mike Franklin <slavo5150 yahoo.com> writes:
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
May 03
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
May 03
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Friday, 3 May 2019 at 16:59:29 UTC, H. S. Teoh wrote:

 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.
I'm not proposing a new API, but I'm not against it either. What I'm proposing is to just copy over the existing APIs in Phobos that don't require druntime for their implementation. It would probably be a good idea to exclude any API from Phobos that is considered a mistake. And, of course, some Phobos implementations do require druntime and dynamic memory allocation, so those would also be excluded, but everything else (that makes sense) could be copied over to the library I'm proposing. Those familiar with Phobos would feel right at home using this library. Mike
May 03
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, May 03, 2019 at 10:52:10PM +0000, Mike Franklin via Digitalmars-d wrote:
 On Friday, 3 May 2019 at 16:59:29 UTC, H. S. Teoh wrote:
[...]
 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.
I'm not proposing a new API, but I'm not against it either. What I'm proposing is to just copy over the existing APIs in Phobos that don't require druntime for their implementation. It would probably be a good idea to exclude any API from Phobos that is considered a mistake.
[...] Understood. Still, now would be a good time to start vetting which APIs are more likely to be beneficial in the long term, and which APIs will only lead to dependency hell later on. Leave the poor choices in the past; pick out the cream and leave the dregs behind. Then, build on this refined core something new and more wonderful.
 And, of course, some Phobos implementations do require druntime and
 dynamic memory allocation, so those would also be excluded, but
 everything else (that makes sense) could be copied over to the library
 I'm proposing.  Those familiar with Phobos would feel right at home
 using this library.
[...] Would love to see where this leads. Hopefully it won't peter out before it has something to show. T -- Talk is cheap. Whining is actually free. -- Lars Wirzenius
May 03
parent Mike Franklin <slavo5150 yahoo.com> writes:
On Friday, 3 May 2019 at 23:19:38 UTC, H. S. Teoh wrote:

 Would love to see where this leads.  Hopefully it won't peter 
 out before it has something to show.
Well, I need help. I'm currently preoccupied trying to fix a few compiler bugs so I can start refactoring druntime and begin converting runtime hooks to templates. That's going to keep me busy for at least a year, unless others jump in. I won't even be able to start working on this until after that. If anyone likes the idea and is ready to volunteer their time and effort towards it, let's get it going. Who's willing to jump in, help me create the repository, CIs, and start submitting PRs? Mike
May 03
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2019-05-03 15:30, Mike Franklin 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.
DConf would be a great place for that, but it might be too long between the conferences. -- /Jacob Carlborg
May 04
parent Mike Franklin <slavo5150 yahoo.com> writes:
On Saturday, 4 May 2019 at 13:50:01 UTC, Jacob Carlborg wrote:

 DConf would be a great place for that, but it might be too long 
 between the conferences.
Yes, but I regret that I won't be there. Looking at the AGM agenda (https://github.com/thewilsonator/Dlang-AGM) it appears you'll have plenty to talk about and don't need any of my noise.
May 04
prev sibling parent Piotrek <dummy dummy.gov> writes:
On Friday, 3 May 2019 at 13:30:01 UTC, Mike Franklin wrote:
 You can find me on Slack and Discord under the handle JinShil 
 should you wish to have more of a dialog.
I wanted to contact you via Discord, but it didn't work. I have created an issue at https://github.com/JinShil/utiliD Cheers, Piotrek
May 06