- Glasgow-haskell-users

RE: import Prelude ([](..))
by Simon Peyton-Jones 07 Nov '03

07 Nov '03

That's it! We fixed GHC6 to follow the Report in this respect, a change that affects very few people. Sorry it wasn't clearer. S | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Martin Sjögren | Sent: 07 November 2003 11:01 | To: glasgow-haskell-users(a)haskell.org | Subject: RE: import Prelude ([](..)) | | fre 2003-11-07 klockan 11.42 skrev Simon Peyton-Jones: | > | Well, I don't want to redefine list syntax, quite the opposite. I want | > | to use regular lists together with my stuff (and "my stuff" doesn't | > | include lists at all). So, this is not possible? (Well, it was in ghc 5, | > | but I guess that ghc 5 is wrong, then) | > | > Yes it is possible! You can't redefine list syntax -- it always means "lists". | > And it will continue to work regardless of what you import. Just omit | > import Prelude( [](..) ) | | Ah! I see. I was getting "constructor not in scope: `:'" in ghc5, but in | ghc6 it does indeed work. | | So, the bottom line here is that with ghc6 I *cannot* have the import, | but in ghc5 I *must* have it? Gah. | | Thanks for your help. | | | /Martin | -- | Martin Sjögren | sjogren(a)debian.org -- marvin(a)dum.chalmers.se | GPG key: http://www.mdstud.chalmers.se/~md9ms/gpg.html | let hello = "hello" : hello in putStr (unlines hello)

1 0

RE: import Prelude ([](..))
by Simon Peyton-Jones 07 Nov '03

07 Nov '03

| Well, I don't want to redefine list syntax, quite the opposite. I want | to use regular lists together with my stuff (and "my stuff" doesn't | include lists at all). So, this is not possible? (Well, it was in ghc 5, | but I guess that ghc 5 is wrong, then) Yes it is possible! You can't redefine list syntax -- it always means "lists". And it will continue to work regardless of what you import. Just omit import Prelude( [](..) ) Simon

2 1

RE: import Prelude ([](..))
by Simon Peyton-Jones 07 Nov '03

07 Nov '03

Lists are regarded by Haskell 98 as "syntax", so you don't import or hide them. The type [], the constructors [] and : are all not importable or hidable, any more than 'case' is. So you can define your own prelude, but you can't redefine what list syntax means. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Martin Sjögren | Sent: 07 November 2003 10:15 | To: glasgow-haskell-users(a)haskell.org | Subject: import Prelude ([](..)) | | Hello ghc users! | | In my experiments with analyzing Haskell programs, I frequently use my | own Prelude variants but want to import parts of the real Prelude for | simplicity. | | In ghc 5, I could write: | import Prelude ([](..)) | and then use lists as usual. In ghc 6, though, I get: | "parse error on input `['" | | Is there a secret way to import the list type that I don't know of? Is | ghc 5 or ghc 6 wrong? :) | | Using the "hiding" is not really an option, since I normally want just | one or two types from the Prelude and then provide other things myself. | | | Regards, | Martin | -- | Martin Sjögren | sjogren(a)debian.org -- marvin(a)dum.chalmers.se | GPG key: http://www.mdstud.chalmers.se/~md9ms/gpg.html | let hello = "hello" : hello in putStr (unlines hello)

2 1

import Prelude ([](..))
by Martin Sjögren 07 Nov '03

07 Nov '03

Hello ghc users! In my experiments with analyzing Haskell programs, I frequently use my own Prelude variants but want to import parts of the real Prelude for simplicity. In ghc 5, I could write: import Prelude ([](..)) and then use lists as usual. In ghc 6, though, I get: "parse error on input `['" Is there a secret way to import the list type that I don't know of? Is ghc 5 or ghc 6 wrong? :) Using the "hiding" is not really an option, since I normally want just one or two types from the Prelude and then provide other things myself. Regards, Martin -- Martin Sjögren sjogren(a)debian.org -- marvin(a)dum.chalmers.se GPG key: http://www.mdstud.chalmers.se/~md9ms/gpg.html let hello = "hello" : hello in putStr (unlines hello)

1 0

RE: Transmitting Haskell values
by Simon Marlow 06 Nov '03

06 Nov '03

