View mode: basic / threaded / horizontal-split · Log in · Help
December 01, 2005
Re: DMD 0.140: Pure magic!
"Don Clugston" <dac@nospam.com.au> wrote in message
news:dmmhfc$2m8p$1@digitaldaemon.com...
> Walter Bright wrote:
> > What's missing from function pointers? Note that the name demangler
> > (std.demangle) can demangle function pointers, so the information must
be
> > complete.
>
> All the mangling information is present in a mangled string, but I don't
> know any way to find out what the function arguments are.
> Suppose T is a function pointer type.
>
> R function (P1, P2, P3)
>
> What are R, P1, P2, P3 ? You can work out what R is, using
> is(T R : function)
> which gives you the type of the return value.
> In C++, you can find out what P1, P2, P3 are, by using implicit template
> instantiation. But in D, I don't even know how I can work out how many
> parameters there are. (Maybe there is, and I've just missed it).

Ok, I see what the problem is now. I don't have a solution at the moment.

> Even the runtime typeinfo structure seems to be incomplete.
> Example:
>
> writefln(typeid(int *), "  ", typeid(int function(char *, creal)));
>
> prints:
> int *    int()*
>
> yet from std.demangle, it looks as though even inout vs out parameters
> are distinguished in the mangled name.
>
> Musing...
>
> Now, a simple-to-implement way of doing this, and ensuring that all
> presnt and future types are covered, would be to include a
> __mangletypeof() function or property, valid for any type, which
> converts a type to a const char[], using exactly the same mangling
> algorithm which is used by the linker for individual types.
> So that std.demangle(__mangletypeof(int)) would return "int".

That's a good idea. The mangletypeof, however, should probably be a method
of TypeInfo. The nice thing about making this a standard method is that code
will be inured against mangling changes. Or do you mean it should be a
compile-time function?

> Note: if there was some kind of __demangletypeof() as well, we would
> have well-supported typelists by the backdoor -- mangle the types,
> perform string manipulations on them, and demangle when you're done. But
> perhaps this is all far, far too much rope...



> Could also be done from a library, if we had implicit function template
> instantiation. But I'm guessing that's not coming any time soon.

It would if I'd only stop doing other stuff <g>.
December 01, 2005
Re: DMD 0.140: Pure magic!
Walter Bright wrote:
> "Don Clugston" <dac@nospam.com.au> wrote in message
>>Now, a simple-to-implement way of doing this, and ensuring that all
>>presnt and future types are covered, would be to include a
>>__mangletypeof() function or property, valid for any type, which
>>converts a type to a const char[], using exactly the same mangling
>>algorithm which is used by the linker for individual types.
>>So that std.demangle(__mangletypeof(int)) would return "int".
> 
> 
> That's a good idea. The mangletypeof, however, should probably be a method
> of TypeInfo. The nice thing about making this a standard method is that code
> will be inured against mangling changes. Or do you mean it should be a
> compile-time function?

The idealist in me says: A compile-time function, analagous to typeof(), 
would be a whole lot more fun :) And I don't think it would often be 
required at runtime. There is the "enough rope" issue, though. It is a 
feature that is a bit too nasty to be easily accessable.

It would be ideal if const char [] typeof(T).mangletypeof (and 
typeof(T).name) were accessable at compile-time, but I don't see how 
that could work, unless parts of typeinfo became a template. Gets tricky.

The pragmatist in me says: A runtime function would probably be adequate 
for almost all applications, and implicit function templates could be 
used for the remainder, when they become available.

>>Could also be done from a library, if we had implicit function template
>>instantiation. But I'm guessing that's not coming any time soon.
> 
> It would if I'd only stop doing other stuff <g>.

Aha! Sounds like it's not a post-1.0 feature, then? (whatever 1.0 means 
:-) ). But it's all good.
December 01, 2005
Re: DMD 0.140: Pure magic!
In article <dmmhfc$2m8p$1@digitaldaemon.com>, Don Clugston says...
>
..

