- Hugs-Bugs - Haskell.org

strange bug
by andreas.marth＠daimlerchrysler.com 02 Mar '01

02 Mar '01

Hallo everybody! The file bug1.hs includes an example where acording to main sT==sXXP is True, but sXXP==sT is False. The file bug2.hs doesn't have the problem after inlinige one where clause. The file bug3.hs also doesn't have the problem after adding a type signature to the function "h0CMt". So what exactly is the problem here? Thanks, Andreas

2 1

Re: possible bug?
by Sigbjorn Finne 02 Mar '01

02 Mar '01

Jonathon Bell jbell(a)mathsoft.com writes: > > i'm tinkering with the Feb 2001 release of hugs, and came across the > following problem while attempting to create my own prelude: > > module MyPrelude where > > import Prelude((:)) > > hd(x:xs) = x > ... > > The compiler complains of a syntax error occuring in the import declaration: > (unexpected symbol ":"). I may well be mistaken since i am somewhat new to > haskell programming, but it seems to me that i ought to be able to > explicitly import the list type constructor just like any other identifier No, the cons operator has special status in H98 (in earlier version of Haskell, this wasn't the case); it is considered to be part of the syntax for lists, just like [] and [x1,x2] is. See the discussion of reservedops in Section 2.4 of the report. hth --sigbjorn

1 0

possible bug?
by Jonathon Bell 02 Mar '01

02 Mar '01

i'm tinkering with the Feb 2001 release of hugs, and came across the following problem while attempting to create my own prelude: module MyPrelude where import Prelude((:)) hd(x:xs) = x ... The compiler complains of a syntax error occuring in the import declaration: (unexpected symbol ":"). I may well be mistaken since i am somewhat new to haskell programming, but it seems to me that i ought to be able to explicitly import the list type constructor just like any other identifier. Thanks for a doing a great job supporting hugs, and keep up the good work... ________________________________ Jonathon Bell jbell(a)mathsoft.com MathSoft, Inc. www.mathsoft.com 101 Main St, Cambridge, MA 02142 (617) 577-1017 x745

3 3

Hugs 2001 release running under Windows 2000
by Jamie Stevenson 01 Mar '01

01 Mar '01

Hello I am trying to run Hugs Feb 2001 release under Windows 2000. File system is NTFS. Hugs is sitting in its own folder (Hugs98) on the my c drive. Can't run it - if you can give me any comments I would be greatly appreciative. e-mail: stevensj(a)dcs.gla.ac.uk Many thanks Jamie Stevenson

1 0

Bug in Hugs 98 MacOS Feb-2001: Crash while Compiling Multiple-Argument Fundep
by Ashley Yakeley 01 Mar '01

01 Mar '01

Product: Hugs 98 MacOS Feb-2001 Hugs Preferences: -98 -h1000000 To Repro: attempt to load a file with this line: class C a b c | a,b -> c where Results: Hugs 98 crashes with a "Type 2 Error" Expected: Is this valid extended Haskell? Compile it or give an error. -- Ashley Yakeley, Seattle WA

1 0

RE: Feb2001 hugs98 on MacOS
by Hans Aberg 01 Mar '01

01 Mar '01

At 02:41 -0800 2001/03/01, Julian Seward (Intl Vendor) wrote: >I tend to sympathise with Alastair/Johan. For us, keeping GHC >working on one platform is not too difficult. Trying to ensure >that it keeps going on all supported platforms without inordinate >amounts of effort, is IMO easily the biggest engineering challenge >we face. Well, as the MacOS implementation, it was developed in small chunks at need, but the Hugs team seemed to not bother to put it in for the last few years. Thus, they now have a large backlog. The MacOS intrusions are not that big: The MacOS (pre-X) is distinctively different from any other platform in that it does not have a shell, and that forces the need of hooks. The MacOS does not provide stack-checks, so that has to be implemented by intrusion into the code. Nor does it have pre-emptive multitasking, only cooperative, which means that one must intrude into the code to release time to other programs. Etc. As Alan said, these things ought really to be a part of the Hugs distribution, as they might be of importance to other platforms. In fact, some of the MacOS stuff was implemented by riding on the code intrusions already made for the MS Windows. It seems me that Johan Nordlander, the first person for a few years bothering about this Mac stuff at all, is new to it, so he has picked out everything that he does not immediately understand. However, he then pretty much breaks everything that makes the MacOS version useful. To fix it up on the course he lays out will take up a lot of time, as Mac programming is very time consuming. (Kevin Hammond spend more time on the Mac GUI than what spent on the Hugs kernel at that time!) On the other hand, there is now a MacOS X, which has existed half-a-year in a beta, and gets public by the end of March. MacOS X does have pre-emptive multitasking, stack-checks, threading (it is built up around a Mach 3 kernel), and the other stuff expected of a modern OS plus some. So much of that special pre-MacOS X will not be needed. So, on the one hand, Johan Nordlander at this late date lays out an extremely time-consuming course for himself, hoping others to join, while on the same time, it looks it is not worth spending any time at it at all as far as pre-MacOS X implementation goes. Some of the stuff may survive if there still are cooperative multitasking platforms under which Hugs may run. Hans Aberg

