Why does the parameters function in lang::java::m3::Core return a set?

[aserebrenik]

Quoting a student submission: "Note that the problem described above is a drawback of the Rascal libraries. The method parameters returns a set and not a list."

[PaulKlint]

Can you please be more specific? An issue should be self-describing or -- in case of a continuation of an older issue -- at least refer to that older issue.

[DavyLandman]

Could you provide a bit more context? Is this a bug for a certain library?

In general, going from a list to set is always possible in rascal.

toList and toSet exists, or a more rascal way is to splice it into the other container, so [*aSet] and {*aList}.

[aserebrenik]

"One of the issues we faced had to do with the method signature. That is the parameters of a method. We used a nice set comprehension to find the parameters of a method. As a consequence the result is also a set. In a set there is no order. When programming in Java, the order the parameters do matter."

The corresponding code is likely to be set[loc] parameters(M3 m, loc method) = {param | param <- elements(m, method), isParameter(param)};

[DavyLandman]

There are two elements here, in M3 we chose to use sets to represent the methods, since this parts it's all about relational algebra. That explains (at least partly) why that function returns a set. In Rascal, you can always choose between a list, set, or map.

Turning the { into [ would have made that code into a list comprehension. So if another use case is needed, that would be possible, except that the elements function also returns unordered sets.

For this use case, it would be better to visit the AST that M3 provides, there the arguments are in order, and have the same loc in the @decl annotation as used in the M3 relations.

[DavyLandman]

Closing the issue for now, it would have made a nice stack overflow question.

In general, the M3 relational models have no order, for that use the AST.

[aserebrenik]

Well, we still can move it to SO if you like.