On Tuesday, 16 February 2016 at 11:02:38 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 16 February 2016 at 10:17:05 UTC, Jonathan M Davis
wrote:
version of D. We don't know what we're going to want to do at
that point, and if we're actually willing to break backwards
compatibility in a serious way, what D2 looks like doesn't
really matter much for D3. And we don't even know whether
there will ever be a D3. What matters to us now is what we do
with D2 for making it a good language now and not what we may
or may not do with a future version of the language. Planning
for D3 now would be like planning for D when working on
finishing up C++98.
This is true, in a way, but also a bit too pessimistic.
Here is a possible strategy:
1. add semantics that are desirable to D2
2. express both D2 and D3 in a single intermediate
representation
3. work on a new D3 syntax that does not support deprecated
features
4. have two parsers, one for D2 and one for D3
Let compiler vendors decide whether they want to support D2 or
not.
A small comment on the way you express most of your opinions:
You have many ideas on how and why D should change, however all
of your proposals are so vague that no one can figure out any
concrete action items in them. Furthermore you don't seem to be
familiar with implementation details and even don't seem to have
any experience in writting large programs in D, because you never
talk about concrete problems and never contribute DIPs or PRs
(which other people serious about using D do). It seems that
you're not interested in using D for anything at all, which is
very strange considering how much time you spend on the forums.
Instead of trying critisize other people's concrete plans/ideas
by saying that instead they should be focusing on something very
abstract that only you understand, I think it would be a lot more
beneficial for the D community and your agenda, if you turn your
words into actions and show **by example** that your
design/implementation has **objective, measurable** benefits.
Otherwise no one will find practical real-world benefits from
your theoretical ideas and we would just waste time arguing with
each other, while something practical could be accomplished in
the same time.
Be the change you want to see in the world.
Back to your concrete comment:
It sounds nice in theory, however there are too many refactorings
in the AST and semantic analysis done for each release, which
prevents creating a stable intermediate representation.
The only stable IRs are the DMD backend IR, the GCC IR and the
LLVM IR.
By the way those sementics (maybe) are already representable in
the current AST abstractions in the frontend. What benefits would
a dedicated frontend IR bring? Hint: I have already watched the
LLVM talk about the Swift IR and I'm familiar with the reasons
for Rust introducing MIR. I just don't see the value such a large
initiative would bring to D.
The best way to defend your point would be look at the DMD source
code and propose specific API changes/additions which would bring
objective benefits. Otherwise you sound like someone telling a
car manufacturer that they should be focusing on flying cars or
teleportation, because clearly that's the future :D
