On Wednesday, 19 August 2020 at 12:03:59 UTC, Stefan Koch wrote:
> Does a limited pattern matching still fulfill a desirable power to complexity ratio though?

If D were to be rebuilt from the ground up with first-class types, things could definitely be simplified. The existence of meta-programming libraries wrapping traits and is-expressions is a sign that D's introspection is not intuitive or ergonomic.

https://code.dlang.org/packages/bolts
https://code.dlang.org/packages/mirror

However, considering the current template parameter system is so deeply ingrained into the D language and is-expressions simply leverage most of that, I don't think we should do away with is-expressions.

On Wednesday, 19 August 2020 at 13:37:54 UTC, Dennis wrote:
> The existence of meta-programming libraries wrapping traits and is-expressions is a sign that D's introspection is not intuitive or ergonomic.

I'm not convinced of that, I think these are just ideological. Like the reason std.traits exists and __traits has the __ is just that they felt it *should* be library, not that it *had* to be.

But perhaps there is just too steep of a learning curve, like I said, I didn't *really* get it myself until I was forced to by writing the book on it. Just... maybe we should make the docs easier to understand (the spec is quite bad for really getting it - but realizing it just mirrors the declaration helps a lot) and see if these libs start dying.

I'd also love to kill the libs because 1) they are invariably buggy and 2) they always bloat compile times and dmd ram to unacceptable amounts.

On Wednesday, 19 August 2020 at 13:37:54 UTC, Dennis wrote:
> On Wednesday, 19 August 2020 at 12:03:59 UTC, Stefan Koch wrote:
>> Does a limited pattern matching still fulfill a desirable power to complexity ratio though?
>
> If D were to be rebuilt from the ground up with first-class types, things could definitely be simplified. The existence of meta-programming libraries wrapping traits and is-expressions is a sign that D's introspection is not intuitive or ergonomic.
>
> https://code.dlang.org/packages/bolts
> https://code.dlang.org/packages/mirror
>
> However, considering the current template parameter system is so deeply ingrained into the D language and is-expressions simply leverage most of that, I don't think we should do away with is-expressions.


I fully agree.
I want to keep is expressions as they are.
They have their place.
I hope that with the slow introduction of features which demonstrate first class types we can migrate away from having to use them for common patterns though.
And also from having to have _costly_ wrapper libraries.

So far the only thing I see which can remove some of the cost of templates is to provide optimized compiler intrinsics.

On Wednesday, 19 August 2020 at 13:15:37 UTC, Paul Backus wrote:
> On Wednesday, 19 August 2020 at 13:07:40 UTC, Stefan Koch wrote:
>>
>> Yes it is useful.
>> And I think I have found a way to support them within the typefunctions.
>> is(T S == super) would become
>> auto f(alias T)
>> {
>>    static literal bool r = is(T S == super);
>>    // here alias S = (r ? SuperTupleOf(T) : ErrorType) is automatically declared.
>>    // where ErrorType is the value for which `!is(ErrorType)` is true
>> }
>>
>> still the pattern matching part is going to be a pain to implement correctly.
>> Without the some limitations we have right now.
>
> Why is it that type functions need their own parallel implementation of an existing language feature? Shouldn't it be possible to re-use the existing implementation?

Type functions work by doing partial evaluation,
In the first, static pass they can use the regular semantic transform and checking pass that the rest of dmd uses.
However everything which touches the type variables, cannot be semantically analyzed or transformed because the types aren't known yet.
Furthermore if during the interpretation the types are in a known state, you cannot change/enrich the type information within the AST based on that.

Since that would change the AST which would either violate the rule that ctfe has to be pure, and cause all sorts of issues, or you would have duplicate the whole subtree (this is what templates, do.).

Both of these things are not an option for me.

Therefore regular implementations of features can modify the meaning of existing nodes or indeed introduce new nodes, cannot be used.
As you can  see is expressions do introduce new nodes, so the regular implementation of them cannot just be forwarded to.
Also the existing implementation has no notion of type variables.
Since those only exist within the dynamic environment of the interpreter.

On Wed, Aug 19, 2020 at 01:37:54PM +0000, Dennis via Digitalmars-d wrote: [...]
> If D were to be rebuilt from the ground up with first-class types, things could definitely be simplified.
[...]

