www.digitalmars.com         C & C++   DMDScript  

D - foreach over enum types

reply Maik Zumstrull <Maik.Zumstrull gmx.de> writes:
Hi,

I think there are some situations where this would be useful. It would
be an easy way to write "for every possible value of this enum,
do ...". As far as I can see, adding this wouldn't break the syntax
(much):

foreach (myEnumType e; myEnumType) {
  doSomething(e);
}

Doesn't look so bad to me. Any comments?
Oct 02 2003
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Enums aren't necessarily linear, but it would be useful in the cases that
the enum doesn't have gaps and goes in steady progression.

I suppose it could work for nonlinear enums too, but it would have to be
completely unrolled by the compiler.

Sean

"Maik Zumstrull" <Maik.Zumstrull gmx.de> wrote in message
news:blh0jt$1qov$1 digitaldaemon.com...

 Hi,

 I think there are some situations where this would be useful. It would
 be an easy way to write "for every possible value of this enum,
 do ...". As far as I can see, adding this wouldn't break the syntax
 (much):

 foreach (myEnumType e; myEnumType) {
   doSomething(e);
 }

 Doesn't look so bad to me. Any comments?
Oct 02 2003
parent Maik Zumstrull <Maik.Zumstrull gmx.de> writes:
Sean L. Palmer schrieb:


 Enums aren't necessarily linear, but it would be useful in the cases
 that the enum doesn't have gaps and goes in steady progression.


I think it would be useful _especially_ in case of non-linear enums,
while only "nice to have" for linear enums. You could use a normal
for-loop to iterate over a linear enum (although it would be a somewhat
"dirty" approach IMHO - why use the enum abstraction when you treat it
as int afterwards anyway).


 I suppose it could work for nonlinear enums too, but it would have to
 be completely unrolled by the compiler.


Well someone has to unroll it in case of a nonlinear enum, and since
unrolling is a really stupid (== simple, straightforward, yet lengthy)
task, I think the compiler should do it for me.
Oct 02 2003
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Maik Zumstrull" <Maik.Zumstrull gmx.de> wrote in message
news:blh0jt$1qov$1 digitaldaemon.com...

 Hi,

 I think there are some situations where this would be useful. It would
 be an easy way to write "for every possible value of this enum,
 do ...". As far as I can see, adding this wouldn't break the syntax
 (much):

 foreach (myEnumType e; myEnumType) {
   doSomething(e);
 }

 Doesn't look so bad to me. Any comments?


It's workable.
Oct 02 2003
parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Walter wrote:

 
 "Maik Zumstrull" <Maik.Zumstrull gmx.de> wrote in message
 news:blh0jt$1qov$1 digitaldaemon.com...

 Hi,

 I think there are some situations where this would be useful. It would
 be an easy way to write "for every possible value of this enum,
 do ...". As far as I can see, adding this wouldn't break the syntax
 (much):

 foreach (myEnumType e; myEnumType) {
   doSomething(e);
 }

 Doesn't look so bad to me. Any comments?


 
 It's workable.


