On Sunday, 1 February 2015 at 06:37:27 UTC, Walter Bright wrote:
I don't recall what you've suggested in this vein that was very
unpopular - can you please post an example?
These are not in any particular order. They are just how I
remember them.
I don't care if everyone disagrees with them, but Rust has shown
the benefits of a minimal, nimble runtime with modular language
implementation [7], and I don't see why D can't compete and offer
something even better.
Issue 11666 - Separate each platform's port to its own
folder/file [1]
----------------------------------------------------------------------
Originally Ian Buclaw's idea, but the Bugzilla issue was filed by
me. The problem is it is difficult to see the abstractions in
the runtime, because one has to navigate through hierarchies of
`version`ing, making it difficult to port D to new platforms.
The solution is to organize it by platform/architecture
separating each into its own folder. While there were a few pull
requests attempting to address this, they all failed, mostly due
to the fact that participants could not agree how to organize the
Linux/Posix platform headers.
That made me wonder: What in the world are the the platform
bindings doing in druntime anyway, and why should they interfere
11666? druntime is supposed to be the language implementation.
If platform bindings are needed, fine, get them from Deimos, and
encapsulate them. If users need platform bindings, they can get
the from Deimos too, and the linker can sort things out.
I brought this up when the community was considering adding C++
standard library language bindings to druntime as well (yikes!).
I tried to intervene, and took a beating [2]. I was criticised
for whining instead of contributing with pull requests. Well, I
did submit a pull request for the most unintrusive,
uncontroversial, trivial thing I could think of to get the ball
rolling [3]. But I was told I should discuss it on the forum. I
decided to stop the ridiculous cycle of discussion and debate,
and did not go back to the forum, as it was clear where that
would have ended up.
If druntime was simply the language implementation, 11666 would
have been resolved without debate, and we'd have a
well-structured code base for the community to gradually and
incrementally bring D to more platforms and architectures,
without having to go their own way with their own runtime and
their own tools.
I think the stuff in core.sys.* needs to be deported to Deimos,
and privately imported by any ports that may need it. The
current architecture of druntime is not very portable or
scalable, especially to the bare-metal architectures.
Issue 13605 - Add ability to `version` a module declaration [4]
---------------------------------------------------------------
One of the issues brought up in 11666 was that using public
imports introduces new namespaces. So, in my own experiments, I
found that if I only had a way to `version` a module, I could
potentially achieve better encapsulation of a given port. So, I
filed this enhancement request. Although this enhancement changes
nothing for anyone, and simply removes an arbitrary limitation,
it was still controversial.
Issue 12270 - Move TypeInfo to the D Runtime [5]
------------------------------------------------
If you remember from my and Adam Ruppe's DConf talk, we both
mentioned the need to stub out TypeInfo in our runtime. It's a
silly, but effective hack. Adam proposed an idea to move
TypeInfo to the runtime, and I decided to log it in Bugzilla
because I thought it was a great idea. But more importantly it's
a great example for future precedent.
There seems to be something inherently wrong with the way the
compiler is coupled to the runtime. I can't put my finger on it,
but perhaps you know what I'm talking about. It seems the
compiler needs to decouple from and delegate more to the runtime.
Issue 12270 is a great start in that direction, but
unfortunately I seem to be the only one of two actually
interested in it, and I'm disappointed to say I don't know how to
implement it. Furthermore, I suspect this may actually break a
few things if it were implemented, and given the aversion to
change in this community, my current belief is it would not be
accepted even if it were implemented.
Moving runtime hook declarations to .di files in the runtime [6]
----------------------------------------------------------------
I want my runtime to inform the compiler which language features
it supports have the compiler generate errors, at compile-time,
if the user attempts to use a language feature that is not
implemented.
Frustrated with the push-back from the larger community, I
decided to take a lower profile and see if I could have more
impact from the bottom up. I found GDC's code base a little
easier to understand than DMD's, and the few bare-metal folks
there are in this community all seem to hang out at D.GNU anyway.
So, I made a few propositions there, one of them being to move
runtime hook declarations to the runtime (see the link). None of
them seemed to light anyone's fire, however, and I have found
that I still don't understand the compiler well enough to do any
of the implementations. Iain has offered to help when he gets
time, but he's certainly under no obligation to do so, and with
the community largely silent on the idea, I'm unsure if it will
be embraced by the community if it were implemented.
Bottom line is some features in D are too high-level and I need a
way to inform users (at compile time) what language features are
supported in the runtime port, and which features aren't. Also,
I think users should be able to make similar choices even if an
implementation in the runtime exists.
Final Thoughts
--------------
The D language needs to be more nimble, pay-as-you-go, scalable,
and portable. For bare-metal programming, it appears the
language designers have not really given much thought to it. As
I study Rust, I see that someone there is thinking about it and
making design choices to support it rather elegantly. [7]
* The D language itself should not be dependent on libc or any
other library. Ports of the D runtime may need those libraries,
but the language itself should not. libc bindings below in
Deimos.
* Those porting D to new platforms shouldn't have to port the
entire feature set of D, especially for resource-constrained
bare-metal ports. They should be able to implement only what is
applicable for their platform (of course I recognize there is a
limit). That is going to look very different for each platform,
so D should be more modular and malleable.
* Users should be able to make decisions about what features of
D they want or don't want in their programs, even if a runtime
implementation exists, and have those decisions enforced at
compile-time.
* Users and those porting D to new platforms should have some
control over the code generation to make efficient binaries,
especially for resource constrained systems. But I also think
the linker needs to take some responsibility here too.
* I have more, but I'm already getting carried away.
I don't want to file more Bugzilla issues because I don't
necessarily have the right answers here, and I think Bugzilla
issues need to be specific and actionable. Also, I want to help
make them happen, and not just throw them in Bugzilla to rot.
Instead, I'd like some dialogue with those willing to work with
me to find a reasonable solution and help with the
implementation. But I also need to know what the core team will
welcome, and what they will not, before I decide to jump in with
both feet. The aversion to change has me very sceptical.
Mike
[1] - Separate each platform's port to its own folder/file -
https://issues.dlang.org/show_bug.cgi?id=11666
[2] - core.spp -
http://forum.dlang.org/post/sdrjfagsayomsngme...@forum.dlang.org
[3] - Move core.stdc to Deimos -
https://github.com/D-Programming-Deimos/libc/pull/2
[4] - Add ability to `version` a module declaration -
https://issues.dlang.org/show_bug.cgi?id=13605
[5] - Move TypeInfo to D Runtime -
https://issues.dlang.org/show_bug.cgi?id=12270
[6] - Move runtime hook declarations to .di file in runtime -
http://forum.dlang.org/post/psssnzurlzeqeneag...@forum.dlang.org
[7] - Writing Safe Unsafe and Low-Level Code in Rust -
http://doc.rust-lang.org/0.11.0/guide-unsafe.html
