On Tuesday, 19 December 2023 at 20:48:04 UTC, FeepingCreature wrote:
> On Tuesday, 19 December 2023 at 20:37:02 UTC, Walter Bright wrote:
>> On 12/19/2023 12:07 PM, FeepingCreature wrote:
>>> figure out a way to dogfood Phobos, it's insane that the premier project in the language refuses to use its stdlib)
>>
>> There is a good reason for that. It's very difficult to debug the compiler when the reason it is failing is a code gen bug that is breaking Phobos in some unknown way. Debugging Phobos is (unfortunately) difficult because too much of Phobos imports every other module in Phobos. (We'd like to fix that for the next iteration of Phobos.)
>>
>> It's hard to port dmd to a new platform when it relies on Phobos and Phobos is not working on the new platform, a chicken-and-egg problem.
>>
>> In order for our ease of debugging, we keep dmd's dependence on other code at a minimum.
>
> This makes little sense to me. You wouldn't *start* by making DMD run on the new platform, but the port would start with a cross-build from your old platform to the new platform, surely? I'd want to have the testsuite and every other tool passing on the new platform before I even try running DMD natively. And this problem only arises when you try to run DMD natively from the start, right? Or am I misunderstanding?

With some made-up version numbers:

Let's say dmd-0.2 only builds correctly with phobos-0.1, dmd-0.3 only builds correctly with phobos-0.2, and dmd-0.4 builds correctly with phobos-0.3, and due to a weird bug in phobos-0.2 it builds against it, but crashes.

This means the only *reliable* way to bootstrap dmd-0.50 is to first build dmd-0.1, then use it to build dmd-0.2, etc. until you catch up. While this might seem like a reasonable choice, it's also very brittle (and unnecessarily so).

Since phobos is changing every version, and we don't want to hold back that progress (or bug fixes), it's better to have a *subset* of library that we can maintain separately, and with the front end, and we know it only changes infrequently, and we can ensure it builds correctly with some large range of compilers. This means bootstrapping is much faster, and more reliable. I'd much prefer this over that.

An alternative universe where phobos is versioned separately from dmd might have been an answer, but we don't have that situation.

Keep in mind that gdc has the *requirement* that you can build the compiler with the last 3 versions. We can't break that, regardless of how good the dogfood is.

-Steve

On Tue, Dec 19, 2023 at 11:48:48PM +0000, GrimMaple via Digitalmars-d wrote: [...]
> In my opinion, we should actually strip D of features and instead focus on getting a decent standard library out so nobody has to write their own anymore.

What's your idea of a decent standard library?

I'm afraid that all of us here each have our own idea of what the standard library should be, and they are incompatible with each other.

Cf.: https://xkcd.com/927/


T

-- 
Engineering almost by definition should break guidelines. -- Ali Çehreli

On Wednesday, 20 December 2023 at 00:09:57 UTC, H. S. Teoh wrote:
> What's your idea of a decent standard library?
>
> I'm afraid that all of us here each have our own idea of what the standard library should be, and they are incompatible with each other.

I don't have this pathological hatred towards phobos that some other Devs have and my code does rely on it heavily. That being said, phobos is really lacking in features. Also, it is a mess of incompatible paradigms. To me, a good example is C#'s `System`, that gets you 99% of what you want from the get go. Phobos, unfortunately, provides about 10% at best.

I don't really care for speed in a standard library, for me it should allow me to get stuff done quickly. I can swap out for an optimized solution later if needed.

On 12/19/2023 12:59 PM, Steven Schveighoffer wrote:
>> I spent a whole afternoon carefully reviewing the DIP, only to be told that wasn't what was implemented and I should read the code. That was a waste of time.
>>
> 
> No, no you weren't. You were told exactly what the spec is. What you did was take the examples of things *that are possible with the DIP* (not the specification),

The dip was not the specification? The whole point of a dip is to be a specification. Where is the specification, then? Why is Atila reading the code and reverse engineering a specification for it?

On 12/19/2023 1:42 PM, jmh530 wrote:
> You said it was a good idea and that it could work, but then you gave another approach of putting files with duplicate names on the command line to override search pattern behavior. Iain said that can lead to duplicate symbols. And the discussion petered out.

We couldn't find a solution that satisfied both of us.

It's not a showstopper problem. At worst, you can do:

---file.c---
#include "file.h"
------------

thereby "converting" a .h file to a .c file.

On Wednesday, 20 December 2023 at 00:20:38 UTC, GrimMaple wrote:
> That being said, phobos is really lacking in features.

Yeah, my biggest problem with it is just it doesn't do the things I want it to do.

The secondary problem is that the stuff it does do, it mostly just does mediocre, but that's good enough a lot of the time. The missing functionality is a lot bigger of a problem than the mediocre functionality.

On 12/19/2023 1:52 PM, Adam D Ruppe wrote:
> I still say the best thing to do is to ditch the overloading of the `import` keyword and instead embrace the `mixin` keyword.
> 
> mixin[C](`#include<stdio.h>`);
> 
> you can now use the full file name, with .h or .c or whatever you want. And you can do this in context of D, meaning you can do things like :
> 
> @nogc {
>     mixin[C](`#include<stdio.h>`);
> }
> 
> 
> And potentially use macros:
> 
> enum C_Context = mixin[C](`#define foo bar`);
> mixin[C, C_Context](`use foo here`);
> 
> or something like that.

Programming with multiple languages is complicated, and it can work if the import mechanism gets to say what language the imported file is in.

I really like making things as simple as possible, and having them "just work". It's hard to beat:

    import whatever;

and not having file.d, file.c, and file.h in the same directory. Then life gets a lot simpler. After all, D was designed with the notion of package.module mapping directly onto directory/file. That inevitably results with some compromises on the names of the directories and files, etc., but it is worth it for the vast simplification of a 1:1 mapping.

On 12/19/2023 12:48 PM, FeepingCreature wrote:
> This makes little sense to me. You wouldn't *start* by making DMD run on the new platform, but the port would start with a cross-build from your old platform to the new platform, surely? I'd want to have the testsuite and every other tool passing on the new platform before I even try running DMD natively. And this problem only arises when you try to run DMD natively from the start, right? Or am I misunderstanding?

The test suite is carefully designed to test the compiler. It's proven to be really good at that, too. But when the compiler doesn't run because Phobos isn't working, I can't run the test suite.

Cross-compiling isn't been an option, and is still pretty darned clumsy with Windows<=>Linux.

The fewer the dependencies, the easier the debugging is. And tracking down obscure code gen bugs can be pretty hard enough.

There also isn't much that Phobos can add to the compiler. Some things that did help were just incorporated into the compiler source.

On 12/19/2023 12:38 PM, Konstantin wrote:
> Thanks!

Hope you find something you'll enjoy working on!