The "type" type dream

[Michel Fortin]

On 2008-11-26 17:49:45 -0500, "Stewart Gordon" <smjg_1998 at yahoo.com> said:

> "Michel Fortin" <michel.fortin at michelf.com> wrote in message 
> news:gghpq4$2nc6$1 at digitalmars.com...
> <snip>
>> Here, valueTypeOf is a function taking a type as argument and returning 
>> another type. Obviously, it's a function that can only be evaluated at 
>> compile-time, but with it we can just forget about using templates and 
>> declarative programming when we need to create variables of related 
>> types.
> 
> If it can only be evaluated at compile-time, ISTM it isn't really types 
> being first-class values.  Your idea is an attempt to capture the power 
> of templates without using templates, whereas a real system of types as 
> first-class values would be more powerful than this.

Well, being able to work with types at runtime implies many things, and 
I didn't want to make it seem like any runtime support is needed to 
implement what I'm proposing. Also, I haven't thought about everything 
that is needed to fully replace templates with functions.

I'll bring back something that was proposed a while ago: static 
arguments for functions. Static arguments were supposed to instanciate 
code for the function for each value you'd pass to the given argument, 
much like a template argument would do. Here's how you can use this to 
create a function that return a type parametrized to a given argument:

	type foo(static int a) {
		class C {
			int opCall() {
				return a;
			}
		}
		return C;
	}

Which could replace this:

	template bar(int a) {
		class bar {
			int opCall() {
				return a;
			}
		}
	}

There's also a difference in the instanciation syntax:

	foo(1) a;
	bar!(1) b;

Now you can implement "headconst(Object)" in a library. :-)


>> [exit dream mode]
>> 
>> Not sure what all this would entail, but if we could return types from 
>> functions, would we still need templates at all? Couldn't we just 
>> create any struct or class inside the function and return that?
> <snip>
> 
> We might no longer need templates for functions or type aliases, but I 
> think that we would still need class/struct templates.  You could 
> invent a notation to construct a class or struct within a function, but 
> I'm not sure that you can make it look as nice as the template notation 
> we already have.

Yes, I agree. The "class A(arguments) {}" and "struct B(arguments) {}" 
syntax should be kept. But then it should also be harmonised to use the 
same parameter naming convention as functions. Basically:

	class A(type T) { ... }

could become a shortcut for function:

	type A(type T) { class A { ... }; return A; }

instead of:

	template A(T) { class A { ... } }

And it could be instanciated like this:

	A(int) a;


> Whether you want types to be full first-class values manipulable at 
> runtime or merely entities that you can manipulate using CTFE, one 
> implication is that type syntax and expression syntax would merge into 
> one common syntax. This might make parsing simpler, but you would have 
> to work out how to deal with such funny things as that * is postfix for 
> types and prefix for expressions, but [] is postfix for both.

I'm mostly interested in CTFE, at least for now.

It's true that parsing postfix * may be an interesting problem. "foo(x) 
* a" has a totally different meaning depending on foo(x) giving you a 
type or a value. If I'm not mistaken, fixing this would imply breaking 
separation of syntaxic and semantic analysis in the compiler, probably 
not something Walter will be interested in.


> I thought a while back about the possibility of giving types 
> first-class citizenship.  I suppose that what it really means is that a 
> type used as an expression would become the TypeInfo for that type.  
> But the TypeInfo classes probably ought to have more human-readable 
> names - Type, ArrayType, ClassType, AAType, etc.  And some properties 
> specific to each of these, e.g. valueType for ArrayType and AAType, 
> eliminating the need for the valueTypeOf function you proposed.

Seems you want runtime reflection. :-)


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/