Hugs/GHC incompatibility
Hello, I have some code which runs fine with GHC/GHCi but signals Program error: undefined array element when run with Hugs. Does anyone know why this difference occurs and where I have to search for the cause of the error in my code? Wolfgang
Am Mittwoch, 21. Januar 2004 21:52 schrieb Wolfgang Jeltsch:
Hello,
I have some code which runs fine with GHC/GHCi but signals Program error: undefined array element when run with Hugs. Does anyone know why this difference occurs and where I have to search for the cause of the error in my code?
Wolfgang
Hello again, 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? Wolfgang
hi, not that it matters, but i think commonly when specifications say that something is undefined, that means that the behaviour can be whatever, i.e. the implementors can do what they like. this is not to be confused with the entity "undefined" defined in the Prelude. -iavor Wolfgang Jeltsch wrote:
Am Mittwoch, 21. Januar 2004 21:52 schrieb Wolfgang Jeltsch:
Hello,
I have some code which runs fine with GHC/GHCi but signals Program error: undefined array element when run with Hugs. Does anyone know why this difference occurs and where I have to search for the cause of the error in my code?
Wolfgang
Hello again,
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?
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 | ==================================================
Am Mittwoch, 21. Januar 2004 23:03 schrieb Iavor S. Diatchki:
hi,
not that it matters, but i think commonly when specifications say that something is undefined, that means that the behaviour can be whatever, i.e. the implementors can do what they like. this is not to be confused with the entity "undefined" defined in the Prelude.
Hmm, I didn't think of this interpretation. If this is the right one, then maybe it should be made more clear that the sentence in the array documentation doesn't mean Prelude.undefined. In addition, I would like as little undefinedness as possible, i.e., different implementations behaving as similar as possible. So I'd be happy if the handling of duplicate indices was defined by the library specification.
-iavor
Wolfgang
On Wed, 21 Jan 2004, Wolfgang Jeltsch wrote:
In addition, I would like as little undefinedness as possible, i.e., different implementations behaving as similar as possible. So I'd be happy if the handling of duplicate indices was defined by the library specification.
I agree (in this case at least), and in fact I'd like the semantics to be defined as array = accumArray (\a b -> b) _|_. Reasons: I think it's the most efficient to implement, and it would allow about half of my uses of accumArray to be replaced by array. (I think this is GHC's current behavior.) -- Ben
On 2004.01.21 15:03, Iavor S. Diatchki wrote:
hi, not that it matters, but i think commonly when specifications say that something is undefined, that means that the behaviour can be whatever, i.e. the implementors can do what they like. this is not to be confused with the entity "undefined" defined in the Prelude. -iavor
Well, except that denotationally, they are the same. --Joe Joseph H. Fasel, Ph.D. email: jhf@lanl.gov Systems Planning and Analysis phone: +1 505 667 7158 University of California fax: +1 505 667 2960 Los Alamos National Laboratory post: D-2 MS F609; Los Alamos, NM 87545
hello, i don't quite agree with this. if something is "undefined" as in the prelude, i should be able to prove that this is the case -- bottom is just another value, admitedly not a very nice one :-) on the other hand, if something is undefined in the specification (i.e. implementer can do whatever), than i cannot prove anything about that part of the program. in particular i cannot prove that it is bottom. i agree that this is a highly undesirable thing to have in a specification, but haskell is much better in that respect that most languages out there. -iavor Joe Fasel wrote:
On 2004.01.21 15:03, Iavor S. Diatchki wrote:
hi, not that it matters, but i think commonly when specifications say that something is undefined, that means that the behaviour can be whatever, i.e. the implementors can do what they like. this is not to be confused with the entity "undefined" defined in the Prelude. -iavor
Well, except that denotationally, they are the same.
--Joe
Joseph H. Fasel, Ph.D. email: jhf@lanl.gov Systems Planning and Analysis phone: +1 505 667 7158 University of California fax: +1 505 667 2960 Los Alamos National Laboratory post: D-2 MS F609; Los Alamos, NM 87545 _______________________________________________ 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 | ==================================================
On 2004.01.21 15:03, Iavor S. Diatchki wrote:
hi, not that it matters, but i think commonly when specifications say that something is undefined, that means that the behaviour can be whatever, i.e. the implementors can do what they like. this is not to be confused with the entity "undefined" defined in the Prelude.
On second thought, I wouldn't think that an implementation is entitled to yield a defined value in place of bottom. Cheers, --Joe Joseph H. Fasel, Ph.D. email: jhf@lanl.gov Systems Planning and Analysis phone: +1 505 667 7158 University of California fax: +1 505 667 2960 Los Alamos National Laboratory post: D-2 MS F609; Los Alamos, NM 87545
participants (4)
-
Ben Rudiak-Gould -
Iavor S. Diatchki -
Joe Fasel -
Wolfgang Jeltsch