On Wednesday, 23 April 2014 at 15:33:36 UTC, Orvid King wrote:
So, in order to get the ball rolling on the new GC I intend to
implement for D, I want to facilitate a lively discussion of
the design of it, so that it can be designed to be both robust
and free of design flaws. To keep the discussion from getting
derailed, I want to lay out a few guidelines, but want to get
feedback on those guidelines before I actually implement them.
My current draft of them is as follows:
First we’ll start with a brief overview of the development
process:
A PR will be created for DMD, DRuntime, and, although it may
stay empty, Phobos. A new commit will be created for each
update of the implementation, this includes bug fixes, and
continuing work on the implementation, in as many iterations as
are required. This is done to allow progressive review of the
code rather than trying to review the PRs as a whole, because,
as it is likely to include several thousand lines of changes to
the code, it would be impractical to review all at once.
No force push should ever be done to the PRs except to fix a
typo in or clarify a detail of the commit message for the
newest commit. If there is a typo in a commit message, or it is
not very clear on what was actually done, and another commit
has already been pushed, the typo or un-clear message shall
remain for all eternity. The suggested remedy in this case is
to make a note of the typo or clarify the commit message with a
comment on the commit.
PRs to the PRs are welcome, it is however encouraged to
coordinate any work you do with the others actively working on
the GC. The primary outlet for this should be the IRC, however,
should the need arise, the mailing list is a valid venue for
this.
Github should be used as the primary outlet for discussion of
actual code, due to the ease of referencing code, as well as
the ability to tell if a comment is about a piece of code that
was already changed.
The mailing list should be used exclusively for discussion of
the design. It should not be used for discussing snippets of
code in the actual implementation. It can, and should be, used
to discuss snippets of code that may demonstrate a flaw,
weakness, or strength in the design.
The IRC should be used for rapid-fire Q&A, or bringing someone
up-to-date with the discussion and progression of the GC so
far. Discussion about inconsistencies in the coding style of
the implementation (whitespaces, newlines, etc.) should reside
exclusively on the IRC, as they are things that a future reader
of the discussions doesn’t really care about. If a discussion
of the overall code style used in the implementation is
required, a thread should be created on the mailing list.
The IRC should not be used to facilitate a design discussion.
The reason for this is twofold, firstly the IRC has a limited
audience, thus limited feedback, and secondly, I want the
discussion of the design to stand as documentation for why the
GC is designed the way it is.
Now, on to the guidelines for the design discussion.
ARC does not exist. We are implementing a GC, however, if the
opportunity arises to allow an efficient implementation of
interfacing with an external ARC platform, such as what is used
in Objective C, discussion of that interfacing mechanism is
permitted.
If DMD support is needed, it exists. This means that if the GC
needs DMD to be capable of something such as scope analysis in
order to make a particular optimization, then DMD should be
assumed to be capable of doing that.
While language additions may be proposed, the design must still
be able to function should the additions not be done, as the
additions should only be to allow for additional optimization
opportunities. For instance, re-introducing scoped class locals.
After all of that, I intend to include a base draft of the
design of the GC, along with opening the PRs and committing the
starting API. So, is there something I’m missing? Am I
overlooking the obvious? Is there a more practical way to
produce the same results?
Wow, this takes the D forums tradition of "all talk, no code," or
as the original saying goes, "all hat, no cattle," to a new peak.
;)
I think most would agree with you on most of these guidelines,
better to get onto the actual design. It might help if you put
forth a tentative proposal, that the D goons can then proceed to
destroy... I mean, critically evaluate.
