Reduce splitAt to undefined in illegal contexts
#2835
Conversation
Previously, the Clash compiler would try to reduce ``` splitAt d1 Nil ``` to something of type ``` (Vec 1 a, Vec (0-1) a) ``` by trying to project the head and the tail out of the `Nil` constructor. This of course does not work resulting in an out-of-bounds indexing error reported in: #2831 The compiler now reduces above expressions to: ``` undefined :: (Vec 1 a, Vec (0-1) a) ``` Which is morally equivalent to the run-time exception Haskell evaluation would have thrown if the circuit description was evaluated like a regular Haskell program. Fixes #2831
|
Perhaps reduce to |
Why wouldn't we want to generate HDL for something like |
|
Because I would say that is nonsensical to generate hardware for. Or rather, my question would be. Why would you want to generate HDL for that? Essentially you have a malformed term, which is something different then something undefined. |
|
I do not want the compiler to generate If we just generate |
Previously, the Clash compiler would try to reduce ``` splitAt d1 Nil ``` to something of type ``` (Vec 1 a, Vec (0-1) a) ``` by trying to project the head and the tail out of the `Nil` constructor. This of course does not work resulting in an out-of-bounds indexing error reported in: #2831 The compiler now reduces above expressions to: ``` undefined :: (Vec 1 a, Vec (0-1) a) ``` Which is morally equivalent to the run-time exception Haskell evaluation would have thrown if the circuit description was evaluated like a regular Haskell program. Fixes #2831 (cherry picked from commit 10f26ff)
Previously, the Clash compiler would try to reduce ``` splitAt d1 Nil ``` to something of type ``` (Vec 1 a, Vec (0-1) a) ``` by trying to project the head and the tail out of the `Nil` constructor. This of course does not work resulting in an out-of-bounds indexing error reported in: #2831 The compiler now reduces above expressions to: ``` undefined :: (Vec 1 a, Vec (0-1) a) ``` Which is morally equivalent to the run-time exception Haskell evaluation would have thrown if the circuit description was evaluated like a regular Haskell program. Fixes #2831 (cherry picked from commit 10f26ff)
Previously, the Clash compiler would try to reduce ``` splitAt d1 Nil ``` to something of type ``` (Vec 1 a, Vec (0-1) a) ``` by trying to project the head and the tail out of the `Nil` constructor. This of course does not work resulting in an out-of-bounds indexing error reported in: #2831 The compiler now reduces above expressions to: ``` undefined :: (Vec 1 a, Vec (0-1) a) ``` Which is morally equivalent to the run-time exception Haskell evaluation would have thrown if the circuit description was evaluated like a regular Haskell program. Fixes #2831 (cherry picked from commit 10f26ff) Co-authored-by: Christiaan Baaij <[email protected]>
Previously, the Clash compiler would try to reduce
to something of type
by trying to project the head and the tail out of the
Nilconstructor. This of course does not work resulting in an out-of-bounds indexing error reported in:#2831
The compiler now reduces above expressions to:
Which is morally equivalent to the run-time exception Haskell evaluation would have thrown if the circuit description was evaluated like a regular Haskell program.
Fixes #2831
Still TODO: