- Glasgow-haskell-users

Question about compiling CGIs with Ghc
by ALFONSO MELENDEZ 14 Feb '03

14 Feb '03

Hello: I have some CGI programs running with Hugs and I want to use GHC instead. What changes must I do to the .hs file? Is it an easy job? Thank you very much

1 0

RE: MArray and runST
by Simon Peyton-Jones 14 Feb '03

14 Feb '03

| > Now, the error message you get is deeply obscure, I grant you. Trouble | > is, this variant IS ok: | > | > foo = id wibble | > | > wibble :: ((forall s. ST s b) -> b) -> b | > | > Why? For the same reason that this is OK | > | > foo = id reverse | > | > That, is we can instantiate the type of the argument to a monotype (a | > type without for-alls). | | Sorry, I don't understand yet. Why isn't the "forall s" in wibble's type a | problem? I'll explain by showing the translation. Here it is for the reverse example. Notice that we instantiate reverse before passing it to 'id'. I'm using curly braces for type application. foo = /\a. id {a} (reverse {a}) Now here's the more complicated version for 'wibble' foo = /\s b. id {(ST s b -> Int) -> Int} (\x::(ST s b - >Int). wibble {b} (/\f::(forall s1. ST s1 b). (x (f {s})))) Simon

1 0

RE: MArray and runST
by Simon Peyton-Jones 14 Feb '03

14 Feb '03

Interesting example! | Coincidentally, I tripped over this subtlety myself just last night. (I, | too, often use '$' to avoid nested parentheses.) I concluded it was an | instance of the "partial-application restriction" that I found described in | section 7.11.4 of the GHC 5.02 User's Guide (still accessible at the GHC web | site if you look carefully enough). No, that's not the reason. That restriction has been lifted. Consider this simpler program; foo = id runST Now we have id :: forall a. a -> a So to apply 'id' to 'runST' we'd have to instantiate the type variable 'a' to runST's type 'forall b. (forall s. ST s b) -> b' But GHC only implements predicative polymorphism; it does not allow you to instantiate a type variable with a for-all type. It would be nice to lift this restriction, but I don't know how do to so without losing type inference. Now, the error message you get is deeply obscure, I grant you. Trouble is, this variant IS ok: foo = id wibble wibble :: ((forall s. ST s b) -> b) -> b Why? For the same reason that this is OK foo = id reverse That, is we can instantiate the type of the argument to a monotype (a type without for-alls). So it's not easy to see how to spot the bad case and give a better message. If this comes up again I'll think about it again. Meanwhile, I'm going to put it under "higher-rank polymorphism gives strange error message" file. Simon | -----Original Message----- | From: Dean Herington [mailto:heringto@cs.unc.edu] | Sent: 13 February 2003 14:54 | To: Keean Schupke | Cc: Simon Marlow; glasgow-haskell-users | Subject: Re: MArray and runST | | Keean Schupke wrote: | | > Ahh, I see, perhaps you could give me a clue as to why (or how) this | > works... | > I have probably become a little over keen on using '$' as a general | > replacement for | > braces '(' ')' - the '$' was there because the actual wrapper function | > takes arguments and | > it looks neater not to have too many nested braces. I thought this could | > be something to do | > with runST enforcing strictness, but '$!' causes the same problem, only | > runST (wrapper x y z) | > appears to work - if its not too much trouble, how does runSTs type | > enforce this, and why does | > using '$' and '$!' cause type leakage? | | Coincidentally, I tripped over this subtlety myself just last night. (I, | too, often use '$' to avoid nested parentheses.) I concluded it was an | instance of the "partial-application restriction" that I found described in | section 7.11.4 of the GHC 5.02 User's Guide (still accessible at the GHC web | site if you look carefully enough). | | [Simon: With a few minutes scanning, I couldn't find the same text in the | current online User's Guide. Can you point out where it is?] | | -- Dean | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

RE: Yet another weakly defined bug report
by Simon Marlow 14 Feb '03

14 Feb '03