> In all, I'm finding it rather difficult to find my way in the > documentation (just as a data point for the documentation folks). > To make the critique helpful instead of just a critique, here > are a few ideas of what might have helped me (YMMV): > > 1. My main problem was that I have no good idea of all the installed > libraries and the names defined in them (remember I'm a > complete newbie > to doing anything with a concrete Haskell installation). If somebody > tells me to look for "Show", I have to sequentially open the > indexes of > all installed packages, and since I'm a newbie, I don't even > know where > to look first. > I'd like to see a tool that gives me a unified overview of > all installed > packages. The tool should extend the "index.html" file in the > ../doc/html directory so that it includes an entry for each installed > library (probably copied from some "manifest.ihtml" file in > the package > directories), and it should create/extend the Haddockish > doc-index-*.html files to be synopses of the doc-index-*.html > files from > the installed packages. > If would be best if that tool were run automatically during package > installation :-) (particularly for newbies who are fully > occupied with > learning the language and don't have much energy or time left for > learning tools). Generating a single unified index is entirely possible, given all the .haddock files for the relevant packages. I'll try to get this into the next version of Haddock. As for the rest, this is all stuff that could/should be done by the library infrastructure (which is currently in in the design stage). > 2. Remove the split between "type/class index" and > "function/constructor > index" in the Haddockish doc-index.html file. Yes, this is also something I'd like to do. > 3. Some links in the indexes are bold, others aren't. The bold ones represent the *original* defining module for the entity, as compared to a module which just re-exports it. However, knowing this information isn't very useful, and arguably it shouldn't be displayed to the user at all. I'll change this for the next Haddock version. Cheers, Simon

3 4

[ ghc-Feature Requests-837563 ] GHCi (Mac OS X) file names
by SourceForge.net 06 Nov '03

06 Nov '03

Feature Requests item #837563, was opened at 2003-11-06 16:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=837563&group_i… Category: None Group: None Status: Open Priority: 5 Submitted By: Hamilton Richards (hamrichards) Assigned to: Nobody/Anonymous (nobody) Summary: GHCi (Mac OS X) file names Initial Comment: It would be nice if, in file names, "\ " were handled as " ". This would make the GHCi interface consistent with those of Terminal and Hugs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=837563&group_i…

1 0

Making implicit parameters explicit
by Stefan Reich 06 Nov '03

06 Nov '03

Hi, I discovered implicit parameters today and I'm very excited about them because they allow to express certain code constructs more elegantly. However, I stumbled upon a problem. Suppose I have these definitions (the definition of Request is irrelevant): type Controller = (?req :: Request) => String controller1 :: Controller controller2 :: Controller controllerList = [controller1, controller2] GHC complains with: Unbound implicit parameter (?req :: Request) arising from use of `controller1' In the list element: controller1 In the definition of `controllerList': controllerList = [controller1, controller2] I can see why this isn't allowed; controllerList requires an implicit parameter ?req because it references functions needing this parameter. But I want it to be parameterless - it's just a static list of controller functions after all. The actual request shouldn't be supplied when selecting a controller from the list, but rather later, when invoking it. A solution is to make the parameter explicit by binding it: controllerList = [\req -> let ?req = req in controller1, \req -> let ?req = req in controller2] This works, but can't really be called elegant (the binding has to be repeated for every controller). So I tried to at least move the rebinding into a function: explicitRequest controller req = let ?req = req in controller controllerList = [explicitRequest controller1, explicitRequest controller2] This, however, is rejected by GHC. GHC doesn't seem to infer that explicitRequest hides the implicit parameter required by the controllers. Am I confused here or is this a bug in GHC? Thanks in advance, -Stefan -- [ADV] http://superversion.sf.net [/ADV]

2 4

RE: DiffArray Performance
by MR K P SCHUPKE 06 Nov '03

06 Nov '03

>This is one good reason they have to be protected by MVars Forgive my stupidity, but arn't the MVar operations (takeMVar, putMVar) IO operation, therefore the locks must be in the IO monad, therefore the code acting on the DiffArray should be in the IO monad... otherwise they can't use the MVar calls? Regards, Keean Schupke.

1 0

RE: DiffArray Performance
by Simon Marlow 06 Nov '03

06 Nov '03

> Could you not provide MVar free calls for use inside a > withMVar function, > minimising locking overhead? Are you suggesting something like withDiffArray :: DiffArray ix e -> (UnlockedDiffArray ix e -> IO a) -> IO a and then a bunch of fast operations on UnlockedDiffArray? The problem with this is that DiffArrays live in the pure world, not the IO world. This is one good reason they have to be protected by MVars: the imperative oeprations happen behind the scenes, so the programmer gets no chance to do his own locking or otherwise ensure that the DiffArray is uesd safely. Functions like withDiffArray don't work too well in the pure world, because you have to arrange that the "inner" part is fully deepSeq'd before you can release the lock. Cheers, Simon

1 0

RE: DiffArray Performance
by MR K P SCHUPKE 06 Nov '03

06 Nov '03

Could you not provide MVar free calls for use inside a withMVar function, minimising locking overhead? Keean Schupke.

1 0