May 07, 2004 Re: foreach over struct, enum, class | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | In article <c7fadt$24bu$1@digitaldaemon.com>, Walter says... > >It's a neat way to do compile time reflection. I don't think it will serve for runtime reflection, though (i.e. getting an arbitrary Object and wondering what its members are without knowing the type). I'm thinking more along the lines of compile time. For compile time, the "big" feature that all this points to, is code generation that is part of the language. In other words, routines that run at compile time, and build boilerplate code in some reasonable way. C++ programmers are trying to do this with the "pseudo functional language" of template metaprogramming, and it is a horrible mess, readability, portability and stability wise. And of course there are programs that write code based on IDLs and so on. Also, the C preprocessor is used this way: consider macros named DO_10_TIMES and DO_100_TIMES as a way of doing stone-age loops. It would be useful to have a good way to do this, in the language, to replace all the bad ways that people are doing it, NEAR the language. The fact that people are doing it in a kludgey way, tell me that the time has come for it. So essentially, I'm suggesting small programs that run at compile time, looping over lists of names and types, and building code. If it were in the same language that the code itself was in, it could be an amazing feature (maybe). I think the main reason it hasn't been done is that it opens the door to abuse (infinite loops during compile etc). But much like pointers, this is a case of trusting programmers, or not. But I suspect that it's one-revolution-too-many for the short term. Kevin |
May 07, 2004 Re: foreach over struct, enum, class | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kevin Bealer | Kevin Bealer wrote: >I'm thinking more along the lines of compile time. For compile time, the "big" >feature that all this points to, is code generation that is part of the >language. > >In other words, routines that run at compile time, and build boilerplate code in >some reasonable way. > > I agree. I discussed something along compile-time-functions, ages ago but got little response. -- -Anderson: http://badmama.com.au/~anderson/ |
May 07, 2004 Re: foreach over struct, enum, class | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kevin Bealer | Kevin Bealer wrote:
> How about iterating over structures:
>
> myprint(double x) {...}
> myprint(int x) {...}
>
> // could be a class .. or an enum!
> struct foo {
> int a;
> double b;
> };
>
> foo bar;
>
> // syntax may need adjustment
> foreach(alias n, bar) {
> my_print(n);
> }
This opens up some really interesting possibilities, but it smells like a can of worms that may well be better left unopened. What if you only want to iterate over public attributes? Protected methods? (something that has irked me for some time now is the fact that there is no generic way to pry the individual argument types out of a delegate and put them back)
Then again, the more I think of it, Walter's idea concerning type expressions* may be enough to handle it. I can't escape the notion that it would require some sort of pseudostruct to iterate over to effectively carry everything it needs to.
* I forget where exactly it was that he proposed it:
(int == T) ? b : c; /* b iff T is an alias for int, else c */
If D grew something like this and tuples for 2.0, the varargs problem could finally be completely, utterly solved without any need for RTTI. (you'd just foreach over a tuple whose size and composition could be known at compile time)
-- andy
|
May 07, 2004 Re: foreach over struct, enum, class | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andy Friesen | Andy Friesen wrote: > What if you only want to iterate over public attributes? Protected methods? (something that has irked me for some time now is the fact that there is no generic way to pry the individual argument types out of a delegate and put them back) This could all be contained inside the class itself. I mean, you wouldn't be able to iterate over anything outside the class, although you could get access vir a method. Outside access could be nice but its not really required. -- -Anderson: http://badmama.com.au/~anderson/ |
May 07, 2004 Re: foreach over struct, enum, class | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kevin Bealer | "Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:c7g6ks$g3i$1@digitaldaemon.com... > In article <c7fadt$24bu$1@digitaldaemon.com>, Walter says... > > > >It's a neat way to do compile time reflection. I don't think it will serve > >for runtime reflection, though (i.e. getting an arbitrary Object and wondering what its members are without knowing the type). > > I'm thinking more along the lines of compile time. For compile time, the "big" > feature that all this points to, is code generation that is part of the language. > > In other words, routines that run at compile time, and build boilerplate code in > some reasonable way. > > C++ programmers are trying to do this with the "pseudo functional language" of > template metaprogramming, and it is a horrible mess, readability, portability > and stability wise. And of course there are programs that write code based on > IDLs and so on. Also, the C preprocessor is used this way: consider macros > named DO_10_TIMES and DO_100_TIMES as a way of doing stone-age loops. > > It would be useful to have a good way to do this, in the language, to replace > all the bad ways that people are doing it, NEAR the language. The fact that > people are doing it in a kludgey way, tell me that the time has come for it. > > So essentially, I'm suggesting small programs that run at compile time, looping > over lists of names and types, and building code. If it were in the same language that the code itself was in, it could be an amazing feature (maybe). I think you're on the right track. I've been exchanging email with some C++ template exports who feel the same way you do. > I think the main reason it hasn't been done is that it opens the door to abuse > (infinite loops during compile etc). But much like pointers, this is a case of > trusting programmers, or not. > > But I suspect that it's one-revolution-too-many for the short term. This is probably a D 2.0 feature <g>. |
May 07, 2004 Re: foreach over struct, enum, class | ||||
---|---|---|---|---|
| ||||
Posted in reply to J Anderson | "J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c7g8io$jbi$1@digitaldaemon.com... > Kevin Bealer wrote: > >I'm thinking more along the lines of compile time. For compile time, the "big" > >feature that all this points to, is code generation that is part of the language. > > > >In other words, routines that run at compile time, and build boilerplate code in > >some reasonable way. > I agree. I discussed something along compile-time-functions, ages ago but got little response. Can you point me towards your postings on this? |
May 07, 2004 Re: foreach over struct, enum, class | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | On Fri, 7 May 2004 13:21:55 -0700, "Walter" <newshound@digitalmars.com> wrote: >> >> So essentially, I'm suggesting small programs that run at compile time, >looping >> over lists of names and types, and building code. If it were in the same language that the code itself was in, it could be an amazing feature >(maybe). > >I think you're on the right track. I've been exchanging email with some C++ template exports who feel the same way you do. > sounds like vhdl generate to me. >> I think the main reason it hasn't been done is that it opens the door to >abuse >> (infinite loops during compile etc). But much like pointers, this is a >case of >> trusting programmers, or not. >> >> But I suspect that it's one-revolution-too-many for the short term. > >This is probably a D 2.0 feature <g>. > |
May 07, 2004 Re: foreach over struct, enum, class | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | In article <c7grbl$1fho$2@digitaldaemon.com>, Walter says... >I think you're on the right track. I've been exchanging email with some C++ template exports who feel the same way you do. I'm on the edge of my seat.. >> I think the main reason it hasn't been done is that it opens the door to >abuse >> (infinite loops during compile etc). But much like pointers, this is a >case of >> trusting programmers, or not. >> >> But I suspect that it's one-revolution-too-many for the short term. > >This is probably a D 2.0 feature <g>. Just when you think it's too good to be true, it gets better. Kevin |
May 07, 2004 Re: foreach over struct, enum, class | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | "Walter" <newshound@digitalmars.com> wrote in message news:c7grbl$1fho$2@digitaldaemon.com... > I've been exchanging email with some C++ > template exports who feel the same way you do. That should be "experts". Talk about a freudian slip! LOL |
May 08, 2004 Re: foreach over struct, enum, class | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | Walter wrote: >>I agree. I discussed something along compile-time-functions, ages ago >>but got little response. >> >> > >Can you point me towards your postings on this? > > Humm. It's in the old d newsgroup and I couldn't search by google. I can give you the subject title and date, if your using a newsreader: Title: Idea - Compile Time functions Date: 9/23/2003 1:21 AM The idea changes a bit at the end of the thread. -- -Anderson: http://badmama.com.au/~anderson/ |
Copyright © 1999-2021 by the D Language Foundation