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?

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.

https://en.wikipedia.org/wiki/Reification_(computer_science)

On Monday, 28 September 2020 at 02:58:13 UTC, Bruce Carneal wrote:
> On Sunday, 27 September 2020 at 16:32:18 UTC, claptrap wrote:
>>
> I hope and believe that there is another such advance available to us in the form of type functions.  The recently discovered alternative, reify/dereify, appears to be equivalent in power but is, comparatively, baroque.
>
> If the two approaches are actually equivalent in power, and in their ability to address the current template issues, then the baroque should be preferred if the language is closed to syntactic additions.
>
> If the language is not closed, then choosing to displace the already prototyped type function capability with reify/dereify would represent a lost opportunity to administer another complexity smackdown.

Yeah I think A&W etc.. are more concerned about keeping compiler complexity down than they are about a clean intuitive language interface.

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?
>
> 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.
>
> https://en.wikipedia.org/wiki/Reification_(computer_science)

Who's actually heard of reification outside of compiler writers? Ive been reading a ton of compiler related stuff lately, but not heard of it before now. It's seems like an implementation detail leaking out to me. Instead of first class types lets have whatever this stuff is cause we can get it on the cheap and its intellectually cool.

I guess my point is if you want meta-programming that just works as if it was regular programming, the reify / dereify just emphasises that it's two different domains because you have to move from one to the other. It's not unification, it's a bridge yes, but lets be honest the user shouldn't have to think about, it should just work. (Even if it makes the compiler writers job harder)

On 28.09.20 23:08, claptrap wrote:
> Instead of first class types

(Stefan's type functions do not give you first-class types. A first-class type you could put in a runtime variable.)

On Mon, Sep 28, 2020 at 11:27:56PM +0200, Timon Gehr via Digitalmars-d wrote:
> On 28.09.20 23:08, claptrap wrote:
> > Instead of first class types
> 
> (Stefan's type functions do not give you first-class types. A first-class type you could put in a runtime variable.)

(typeid(T) is a first-class type (of sorts), which we already have
today.  All we really need today is a way to retrieve T from typeid(T)
at compile-time.)


T

-- 
By understanding a machine-oriented language, the programmer will tend to use a much more efficient method; it is much closer to reality. -- D. Knuth

On Monday, 28 September 2020 at 21:27:56 UTC, Timon Gehr wrote:
> On 28.09.20 23:08, claptrap wrote:
>> Instead of first class types
>
> (Stefan's type functions do not give you first-class types. A first-class type you could put in a runtime variable.)

First class in the context of compile time meta programming i guess is more apt. I mean what people want is to manipulate these things at compile time so you want them to be first class in that context. Could just be called reified types to keep Andrei happy ;)

On 9/28/20 5:08 PM, claptrap wrote:
> 
> Who's actually heard of reification outside of compiler writers? Ive been reading a ton of compiler related stuff lately, but not heard of it before now. It's seems like an implementation detail leaking out to me. Instead of first class types lets have whatever this stuff is cause we can get it on the cheap and its intellectually cool.

Reification is first class types.

On Monday, 28 September 2020 at 21:55:45 UTC, Andrei Alexandrescu wrote:
> On 9/28/20 5:08 PM, claptrap wrote:
>> 
>> Who's actually heard of reification outside of compiler writers? Ive been reading a ton of compiler related stuff lately, but not heard of it before now. It's seems like an implementation detail leaking out to me. Instead of first class types lets have whatever this stuff is cause we can get it on the cheap and its intellectually cool.
>
> Reification is first class types.

If you have to litter your code with refiy / dereify then it's not first class. It's not a language feature but a library one. Hence not first class.

On 9/28/20 6:13 PM, claptrap wrote:
> On Monday, 28 September 2020 at 21:55:45 UTC, Andrei Alexandrescu wrote:
>> On 9/28/20 5:08 PM, claptrap wrote:
>>>
>>> Who's actually heard of reification outside of compiler writers? Ive been reading a ton of compiler related stuff lately, but not heard of it before now. It's seems like an implementation detail leaking out to me. Instead of first class types lets have whatever this stuff is cause we can get it on the cheap and its intellectually cool.
>>
>> Reification is first class types.
> 
> If you have to litter your code with refiy / dereify then it's not first class. It's not a language feature but a library one. Hence not first class.

I agree. Reification is a transformation that takes a non-first-class type and produces a first-class value.

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).