- Hugs-Bugs - Haskell.org

A fundep bug (?)
by anatoli 12 Apr '01

12 Apr '01

This slightly bizarre (meta)code has to do with the recent Dimension thingy, discussed on haskell mailing list. > data Z = Z > data S a = S a > z = Z > sz = S Z > ssz = S (S Z) > class Add a b c | a b -> c where add :: a -> b -> c > instance Add Z a a > instance Add a b c => Add (S a) b (S c) > class Mul a b c | a b -> c where mul :: a -> b -> c > instance Mul Z a Z > instance (Mul a b c, Add b c d) => Mul (S a) b d > data Q a b = Q a b Problem here. This is the addition of rational numbers: (a/b) + (c/d) = (ad+bc)/bd > instance (Mul a d ad, > Mul b c bc, > Mul b d bd, > Add ad bc ad_bc) => Add (Q a b) (Q c d) (Q ad_bc bd) The problem is, Hugs does not infer a predicate-free type for say "add (Q sz sz) (Q sz sz)". I think it's a Hugs bug. I tried both CVS and last stable versions. When I turn "Explain instance resolution" on, the last thing I get is: entail: () ||- Add (S Z) (S Z) a No instance found for Add (S Z) (S Z) a which is strange because the last parameter of Add functionally depends on the rest. -- anatoli (at, not speaking for) ptc (dot) com __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/

2 1

Profiling with classes
by Josef Svenningsson 10 Apr '01

10 Apr '01

Hi! There seems to be some problems with the profiling in hugs. The problem shows up when using classes with methods which has no default definitions. After evaluating an expression (which causes a class method without default definition to be called) I get the following error message: hp2ps: profile.hp, line 24: integer must follow identifier In profile.hp line 24 says: Undefined member: defined member: 1 As far as I can see this is comes from a class method with no default definition. Note that the process of generating the profile.hp file is ok (so maybe this is a bug in hp2ps?). /Josef

1 0

Re: Fran and HGL broken with Feb 2001 Hugs
by C.Reinke 02 Apr '01

02 Apr '01

Alastair wrote: > As you and others have found, my HGL and Conal's Fran both depend on internal > details of Hugs which were changed in the latest release. Dear all (and especially Hugs maintainers), it is not too nice if libraries have to depend on internal details of the Hugs distribution, but I assume they wouldn't if their author's had known any way around this. And, given that several very popular libraries were affected seriously by the latest release of Hugs, may I suggest that those libraries are added to the test-suite for Hugs? It is just too risky to hope that all library authors will test their (in some cases several years old) libraries whenever any of the Haskell implementations gets updated, so this would better be automated (as, I believe, it is for GHC). It cannot be the task of the Hugs maintainers to fix the libraries in the test suite if they break due to a change to Hugs internals (*), but neither should a new release of Hugs come out with all those widely used libraries broken. In other words, new releases of Hugs could be tested against the suite and any problems encountered could be fixed "behind the scenes" before the releases reach the general public. In the worst case, if no easy fixes can be found, a decision would have to be made between breaking all those popular libraries and not introducing some potentially useful new features. In case anyone wonders: here in Canterbury, as soon as the first of us found only one of those libraries broken, a warning went round not to use the new Hugs for the time being, and that early adopter had to try and restore his old Hugs environment..(**) No-one here is using the new release! And I know of other fp places following the same cautious approach, waiting for the situation to stabilize instead of risking their research and teaching (!!!) environments. Just some thoughts of a Hugs+libraries fan, Claus (*) Btw, what was the rationale for that change? Was it really necessary? (**) no, it wasn't me, but I agree. I needed to have a look at the new built-in Observe stuff, and I had been hoping for the new FFI stuff, but not at the risk of so seriously upsetting my Hugs enviroment, so I only downloaded the source release and kept my old Hugs installation.

3 2

Fran broken with Feb 2001 Hugs
by Conal Elliott 02 Apr '01

02 Apr '01

Hi Sean. Some bad news. The Feb'01 Hugs release has a representation change for IO, breaking Fran's Compatibility.safeTry, which I had copied from Alastair Reid's graphics library. I noticed that the graphics library is broken for the same reason. I worked around that problem, but then I get "Program error: no more threads (deadlock?)" on even the most trivial Fran example. That kind of error is usually very hard to track down. Hugs-bugsers: any guesses about the thread deadlock problem? Also, as a possible temp solution for Sean, is the previous version of Hugs still available somewhere? Thanks, - Conal

3 2

Re: Windows registry handling / hugs CVS repository?
by Sigbjorn Finne 02 Apr '01

02 Apr '01

