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