On Monday, July 09, 2012 20:42:47 Gor Gyolchanyan wrote:
> Currently, code introspection in D is way worse, then it should be. And
> this is true for both compile-time and run-time introspection.
> Moreover, the available stuff is bugged out in the most critical places.
> I'd like to hear what people think would be a better way to handle
> code introspection.

You mean reflection?

- Jonathan M Davis

On Mon, Jul 9, 2012 at 9:37 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Monday, July 09, 2012 20:42:47 Gor Gyolchanyan wrote:
> > Currently, code introspection in D is way worse, then it should be. And
> > this is true for both compile-time and run-time introspection.
> > Moreover, the available stuff is bugged out in the most critical places.
> > I'd like to hear what people think would be a better way to handle
> > code introspection.
>
> You mean reflection?
>
> - Jonathan M Davis
>

I mean compile-time and run-time information like:
 * What are the types this one can implicitly/explicitly convert to/from?
 * What does this alias point to (variable/type/template/function)?
 * What is the protection of this alias?
 * What aliases does this one contain?
 * What are the instances of this template?
 * What are the available types (including/excluding template instances)?
 * What modules are being compiled and what modules do they import?
 * What packages are visible from the specified import paths?

This kind of information can allow enormously powerful libraries to be built. For instance python-style dynamic type subsystem, which flawlessly integrates with existing static type system, making D the first ever hybrid static-dynamic typed language. This will include making functions and templates dynamic:

   - Templates transformed into partially dynamically-typed
   functions/classes or associative arrays (in case of template variables).
   - Function and template overloading make dynamic, creating
   multi-dispatch functions.

-- 
Bye,
Gor Gyolchanyan.

On Monday, 9 July 2012 at 17:50:08 UTC, Gor Gyolchanyan wrote:
> making D the first ever hybrid static-dynamic typed language


s/D/C#/g

On Monday, July 09, 2012 21:49:57 Gor Gyolchanyan wrote:
> On Mon, Jul 9, 2012 at 9:37 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:
> > On Monday, July 09, 2012 20:42:47 Gor Gyolchanyan wrote:
> > > Currently, code introspection in D is way worse, then it should be. And
> > > this is true for both compile-time and run-time introspection.
> > > Moreover, the available stuff is bugged out in the most critical places.
> > > I'd like to hear what people think would be a better way to handle
> > > code introspection.
> > 
> > You mean reflection?
> > 
> > - Jonathan M Davis
> 
> I mean compile-time and run-time information like:
> * What are the types this one can implicitly/explicitly convert to/from?
> * What does this alias point to (variable/type/template/function)?
> * What is the protection of this alias?
> * What aliases does this one contain?
> * What are the instances of this template?
> * What are the available types (including/excluding template instances)?
> * What modules are being compiled and what modules do they import?
> * What packages are visible from the specified import paths?
> 
> This kind of information can allow enormously powerful libraries to be built. For instance python-style dynamic type subsystem, which flawlessly integrates with existing static type system, making D the first ever hybrid static-dynamic typed language. This will include making functions and templates dynamic:
> 
> - Templates transformed into partially dynamically-typed functions/classes or associative arrays (in case of template variables). - Function and template overloading make dynamic, creating multi-dispatch functions.

So, yes, you mean reflection. We have it available at compile time, and the number of things that you can determine have been slowly increasing. Runtime reflection can be built from compile-time reflection (I believe that some libraries already exist which do this), but it's not baked in like it is in Java or C#, because there's a cost associated with it, and we don't want an object to pay for it if it's not going to use it.

- Jonathan M Davis

On 07/09/2012 07:58 PM, Mehrdad wrote:
> On Monday, 9 July 2012 at 17:50:08 UTC, Gor Gyolchanyan wrote:
>> making D the first ever hybrid static-dynamic typed language
>
>
> s/D/C#/g

s/C#/presumably some lisp dialect/g

On Monday, July 09, 2012 21:49:57 Gor Gyolchanyan wrote:
> On Mon, Jul 9, 2012 at 9:37 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:
> > On Monday, July 09, 2012 20:42:47 Gor Gyolchanyan wrote:
> > > Currently, code introspection in D is way worse, then it should be. And
> > > this is true for both compile-time and run-time introspection.
> > > Moreover, the available stuff is bugged out in the most critical places.
> > > I'd like to hear what people think would be a better way to handle
> > > code introspection.
> > 
> > You mean reflection?
> > 
> > - Jonathan M Davis
> 
> I mean compile-time and run-time information like:
> * What are the types this one can implicitly/explicitly convert to/from?
> * What does this alias point to (variable/type/template/function)?
> * What is the protection of this alias?
> * What aliases does this one contain?
> * What are the instances of this template?
> * What are the available types (including/excluding template instances)?
> * What modules are being compiled and what modules do they import?
> * What packages are visible from the specified import paths?
> 
> This kind of information can allow enormously powerful libraries to be built. For instance python-style dynamic type subsystem, which flawlessly integrates with existing static type system, making D the first ever hybrid static-dynamic typed language. This will include making functions and templates dynamic:
> 
> - Templates transformed into partially dynamically-typed functions/classes or associative arrays (in case of template variables). - Function and template overloading make dynamic, creating multi-dispatch functions.

So, yes, you mean reflection. We have it available at compile time, and the number of things that you can determine have been slowly increasing. Runtime reflection can be built from compile-time reflection (I believe that some libraries already exist which do this), but it's not baked in like it is in Java or C#, because there's a cost associated with it, and we don't want an object to pay for it if it's not going to use it.

- Jonathan M Davis

On Monday, 9 July 2012 at 17:50:08 UTC, Gor Gyolchanyan wrote:
> I mean compile-time and run-time information like:
>  * What are the types this one can implicitly/explicitly convert to/from?
>  * What are the instances of this template?
>  * What modules are being compiled and what modules do they import?

These are not doable without breaking the encapsulation guarantees the module system provides right now.

David