type variables

[Paul Backus]

On Sunday, 2 August 2020 at 04:08:00 UTC, Bruce Carneal wrote:
>
> 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.
>
> ...
>
> 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.

Correct me if I'm wrong, but it sounds to me like what you have 
in mind is something like this:

// type function
alias Tuple(Ts...)
{
     TypeBuilder b;
     b.kind = Kind.struct;
     foreach (T; Ts)
         b.addMember(T, ""); // anonymous member
     return b.toType;
}

That is, we have some mutable representation of a type, which we 
can manipulate via some compiler-defined API, and once we're 
done, we convert the result to a "real", immutable type, which 
can be used in other parts of the program.

I can see how this sort of thing might be useful. Indeed, if you 
generalize this design from just types to *all* kinds of AST 
nodes (FunctionBuilder, ExpressionBuilder, etc.), what you end up 
with is essentially a procedural macro system.

The problem is that D already has features for performing these 
kinds of AST manipulations: static if, static foreach, and 
mixins. From a language-design perspective, adding new features 
that duplicate the functionality of existing ones is generally 
not a good idea.

Rather that attempt to *replace* D's existing metaprogramming 
features with something entirely new, I think it would be much 
better to *extend* them with language features that allow us to 
overcome their current limitations.


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

I don't understand what structural vs. nominal typing has to do 
with the rest of your post.