- Hugs-Users - Haskell.org

one more problem with Hugs
by Bulat Ziganshin 08 Mar '06

08 Mar '06

Hello , The following code compiles with GHC but not with Hugs. moreover, if you replace STURef with STRef in instance definition, all will be fine. bug? {-# OPTIONS_GHC -cpp -fglasgow-exts #-} import Control.Monad.ST import Data.STRef -- ----------------------------------------------------------------------------- -- Unboxed references in ST monad type STURef = STRef -- | Create new unboxed reference in ST monad newSTURef :: e -> ST s (STURef s e) newSTURef = newSTRef -- ----------------------------------------------------------------------------- -- Monad-neutral interface for fast unboxed references class (Monad m) => URef m r | m->r, r->m where newURef :: a -> m (r a) instance URef (ST s) (STURef s) where newURef = newSTURef -- ----------------------------------------------------------------------------- -- Main test = runST ( do newURef (0::Int) return '1' ) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 1

the bug or not the bug? :)
by Bulat Ziganshin 03 Mar '06

03 Mar '06

Hello one more example that works in GHC but not Hugs. why i'm so unlucky? :) import Foreign.Storable import Foreign.ForeignPtr class (Monad m) => STorIO m s | m->s where mLift :: IO a -> m a newtype MBA s a = MBA (ForeignPtr a) class (Storable value) => Unboxed value where readUnboxed :: (STorIO m s) => MBA s value -> m value readUnboxed (MBA arr) = mLift $ withForeignPtr arr $ \a -> peek a -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Fwd: Re[2]: [Hugs-users] Status of Hugs? (last major release for Windows was 2003..)
by Bulat Ziganshin 01 Mar '06

01 Mar '06

it seems that this message was lost somewhere... This is a forwarded message From: Bulat.Ziganshin(a)gmail.com <Bulat.Ziganshin(a)gmail.com> To: "Neil Mitchell" <ndmitchell(a)gmail.com> Date: Monday, February 20, 2006, 1:03:13 PM Subject: [Hugs-users] Status of Hugs? (last major release for Windows was 2003..) ===8<==============Original message text=============== Hello Neil, Monday, February 20, 2006, 6:31:44 AM, you wrote: >> > http://www-users.cs.york.ac.uk/~ndm/projects/winhugs.php >> >> Yes, please try that out. When WinHugs is ready, there will be a Hugs >> release. NM> It's pretty much ready now, I'll package up some final binaries NM> tomorrow - whenever Hugs is in a ready state I'm happy to release. i still have some suggestions before the final version can be rolled. it's from docs on my Streams library: The library fully supports Hugs 2003 and Hugs 2005, but 1) support for FD and MMFile is temporarily disabled because I don't know how to build DLLs 2) Hugs 2003 doesn't include support for "instance Bits Word" and vGetBuf/vPutBuf, so you need to add these implementations manually or delete the lines that use it (look for "2003" in the sources) 3) WinHugs doesn't support preprocessing, so I included the MakeHugs.cmd script to preprocess source files using cpphs so, list of my suggestions for Hugs include: * add preprocessing symbol HUGS_VERSION to distinguish Hugs06 from previous builds and to allow distinguish future Hugs modifications * (optional) add option to disable monomorphism restriction. as far as i understand this restriction is just additional part of code and it should be easy to skip this code when requested * (optional) add hSetFileSize support. it should be easy using ftruncate() and it will increase compatibility between Hugs ans GHC * afair, at least one error i reported was not fixed immmediately. i don't read hugs-bugs but if this still unfixed, it seems strange to me to release Hugs with known errors for WinHugs such list is bigger: * ffihugs * preprocessor. i'm displeased by the requirement to ship myrriad versions of my library, one for each Hugs version+platform combination. in addition, lack of preprocessor makes my edit/test cycle more complicated and less intuitive. On the other side, adding preprocessor to WInHugs should be very easy: instead of readig the source file as is just run "cpphs.exe --noline -D__HUGS__ -D__HUGS_VERSION__=2005 -DSIZEOF_HSINT=4 -DSIZEOF_HSWORD=4" or something like this on the file and read the resulting temporary file. i do't see _any_ problem in implementing this. CPPHS is easily build by ghc/mingw, its output with "--noline" don't contain any directives and all lines is just at their right places. this will finally allow to include in Hugs distribution original (non preprocessed) sources of standard libs i also have suggestions about WinHugs that should not delay its releasing: * reduce size of installer. it can be done in many ways but at least i'm not glad to download 16 megs that can be really packed in 2 megs * use text file to store global commands history thank you for patience :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com ===8<===========End of original message text=========== -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