Antony Courtney antony(a)apocalypse.org writes: > > I think that the way hugs uses the registry under Windows is > dangerous and buggy. This message describes the problems > and proposes some alternative designs. I welcome comments > and suggestions. > ... points deleted.... > Hi, I'm mostly in agreement with what you're saying & it's a good thing you bring it up. However, I think that the use of the Registry for storing options is a Good Thing, and shouldn't be scrapped just because the current interface has a flaw (or two.) It's a good thing because: - the current interface provides a simple way for users to configure their setup. I'd claim that twiddling with environment variables isn't as straightforward for many Windows platform users (which in some cases means editing autoexec.bat and restarting.) - it simplifies the work of installation software; not just an installer for Hugs itself, but libraries that are distributed separately (via the Projects subkey.) - it lets you configure machine-wide Hugs settings, something that's fiddly to do using environment variables (.bat or shell scripts that wrap the hugs executable; tedious.) Setting the machine-wide Hugs settings could be easier though (at the moment, you'll have to use a Registry editor.) - it avoids running into notorious problems with not big enough environment blocks on various Win9x systems, should the length of an environment variable like HUGSFLAGS become too long. So, the question is more what is an appropriate and safer way of configuring the Hugs registry settings. Alastair implemented the current behaviour, and has identified before the very weakness you bring up. My suggestion would be the following: - if there's a HUGSFLAGS environment variable, use it & ignore the registry. Keeps people that prefer & are accustomed to env. vars happy. - :set doesn't persist to the registry. - provide an option like :regsave for persisting to the Registry. A nop if you're using environment variables. :set emits an informational message telling the user that :regsave is now needed to achieve persistence. - provide a UI for changing the options. WinHugs does this well (via the Options dialog); HaskellScript also via one of its samples, and you could easily imagine an applet that came with the Hugs distribution which did the same thing (I wrote a Hugs98 control panel applet which did just this sometime ago, and I could locate the code if there's interest in providing something like this.) The UI could also let you modify the environment variable, at least on Win2k and NT systems. i.e., not too far from what you're suggesting. BTW, re: buffers - the Registry API (RegQuery*) lets you query the size of a string value (REG_SZ), so there's really no need to guess string lengths, they can be precisely determined. --sigbjorn

1 0

Windows registry handling / hugs CVS repository?
by Antony Courtney 02 Apr '01

02 Apr '01

Hi, I think that the way hugs uses the registry under Windows is dangerous and buggy. This message describes the problems and proposes some alternative designs. I welcome comments and suggestions. "dangerous": In the current design, any options changes made interactively using ":set" from the hugs prompt are ALWAYS saved immediately to the registry. This is all well and good when the user actually made an intended change, but it is an brutally unforgiving of mistakes. Consider the common scenario of someone attempting to add a component to the search path using something like: Prelude> :set -Pc:\my\lib\path Ooops! The user forgot to include a ';' in the search path to append or prepend this path to the existing search path. Thanks to the automatic save-to-registry "feature", there is no way to undo this change. Even if the user quits and restarts hugs, the search path will only contain this one component. The original hugs default search path, as well as any changes made to the search path since hugs was installed on the system, are now GONE FOREVER! In fact, the only way I know of to recover the default search path is to re-install hugs from scratch. "buggy": During a desperate last minute demo preparation recently (for Paul Hudak's class), I had to append a few things to my search path using something like: Prelude> :set -P;c:\some\big\long\hairy\path At some point, I crossed some small magic size limit, and *poof!*: next time I started hugs, all of my path changes since hugs had been installed silently disappeared, and the path reverted to the system default path! If you want to see this bug yourself, simply run the above command a bunch of times (maybe 6 to 10), restart hugs, and do a ":set" to see the bogus value for path. I did a little digging around in the code (from Feb2001 release of hugs), and found the following First, in hugs.c, the implementation of optionsToStr() looks like this: static String local optionsToStr() { static char buffer[2000]; (...bunch of code to add things to buffer, with no buffer overrun checks...) return buffer; } Then, in machdep.c, we have: static Sting local readRegString(...) ... { #if HUGS_FOR_WINDOWS static char buf[2048]; #else static char buf[300]; #endif if (queryValue(...buf, sizeof(buf)) == REG_SZ) { /* success */ return buf; } else { return def; /* system default option settings */ } } Here is my short list of bugs in the above code: 1. Fixed size buffers are a dangerous practice. If you must use them, at least make sure they are large enough to hold the largest conceivable value and then some. In this case, 2048 bytes is a reasonable size; 300 is not. It turns out that the HUGS_FOR_WINDOWS preprocessor symbol is only defined when building the rarely used Windows GUI for hugs, not the ordinary Windows version. I *STRONGLY RECOMMEND* just getting rid of the #if..#endif, and using the larger buffer size. I'm fairly certain this is the cause of the bug I noted above. 2. It's unfortunate that the code in the first function doesn't check for buffer overruns, but at least a 2000 byte buffer is (somewhat) reasonable. 3. Both of these functions return a pointer to automatic (i.e. stack allocated) variables. This is a classic dangling pointer bug, and the behavior of such a program is undefined according to the ANSI C standard. (IF you happen not to have any function calls between where the pointer is returned and where the pointer is used in the calling code, and IF your compiler happens to implement automatic variables using a stack, then you might "get lucky" and your program might behave as intended, but there is no guarantee this will work.) A simple solution is to allocate the buffer in the caller's stack frame and pass a pointer to the callee. ----- My radical alternative design proposal: - Do NOT automatically save settings to the Windows registry. I hope the "dangerous" paragraph above is enough to convince anyone that this is just a bad idea. - As a convenience, after reading HUGSFLAGS from the environment, also read an environment variable HUGSPATH. Allow empty path components to be used to specify the current path (to prepend / append), as we do now. If absolutely necessary, we could provide a ":regsave" command to allow the user to explicitly save changes made to hugs options to the registry. Personally, I don't think this is necessary, but I'd be happy to hear others' opinions. I welcome comments / discussion on this proposal. Using environment variables for such settings is cross-platform, well understood, reasonably standard, and avoids the dangers of this automatic save-to-registry. I volunteer to implement the above changes, if someone would be so kind as to point me towards the hugs CVS repository. -antony -- Antony Courtney Grad. Student, Dept. of Computer Science, Yale University antony(a)apocalypse.org http://www.apocalypse.org/pub/u/antony

2 1

help
by m_rodriges 01 Apr '01

01 Apr '01

please, read the file new.lhs _________________________________________________________________ UOLMAIL - Todo Argentino tiene derecho a tener su e-mail. http://www.uolmail.com.ar

1 0

BUGGGGGGGGGGGGGGGGGGGGGGGGGG
by Muhammad Bilal 30 Mar '01

30 Mar '01

HI I HAVE FOUND A NEW BUG IN THE HASKELL THAT IS WE HAVE HEARED THAT THE APPENDER IS OF TWO EQUAL ORDER LIST I-e [[2,3]] ++ [[2,3]] [[2,3]] ++ [[]] BUT NOW ACCORDING TO OUR ASSIGNMENT WE HAVE TO MADE THE CARTESIAN PRODUCT AND I FIND THAT IT IS ALSO WORKING IN APPENDING. from my point of view IT IS A BUG IN HASKELL ACCORDING TO MY LIMITED INFORMATION. PLZ SOLVE THIS [] ++ [[1,2]] [[2,3]] ++ [] BUT WHEN WE PUT THE FULL LIST INSTEAD OF EMPTY THEN IT GIVES THE ERROR BUT IT SHOULD BE POSSIBLE TO GIVE ERROR IN EMPTY LIST. SALAM MUHAMMED BILAL bilalnz(a)yahoo.com

1 0

Re: Parsing error
by Sigbjorn Finne 29 Mar '01

29 Mar '01

Ralf Hinze ralf(a)cs.uu.nl writes: > > the version of hugs in the repository stumbles over the following > program (which the february 2001 version compiles without problems): > .... > > instance Num Dir where > > a + b = toEnum (fromEnum a + fromEnum b) > > a - b = toEnum (fromEnum a - fromEnum b) > > > Parsing > ERROR error.lhs:6 - Syntax error in declaration (unexpected `-') Sorry, my fault - the use of infix (-) was wrongly disallowed as part of the patch which permitted the use of qualified method names in instance decls. My proposed fix is to add the following rule to parser.y qvarop_mipl : QVAROP {$$ = $1;} | '-' {$$ = gc1(varMinus);} | '`' QVARID '`' {$$ = gc3($2);} | varop_mi {$$ = $1;} ; and change the last alternative for the rule 'qfunlhs0' from | var qvarop_mi pat0 {$$ = gc3(ap2($2,$1,$3));} to | var qvarop_mipl pat0 {$$ = gc3(ap2($2,$1,$3));} Many thanks for reporting this, you can get the above code to work if you parenthesise the operator (which is what the Hugs Prelude consistently does, which is why this didn't show up before now.) --sigbjorn

1 0

Parsing error
by Ralf Hinze 29 Mar '01

29 Mar '01

Dear Hugs maintainers, the version of hugs in the repository stumbles over the following program (which the february 2001 version compiles without problems): > data Dir = C | N | NE | E | SE | S | SW | W | NW > deriving (Eq, Read, Show, Enum, Ord) > instance Num Dir where > a + b = toEnum (fromEnum a + fromEnum b) > a - b = toEnum (fromEnum a - fromEnum b) Parsing ERROR error.lhs:6 - Syntax error in declaration (unexpected `-') Just to let you know ... Cheers, Ralf

1 0