Which patches/mods exists for current versions of the DMD parser?

[via Digitalmars-d]

On Thursday, 11 September 2014 at 17:10:13 UTC, Joakim wrote:
> Let me begin by noting that I'm glad you're tinkering with D, 
> :) as I noted earlier that experimentation is good.

Yeah, but there are many different models to design. Informally:

1. organic/evolutionary design: let development go in many 
directions and let the most fit solutions survive. "The proof of 
the pudding is in the eating". Comes with overhead.

2. expert design: let people with theoretical knowledge do the 
overarching design and let regular people do the implementation. 
"sistine chapel". Risks of missing the target.

3. democratic/iterative/evolutionary design: involve end users in 
the process and let them design features. The big advantage is 
end user acceptance, the downside is that they might vote for the 
wrong features.

I prefer a mix of 1/2, but you can make good arguments for all of 
these and several other models. Basically, there are trade-offs. 
Some good, some bad.

> These "totalitarian" or "cult" arguments don't go anywhere 
> because it is easy to shrug them off, since the reality is far 
> from that extreme.  The core D group can sometimes be insular, 
> but I don't think that's really the problem here.

No, but I have previously argued against having a single branch 
and rather have one stable branch maintained by the "D team", and 
then have an experimental branch which is more lax and open to 
experimental contributions and "fun".

People working on the main branch need to align their goals to be 
productive, but you can only do that with a limited amount of 
people. Team-management is a challenging task, so you have to 
limit the size of the team if you want to do it well.

What is really wrong is brushing latent conflicts and 
irreconcilable expectations under the carpet. That can grow over 
time into fracturing. It is better to have them in the open at an 
early stage.

>> What you are saying is basically that you disagree with the 
>> license, so maybe Walter should have spent more time making 
>> sure that he had backing for it in the community, but that is 
>> an issue you have to take up with him. Not me or ketmar.
>
> This argument has nothing to do with the Boost license, as 
> practically every open source license allows the same forking.

> Looking back at how this blew up, it was actually Daniel who 
> asked you not to "fork D's syntax" and then Dicebot merely 
> reinforced that, before you both went overboard.

Actually, I usually agree with most of what Dicebot says in other 
threads. He is intelligent, analytical and focused. So I was a 
bit surprised here, but anyone can be tired and have a bad day, 
and the reasons are not important anyway.

Besides, he is not alone in thinking that a fork would be WRONG, 
so that tells me that the team-building process behind the 
selection might have been too much top-down and that some 
community building efforts are lacking.

In software process improvement you need to spend time on changes 
in policies so that you bring everyone with you (or in the worst 
case break up all teams and rebuild them from scratch, very 
costly ;-)

I also think that the GPL would be a more fitting license for D, 
given the democratic process and the community aspect.

But I would not modify the source then. So the license sure 
matters. MIT/BSD has traditionally been used for reference 
implementations for commercial closed source refinement. It is 
basically "take this and do whatever you want, no strings 
attached, but don't blame me for failures" licenses.

But you need to choose, because in open source:

product == source-code + license
support == forums/community
end users == people who download the source-code

We are only end users, not D devs. Maybe later devs, but 
currently just end users that evaluate the "product", which 
includes the license.

> The real issue is that historically any programming language 
> didn't want a bunch of incompatible syntax dialects floating 
> around, as that makes it difficult for many devs to understand 
> what the language proper actually consists of.  That concern 
> about "fragmentation" is all Daniel and Dicebot were speaking 
> to.

I know a fair share of the history of programming languages. Lots 
of dialects did not make them less popular as a "group". On the 
contrary. It probably increased their proliferation. 
Inconvenient? Sure.

Pascal would have died without Turbo Pascal, TP and C was better 
than regular Pascal…

C++ and objective-C did not make C irrelevant. IMO C++ made it 
necessary to come up with much needed improvements to C that 
probably would never have come about if C++ did not exist.

SQL and C leaves a lot of stuff implementation defined. The 
uptake of these 2 is huge.

And what is a dialect and what is a new language? Aren't most 
C-like languages more or less dialects with the same root?

> However, I've noted that is not a reason to frown on syntax 
> experimentation like you and ketmar want to do, as your syntax 
> tweaking is far from a full-blown or popular dialect yet.  I've 
> also noted that there may be a modern solution to such a 
> problem, automated syntax translation for different dialects.

Yeah, that is my goal for my experiments for now. To have a 
distinct pre-amble in the head of each source code file and 
provide 2 parsers and keep it compatible with a restricted set of 
D (no GC).

However a fork is no real threat to D for the following reasons:

1. Walter Bright is a good C++ programmer with intimate knowledge 
of the D compiler internals. If a D dialect is good he can 
implement the good features in the main branch with less effort. 
Copyright does not constrain this. (only patents)

2. To fund a fork you probably have to close the source code and 
target small specialised commercial markets. That means high 
licensing costs. Which in turn means that for every sale of a 
closed source dialect there will be 100s of users looking for a 
free version. It could looked upon as free marketing.

This is my take on this: I don't think a fork is a bad thing, and 
I think BSD/MIT style licensing increase the probability of a 
fork down the road compared to GPL. The payoff for forking is 
simply higher with a liberal license.