1 0

RE: Feb2001 hugs98 on MacOS
by Julian Seward (Intl Vendor) 01 Mar '01

01 Mar '01

| Some advice to people submitting changes: | | Back in the days when I was maintaining Hugs, changes were substantially more | likely to be merged into the main base if they were decomposed into a number of | small, independent changes whose impact and consequences could be understood in | isolation from the other changes. The same issue crops up from time to time for the Linux kernel development community, wherein the keepers of the kernel (Torvalds, Cox, et al) are much more likely to accept patches in the form Alastair describes, precisely for the reason he mentions, and those whose large, all-encompassing patches are rejected get hot under the collar. Assimilation of large chunks of code implementing new subsystems (ie, the ReiserFS file system) is slow indeed. So this is not by any means a new problem. I tend to sympathise with Alastair/Johan. For us, keeping GHC working on one platform is not too difficult. Trying to ensure that it keeps going on all supported platforms without inordinate amounts of effort, is IMO easily the biggest engineering challenge we face. </red-herring> J

1 0

AW: "Compiled code too complex" error message - Problem solved.
by Laaser Christian 01 Mar '01

01 Mar '01

Thank you very much for your message. I think the new Feb 2001 distribution doesn't use the large version. Look at the code extract from options.h: #define SMALL_HUGS 0 #define REGULAR_HUGS 0 #define LARGE_HUGS 0 If I understand it correctly LARGE_HUGS should normally be defined as 1 so that the large version is used by default. I can confirm that changing NUM_FIXUPS to 1000 solves my problem because I used Feb 2001 distribution with the modified hugs.exe Karl M. Syring sent me and the interpreter is working fine. Christian > -----Urspr> üngliche Nachricht----- > Von: Alastair Reid [SMTP:reid@cs.utah.edu] > Gesendet am: Montag, 26. Februar 2001 18:22 > An: Laaser Christian; 'Mark P Jones' > Cc: hugs-bugs(a)haskell.org; kort(a)wins.uva.nl; Lescher Christian > Betreff: RE: AW: What does "Compiled code too complex" error message of Hugs mean? > > Laaser Christian writes: > > > I installed the new Feb 2001 distribution and I saw that NUM_FIXUPS > > with value 1000 is only possible for large version of hugs interpreter. > > It would be great if I could get this version because the standard > > interpreter > > only has a NUM_FIXUPS of 400 and so I get the error message > > "Compiled code too complex". > > Almost every machine in existence uses the large version so I'm a bit surprised > by this report. Can you confirm: > > a) That your machine _does not_ use the large version. > (Look at the values of SMALL_HUGS, REGULAR_HUGS and LARGE_HUGS in > hugs98/src/options.h) > > b) That changing NUM_FIXUPS to 1000 fixes your problem. > > If you are indeed using the regular version, is there any reason why you can't > use the large version? > > -- > Alastair Reid

1 0

RE: please confirm that this is a feature
by Simon Peyton-Jones 28 Feb '01

28 Feb '01

GHC infers the type g :: (Foo [[a]] [b], Foo [[b]] [a]) => [a] -> [b] -> Int As you imply, if GHC used the instance decl to simplify the first constraint to Foo [a] b, for example, then the functional dependency would kick in, and there would be an infinite loop. But GHC's constraint simplification is (now) lazy, unless forced to be eager by supplying a type signature. I think Hugs is the same, and I think that's probably why it terminates. Interesting example! Simon | -----Original Message----- | From: Dominic Duggan [mailto:dduggan@cs.stevens-tech.edu] | Sent: 28 February 2001 16:00 | To: hugs-bugs(a)haskell.org | Subject: please confirm that this is a feature | | | I am finishing up revisions on a paper that | has been accepted to JFP, on type-checking | with multi-parameter type classes. | With the following definitions: | | | class Foo a b | a -> b where foo :: a -> b -> Int | | | | instance Foo Int Float where foo x y = 0 | | | | instance Foo a b => Foo [a] [b] where foo [x] [y] = foo x y | | | | g x y = (foo [x] y) + (foo [y] x) | | In our system type-checking fails to terminate when | type-checking "g", but Hugs 98 (Feb 2001) returns | a type. | | I assume that this is because of a depth bound in the | type-checker, can you confirm this before I submit | the final version of the paper? | | Thanks | --dd |

1 0

please confirm that this is a feature
by Dominic Duggan 28 Feb '01

28 Feb '01

I am finishing up revisions on a paper that has been accepted to JFP, on type-checking with multi-parameter type classes. With the following definitions: | class Foo a b | a -> b where foo :: a -> b -> Int | | instance Foo Int Float where foo x y = 0 | | instance Foo a b => Foo [a] [b] where foo [x] [y] = foo x y | | g x y = (foo [x] y) + (foo [y] x) In our system type-checking fails to terminate when type-checking "g", but Hugs 98 (Feb 2001) returns a type. I assume that this is because of a depth bound in the type-checker, can you confirm this before I submit the final version of the paper? Thanks --dd

1 0