No text output in WinHugs
by Kevin Lindsey 26 Feb '06

26 Feb '06

Hello, I suspect this is a total newbie question, so I wanted to check here before going over to the Hugs-Bugs list. I've just installed hugs_SOE-Jan2005.msi on a WinXP machine. When I enter an expression in WinHugs like following: putStr "Hello" I get a blank line instead of the expected "Hello". I do get output from commands like ":?", etc. I assume I need to change a setting somewhere, but I haven't seen anything obvious yet. Please note that everything works fine with Hugs (command prompt version) and WinHugs in hugs98-Nov2003-2.msi works fine too. However, I'm starting to work through SOE, so, as I understand it, I need to use the Jan2005 installer. Thanks for any help with this, Kevin P.S. Are there any archives of the Haskell lists?

2 1

WinHugs error
by Paqui Lucio 26 Feb '06

26 Feb '06

Hi, > I have installed Hugs98 Nov2003 on Windows XP. > WinHugs opens with the message: > > __ __ __ __ ____ ___ > _______________________________________________ > || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard > ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2003 > ||---|| ___|| World Wide Web: http://haskell.org/hugs > || || Report bugs to: hugs-bugs(a)haskell.org > || || Version: Nov 2003 > _______________________________________________ > > Hugs mode: Restart with command line option +98 for Haskell 98 mode > > ERROR ".\Prelude.hs" - Module "Hugs.Prelude" already loaded > Hugs.Prelude> > > > > Is that normal ? > > Thanks in advance, > Paqui > > --------------------------------- > Paqui Lucio > Dpto de LSI > Facultad de Informática > Paseo Manuel de Lardizabal, 1 > 20080-San Sebastián > SPAIN > --------------------------------- > Tfn: (+34) (9)43 015049 > Fax: (+34) (9)43 015590 > --------------------------------- >

2 1

Status of Hugs? (last major release for Windows was 2003..)
by Claus Reinke 20 Feb '06

20 Feb '06

