type variables

[Bruce Carneal]

On Sunday, 2 August 2020 at 02:21:30 UTC, Paul Backus wrote:
> On Sunday, 2 August 2020 at 00:19:46 UTC, Bruce Carneal wrote:
>> Current dlang type 'variables' are created in a strictly 
>> functional style.  IOW, they come from declarative syntax, 
>> CTFE constants, and possibly recursive application of 
>> templates.
>
> In D, currently, there are a few different ways you can refer 
> to a type.
>
> 1) By its name.
>
>     int x; // refers to `int` by name
>
> 2) By an alias.
..
> 3) By a template parameter.
..
> 4) By a typeof expression.
..
> 5) By a __traits expression.
..
> 6) By a string mixin.
..
> By "type variables", I am going to assume you mean #2 and #3, 
> aliases and template parameters, since they both involve giving 
> an existing type a new name.

I was thinking more about gaining access to a mutable form which 
could be converted to/from concrete types as represented by the 
compiler under the hood rather than the current methods of 
creating types in the source.  Note that "mixin" reduces to the 
others above and the others, of course, reduce to the compiler's 
internal form.

>
> Currently, these "type variables" are immutable, in the sense 
> that once a name is given to a type, the same name cannot later 
> be given to a new type. For example, you are not allowed to
...
>
> In general, this is a good thing--having `T` refer to two 
> different types ...

Yes, unrestricted type mutation capability is a non goal. So 
today we have a large and growing zoo of forms that we can 
utilize to work with types.  A mutable class convertible to/from 
whatever the compiler is using "under the hood" might be a better 
way.  It might be used to implement the zoo while limiting 
further special casing.  Switching metaphors, we'd have less 
unsprung weight going forward.

>
> However, in certain specific contexts, the ability to modify an 
> alias or a template parameter can be useful. This is where 
> proposals like type functions come in: they provide a context 
> in which aliases like `T` can be mutated, while still leaving 
> them immutable in "normal" D code.

Yes, there are other ways to achieve better readability without 
exposing types as completely as I've sketched.

>
>> Pure functional programming is great wrt correctness, it's 
>> working today, but it's not-so-great when it comes to 
>> readability/maintainability.  For starters, composition is a 
>> challenge.  Unwinding recursions in your head is another 
>> challenge.  Debugging is another challenge.
>
> The main issue with recursion is not that it is difficult to 
> understand or maintain, but that it has poor performance. In 
> order to process an argument list of length N using template 
> recursion, N separate template instantiations are required. 
> Using mutation instead of recursion would reduce the memory 
> required by such templates from O(N) to O(1).
>
> This is the primary motivation behind proposals like Stefan 
> Koch's type functions and Manu's `...` operator.
>

Yes, I misspoke.  It's the potential expanse of the template 
invocations that's the issue.  Recursion tends to improve 
readability.

>> Additionally, any template recursions extend the type names in 
>> a very ugly way.  Yes, the extension will give you a unique 
>> (unintelligible ginormous) name but that's about it.  Seems 
>> that we should be able to get a unique mangle without the 
>> garbage, something that a human could read and have a prayer 
>> of understanding while the universe is still warm.
>
> As far as I'm aware, the problem with ginormous names had 
> nothing to do with template *recursion*. Rather, it resulted 
> from the fact that code making heavy use of templates (for 
> example, UFCS chains of std.algorithm and std.range functions) 
> generated names in which the *same exact* type names were 
> *repeated* many, many times.
>
> If you know of an example of excessively large symbol names 
> resulting *specifically* from template recursion, I would be 
> interested to hear about it.

Yes, as above I misspoke here, it's not recursion that's the 
issue rather it's the mechanism that is employed wrt naming that 
could show up when recurring (but mostly elsewhere).

Factoring out naming from the "anonymous" structural aspects of 
types seems like a good way to go.  If people want to match on 
type structure for some reason, great.  If they want to create 
ginormous names, well, OK.

Thanks for the response.