September 2001 - Haskell

Re: Haskell report (August release)
by Marcin 'Qrczak' Kowalczyk 12 Sep '01

12 Sep '01

Thu, 23 Aug 2001 10:00:35 -0700, Simon Peyton-Jones <simonpj(a)microsoft.com> pisze: > Please check it out. My plan is that if I hear nothing for a month, > I'll freeze it. Otherwise I'll iterate. I'll send some minor issues in September (much less than before it seems). Please wait... -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: The future of Haskell discussion
by Marcin 'Qrczak' Kowalczyk 12 Sep '01

12 Sep '01

Wed, 12 Sep 2001 11:00:38 +0100, Olaf Chitil <olaf(a)cs.york.ac.uk> pisze: > Mark Shields: Lightweight Modules for Haskell > Shortly stated that he is working on a new module system and would like > every interested person to join. I'm interested. How to join? -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Haskell98 undefinedness
by Sigbjorn Finne 11 Sep '01

11 Sep '01

What's the meaning of module A (B, B(..)) where { data B = C }; Is or isn't C exported? i.e., the H98 report is silent about what it means to have entity duplicates in an export list, possibly with different 'visibility' modifiers. --sigbjorn

2 1

LOPSTR 2001 - Submission Deadline Extension
by Fabio Fioravanti 11 Sep '01

11 Sep '01

___________________________________________________________________________ Our apologies if you receive multiple copies. ___________________________________________________________________________ CALL FOR PAPERS LOPSTR 2001 11th International Workshop on Logic-based Program Synthesis and Transformation http://www.iasi.rm.cnr.it/~adp/lopstr01_cfp.html Paphos, Cyprus, November 28 - 30, 2001 The deadline for abstract submission has been extended to: *** September 24th, 2001. Invited Speaker: Natarajan Shankar, SRI, Menlo Park, CA, USA, "Generating Efficient Code from Logic". The following is a non-exhaustive list of topics: specification analysis component-based software development synthesis optimization software architectures verification composition design patterns and frameworks transformation reuse specialization applications Any other information is available at: http://www.iasi.rm.cnr.it/~adp/lopstr01_cfp.html ============================================================================

1 0

Re: H98: Ix class
by Marcin 'Qrczak' Kowalczyk 11 Sep '01

11 Sep '01

Tue, 11 Sep 2001 09:16:11 -0400, Jan-Willem Maessen <jmaessen(a)alum.mit.edu> pisze: > Just to clarify, do we still require identities (1) and (3) below > (pasted from the Library report and numbered)? That is, is range > obliged to yield its results in strict index order? [This rules out > Ix instances that do, e.g., blocked iteration unless the array itself > is also re-blocked. Reblocking the array itself is arguably a good > idea, but may not be what we expect...] > > 1) range (l,u) !! index (l,u) i == i -- when i is in range > 2) inRange (l,u) i == i `elem` range (l,u) > 3) map index (range (l,u)) == [0..rangeSize (l,u)] The current implementation of Array in ghc iterates relies on them. It iterates either over array elements in the stored order or over range, whichever is more convenient for efficient implementation of the particular operation. For example elems is described in Haskell 98 as [a!i | i <- indices a], but ghc just picks elements in the stored order without computing index values or bounds checking. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: H98: Ix class
by Simon Peyton-Jones 11 Sep '01

11 Sep '01

| Just to clarify, do we still require identities (1) and (3) | below (pasted from the Library report and numbered)? That | is, is range obliged to yield its results in strict index | order? [This rules out Ix instances that do, e.g., blocked | iteration unless the array itself is also re-blocked. | Reblocking the array itself is arguably a good idea, but may | not be what we expect...] | | 1) range (l,u) !! index (l,u) i == i -- when i is in range | 2) inRange (l,u) i == i `elem` range (l,u) | 3) map index (range (l,u)) == [0..rangeSize (l,u)] I was not proposing to remove these identities. Should I? Simon

1 0

Re: H98: Ix class
by Jan-Willem Maessen 11 Sep '01

11 Sep '01

