March 2006 - Haskell-prime

partial type signatures/annotations/declarations..
by Claus Reinke 07 Mar '06

07 Mar '06

when trying to look up the state of this proposal, I noticed: - there seem to be two parallel versions (probably signatures is an older form, and all references ought to point to annotations instead?): http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions points to: http://hackage.haskell.org/trac/haskell-prime/wiki/PartialTypeSigs http://hackage.haskell.org/trac/haskell-prime/ticket/40 whereas http://hackage.haskell.org/trac/haskell-prime/report/9 points to: http://hackage.haskell.org/trac/haskell-prime/wiki/PartialTypeAnnotations http://hackage.haskell.org/trac/haskell-prime/ticket/86 - the proposal focusses on using "_" as a place holder for unspecified parts of a type or context, without discussing the alternative I'd favour: instead of introducing holes in types and contexts to leave parts of a declaration unspecified, why not use type subsumption? the idea being, that instead of declaring the precise type, one would declare an upper bound on the type, and the precise type inferred needs to be subsumed by the one declared. type and context syntax would remain unchanged, but in addition to "::" for precise type annotations, there'd be ":::" (or "::<", or whatever) to indicate the difference in intended semantics. pro: would easily allow for omission of type details or parts of context (a type with more context, or with more specific type components, is subsumed by the declaration) cons: as long as we only specify an upper bound, the inferred type could be more specific than we'd like (we can't say that we don't want context, or that some type variable must not be instantiated) cheers, claus

2 2

Re: Export lists in modules
by Ketil Malde 03 Mar '06

03 Mar '06

Wolfgang Jeltsch <wolfgang(a)jeltsch.net> writes: >> Personally, I would greatly prefer to have libraries that do not clash >> with common Prelude functions. > I would solve this problem by reducing the Prelude to just a core. List > function could go, for example, (mostly) into Data.List. If this means that you must import Data.List almost everywhere, this won't change anything - only add yet another import to every file. I know most - if not all - of my modules use lists, but just in case, I checked with the darcs sources - 95 of 107 source files appear to use lists. Ignoring the : and ++ operators (looking for null, map, and filter) the count is 76 files. >> If you always have to qualify it, what's the advantage of >> Data.Set.empty over emptySet again? At least with 'emptySet' I know >> what to grep for. > I would import Data.Set as Set. So I would use Set.empty instead of > emptySet. The problem is that I might import Data.Set as S. Joe would import it as something else, and Frank would use yet another prefix. > The advantage is that Set.empty is more structured. I'm not sure why that is such an advantage. To me, structure sounds like a means rather than an end. If it made things simpler, I'd be all for it, but IMO it doesn't - and it makes some things more difficult. > You can easily distinguish the kind of operation (empty) and the > type you are working with (Set). Only by convention - i.e. I must manually rename the module in a way that is meaningful with respect to the type. (As an aside, 'empty' is a rather poor example, as it is not a Prelude function. Take 'null' or 'map' or - why not - '(:)' instead) Don't get me wrong, I don't want to go back to the old ways of prefixing *every* identifier with a module abbreviation. But I resent having to add a multi-line half-standardized set of imports to over 90% of my source files. In short, I'm fairly comfortable with the scope of the Prelude¹ and I don't mind modules like e.g. Data.Map and Data.Set, which are similar in many ways to recycle some of their identifiers. However, I think minimizing the number of name clashes should be a goal, and modules that are intended to be used together, should try to avoid using the same identifiers. And this implies that Prelude identifiers should *not* be recycled, unless you intend to replace the Prelude. -k ¹ I might want to shove some of the association list stuff into Data.List, but certainly not all list functionality. -- If I haven't seen further, it is by standing in the footprints of giants

12 29

Re: Collections (was: Arrays)
by Robert Dockins 02 Mar '06

02 Mar '06

