October 2003 - Haskell

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

Re: "interact" behaves oddly if used interactively
by S.J.Thompson 02 Oct '03

02 Oct '03

Bruce, All this discussion of 'interact' makes me feel quite nostalgic. In the late 80s(!) I did some work on this, since Miranda's only IO was in the form of interact. Understanding the interleaving behaviour is problematic, and hand-coded solutions proved to be difficult. I came up with a way of analysing these programs, and proved some elementary properties. The paper also contains a set of combinators for writing interactive programs, which prefigure the monadic interaction combinators. The paper is at: http://www.cs.kent.ac.uk/~sjt/Pubs/yoptrace.ps Best regards, Simon Thompson

1 0

Re: "interact" behaves oddly if used interactively
by b.i.mills＠massey.ac.nz 01 Oct '03

01 Oct '03

On the pedagogic part of this issue, I personally feel that using interact causes concentration on the temporal logic aspects of the code. That is, on understanding the interaction between the computer and the user as a whole. Although the monad approach has this in it, I feel it to be more hidden, and I like my students to have some experience with interact before going any significant distance into monadic IO. Similarly, I like them to look at other monads before IO monads, and IO monads before trying the do constructs. I've found that without the background of monads, the students get into tangles with the seemingly strange logic of the construct, and the error messages don't help them at all. However, on the down side of interact, I do have a grumble. I like to use the exercise of writing a generic command line processor, with line editing capacity as the basic task. The answer I'm looking for is just something like ... parse = lines execute s = if s==endCode then "" else "{" ++ s ++ "}" endCode = "stop" fini a = (take (length endCode) a) == endCode del ('\27':'\91':'\51':'\126':t) = True del _ = False edit s = aux 0 s [] where aux n [] b = '\n' : (blat (reverse b)) aux 0 b c | del b = aux 0 (drop 4 b) c aux n b (x:c) | del b = '\b' : ' ' : '\b' : (aux (n-1) (drop 4 b) c) aux n (a:b) c = a : (aux (n+1) b (a : c)) join (a:b) = a ++ "\n" ++ (if (fini a) then [] else "cmd: " ++ (join b)) blat s = execute (head (parse s)) myCmd = interact (\s -> "cmd: " ++ (join (map edit (lines s)))) In this code ... look at join, we could write this more along the lines of ... join ("stop\n":b) = "stop\n" join (a:b) = a ++ "\ncmd: " ++ (join b) But this basic approach has the problem (at least under Hugs) that when we enter the word "stop" at the command prompt, the word will not be echoed until we have got past the p in stop. But, it does not matter which line code we take, the initial characters of the string are the same. Although it is a tall order to work this out in general, it does seem to be fairly obvious in this case. That is, if I feed in something of the form ('s':b), then I can see that under each clause I must irrevocably get something of the form ('s':t) back, and further more if the first clause does not in the end match, then the second one will anyway (since we already know we have a list of at least one character). So, it is apparent at this stage that the output will not be an error (the only way that join has started processing this is that it was successfully returned by edit as a complete string), and will start with an 's'. Would such a characteristic make it easier or harder to work with interact? Just a thought, Bruce, Institute for Information and Mathematical Sciences Massey University at Albany, New Zealand.

1 0