January 2001 - Hugs-Bugs

OSX
by Michel Schellekens 25 Oct '02

25 Oct '02

After downloading the OSX version, and typing "hugs" to start up the language, I obtain the following error: [schellekens:~] mpcs% hugs dyld: hugs can't open library: /usr/lib/libncurses.5.dylib (No such file or directory, errno = 2) Any suggestions? Michel.

2 1

more on functional dependencies and overlapping instances
by Peter Thiemann 31 Jan '01

31 Jan '01

Hi again, as I said before, the fix was only partial. I also had to modify instImprove in subst.c, but it is clearly a hack because it assumes that more specific instances are given first, so I'm not sending it along. [I hope this is the right forum for talking about this:] I don't know about the current state of the implementation, but the following looks like a viable approach: * keep an "improved" tag with each predicate pi * in instImprove, if pi.improved then terminate immediately with result FALSE * check all instances for improvement candidates (but don't do anything, yet) * if there is exactly one candidate, go for it: improve pi, set the flag, and exit * if there is more than one candidate, find the most specific * if pi MATCHES the most specific one, go for it: ... * otherwise, no improvement possible, yet Doing this properly would require digging much deeper in the code than I can afford to right now. I'd appreciate any help (or alpha release:-) to solve this problem. And a widely related question: how exactly does the overlapping instances mechanism deal with specificity? I mean, what happens if there are two instances which are unifiable, but there is a third instance that covers the unifier? The feb2000 release definitely cannot handle this since instances are added and checked incrementally. -Peter

1 0

functional dependencies and overlapping instances
by Peter Thiemann 31 Jan '01

31 Jan '01

Hi, this reports two bugs in Hugs98-feb2000 and provides a fix for the first and a proposed fix for the second. 1. Given the definitions > class NextState s t s' | s t -> s' > instance NextState EMPTY t EMPTY > instance NextState EPSILON t EMPTY > instance NextState (ATOM t) t EPSILON > instance NextState (ATOM t) t' EMPTY hugs -98 +o complains that ERROR "REGEXP.hs" (line 76): Instances are not consistent with dependencies *** This instance : NextState (ATOM a) b EMPTY *** Conflicts with : NextState EMPTY a EMPTY *** For class : NextState a b c *** Under dependency : a b -> c Oops, the "Conflicts with" line is not right, it should rather be *** Conflicts with : NextState (ATOM a) a EPSILON The patch below corrects this. 2. But actually, since we are allowing overlapping instances and the > instance NextState (ATOM t) t EPSILON is definitely more specific than > instance NextState (ATOM t) t' EMPTY the above definitions should be perfectly ok. The patch below fixes the generation of the error message, but other fixes might be necessary, too. Cheers Peter

1 0

Re: What does "Compiled code too complex" error message of Hugs mean?
by Ch. A. Herrmann 31 Jan '01

31 Jan '01

Hi, >>>>> "Jan" == Jan Kort <kort(a)wins.uva.nl> writes: Jan> 400, you should increase it to 1000 or so. I have it at 10000, Jan> but that's probably not necesary in your case and if you Jan> increase constants too much starting up Hugs will become Jan> slower. that's a general problem with hugs that you have a lot of definitions which determine the size of arrays. I've got problems with the code and the stack size yet, so I have hugs installed with different settings which is not very convenient. Maybe hugs will become obsolete by the new fast interactive ghc, but if not I would suggest to implement as many arrays as possible dynamically and make all other settings available as a program parameter. You also could have an option which selects a permanent check of the control stack to avoid overflows where safety is more important than speed. The following piece of C code duplicates the size of an array and could be applied in the case that both the pointer to the array and its size reside in a single variable. **data is a pointer to the variable carrying the former and *size a pointer to the variable carrying the latter value. elemsize is the memory requirement of a single array element. void array_expand(void **data, int elemsize, int *size) { void *newdata; newdata = (void *)malloc(elemsize*2*(*size)); memcpy(newdata,*data,elemsize*(*size)); free(*data); *data=newdata; (*size)*=2; } Bye -- Christoph Herrmann E-mail: herrmann(a)fmi.uni-passau.de WWW: http://brahms.fmi.uni-passau.de/cl/staff/herrmann.html

1 0

hugs won't compile for me.....
by Byron Cook 29 Jan '01

29 Jan '01

i get the following error when trying to compile Hugs Feb2000: gcc -c -g -O2 builtin.c In file included from builtin.c:1432: iomonad.c: In function `primHGetPosn': iomonad.c:715: aggregate value used where an integer was expected iomonad.c: In function `primHSetPosn': iomonad.c:730: invalid initializer iomonad.c:736: incompatible types in assignment make: *** [builtin.o] Error 1 $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.0) $

2 1

.y & precedence
by Hans Aberg 28 Jan '01

28 Jan '01

Once an operator has been defined using the INFIX.. tokens in the parser.y grammar, how does that grammar handle the parsing of later occurrences of the operator symbol in order to get the precedence right? -- Does Hugs handle that internally (externally to the .y grammar)? Hans Aberg

3 3

RE: Yet more on functional dependencies
by Simon Peyton-Jones 26 Jan '01

26 Jan '01

| | I am finding functional dependencies confusing. (I suspect I am | | not alone.) Should the following code work? | | | | class HasConverter a b | a -> b where | | convert :: a -> b | | | | instance (HasConverter a b,Show b) => Show a where | | show value = show (convert value) | | It's a separate issue. There's no reason why a system using | functional dependencies *should* support this. But it is an | attractive and useful extension that such a system would | probably *want* to include. (i.e., it's a desirable feature, | not a requirement.) There are two things going on here a) The 'head' of the instance declaration is just "Show a", so this purports to give an instance declaration for all types "a". So it overlaps with other instance declarations, and GHC currently rejects it for that reason. (Arguably, if you accept overlapping instance declarations, then this should be acceptable too.) b) There's a "b" in the instance declaration context that doesn't appear in the head. This is quite OK, because the functional dependency ensures that "a" uniquely determines "b". So here's a variant that works in the (as-yet-unreleased) GHC 5.0: data Foo a = MkFoo a instance (HasConverter a b,Show b) => Show (Foo a) where show (MkFoo value) = show (convert value) [Incidentally, functional dependencies don't work at all in GHC 4.08; don't even try.] Simon

1 0

RE: bug in dupChan
by Simon Peyton-Jones 26 Jan '01

26 Jan '01

Shouldn't this instead be dupChan :: Chan a -> IO (Chan a) dupChan (Chan _read write) = do new_read <- newEmptyMVar hole <- readMVar write putMVar new_read hole ** putMVar write hole ** return (Chan new_read write) No: readMVar is defined to be take-followed-by-put. I think you mis-read the "readMVar write" as "takeMVar write". Nevertheless, there is a bug in dupChan, but it's in the code for readChan, where "takeMVar read_end" should be "readMVar read_end". As you'll have seen if you are on the Haskell mailing list. Shame on me! Simon

1 0

bug in dupChan
by Meurig Sage 24 Jan '01

24 Jan '01

Hi I think that there's a bug in dupChan in Chan.lhs I tried the following program. main = do chan <- newChan ch <- dupChan chan writeChan chan "done" x <- readChan chan y <- readChan ch prnt ("Got "++x ++" "++y) Now if I remember correctly this should print "Got done done". Instead it exits with C:\Test\test.exe: no threads to run: infinite loop or deadlock? I looked for the code for dupChan in hslibs and it says dupChan :: Chan a -> IO (Chan a) dupChan (Chan _read write) = do new_read <- newEmptyMVar hole <- readMVar write putMVar new_read hole return (Chan new_read write) Shouldn't this instead be dupChan :: Chan a -> IO (Chan a) dupChan (Chan _read write) = do new_read <- newEmptyMVar hole <- readMVar write putMVar new_read hole ** putMVar write hole ** return (Chan new_read write) That's at least what the Concurrent haskell paper says. Hugs 98 seems to have the same bug with its library. Meurig

1 0

Infinite loop in an error message
by Dimitur Krustev 22 Jan '01

22 Jan '01

The following script causes an infinite loop when printing the error message provoked by the evaluation of main. Tested with Hugs98 February 2000, both in +98 and -98 mode. >type E s = [T s] >data T s = S s | SE (E s) deriving (Show, Eq) >p (S s1) (S s2) | s1==s2 = True >p t1 (SE e2) = all (q t1) e2 >-- p _ _ = error "error in p" >q t1 t2 = if p t1 t2 then True else p t2 t1 >f (x:xs) (y:ys) | p x y = 1 >f _ _ = 2 >main = f [S "a"] [SE [S "b"]] Main> main Program error: {p (Make.Eq (instEq_v23_v1175 instEq_v14) (Eq_default_== (Make.Eq (instEq_v23_v1175 instEq_v14) (Eq_default_== (Make.Eq (instEq_v23_v1175 instEq_ v14) (Eq_default_== (Make.Eq (instEq_v23_v1175 instEq_v14) (Eq_default_== (Make. ...{Interrupted!} Uncommenting the last line in the definition of p fixes the problem, of course. (Although the script is quite contrived, it has been derived from a larger and more realistic program.) Best regards, Dimitur _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

1 0