Thoughts about "Compile-time types" talk

H. S. Teoh hsteoh at quickfur.ath.cx
Tue May 14 17:58:17 UTC 2019


On Mon, May 13, 2019 at 10:26:11AM +0000, Luís Marques via Digitalmars-d wrote:
> On Friday, 10 May 2019 at 00:33:04 UTC, H. S. Teoh wrote:
> > Skimmed over Luís Marques' slides on "compile-time types", and felt
> > compelled to say the following in response:  I think we're still
> > approaching things from the wrong level of abstraction.  This whole
> > divide between compile-time and runtime is IMO an artificial one,
> > and one that we must transcend in order to break new ground.
> 
> Thanks for the feedback. I think your counter-proposal makes some
> sense.  Whether it is the right way to attack the problem I don't
> know. My presentation was fairly high-level, but as part of my
> prototyping efforts I've gone over a lot of the details, the problems
> they would create, how they could be solved and so on. When I read
> your counter-proposal my knee jerk reaction was that it would address
> some deficiencies with my approach but also introduce other difficult
> practical problems.
[...]

I'd love to hear what are the difficult practical problems you have in
mind, if you have any specific examples.

The underlying idea behind my proposal is to remove artificial
distinctions and unify CT and RT so that, as far as is practical, they
are symmetric to each other.

Currently, the asymmetry between CT and RT leads to a lot of incidental
complexity: we have std.algorithm.filter and std.meta.Filter,
std.algorithm.map and std.meta.Map, and so on, which are needless
duplications that are necessary only because of the artificial
distinction between CT and RT.  Also, UFCS only applies to RT values, so
to chain std.meta.Filter, we'd have to write ugly nested expressions
where the RT counterpart is already miles ahead in terms of readability
and writability.

Then the ugly-looking !() vs. () between CT and RT arguments.  I'll
admit !() was a very clever invention in the early days of D when
templates were first introduced -- it's definitely much better than
C++'s nasty ambiguous <> syntax.  But at the end of the day, it's still
an artifact that only arose out of the artificial distinction between CT
and RT parameters.

Looking forward, one asks, is this CT/RT distinction a *necessary* one?
Certainly, at some point, the compiler must know whether something is
available at compile-time or should be deferred to runtime.  But is this
a decision that must be made *every single time* you declare a bunch of
parameters?  Is it a decision so important that it has to be made *right
then and there*?  Perhaps not.  Perhaps we can do better by passing this
decision to the caller, who probably has a better idea of what context
we're being called in, and who can make a more meaningful decision.

Hence, the idea of unifying CT and RT (to the extent possible) by not
differentiating between them until necessary.


T

-- 
Why waste time learning, when ignorance is instantaneous? -- Hobbes, from Calvin & Hobbes


More information about the Digitalmars-d mailing list