>
>All the mangling information is present in a mangled string, but I don't 
>know any way to find out what the function arguments are.
>Suppose T is a function pointer type.
>
>R function (P1, P2, P3)
>
>What are R, P1, P2, P3 ? You can work out what R is, using
>is(T R : function)
>which gives you the type of the return value.
>In C++, you can find out what P1, P2, P3 are, by using implicit template 
>instantiation. But in D, I don't even know how I can work out how many 
>parameters there are. (Maybe there is, and I've just missed it).
>


Another similar problem comes up with function pointers to overloaded functions,
e.g. you can't tell witch function is being used without knowing the type. 

DMD currently just picks one of the function. (For an example see
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/5671 )
December 01, 2005
Re: DMD 0.140: Pure magic!
In article <dmn9vf$i7r$1@digitaldaemon.com>, BCS says...
>
>In article <dmmhfc$2m8p$1@digitaldaemon.com>, Don Clugston says...
>>
>..
>
>>
>>All the mangling information is present in a mangled string, but I don't 
>>know any way to find out what the function arguments are.
>>Suppose T is a function pointer type.
>>
>>R function (P1, P2, P3)
>>
>>What are R, P1, P2, P3 ? You can work out what R is, using
>>is(T R : function)
>>which gives you the type of the return value.
>>In C++, you can find out what P1, P2, P3 are, by using implicit template 
>>instantiation. But in D, I don't even know how I can work out how many 
>>parameters there are. (Maybe there is, and I've just missed it).
>>
>
>
>Another similar problem comes up with function pointers to overloaded functions,
>e.g. you can't tell witch function is being used without knowing the type. 
>
>DMD currently just picks one of the function. (For an example see
>http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/5671 )
>
>

Does anyone know of plans for including reflection in the language?  It seems
like there's a lot of pieces and groudwork for it already, but maybe having a
standard library that uses these pieces would be beneficial for D and would
round out that feature in a consistent api; or maybe those other pieces just
need to be filled out more.

-Kramer
December 01, 2005
Re: DMD 0.140: Pure magic! ~ unofficial features?
This is great stuff.

If there were an "official" way to try out features, knowing fully that they 
are liable to change over time, I think it might help in such cases.

For example, if such things were symbolically marked in a manner akin to 
"deprecated", then the compiler would toss out an appropriate message: 
"using speculative feature x". Can't help but wonder if that might "permit" 
some more experimental aspects?

- Kris


"Don Clugston" <dac@nospam.com.au> wrote in message 
news:dmmn7h$2rhm$1@digitaldaemon.com...
> Walter Bright wrote:
>> "Don Clugston" <dac@nospam.com.au> wrote in message
>>>Now, a simple-to-implement way of doing this, and ensuring that all
>>>presnt and future types are covered, would be to include a
>>>__mangletypeof() function or property, valid for any type, which
>>>converts a type to a const char[], using exactly the same mangling
>>>algorithm which is used by the linker for individual types.
>>>So that std.demangle(__mangletypeof(int)) would return "int".
>>
>>
>> That's a good idea. The mangletypeof, however, should probably be a 
>> method
>> of TypeInfo. The nice thing about making this a standard method is that 
>> code
>> will be inured against mangling changes. Or do you mean it should be a
>> compile-time function?
>
> The idealist in me says: A compile-time function, analagous to typeof(), 
> would be a whole lot more fun :) And I don't think it would often be 
> required at runtime. There is the "enough rope" issue, though. It is a 
> feature that is a bit too nasty to be easily accessable.
>
> It would be ideal if const char [] typeof(T).mangletypeof (and 
> typeof(T).name) were accessable at compile-time, but I don't see how that 
> could work, unless parts of typeinfo became a template. Gets tricky.
>
> The pragmatist in me says: A runtime function would probably be adequate 
> for almost all applications, and implicit function templates could be used 
> for the remainder, when they become available.
>
>>>Could also be done from a library, if we had implicit function template
>>>instantiation. But I'm guessing that's not coming any time soon.
>>
>> It would if I'd only stop doing other stuff <g>.
>
> Aha! Sounds like it's not a post-1.0 feature, then? (whatever 1.0 means 
> :-) ). But it's all good.
December 01, 2005
Re: DMD 0.140: Pure magic! ~ unofficial features?
Kris wrote:
> This is great stuff.
> 
> If there were an "official" way to try out features, knowing fully that they 
> are liable to change over time, I think it might help in such cases.
> 
> For example, if such things were symbolically marked in a manner akin to 
> "deprecated", then the compiler would toss out an appropriate message: 
> "using speculative feature x". Can't help but wonder if that might "permit" 
> some more experimental aspects?

