• Stefan Koch (45/45) Oct 08 2016 Hi Guys,
• Nicholas Wilson (2/13) Oct 08 2016 Infinite recursion if a struct, I assume you mean class :P
• Stefan Koch (8/21) Oct 08 2016 It's a special compiler Symbol :) therefore it would know
• Jacob Carlborg (4/47) Oct 09 2016 How about we just implement AST macros and be done with it :)
• Stefan Koch (4/5) Oct 09 2016 Walter would rather die. Then see ast-macros in D.
• Jacob Carlborg (9/12) Oct 09 2016 Yeah, unfortunately. Instead a lot of features are proposed and some

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;
   ....
  */
}

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

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;
}

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

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.

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