On Mar 2, 2006, at 1:57 PM, Alson Kemp wrote: >> This doesn't address Bags, Heaps, Finite Relations >> or 'cons'able >> sequences. > True. > > Perhaps my listing was incomplete, in which case this > might fix it: >>> Collection >>> .Array > * * .Bag > * * .FiniteRelations -- Maps? Finite Relations are to Finite Maps as Bags are to Sets. Each key can be associated with multiple elements. > * * .Heap >>> .Map >>> .Set >>> .Tree >>> .Binary >>> .Rose >>> Data >>> . ... >>> . Int >>> . ... > > What is an example of a cons-able sequence? (aside > from []) See http://www.eecs.tufts.edu/~rdocki01/docs/edison/index.html Edison contains about 8 or 9 different concrete implementations of sequences with varying time complexity for the core operations. > Or, perhaps as a non-math-geared programmer, I've > missed something. I come at this from "make Haskell > more useful to more programmers" rather than from > "make Haskell a mathematically beautiful language" (I > slept through Discrete Mathematics). That said, if > you can point me towards a paper, I'd be happy to read > up and try to encompass the "mathematically beautiful" > perspective, too. (Especially since the proposal will > probably get rejected without a component of > mathematical beauty! ;) ) I don't know of any papers of the top of my head. I guess I just wanted to point out that the landscape of abstract data structures is wider than "Array, Set, Map". Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

1 0

Collections (was: Arrays)
by Alson Kemp 02 Mar '06

02 Mar '06

Following on an earlier e-mail about refactoring Arrays... In noodling around with collections, sets, maps, arrays, I seem to have duplicated (a very small piece of) some of SPJ's work in "Bulk types with class"... from 9 years ago... In particular, Section 4 lays out the beginning steps of how to use multiparameter classes to implement a consistent set of Collections and subclasses. I know that I floated something similar a couple of weeks ago, but, based on the above, I thought that I'd float a more specific proposal: ------------ In Haskell', "collection"-style classes will be moved from the Data module and to the Collection module. Modules would be organized something like as follows: Collection .Array .Map .Set .Tree .Binary .Rose Data . ... . Int . ... Backwards compatibility can be maintained by leaving deprecated Data classes. -------- If there's no objection, I'll create a proposal ticket and flesh out the proposal more clearly. - Alson

2 1

RE: the MPTC Dilemma (please solve)
by Simon Peyton-Jones 02 Mar '06

02 Mar '06

You addressed this to me -- but I'm an advocate for rather conservative extensions whereas you are calling for extensions that go beyond what any current implementation can do. Anyway, there is already a ticket for overlapping instances, I think -- why don't you just add to that. If you send me Wiki-marked-up text I'll gladly paste it in for you. Simon | -----Original Message----- | From: Claus Reinke [mailto:claus.reinke@talk21.com] | Sent: 25 February 2006 15:33 | To: Simon Peyton-Jones | Cc: haskell-prime(a)haskell.org | Subject: Re: the MPTC Dilemma (please solve) | | | Is the behaviour of GHC with -fallow-undecidable-instances (and | | -fcontext-stack) well-understood and specifiable? | >I would not say that it's well-specified, no. | | to start improving that situation, could we please have a task ticket | for "document differences in unconstrained instance handling", then | ask everyone to attach source examples showing such differences? | [can guests attach code to task tickets?] | | the hope being, of course, that implementations nominally providing | the same feature will eventually converge on providing the same | interpretation of all programs using that feature. | | an example of the current oddities (at least they seem odd to me;): | both hugs and ghc claim to resolve overlapping instances in favour | of the most specific instance declaration. both claim that functional | dependencies uniquely determine the range types from the domain | types. but they do not agree on which programs to accept when | we try to combine best-match with FDs. | | I've already given an example where ghc allows me to define | record selection, while hugs complains that the overlap violates | the FDs. | | I reported that as a hugs bug, because I think the best-match | resolution of overlaps should ensure that the FD violation cannot | happen, so the code should be valid. there are different ways to | interpret FDs (something to check, or something to use), but it | seemed that ghc was doing the right thing there. thread start: | | http://www.haskell.org//pipermail/hugs-bugs/2006-February/001560.html | | but after further experimentation, I'm not longer sure that ghc | is doing the right thing for the right reasons. here is a tiny example | of one of the disagreements: | | {- ghc ok | hugs "Instance is more general than a dependency allows" -} | | class C a b | a -> b | instance C a b | | so what is ghc doing there? is it going to guarantee that b will | always be uniquely determined? | | {- ghc ok | hugs "Instance is more general than a dependency allows" -} | | class C b | -> b where c :: b | instance C b where c = error "b" | | safely m = m `CE.catch` print | main = do | safely $ print $ (c::Int) | safely $ print $ (c::Bool) | safely $ print [id,c] | | oh, apparently not. unless b is uniquely determined to be universally | quantified, and the instantiations happen "after" instance selection. | | {- ghc ok | hugs "Instance is more general than a dependency allows" -} | | class C b | -> b where c :: b | instance C b where c = error "b" | | class D a where d :: a -> String | instance C a => D a where d a = "a" | instance C Int => D Int where d a = "Int" | | -- try at ghci prompt: (d 1,d (1::Int)) | -- gives: ("a","Int") | | so that parameter of C isn't all that unique. at least not long enough | to influence instance selection in D. | | comments? | | cheers, | claus