Something like that could be useful.  It would even prevent the need for 
new namespaces for library updates to differentiate between standard and 
proposed features (I'm thinking of std::tr1 in C++ here).


Sean
December 01, 2005
Re: DMD 0.140: Pure magic!
Don Clugston wrote:
<snip>

> Musing...
> 
> Now, a simple-to-implement way of doing this, and ensuring that all 
> presnt and future types are covered, would be to include a 
> __mangletypeof() function or property, valid for any type, which 
> converts a type to a const char[], using exactly the same mangling 
> algorithm which is used by the linker for individual types.
> So that std.demangle(__mangletypeof(int)) would return "int".
> 
> Note: if there was some kind of __demangletypeof() as well, we would 
> have well-supported typelists by the backdoor -- mangle the types, 
> perform string manipulations on them, and demangle when you're done. But 
> perhaps this is all far, far too much rope...
> 
> Could also be done from a library, if we had implicit function template 
> instantiation. But I'm guessing that's not coming any time soon.
> 

This would be just beautiful and, I think, would be a solution to the 
problem I gave in the d.learn group (see Symbol to char[]).  This idea 
is better because it is much more generalized.

-JJR
December 01, 2005
Re: DMD 0.140: Pure magic!
Walter Bright wrote:

>>Musing...
>>
>>Now, a simple-to-implement way of doing this, and ensuring that all
>>presnt and future types are covered, would be to include a
>>__mangletypeof() function or property, valid for any type, which
>>converts a type to a const char[], using exactly the same mangling
>>algorithm which is used by the linker for individual types.
>>So that std.demangle(__mangletypeof(int)) would return "int".
> 
> 
> That's a good idea. The mangletypeof, however, should probably be a method
> of TypeInfo. The nice thing about making this a standard method is that code
> will be inured against mangling changes. Or do you mean it should be a
> compile-time function?
> 

Definitely compile-time... at least for the purposes I'm thinking of.
December 02, 2005
Re: DMD 0.140: Pure magic!
John Reimer wrote:
> Don Clugston wrote:
> <snip>
> 
>> Musing...
>>
>> Now, a simple-to-implement way of doing this, and ensuring that all 
>> presnt and future types are covered, would be to include a 
>> __mangletypeof() function or property, valid for any type, which 
>> converts a type to a const char[], using exactly the same mangling 
>> algorithm which is used by the linker for individual types.
>> So that std.demangle(__mangletypeof(int)) would return "int".
>>
>> Note: if there was some kind of __demangletypeof() as well, we would 
>> have well-supported typelists by the backdoor -- mangle the types, 
>> perform string manipulations on them, and demangle when you're done. 
>> But perhaps this is all far, far too much rope...
> 
> This would be just beautiful and, I think, would be a solution to the 
> problem I gave in the d.learn group (see Symbol to char[]).  This idea 
> is better because it is much more generalized.
> 
> -JJR

Having thought about it a little more, I think that this would provide 
almost all of the compile-time type info you could want. Since we can 
now do string parsing at compile time, I think everything else could be 
extracted from the mangled string via a compile-time library.
A nice feature of using the name mangling is that it's a simple, fully 
general way of unifying type information.
By presenting members (of modules, templates, classes and structs, maybe 
even functions) as an array of constant char [] identifiers and char [] 
mangled typenames, you could have *full* compile-time reflection.

I suspect this would be by far the easiest way of implementing it, too.
Although walking the syntax tree before compilation is complete sounds 
perilous. Could it ever be done safely? (I wonder if any other languages 
have done it successfully?)
December 02, 2005
Re: DMD 0.140: Pure magic!
In article <dmovhp$ecm$1@digitaldaemon.com>, Don Clugston says...
>
>John Reimer wrote:
>> Don Clugston wrote:
>> <snip>
>> 
>>> Musing...
>>>
>>> Now, a simple-to-implement way of doing this, and ensuring that all 
>>> presnt and future types are covered, would be to include a 
>>> __mangletypeof() function or property, valid for any type, which 
>>> converts a type to a const char[], using exactly the same mangling 
>>> algorithm which is used by the linker for individual types.
>>> So that std.demangle(__mangletypeof(int)) would return "int".
>>>
>>> Note: if there was some kind of __demangletypeof() as well, we would 
>>> have well-supported typelists by the backdoor -- mangle the types, 
>>> perform string manipulations on them, and demangle when you're done. 
>>> But perhaps this is all far, far too much rope...
>> 
>> This would be just beautiful and, I think, would be a solution to the 
>> problem I gave in the d.learn group (see Symbol to char[]).  This idea 
>> is better because it is much more generalized.
>> 
>> -JJR
>
>Having thought about it a little more, I think that this would provide 
>almost all of the compile-time type info you could want. Since we can 
>now do string parsing at compile time, I think everything else could be 
>extracted from the mangled string via a compile-time library.
>A nice feature of using the name mangling is that it's a simple, fully 
>general way of unifying type information.
>By presenting members (of modules, templates, classes and structs, maybe 
>even functions) as an array of constant char [] identifiers and char [] 
>mangled typenames, you could have *full* compile-time reflection.
>
>I suspect this would be by far the easiest way of implementing it, too.
>Although walking the syntax tree before compilation is complete sounds 
>perilous. Could it ever be done safely? (I wonder if any other languages 
>have done it successfully?)

Well, you know me, if it gets us closer to a good reflection system, it gets my
vote.  One question though: how will this help with type discovery at runtime...
or will it?

- EricAnderton at yahoo
1 2 3
Top | Discussion index | About this forum | D home