data-parallel/vect-pragma.md

@@ -94,29 +94,31 @@ For a type constructor `T`, the pragma
 ```
 
 
-indicates that the type `T` should be vectorised and embeds no parallel arrays.  This is the same as where the vectoriser automatically decides to vectorise a type, but no special vectorised representation needs to be generated as the type embeds no arrays.  The purpose of this pragma is to enable the vectorisation of imported types from modules that where not compiled with vectorisation enabled.
-
-
-The data type constructor `T` that together with its constructors `Cn` may be used in vectorised code, where `T` and the `Cn` represent themselves in vectorised code. An example is the treatment of 'Bool'.  'Bool' together with 'False' and 'True' may appear in vectorised code and they remain unchanged by vectorisation.  (There is no need for a special representation as the values cannot embed any arrays.)
+indicates that the type `T` should be automatically vectorised even if it is imported.  This is the default for all data types declared in the current module. If the type embeds no parallel arrays, no special vectorised representation will be generated. 
 
 
 The type constructor `T` must be in scope, but it may be imported.  'PData' and 'PRepr' instances are automatically generated by the vectoriser.
 
-**ALTERNATIVE:** This pragma simply means to treat an imported tycon as if it was defined in this module (and is automatically vectorised as usual).  This is what I just implemented.
-
-**OPEN QUESTION:**
 
-- Do we need to be able to specify that an imported type embedding arrays should be vectorised including the generation of a specialised right-hand side?
+Examples are the vectorisation of types, such as `Ordering` and `[]`, defined in the `Prelude`.
 
 ### With right-hand side
 
+
+For a type constructor `T`, the pragma
+
 ```wiki
 {-# VECTORISE type T = T' #-}
 ```
 
-**TODO**
 
-- This isn't fully implemented yet.  (Implemented up to and including desugaring and being put into `ModGuts`, but not used in the vectoriser.)
+directs the vectoriser to replace `T` by `T'` in vectorised code and to use the corresponding data constructors of `T'` instead of those of `T`.  This implies that the two type constructors must be of the same kind and that the data constructors of `T` and `T'` need to be of the same number and type. 
+
+
+The type constructor `T` must be in scope, but it may be imported.  'PData' and 'PRepr' instances must be explicitly defined — they are not automatically generated.
+
+
+An example is the handling of `Bool`, where we represent `Bool` by itself in vectorised code, but want to use the custom instances of 'PData' and 'PRepr' defined in the DPH libraries.
 
 ## The VECTORISE SCALAR pragma for type constructors
 
@@ -137,7 +139,7 @@ Due to this pragma declaration, `T` that may be used in vectorised code, where `
 The type constructor `T` must be in scope, but it may be imported.  The `PData` and `PRepr` instances for `T` need to be manually defined.  (For types that the vectoriser automatically determines that they don't need a vectorised version, instances for `PData` and `PRepr` are still generated automatically.)
 
 
-NB: The crucial difference between `{-# VECTORISE type T1 #-}` and `{-# VECTORISE SCALAR type T2 #-}` is that the \*representation\* (i.e., the constructors) of the latter can only be used in scalar code. However, the representation of both `T1` and `T2` does not get vectorised — so, both types are suitable for code that does not get vectorised due to vectorisation avoidance.
+NB: The crucial difference between `{-# VECTORISE SCALAR type T1 #-}` and `{-# VECTORISE type T2 #-}`, where `T2` embeds no parallel arrays, is that the \*representation\* (i.e., the constructors) of the former can only be used in scalar code. However, neither the representation of `T1` nor `T2` does get vectorised — so, both types are suitable for code that does not get vectorised due to vectorisation avoidance.
 
 **TODO**
 
@@ -147,4 +149,4 @@ NB: The crucial difference between `{-# VECTORISE type T1 #-}` and `{-# VECTORIS
 ## Cross-module functionality
 
 
-The various `VECTORISE` pragmas can be applied to imported identifiers (both variables and types).  The resulting vectorisation mappings and the vectorised version of the identifier will will be implicitly exported — much like it is the case for `RULES` defined on imported identifiers.
+The various `VECTORISE` pragmas can be applied to imported identifiers (both variables and types).  The resulting vectorisation mappings and the vectorised version of the identifier will be implicitly exported — much like it is the case for `RULES` defined on imported identifiers.