Ticket #291 (new defect)
Opened 13 months ago
Indexed setters appear to use the same naming as indexed getters.
| Reported by: | jmaessen | Owned by: | dr2chase |
|---|---|---|---|
| Priority: | blocker | Milestone: | |
| Component: | interpreter | Version: | |
| Keywords: | Cc: |
Description
It appears that indexed setters are not clearly distinguished from indexed getters in the interpreter. To exhibit the bug, uncomment the lines after "Indexing by pairs of ranges" in source:trunk/Library/FortressLibrary.fss, run source:trunk/ProjectFortress/tests/subArray.fss, and note that you obtain an error of the following form:
/Users/jmaessen/PFC/Library/FortressLibrary.fss:1650:4-1651:37: and /Users/jmaessen/PFC/Library/FortressLibrary.fss:2215:2-2218:7: first parameters v:[Indexed[\ZZ32,(ZZ32,ZZ32)\], TrivialOpenRange] and r:[Range[\ZZ32\], TrivialOpenRange] are unrelated (neither subtype, excludes, nor equal) and no excluding pair is present
Note that the former set of lines are the following declaration:
opr[_:TrivialOpenRange]:=(v:Indexed[\E,I\]) : () =
do self[self.bounds] := v end
and the latter are an uncommented declaration:
opr[r:(Range[\ZZ32\], TrivialOpenRange)]: Array[\T,(ZZ32,ZZ32)\] = do
Note also that I uglified these declarations (introducing an explicit tuple) to see if it would help. It prevents conflicts in two of the four cases. Note also that there are two potentially conflicting setter declarations and four potentially conflicting getter declarations, so you might obtain a different pair than the one I showed here, but the principle is the same in all of them.
This is blocking work on the array sublanguage (as should be obvious if you take a close look at the code).

