In article <du1q50$1qk8$1@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

"Kramer" <Kramer_member@pathlink.com> wrote in message news:dui66d$20ml$1@digitaldaemon.com...
> In article <du1q50$1qk8$1@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

In article <dun6m4$318o$1@digitaldaemon.com>, Craig Black says...
>
>
>"Kramer" <Kramer_member@pathlink.com> wrote in message news:dui66d$20ml$1@digitaldaemon.com...
>> In article <du1q50$1qk8$1@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

Probably out of scope but real metaprogramming requires different model of the language.

I think that model of Forth language and machine
(http://www.pcai.com/web/ai_info/pcai_forth.html)
was near the ideal from metaprogramming perspective.
Language practically had no grammar initially. Set of loaded "words" defines
particular language for particular domain.

Andrew.

>
> 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.
>

Why do you think that reflection (I suppose you mean runtime reflection) is
so good?
Do you have any practical examples where it is so needed?

Andrew.

Andrew Fedoniouk skrev:
>> 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.
>>
> 
> Why do you think that reflection (I suppose you mean runtime reflection) is so good?
> Do you have any practical examples where it is so needed?
> 
> Andrew. 
> 
> 
If done correctly you can pretty much base an API on it, and a really good one. Lets take Cocoa (OpenSTEP) as an example. It is written in Objective-C, with very good reflections support, and with the Smalltalk-OOP inheritance, as opposed to C++/D, etc Simula-OOP inheritance that is natural. After all what C++ and D does is just syntactic sugar for function pointers in structs :).

The class NSTableView is a 2d grid control, spreadsheet like if you will. So how is the table filled with data and managed? With _a single object_, called the dataSource. The dataSource object must conform to the informal protocol NSTableDataSource. Protocols in Objective-C is what we would call interfaces, informal mean that it must not implement all of the protocol, just some of it.

Now this is the good part, to make a read-only data view your data source needs only implement a few methods; numberOfRowsInTableView:, and tableView:objectValueForTableColumn:row: and adding; tableView:setObjectValue:forTableColumn:row: would be enough to make it writable as well. Making it sortable is yet a single method more.

So how does it work? Simple, when the table view wants to redraw itself, it asks the table source if it implements the methods needed, if it does, feature on, otherwise, feature off, or even call default handler instead (99% of all Cocoa controls have free cut/paste, spelling, etc).

I have written applications using pure win32 API, borlands VCL, Visual BAsic 6, .NET, Java swing, and GTK. And for simplicity, consistency and redused code size, Cocoa beats them all.

And it is all made possible because of strong support for reflection.

// Fredrik