- Haskell - Haskell.org

RE: Imported instance declarations
by Simon Peyton-Jones 06 Oct '03

06 Oct '03

This bad error message is improved in subsequent versions of GHC. 6.0.1 says In.hs:5: Duplicate instance declarations: In.hs:5: Functor ((->) i) In module Control.Monad.Reader: Functor ((->) r) Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Frieder Kalisch | Sent: 01 October 2003 15:12 | To: haskell(a)haskell.org | Subject: Imported instance declarations | | Hello, | | While trying to learn Hakell I came across a weird (to me) error message | concerning imported instance declarations. | | This module | | module XXX() where | | import Control.Monad.Error() | | instance Functor ((->)i) where | fmap = (.) | | gives this error message (compiling with ghc 5.0.4.2): | | Duplicate instance declarations: | XXX.hs:5: Functor ((->) i) | <No locn>: Functor ((->) r) | | For me this error message is somewhat puzzling: Where is the second | instance declaration given? In this case it happens to be in | Control.Monad.Reader, but how can I find out without looking for it | in the CVS repository? The documentation for Control.Monad.Error does | not mention the imported modules. | | I suppose, that the compiler knows in which module the instance | declaration was given, because it needs to tell duplicate import paths | from duplicate instance declarations. Why is it not given in this example? | | Greetings | | Frieder Kalisch | | | -- | Frieder Kalisch | f.kalisch(a)tphys.uni-heidelberg.de | +49-6221-549-432 | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

ANNOUNCE: HaRe, the Haskell Refactorer, version 0.1
by C.Reinke 06 Oct '03

06 Oct '03

Dear Haskellers, as part of our project on Refactoring Functional Programs http://www.cs.kent.ac.uk/projects/refactor-fp/ we are pleased to announce the availability of HaRe 0.1 (also known as HaRe 01/10/2003 ;-), a snapshot of our Haskell Refactorer prototype. You can get it via http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html Please see the README.txt for build/use instructions and known issues, and let us know about any problems, bugs, suggestions, or additional platforms you can confirm as working: our project address at kent.ac.uk is refactor-fp (which we'd like to keep spam-free). An initial catalogue describing the refactorings implemented in HaRe (with slightly different names) is included in the doc/ directory. Happy Refactoring! The HaRe Team (Huiqing Li, Claus Reinke, Simon Thompson) ---------------------------------------------------------------------- Background: Refactoring is the process of changing the structure of programs without changing their functionality, i.e., refactorings are meaning-preserving program transformations that implement design changes. For more details about refactoring, about our project and for background on HaRe, see our project pages and the papers/presentations/catalogue/demo/etc. available there, especially our contribution to this year's Haskell Workshop. HaRe - the Haskell Refactorer: HaRe is our prototype tool supporting a first few basic refactorings for Haskell 98 (see README.txt for known issues and limitations). It is implemented as a separate refactoring engine (on top of Programatica's Haskell frontend and Strafunski's generic traversal strategy library), with small scripting frontends that call this engine from either Vim or Emacs. The refactoring engine itself has been seen to build (with ghc-5.04.3) and run on most flavours of Windows (cygwin needed to build) and on Suns (binutils recommended to build), so we expect it to build and work on other unix-like platforms with almost no changes. In other words, we've tried to make sure that most of you should be able to build and use HaRe from your favourite OS/editor. Currently supported refactorings: removeDef : remove an unused definition duplicateDef : duplicate a definition under a new name liftToTopLevel : move a local definition to top level liftOneLevel : move a local definition one level up demote : move a definition local to point of use rename : rename an identifier introNewDef : turn expression into use of new definition unfoldDef : replace use of identifier by right-hand side addOneParameter: add parameter to definition rmOneParameter : remove unused parameter from definition generaliseDef : turn expression on rhs of definition into new parameter of that definition A series of screenshots illustrating some of the tasks one might want to accomplish with these refactorings can be found via the HaRe page (see above for URL). Caveats (see also README.txt): Please keep in mind that this is a prototype, so we do not recommend to use it on your productions sources just yet. Just play with it to get an idea of tool-supported refactoring in Haskell, and send us your feedback and bug-reports. Our goal is to develop this into a tool that many of you will find indispensible for Haskell development, and while we won't be able to follow every suggestion, we've got almost two more years in which to work towards this goal!-) History: Functionally, this is still roughly the snapshot you've seen at the Haskell workshop, packaged up for relative ease of build/use. Indeed, interim snapshots have been available all through September, and some of you have already played with those. The earliest snapshots were somewhat buggy, but over the last weeks the software has stabilised to the extent that we are back to Bug 0 (aka: insufficient test-coverage!-), and the time has come to distribute the current snapshot more widely.