Simon PJ asks: > Does anyone want to argue that having Ord as a superclass of Ix is So > Bad > that it Absolutely Must Be Removed? Nope. If there's no natural ordering I expect the derived ordering will be used in practice. Occasionally messy, but it keeps the old code going. Just to clarify, do we still require identities (1) and (3) below (pasted from the Library report and numbered)? That is, is range obliged to yield its results in strict index order? [This rules out Ix instances that do, e.g., blocked iteration unless the array itself is also re-blocked. Reblocking the array itself is arguably a good idea, but may not be what we expect...] 1) range (l,u) !! index (l,u) i == i -- when i is in range 2) inRange (l,u) i == i `elem` range (l,u) 3) map index (range (l,u)) == [0..rangeSize (l,u)] -Jan-Willem Maessen Eager Haskell Project jmaessen(a)mit.edu

1 0

ANN: Gtk+HS 0.11.5
by Manuel M. T. Chakravarty 11 Sep '01

11 Sep '01

I am pleased to announce version 0.11.5 of Gtk+HS, the Haskell binding for the GUI toolkit GTK+. This is the first beta release and the first release that comes with pre-build binaries. The binding is not complete yet, but it is sufficient for applications with GUIs of medium complexity. The underlying toolkit, GTK+, implements a mature, high-end widget set, which forms the basis of the Gnome desktop environment, and is used in cutting edge open source applications, such as the Gimp, Gnumeric, and Abiword. Gnome (and, thus, GTK+) is not only one of the two main desktop environments for Linux, but has also been selected by Sun as the new standard desktop for Solaris. Moreover, there is a port of GTK+ available for Win32. The present distribution includes an example application (The Boolean Editor) that demonstrates how GTK+ can be used from Haskell. It illustrates concepts, such as callbacks, the handling of global GUI state, and synchronisation between the different windows of an application. The code is available directly from the Web page without need to download the complete release. Portability: I tested this release with GHC on GNU/Linux; however, it should work equally well on any other Unix platform that is supported by GHC. Moreover, it should, after some fiddling with makefiles, also work with NHC98, but I haven't got around to testing that yet. With the GTK+ port for Windows, Gtk+HS should in principle also be usable on Windows. I am not keen on trying the latter myself, but I would welcome any patches that are necessary to make it work. Gtk+HS includes code contributions from a number of people. See <http://cvs.gnome.org/lxr/source/gtk%2bhs/AUTHORS> for details. More information (including screenshots!) as well as source and binary packages are available from http://www.cse.unsw.edu.au/~chak/haskell/gtk/ Happy Hacking! Manuel

2 1

H98: Ix class
by Simon Peyton-Jones 11 Sep '01

11 Sep '01

