Jakob Stoklund Olesen <stoklund at 2pi.dk> writes:>> Yes, I get it. I think I have said that before. > > Excellent. I am sorry for the harsh tone, but you seemed to have > completely missed the point of the thread.E-mail is often a poor communication medium. :-/>> I will not change anything before the 3.0 branch. But I am working on >> this functionality with the understanding that it is desired. Please >> tell me now if we've changed our minds. > > No, I think for-loops for top-level defs could be a useful feature.Ok, we're on the same page here.> I don't want to allow for-loops inside multiclasses. The multiclasses > and for-loops provide essentially the same macro functionality with > different syntax. Mixing them would lead to a very confusing > language.Agreed about multiclasses and for loops implementing similar things. Multiclasses are implemented as a big hack in TableGen. They're really a pain to deal with, actually. I can see Bruno's tears in the code he wrote to allow defms inside multiclasses. :) I wonder if we could someday replace multiclasses with a simpler for loop syntax. I'll have to think about that. If multiclasses are too complicated right now because they spread instruction definitions around various classes (I agree with this view), this change might alleviate that issue. This kind of thing would have to be considered carefully and transitioned slowly, of course. It's just an idea. FYI, the way I am implementing for loops means that they *could* work in multiple places (e.g. multiclasses) but they do not have to be used that way. Restricting for loops to only the top level actually complicates things slightly because it becomes a special case. I'd like to continue this implementation but of course I would not actually try to use them in multiclasses or anywhere else besides the top level. Actually, I don't plan to use them at all anytime soon, but it sounds like Che-Liang has some immediate needs. Does this sound reasonable to you? I'll still wait until the 3.0 split to check anything in. -Dave
On Oct 11, 2011, at 11:38 AM, David A. Greene wrote:> FYI, the way I am implementing for loops means that they *could* work in > multiple places (e.g. multiclasses) but they do not have to be used that > way. Restricting for loops to only the top level actually complicates > things slightly because it becomes a special case. > > I'd like to continue this implementation but of course I would not > actually try to use them in multiclasses or anywhere else besides the > top level. Actually, I don't plan to use them at all anytime soon, but > it sounds like Che-Liang has some immediate needs. > > Does this sound reasonable to you?Yes, thanks for working on this.> I'll still wait until the 3.0 split to check anything in.Thanks. /jakob
On Oct 11, 2011, at 11:38 AM, David A. Greene wrote:> Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >>> Yes, I get it. I think I have said that before. >> >> Excellent. I am sorry for the harsh tone, but you seemed to have >> completely missed the point of the thread. > > E-mail is often a poor communication medium. :-/ > >>> I will not change anything before the 3.0 branch. But I am working on >>> this functionality with the understanding that it is desired. Please >>> tell me now if we've changed our minds. >> >> No, I think for-loops for top-level defs could be a useful feature. > > Ok, we're on the same page here. > >> I don't want to allow for-loops inside multiclasses. The multiclasses >> and for-loops provide essentially the same macro functionality with >> different syntax. Mixing them would lead to a very confusing >> language. > > Agreed about multiclasses and for loops implementing similar things. > Multiclasses are implemented as a big hack in TableGen. They're really > a pain to deal with, actually. I can see Bruno's tears in the code he > wrote to allow defms inside multiclasses. :) > > I wonder if we could someday replace multiclasses with a simpler for > loop syntax. I'll have to think about that. If multiclasses are too > complicated right now because they spread instruction definitions around > various classes (I agree with this view), this change might alleviate > that issue. This kind of thing would have to be considered carefully > and transitioned slowly, of course. It's just an idea. > > FYI, the way I am implementing for loops means that they *could* work in > multiple places (e.g. multiclasses) but they do not have to be used that > way. Restricting for loops to only the top level actually complicates > things slightly because it becomes a special case.Perhaps a minor note, but can I'd prefer we call them something other than a "for loop." That implies a more procedural nature than is natural for the language. TableGen is far more declarative that procedural. Even something simple like using a "for each" type syntax and refering to the construct as a "for each definition" would go a long way. What I want to avoid is any implication that there's a guarantee for order of evaluation. Regards, -Jim> > I'd like to continue this implementation but of course I would not > actually try to use them in multiclasses or anywhere else besides the > top level. Actually, I don't plan to use them at all anytime soon, but > it sounds like Che-Liang has some immediate needs. > > Does this sound reasonable to you? > > I'll still wait until the 3.0 split to check anything in. > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Oct 11, 2011, at 1:07 PM, Jim Grosbach wrote:> Perhaps a minor note, but can I'd prefer we call them something other than a "for loop." That implies a more procedural nature than is natural for the language. TableGen is far more declarative that procedural. Even something simple like using a "for each" type syntax and refering to the construct as a "for each definition" would go a long way. What I want to avoid is any implication that there's a guarantee for order of evaluation.Another thing that needs clarification is the multiple variable syntax: for x = [1, 2, 3], y = [4, 5, 6] in { … } It is not clear if you get a cross product or a 'zip'. /jakob