3 2

RE: Export lists in modules
by Simon Peyton-Jones 01 Mar '06

01 Mar '06

These days, hs-boot files are pretty close to source files, with masses of stuff omitted. However, you must process the import declarations of the hs-boot file to figure out the name spaces involved. In the original source file, you can't process the import declarations because those modules have not been compiled yet. It's not clear which ones to omit. Similarly in the body of the source file, there are lots of references to things in imported modules, but those imported modules have not been compiled yet. You could imagine a) compiling recursive groups "all at once" b) somehow magically filtering the source file to omit anything undefined, leaving only defined stuff..... which ought to be enough to tie the knot. But GHC currently requires the programmer to perform (b) manually. Simon | -----Original Message----- | From: haskell-prime-bounces(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | Ben Rudiak-Gould | Sent: 23 February 2006 21:26 | To: haskell-prime(a)haskell.org | Subject: Re: Export lists in modules | | Malcolm Wallace wrote: | > An explicit interface would be useful for many purposes besides | > machine-checked documentation. For instance, it could be used to | > eliminate the hs-boot or hi-boot files used by some compilers when | > dealing with recursive modules. | | Why *does* ghc require hs-boot files? What can be gleaned from an hs-boot | file that couldn't be expressed in the corresponding hs file? For example, | why doesn't ghc simply require that at least one module in a recursive group | contain an explicit export list mentioning only explicitly typed symbols? | | -- Ben | | _______________________________________________ | Haskell-prime mailing list | Haskell-prime(a)haskell.org | http://haskell.org/mailman/listinfo/haskell-prime

4 3

RE: realToFrac issues
by Simon Marlow 01 Mar '06

01 Mar '06

On 28 February 2006 18:42, Jacques Carette wrote: > What *problem* are you actually trying to solve here? The problem that 'realToFrac (0/0 :: Float) :: Double' doesn't give you NaN, and similarly for the other special float values. > If it is > "conversion between floating point types", then there are other > solutions that do not need to ``pollute'' exact arithmetic. I did not > see any tickets on this -- did I miss it/them? This is one issue > where I should go and contribute, as I've been part of a team that > has done just this to a programming language before, so at least I > can claim to know the pitfalls to avoid! Please go ahead and create a ticket. I don't claim to know a great deal about floating point, but Cale Gibbard's suggestion (use encodeFloat.decodeFloat) looks reasonable to me. I have an old item on my GHC ToDo list that says "make encodeFloat.decodeFloat work for NaN" :-) Cheers, Simon

1 0

RE: the MPTC Dilemma (please solve)
by Simon Peyton-Jones 01 Mar '06

01 Mar '06

| >You addressed this to me -- but I'm an advocate for rather conservative | >extensions whereas you are calling for extensions that go beyond what | >any current implementation can do. | | generally, that may be true,-) but in this specific case, I was just asking | for an effort to document the differences in current handling of extended | Haskell in hugs and ghc, by collecting test cases such as those I included. Collecting test cases is indeed useful. But since it is apparently well beyond Haskell', you probably don't want to tangle it up with the Haskell' web site. In that case, a plausible place to collect them would be the GHC user documentation wiki http://haskell.org/haskellwiki/GHC:Documentation. At the bottom is "Collaborative documentation" and you could add a new page for "Overlapping instances and functional dependencies" or whatever. It's all entirely world-writeable. I know you want to describe the differences between GHC and Hugs, but this seems as good a place as any to do so. thanks Simon

1 0