> What is the limit on open files, and why? I think it'd be nice to > just schedule a huge amount of IO operations, and have them all be > performed when required (i.e. when the FM is first accessed). > Apparently, my addDir took the trouble to open the files, but not > generate the FMs -- any idea why? The limit is imposed by the OS, and is usally tunable. Try 'ulimit -a' on a Unix box (the command might be different depending on your shell; check the manpage). readFile must *open* the file strictly, because it has to raise an exception if any errors occur. But thereafter, all reading is done lazilly. If you also want the open to be lazy, then use unsafePerformIO. It's Your Funeral, as we say in GHC land ;-) Cheers, Simon

1 0

RE: GHCi-5.04.2: Windows Open with ... problem.
by Simon Peyton-Jones 14 Feb '03

14 Feb '03

We'll merge the fix into the 5.04 branch. We're planning another 5.04 release (5.04.4), which has numerous small fixes, sometime "soon", but exactly when depends on demand. When would you need it for your course? Simon -----Original Message----- From: Calle Lejdfors [mailto:calle.lejdfors@cs.lth.se] Sent: 13 February 2003 10:56 To: glasgow-haskell-users(a)haskell.org Subject: Re: GHCi-5.04.2: Windows Open with ... problem. Hi. Ok. When can we expect a patch? Will it be incorporated into the next stable release? The reason for asking is that we're migrating from Hugs to using GHC(i) in our basic Functional Programming course. And since all our lab machines are Windows based it is imperative that this works correctly. Thanks, Calle ----- Original Message ----- From: Sigbjorn Finne <mailto:sof@galois.com> To: Calle <mailto:calle.lejdfors@cs.lth.se> Lejdfors Cc: glasgow-haskell-users(a)haskell.org Sent: Wednesday, February 12, 2003 3:54 PM Subject: Re: GHCi-5.04.2: Windows Open with ... problem. Allright, thanks - this a bug in the GHCi UI frontend. When given a filename via a :load command or the cmd-line it processes the filename(s) using Prelude.words, which isn't the right thing to do. --sigbjorn ----- Original Message ----- From: Calle <mailto:calle.lejdfors@cs.lth.se> Lejdfors To: glasgow-haskell-users(a)haskell.org Sent: Wednesday, February 12, 2003 05:33 Subject: Re: GHCi-5.04.2: Windows Open with ... problem. Hi Thanks for the answer. It appears as if XP calls ghci via "p::\ath\to\ghci" "c:\Documents and Settings\foo\...." i.e. with quotes. Trying to start ghci via cygwin using any of $ ghci Test\ with\ spaces/Test.lhs $ ghci Test\ with\ spaces\\Test.lhs $ ghci "Test with space/Test.lhs" $ ghci "Test with space\\Test.lhs" will give the error: can't find module `Test' (while processing "Test") Testing $ ghci Test\ with\ spaces/Test.lhs $ ghci "Test with space/Test.lhs" under Linux gives the same error. Hence there seem to be something strange about pathnames containing spaces under GHCi. However trying the same thing under GHC works like a charm under both cygwin and Linux. Any ideas? /Calle ----- Original Message ----- From: Sigbjorn Finne <mailto:sof@galois.com> To: Calle <mailto:calle.lejdfors@cs.lth.se> Lejdfors Cc: glasgow-haskell-users(a)haskell.org Sent: Tuesday, February 11, 2003 3:19 PM Subject: Re: GHCi-5.04.2: Windows Open with ... problem. Hi thee, this is most likely due to the XP shell invoking 'ghci' as follows: p:\ath\to\ghci c:\Documents and Settings\foo\.... which makes it look as if multiple arguments are given on the command-line (indeed, that's what the argv vector will contain.) The registered file assocations for .hs and .lhs takes care of quoting the filename argument, so I'm not sure this is worth fixing. --sigbjorn Enterprising souls may want to have a look at the Registry key HKEY_CLASSES_ROOT\Unknown\shell\openas\command and look at how the %1 arg is quoted (or not).... ----- Original Message ----- From: Calle <mailto:calle.lejdfors@cs.lth.se> Lejdfors To: glasgow-haskell-users(a)haskell.org Sent: Tuesday, February 11, 2003 02:02 Subject: GHCi-5.04.2: Windows Open with ... problem. Hello. I am having a problem using the Open with ... on haskell-files under WinXP. The problem is this: create a file on my desktop and then right-click and try to open it using Open with -> ghci. I get the following error message: can't find module `C:\Documents' (while processing "C:\\Documents") Obviously GHCi incorrectly handles white space in the path. If I run under Cygwin I can use a script like: c:\\ghc\\ghc-5.04.2\\bin\\ghci `cygpath -d $1`; But how do I solve this if I'm not using cygwin? Thanks, Calle

2 1

RE: Yet another weakly defined bug report
by Simon Marlow 14 Feb '03

14 Feb '03

> > These things are always tricky to understand, which is why > I recommend > > not using lazy I/O. File reading is not a pure operation: > running out > > of file descriptors is a good counter-example. > > Without saying wether I agree with lazy I/O or not, I suggest that > this particular problem may also be due to the runtime implementation: > If one tries to open a new file but the file descriptors are > exhausted, > the runtime system should first trigger a full GC because that might > free up some descriptors -- but maybe GHC is already doing this? GHC could do this, but it doesn't. Nevertheless, it wouldn't help in Ketil's example: no amount of GC is going to free up the file descriptors which are being held on to because the program hasn't completely evaluated the file contents yet. Cheers, Simon

1 0

RE: Pattern matching with implicit par. bug
by Simon Peyton-Jones 14 Feb '03

14 Feb '03

This is ok in ghc-5.04.2 onwards. Time to update your GHC Simon | -----Original Message----- | From: Jorge Adriano [mailto:jadrian@mat.uc.pt] | Sent: 13 February 2003 14:21 | To: glasgow-haskell-bugs(a)haskell.org; GHC Users Mailing List | Subject: Pattern matching with implicit par. bug | | There it goes, | J.A. | | | type CTPar = ([Double],Int,Int) | us :: (?ctPar :: CTPar) => [Double] | us = let (us',_,_) = ?ctPar in us' | | | ghc-5.04: panic! (the `impossible' happened, GHC version 5.04): | tcSplitTyConApp | {?ctPar{-r2kd-} :: ([GHCziFloat.Double{-3u-}], | GHCziBase.Int{-3J-}, | GHCziBase.Int{-3J-})} | | Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, | or http://sourceforge.net/projects/ghc/. | | | _______________________________________________ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

1 0

RE: Pattern matching, implict par. question
by Simon Peyton-Jones 14 Feb '03

14 Feb '03

Well the definition clearly falls under the monomorphism restriction as laid down by the Report, because you haven't given a signature for us,n,j. I suggest ctPar :: (?ctPar::CTPar) => CTPar ctPar = ?ctPar (us,n,j) = ctPar That should work Simon | -----Original Message----- | From: Jorge Adriano [mailto:jadrian@mat.uc.pt] | Sent: 13 February 2003 14:36 | To: Haskell Cafe; glasgow-haskell-users(a)haskell.org | Subject: Pattern matching, implict par. question | | Hello, When trying | | type CTPar = ([Double],Int,Int) | ctPar ::(?ctPar::CTPar)=>CTPar | ctPar@(us,n,j) = ?ctPar | | I got this error message in ghci is: | " Illegal overloaded type signature(s) | in a binding group for ctPar, us, n, j | that falls under the monomorphism restriction | When generalising the type(s) for ctPar, us, n, j | Failed, modules loaded: CrossTypeOps." | | Should the monomorphis restriction really apply here? | The values of us,j,n do depend on the context, but not their types (right?). | | J.A. | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: MArrayt and runST
by Simon Marlow 13 Feb '03

13 Feb '03

> However the problem comes when I try and use runST to run it... > > runMatrix :: Array (Int,Int) Int > runMatrix = runST $ wrapper > > This is becase 's' escapes > Expected: ST s a -> b > Inferred: (forall s1. ST s1 a) -> a Delete the dollar? Cheers, Simon

3 2

Pattern matching, implict par. question
by Jorge Adriano 13 Feb '03

13 Feb '03

Hello, When trying type CTPar = ([Double],Int,Int) ctPar ::(?ctPar::CTPar)=>CTPar ctPar@(us,n,j) = ?ctPar I got this error message in ghci is: " Illegal overloaded type signature(s) in a binding group for ctPar, us, n, j that falls under the monomorphism restriction When generalising the type(s) for ctPar, us, n, j Failed, modules loaded: CrossTypeOps." Should the monomorphis restriction really apply here? The values of us,j,n do depend on the context, but not their types (right?). J.A.

1 0