Attribute ops as special control package

[rensink]

Currently, when one wants to perform some operation on attributes (sum, sub, etc) inside a recipe, one has to create an auxiliary rule with just a product node (and corresponding parameters) so it can be invoked from the recipe. This is unattractive since it pollutes the grammar with helper rules which are also duplicated in many grammars that use recipes.

Suggestion: create a special library to provide all the existing attribute operations to a control program. For instance, one could say in the beginning

import attr.*;

and then use, for example

int.add(x, y, out z)

in the program. Implementing this will probably require the programmatic creation of internal rules into the grammar model.

Reported by: zambon

[rensink]

Some discussion points:

1. Normally, if you have a rule attr.int.add then after import attr.* you wouldn't be able to use int.add; instead, you have to use attr.int.add or do import attr.int.* and use add. However, it may be that this is in itself a useful feature. What do you think?

2. If this library is made available, what do you expect to see in the Simulator? Surely not the entire library by default. If you invoke, say, attr.int.add(x, y, out z) somewhere in your control program, should the rule attr.int.add then appear in the rule tree? And when selected, should you actually get to see the rule? (I personally feel that this should indeed be the case.)

3. Currently the default control program is # *.any. The scope includes all the rules in the proposed library, and will then fail because those need input parameters. Clearly you would like to exclude attr.* from the scope, but how? A special exception?

Original comment by: rensink

[rensink]

W.r.t. point 1 in the previous comment: In fact, wildcards are currently not allowed at all import declarations.

Original comment by: rensink

[rensink]

Comments:

1. I don't like having to write z := attr.int.add(x, y) because I think is too long. I wouldn't like to write z := add(x, y) either because then I wouldn't be able to see from the statement alone that I'm doing integer addition. Suggestion: borrow from Python and write import attr.int as int and also from attr.int import add for those that want to use the short version.

2. I wouldn't expect to see anything new in the Simulator. These special rules are just the attribute operations. Maybe a new entry in the control syntax help is sufficient?

3. I don't see this as an special exception because the library rules are not meant to be used stand-alone. So, in my mind, # *.any should only refer to user-defined procedures (rules and recipes).

Original comment by: zambon

[rensink]

1. I would prefer to remain compatible to the current syntax, and frankly I never saw why Python has these two difference syntactical forms (and I keep mixing them up). But we could allow import a.b for subpackages b as well as control programs, after which b.c would actually stand for a.b.c; and it's a very small step to extend this to import a.b as ab, after which ab.c stands for a.b.c. It would require, however, that we impose a restriction that it's not allowed to have overlap of subpackage names and control program names. That should then also apply to other resources, meaning no overlap of file names (irregardless of extensions).

2. As you konw, I always want to understand how this generalises. We're about to introduce the concept of a library. OK, I see you might limit the visualised rules to the user-defined ones.

3. Same as for 2: yes, *.any could refer to user-defined rules.

Original comment by: rensink

[rensink]

1. Come to think of this from a different angle, it seems an unnecessary complication, and I'm always in favor of keeping things simple. My current reasoning is whether this is actually going to be used in practice. I expect that even the larger grammars won't have a complex package structure for control programs, so putting effort in developing this might not payoff so much. As another possibility, we could introduce not one library attr with subpackages but several independent packages int, float, etc...

2. Sure, but I think that we should only worry about generalization when we have more than one instance of something. ;) (OK, my new proposal for 1. would introduce several packages... :P)

Original comment by: zambon