Folks, (esp Matt, Jan-Willem) Back from ICFP, I have resumed my increasingly small circles around the Revised Haskell 98 Report. In an earlier message (which I enclose for your convenience) I proposed to: a) Remove Ord from Ix's superclasses b) Add rangeSize to Ix's methods (with a suitable default method) As we implemented these changes we discovered that change (a) actually breaks existing programs. Of course it does: now you have to add Ord to the signature of any function that compares indices. This really does happen (for example, it happens even in the code for the Array library in the Report). I should have realised this before, but I therefore withdraw proposal (a). It now looks like a perhaps-desirable, but definitely un-forced change, and that goes beyond my remit. However (b) doesn't break anything, I think, so I propose to let it stand. (The two are independent I think.) Does anyone want to argue that having Ord as a superclass of Ix is So Bad that it Absolutely Must Be Removed? Simon -----Original Message----- From: Simon Peyton-Jones Sent: 17 May 2001 17:52 To: Matt Harden; Haskell list Subject: RE: Ix class I rather agree with Matt's message below. I'm desperately trying NOT to change the H98 libraries, but this is a very non-disruptive change, as he points out, and it does lift two apparently-unnecessary restrictions. a) Remove Ord from Ix's superclasses b) Add rangeSize to Ix's methods Does anyone have any thoughts about this. (We made a similar change to Random, adding a method.) Simon | -----Original Message----- | From: Matt Harden [mailto:matth@mindspring.com] | Sent: 16 May 2001 00:43 | To: Haskell list | Subject: Ix class | | | Hello, | | I am working on an Ix instance for one of my types and | finding it rather restrictive. For me it would be useful to | have rangeSize be defined in the Ix class (with a default | definition of course), so that it can be overridden. | | Also, does anybody know why Ix derives from Ord? It seems to | me this is an unnecessary limitation on the types that can be | instances of Ix. I cannot think of a reason why the | implementation of anything in the Ix or Array modules would | require that every Ix be an Ord (with a minor exception -- | see below). If an implementation is using a comparison on an | Ix type, chances are it should be using inRange or comparing | (index bnds x) with (index bnds y) instead. | | One change would have to be made in the Array module if Ord | is removed from Ix: | instance (Ix a, Eq b) => Eq (Array a b) where | a == a' = assocs a == assocs a' | instance (Ix a, Ord b) => Ord (Array a b) where | a <= a' = assocs a <= assocs a' | | would become: | instance (Ix a, Eq a, Eq b) => Eq (Array a b) where | a == a' = assocs a == assocs a' | instance (Ix a, Ord a, Ord b) => Ord (Array a b) where | a <= a' = assocs a <= assocs a' | | As I said, I think this is a very minor issue. | | I believe that making these changes in the standard would not | impact existing programs in any way. Could these changes be | considered as a possible "typo" to be fixed in the Library Report? | | | P.S. In case anybody's interested, here's why I want to override | rangeSize: | | > newtype Honeycomb = Hx (Int,Int) deriving (Eq,Show,Ord) | > | > indexError = error "Index out of range" | > | > instance Ix Honeycomb where | > range (Hx b1, Hx b2) = | > [Hx x | x <- range (b1,b2), isHexIx x] | > inRange (Hx b1, Hx b2) (Hx x) = | > inRange (b1,b2) x && isHexIx x | > index (Hx b1, Hx b2) (Hx x) = | > let i = index (b1,b2) x in | > if isHexIx x then i `div` 2 else indexError | > | > isHexIx :: (Int,Int) -> Bool | > isHexIx (x,y) = x `mod` 2 == y `mod` 2 | | This implements a honeycomb or hexagonal tiling for a maze | generating program. The honeycomb is superimposed on a grid | such that only every other square is "active", corresponding | to a particular hexagon in the honeycomb. It's similar to a | checkers game, where only the dark squares are used. | | I would like _any_ pair of Ints to be an acceptable boundary | for the honeycomb, not just the ones that represent valid | indexes. For example, (Hx (0,0), Hx (15,12)) should be a | valid set of bounds. The current definition of rangeSize | makes this impossible, which is why I would like to override | it. By the way, the Library Report does not explicitly say | that the bounds have to both be valid indexes, though it does | imply this with the sample definition of rangeSize. | | Thanks, | Matt Harden | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell | _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

2 1

RE: Hiding non-existent entities
by Simon Peyton-Jones 10 Sep '01

10 Sep '01

Simon and Manuel propose that it should be an error for an import statement to hide something which isn't exported by the module being imported. This is a point on which I am willing to be swayed. It's a matter of taste, and really it doesn't matter what we decide provided we decide something. I'll adopt Simon & Manuel's view unless enough people yell. Frankly, I don't think it is worth a hullabaloo. Simon | -----Original Message----- | From: Manuel M. T. Chakravarty [mailto:chak@cse.unsw.edu.au] | Sent: 30 August 2001 07:20 | To: Simon Marlow | Cc: haskell(a)haskell.org | Subject: Re: Hiding non-existent entities | | | "Simon Marlow" <simonmar(a)microsoft.com> wrote, | | > The Haskell 98 errata page currently contains this item | related to a | > hiding clause on an import declaration which refers to a | non-existent | > entity: | > | > [Aug 2001] Page 66, Section 5.3, Import Declarations, | > numbered item 2. Add "It is not an error to hide an entity | > that is not, in fact, exported by the imported module, although | > compilers are encouraged to flag a warning in this case." (This | > is different from what I proposed by email, which made this case | > an error, but it allow a bit more flexibility as modules change.) | > | > IMO allowing a hiding clause to refer to a non-existent entity is a | > bit odd. Haskell doesn't have any other features like this: it's | > always an error to refer to an entity that isn't defined anywhere, | > even if the reference is otherwise harmless. Does anyone else have | > any opinions on this? | | I agree with you. | | Cheers, | Manuel | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0