ClemsonRSRG/RESOLVE — pull request #71 by Welchd1 (2013-09-21 16:57:47+00:00)
Title: Populator adds

HwS defined this method in typeandpopulate/Scope.java:

public List getFormalParameterEntries();

which

"Returns a list of ProgramParameterEntries contained directly in this scope. These correspond to the formal
parameters defined by the syntactic element that introduced the scope. If there are no parameters, or the
syntactic element is not of the sort that can define parameters, returns an empty list."

This works fine 99% of the time, but not for moduleScope since it can have operationEntries that serve as formal parameters. This method ignores these since, when iterating over the symboltable bindings and adding relevant entries to the result list, operations fail to get added because they are a completely different symbolTableEntry type. Perhaps this wasn't an oversight? No matter, for translation, it would be very nice if we could somehow get operationEntries recognized since we need to be able to obtain somehow formal parameters to a module, not just those that happen to be programParameterEntries

For now I've changed the method to return a List pf symbolTableEntrys and simply told the method implementing all of this that it should also consider relevant operationEntries. The "relevant" operationEntries had to be specially marked in population since, right now, the compiler doesn't seem to distinguish in any discernable way between a "normal" operation declarations existing somewhere insignificant in-scope, and those acting as formal parameters to a module.

I do realize this is getting long-winded but it helps me to write it out before I'll (most likely) have to explain/reason-it out in person to someone who will listen -- probably the janitors again. So give me my writing space:

This isn't a final solution by any means. First off, HwS defines "pieces" of a facility (i.e. the specification, implementation, and (enhancement/realization pairs)) as something called "moduleParameterization"s. For example,

facility SF is "moduleParameterization" realized by "moduleParameterization";

From these moduleParameterizations you can get most things you would ever want/need. Things like moduleIdentifiers, actual parameters passed in, etc. However, in order to get the FORMAL parameters belonging to the module referenced by the moduleParameterization, we need to use a method in moduleParameterization called "getScope". This method returns a Scope object which finally allows us to use the "getFormalParameterEntries" method which, was the original point to this post.

However, this is where things get hairy.. When we write .getScope(...) we are given the option of passing in true or false to getScope. From what I can tell -- and I'm still struggling with how exactly all this works -- if you pass in true, then hampton attempts to "instantiate generics" in the module that our facility is referring to. He does this using some functional programming techniques (foldr2) that I have not entirely figured out yet. I'm not even sure yet if it is possible to use what he has there on operationEntries (it seems very specifically designed around programParameterEntries). So for the time being, I sidestep actually passing relevant operationEntries into that foldr2 method and pretend that the list looks like it originally did without them.

To sum up, It's our job to figure out what those methods do and how they work so we can do this the right way.