3 3

RE: Library Infrastructure Proposal & Home Page
by Simon Marlow 05 Oct '03

05 Oct '03

I think the proposal is great. Here's some random comments: It might be worth saying earlier on that the library infrastructure is expected to be a layer underneath the platform's native package support (if such support exists). For example, I've never used Python's Distutils, but I have a bunch of Python packages on my system that were installed using the native package system on top of Distutils (I presume). FreeBSD's ports is both a source and binary package system. A FreeBSD system functions perfectly well using only binary packages. To a certain extent Gentoo is the same, although they place far less emphasis on binary packages. FreeBSD (in source or binary mode), and Gentoo, have no support for recompiling packages when something they depend on has changed. This is the biggest failing of these systems IMHO. The 3rd paragraph of 2.1 therefore isn't correct - there's still a big problem for source-based distributions. However, this is not *our* problem, it's theirs - when a dependency is updated, everything that depends on it should be recompiled. ./Setup.lhs bdist: wouldn't it be better to create a source RPM than a binary RPM? Once you have a source RPM the RPM tools can be used to build a binary RPM. Similarly for FreeBSD and Gentoo - I'd expect Setup.lhs to produce a port skeleton/ebuild for me, not a binary package. The PackageConfig file: I'd leave out 'provides' and 'isDefault' unless we have a convincing example which needs them. Possibly add: 'haddock_html_root :: String' and 'haddock_interface :: String' for documentation. I'm thinking about removing 'extra_ghc_opts' - it's highly dodgy when combined with 'auto'. I agree with Ross's comments about data vs. code. Let's abstract as much as possible as data. Cheers, Simon

3 2

Announce: hircules IRC client 0.3 released
by Jens Petersen 05 Oct '03

05 Oct '03

It's a pleasure to announce the release of Hircules 0.3. Hircules is an IRC client written in Haskell, using gtk2hs for its gui. Since the last release about 3 months ago, various bugs have been fixed and a good number of new features added, including better charset support and tab highlighting. A summary of the main changes is appended below. See the Hircules webpage <http://haskell.org/hircules/> for more details. A source tarball and an i386 rpm built for Linux with glibc-2.3 and gtk2-2.2 are available for download from the project site page <http://sourceforge.net/project/showfiles.php?group_id=81211>. Enjoy, Jens Version 0.3 (2003-10-05): * New features - input area is now at the bottom of the channel buffer, not a Entry box - UTF-8 support - highlighting of tabs for channel activity - multiline input is support now (from text pasted into input area) - exceptions from lambdabot modules are now caught - absolute paths are no longer mistaken for irc commands - leading '/' is optional now in virtual channels - topic changes appear in Alert channel now - autodecoding of ISO-2022 - tabs menu setup now - virtual channels now have '%' in front of them and can be "joined" - irc log is now date-stamped as well - the charset encoding for writing to a channel can now be set and shown with the new "/coding" command - improved lambdabot configure support

1 0

Re: Feature-request (was: Re: IO behaves oddly if used nested)
by ketil+haskell＠ii.uib.no 03 Oct '03

03 Oct '03

"Simon Marlow" <simonmar(a)microsoft.com> writes: > You don't need to know :-) > It's actually in the base package, but GHCi knows about all hierarchical > libraries without having to specify any extra command-line arguments. Ai! And here I've been doing :set -package all this time. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

RE: IO behaves oddly if used nested
by Simon Marlow 03 Oct '03

03 Oct '03

Alastair Reid writes: > ... Thus, we have Show instances for -> and IO ... Actually, you have to explicitly import Text.Show.Functions to get the Show instance for (->). Cheers, Simon

1 0

GHC allow-overlapping-instances (PART II)
by Kenny 03 Oct '03

03 Oct '03

