www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - __Symbol an alternative to recursive templates for type-introsecption

reply Stefan Koch <uplink.coder googlemail.com> writes:
Hi Guys,

You might remember my critique regarding the 
fullyQulifiedName-template in phobos.
Basically it is dramatically slowed down by the cost of template 
instanciation.
I tried to remedy the situation by using by introducing another 
__trait.
While this succeeded in reducing the compile-time drastically,
It was deemed a bad precedent to replace library functionality 
with compiler intrinsics.

If we were to introduce a new that could hold a symbol.
(akin to AliasSeq!(...)[0]), only much less expensive :))
Then we could replace the fqn template with this :

template fqn(alias T)
{
   string fqn = ()
   {
     string result = (cast(__Symbol)T).name;
     __Symbol t = cast(__Symbol)T;
     __Symbol p = t.parent;
     while(p)
     {
       result = p.name ~ "." ~ result;
       t = p;
     }
     return result
   }();
}

As you can see there is only CTFE and no recursive template 
instanciation.
Thereby the currently worst factor would be removed.

The pseudo-type __Symbol is only valid at CT.

It can only be obtained by either a TemplateAliasParameter or 
from a member-variable of another __Symbol.

So far it can be visualized as
struct __Symbol
{
   string name;
   __Symbol parent;
   /* MaybeLater:
   __SymbolType type;
   __Symbol[] members;
   ....
  */
}
Oct 08 2016
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Sunday, 9 October 2016 at 03:05:22 UTC, Stefan Koch wrote:
 So far it can be visualized as
 struct __Symbol
 {
   string name;
   __Symbol parent;
   /* MaybeLater:
   __SymbolType type;
   __Symbol[] members;
   ....
  */
 }
Infinite recursion if a struct, I assume you mean class :P
Oct 08 2016
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Sunday, 9 October 2016 at 04:12:48 UTC, Nicholas Wilson wrote:
 On Sunday, 9 October 2016 at 03:05:22 UTC, Stefan Koch wrote:
 So far it can be visualized as
 struct __Symbol
 {
   string name;
   __Symbol parent;
   /* MaybeLater:
   __SymbolType type;
   __Symbol[] members;
   ....
  */
 }
Infinite recursion if a struct, I assume you mean class :P
It's a special compiler Symbol :) therefore it would know But for the sake of normal rules see it as struct __Symbol { string name; __Symbol* parent; }
Oct 08 2016
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-10-09 05:05, Stefan Koch wrote:
 Hi Guys,

 You might remember my critique regarding the fullyQulifiedName-template
 in phobos.
 Basically it is dramatically slowed down by the cost of template
 instanciation.
 I tried to remedy the situation by using by introducing another __trait.
 While this succeeded in reducing the compile-time drastically,
 It was deemed a bad precedent to replace library functionality with
 compiler intrinsics.

 If we were to introduce a new that could hold a symbol.
 (akin to AliasSeq!(...)[0]), only much less expensive :))
 Then we could replace the fqn template with this :

 template fqn(alias T)
 {
   string fqn = ()
   {
     string result = (cast(__Symbol)T).name;
     __Symbol t = cast(__Symbol)T;
     __Symbol p = t.parent;
     while(p)
     {
       result = p.name ~ "." ~ result;
       t = p;
     }
     return result
   }();
 }

 As you can see there is only CTFE and no recursive template instanciation.
 Thereby the currently worst factor would be removed.

 The pseudo-type __Symbol is only valid at CT.

 It can only be obtained by either a TemplateAliasParameter or from a
 member-variable of another __Symbol.

 So far it can be visualized as
 struct __Symbol
 {
   string name;
   __Symbol parent;
   /* MaybeLater:
   __SymbolType type;
   __Symbol[] members;
   ....
  */
 }
How about we just implement AST macros and be done with it :) -- /Jacob Carlborg
Oct 09 2016
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Sunday, 9 October 2016 at 13:40:14 UTC, Jacob Carlborg wrote:
 How about we just implement AST macros and be done with it :)
Walter would rather die. Then see ast-macros in D. I must say they would probably be worse then templates, in regards of compile-time bloating.
Oct 09 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-10-09 15:52, Stefan Koch wrote:

 Walter would rather die. Then see ast-macros in D.
Yeah, unfortunately. Instead a lot of features are proposed and some implement that all could be implement using macros. At the same time complaining that macros are complex. That's making the language complex is implementing a lot of small features that could have been implemented with a generic solution instead.
 I must say they would probably be worse then templates, in regards of
 compile-time bloating.
It's difficult to say without implementing and testing it out. -- /Jacob Carlborg
Oct 09 2016