February 2003 - Glasgow-haskell-users

RE: Question about compiling CGIs with Ghc
by Simon Marlow 17 Feb '03

17 Feb '03

> 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? Depends on lots of things really. The CGI library that comes with GHC is documented here: http://www.haskell.org/ghc/docs/latest/html/network/Network.CGI.html Cheers, Simon

2 1

RE: awaitEval in Concurrent Haskell
by Simon Peyton-Jones 17 Feb '03

17 Feb '03

Does this mean you can womble along with Claus's suggestion? I'm feeling a bit swamped at the moment, and not keen to undertake another open-ended implementation exercise. So if you can manage without, and perhaps use the experience to refine the specification of a Really Useful Feature, that'd be great from my point of view. Simon | -----Original Message----- | From: Colin Runciman [mailto:colin@cs.york.ac.uk] | Sent: 17 February 2003 13:40 | To: Claus Reinke | Cc: Colin Runciman; C.Reinke; Simon Peyton-Jones; GHC users | Subject: Re: awaitEval in Concurrent Haskell | | A couple of hours ago, I wrote (in reponse to Claus Reinke's suggestion): | | > Thanks for this further suggestion. A solution along these lines | > might be | > possible, but it would still be restricted ... | | Actually a mild variant of Claus's proposal seems to work out | quite well. Another way to avoid the problems with types is | to use a multi-parameter type class. Little example attached. | | So, thanks again Claus! | | Regards | Colin R

2 1

Re: awaitEval in Concurrent Haskell
by C.Reinke 17 Feb '03

17 Feb '03

> Colin [ccing GHC users in case there are other enthusiasts out there] > > | we briefly discussed the lack in > | Concurrent Haskell of any way to set up a data-driven > | thread -- one that works on a data structure D without > | ever forcing its evaluation, only proceeding with the > | computation over D as and when the needed parts get > | evaluated by some other thread. I'm not sure whether I understand what you have in mind later on, but this first part sounds so remarkably like something I've seen before, that I'll take my chances. Do you remember Andy Gill's Hood from long ago? Inside its implementation, it had a very similar problem: writing information about an observed structure to some observation trace, but without forcing premature evaluation of the structure under observation. The trick used in Observe.lhs is roughly this (here for (,)): observe label (a,b) = unsafePerformIO $ do sendObservation label "(,)" return (observe label a,observe label b) with some position information and strictness mangling added, and the whole nicely wrapped into a monad (see Observe.lhs for details). Nothing happens as long as the thing under observation is not inspected by its context. Then, and precisely then, the unsafePerformIO kicks in to record a piece of information and to return the outer part of the thing, wrapping its components into fresh observers. Andy used this to store observations in a list, to be processed at the end of the program run, but you can just as well send the observations during evaluation, e.g., to a concurrent thread (with the usual caveats). In particular, the sequencing of information becoming available was detailed enough to inspire my own GHood;-) With no implementation slot free, something like this might get your student's project unstuck (e.g., replace sendObservation by assert)? After all, my favourite justification for unsafePerformIO is as an extension hook in the runtime system.. Sorry if your intention was something else and I'm just trying to fit a solution to the problem. Even then, you might be able to adapt the trick to your application. Cheers, Claus

3 4

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