Super-dee-duper D features

[Kevin Bealer]

Andrei Alexandrescu (See Website For Email) wrote:
> janderson wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> janderson wrote:
>>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>>> janderson wrote:
>>>>>> Note: I'm not arguing that meta-programming should be higher 
>>>>>> priority then say reflection.  I'm just arguing that its just an 
>>>>>> extension to what programmers do on a day-to-day basis.
>>>>>
>>>>> But metaprogramming *gives* reflection (as even you and others 
>>>>> discussed recently). The half-assed way to do reflection is to have 
>>>>> the language implementer sit down and define the run-time 
>>>>> reflection mechanism. The full-assed way is to define compile-time 
>>>>> reflection, to then allow people to define and refine run-time 
>>>>> reflection mechanisms as libraries, in addition to many other 
>>>>> useful libraries! It's like in the fish vs. fishing parable.
>>>>
>>>> I agree but its like the stl vectors.  I'm unsure weather it just is 
>>>> easier to have that kinda thing in the language because it already 
>>>> has much of that information. 
>>>
>>> The information being there is all the more reason to make it 
>>> available during compilation, for reflection and many other purposes, 
>>> e.g. PyD being one of them.
>>>
>>>> Also to write a reflection program that doesn't require wrapping 
>>>> each and every call you'd need to write a fully fledged compiler 
>>>> which may become out of sync with the compiler.   I'm undecided on 
>>>> this matter.
>>>
>>> Not sure I understand. All that will be needed to make Widget 
>>> available is:
>>>
>>> mixin Manifest!(Widget);
>>>
>>> I don't see where the syncing problem occurs.
>>
>> This is wrapping each class.  What if the the code was hidden in a 
>> library or something.  How would you get a such information?  Also 
>> wrapping each class is not as neat as a complete code analysis could 
>> be (which is possible in mixin, just very difficult and slow).
>>
>> Syncing problems could still occur if Walter decides to make some 
>> change in the language syntax.
> 
> I find it reasonable to require one line per exposed class. This is even 
> easier than writing a manifest file.
> 
> 
> Andrei

Ah, but what if I want to deal with non-exposed classes, i.e. serialize 
a complex graph or similar data structure to disk?  I think python has 
'pickling' that does this either in the language or in a fairly standard 
library.

For this kind of purpose, it would be useful to have some in-language 
and some library support; the library support can ride on top of the 
language support, and shouldn't require too much more.

Once you can get the useful parts of the parse tree or the equivalent 
data from the language, most or all of the rest can go in a library.

It would help my argument a lot if the unused bits could be left out of 
the program on the basis of some kind of analysis; that implies that the 
language support be triggered by the library instances on some level, 
something like C++'s automatically generated methods.  (For some reason 
I suspect that idea won't be popular...)

Kevin