Differences

This shows you the differences between two versions of the page.

--- language:types2 [2026/08/05 15:07] – [Non-strict template parameters] rajit
+++ language:types2 [2026/08/09 13:10] (current) – [Non-strict template parameters] rajit
@@ Line 153: / Line 153: @@
 the type. Hence, when checking for type compatibility, the values of
 parameters are also taken into account. Hence, the full type for
-instance ''a2'' above is in fact ''adder<5>'', not just
+instance ''a2'' above is in fact ''adder<16>'', not just
 ''adder''. Types such as ''fulladder'' that do not have
 parameters are more completely specified as ''fulladder<>'',
@@ Line 463: / Line 463: @@
 ...
 </code>
-This will also result in the same circuit as the earlier example, because the value ''17'' is a parameter and so ACT can specialize the circuit to use this value.
+This will also result in the same circuit as the earlier example, because the value ''17'' is a parameter and so, after expansion, the CHP to be synthesized will have the constant value ''17'' as a fixed input to the adder.
+What if we wanted to create an array of these adders? While
+<code act>
+...
+addbuf<8,17> mybuf[8];
+</code>
+is fine, the problem arises if we want each ''addbuf'' to add a //different// value. The following program
+<code act>
+addbuf<8,17> mybuf[0..0];
+addbuf<8,18> mybuf[1..1];
+</code>
+will result in the error message
+<code>
+-[ERROR]-> Sparse array type error on mybuf
+                   Orig type: addbuf<8,17>
+                   New type: addbuf<8,18>
+</code>
+This is because elements of an array must have the same type. As this is a useful use-case, ACT has support for a special type of template parameter introduced for this scenario.
+Template parameters for processes can be of two types:
+   * //strict// parameters, which are the ones we have been considering so far. Elements of an array must have the same strict template parameters.
+   * //non-strict// parameters, which can be varied within an array.
+Non-strict parameters are separated from strict parameters by a vertical bar. The example above would be written as follows:
+<code act>
+template<pint W | pint VAL>
+defproc addbuf(chan?(int<W>) L; chan!(int<W>) R)
+{
+   int<W> x;
+   chp {
+      *[ L?x; R!(x+VAL) ]
+   }
+}
+...
+addbuf<8,17> mybuf[0..0];
+addbuf<8,18> mybuf[1..1];
+...
+</code>
+ACT will allow this syntax. This comes with a few caveats:
+    * Any ports for the type can only use strict parameters.  In other words, the type signature can only depend on strict parameters. This is what permits different process types to be mixed within a single array, since the external interface to the array elements remains unchanged. So<code act>
+template<pint W | pint VAL>
+defproc oddbuf(chan?(int<W>) L; chan!(int<W+VAL>) R)
+{
+...
+}
+</code>will lead to the following error<code>
+-[ERROR]-> Expressions in port parameter list can only use strict template parameters
+</code>
+   * Even if the array is dense, it will be treated as a sparse array with multiple chunks where each chunk can have different non-strict parameters.
+   * Sub-array expressions cannot be used where different elements have different types.
+Since the general ACT syntax can be used, the following would also be valid:
+<code act>
+...
+(i:8: addbuf<8,17+i> mybuf[i..i];)
+...
+</code>