How can we make it easier to experiment with the compiler? (page 6)

On Monday, 24 May 2021 at 22:21:46 UTC, Walter Bright wrote:

core is a separate library in its own, independent hierarchy, it is not in the std hierarchy. It is not "up sideways and down". So it's good.

Shouldn't the same reasoning apply to importing dmd.root from dmd.backend? if I understood right, dmd.root is designed to act like an external utility library. It should be no problem to import it, as long as dmd.root does not try to import rest of DMD.

Now, if std.stdio imported core.stdc.stdio, and core.stdc.stdio imported std.stdio, then you've got a really bad design.

It sounds like your real issue is circular imports, not parent package imports. That sounds more reasonable to me.

May 24, 2021

Re: How can we make it easier to experiment with the compiler?

Posted by Iain Buclaw
in reply to Walter Bright

Permalink

Iain Buclaw

Posted in reply to Walter Bright

Permalink

On Monday, 24 May 2021 at 22:18:35 UTC, Walter Bright wrote:

On 5/24/2021 3:51 AM, Iain Buclaw wrote:

For instance, how else would we be able to infer isReturnOnStack without a TypeFunction?
Challenge accepted!

Let's see. The only things the TypeFunction for are:

the return type
the function linkage
if the function returns a ref

Pass those in instead, and the need for TypeFunction goes away.

I still see a Type though. :-)

On my side, in pseudo-code this would become:

  tree type = build_gcc_type (return_type);
  if (isref)
    type = build_reference_type (type);
  return targetm.calls.return_in_memory (type);

Or alternatively, I could just abandon all accuracy and go with:

  return (return_type.ty == Tstruct || return_type.ty == Tsarray) && !isref;

Because I know that this function doesn't affect the code generator, though users won't be able to reliably do introspection.

Notice how isReturnOnStack depends on several random global variables like os, is64bit, and isPOSIX. They can be passed in as arguments, too (or passed in as a const ref to a struct containing those as members).

They have been moved to the internal state of Target, so no longer random globals.

Information such as the target OS or CPU should not be floating around the front-end. It should all be constrained to either the dmd.target interface or dmd.backend, leaving the front-end to only handle matters relating to language semantics.

isReturnOnStack() then becomes a pure function! (and safe, nogc, nothrow, all that good stuff)

Those initialize() functions go away, too.

The beauty now becomes that we can (at last!) easily and correctly write unittests for it. target.d now becomes INDEPENDENT of the rest of the compiler.

How sweet it will be!

I think target.d could instead benefit from breaking out into per-backend modules though, such as target_linux.d, target_freebsd.d, target_x86.d, target_x86_64.d, ... to separate out concerns of the OS with concerns of the CPU. It would be something completely dmd-specific though, as I don't use/re-use any part of what's present in dmd's source tree around this module.

On 5/24/2021 3:18 AM, poffer wrote: > On Monday, 24 May 2021 at 09:41:12 UTC, Walter Bright wrote: >> On 5/24/2021 1:40 AM, poffer wrote: >>> A good enhancement to the language would be adding some sort of module declaration that just states the admitted import packages or modules. I know that could be done by an external tool, but I feel that this one is a common problem. >> >> Importing unused modules is a problem, but a minor one. The larger problem is needing those modules. > > No. What I mean is a declaration that for example, allows only import from dmd in dmd/backend, of declare that imports from dmd/root are forbidden. Ok, now I understand what you meant. > Aren't you the guy pushing from declarations over conventions? Snark isn't necessary. > Conventions do not scale. Please propose a DIP for your idea.

On 5/24/2021 3:47 AM, Johan Engelen wrote: > The main stumbling block is already mentioned: ownership. If you want contributors, you have to give up some ownership and be willing to make compromises between your own and the new contributors' viewpoints. The lack of willingness to give up ownership is what keeps me out (and I suspect, indirectly, others too). The frontend source code is not nice, but I'm not drawn to fix it at all (even if paid for) because I am not ashamed by it as I would be if I would have some shared 'ownership' of it. Good points, but part of the reason the front end code is what it is is because of many contributors with diverse viewpoints on what good code should look like. How should we reconcile that?

On 5/24/2021 6:53 AM, 12345swordy wrote: > I seriously question the "Optimized for people who spend thousands of hours working on it" line, as I had a very intelligent person posted on slacks asking what does this function do, as there is no comments for said functions. "Use correct Ddoc function comment blocks." https://github.com/dlang/dmd/blob/master/CONTRIBUTING.md It's up to contributors to read and follow the guidelines, and up to those with pull privileges to require conformance. It's also up to you and I and us to go and fix documentation problems we run across, like this: https://github.com/dlang/dmd/pull/12570

On 5/24/2021 2:01 PM, Max Haughton wrote: > Where do you start? At the first function you notice that has poor/missing/wrong documentation. Like this one I just did: https://github.com/dlang/dmd/pull/12570

On Tuesday, 25 May 2021 at 00:03:56 UTC, Walter Bright wrote: > On 5/24/2021 2:01 PM, Max Haughton wrote: >> Where do you start? > > At the first function you notice that has poor/missing/wrong documentation. > > Like this one I just did: > > https://github.com/dlang/dmd/pull/12570 This is not helpful. Too much commenting makes the code even harder to read and drowns out important comments. This corporate illness (which assumes that programmers are idiots) is why editors now ship with hide-all-comments functionality... Good code with good naming needs only few comments and those are on an _algorithmic_ level. Nobody that has read an introductory book on compilers need a comment explaining a function that is looking up a symbol from a symboltable. If that is a problem, improve the name, use a longer name.

On Tuesday, 25 May 2021 at 04:21:08 UTC, Ola Fosheim Grostad wrote: > Nobody that has read an introductory book on compilers need a comment explaining a function that is looking up a symbol from a symboltable. If that is a problem, improve the name, use a longer name. An improvement that would have made any comment on "lookup(symbol)" superfluous is to have a signature that indicates whether a returned pointer can be null or not.

Forums