- Hugs-Bugs - Haskell.org

A pair of editor related changes
by Sigbjorn Finne 05 Feb '01

05 Feb '01

Hi, great to see that Hugs98 isn't withering, but that new releases keep coming out. Attached are some diffs that might be of interest - they fix the following: * when invoking the editor, cope with filenames containing spaces (and other icky characters) by escaping them in double-quotes. * don't hardwire the location of notepad.exe as the default editor (and make notepad.exe the default editor on Win32 platforms, not just with Hugs for Windows.) The changes have only been tested on Win2k using MSVC; the diffs are wrt the Jan 2001 sources. --sigbjorn

1 0

(no subject)
by Rob MacAulay 05 Feb '01

05 Feb '01

Hugs January 2001 Beta release, WinHugs, Win2000 service pack 1 Haskell98 mode. 1. Does not appear to auto-load modules. For example, trying to open Calendar.hs in the demo directory (using the Open dialogue) produces the message: ERROR C:\tools\programming\esoteric\hugs98\demos\Calendar.hs - Module "System" n ot previously loaded 2. Trying to load a file from the command line :l demos\calendar crashes the program. Note that WinHugs was invoked by double clicking on the executable file in explorer, rather than via an icon. The Feb 2000 release works OK. Regards, Rob MacAulay

2 1

Unrelated question
by mpringle＠sfu.ca 04 Feb '01

04 Feb '01

Does anybody know of a maillist for ML? Sorry to post the message to this list. I'd rather be using Haskell myself. cheers, Micha

1 0

hugs bug?
by Philippe Faes 03 Feb '01

03 Feb '01

Hugs (version februari 2000) keeps reporting unexpected ';' or unexpected '}' in files that don't even contain those characters. I know very little about Haskell (I just started to try and study the language) so my haskell files will probably not be correct. Still with this kind of messages I have no clue of what to change in my programs. I don't know if this is a bug, or something I'm doing wrong. I'm using a Linux2.2 operating system on an i386 processor. I attached a haskell source file (which is probably not even good haskell syntax), and the unexpected error message reported by hugs. The latter file was created typing: hugs tree.hs > hugserror.txt Thank you, Philippe Faes mailto:Philippe.Faes@rug.ac.be __ __ __ __ ____ ___ _________________________________________ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-1999 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Report bugs to: hugs-bugs(a)haskell.org || || Version: February 2000 _________________________________________ Haskell 98 mode: Restart with command line option -98 to enable extensions Reading file "/usr/local/share/hugs/lib/Prelude.hs": Parsing Dependency analysis Type checking Compiling Reading file "tree.hs": Parsing ERROR "tree.hs" (line 16): Syntax error in data type definition (unexpected `;', possibly due to bad layout) Prelude> [Leaving Hugs] -- haskell -- poging tot implementeren van trees en optimal search tree -- *** tree.hs *** -- cf cursus G&S p430 -- nieuwe types type Weight = Float type Cost = Float type Failweight = Weight type Token = Char -- datastucturen data Tree = Failnode Weight | Branch Token Tree Tree data Lijst = [Lijstelem] data Lijstelem = Le Weight Failweight -- functies q :: Int -> Lijst -> Weight q 0 (Lelm _ fw):ls = fw q i l:ls | i>0 = q i-1 ls | i<0 = error "fout in q" p :: Int -> Lijst -> Weight c :: Int -> Int -> Lijst -> Weight c i i _ = 0 c i j l = (w i j l) + zoekmin w :: Int -> Int -> Lijst -> Weight w 0 0 [] = error "fout in lijstbewerking in tree.hs" w i i l = q i w i j l = (w i j-1 l) + (q j) +(p j) -- er wordt niet gecontroleerd of i>j; dat zou een fout moeten opleveren zoekmin :: Int -> Int -> Lijst -> Weight zoekmin i j l = (c i (zoekroot-1 l) l) + (c (zoekroot l) j l) zookroot :: Int -> Int -> Lijst -> Int --moet nog geimplementeerd worden optboom :: Int -> Int -> Lijst -> Tree optboom i i l = Failnode (q i) optboom i j l = Branch (optboom i zoekroot) (zoekroot) (optboom (zoekroot+1) j) -- deze syntax klopt niet

2 1

ANNOUNCE: Hugs 98 January 2001 beta
by Johan Nordlander 02 Feb '01

02 Feb '01

================================================================== __ __ __ __ ____ ___ || || || || || || ||__ ||___|| ||__|| ||__|| __|| ||---|| ___|| || || || || Version: January 2001 beta ================================================================== Dear all, I'm pleased to announce the availability of a new beta release of Hugs98. This is a beta release that aims at giving as many people as possible a chance to react to the changes and additions that have recently been incorporated, before the next major version is released on February 14 2001. A list of the most important new features looks as follows: - A Foreign Function Interface closely modelled after the one provided by GHC. - Built-in, Hood-like debugging support. - A new syntax for recursive monad bindings. - A new GUI under Windows that doesn't consume all CPU time. See the release notes in the "docs" directory of the distribution for more information on some of these features. Send email to hugs-users-request(a)haskell.org to join the hugs-users mailing list. Bug reports should be sent to hugs-bugs(a)haskell.org. Send email to hugs-bugs-request(a)haskell.org to subscribe to the hugs-bugs list. The home page and download site for Hugs is at http://www.haskell.org/hugs/ Enjoy, Johan Nordlander PS Please don't confuse this release with latest (January 31) release of a new version of O'Hugs, the O'Haskell interpreter!

1 0

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