On 2008-11-26 17:49:45 -0500, "Stewart Gordon" <[EMAIL PROTECTED]> said:
"Michel Fortin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
<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
[EMAIL PROTECTED]
http://michelf.com/
