llvm dev - Oct 2011 - [LLVMdev] Enhancing TableGen

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

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes:
> 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. 
Yep.
>> 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.
Good idea.  How about:

foreach x = [...]

I could do 

foreach x in [...]

but that requires another keyword.  Do we care?
> 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'.
Che-Liang proposed a zip and I think I like that.  A cross-product can
be done with nested loops.  If the above implied a cross-product there
would be no way to do a zip and a zip is definitely useful in some
cases.

                         -Dave

On Oct 11, 2011, at 1:33 PM, David A. Greene wrote:
> Jakob Stoklund Olesen <stoklund at 2pi.dk> writes:
> 
>> How about:
> 
> foreach x = [...]
> 
> I could do 
> 
> foreach x in [...]
> 
> but that requires another keyword.  Do we care?
The syntax should be consistent with let expressions, even if the meaning is
completely different.

That is: "foreach x = […] in { def … }"
>> 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'.
> 
> Che-Liang proposed a zip and I think I like that.
Yes, we definitely need to do a zip.

I was looking for a syntax that makes it clear what is happening.

/jakob

On Oct 11, 2011, at 2:03 PM, David Blaikie wrote:
> I'd assume something like:
> 
>     for (x, y) = [(1, 4), (2, 5), (3, 6)] in { ... }
> 
> Though I don't know a great deal about tablegen syntax. But so long as
the lists are separate it seems it'd always be unclear that it was a zip.
+1

Nobody actually needs the zip functionality anyway.

/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111011/532fc131/attachment.html>

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes:
> On Oct 11, 2011, at 2:03 PM, David Blaikie wrote:
>
>     I'd assume something like:
>    
>         for (x, y) = [(1, 4), (2, 5), (3, 6)] in { ... }
>    
>     Though I don't know a great deal about tablegen syntax. But so
>     long as the lists are separate it seems it'd always be unclear
>     that it was a zip.
>
> +1
Ah yes, I like this idea.  It clarifies exactly how the zip works.  The
problem I see with this is that ( ... ) is a dag in TableGen and that
doesn't really map will onto iteration.  It could be done in the parser
but it would be pretty ugly.

Another thing we need to do is provide some way to declare x and y.
Otherwise TableGen will barf about use before declaration.

Another option:

         for {int x, int y} = [[1, 4], [2, 5], [3, 6]] in { ... }

This re-uses the class body syntax so we can make use of ParseObjectBody
directly.  We'd just create an anonymous class.  I'm not as happy with
the nested list syntax but it fits in the parser very well and supports
iteration directly.
> Nobody actually needs the zip functionality anyway.
In the sense of declaring and iterating separate lists?  Yeah, now that
I see this I agree.

                               -Dave