What if this were the job of a reflection module in a future standard library?

   myEnumType [] myEnumTypeReflection=ReflectModuleEnum("module.pat
.name",myEnumType);   

   foreach(myEnumType e; myEnumTypeReflection) {
       doSomething(e);
   }    


-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Oct 03 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3F7D665C.2999F29 chello.at...

 Walter wrote:

 "Maik Zumstrull" <Maik.Zumstrull gmx.de> wrote in message
 news:blh0jt$1qov$1 digitaldaemon.com...

 Hi,

 I think there are some situations where this would be useful. It would
 be an easy way to write "for every possible value of this enum,
 do ...". As far as I can see, adding this wouldn't break the syntax
 (much):

 foreach (myEnumType e; myEnumType) {
   doSomething(e);
 }

 Doesn't look so bad to me. Any comments?


 It's workable.


 What if this were the job of a reflection module in a future standard


library?

    myEnumType []


myEnumTypeReflection=ReflectModuleEnum("module.path.name",myEnumType);

    foreach(myEnumType e; myEnumTypeReflection) {
        doSomething(e);
    }


I'm less sure how to do that <g>.
Oct 03 2003
parent reply Helmut Leitner <leitner hls.via.at> writes:
Walter wrote:

 What if this were the job of a reflection module in a future standard


 library?

    myEnumType []


 myEnumTypeReflection=ReflectModuleEnum("module.path.name",myEnumType);

    foreach(myEnumType e; myEnumTypeReflection) {
        doSomething(e);
    }


 
 I'm less sure how to do that <g>.


What if someone would write a 
   "D source" => "general tree structure"
parser (must be hidden in your compiler frontend)?

Then it would be trivial to find the enum definition in the tree (and do a 
lot of other useful things).

Burton's DIGC goes a long way in parsing D code to strip functions bodys, looks 
into module dependencies, versions ... and I think a lot of future D tools might
be easier to write if there were a reusable D parser module written in D.

I'm currently working on a DMI (D make from import) utility to build
applications 
directly using the import dependencies without any need for makefiles and
libraries. 
Just from the sources: "dmi -Ic:\d -Ic:\dmd\src\phobos main" - the same problem.

Of course, it doesn't make sense for "foreach(...enum...)" alone.
But if you think about how to add a kind of reflection sometime in the future?
Such a library based "soft" reflection could be a cheap solution.

And it wouldn't be a "Walter problem".

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Oct 03 2003
parent "Walter" <walter digitalmars.com> writes:
"Helmut Leitner" <leitner hls.via.at> wrote in message
news:3F7DB2E0.636D1B8F hls.via.at...

 Burton's DIGC goes a long way in parsing D code to strip functions bodys,


looks

 into module dependencies, versions ... and I think a lot of future D tools


might

 be easier to write if there were a reusable D parser module written in D.


There is a reusable D parser, but it's in C++ right now. Eventually, it
should be rewritten in D.


 I'm currently working on a DMI (D make from import) utility to build


applications

 directly using the import dependencies without any need for makefiles and


libraries.

 Just from the sources: "dmi -Ic:\d -Ic:\dmd\src\phobos main" - the same


problem.

 Of course, it doesn't make sense for "foreach(...enum...)" alone.
 But if you think about how to add a kind of reflection sometime in the


future?

 Such a library based "soft" reflection could be a cheap solution.


I think supporting reflection is important. But not important enough to do
it for the next version, for that I think improving the template support is
much more important.
Oct 04 2003
prev sibling parent reply Juan C <Juan_member pathlink.com> writes:
In article <blh0jt$1qov$1 digitaldaemon.com>, Maik Zumstrull says...

Hi,

I think there are some situations where this would be useful. It would
be an easy way to write "for every possible value of this enum,
do ...". As far as I can see, adding this wouldn't break the syntax
(much):

foreach (myEnumType e; myEnumType) {
  doSomething(e);
}

Doesn't look so bad to me. Any comments?


What would it do with this enum then?
enum myEnumType { Zilch=0 , Zip=0 , Nul=0 , GooseEgg=0 , Nada=0 } ;
will it call doSomething() four times with the value 0 as expected or something
unexpected?

Juan C
Oct 04 2003
parent Maik Zumstrull <Maik.Zumstrull gmx.de> writes:
Juan C schrieb:


 What would it do with this enum then?
 enum myEnumType { Zilch=0 , Zip=0 , Nul=0 , GooseEgg=0 , Nada=0 } ;
 will it call doSomething() four times with the value 0 as expected or
 something unexpected?


That would have to be defined. I'd prefer it to do only one call per
real value, not one for every alias. It could also be made to do all
five calls in plain mode and optimize four of them away with enabled
optimization. Would/could the optimizer be intelligent enough to
optimize four calls away if it recognizes that making all five calls
doesn't lead to a different result? In that case, you could write code
with the assumption that all five calls are made while they aren't
actually made when it's not necessary.
Oct 05 2003