Yeah, that will require some careful thought. -Walter

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agf4ib$i2h$1@digitaldaemon.com...
> sweet
>
> but hopefully there's some rule about what scope the template
instantiation
> uses
>
> Perhaps it can first try to use the scope of its declaration
>
> and if that fails, try the scope of the point of instantiation
>
> Sean

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agf4m8$i7u$1@digitaldaemon.com...

> "Walter" <walter@digitalmars.com> wrote in message news:age1p7$1vei$2@digitaldaemon.com...
> >
> > To me either the symbols from the point of declaration or the point of instantiation, not a mish-mash of both.
>
> Then I would pick the point of declaration;  however you still need to be able to "inject" symbols via template parameters that aren't otherwise available at the point of template declaration.
>
> The template writer has no idea what symbols will be available at point of instantiation and cannot rely on having all its needed symbols present.
So
> point of instantiation seems like a bad choice.

   Hmmm... I'm thinking...

   This would not be a problem is the following applies:

- The language is structurally unambiguous. So you know what is a function
call, a declaration, etc... without doing symbol lookup.
- The overloading resolution is done at link time.

   This would mean the syntax would have to differ from C/C++ more
significantly, and a big portion of the code generation would move to the
linker. Not for D, I suppose, but interesting nonetheless.

Salutaciones,
                         JCAB

"Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:agfek2$roc$1@digitaldaemon.com...
>    Hmmm... I'm thinking...
>
>    This would not be a problem is the following applies:
>
> - The language is structurally unambiguous. So you know what is a function
> call, a declaration, etc... without doing symbol lookup.
> - The overloading resolution is done at link time.
>
>    This would mean the syntax would have to differ from C/C++ more
> significantly, and a big portion of the code generation would move to the
> linker. Not for D, I suppose, but interesting nonetheless.
>
> Salutaciones,
>                          JCAB

Exactly.  Move most of the actual code generation to *after* linking.  Some optimization could be done on the parse tree ahead of time, but the brunt should be done after link, when everything aside from dynamic linkage is known.  Microsoft, with C# and .NET, decided to move code generation to execution time.  That's not a bad idea either but it requires more runtime support, and could take a little time, which is bad for many classes of apps.  At least it should only have to be done once per app per machine.

I wonder if anyone has really taken a step back from the lex/parse/semantic/codegen/link design we've had for several decades and tried to design a better way?  Surely some improvements could be made.

Sean

And if T didn't have a name member, it would be an error to try to instantiate getName().  No harm done though.  That's probably exactly the desired behavior.

Sean

"Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:agfebn$r98$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:agf4b6$ho7$2@digitaldaemon.com...
>
> > "Patrick Down" <pat@codemoon.com> wrote in message news:Xns9246524F06ABDpatcodemooncom@63.105.9.61...
> >
> > > I don't know what our template syntax will be so I'll just make it up. :-)
> > >
> > > template<>
> > > char[] getName()
> > > {
> > >   return name;
> > > }
> > >
> > > ...
> >
> > Hmm. I don't think that should work!
>
> template< class T >
> char[] T::getName()
> {
>   return name;
> }
>
>    As far as expressivity is concerned, this type of thing should be
doable.
> It's definitely no more ambiguous than operator overloading in C++.
>
> Salutaciones,
>                          JCAB

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agghgk$1uis$1@digitaldaemon.com...

> "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:agfek2$roc$1@digitaldaemon.com...
>
> >    This would mean the syntax would have to differ from C/C++ more
> > significantly, and a big portion of the code generation would move to
the
> > linker. Not for D, I suppose, but interesting nonetheless.
>
> Exactly.  Move most of the actual code generation to *after* linking.
Some
> optimization could be done on the parse tree ahead of time, but the brunt should be done after link, when everything aside from dynamic linkage is known.

   Interestingly, this would make the "export" support in C++ trivial...

> Microsoft, with C# and .NET, decided to move code generation to
> execution time.  That's not a bad idea either but it requires more runtime
> support, and could take a little time, which is bad for many classes of
> apps.  At least it should only have to be done once per app per machine.

   Yes, their JIT system is actually very impressive, but a bit overkill for
some cases. You'd never want to use something like that on a Playstation
2...

> I wonder if anyone has really taken a step back from the lex/parse/semantic/codegen/link design we've had for several decades and tried to design a better way?  Surely some improvements could be made.

   I'm experimenting along those lines... :)

Salutaciones,
                         JCAB

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns923986BCD9ED7patcodemooncom@63.105.9.61...
> If you look in the D libary right now you will see that there is
> ( if I remember correctly ) a ClassInfo and a TypeInfo structure.
> ClassInfo describes user defined classes.  TypeInfo is used more
> internally to hold certain functions related to basic types and
> to help implement dynamic arrays and such.  It would seem that
> perhaps these two could be unified to make a standard type descriptor
> for all types, basic and user defined.

TypeInfo certainly has promise for a more general type descriptor functionality.