RE: Hugs/GHC incompatibility
| I think, I've found the problem. GHC seems to not implement Data.Array.array | correctly. The implementation doesn't adhere to the following sentence from | the Data.Array.IArray.array documentation: | If any two associations in the list have the same index, the value at that | index is undefined. | Could this be fixed? It's a documented incompatibility with H98 http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs-and-infelic ities.html#HASKELL98-DIVERGENCE We don't intend to fix this because fixing it will have a significant overhead on every array construction. Actually I rather think H98 should have left the behaviour of double indices undefined, rather than defining it to be bottom. But it's too late now. Simon
Am Dienstag, 3. Februar 2004 18:17 schrieb Simon Peyton-Jones:
I think, I've found the problem. GHC seems to not implement Data.Array.array correctly. The implementation doesn't adhere to the following sentence from the Data.Array.IArray.array documentation: If any two associations in the list have the same index, the value at that index is undefined.
Could this be fixed?
[...]
We don't intend to fix this because fixing it will have a significant overhead on every array construction.
Sorry, but I don't see where the overhead should come from.
[...]
Simon
Wolfgang
hi, i am speculating here, but i guess that if double initializations were to result in _|_ one would have to check if a cell has already been initialized, and if so replace it with _|_. currently ghc probably simply overwrites the array elements. i personally prefer ghc's behavior. -iavor Wolfgang Jeltsch wrote:
Am Dienstag, 3. Februar 2004 18:17 schrieb Simon Peyton-Jones:
I think, I've found the problem. GHC seems to not implement Data.Array.array correctly. The implementation doesn't adhere to the following sentence from the Data.Array.IArray.array documentation: If any two associations in the list have the same index, the value at that index is undefined.
Could this be fixed?
[...]
We don't intend to fix this because fixing it will have a significant overhead on every array construction.
Sorry, but I don't see where the overhead should come from.
[...]
Simon
Wolfgang
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
-- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================
participants (3)
-
Iavor S. Diatchki -
Simon Peyton-Jones -
Wolfgang Jeltsch