subject says it all? long gone the times when Valentine's day marked Hugs releases;-) here is the situation a windows users like me sees at the moment (I had switched to ghci, but the Haskell' effort prompts me to have two implementations of Haskell+extensions again, so I'd like to update my old Nov 2003 Hugs:-): hcar nov 2005 says "A new major release of Hugs is planned within a few months" "It should also include a Windows distribution" http://haskell.org/communities/11-2005/html/report.html#sect2.2 hugs home page says latest news last major release nov 2003 interim release mar 2005 targeted at unix systems http://www.haskell.org/hugs/ hcar also refers to winhugs, which isn't mentioned on hugs home page at all (its download page refers to an older version, stating that that one doesn't work), for a pre-release. http://www-users.cs.york.ac.uk/~ndm/projects/winhugs.php i tried minhugs from there, which claims Version: 20051031, but doesn't seem to know about the hierarchical libs. the menu entry gives a blank, and the prompt gives: Hugs> :b Data.List Unknown module Data.List cheers, claus

3 4

trivial list foldings require quadratic time?
by Härmel Nestra 14 Feb '06

14 Feb '06

Hi, Recently I noticed that evaluating minimum [1 .. 10000] in Hugs takes much more time than evaluating minimum [10000, 9999 .. 1] . This seems weird because evaluating min always needs evaluation of both its arguments, so the computation schema should be the same. I think this is a bug. Making experiments with the length varying leads to the suggestion that minimum [1 .. n] runs in quadratic time on n while minimum [n, n - 1 .. 1] runs in linear time. But it would be normal to assume minimum working in linear time in both cases. By the way, both the number of reductions and the number of cells reported by Hugs grow linearly in both cases, the corresponding numbers remain close to each other. Somehow the reductions of minimum [1 .. 10000] take much more time on an average then the reductions of minimum [10000, 9999 .. 1] . The difference is that, in the first case, comparisions are performed with the same element 1 all the time while, in the second case, the numbers being compared continuously change. I made yet more experiments. From the expressions foldl (\ x y -> if x < y then x else y) (maxBound :: Int) [1 .. 10000] foldl (\ x y -> if x < y then x else y) (maxBound :: Int) [10000, 9999 .. 1] foldr (\ x y -> if x < y then x else y) (maxBound :: Int) [1 .. 10000] foldr (\ x y -> if x < y then x else y) (maxBound :: Int) [10000, 9999 .. 1] the first and the last evaluate slowly while the others evaluate fast, although evaluation of the last needs by ~20% less reductions and cells than the third. The phenomenon occurs even when using foldl' instead of foldl . The punch-line is that if I modify the expressions as follows: foldl (\ x y -> if x < y then x + 0 else y + 0) (maxBound :: Int) [1 .. 10000] foldl (\ x y -> if x < y then x + 0 else y + 0) (maxBound :: Int) [10000, 9999 .. 1] foldr (\ x y -> if x < y then x + 0 else y + 0) (maxBound :: Int) [1 .. 10000] foldr (\ x y -> if x < y then x + 0 else y + 0) (maxBound :: Int) [10000, 9999 .. 1] then all are fast! The conditional in the operator is not essential: foldl (\ x y -> x) 0 [1 .. 10000] evaluates fast, foldl (\ x y -> ($!) const x y) 0 [1 .. 10000] evaluates slowly, foldl (\ x y -> ($!) const (x + 0) y) 0 [1 .. 10000] evaluates fast again. All this occurs with both Nov-2003 and Mar-2005 release of Hugs, on both Linux and Solaris. I have not tested in Windows. With ghci, this anomaly does not appear. Härmel

2 2

WinHugs bug: putChar (chr 255)
by Bulat Ziganshin 07 Feb '06

07 Feb '06

Hello , seems that WinHugs hates to do binary I/O :))) Main> putChar (chr 255) я Program error: <stdout>: Prelude.putChar: does not exist (file does not exist) the same problem in this program: import System.IO import Data.Char main = do h <- openBinaryFile "test" WriteMode hPutChar h (chr 255) hPutChar h 'a' -- never executed -- Best regards, Bulat mailto:bulatz@HotPOP.com

5 7

searching for documentation about FFI+Hugs
by Bulat Ziganshin 07 Feb '06

07 Feb '06

Hello please point me to the section of manual which addresses using FFI functions. The only one i found is "3.4. Compiling modules that use the Foreign Function Interface", but 1) it says about .so, not .dll files 2) it says about "ffihugs", what is not included in WinHugs distro 3) it says nothing about foreign import wrappers -- Best regards, Bulat mailto:bulatz@HotPOP.com

3 3

:t / :f inconsistencies
by Neil Mitchell 05 Feb '06

05 Feb '06

Hi, I've always been confused when looking up symbols using :t and :f, never knowing if it should have brackets or not. I have finally figured out why I am confused: Hugs> :t (^) (^) :: (Num a, Integral b) => a -> b -> a Hugs> :t ^ ERROR - Syntax error in expression (unexpected symbol "^") Hugs> :f ^ -- goes away and finds it Hugs> :f (^) ERROR - No current definition for name "(^)" Essentially, :t wants brackets, :f doesn't. I realise that in haskell ^ on its own is not a valid expression, and therefore that is a reason for :t not working on it. Perhaps a symbol on its own with no other stuff could be special cased for :t, since its certainly a valid answer to the question the user was asking. I can't see any reason for :f not dropping brackets in all cases, since :f (,) and :f () doesn't work anyway (because of the way tuples are implicit in Hugs, it seems). With these two changes, all of the above examples would work perfectly. I'm happy to have a go at hacking this up, provided its OK, and I haven't missed anything in my interpretation. Thanks Neil

2 2