Hi all, Here I change the instances from > instance C (OR T r) T > instance C (OR r T) T to > instance C (OR T r) T > instance C (OR T T) T and it compiles when allow-overlapping-instances is turned on. now I understand that GHC in fact allow-overlapping-instances if one is more specific than the other. But how about instance C (AND (OR r1 r2) (OR r1 r2)) (OR r1 r2) --[1] instance ( C (AND r1 r3) r5 , C (AND r2 r4) r6 ) => C (AND (OR r1 r2) (OR r3 r4)) (OR r5 r6) --[2] GHC allows this with -fallow-overlapping-instances flag on, but why? Is [1] more specific than [2] or the other way round? I am confused. -Kenny --- H X <haskellmail(a)yahoo.com.sg> wrote: > Date: Mon, 29 Sep 2003 13:10:25 +0800 (CST) > From: H X <haskellmail(a)yahoo.com.sg> > Subject: GHC allow-overlapping-instances > To: haskell(a)haskell.org > > Hi, > > Does anyone have ever used this option? > I see no difference when I present this program to > ghc > with -fallow-overlapping-instances on/off: > > module Test where > > > data T = T > data F = F > > data OR a b = OR a b > data AND a b = AND a b > > class C a b | a -> b > > instance C (OR T r) T > instance C (OR r T) T > > instance C (AND F r) F > instance C (AND r F) F > > -Kenny > > __________________________________________________ > Do You Yahoo!? > A free party for the most "shiok" photo! > http://sg.yahoo.com/shiok > __________________________________________________ Do You Yahoo!? A free party for the most "shiok" photo! http://sg.yahoo.com/shiok

2 1

IO behaves oddly if used nested
by blaat blaat 03 Oct '03

03 Oct '03

Hi, the interact remark triggered me to post this remark on nested use of IO. (I posted something similar some month ago on haskell-cafe/I read the haskell-archives ones so often) What about this program: main :: IO () main = putStr (show (putStr "Hello World!")) Am I the only one who feels that there is some conceptual _wrongness_ about Hugs responding with <<IO action>>? Another question with a trivial answer, what is the result of: main :: IO (IO ()) main = return (putStr "Hello World!") Clearly it also shows the relation between IO and chosen evaluation strategy. Cheers, l4t3r Some other random thoughts:.... Hmm,... there was also some question on the use of existential types, what about the following one (might be used to implement IO trivially in a _pure*_ manner! *with respect to rewrite strategy): data Nomad a = Return a | forall b . Bind (Nomad b) (b -> Nomad a) I would like to see Haskell extended with subtyping on algebraic datatypes (or is this implemented already?) Some of my programs would really benefit from such a feature. I am a teacher, I use haskell to test random ideas from combinatorics, SAT/EDA verification, control theory, real-time processes, and compiler/verification-language implementation. In short, I use Haskell as a vehicle to test short algorithms. Oh yeah, I propose to move the link on the Haskell site on "Monads explained by the Catholic Church" from the "Humor" section to the "Learning Haskell" section since they seem to be the only ones who actually clearly understand what is up with monadic IO. ;-p (actually, that is a dead-serious proposition) Hmm, long post, cheers again, l4t3r _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

5 6

Typo in GHC user guide?
by Graham Klyne 02 Oct '03

02 Oct '03

I think there's a typo in section 7.3.12.3: [[ You can't use existential quantification for newtype declarations. So this is illegal: newtype T = forall a. Ord a => MkT a Reason: a value of type T must be represented as a pair of a dictionary for Ord t and a value of type t. That contradicts the idea that newtype should have no concrete representation. You can get just the same efficiency and effect by using data instead of newtype. If there is no overloading involved, then there is more of a case for allowing an existentially-quantified newtype, because the data because the data version does carry an implementation cost, [--------------] [--------------] ... Repeated clause but single-field existentially quantified constructors aren't much use. So the simple restriction (no existential stuff on newtype) stands, unless there are convincing reasons to change it. ]] #g ------------ Graham Klyne GK(a)NineByNine.org

1 0

Pre-Call for Contributions -- HC&A Report (November 2003 edition)
by C.Reinke 02 Oct '03

02 Oct '03

[apologies for multiple copies - experience has shown that not all Haskellers can be reached via the main Haskell list anymore] An entry for your diaries (no other action required right now): ------------------------------Pre-Call-------------------------------- Your contributions to the November 2003 edition of the Haskell Communities & Activities Report will be invited soon. http://www.haskell.org/communities/ Submissions are welcome between 20th and 31st of October ---------------------------------------------------------------------- The real Call for Contributions will follow closer to the submission window, in about two weeks. This is just an early warning. You will need to plan about 15 minutes for composing your contribution, which would be a brief, ASCII-format, description of your Haskell activities (see earlier editions for plenty of examples). Cheers, Claus (current editor of HC&A Reports)

1 0