RE: FiniteMap: modifyFM
So...yeah...I've kind of lost my train of thought, but I think that the problem I've frequently had is that I want to use the names the prelude uses, but can't. :).
Back when Haskell 1.4 (or 98?) was being designed, I proposed that Haskell's rule that the Prelude is implicitly imported into every module should be dropped. Benefit: simpler language, easier to replace Prelude with your own. Cost: requires you to type 2 extra tokens in every module and to ask students to type it in without first giving them a full explanation of what it means. Didn't get anywhere.
I'm wondering if that would help at all?
So what's wrong with 'import Prelude()'? If you regularly want to hide certain names just define a module: module MyPrelude (module Prelude) where import Prelude hiding (map) and at the top of every module in your own code, write import Prelude () import MyPrelude the current scheme is biased towards the majority (i.e. those that want to use the Prelude unchanged), but it's flexible if you want to do something else. I think it's fine. Cheers, Simon
So what's wrong with 'import Prelude()'?
It's kinda cryptic. A reasonable way to describe the rule being followed when you write 'import Prelude()' is: "To not import the prelude, first import the Prelude." It has to be explained to people as a special rule. After all, if I see this: import Foo() I know I can delete it with no change to the program. Do that with an import Prelude and you probably get a warnign about ambiguous imports. So it's another rule you have to explain to people. The situation where this came up was in writing Embedded Domain Specific Langauges like Fran. Fran users didn't want to know about Haskell's module system. It seemed reasonable to ask them to write import Fran at the head of their program but asking them to not import something they've never heard of using cryptic syntax seems a bit much. Similarily, if teaching functional programming, one might want to start out with a beginners' Prelude which has no type classes, only Integer (or Rational?), omits foldl, map and friends (because you want to teach students how to write their own versions, etc.) First thing you have to do is explain something cryptic. "Well, see there's this thing called a Prelude which we're not going to discuss in this course and we don't want it so what we do is we import it to make it go away." -- Alastair Reid
There were two comments from Simon that deserve addressing: 1:
There's no problem with having an AdvancedPrelude, but I would argue against building the standard Prelude on top of it for purely practical reasons
Agreed; I was only suggesting that for code-duplication purposes but understandable error messages are probably more important.
Just have a separate package containing AdvancedPrelude, and use -fno-implicit-prelude with GHC.
I would prefer having a standard library (couldn't tell if this was what you were suggesting or not) and having -fuse-advanced-prelude which defaults to: -fno-implicit-prelude and import AdvancedPrelude in the relevant modules. 2:
So what's wrong with 'import Prelude()'? If you regularly want to hide certain names just define a module:
the current scheme is biased towards the majority (i.e. those that want to use the Prelude unchanged), but it's flexible if you want to do something else. I think it's fine.
I have no problem with MyPrelude (I've actually resorted to this in a few instances), but, for as small as the haskell community is, there's the standard prelude, the hugs prelude (which is slightly different, last time I checked -- i bevelive it has foldl' and fromInt), my prelude, Ashley's prelude, and I'm sure (well, pretty sure) that other people out there either have their own prelude or have had the desire but not the gall to make their own. I would simply like a standard one that's more flexible. - Hal
participants (3)
-
Alastair Reid -
Hal Daume III -
Simon Marlow