The current syntax which does not need this cast seems to lead to lot of confusion among users, who end up using this feature unintentionally. This usually happens because the user is referring to the bag column(s) in output of (co)group using a wrong name, which happens to be another relation. Often, users realize the mistake only at runtime. New users, will have trouble figuring out what was wrong.

I think we should support the use of the cast as originally proposed, and deprecate the current syntax. The warning issued when the deprecated syntax is used is likely to help users realize that they have unintentionally used this feature.

Thejas M Nair
added a comment - 15/Jun/12 22:34 I am for making that more clear. But "scalar long" sounds like a new type of long. Also, based on the current precedence of operators, i think it would be read as
(scalar long ) (totals.num_rows)
How about using -
((scalar)totals).num_rows
or
((scalar tuple)totals).num_rows
.

Dmitriy V. Ryaboy
added a comment - 15/Jun/12 22:23 Can I suggest a different syntax that would make it extra clear to the user that he is doing something unusual, such as
ratios = foreach (group mytable by dimension)
generate group as dimension,
COUNT(mytable) / (scalar long ) totals.num_rows;

The syntax in the initial patch is confusing , it supports (tuple)A.$0 (where A is a relation. But that seems to imply the casting of first column of A as tuple. So the supported syntax should only be - ((tuple)A).$0 .

Thejas M Nair
added a comment - 21/Oct/11 00:42 The syntax in the initial patch is confusing , it supports (tuple)A.$0 (where A is a relation. But that seems to imply the casting of first column of A as tuple. So the supported syntax should only be - ((tuple)A).$0 .