September 2001 - Hugs-Bugs

RE: Literate scripts not handled correctly
by Simon Marlow 18 Sep '01

18 Sep '01

> > Then I think hugs and nhc98 are wrong. The report states that the > > unliterate version of the file is recovered by "taking only > those lines > > beginning with '>', and removing the first character of > those lines", > > which would leave the lines indented by a single space, not two. > > This would appear to be an un-remarked change to the Report since > version 1.2. That version states that "program lines have the > leading '>' replaced by a leading space, to preserve tab alignments". > Version 1.3 removed this specification, and the changed specification > only appeared in Haskell'98. > > I would like to submit it as a bug in the Report - the older > specification, as implemented by Hugs and nhc98 makes more sense in > conjunction with the layout rule. I'm inclined to agree. But I'd like to know what the reason for the change in the first place was. GHC's unlit preprocessor converts the tabs to spaces in such a way that they line up after removal of the '>' characters, by the way. Cheers, Simon

1 0

RE: Literate scripts not handled correctly
by Simon Marlow 18 Sep '01

18 Sep '01

> The definitions of foo and bar are not at the same indentation level, > so they are being rejected by the layout rule. At least, hugs and > nhc98 accept it if you indent bar by two spaces, ghc still complains: > > ghc -c lit.lhs > lit.lhs:9: parse error on input `_' Then I think hugs and nhc98 are wrong. The report states that the unliterate version of the file is recovered by "taking only those lines beginning with '>', and removing the first character of those lines", which would leave the lines indented by a single space, not two. Cheers, Simon

2 1

Literate scripts not handled correctly
by Ian Lynagh 18 Sep '01

18 Sep '01

Hi all My understanding is that the following script: ----- cut here ----- > foo :: Int -> Int > foo _ = 2 \begin{code} bar :: Int -> Int bar _ = 1 \end{code} ----- cut here ----- should be valid and define foo and bar (although the report does say "It is not advisable to mix these two styles in the same file"). However, in hugs: ERROR Q.lhs:7 - Syntax error in input (unexpected symbol "bar") % ghc -c -o Q.o Q.lhs Q.lhs:7: parse error on input `bar' % nhc98 -c -o Q.o Q.lhs In file ./Q.lhs: 7:1 Found bar but expected a {-EOF-} Secondly, in the following script (which I think should define main according to the report): ----- cut here ----- \begin{code} module Main where main :: IO() main = putStrLn "Foo" \end{code} ----- cut here ----- hugs: ERROR W.lhs:12 - Empty script - perhaps you forgot the `>'s? % nhc98 -c -o W.o W.lhs Warning: Can not find main in module Main. ghc -c -o W.o W.lhs W.lhs line 11: unlit: missing \end{code} Interestingly it works in GHC if you remove the white space before the end but not before the begin. Thanks Ian

2 1

RE: Literate scripts not handled correctly
by Simon Marlow 18 Sep '01

18 Sep '01

> My understanding is that the following script: > > ----- cut here ----- > > > foo :: Int -> Int > > foo _ = 2 > > \begin{code} > > bar :: Int -> Int > bar _ = 1 > > \end{code} > > ----- cut here ----- > > should be valid and define foo and bar (although the report > does say "It > is not advisable to mix these two styles in the same file"). > > However, in hugs: > ERROR Q.lhs:7 - Syntax error in input (unexpected symbol "bar") This is probably due to layout. The unliterate version of the file would be foo :: Int -> Int foo _ = 2 bar :: Int -> Int bar _ = 1 so the occurrence of the token 'bar' at a column less than that of the first 'foo' causes a close brace to be inserted by the layout system, closing the top-level declaration group. > Secondly, in the following script (which I think should define main > according to the report): > > ----- cut here ----- > > \begin{code} > > module Main where > > main :: IO() > main = putStrLn "Foo" > > \end{code} > > ----- cut here ----- > > hugs: > ERROR W.lhs:12 - Empty script - perhaps you forgot the `>'s? > > % nhc98 -c -o W.o W.lhs > Warning: Can not find main in module Main. > > ghc -c -o W.o W.lhs > W.lhs line 11: unlit: missing \end{code} > > Interestingly it works in GHC if you remove the white space before the > end but not before the begin. Yes, it looks like GHC's unlit program removes whitespace when looking for \begin{code}, but not for \end{code}. The report isn't explicit about whether whitespace is allowed on these lines, but I would tend to the view that it isn't. Cheers, Simon

1 0

Hugs doesn't parse left sections correctly
by Ian Lynagh 17 Sep '01

17 Sep '01

The following looks like it is valid to me, and ghc and nhc98 agree: Prelude> (5 * 6 +) 7 ERROR - Syntax error in expression (unexpected `)') Thanks Ian