In an ideal world, types would be first class entities that you can pass around and manipulate at will.  Inside templates / CTFE, operations on types would operate directly on the compiler's internal type representation.  If any of these types end up in runtime code, they are replaced with runtime equivalents (typeid, et al).  The same type-manipulating function would be usable both at CTFE and at runtime, with the same semantics.

Of course, this idealistic scenario may not be very realistic, but moving in its direction could unify quite a number of currently divergent constructs, simplify the language, yet increase expressivity.


T

-- 
The best way to destroy a cause is to defend it poorly.

On Wednesday, 19 August 2020 at 15:18:03 UTC, Stefan Koch wrote:
>
> Type functions work by doing partial evaluation,
> In the first, static pass they can use the regular semantic transform and checking pass that the rest of dmd uses.
> However everything which touches the type variables, cannot be semantically analyzed or transformed because the types aren't known yet.
> Furthermore if during the interpretation the types are in a known state, you cannot change/enrich the type information within the AST based on that.
>
> Since that would change the AST which would either violate the rule that ctfe has to be pure, and cause all sorts of issues, or you would have duplicate the whole subtree (this is what templates, do.).
>
> Both of these things are not an option for me.

I see. I had assumed that type functions would work by duplicating the subtree, using the copy as a temporary "stack frame" in which local mutation was permitted, and then throwing it away at the end of interpretation.

This is still more efficient than using recursive templates, since it reduces the number of syntax-tree copies from O(n) to O(1), but I guess that's not enough of a performance win for what you're trying to accomplish.

On Wednesday, 19 August 2020 at 15:51:01 UTC, H. S. Teoh wrote:
> On Wed, Aug 19, 2020 at 01:37:54PM +0000, Dennis via Digitalmars-d wrote: [...]
>> If D were to be rebuilt from the ground up with first-class types, things could definitely be simplified.
> [...]
>
> In an ideal world, types would be first class entities that you can pass around and manipulate at will.  Inside templates / CTFE, operations on types would operate directly on the compiler's internal type representation.  If any of these types end up in runtime code, they are replaced with runtime equivalents (typeid, et al).  The same type-manipulating function would be usable both at CTFE and at runtime, with the same semantics.

Yes.  Were types first class citizens we'd have a lot of power but backing away from full mutability could be a good thing wrt comprehension and correctness.
Monadic forms perhaps.

>
> Of course, this idealistic scenario may not be very realistic, but moving in its direction could unify quite a number of currently divergent constructs, simplify the language, yet increase expressivity.

Yes.  D language users and implementers are at the forefront of practical metaprogramming.  It's great, challenging but great.

Stefan's type functions could be a good addition.  I like the parsimonious naming and the move towards full reification.

On Wednesday, 19 August 2020 at 13:07:40 UTC, Stefan Koch wrote:
>
> And I think I have found a way to support them within the typefunctions.
> is(T S == super) would become
> auto f(alias T)
> {
>    static literal bool r = is(T S == super);
>    // here alias S = (r ? SuperTupleOf(T) : ErrorType) is automatically declared.
>    // where ErrorType is the value for which `!is(ErrorType)` is true
> }
>

Back to the drawing board, it turns out my initial fears were appropriate.
Making an identifier into a variable declaration depending on whether you are in a type function or not; Is a funky thing to do.

I'll to go with additional __traits.

Besides I do think that __traits(getSuperType, T)
does look more readable than is(T S == super)

even though it does not give you the "symbolic equation" feeling :)

On Wednesday, 19 August 2020 at 13:48:49 UTC, Adam D. Ruppe wrote:
> On Wednesday, 19 August 2020 at 13:37:54 UTC, Dennis wrote:
>> The existence of meta-programming libraries wrapping traits and is-expressions is a sign that D's introspection is not intuitive or ergonomic.
>

I just found out that
is(T S == super)
returns true, even if T is object.Object.

On Friday, 21 August 2020 at 17:39:12 UTC, Stefan Koch wrote:
> I just found out that
> is(T S == super)
> returns true, even if T is object.Object.

yeah it actually sets S to be a tuple of (base class, interfaces...). So you need to check the length of it too.

It gives false only if passed a type that has no super at all, like a struct or a basic type.