D is our last hope (page 25)

On Saturday, 23 December 2023 at 06:18:16 UTC, Walter Bright wrote:

To communicate a proposal to users, a specification is also needed. Telling users to read the code isn't going to work.

Well, as a user I often click through to the source when reading Phobos and other D docs and rarely, if ever, do I read specs unless tasked with verifying compliance or with creating a de-novo implementation against an extant spec. Fortunately, Adam already has working code and examples while Attila is, reportedly, hammering away on the spec.

I think this is a good way to do things. An independent spec writer may shine a spot on some unexpectedly dark corners, some implementer "blind spots".

A specification is needed to determine what the proposal is, and what it is not. It is also used to judge whether the implementation is correct or not.

Yes, but specs need to be "debugged" too, and directed testing against a working body of code can be very helpful there... probably much more helpful than a bunch of code-free language lawyering.

At the very least a working implementation with examples should let us skip past a lot of the "proof by assertion" noise regarding difficulty of implementation and marginal utility.

Here's hoping for swift understanding and a useful addition to D.

On Saturday, 23 December 2023 at 06:51:38 UTC, Walter Bright wrote: > On 12/22/2023 1:47 AM, GrimMaple wrote: >> Not the case with ImportC apparently, when you can just show up, make a 5K LOC PR out of thin air, mark it "trivial" and have 0 spec or rationale prepared. Good double standards bro. > > ImportC was not a D language change. C has a standard, C11, which ImportC implements. We had this talk before, and you now it's a lie. If ImportC was just a C compiler - fine (not really fine, but at least your point would stand). But ImportC has to extensively communicate with D code, which requires specification on topics including, but not limited to: * How C code should be imported in the first place (directly changes how `import` works) * How parts of C code should be translated to usable D code (unclear, nobody discussed that) * How to translate incompatible C `const` to D's `const` (no solution exists to this day, and you choose to ignore criticism on this topic) * How to expand and use macros And that's just what I could thinkg of from the top of my head. Go ahead and tell me all of that requires no specification.

On Saturday, 23 December 2023 at 09:49:09 UTC, GrimMaple wrote: > On Saturday, 23 December 2023 at 06:51:38 UTC, Walter Bright wrote: >> On 12/22/2023 1:47 AM, GrimMaple wrote: >>> Not the case with ImportC apparently, when you can just show up, make a 5K LOC PR out of thin air, mark it "trivial" and have 0 spec or rationale prepared. Good double standards bro. >> > > And that's just what I could thinkg of from the top of my head. Go ahead and tell me all of that requires no specification. That can be incrementally improved, quality of implementation, no spec needed. Has anyone actually found a concrete problem? Then create a thread and discuss that. 11 out of 10 times Walter delivers beyond expectations. There are of course some rare counter examples, but then please focus on those and not hypothetical arguments.

On Saturday, 23 December 2023 at 10:13:50 UTC, Daniel N wrote: > Has anyone actually found a concrete problem? There are a few in the bugzilla. None is really a blocker, but some defeat the purpose of the feature, which is importing unmodified C headers. dstep + tweaks or manual translation is still a saner option.

On Saturday, 23 December 2023 at 09:49:09 UTC, GrimMaple wrote: > And that's just what I could thinkg of from the top of my head. Go ahead and tell me all of that requires no specification. There is also nothing "simple" about implementing C11 anyway with its "sequence points" and memory model and atomics and "volatile" and its undefined behaviors. But hey, it was simple in 1988 I guess when Mr Bright found his love for C...

December 23

Re: D is our last hope

Posted by GrimMaple
in reply to Daniel N

Permalink

GrimMaple

Posted in reply to Daniel N

Permalink

On Saturday, 23 December 2023 at 10:13:50 UTC, Daniel N wrote:

That can be incrementally improved, quality of implementation, no spec needed.

Same could be said about Adam's string interpolation, couldn't it? Yet here Walter sits demanding some kind of "spec" and not using this "can be incrementally improved" argument. Why is it that Walter's changes can be "improved later", and Adam's can not? You have to understand that I'm not trying to attack ImportC personally, even though I might be the biggest ImportC protester to this day. I'm trying to attack an obviously doubly standarded practice when one person demands specs and compliance from everyone else, even when the rest of the community disagrees, and feels no need to commit in the same way. If you want specs, then write them youself for your own changes too.

Has anyone actually found a concrete problem? Then create a thread and discuss that.

Again, same could be said about Adam's string interpolation. Where is the discussion besides "gib spec"?

As for ImportC, there are plenty of fundamental issues with it that just get ignored.

11 out of 10 times Walter delivers beyond expectations. There are of course some rare counter examples, but then please focus on those and not hypothetical arguments.

This is exactly the thing I'm talking about. He shows up, burdens the community with his Super Cool Idea™, doesn't write specs, doesn't explain anything, people find sink holes in it, he merges it anyway. And now we are in this room: ImportC is already a thing (or rather, a broken mess) that all the DMD contributors have to deal with. And it's not like this "discussing" is going to change the sad reality of this mess being broken. No amount of arguing is going to undo the maintenance burden that was forced upon contributors, no matter what you do.

On Saturday, 23 December 2023 at 10:13:50 UTC, Daniel N wrote: > Has anyone actually found a concrete problem? Then create a thread and discuss that. (this one is old, it has since been mostly corrected, but the question of macros in general remains open) http://dpldocs.info/this-week-in-d/Blog.Posted_2021_11_01.html at one year old, the question of macros has still not been addressed, leaving importC well short of its potential: http://dpldocs.info/this-week-in-d/Blog.Posted_2022_05_09.html#importc And the namespace problem with conflicts was at that point, and still is, a serious problem for widespread adoption: http://dpldocs.info/this-week-in-d/Blog.Posted_2022_05_16.html ImportC is 2 1/2 years old and still hasn't addressed fundamental problems with its model. It finally works ok if you use it alone, but it still has trouble if you use it with others.

On Saturday, 23 December 2023 at 13:11:11 UTC, Araq wrote: > There is also nothing "simple" about implementing C11 anyway This, and as he learned the hard way, C11 alone is virtually useless for importC's mission, since vendor extensions are used heavily in the existing header files.

Forums