Reimplementing the bulk of std.meta iteratively
Bruce Carneal
bcarneal at gmail.com
Mon Sep 28 22:46:55 UTC 2020
On Monday, 28 September 2020 at 16:57:19 UTC, Andrei Alexandrescu
wrote:
> On 9/28/20 11:55 AM, Bruce Carneal wrote:
>> On Monday, 28 September 2020 at 14:16:20 UTC, Andrei
>> Alexandrescu wrote:
>>> On 9/28/20 8:46 AM, Stefan Koch wrote:
>>>> On Monday, 28 September 2020 at 03:03:01 UTC, Andrei
>>>> Alexandrescu wrote:
>>>>> On 9/27/20 10:58 PM, Bruce Carneal wrote:
>>>>>> Disclaimer: Andrei has stated, effectively, that I have
>>>>>> little standing to opine on these issues.
>>>>>
>>>>> Sorry! Didn't mean to sound dismissive at all. Meant to
>>>>> just say, don't shun templates, embrace them and thrive.
>>>>
>>>> In practice template can quite literally explode though.
>>>> Which could be a valid reason to shun them.
>>>> You can embrace them, of course, and thrive.
>>>> The question is for how long you will thrive.
>>>
>>> For a very long time judging by the success C++ is enjoying
>>> with them.
>>
>> As you note, by employing a variety of "best practices", of
>> extra-language conventions, of one-level-of-indirection
>> wrappers, of "human must certify this correct" mechanisms, the
>> C++ community has indeed "thrived".
>>
>> We've not settled for that meta programming drudgery, that
>> friction, in the past. You know better this better than
>> anyone else on the planet. I hope we don't "settle" going
>> forward.
>
> (Not getting some of the uses of quotation marks.)
>
> That's a bit backhanded because it implies I promote settling
> for meta programming drudgery. Did you mean to say that?
My gosh, no! My apologies for leaving you with that impression.
You were and are one of the major players in the C++
friction/drudgery smackdown that is the D language. I was
attempting to say that there's an opportunity for another
language level complexity smackdown that I believe covers, en
passant, your reify/dereify use case.
>
> On the contrary, I find type reification interesting exactly
> because it takes you from said drudgery to familiar land -
> first-class values that can be manipulated in traditional
> manner. Should you need to get back to type-land, dereification
> helps with that. We can now draw from a large body of existing
> theory and practice.
OK. I'll really try to do better here. Zero disrespect intended.
When you leave the type system behind, when you reify, you must
assume responsibility for constraints that were previously, and
seamlessly, taken care of by the type system. The drudgery, the
friction, follows directly from the decision to escape from the
type system (reify) rather than remain within it (type functions).
I think of it as being similar to CT functions vs templates.
Within CT functions you've got the type system on your side.
Everybody loves CT functions because everything "just works" as
you'd expect. Near zero additional semantic load.
Wonderfully boring.
Within templates, on the other hand, you'd better get your
big-boy britches on because it's pretty much all up to you
pardner! (manually inserted constraints, serious tension between
generality and debugability, composition difficulties,
lazy/latent bugs in the general forms, localization difficulties,
...)
If language additions like type functions are off the table, then
we're left with LDMs and you've produced what looks like a dandy
in reify/dereify. If we have to step outside the language, if
language additions are just not in the cards any more, then
something like reify/dereify will be the way to go.
I hope that we've not hit that wall just yet but even if we have
D will remain, in my opinion, head and shoulders above anything
else out there. It is a truly wonderful language. I am very
grateful for the work you, Walter, and many many others have put
in to make it so. (most recent standout, Mathias! I'm a
-preview=in fan)
Finally, I'd love to hear your comments on type functions vs
reify/dereify. It's certainly possible that I've missed
something. Maybe it's a type functions+ solution we should be
seeking (type functions for everything they can do, and some LDM
for anything beyond their capability).
More information about the Digitalmars-d
mailing list