June 2002 - Libraries

RE: FiniteMap: modifyFM
by Ashley Yakeley 21 Jun '02

21 Jun '02

At 2002-06-20 09:42, Hal Daume III wrote: >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. I don't think this flag thing is a good idea. The way to indicate that your code needs a particular prelude is to import it. I rather like Alastair's suggestion that the Prelude should not be implicitly imported. But it may be too late for that, and we can make do with -fno-implicit-prelude, at least for GHC. -- Ashley Yakeley, Seattle WA

1 0

RE: FiniteMap: modifyFM
by Simon Marlow 21 Jun '02

21 Jun '02

> 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. Not a problem; if you guys come up with a proposal and implement it, we'll add the appropriate flag to GHC. I think the right way to do it would be to put the code for the "advanced prelude" in a separate package. The package could be used to provide a replacement prelude (say with -fadvanced-prelude), or it could be used on its own (say with -package advancedprelude), to just use it as a library without changing the existing prelude. Cheers, Simon

1 0

Real ZOO web site, welcome! ID<oleudulhvCkdvnhoo1ruj>
by Farmgirl3997 21 Jun '02

21 Jun '02

1 0

RE: FiniteMap: modifyFM
by Simon Marlow 21 Jun '02

21 Jun '02

> > 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

3 2

Re: Prelude and FiniteMap: modifyFM
by George Russell 21 Jun '02

21 Jun '02

Alistair wrote [snip] > 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. [snip] I have the more radical solution of abolishing the Prelude altogether. Instead if you wanted to write main = putStrLn (show (2+2)) you would need something like import IO import Num import ReadShow Of course this would be somewhat tiresome for 1-line programs, but I think it would in general be more elegant. I fear thought that Haskell may already have passed the point where such radical changes are practical, so such a solution could only be implemented in a new language. Of course in a sense this is no worse than Alistair's solution, since for sure in the unlikely event that my solution became part of Haskell 3000, the implementors would include a library Prelude allowing users to port old code by inserting "import Prelude".

1 0

RE: FiniteMap: modifyFM
by Simon Marlow 20 Jun '02

20 Jun '02

> Yes, I agree with your [Possibly not...] statement, which I > why I think > I'm in favor of having the "two Preludes" option, but having > both standard > (this is part of my reason for not adopting Ashley's Prelude). > > I think a reasonable way to do it would be to have > > module AdvancedPrelude > > which defines the map, fold, etc functions all in their own class, > something like: > > class Map m a where > map :: (a -> b) -> m a -> m b > mapAccum :: ... > > and so on. It also defines things like Group, Ring, etc. 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 - people like me who have to maintain the code and don't understand Groups and Rings would be disadvantaged. It would also be hard, I'm guessing, to prevent the advanced prelude from leaking into error messages even if you hide every scrap of it from the Prelude's interface. Moreover, the vast majority of Haskell programmers don't need the AdvancedPrelude, yet they'd be linking in most of it whenever they write a program. Just have a separate package containing AdvancedPrelude, and use -fno-implicit-prelude with GHC. Cheers, Simon

1 0

RE: FiniteMap: modifyFM
by Simon Marlow 20 Jun '02

20 Jun '02

> Curiously, it seems classes aren't used much in the libraries. I.e. I > wanted my data structure to be used more or less like an array (it was > basically an array with some extras), but I couldn't just > > instance Indexed Foo where > a ! i = ... > bounds a = ... Hmm, very true. Perhaps there ought to be a way to define new instances of IArray and HasBounds - unfortunately IArray doesn't have the obvious methods like (!) and 'array' any more, it has methods like 'unsafeArray' and 'unsafeAt' which are versions of these without bounds checking (for efficiency - bounds checks are done only when necessary). > I can of course always define operations using different names, but > IMHO reusing common ones, like (!) makes the code much more readable. > > Similar for Sets, lists, and FMs, I'd expect something like > > instance Collection a where > empty = ... > (!!) > cardinality -- or whatever > > and so on. There have been lots of proposals for collection classes over the years, and no single one stands out as an obvious choice. However, I don't think we should stop looking - this is arguably one of the most important pieces still missing from the libraries, and the longer we go on without a good framework for collections, the harder it will be to add one. So get designing! Cheers, Simon

2 1

RE: FiniteMap: modifyFM
by Simon Marlow 20 Jun '02

20 Jun '02

> Now, in the case where equality from Ord key is an > equivalence rather than true equality, I can see that using > "new_key" in the otherwise case is the right thing to do. > > For my case, it means that the recently allocated new_key > replaces the old key that will have been around > longer. Doesn't this interact badly with generational > collectors? Is this causing you real grief? If it is, as you say, the Right Thing To Do, then can we really change it? > Oh yes, and since the similar operations on Refs and states > are called modifyBlah, shouldn't the _C versions of > operations on FiniteMaps be called something with "modify" > in them? > > so addToFM_C would become modifyFM > addListToFM_C ----"--- listModifyFM > > etc. I think names with words rather than abbreviations are > easier to read when returning to something after a long > period of absence. I agree, and if I had my way we would remove all the 'FM' suffices too. But name changes shouldn't be made gratuitously; FiniteMap is one of the more heavily-used modules in the libraries (certainly by me, and I expect other people too). I suppose we could rename everything exported by the library, leaving the old names in place for a couple of versions (deprecated, of course). Would someone like to suggest a complete new interface? Cheers, Simon

5 7

Re: FiniteMap: modifyFM
by Ashley Yakeley 18 Jun '02

18 Jun '02

At 2002-06-17 03:43, Jon Fairbairn wrote: >Omelettes! And ghc has an option to deprecate things (I >don't know about other compiler), so there's a >straightforward upgrade path. And the libraries are being moved into hierarchies anyway... -- Ashley Yakeley, Seattle WA

1 0

RE: FiniteMap: modifyFM
by Simon Peyton-Jones 17 Jun '02

17 Jun '02

| For my case, it means that the recently allocated new_key | replaces the old key that will have been around longer. | Doesn't this interact badly with generational collectors? I suppose it might, but I doubt its a significant effect, and the thought of having two versions doesn't appeal much! | Oh yes, and since the similar operations on Refs and states | are called modifyBlah, shouldn't the _C versions of | operations on FiniteMaps be called something with "modify" | in them? | | so addToFM_C would become modifyFM | addListToFM_C ----"--- listModifyFM | | etc. I think names with words rather than abbreviations are | easier to read when returning to something after a long | period of absence. I agree. Though "addTo" is hardly an abbreviation. Actually for finite maps etc, we've found "extendFM" to work nicely (better than addTo). Have a look at the nomenclature for (say) basicTypes/NameEnv.lhs in GHC's sources. Changing the names breaks programs, though. S

2 1