Metacode mechanics

[Kramer]

In article <dun6m4$318o$1 at digitaldaemon.com>, Craig Black says...
>
>
>"Kramer" <Kramer_member at pathlink.com> wrote in message 
>news:dui66d$20ml$1 at digitaldaemon.com...
>> In article <du1q50$1qk8$1 at digitaldaemon.com>, Don Clugston says...
>>>
>>>David Medlock wrote:
>>>> Georg Wrede wrote:
>>>>
>>>> <snip>
>>>>> So I suggest that we:
>>>>>
>>>>>  - continue developing the current D metalanguage
>>>>>  - continue to have both Don's and Phobos' regexps
>>>>>  - in this NG start the development of requirements for KBDM
>>>>>
>>>>> KBDM being Kick-Butt D Metalanguage. :-)
>>>>
>>>> This is a very good idea, as code-which-generates-code is the heart of
>>>> some powerful techniques(Lisp/Scheme macros among them).
>>>>
>>>> To make them truly work however one of the following is really needed:
>>>>
>>>> 1. Runtime evaluation, as in scripting type languages.  In this case all
>>>> you need is a function which returns a string.
>>>>
>>>> 2. A _uniform_ way to represent all the constructs of the language. This
>>>> works in Lisp because everything is a List(actually a CONS cell), and
>>>> you can simply walk the tree checking for symbols and generating code as
>>>> needed.
>>>
>>>I'm sure that compile time reflection is the way to go.
>>>We already have the .mangleof property, which maps any type to a string.
>>>Once we get array literals, you could have an array of strings showing
>>>all members of a given item.
>>>eg a property
>>>char [][] .membersof
>>>which is valid for any type.
>>>
>>>Then with __identifier(char []) you could walk the syntax tree.
>>>
>>>Somewhat lacking in syntactic sugar, and doesn't deal with control
>>>structures, but it gets you to most of the interesting stuff.
>>>
>>>I've already written templates that do:
>>>char [] qualifiednameof!(alias x)
>>>char [] symbolnameof!(alias x)
>>>which work for any variable, function, type or module x,
>>>and as a side-effect, you get loads of type info. I don't think too many
>>>additions would be required to make everything possible. But, you'd
>>>certainly want some simplified syntax.
>>>
>>>> D is much simpler than C++, I will agree wholeheartedly. However, I fear
>>>> that such a language strapped on to D would be rife with kludges to
>>>> accomodate its (relatively)complex syntax.
>>>>
>>>> Cheers.
>>>> -DavidM
>>
>> I wonder if Walter checks this news group.  I've heard many people asking 
>> for
>> some type of full reflection capabilty.  I'm not that great with templates 
>> and
>> meta-programming, but it sounds like some people here are saying it would 
>> help
>> fill out D's capabilities in this arena.  Maybe it's time to press for 
>> this
>> again as a serious improvement to D?... (just thinking out loud)
>>
>> -Kramer
>
>Don't think it's time to push for reflection yet.  Walter is still 
>implementing IFTI, and there are a lot of bugs to fix.
>
>Personally, I think array literals should come before reflection.  To me, 
>it's a more fundamental language feature.
>
>-Craig 
>
>

I definitely agree with the array literals.  And the IFTI.  I guess I still
think that reflection is an important piece that should happen, but the other
pieces are probably much more pertinent to the language in the end and as such,
should be handled first.

-Kramer