CAL 1 permitted indexers that contained more than one index:
a[1, 2]
Instead, we also allow a[1][2], which is what is used in C/Java.
One rationale of the original design was that CAL actually does not permit indexing "paths" longer than 1 on the left-hand side of an assignment. So while the current interpreter permits both a[1,2] and a[1][2] as *expressions* (and treats them identically), it actually does NOT permit
a[1][2] := 11; // ERROR
while the form
a[1, 2] := 11; // OKAY
is fine.
There have been several suggestions to permit arbitary paths (including indexers and field selectors, i.e. constructions of the form a.f) on the left-hand side. This would get rid of the inconsistency, and we could eliminate the multi-index syntax.
Are there any ramifications re: aliasing in doing so? I believe that was one of the original concerns, but I cannot really reconstruct the problem (we did not use a forum such as this back then... ;-).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a poor understanding of the real problem here. I assume that we chose the "a[1,2]" syntax to
be "MATLAB compatible" and allow for support or proper matrices, not C/Java-stype arrays of arrays of arrays. The reasoning was that the index list (here [1, 2]) was passed on as an argument to the implementation of the matrix. This would, for example, allow for efficient implementation sparse matrices, since the matrix was a self contained data type, rather than an array of arrays.
To me "a[1][2]" is a slightly different data structure, possibly heterogenous wrt to size
and type of the second element.
I think we could support both forms:
a[1][2] := 11;
a[1, 2] := 11;
and also
a[1] := array() // whatever syntax there could be to create an array.
But, again, since I don't see the problem with multi-index could you maybe please clarify the problem.
Is it a syntactical or a semantical issue?
Cheers,
Johan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm in favor of choosing one syntax and stick to it. If two syntaxes are allowed, it will be possible to write things such as a[1, 2][3] or a[1][2, 3] and I'm not sure it helps keeping source code homogeneous.
Plus since most languages used today have a C-like syntax for access to multi-dimensional arrays (C, C++, Java, C#, Perl, PHP, JavaScript etc.), it might be good to follow this notation.
Cheers,
Matthieu
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would agree with choosing one syntax, and I think the fact that there is one that seems to be very popular is definitely a good point.
I think I have no problem with following this convention. I guess if we do we need to resolve the question of what it means to use fewer indices than the dimensionality of the array, but I guess we can just follow Java et al. and just define this to mean that a corresponding sub-array has been selected.
One thing we need to define, then, is whether we require arrays to be rectangular, and also whether there are "arrays" that are not lists. Also, I think the list type declaration syntax is hugely verbose, and it does not get any better when these things become multi-dimensional, so we might want to do something about that. Maybe add some syntactic sugar?
-- j
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I think I have no problem with following this convention. I guess if we do we need to resolve the question of what it means to use fewer indices than the dimensionality of the array, but I guess we can just follow Java et al. and just define this to mean that a corresponding sub-array has been selected.
I agree.
> One thing we need to define, then, is whether we require arrays to be rectangular, and also whether there are "arrays" that are not lists.
As far as SW code generation is concerned, ORCC currently considers lists as arrays, with all the limitations it imposes: No concatenation, static size, etc. I think that the "lists" used in both Xilinx and RVC versions of the MPEG-4 decoder are more arrays than lists.
The problem posed is far from trivial however, for instance what is the meaning of the statement
x := y;
when x and y are lists, and when x and y are arrays?
Following C conventions, assigning an array to another is forbidden, and C has no lists. Following Java conventions, both arrays and lists are Objects, so it means that x references y.
If x and y are lists, with CAL x will become a copy of y. If x and y were arrays, would the assignment be forbidden?
> Also, I think the list type declaration syntax is hugely verbose, and it does not get any better when these things become multi-dimensional, so we might want to do something about that. Maybe add some syntactic sugar?
Actual syntax:
List(type:List(type:int(size=12), size=4), size=3) myList
again coming from "mainstream" languages, what about:
int(size=12) myList[3][4]
?
And that does not even take half as much space :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"As far as SW code generation is concerned, ORCC currently considers lists as arrays, with all the limitations it imposes: No concatenation, static size, etc. I think that the "lists" used in both Xilinx and RVC versions of the MPEG-4 decoder are more arrays than lists."
That's true. I do think it would be desirable to keep lists in their full generality, and allow for array-like uses as a special case.
I guess the question is whether we need a separate array type in addition to this. I suspect not.
"The problem posed is far from trivial however, for instance what is the meaning of the statement
x := y;
when x and y are lists, and when x and y are arrays?
Following C conventions, assigning an array to another is forbidden, and C has no lists. Following Java conventions, both arrays and lists are Objects, so it means that x references y.
If x and y are lists, with CAL x will become a copy of y. If x and y were arrays, would the assignment be forbidden? "
x is a perfectly fine variable, so assigning to it should not be forbidden. I think that the principle we have so far followed in CAL (even though it is not always implemented entirely accurately) is that everything but closures has value-semantics. With that, the result will be a copy, also in accordance with section 7.1.4 of the CLR.
"int(size=12) myList[3][4]
?
And that does not even take half as much space :-)"
Sure, if we decide to add syntactic sugar, it should probably look something like this.
-- j
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
CAL 1 permitted indexers that contained more than one index:
a[1, 2]
Instead, we also allow a[1][2], which is what is used in C/Java.
One rationale of the original design was that CAL actually does not permit indexing "paths" longer than 1 on the left-hand side of an assignment. So while the current interpreter permits both a[1,2] and a[1][2] as *expressions* (and treats them identically), it actually does NOT permit
a[1][2] := 11; // ERROR
while the form
a[1, 2] := 11; // OKAY
is fine.
There have been several suggestions to permit arbitary paths (including indexers and field selectors, i.e. constructions of the form a.f) on the left-hand side. This would get rid of the inconsistency, and we could eliminate the multi-index syntax.
Are there any ramifications re: aliasing in doing so? I believe that was one of the original concerns, but I cannot really reconstruct the problem (we did not use a forum such as this back then... ;-).
Hi all,
I have a poor understanding of the real problem here. I assume that we chose the "a[1,2]" syntax to
be "MATLAB compatible" and allow for support or proper matrices, not C/Java-stype arrays of arrays of arrays. The reasoning was that the index list (here [1, 2]) was passed on as an argument to the implementation of the matrix. This would, for example, allow for efficient implementation sparse matrices, since the matrix was a self contained data type, rather than an array of arrays.
To me "a[1][2]" is a slightly different data structure, possibly heterogenous wrt to size
and type of the second element.
I think we could support both forms:
a[1][2] := 11;
a[1, 2] := 11;
and also
a[1] := array() // whatever syntax there could be to create an array.
But, again, since I don't see the problem with multi-index could you maybe please clarify the problem.
Is it a syntactical or a semantical issue?
Cheers,
Johan
Hi all,
I'm in favor of choosing one syntax and stick to it. If two syntaxes are allowed, it will be possible to write things such as a[1, 2][3] or a[1][2, 3] and I'm not sure it helps keeping source code homogeneous.
Plus since most languages used today have a C-like syntax for access to multi-dimensional arrays (C, C++, Java, C#, Perl, PHP, JavaScript etc.), it might be good to follow this notation.
Cheers,
Matthieu
I would agree with choosing one syntax, and I think the fact that there is one that seems to be very popular is definitely a good point.
I think I have no problem with following this convention. I guess if we do we need to resolve the question of what it means to use fewer indices than the dimensionality of the array, but I guess we can just follow Java et al. and just define this to mean that a corresponding sub-array has been selected.
One thing we need to define, then, is whether we require arrays to be rectangular, and also whether there are "arrays" that are not lists. Also, I think the list type declaration syntax is hugely verbose, and it does not get any better when these things become multi-dimensional, so we might want to do something about that. Maybe add some syntactic sugar?
-- j
> I think I have no problem with following this convention. I guess if we do we need to resolve the question of what it means to use fewer indices than the dimensionality of the array, but I guess we can just follow Java et al. and just define this to mean that a corresponding sub-array has been selected.
I agree.
> One thing we need to define, then, is whether we require arrays to be rectangular, and also whether there are "arrays" that are not lists.
As far as SW code generation is concerned, ORCC currently considers lists as arrays, with all the limitations it imposes: No concatenation, static size, etc. I think that the "lists" used in both Xilinx and RVC versions of the MPEG-4 decoder are more arrays than lists.
The problem posed is far from trivial however, for instance what is the meaning of the statement
x := y;
when x and y are lists, and when x and y are arrays?
Following C conventions, assigning an array to another is forbidden, and C has no lists. Following Java conventions, both arrays and lists are Objects, so it means that x references y.
If x and y are lists, with CAL x will become a copy of y. If x and y were arrays, would the assignment be forbidden?
> Also, I think the list type declaration syntax is hugely verbose, and it does not get any better when these things become multi-dimensional, so we might want to do something about that. Maybe add some syntactic sugar?
Actual syntax:
List(type:List(type:int(size=12), size=4), size=3) myList
again coming from "mainstream" languages, what about:
int(size=12) myList[3][4]
?
And that does not even take half as much space :-)
"As far as SW code generation is concerned, ORCC currently considers lists as arrays, with all the limitations it imposes: No concatenation, static size, etc. I think that the "lists" used in both Xilinx and RVC versions of the MPEG-4 decoder are more arrays than lists."
That's true. I do think it would be desirable to keep lists in their full generality, and allow for array-like uses as a special case.
I guess the question is whether we need a separate array type in addition to this. I suspect not.
"The problem posed is far from trivial however, for instance what is the meaning of the statement
x := y;
when x and y are lists, and when x and y are arrays?
Following C conventions, assigning an array to another is forbidden, and C has no lists. Following Java conventions, both arrays and lists are Objects, so it means that x references y.
If x and y are lists, with CAL x will become a copy of y. If x and y were arrays, would the assignment be forbidden? "
x is a perfectly fine variable, so assigning to it should not be forbidden. I think that the principle we have so far followed in CAL (even though it is not always implemented entirely accurately) is that everything but closures has value-semantics. With that, the result will be a copy, also in accordance with section 7.1.4 of the CLR.
"int(size=12) myList[3][4]
?
And that does not even take half as much space :-)"
Sure, if we decide to add syntactic sugar, it should probably look something like this.
-- j