1 0

Stack size
by ajf 14 Sep '01

14 Sep '01

I'm using the Feb 2000 release of Hugs and am preparing student labs using the graphics library. Several nasties happen: * For very moderate problems (plot ~2K lines centred in a window of fixed size) I get a control stack overflow. To centre, the code finds pre-computes the minimum and maximum x and y ordinates of all line end-points. This is potentially a problem, but fixable in this case, you'd hope. However, the overflow happens EVEN IF the code is written tail-recursive, or using foldl. Oh dear. * If the relevant scaling factors are passed as parameters (to avoid pre-computation) I can plot quite a bit more (4997 lines on my W2000 set-up; rather more on an earlier installation under W98). But then the program aborts, presumably because of the C stack overflow problem. * On W2000 the previous problem corrupts the WHOLE screen buffer, rather like a virus. Actually this is fixable by maximising and then minimising the hugs window, but it's all very disturbing! On W98, the programs seems to die gracefully. So question: how do I increase the stack size? Also, are you aware of problems with the graphics library burning up the C stack? I cannot find anything in the hugs documentation, but have a feeling you have to recompile Hugs. Is this true? (Otherwise Hugs is completely wonderful...!) Many thanks. Tony Field Imperial College

3 3

installation
by Paul Balenzano 14 Sep '01

14 Sep '01

Can someone please explain to me in english how exactly to intsall hugs 98 v. feb 2001 on to my Windows 98 system. Much Appreciated, Paul Balenzano _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

2 1

One more thing...
by ajf 13 Sep '01

13 Sep '01

Following on from my earlier email... This may be unsurprising, but I also notice that when my program aborts and returns me to hugs, re-running the program with a smaller problem size (one that USED to work OK) sometimes also aborts. Just now the same thing happened for ALL problem sizes - right down to drwaing just half a dozen lines. When I quite Hugs and then re-start it problems the 'problem' seems to go away. In other words, I'm seeing non-deterministic behaviour! Tony Field. Imperial College

1 0

hugs segfaults
by Iavor Diatchki 13 Sep '01

13 Sep '01

hello, the following piece of code seems to crash hugs. --------------------------------------------------------------- module Main where inf = foldl (+) 0 (repeat 1) main :: IO () main = putStrLn $ show inf --------------------------------------------------------------- here is what happens: [diatchki@localhost modules]$ hugs -h4M hugsBug.hs __ __ __ __ ____ ___ _________________________________________ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2001 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Report bugs to: hugs-bugs(a)haskell.org || || Version: February 2001 _________________________________________ Haskell 98 mode: Restart with command line option -98 to enable extensions Reading file "/usr/share/hugs/lib/Prelude.hs": Reading file "hugsBug.hs": Hugs session for: /usr/share/hugs/lib/Prelude.hs hugsBug.hs Type :? for help Main> main Segmentation fault (core dumped) [diatchki@localhost modules]$ i tried it using the feb 2001 release of hugs on a linux machine (mandrake 8.0 distribution). the machine is an athlon 750 with 128Mb of RAM. bye iavor -- +---------------------------------+---------------------------------------+ |Iavor S. Diatchki | email: diatchki(a)cse.ogi.edu | |Dept. of Computer Science | web: http://www.cse.ogi.edu/~diatchki | |Oregon Graduate Institute | tel: 5037481631 | +---------------------------------+---------------------------------------+

2 1

error reporting for qualified fields
by Iavor S. Diatchki 12 Sep '01

12 Sep '01

hi i seem to have stumbled onto a bug in the error reporting part of hugs. here is an example: [diatchki@limit Modules]$ cat hugsbug2.hs data T = T bug = T { X.missing = 1 } [diatchki@limit Modules]$ hugs hugsbug2.hs __ __ __ __ ____ ___ _________________________________________ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2001 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Report bugs to: hugs-bugs(a)haskell.org || || Version: February 2001 _________________________________________ Haskell 98 mode: Restart with command line option -98 to enable extensions Reading file "/usr/share/hugs/lib/Prelude.hs": Reading file "hugsbug2.hs": Dependency analysis ERROR hugsbug2.hs:3 - "d119392" is not a selector function/field name Prelude> :q [Leaving Hugs] it seems to only happen when one uses qualified field names. if the field name is not qualified the correct error is reported. bye iavor

2 1