Re: bug in 6.8.1-candidate
On Fri, Oct 12, 2007 at 05:39:51PM +0100, Simon Peyton-Jones wrote: Serge Thank you so much for reporting your problems with DoCon 2.11. I believe I have fixed them. Would you like to try again? As of now, the fixes are in the HEAD, so you'll have to pull from there. In a day or two Ian should have merged them to the 6.8 branch. It'd be great to hear back from you to know whether things are now ok. Please let us know -- meanwhile I'll file your messages about DoCon. Simon Thank you. Now, I search for `HEAD', looking into http://haskell.org/ghc/download.html, and it shows HEAD branch (development snapshots): * Download snapshot distributions I click at (*), and it is http://www.haskell.org/ghc/dist/current/dist/, and it keeps many ghc sources, but no 6.8* among them. Need I to take ghc-6.9.20071013-src.tar.bz2 of October 13 ? --- Mechveliani ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1772: GHC doesn't like 'inline' type function applications
#1772: GHC doesn't like 'inline' type function applications +--- Reporter: jpbernardy |Owner: chak Type: bug | Status: new Priority: normal |Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | +--- Changes (by simonmar): * milestone: 6.8.1 = 6.10 branch Comment: We're not advertising type functions as part of 6.8. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1772#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1709: simplifier causes stack overflow in ghc-6.8.0.20070916
#1709: simplifier causes stack overflow in ghc-6.8.0.20070916 -+-- Reporter: [EMAIL PROTECTED] |Owner: simonpj Type: bug | Status: new Priority: normal|Milestone: 6.8.1 Component: Compiler | Version: 6.8 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -+-- Changes (by simonmar): * owner: = simonpj * milestone: = 6.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1709#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1701: impossible happened
#1701: impossible happened -+-- Reporter: [EMAIL PROTECTED] |Owner: Type: bug | Status: new Priority: normal|Milestone: 6.8.1 Component: Compiler | Version: 6.6.1 Severity: normal| Resolution: Keywords: impossible| Difficulty: Moderate (1 day) Os: Linux | Testcase: Architecture: x86_64 (amd64)| -+-- Changes (by simonmar): * milestone: = 6.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1701#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1649: running GHCi screws up console display by changing code page
#1649: running GHCi screws up console display by changing code page ---+ Reporter: guest |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: GHCi| Version: 6.6.1 Severity: normal | Resolution: Keywords: codepage code page | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86 | ---+ Comment (by simonmar): See also #1483 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1649#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1649: running GHCi screws up console display by changing code page
#1649: running GHCi screws up console display by changing code page ---+ Reporter: guest |Owner: Type: bug | Status: new Priority: normal |Milestone: 6.8.2 Component: GHCi| Version: 6.6.1 Severity: normal | Resolution: Keywords: codepage code page | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86 | ---+ Changes (by simonmar): * milestone: = 6.8.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1649#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1720: 6.8.0.20070917 Haddock links use absolute paths with no file:// prefix
#1720: 6.8.0.20070917 Haddock links use absolute paths with no file:// prefix +--- Reporter: guest|Owner: igloo Type: bug | Status: new Priority: high |Milestone: 6.8.1 Component: None | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: Unknown | +--- Changes (by simonmar): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1720#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1745: i386 Linux bindist doesn't install .hi files for the ghc package
#1745: i386 Linux bindist doesn't install .hi files for the ghc package -+-- Reporter: igloo |Owner: igloo Type: bug | Status: new Priority: normal|Milestone: 6.8.1 Component: Build System | Version: 6.8 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Changes (by igloo): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1745#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1776: type families : couldn't match type Elem a against type Elem a
#1776: type families : couldn't match type Elem a against type Elem a -+-- Reporter: guest |Owner: chak Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.8 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Changes (by chak): * owner: = chak -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1776#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1775: type families: poor error massages when lacking instances
#1775: type families: poor error massages when lacking instances -+-- Reporter: guest |Owner: chak Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.8 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Changes (by chak): * owner: = chak -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1775#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug in 6.8.1-candidate
On Mon, Oct 15, 2007 at 02:47:37PM +0100, Simon Peyton-Jones wrote: | But it'd be better still to check with the 6.8 branch, but I can see you can't do that. IAN, are we | dumping snapshots of the 6.8 branch for people to try? Can you help Serge (and perhaps others) have a | snapshot they can try. Actually, Serge, you can find STABLE (i.e. 6.8 branch) snapshots here: http://haskell.org/ghc/download.html There's no Windows installer in the last few days, for reasons Simon is looking into, but the source distributions should be fine. I'd wait until after tonight, to be sure Ian's merges have all gone in. Simon Do you mean that http://haskell.org/ghc/dist/stable/dist/ghc-6.8.0.20071013-src.tar.bz2 of October 13 will do? --- Mechveliani ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1706: type checking does not terminate for ghc-6.8.0.20070916
#1706: type checking does not terminate for ghc-6.8.0.20070916 -+-- Reporter: [EMAIL PROTECTED] |Owner: simonpj Type: bug | Status: new Priority: normal|Milestone: 6.8.1 Component: Compiler | Version: 6.8 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -+-- Comment (by simonpj): OK, I'm happy to say that both the HEAD and the stable branch now compile the HETS download without fuss. I'm not sure about the Programmatica case because when I try the `cvs` command you give, I'm getting {{{ bash-3.1$ socksify cvs -d :pserver:[EMAIL PROTECTED]:/cvs co -P programatica/tools/base cvs checkout: authorization failed: server cvs.haskell.org rejected access to /cvs for user anoncvs cvs checkout: used empty password; try cvs login with a real password bash-3.1$ }}} Can you try with the current stable snapshot, and see if you agree that it's fixedo? Thanks Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1706#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1706: type checking does not terminate for ghc-6.8.0.20070916
#1706: type checking does not terminate for ghc-6.8.0.20070916 -+-- Reporter: [EMAIL PROTECTED] |Owner: simonpj Type: bug | Status: new Priority: normal|Milestone: 6.8.1 Component: Compiler | Version: 6.8 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -+-- Comment (by guest): Great! I've checked both cases with `ghc-6.8.0.20071014-i386-unknown- linux.tar.bz2` and it works. (The password for `cvs login` is `cvs`, see http://ogi.altocumulus.org/~hallgren/Programatica/cvs.html) [EMAIL PROTECTED] (the field is gone to add this?) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1706#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1706: type checking does not terminate for ghc-6.8.0.20070916
#1706: type checking does not terminate for ghc-6.8.0.20070916 -+-- Reporter: [EMAIL PROTECTED] |Owner: simonpj Type: bug | Status: closed Priority: normal|Milestone: 6.8.1 Component: Compiler | Version: 6.8 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -+-- Changes (by simonpj): * status: new = closed * resolution: = fixed Comment: Excellent, thank you. I'll close this bug then. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1706#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1709: simplifier causes stack overflow in ghc-6.8.0.20070916
#1709: simplifier causes stack overflow in ghc-6.8.0.20070916 -+-- Reporter: [EMAIL PROTECTED] |Owner: simonpj Type: bug | Status: new Priority: normal|Milestone: 6.8.1 Component: Compiler | Version: 6.8 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -+-- Comment (by guest): The problem also shows up with ghc-6.8.0.20071014, Christian -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1709#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: bug in 6.8.1-candidate
I'd go for 20070914 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.0.20070914-src.tar.bz2 S | -Original Message- | From: Serge D. Mechveliani [mailto:[EMAIL PROTECTED] | Sent: 15 October 2007 15:41 | To: Simon Peyton-Jones | Cc: glasgow-haskell-bugs@haskell.org | Subject: Re: bug in 6.8.1-candidate | | On Mon, Oct 15, 2007 at 02:47:37PM +0100, Simon Peyton-Jones wrote: | | But it'd be better still to check with the 6.8 branch, but I can see you can't do that. IAN, are | we | | dumping snapshots of the 6.8 branch for people to try? Can you help Serge (and perhaps others) | have a | | snapshot they can try. | | Actually, Serge, you can find STABLE (i.e. 6.8 branch) snapshots here: | | http://haskell.org/ghc/download.html | | There's no Windows installer in the last few days, for reasons Simon is looking into, but the source | distributions should be fine. I'd wait until after tonight, to be sure Ian's merges have all gone in. | | Simon | | | Do you mean that | | http://haskell.org/ghc/dist/stable/dist/ghc-6.8.0.20071013-src.tar.bz2 | of October 13 | will do? | | --- | Mechveliani ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1759: HPC interaction with -Wall leading to spurious pattern match warnings
#1759: HPC interaction with -Wall leading to spurious pattern match warnings -+-- Reporter: guest |Owner: igloo Type: merge | Status: reopened Priority: low |Milestone: Component: Compiler | Version: 6.8 Severity: normal| Resolution: Keywords: HPC | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Changes (by AndyGill): * status: closed = reopened * resolution: fixed = -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1759#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug in 6.8.1-candidate
ghc-6.8.0.20071013-src.tar.bz2 (October 13) is buggy, it cannot build the DoCon test module, starts to `panic'. Now, I shall try http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.0.20070914-src.tar.bz2 On the other hand, whatever GHC version the developers would like to test, they can easily take the public docon-2.10 and follow install.txt. The only two small points for porting from ghc-6.6.1 to 6.8* are * replacing runhaskell with runghc in source/Makefile, * adding ``, containers'' to the line of build-depends in source/docon.cabal. --- Mechveliani On Mon, Oct 15, 2007 at 04:47:09PM +0100, Simon Peyton-Jones wrote: I'd go for 20070914 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.0.20070914-src.tar.bz2 S | -Original Message- | From: Serge D. Mechveliani [mailto:[EMAIL PROTECTED] | Sent: 15 October 2007 15:41 | To: Simon Peyton-Jones | Cc: glasgow-haskell-bugs@haskell.org | Subject: Re: bug in 6.8.1-candidate | | On Mon, Oct 15, 2007 at 02:47:37PM +0100, Simon Peyton-Jones wrote: | | But it'd be better still to check with the 6.8 branch, but I can see you can't do that. IAN, are | we | | dumping snapshots of the 6.8 branch for people to try? Can you help Serge (and perhaps others) | have a | | snapshot they can try. | | Actually, Serge, you can find STABLE (i.e. 6.8 branch) snapshots here: | | http://haskell.org/ghc/download.html | | There's no Windows installer in the last few days, for reasons Simon is looking into, but the source | distributions should be fine. I'd wait until after tonight, to be sure Ian's merges have all gone in. | | Simon | | | Do you mean that | | http://haskell.org/ghc/dist/stable/dist/ghc-6.8.0.20071013-src.tar.bz2 | of October 13 | will do? | | --- | Mechveliani ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc for docon-2.10
Simon P. Jones wrote he would go for ghc-6.8.0.20070914. I tried to `make' it by ghc-6.8.0.20070928: ./configure --prefix=.. make makeLog It reports ... cbits/unicode.c:1:63: error: floating constant in preprocessor expression ghc: 15634792 bytes, 4 GCs, 122880/122880 avg/max bytes residency (1 samples)\, 16M in use, 0.00 INIT (0.00 elapsed), 0.00 MUT (0.03 elapsed), 0.01 GC (0.01 \elapsed) :ghc make[2]: *** [cbits/unicode.o] error1 make[1]: *** [boot] error 2 make: *** [stage1] error 1 Dear GHC developers, please try any appropriate ghc-6.8* candidate for making the public docon-2.10 and running its test module. Porting to 6.8 is simple: 1) runhaskell -- runghc (in Makefile) 2) build-depends: + , containers (in docon.cabal). Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Prevent optimization from tempering with unsafePerformIO
Hello, I am writing a compiler from the functional logic language Curry to Haskell. As the result is a real extension of Haskell, there has to be SOME side effect involved. Unfortunately, this seems to prevent me from using any of ghc's optimizations on the resulting code. I have tried for some time to invoke the no-inline pragmata, but they seem to have no effect at all. Recently at ICFP, Neil Mitchell told me that there definitely is a way to avoid this problem. But does anybody know how? Thanks for your help! Bernd Brassel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] PLAN-X 2008 Deadline approaching
Call for Papers and Demos = ** Abstract deadline: Oct. 17, 2007 ** Paper deadline: Oct. 22, 2007 PLAN-X 2008 --- Programming Language Techniques for XML ACM SIGPLAN Workshop colocated with POPL 2008 San Francisco, California, USA - 9 January 2008 http://gemo.futurs.inria.fr/events/PLANX2008/ The PLAN-X 2008 workshop is the forum to present and discuss bleeding-edge research at the intersection of programming language and data base technology with an emphasis on tree-shaped data structures and their XML representation. Topics of interest are all aspects of XML processing and querying: theories, methodologies, paradigms, language designs, types, analyses, runtime aspects, implementations, tools, applications. This edition of PLAN-X is particularly interested in blending the XML processing approaches developed by the programming languages and data management communities. Expressive power and high performance are among the common goals that these communities pursue. We encourage the submission of crosscutting contributions that apply techniques from one community to problems from the other. The primary criteria for paper selection are originality, relevance, and timeliness to ensure that we can enjoy reports on ongoing and unfinished work with high potential in the workshop. Submissions === We seek submissions in two categories * regular papers (10 pages, 30 minutes presentation) * demo papers (4 pages, 10 minutes plenary presentation + 30 minutes slot for individual discussions shared with other demos) For details see the submission instructions on http://gemo.futurs.inria.fr/events/PLANX2008/?page=subm Important Dates === Abstract deadline *** 17 October 2007 Submission deadline *** 22 October 2007 Notification30 November 2007 Final papers due14 December 2007 Program Committee = Veronique Benzaken Université de Paris-Sud 11, France Alin DeutschUniversity of California, San Diego, USA Wenfei Fan University of Edinburgh, UK Mary Fernandez ATT Research, USA Haruo HosoyaUniversity of Tokyo, Japan Ralf Lämmel Universität Koblenz, Germany Sebastian ManethNational ICT and UNSW, Sydney, Australia Jim Melton Oracle Corporation, USA Michael SchwartzbachUniversity of Aarhus, Denmark Jérôme Vouillon CNRS, France Ioana Manolescu (general chair) Gemo group, INRIA Futurs, France Peter Thiemann (program chair) University of Freiburg, Germany ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Fingerprints and hashing
Simon Peyton Jones writes: We are all familiar with the idea of an MD5 checksum, which provides a reliable fingerprint for a file, usually 128 bits or so... For various applications (including identifying common sub-expressions, and version tracking in GHC), I'd like a Haskell library that supports simple fingerprint operations... Below I give an informal specification of such a library. I can think of any number of implementations, but I'd like one that is (a) robust and (b) efficient. By robust I meant that with, say, a 128-bit fingerprint the chance of accidental collision is truly low; a non-robust implementation uses the 128-bit space in a non-uniform way [trivial example: gets stuck on zero]... The module signature would be something like this: data Fingerprint initialPrint :: Fingerprint class Fingerprintable t where fingerPrint :: t - Fingerprint - FingerPrint instance Fingerprintable Char instance Fingerprintable Int instance Fingerprintable Word32 -- etc The fingerPrint operation here is expressed in the traditional way: an accumulator (say 128 bits) into which one stuffs successive values (e.g. a byte stream). However, very important, I also want a more compositional form: instance Fingerprintable Fingerprint so that I can do something like fp :: Expr - Fingerprint fp (App e1 e2) = fp e1 `fingerPrint` fp e2 [For Salil anad Michael: apply the fingerPrint function to a fingerprint] An obvious implementation of instance Fingerprintable Fingerprint is to divide one fingerprint into words, and feed it into the other via the Word32 instance. But it's not clear to me whether or not that is robust... I'd like one other thing: to be able to trade cost for accuracy. I'd like a 128-bit fingerprint with essentially zero chance of having two distinct values that map to the same fingerprint; and a one-word fingerprint that was a lot more efficient, but where collisions would be entirely possible (again hash-consing is an example). Simon, If I wanted this functionality, I'd call in the professionals (like Salil Vadhan, Michael Rabin, and Andrei Broder, whom I have cc'ed on this message). You sent this mail to the Haskell list, but I think the Haskell content of this problem is trivial compared to the algorithmic problems you pose. I remember, for example, a problem in the distant past of SRC Modula-3, where fingerprinting did not behave as expected because the source of the fingerprint module was itself fingerprinted. Here are some algorithmic references: http://tinyurl.com/yoeusg, http://tinyurl.com/2a2yfj - Modula-3 code for compositional 64-bit fingerprints, polynomial chosen by (literally) flipping a coin http://citeseer.ist.psu.edu/broder93some.html - Andrei's paper on applications of fingerprinting How does laziness play into this problem? If you don't mind building up a lot of thunks, you can probably just use several fingerprinting algorithms in parallel and then pull just the one you need... Norman ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] pretty-printing Haskell with automatic parens?
The haskell-src package contains a pretty-printer for Haskell syntax that requires parentheses to be explicitly placed in the (abstract) syntax representation. I have some code for automatically inserting parentheses where necessary (for use before pretty-printing), but I'm guessing someone else has done so better than I. Does anyone have pointers? I'm glad to share my version as well. Conal, I don't have code, but I did publish an algorithm for inserting parentheses minimally: http://tinyurl.com/24xbp7 There's code on that page but I'm sorry to say it's ML code :-( Norman ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
igloo: On Sun, Oct 14, 2007 at 05:19:31PM +0200, Udo Stenzel wrote: Ian Lynagh wrote: People interested in making it easy to use new versions of packages with old compiler releases can make a small script that installs empty Cabal packages called bytestring, containers, array, etc. That completely misses the fact that bytestring cannot be upgraded, no matter how many fake packages are available. Ah, you mean the problem is that it really does depend on some change in bytestring (the internal API?), rather than just having a dependency on the bytestring package? Then yes, things are not so easy. Part of the motivation for splitting up base is so that this sort of thing is easier in the future. Yes, this was exactly the motivation for not back porting the binary library to 6.4 and earlier: it depends on representation details of ByteString that I'm not going to cpp into portability. If I understand correctly, the main issue for Udo is simply that the MonadFix instance is required by his code, and isn't available in binary 0.3 -- the version to be used on earlier GHCs. Is that right Udo? If that's the case, manually inserting that instance when using binary 0.3 seems easy enough. -- Don ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Module system question
Hello, I have a question concerning Haskell's module system. Consider the following example which defines three modules A,B, and C: module A where { data X = X } module B where { class X a } module C where { import A; import B; data Y = Y X } The question is: Is there an ambiguity error in module C?. It seems that the answer depends on how we interpret ambiguous. In the context of module C, the name X may refer to either the class defined in module B, or the datatype defined in module A. Therefore, we could consider X to be ambiguous, and indeed, this is what happens in GHC 6.6. On the other hand, the name X is used in a context where we are expecting a type constructor and not a class name, and therefore the name X could be unambiguously taken to refer to the datatype X, which is what seems to happen in Hugs. I like the Hugs behavior because it accepts more programs. OTOH, GHC's behavior may be a bit simpler to explain and implement(?). Any thoughts? -Iavor ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
On Fri, 2007-10-12 at 01:27 +0200, Udo Stenzel wrote: Don Stewart wrote: Since you're not using ghc 6.8, you should use binary 0.3 :) That was PC for sorry, GHC 6.6 is no longer supported and don't even ask about 6.4 As far as I can see, there's no good reason why binary, tar, etc cannot work with ghc-6.4, 6.6 and 6.8. I've made it work for my zlib iconv libs just fine without too much cpp'ery. So I'm going to try and fix binary, tar etc to work with all recent ghc. Stay tuned. Obviously it'll need the newest Cabal, but that works with all versions of ghc back to 6.2, and it can be installed as user. Duncan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Status of Haskell Prime Language definition
Hi Robert, At the recent Haskell workshop, I stood up and gave the following summary (approximately): Up to now, the Haskell' effort has been mostly about exploring the possibilities, to find out what could be in Haskell', and to scope out what it might mean. We've now reached the stage where we want to do the opposite, namely trying to pin down what we definitely want to have in the standard, and what it should look like in detail. I've set aside a chunk of my own time this fall to help coordinate the activity, write text etc. I'm hoping that things should be pretty clear by early next year. I have spoken with CUP and JFP about publishing the standard as a special issue of JFP and as a book, and they are interested. The strawman timeline for that is early next summer. Hope this helps, John On Oct 11, 2007, at 9:34 PM, Robert Will wrote: Hi all, When I first discovered Haskell' I was really excited to hear that many of the individual extensions that are already used by many people are going to be put together to one coherent next release. I have read the archive of the Haskell Prime Mailing list for all of 2007 as well as a lot of pages on Haskell.org and in the Haskell Prime Wiki, yet the most recent status report that I found is the one in the wiki from September 2006. (http://hackage.haskell.org/trac/haskell-prime/wiki/Status') Could someone please summarize the current status and planned time line for Haskell'? thanks a lot, Robert -- Skype: robert.will ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime John Launchbury | galois | (503)626-6616 x104 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
[Haskell-cafe] Re: New slogan... (A long speculation)
On 2007-10-15, [EMAIL PROTECTED] wrote: ok writes: On 11 Oct 2007, at 1:00 pm, [EMAIL PROTECTED] wrote: An anonymous called ok writes: I am not anonymous. That is my login and has been since 1979. Oh, bother... According to my imperfect knowledge of English, an anonymous is somebody who doesn't sign his/her letters. And doesn't unveil his name. Just OK as login, even since 1979, is still anonymous, whatever you may say. In my dialect, anonymous is never used as noun, solely an adjective. Further, maintaining the same identity but not revealing the corresponding legal identity is pseudonymous. Pseudonym can be used as a noun, but it refers strictly to the name itself, and never the bearer. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell-curry, classical logic, excluded middle
Now that that works, one more question. Is it possible to hide the r that is attached to every single type? For example to do something like this (which doesn't compile): No answer needed. Duh.. I can just pick r to be any type (like ()). I've got intuitionistic logic and classic logic in haskell types now, using an identical interface/notation (ie. they're swappable for proofs that don't need excluded-middle). The interfaces use infix type names that read similarly to their meanings: logic: http://www.thenewsh.com/%7Enewsham/formal/curryhoward/IntLogic.hs http://www.thenewsh.com/%7Enewsham/formal/curryhoward/ClassLogic.hs and example theorems: http://www.thenewsh.com/%7Enewsham/formal/curryhoward/IntTheorems.hs http://www.thenewsh.com/%7Enewsham/formal/curryhoward/ClassTheorems.hs Should this go up on the wiki somewhere? Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hosting of Haskell project
On Sun, Oct 14, 2007 at 21:24:50 +0200, Gour wrote: On Sun, 14 Oct 2007 15:22:13 +0100 Ian Lynagh [EMAIL PROTECTED] wrote: We could perhaps have web pages on projects.haskell.org, and some sort of bug tracker on bugs.haskell.org (or perhaps trac.haskell.org etc). Some days ago I stumbled upon Redmine tracker (http://redmine.org/) written in Ruby (well, Trac is also not Haskell :-) but has support for darcs ;) Just an idea... There is support for darcs in tracs as well. I never got around to writing a blog post about setting up darcs+trac+lighttpd on Debian and by now I fear I've forgotten how I did it... I remember it being remarkably easy though. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus.therning@gmail.com http://therning.org/magnus signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
The really amazing thing about the IO Monad in Haskell is that there *isn't* any magic going on. An level of understanding adequate for using the I/O and State monads stuff (that is, adequate for practically anything analogous to what you might do in another language) goes like this:[...] Yes, I am at the stage where I can understand most of whats going on, as you described it in your email. I was wondering if understanding Category Theory would help me model situations better. Thats all :) But for now, I guess I will stick with this. Assuming that its a black box and it does what its supposed to do. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hosting of Haskell project
On Sun, Oct 14, 2007 at 15:22:13 +0100, Ian Lynagh wrote: On Wed, Oct 10, 2007 at 05:05:28PM +0100, Magnus Therning wrote: I've almost reached a state where I wouldn't be ashamed of sharing the code so I looked into my options of free hosting. It seems I only have one option for publishing the code: - Request a project on code.haskell.org. I could only find one option for a homepage for the project: - Create a page on the Wiki. There seems to be no option when it comes to tracking bugs. :-( I could also not locate any option for publishing haddock pages. :-( We'd like community.haskell.org to be usable for all of this, it just needs someone to ask us for something, and then us to get around to setting it up. Currently source repos go on code.haskell.org. We could perhaps have web pages on projects.haskell.org, and some sort of bug tracker on bugs.haskell.org (or perhaps trac.haskell.org etc). Would it be better to make things consistent for users, and have all projects use trac (or something else), or for each project to be able to easily use the bug tracker of their choice? It sounds like things are moving in a good direction. I have some suggestions on what is currently there: 1. Make sure that requesting an account via the web form works. I was met with a 500 when I tried a few days ago. (I reported it and [rt.haskell.org #92] is the ticket ID.) 2. Make the flow more explicit. It isn't clear that one needs an account before requesting the creation of a project. It doesn't have to be enforced in code on the site, just a bit of text would be enough. My thoughts: - Offer as few options as possible, ideally just offer one. Trac is a good example of something that's good enough. It combines homepage, documentation, bug tracking and VC inspection in one tool. The main reason for offering just one option: minimise the burden administration (I'm assuming administrators are volunteers). Secondary reason: consistency for users. - Have one instance of trac¹ on trac.haskell.org per project. - Have one entry point that is separate from trac.haskell.org. I think this is what Hackage is supposed to be. /M ¹ I'm just using trac and trac.haskell.org as examples without really saying that's what should be used. -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus.therning@gmail.com http://therning.org/magnus signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
On 10/14/07, Peter Verswyvelen [EMAIL PROTECTED] wrote: If you want I can dig up my old source code where I converted a random number generator from a purely functional approach to a monadic approach, but I'm not sure reading it would help you, it's creating the code yourself that will be useful I guess. Actually I stopped bothering long ago about 'understanding monads'. After reading many blog posts, wikis, tutorials, etc, often multiple times, I developped a fuzzy idea of what you can do using monads, and that's enough for me to use monads like IO, STM, State, Parsec, etc. without too much problems. I use haskell to solve many little problems in my job and I'm damned sad that I can't use it for larger projects. I feel I'm still a long way from identifying a situation where I would need to write my own monad, and be able to do it, but by the time such situation arises, I don't think it'd be too much a problem. That being said, I plead guilty of not provinding feeback where I found the doc lacking. I have no excuse. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hosting of Haskell project
On Mon, 15 Oct 2007 07:36:55 +0100 Magnus Therning [EMAIL PROTECTED] wrote: There is support for darcs in tracs as well. I never got around to writing a blog post about setting up darcs+trac+lighttpd on Debian and by now I fear I've forgotten how I did it... I remember it being remarkably easy though. I was playing with it in the past, but it's 3rd party, ie. Trac does not have official support. otoh, Redmine has it out-of-the-box and, even more important, Redmine has support for multiple projects (I know a person who plans to configure SF-like service based on Redmine) which is scheduled for Trac-1.0, but considering how long we are waiting for trac-0.11, who know when it will happen... Sincerely, Gour signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: On the verge of ... giving up!
[EMAIL PROTECTED] wrote: However, arguably the biggest imperatives for Haskell 98 was to remove features that would confuse undergraduates. [...] People want to write map instead of fmap. We could have come up with an alternative name for the list-version of map and not showed map to newbies. Couldn't the too much overloading for undergrads issue be solved by providing a LearningPrelude and a RealHackersPrelude? :) The condition is that the former exports the same or less functions with the same or less general types than the latter, so that function names are the same and there's no infantilizing. A stronger condition would be that every valid LearningPrelude program should be a valid RealHackersPrelude program. This is probably preferred, but may be tricky due to overloading ambiguities. Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] do
Actually I stopped bothering long ago about 'understanding monads'. I think that's a shame, because when I wrote the source code myself to get from a pure functional approach (passing the object from function to function as an extra argument) to a monadic approach, it was a real eye opener. Many of the different FP techniques, like partial http://www.haskell.org/haskellwiki/Partial_application application, reversed' http://www.haskell.org/haskellwiki/Parameter_order parameter order, lambas http://www.haskell.org/haskellwiki/Anonymous_function , pointfree notation http://haskell.org/haskellwiki/Pointfree etc were required to do this, which might be one of the reasons it's a bit difficult for newbies to see how a monad is just pure FP in disguise. After cracking the code myself, I had so much appreciation for the guys who invented this stuff, it's really the work of a genius, at least that's the way it felt to me. And then the math approach to abstract the whole thing into a type class, so it can be used for many other single-flow (or how should I call that?) computations,... so nice. I can't say that I can write a monad instance myself yet without peeking in the book, but I think I would recognize the pattern if I see code that could make use of monads (at least the simple cases). Now I'm figuring out arrows, and this gives me a feeling like... euh... well... it's even more abstract, it encapsulates any kind of computation, also the ones then can be split into multiple branches (okay, I should not talk about this, I don't really get arrows yet...) Of course, I'm a kind of guy who likes to understand the inner details before I'm really pleased... So for Haskell, I still have a long way to go :) But you seem to be much further ahead than I am when it comes to *using* monads, so your approach is probably better. Just get used to the damn things and accept them (ouch, that feels a lot like religion...) Cheers, Peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of david48 Sent: Monday, October 15, 2007 9:15 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] do On 10/14/07, Peter Verswyvelen [EMAIL PROTECTED] wrote: If you want I can dig up my old source code where I converted a random number generator from a purely functional approach to a monadic approach, but I'm not sure reading it would help you, it's creating the code yourself that will be useful I guess. Actually I stopped bothering long ago about 'understanding monads'. After reading many blog posts, wikis, tutorials, etc, often multiple times, I developped a fuzzy idea of what you can do using monads, and that's enough for me to use monads like IO, STM, State, Parsec, etc. without too much problems. I use haskell to solve many little problems in my job and I'm damned sad that I can't use it for larger projects. I feel I'm still a long way from identifying a situation where I would need to write my own monad, and be able to do it, but by the time such situation arises, I don't think it'd be too much a problem. That being said, I plead guilty of not provinding feeback where I found the doc lacking. I have no excuse. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hosting of Haskell project
Magnus Therning wrote: There is support for darcs in tracs as well. Gour wrote: I was playing with it in the past, but it's 3rd party, ie. Trac does not have official support. I happen to be looking for a project mgmt framework right now. It seems to me that the opposite is true. Trac is a mature app with a huge community of people supporting it and writing plugins, including some departments at NASA. It is being used successfully for many large projects, such as GHC. It will not go away for a long, long time. Much of the Haskell community is already accustomed to Trac. Redmine is quite new. Based on posts and commits, it appears to be maintained by a single person. I don't know of any major project or organization that is using it yet. So I am a little worried that its future is not yet assured. And I am not sure if anyone knows yet how stable it is currently, or how it scales under load. For that reason, I am currently not considering Redmine for my organization. However, Redmine definitely looks nicer and easier to use than Trac. Please let me know if my impression of its stability and track record are wrong. Also - if the Haskell community adopts Redmine, that itself could give it a big push. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up! [OT]
Richard A. O'Keefe writes: (2) The mathematical background of Haskell is extremely important for implementations. Some important data structures and techniques are practical in large part because of the kinds of optimisations that are only straightforward in a language that has such foundations. (3) Beginners do not need to understand all the mathematics behind Haskell to use it. (5) Precisely because it seeks generality, category theory seems difficult to concrete thinkers. And books on category theory tend to be extremely fast-paced, so ideas which are not in themselves particularly esoteric (which may in fact be eminently practical) tend to be presented in a way which people trying to study by themselves have trouble with. So people can be scared off by what _ought_ to be a big help to them. Yes. Yes. And when *additionally* people whose experience/competence is rather weak, spread the fear, hatred and carelessness, I have the impression that this is something similar to a guy in primary school (and this list *is* a kind of school) who bothers the pupils with such discoveries as the differential calculus is a swearword, just to annoy you, you will =never= need that, I live happily without. There IS a problem. The fast pace of Category theory is a bit incomplete diagnosis. For me, what was most annoying was an awful trap. Everything began slowly, and nicely. And authors are kind, helpful, and understanding. And they promise that it is *for me*. Or for Brandon S. Allbery KF8NH... (BTW, Why Andrew Bromage says that the book of Lawvere is pricey? Cambridge Univ. Press sells the Conceptual Mathematics for 33 pounds. This is not so much...) Check some other titles, *free*, please: *Categories for =working comp. sci'ists=, AspertiLungo. *Categorical Primer by Chris Hillman (he - apparently - still revises the next version...) *Gentle introduction to Cat. Th., a calculational approach by Fokkinga. *Basic Cat., by Jaap Van Osten, a course for undergraduates, which begins by saying that for the Author the basic experience counts more than theory. (And, of course, Barr and Wells...) Now, you start reading, it goes smoothly, you understand functors, natural transformations, retracts, initial objects, etc. And then the slope begins to increase exponentially, you hit a wall... It seems that people who finally decided to write books, tutorials, etc. are so conditioned, that they cannot put themselves into a skin of a true profan, even people so perfect, so didactically skilled as Barr and Wells. But as says the quotation from a science-fiction story /Born among the dead/: you must elevate yourself to their level, since you cannot force them to descend to yours... Still, monads, Kleisli triples, etc. belong to the *EASY* part!! === So, if some people really *want* to learn something, some time devote they shall. But, there are some shortcuts as well, although nothing complete. http://en.wikibooks.org/wiki/Haskell/Category_theory is a nice introduction! The paper on Bananas, lenses and barbed wire (Meijer, Fokkinga, Paterson) is almost a compulsory reference. The craziness of generalization/universality is very well exposed in the compilation of Fritz Ruehr, which can be read by *ANYBODY*. There is no hard science inside, just examples! http://www.willamette.edu/~fruehr/haskell/evolution.html Once upon a time, Eric Meijer and Luc Duponcheel wrote a paper entitled On the expressive power of constructor classes, where they proposed a new categorical prelude for Gofer. It is an extremely inspiring paper! (Citeseer shall have it.) Some of ideas therein, in a different setting, can be easily read in the Varmo Vene thesis on coinduction, and other horrible stuff. And, of course, there is a paper by Conor McBride and Ross Paterson on applicative programming with effects, with an interesting discussion *around* monads. http://www.soi.city.ac.uk/~ross/papers/Applicative.pdf ... Ugh. I am afraid I began an infinite, corecursive strem. Perhaps it is time to break it. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] do
On Mon, 15 Oct 2007, Peter Verswyvelen wrote: Actually I stopped bothering long ago about 'understanding monads'. I think that's a shame, because when I wrote the source code myself to get from a pure functional approach (passing the object from function to function as an extra argument) to a monadic approach, where monadic is still pure functional, but somehow tries to hide that ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Claus Reinke wrote: but calling split-base base goes directly against all basic assumptions of all packages depending on base. The new base will have a new version number. There is no expectation of compatibility when the major version is bumped; but we do have an informal convention that minor version bumps only add functionality, and sub-minor version bumps don't change the API at all. So a package that depends on 'base' (with no upper version bound) *might* be broken in GHC 6.8.1, depending on which modules from base it actually uses. Let's look at the other options: - if we rename base, the package will *definitely* be broken - if the package specified an upper bound on its base dependency, it will *definitely* be broken In the design we've chosen, some packages continue to work without change. Specifying a dependency on a package without giving an explicit version range is a bet: sometimes it wins, sometimes it doesn't. The nice thing is that we have most of our packages in one place, so we can easily test which ones are broken and notify the maintainers and/or fix them. Another reason not to change the name of 'base' is that there would be a significant cost to doing so: the name is everywhere, not just in the source code of GHC and its tools, but wiki pages, documentation, and so on. Yes I know we've changed other names - very little in packaging is clear-cut. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hosting of Haskell project
On Mon, 15 Oct 2007 11:39:27 +0200 Yitzchak Gale [EMAIL PROTECTED] wrote: It seems to me that the opposite is true. Trac is a mature app with a huge community of people supporting it and writing plugins, including some departments at NASA. It is being used successfully for many large projects, such as GHC. It will not go away for a long, long time. Much of the Haskell community is already accustomed to Trac. That's true. Redmine is quite new. Based on posts and commits, it appears to be maintained by a single person. I don't know of any major project or organization that is using it yet. So I am a little worried that its future is not yet assured. And I am not sure if anyone knows yet how stable it is currently, or how it scales under load. I'm doing some small tests and cannot say anything concrete. However, Redmine supports MySQL PostgreSQL (besides SQLite), so that part should scale well. otoh, I am waiting quite long for Trac-0.11 to appear and based on recent post(s) from its devs on ml, it looks it is not so close. Solution for hosting for many projects, should have built-in support for multiple-projects and Trac won't have it for some time. However, Redmine definitely looks nicer and easier to use than Trac. Please let me know if my impression of its stability and track record are wrong. I'll try, although I cannot mimic proper scaling on my localhost with few small projects. Also - if the Haskell community adopts Redmine, that itself could give it a big push. I fully agree and hope someone more qualified (from Haskell community) will take a look too. Sincerely, Gour signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hosting of Haskell project
On Mon, Oct 15, 2007 at 09:24:28 +0200, Gour wrote: On Mon, 15 Oct 2007 07:36:55 +0100 Magnus Therning [EMAIL PROTECTED] wrote: There is support for darcs in tracs as well. I never got around to writing a blog post about setting up darcs+trac+lighttpd on Debian and by now I fear I've forgotten how I did it... I remember it being remarkably easy though. I was playing with it in the past, but it's 3rd party, ie. Trac does not have official support. Yes, that's true. It seemed very good at the time though and it integrated well with trac. Personally I don't see the 3rd-party state as an issue. otoh, Redmine has it out-of-the-box and, even more important, Redmine has support for multiple projects (I know a person who plans to configure SF-like service based on Redmine) which is scheduled for Trac-1.0, but considering how long we are waiting for trac-0.11, who know when it will happen... It being implemented in Ruby-on-Rails, which I've /read/ has bad scaling properties, could be a problem. I'm also not convinced support for multiple projects is an important feature. It could even pose a problem in the future since, depending on how it's done underneath, it could make migrating a single project off the site more difficult than tarring up a directory and copy it to its new home. I'm somewhat sad to learn trac might be going in that direction. On the other hand Redmine does look cleaner somehow and I've never seen a trac site that is as easy to find my way around as www.redmine.org. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus.therning@gmail.com http://therning.org/magnus pgpCzobeAItnw.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
Yes, exactly, but how does one call the way of programming without monads / do notation then, explicitly passing the object? Does this approach have a name? Or just non-monadic style? Henning Thielemann wrote: On Mon, 15 Oct 2007, Peter Verswyvelen wrote: Actually I stopped bothering long ago about 'understanding monads'. I think that's a shame, because when I wrote the source code myself to get from a pure functional approach (passing the object from function to function as an extra argument) to a monadic approach, where monadic is still pure functional, but somehow tries to hide that ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
Peter Verswyvelen writes: Yes, exactly, but how does one call the way of programming without monads / do notation then, explicitly passing the object? Does this approach have a name? Or just non-monadic style? In the jargon of CPS, somehow related to Monads, the constructions which do not use continuations are often called in Direct Style. I think it can be exported to Monads in general. State Monad in particular. IO is different, you *cannot* make it non-monadic. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
On 10/15/07, Peter Verswyvelen [EMAIL PROTECTED] wrote: Yes, exactly, but how does one call the way of programming without monads / do notation then, explicitly passing the object? Does this approach have a name? Or just non-monadic style? the painful style ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: On the verge of ... giving up!
On 10/15/07, apfelmus [EMAIL PROTECTED] wrote: Of course, the solution is to first drop n elements and then take tails instead of dropping n elements every time. map (drop n) . tails = tails . drop n O(m*n) O(m) Nice identity. I'll remember this one. With this, we can write a function that returns the last n elements of a list in O(m) time and O(n) space as lasts :: Int - [a] - [a] lasts n xs = head $ [x | (x,[]) - zip (tails xs) (tails $ drop n xs)] and use it as a drop-in replacement main n = print . sum . map read . lasts n . lines = getContents But that's a a two-liner now heh =). Thanks for your great postings, apfelmus. Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: On the verge of ... giving up!
2007/10/15, Felipe Lessa [EMAIL PROTECTED]: On 10/15/07, apfelmus [EMAIL PROTECTED] wrote: Of course, the solution is to first drop n elements and then take tails instead of dropping n elements every time. map (drop n) . tails = tails . drop n O(m*n) O(m) Nice identity. I'll remember this one. With this, we can write a function that returns the last n elements of a list in O(m) time and O(n) space as lasts :: Int - [a] - [a] lasts n xs = head $ [x | (x,[]) - zip (tails xs) (tails $ drop n xs)] and use it as a drop-in replacement main n = print . sum . map read . lasts n . lines = getContents But that's a a two-liner now heh =). If we're talking about (more than one)-liners, isn't this simpler to read? Or is it just me lasts n xs = let (_,remn) = splitAt n xs in go xs remn go lag [] = lag go [] _ = error shouldn't happen go (l:ls) (x:xs) = go ls xs -- Daniil Elovkov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: On the verge of ... giving up!
Felipe Lessa wrote: apfelmus wrote: Of course, the solution is to first drop n elements and then take tails instead of dropping n elements every time. map (drop n) . tails = tails . drop n O(m*n) O(m) Nice identity. I'll remember this one. Oops, please don't because it's wrong :) Data.List let xs = [1..3] Data.List map (drop 2) . tails $ xs [[3],[],[],[]] Data.List tails . drop 2 $ xs [[3],[]] The first one produces some extra empty lists at the end. In other words, the left hand side and the right hand side have different lengths length . map (drop n) . tails = (+1) . length but length . tails . drop n = (\k - 1 + max 0 (k-n)) . length But the wrong version looks much nicer :) Thanks for your great postings, apfelmus. λ(^_^)λ Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
but calling split-base base goes directly against all basic assumptions of all packages depending on base. The new base will have a new version number. There is no expectation of compatibility when the major version is bumped; but we do have an informal convention that minor version bumps only add functionality, and sub-minor version bumps don't change the API at all. if this is the official interpretation of cabal package version numbers, could it please be made explicit in a prominent position in the cabal docs? of course, i have absolutely no idea how to write stable packages under this interpretation. and the examples in the cabal docs do not explain this, either (neither bar nor foo 1.2 are any good under this interpretation). So a package that depends on 'base' (with no upper version bound) *might* be broken in GHC 6.8.1, depending on which modules from base it actually uses. Let's look at the other options: - if we rename base, the package will *definitely* be broken - if the package specified an upper bound on its base dependency, it will *definitely* be broken why do you omit the most popular (because most obvious to users) option? - if base remains what it is and a new package is created providing the rest of base after the split, then every user is happy (that it is currently hard to implement this by reexporting the split packages as base is no excuse) In the design we've chosen, some packages continue to work without change. Specifying a dependency on a package without giving an explicit version range is a bet: sometimes it wins, sometimes it doesn't. The nice thing is that we have most of our packages in one place, so we can easily test which ones are broken and notify the maintainers and/or fix them. sorry, i don't want to turn package management into a betting system. and i don't see how knowing how much is broken (so cabal can now only work with central hackage?) is any better than avoiding such breakage in the first place. cabal is fairly new and still under development, so there is no need to build in assumptions that are sure to cause grief later (and indeed are doing so already). Another reason not to change the name of 'base' is that there would be a significant cost to doing so: the name is everywhere, not just in the source code of GHC and its tools, but wiki pages, documentation, and so on. but the name that is everywhere does not stand for what the new version provides! any place that is currently referring to 'base' will have to be inspected to check whether it will or will not work with the reduced base package. and any place that is known to work with the new base package might as well make that clear, by using a different name. Yes I know we've changed other names - very little in packaging is clear-cut. how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. base-not-1.0 would know that it doesn't do that. and if there is no single package that reexports the functionality of base-1.0, cabal could even try to consult multiple packages to make ends meet (provided that someone told it that 'expects: base' can be met by 'provides: rest-base containers ..'). claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up! [OT]
On Oct 15, 2007, at 7:01 , Yitzchak Gale wrote: But I think we are still at the stage where a programmer who wants practical results is better off starting out by learning how to use monads in practice, not by delving into category theory. No argument from a Haskell standpoint. Still, when people here or on #haskell start tossing CT around, it'd be nice to have more than a very vague and probably incorrect notion of what they're saying. :) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
On Oct 15, 2007, at 7:02 , [EMAIL PROTECTED] wrote: IO is different, you *cannot* make it non-monadic. Not really true; it's just much more painful. You just e.g. explicitly do what the ghc library's implementation of IO does: construct a chain of functions with an opaque (and optionally(?) existential to enforce the opacity) RealWorld type which is passed as state from one invocation to the next, with the top level application partially applied. Or one of the operationally equivalent tricks used by other Haskell runtime implementations, cf. IO Inside. It's not so much hard as it is far too much busywork for a programmer to want to deal with when programming... hence hiding the scaffolding in the type, which is perhaps the most general description of what a Haskell monad actually is. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
On Oct 15, 2007, at 7:02 , david48 wrote: On 10/15/07, Peter Verswyvelen [EMAIL PROTECTED] wrote: Yes, exactly, but how does one call the way of programming without monads / do notation then, explicitly passing the object? Does this approach have a name? Or just non-monadic style? the painful style ? Explicit style, cf. my previous message? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: On the verge of ... giving up!
On Oct 15, 2007, at 7:59 , Felipe Lessa wrote: On 10/15/07, apfelmus [EMAIL PROTECTED] wrote: lasts :: Int - [a] - [a] lasts n xs = head $ [x | (x,[]) - zip (tails xs) (tails $ drop n xs)] (...) main n = print . sum . map read . lasts n . lines = getContents But that's a a two-liner now heh =). .oO { if you want Perl, you know where to find it... } -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
On Oct 15, 2007, at 9:48 , Brandon S. Allbery KF8NH wrote: On Oct 15, 2007, at 7:02 , [EMAIL PROTECTED] wrote: IO is different, you *cannot* make it non-monadic. Not really true; it's just much more painful. Expanding on this slightly: the neat thing about Haskell's monads is not that they are somehow not pure. It is that they a completely pure and referentially transparent way to capture and safely encapsulate concepts that themselves may *not* be pure or referentially transparent, such as IO --- while simultaneously being useful for concepts that *are* pure and referentially transparent, such as State or Maybe/Either/[]. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Claus Reinke [EMAIL PROTECTED] writes: if this is the official interpretation of cabal package version numbers, could it please be made explicit in a prominent position in the cabal docs? Me too. This is not a criticism nor endorsement of any particular scheme, just a vote in favor of having a - one, single, universal - scheme. of course, i have absolutely no idea how to write stable packages under this interpretation. and the examples in the cabal docs do not explain this, either (neither bar nor foo 1.2 are any good under this interpretation). You need a way to specify foo 1.2 foo 2, which is a suggestion that was tossed around here recently. Also, you'd need foo 1.x for x=2 to be available after foo-2.0 arrives. 'base' aside, I don't think we want a system that requires us to rename a library any time incompatible changes are introduced. The major/minor scheme has worked nicely for .so for ages. I'd like to make the additional suggestion that a major version number of 0 means no compatibility guarantees. Another reason not to change the name of 'base' is that there would be a significant cost to doing so: the name is everywhere, not just in the source code of GHC and its tools, but wiki pages, documentation, and so on. Much like 'fps', now known as 'bytestring', no? I had some problems finding it, true, but the upside is that old stuff is free to reference fps until I can get around to test and update things. how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. base-not-1.0 would know that it doesn't do that. and if there is no single package that reexports the functionality of base-1.0, cabal could even try to consult multiple packages to make ends meet Scrap cabal in favor of 'ghc --make'? :-) Seriously though, how hard would it be to automatically generate a (suggested) build-depends from ghc --make? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Claus Reinke wrote: Simon Marlow wrote: Another reason not to change the name of 'base' is that there would be a significant cost to doing so: the name is everywhere, not just in the source code of GHC and its tools, but wiki pages, documentation, and so on. but the name that is everywhere does not stand for what the new version provides! any place that is currently referring to 'base' will have to be inspected to check whether it will or will not work with the reduced base package. and any place that is known to work with the new base package might as well make that clear, by using a different name. base changed its API between 2.0 and 3.0, that's all. The only difference between what happened to the base package between 2.0 and 3.0 and other packages is the size of the changes. In fact, base 3.0 provides about 80% the same API as version 2.0. Exactly what percentage change should in your opinion require changing the name of the package rather than just changing its version number? Neither 0% nor 100% are good choices... packaging is rarely clear-cut! Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Java - Haskell adjustment
Hi, its Ryan here... I've just come from an intensive course in java and have been thrown into the imperative world of haskell. The problem that I have is extremely simple in java but I am having trouble adjusting my old mindset. A multiset is a collection of items. Each item may occur one or more times in the multiset. All items are of the same type. The scenario we could use is a students' grades for their A levels: 3A, 4B and 2C grades for our pupil 'x'. A multiset may be implemented by a list... so ['A', 'A', 'A', 'B', 'B', 'B', 'B, 'C', 'C'] but this very ineffiecient and tedious. How might one set out into putting this into action thanks... Any help that complements my ideas is welcome _ Feel like a local wherever you go. http://www.backofmyhand.com___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Laziness (was: [Haskell-cafe] Performance problem with random numbers)
On Sun, Oct 14, 2007 at 11:54:54PM +0200, ntupel wrote: On Sat, 2007-10-13 at 09:56 -0400, Brandon S. Allbery KF8NH wrote: Now you need to start forcing things; given laziness, things tend to only get forced when in IO, which leads to time being accounted to the routine where the forcing happened. If random / randomR are invoked with large unevaluated thunks, their forcing will generally be attributed to them, not to functions within the thunks. (Yes, this means profiling lazy programs is a bit of a black art.) After more testing I finally realized how right you are. It appears that my problem is not related to random/randomR but only to laziness. I came up with a test that doesn't use random numbers at all and still needs about 2.5 seconds to complete (it is really just meaningless computations): Here's a modified version of your code that prints out a real result, by using sum rather than seq to force the computation: module Main where main :: IO () main = do let n = 100 :: Int print $ sum (take n $ test 1 [1,2..]) test :: Int - [Int] - [Int] test t g = let (n, g') = next t g in n:test t g' next :: Int - [Int] - (Int, [Int]) next x (y:ys) = let n = func y in if n = 0.5 then (x, ys) else (0, ys) where func x = fromIntegral x / (10 ^ len x) where len 0 = 0 len n = 1 + len (n `div` 10) On my computer this takes 4 seconds to run. I can speed it up by an order of magnitude by writing code that is friendlier to the compiler: module Main where main :: IO () main = do let n = 100 :: Int print $ sum (take n $ test 1 [1,2..]) test :: Int - [Int] - [Int] test t g = map f g where f :: Int - Int f y = if func y = 0.5 then t else 0 func :: Int - Double func x = fromIntegral x / mypow x mypow 0 = 1 mypow n = 10*(mypow (n `div` 10)) Switching to map and simplifying the structure gained me 30% or so, but the big improvement came from the elimination of the use of (^) by writing mypow (ill-named). I have no idea if this example will help your actual code, but it illustrates that at least in this example, it's pretty easy to gain an order of magnitude in speed. (That func is a weird function, by the way.) Incidentally, implementing the same program in C, I get: #include stdio.h int test(int, int); double func(int); int mypow(int); int mypow(int n) { double result = 1; while (n0) { result *= 10; n /= 10; } return result; } double func(int x) { return x / (double) mypow(x); } int test(int t, int y) { if (func(y) = 0.5) { return t; } else { return 0; } } int main() { int i; int sum = 0; for (i=0;i100;i++) { sum += test(1,i); } printf(sum is %d\n, sum); return 0; } Which runs more than 10 times faster than my Haskell version, so there's obviously still a lot of room for optimization. :( Incidentally, a version written in C that uses pow for the 10^(len n) runs in only half the time of my haskell version (five time the time of the C version I give)--confirming that pow is indeed a very expensive operation (as I already knew) and that if you call the pow function it *ought* to dominate your timing. But we've also still clearly got some seriously painful loop overhead. :( -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Claus Reinke wrote: if this is the official interpretation of cabal package version numbers, could it please be made explicit in a prominent position in the cabal docs? Yes - I think it would be a good idea to make that convention explicit somewhere (I'm sure we've talked about it in the past, but I can't remember what happened if anything). However, I'd like to separate it from Cabal. Cabal provides mechanism not policy, regarding version numbers. of course, i have absolutely no idea how to write stable packages under this interpretation. and the examples in the cabal docs do not explain this, either (neither bar nor foo 1.2 are any good under this interpretation). base = 2.0 3.0 I believe Cabal is getting (or has got?) some new syntax to make this simpler. why do you omit the most popular (because most obvious to users) option? - if base remains what it is and a new package is created providing the rest of base after the split, then every user is happy (that it is currently hard to implement this by reexporting the split packages as base is no excuse) Omitted only because it isn't implemented. Well, it is implemented, on my laptop, but I'm not happy with the design yet. In the design we've chosen, some packages continue to work without change. Specifying a dependency on a package without giving an explicit version range is a bet: sometimes it wins, sometimes it doesn't. The nice thing is that we have most of our packages in one place, so we can easily test which ones are broken and notify the maintainers and/or fix them. sorry, i don't want to turn package management into a betting system. and i don't see how knowing how much is broken (so cabal can now only work with central hackage?) is any better than avoiding such breakage in the first place. cabal is fairly new and still under development, so there is no need to build in assumptions that are sure to cause grief later (and indeed are doing so already). what assumptions does Cabal build in? Yes I know we've changed other names - very little in packaging is clear-cut. how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. Using the version number convention mentioned earlier, base-1.0 funcionality is provided by base-1.0.* only. A package can already specify that explicitly. I think what you're asking for is more than that: you want us to provide base-1.0, base-2.0 and base-3.0 at the same time, so that old packages continue to work without needing to be updated. That is possible, but much more work for the maintainer. Ultimately when things settle down it might make sense to do this kind of thing, but right now I think an easier approach is to just fix packages when dependencies change, and to identify sets of mutually-compatible packages (we've talked about doing this on Hackage before). Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] How to thoroughly clean up Haskell stuff on linux
Thanks for all the feedback. I removed GHC 6.4 and re-installed 6.6.1 and was able to install Haddock and other things in a few seconds. It seems that the GOA and Lambdabot complicated the environment under the hook, I will just leave them alone for now. Life is too short (and haskell has enough other complications) to be installing stuff from source :) Indeed, I don't want to waste time but have no choice (rpm needs root), and in today's world, software should be built by simply config,build,install. Maybe in the academic world, people always have their own machines and root access, but this is not true for people living on ISP accounts (and corporate world too) where root access is restricted. Consider that Haskell is not a mainstream software like perl or java, it is hard to ask sysadmin to put it under root. I was exploring Haskell website and finding more and more things I need to install. The time to figure out how to build each one of them is too much (consider I am a fluent IT software builder). I am wondering why Haskell community does not pacakge a full package that includes ghc, haddock, happy, alex, darcs, cabal, etc... Things that a typical developer will bump into eventually. I understand that putting two large compilers (ghc+hugs) may take a lot space, but for smaller utilities, it would be nice if they are included (if there is no unwelcomed side effect). Steve -Original Message- From: Stefan O'Rear [mailto:[EMAIL PROTECTED] Sent: Friday, October 12, 2007 11:04 PM To: Brandon S. Allbery KF8NH Cc: Lihn, Steve; Haskell-Cafe Haskell-Cafe Subject: Re: [Haskell-cafe] How to thoroughly clean up Haskell stuff on linux On Fri, Oct 12, 2007 at 07:31:45PM -0400, Brandon S. Allbery KF8NH wrote: I don't think haddock has to depend on lamdbabot. But I saw Skipping HaddockHoogle during the build. Isn't the Hoogle thing related to Lambdabot? Or they are unrelated. Only insofar has Lambdabot has an interface to Hoogle (which IIRC depends on Haddock knowing how to build Hoogle indexes, which is what that segment is about). Haddock doesn't build the Hoogle stuff by default, IIRC. Besides, Skipping foo is GHC-ese for foo is already up to date, not wasting time... Stefan -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Java - Haskell adjustment
Ryan Bloor wrote: Hi, its Ryan here... I've just come from an intensive course in java and have been thrown into the imperative world of haskell. The problem that I have is extremely simple in java but I am having trouble adjusting my old mindset. A multiset is a collection of items. Each item may occur one or more times in the multiset. All items are of the same type. The scenario we could use is a students' grades for their A levels: 3A, 4B and 2C grades for our pupil 'x'. A multiset may be implemented by a list... so ['A', 'A', 'A', 'B', 'B', 'B', 'B, 'C', 'C'] but this very ineffiecient and tedious. How might one set out into putting this into action thanks... Why do you think a list is inefficient and tedious? It sounds fine for this simple application. If you have complexity constraints which rule a list out, then consider Data.Sequence. Actually Data.Sequence has a very similar API to the programmer; you will feel much like you're using List, but it is faster for certain things. (most things, in fact). Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Java - Haskell adjustment
On Mon, Oct 15, 2007 at 03:49:44PM +0100, Ryan Bloor wrote: Hi, its Ryan here... I've just come from an intensive course in java and have been thrown into the imperative world of haskell. The problem that I have is extremely simple in java but I am having trouble adjusting my old mindset. A multiset is a collection of items. Each item may occur one or more times in the multiset. All items are of the same type. The scenario we could use is a students' grades for their A levels: 3A, 4B and 2C grades for our pupil 'x'. A multiset may be implemented by a list... so ['A', 'A', 'A', 'B', 'B', 'B', 'B, 'C', 'C'] but this very ineffiecient and tedious. You might try, for example, rle encoding : [(3, 'A'), (4, 'B'), (2, 'C')]. Don't know if this would be more efficient for your task, but if you wish to 'just optimize something' you can give that a try. How might one set out into putting this into action thanks... Any help that complements my ideas is welcome _ Feel like a local wherever you go. http://www.backofmyhand.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- pierre ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Java - Haskell adjustment
On Mon, 15 Oct 2007, Ryan Bloor wrote: Hi, its Ryan here... I've just come from an intensive course in java and have been thrown into the imperative world of haskell. The problem that I have is extremely simple in java but I am having trouble adjusting my old mindset. A multiset is a collection of items. Each item may occur one or more times in the multiset. All items are of the same type. The scenario we could use is a students' grades for their A levels: 3A, 4B and 2C grades for our pupil 'x'. A multiset may be implemented by a list... so ['A', 'A', 'A', 'B', 'B', 'B', 'B, 'C', 'C'] but this very ineffiecient and tedious. You might model it using Map Char Int which maps each multiset element to its multiplicity. Maybe 'Char' is not the appropriate type, but an enumeration? data Grade = A | B | C | D | E deriving (Show, Eq, Ord) then use 'Map Grade Int' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hosting of Haskell project
Magnus Therning wrote: On the other hand Redmine does look cleaner somehow and I've never seen a trac site that is as easy to find my way around as www.redmine.org. That site loads slowly for me in Firefox (loading several files per page, perhaps?). In some page's source on that site, it claims to be XHTML, and it puts some Javascript code inside an XML comment, which is stupid. Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] do
Yes indeed, Concurrent Clean actually just passes around the world object in direct/explicit style but uses uniquness typing to make sure nothing happens that would violate the nice FP paradigm (mainly referential transparency?). That is, I think it's like that :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brandon S. Allbery KF8NH Sent: Monday, October 15, 2007 3:49 PM To: [EMAIL PROTECTED] Cc: haskell-cafe Cafe Subject: Re: [Haskell-cafe] do On Oct 15, 2007, at 7:02 , [EMAIL PROTECTED] wrote: IO is different, you *cannot* make it non-monadic. Not really true; it's just much more painful. You just e.g. explicitly do what the ghc library's implementation of IO does: construct a chain of functions with an opaque (and optionally(?) existential to enforce the opacity) RealWorld type which is passed as state from one invocation to the next, with the top level application partially applied. Or one of the operationally equivalent tricks used by other Haskell runtime implementations, cf. IO Inside. It's not so much hard as it is far too much busywork for a programmer to want to deal with when programming... hence hiding the scaffolding in the type, which is perhaps the most general description of what a Haskell monad actually is. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
Peter Verswyvelen writes, about non-monadic IO, after the posting of Brandon S. Allbery, who reacted to my claim that IO Monad is unavoidable: Not really true; it's just much more painful. You just e.g. explicitly do what the ghc library's implementation of IO does: construct a chain of functions with an opaque (and optionally(?) existential to enforce the opacity) RealWorld type which is passed as state from one invocation to the next, with the top level application partially applied. P.V.: Yes indeed, Concurrent Clean actually just passes around the world object in direct/explicit style but uses uniquness typing to make sure nothing happens that would violate the nice FP paradigm (mainly referential transparency?). That is, I think it's like that :) Well, I think I am one of not-so-numerous people on this list who use Clean. (After all, it is the competitor... We might forget about the buzzword Concurrent...) So, I know about unique *World, *FileSystem, *File, etc., I have used it for graphics and for generation of sound. But I didn't find a way to use *really* this awful State# RealWorld in Haskell! Somebody can show me some working examples? Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Haskell Selenium bindings, version 0.2.1
Hi, I'm pleased to announce the first external release of a set of Haskell bindings for the Selenium automated web testing system (specifically, the Selenium Remote Control). These bindings make it possible to use Haskell to write test scripts that automatically exercise arbitrary web sites by controlling a web browser. More information on Selenium is available here: http://www.openqa.org/ You can get the tagged release from Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ selenium-0.2.1 Or you can keep up with the development version from darcs (which currently has no changes from 0.2.1): darcs get http://code.haskell.org/selenium Many thanks to Don Stewart for code and design contributions. Aaron ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
Peter Verswyvelen writes about non-monadic IO, unique external worlds: But... isn't this what the Haskell compiler runtime do internally when IO monads are executed? Passing the RealWorld singleton from action to action? I never looked into any Haskell compiler. Chalmers, or York, don't remember, used continuations, this seems a bit different from the Clean approach, but I don't really know the gory details. To me, no real difference exists between IO monads and Clean's uniques types; it's just a different approach to tackle the same problem. Yes, *different approach*. So, there *are* differences. Compilers, anyway, are special applications. I wanted to see - responding to Brandon - a normal Haskell program, which does IO without monads, that't all. The problem is then when you hide something, you hide. It is possible to superpose a kind of monadic framework on unique worlds, files, etc. in Clean, but the reverse operation goes beyond my horizons. Some examples, anybody? Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
[EMAIL PROTECTED] wrote: Yes, *different approach*. So, there *are* differences. Compilers, anyway, are special applications. I wanted to see - responding to Brandon - a normal Haskell program, which does IO without monads, that't all. The problem is then when you hide something, you hide. It is possible to superpose a kind of monadic framework on unique worlds, files, etc. in Clean, but the reverse operation goes beyond my horizons. Some examples, anybody? Jerzy Karczmarczuk Ah yes, I see what you mean now. I have no idea, I guess only unsafePerformIO will allow you to do something like that... But that will completely break referential transparency. But I really don't know. What do the experts have to say? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
And Haskell embedded a logical programming language on accident. On 10/15/07, Manuel M T Chakravarty [EMAIL PROTECTED] wrote: Dan Piponi wrote, On 10/12/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: He wants to write entire programs in the type system, something like the crazies who write programs in C++ templates such that template expansion does all the work at compile time Crazies? :-) http://homepage.mac.com/sigfpe/Computing/peano.html Having switched from C++ to Haskell (at least in my spare time) I thought I'd escaped that kind of type hackery but it seems to be following me... The way I see, we are trying to come up with a clean way of providing type-level computations (ie, we use and extend the standard theory of HM type systems). C++ embedded a functional language in the type systems mostly by accident, whereas we do it on purpose. Manuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HSSDL (was Pixel Plotter)
I tried this library on Win32. A very nice initiative indeed. Currently, I found the following problems: - as mentioned in the WIN32 readme file, the library does not seem to work with GHCI. Firstly, it seems to look for incorrect DLLs. When I copy SDL.DLL to both SDLmain.DLL and SDL.DLL.DLL, then GHCI starts the Test app, but it hangs as soon as the window is displayed. This behavior is similar to what I initially had with SOE/Gtk, but that got fixed in the latest release of Gtk2HS. Maybe the author of Gtk2HS (Duncan?) and HSSDL (lemmih) could exchange information on how to get it running under GHCI? - the documentation contains links to non-existing files. I had to rename Graphics.IO.SDL.name.html to Graphics-IO-SDL-name.html, then the docs worked. Cheers, Peter Verswyvelen Luke Palmer wrote: YEEESSS!! W00t11 I've been looking for that for a long time. I get so sick of glut... Thanks. Luke On 10/14/07, Roel van Dijk [EMAIL PROTECTED] wrote: I say someone binds SDL[1]. (If it hasn't been done already.) Ask and you shall receive: http://darcs.haskell.org/~lemmih/hsSDL/ I use those SDL bindings to plot pixels with OpenGL and play with 3D stuff in Haskell. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
On Oct 15, 2007, at 13:32 , Peter Verswyvelen wrote: [EMAIL PROTECTED] wrote: Yes, *different approach*. So, there *are* differences. Compilers, anyway, are special applications. I wanted to see - responding to Brandon - a normal Haskell program, which does IO without monads, that't all. The problem is then when you hide something, you hide. It is possible to superpose a kind of monadic framework on unique worlds, files, etc. in Clean, but the reverse operation goes beyond my horizons. Some examples, anybody? Ah yes, I see what you mean now. I have no idea, I guess only unsafePerformIO will allow you to do something like that... But that will completely break referential transparency. But I really don't know. What do the experts have to say? Use the source of unsafePerformIO as an example of how to write code which passes around RealWorld explicitly, but without unencapsulating it like unsafePerformIO does. The main problem here, I think, is that because all the GHC runtime's functions that interact with RealWorld (aside from unsafe*IO) are themselves only exported wrapped up in IO, you can't (as far as I know) get at the lower level internal (e.g.) putStrLn' :: RealWorld - String - (# RealWorld,() #) to do I/O in a direct/explicit/non- monadic style. In theory, one could export those and use them directly. (Actually, as a practical matter, IIRC GHC knows about RealWorld and removes all of it when generating cmm code once it's done the job of sequencing Haskell evaluation; I'm not sure how well that would work if you wrote I/O in direct/explicit style. unsafePerformIO doesn't really count for that because it removes the RealWorld itself.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: do
[EMAIL PROTECTED] wrote: Peter Verswyvelen writes about non-monadic IO, unique external worlds: But... isn't this what the Haskell compiler runtime do internally when IO monads are executed? Passing the RealWorld singleton from action to action? In GHC, yes. I never looked into any Haskell compiler. Chalmers, or York, don't remember, used continuations, this seems a bit different from the Clean approach, but I don't really know the gory details. To me, no real difference exists between IO monads and Clean's uniques types; it's just a different approach to tackle the same problem. Yes, *different approach*. So, there *are* differences. Compilers, anyway, are special applications. I wanted to see - responding to Brandon - a normal Haskell program, which does IO without monads, that't all. The problem is then when you hide something, you hide. It is possible to superpose a kind of monadic framework on unique worlds, files, etc. in Clean, but the reverse operation goes beyond my horizons. Some examples, anybody? Jerzy Karczmarczuk I don't have examples, but I can show you where the gory details are hiding: The Haskell 98 standard specifies the API for input/output to be using the IO monad. If you want to use Haskell 98 to do input/output without the IO monad then you will find that you cannot do so. I see three ways to go around Haskell98. Common caveat: The thing that using the provided IO monad does is provide a standard way of sequencing two input/output operations. Once you avoid that sequencing then you indeterminism unless you provide your own sequencing manually. The first, which you may decide does not really count, is using unsafePerformIO or unsafeInterleaveIO and avoiding the sequencing provided by the IO monad. This still does nothing to tell you about the gory details. As a cheat: If you use the FFI addendum then you can access all the impure c input/output functions and lie about their type so that are not in IO. Then you could manually manage their sequencing and control everything. This comes closer to understanding how the standard IO operations are implemented in the gory details. For the GHC implementation of Haskell it is possible to go inside the IO monad and operate using the same gory details that GHC uses. This is probably what you want to see, but note that it is not the only compiler or the only way to do this. The details are in the source at http://darcs.haskell.org/ghc-6.6/packages/base/GHC/ in IOBase.lhs and IO.hs and so on... From IOBase.lhs I see that GHC uses a newtype around a function of type State b - (State b, a) to represent IO a. The State b is actually an unboxed type State# RealWorld. The tuple is likewise an unboxed (# , #) tuple. newtype IO a = IO (State# RealWorld - (# State# RealWorld, a #)) unIO :: IO a - (State# RealWorld - (# State# RealWorld, a #)) unIO (IO a) = a Also in IOBase.lhs this is made into a Functor and, inevitably, a monad: instance Functor IO where fmap f x = x = (return . f) instance Monad IO where {-# INLINE return #-} {-# INLINE () #-} {-# INLINE (=) #-} m k = m = \ _ - k return x = returnIO x m = k = bindIO m k fail s= failIO s returnIO :: a - IO a returnIO x = IO (\ s - (# s, x #)) bindIO :: IO a - (a - IO b) - IO b bindIO (IO m) k = IO ( \ s - case m s of (# new_s, a #) - unIO (k a) new_s ) failIO :: String - IO a failIO s = ioError (userError s) -- | Raise an 'IOError' in the 'IO' monad. ioError :: IOError - IO a ioError = ioException ioException :: IOException - IO a ioException err = IO $ raiseIO# (IOException err) Where raiseIO# is from GHC.Prim http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-Prim.html http://darcs.haskell.org/ghc/compiler/prelude/primops.txt.pp ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Laziness (was: [Haskell-cafe] Performance problem with random numbers)
On Mon, 2007-10-15 at 10:48 -0400, David Roundy wrote: I have no idea if this example will help your actual code, but it illustrates that at least in this example, it's pretty easy to gain an order of magnitude in speed. (That func is a weird function, by the way.) Thanks for your reply David, Unfortunately my original problem was that System.Random.{random, randomR} is used instead of all these weird test functions that I came up with during experimentation. And I can't force anything inside StdGen so I see no way of speeding up the original program sans replacing the random number generator itself. When I did that I became about 4 times faster than with System.Random but still an order of magnitude slower than for instance by using the Java implementation (and I can confirm that (^) is *very* expensive in this context). Many thanks again, Thoralf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
You need a way to specify foo 1.2 foo 2, which is a suggestion that was tossed around here recently. but what does such a version range say? that i haven't tested any versions outside the range (because they didn't exist when i wrote my package)? or that i have, and know that later versions won't do? Also, you'd need foo 1.x for x=2 to be available after foo-2.0 arrives. indeed. available, and selectable. so the package manager needs to be able to tell which package versions can be used to fulfill which dependencies. if that decision is based on version numbers alone, we need to be specific about the meaning of version numbers in dependencies. and if the major/minor scheme is to be interpreted as Simon summarised, the only acceptable form of a dependency is an explicit version range (the range of versions known to work). which means that package descriptions have to be revisited (manually) and updated (after inspection) as time goes on. so we seem to be stuck with a choice between breaking packages randomly (because version numbers were too imprecise to prevent breakage accross dependency updates) or having packages unable to compile (because version numbers were needlessly conservative, and newer dependencies that may be acceptable in practice are not listed). neither option sounds promising to me (instead of the package manager managing, it only keeps a record while i have to do the work), so i wonder why everyone else claims to be happy with the status quo? 'base' aside, I don't think we want a system that requires us to rename a library any time incompatible changes are introduced. i was talking only about the base split, as far as renaming is concerned. but i still don't think the interpretations and conventions of general haskell package versioning have been pinned down sufficiently. and i still see lots of issues in current practice, even after assuming some common standards. The major/minor scheme has worked nicely for .so for ages. i'm not so sure about that. it may be better than alternatives, but it includes standards of common practice, interpretation, and workarounds (keep several versions of a package, have several possible locations for packages, renumber packages to bridge gaps or to fake unavailable versions, re-export functionality from specific package versions as generic ones, ...). and i don't think cabal packages offer all the necessary workarounds, even though they face all the same issues. how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. base-not-1.0 would know that it doesn't do that. and if there is no single package that reexports the functionality of base-1.0, cabal could even try to consult multiple packages to make ends meet Scrap cabal in favor of 'ghc --make'? :-) ultimately, perhaps that is something to aim for. i was thinking of a simpler form, though, just liberating the provider side a bit: - currently, every package provides it's own version only; it is the dependent's duty to figure out which providers may or may not be suitable; this introduces a lot of extra work, and means that no package is ever stable - even if nothing in the package changes, you'll have to keep checking and updating the dependencies! - instead, i suggest that every package can stand for a range of versions, listing all those versions it is compatible with; that way, the dependent only needs to specify one version, and it becomes the provider's duty to check and specify which api uses it is compatible with (for instance, if a package goes through several versions because of added features, it will still be useable with its initial, limited api). of course, if you refine that simple idea, you get to typed interfaces as formally checkable specifications of apis (as in the ML's, for instance). and then you'd need something like 'ghc --make' or 'ghc -M' to figure out the precise interface a package depends on, and to provide a static guarantee that some collection of packages will provide those dependencies. Seriously though, how hard would it be to automatically generate a (suggested) build-depends from ghc --make? i'd like to see that, probably from within ghci. currently, you'd have to load your project's main module, then capture the 'loading package ...' lines. there is a patch pending for ghci head which would give us a ':show packages' command. claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
but the name that is everywhere does not stand for what the new version provides! any place that is currently referring to 'base' will have to be inspected to check whether it will or will not work with the reduced base package. and any place that is known to work with the new base package might as well make that clear, by using a different name. base changed its API between 2.0 and 3.0, that's all. The only difference between what happened to the base package between 2.0 and 3.0 and other packages is the size of the changes. In fact, base 3.0 provides about 80% the same API as version 2.0. so it is not just an api extension, nor an api modification with auxiliary definitions to preserve backwards api compatibility, nor a deprecation warning for api features that may disappear in the distant future; it is an api shrinkage - features that used to be available from dependency 'base' no longer are. and it isn't just any package, it is 'base'! the decision to make the difference visible in package names was made when subpackages were created from the old base. if cabal can handle multiple versions of base coexisting, and can guess which version was meant when someone wrote 'base', then no renaming is necessary. but if cabal can't handle that (yet), then renaming might be a workaround, to avoid more trouble. if ghc told me that expected type 'base' doesn't match inferred type 'base', i'd file a bug report. why do we throw out such standards when grouping modules into packages? Exactly what percentage change should in your opinion require changing the name of the package rather than just changing its version number? Neither 0% nor 100% are good choices... packaging is rarely clear-cut! then we should ask: why not? it seems to be a standard type system problem: either we have no subtyping, then the types/versions/apis must match precisely, however inconvenient that might be, or we have subtyping, then we need to define what we want it to mean that one package version may be used instead of another. just having names and numbers and schemes that give no guarantees that matches imply compatibility is no solution. i don't want a package manager that tells me: congratulations! your package is 88.745% likely to be buildable, it provides between 45% and 95% of the features your package spec promises (since all promises are informal, no precise validation is possible, but most users should be happy), provided that our dependencies really do provide all the features we depend on (i have no idea what those features might be). go ahead and publish it. let others clean up the mess. oh, and remember to come back every couple of months or so to clean up the mess made by those providing your package's dependencies.. of course, cabal doesn't even tell me that. it lets me publish anything (shouldn't there be a './Setup check' to validate? or is there?) and only gets involved when people try to build what i published, usually months later, when anything might happen (depending on how good my package spec was, and on what happened to the dependencies in the meantime), followed by someone chasing me, then me chasing someone else, or someone giving up. is this too bleak a view?-) claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
However, I'd like to separate it from Cabal. Cabal provides mechanism not policy, regarding version numbers. but the examples in the cabal docs should reflect the standard interpretation of version numbers. of course, i have absolutely no idea how to write stable packages under this interpretation. and the examples in the cabal docs do not explain this, either (neither bar nor foo 1.2 are any good under this interpretation). base = 2.0 3.0 that only works if older versions of base are kept side by side with base = 3.0. otherwise, any package with that range will refuse to build (which may be better than failing to build), even though nothing in that package has changed, and all the features it depends on are still available. Omitted only because it isn't implemented. Well, it is implemented, on my laptop, but I'm not happy with the design yet. i look forward to hearing more. here, you say you are working on an implementation; earlier, you said that re-exporting modules via several packages was not the way forward. cabal is fairly new and still under development, so there is no need to build in assumptions that are sure to cause grief later (and indeed are doing so already). what assumptions does Cabal build in? its documentation is not very precise about what version numbers mean. going by the examples, i thought that 'base' was an acceptable dependency, but it isn't. i also assumed that lower bounds (foo 1.2) could be relied on, but they can't. perhaps i'm the only one reading the cabal docs this way, but i feel mislead!-) and even if i translate your versioning scheme into cabal dependencies, i end up with explicit version ranges as the only valid option, so the assumption becomes that every package *will* break as its dependencies move on. how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. Using the version number convention mentioned earlier, base-1.0 funcionality is provided by base-1.0.* only. A package can already specify that explicitly. not entirely correct. you said that major versions implied api changes. that does not imply that the api is no longer backwards compatible, only that there are sufficiently substantial new features that a version naming them seems called for. while base breaks backwards compatibility, other packages might not do so. and cabal does not allow me to specify anything but a name and a range of numbers as dependencies (there is exposed-modules:, but no imported-modules:), so i can't say which parts of base-1.0 my package depends on, and cabal can't decide which versions of base might be compatible with those more specific dependencies. I think what you're asking for is more than that: you want us to provide base-1.0, base-2.0 and base-3.0 at the same time, so that old packages continue to work without needing to be updated. That is possible, but much more work for the maintainer. Ultimately when things settle down it might make sense to do this kind of thing, but right now I think an easier approach is to just fix packages when dependencies change, and to identify sets of mutually-compatible packages (we've talked about doing this on Hackage before). yes. it's called automatic memory management!-) as long as there's a package X depending on package Y-a.b, package Y-a.b should not disappear. not having to waste time on such issues is one reason why programmers are supposed to prefer haskell over non-functional languages, right?-) claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Equality Question
Hi is const = id? const 'x' 'y' 'x' id 'x' 'x' Cheers, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Equality Question
On 10/15/07, PR Stanley [EMAIL PROTECTED] wrote: Hi is const = id? You answered the question yourself const 'x' 'y' 'x' id 'x' 'x' const has another parameter. Their types are id:: a - a const :: a - b - a HTH, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Equality Question
PR Stanley wrote: is const = id? No, const is saturated with 2 arguments, id with 1. const 1 2 - 1 id 1 2 - type error b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: do
Brandon S. Allbery KF8NH wrote: On Oct 15, 2007, at 13:32 , Peter Verswyvelen wrote: [EMAIL PROTECTED] wrote: Yes, *different approach*. So, there *are* differences. Compilers, anyway, are special applications. I wanted to see - responding to Brandon - a normal Haskell program, which does IO without monads, that't all. The problem is then when you hide something, you hide. It is possible to superpose a kind of monadic framework on unique worlds, files, etc. in Clean, but the reverse operation goes beyond my horizons. Some examples, anybody? Ah yes, I see what you mean now. I have no idea, I guess only unsafePerformIO will allow you to do something like that... But that will completely break referential transparency. But I really don't know. What do the experts have to say? Use the source of unsafePerformIO as an example of how to write code which passes around RealWorld explicitly, but without unencapsulating it like unsafePerformIO does. The main problem here, I think, is that because all the GHC runtime's functions that interact with RealWorld (aside from unsafe*IO) are themselves only exported wrapped up in IO, you can't (as far as I know) get at the lower level internal (e.g.) putStrLn' :: RealWorld - String - (# RealWorld,() #) to do I/O in a direct/explicit/non-monadic style. In theory, one could export those and use them directly. Well, if you import GHC.IOBase then you get newtype IO a = IO (State# RealWorld - (# State# RealWorld, a #)) unIO :: IO a - (State# RealWorld - (# State# RealWorld, a #)) unIO (IO a) = a Then the type of putStrLn: -- putStrLn :: String - IO () means that putStrLn' can be defined as putStrLn' :: String - State# RealWorld - (# State# RealWorld, a #) putStrLn' = unIO . putStrLn Now you have the unboxed tuple and need to work with many 'case' statements to accomplish anything. Also you need to get you hand on State# RealWorld either (1) Honestly, by wrapping your code in IO again and using it normally (2) From a copy, via unsafeInterleaveIO (3) From nowhere, via unsafePerformIO (Actually, as a practical matter, IIRC GHC knows about RealWorld and removes all of it when generating cmm code once it's done the job of sequencing Haskell evaluation; I'm not sure how well that would work if you wrote I/O in direct/explicit style. unsafePerformIO doesn't really count for that because it removes the RealWorld itself.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: do
On Oct 15, 2007, at 19:00 , ChrisK wrote: Brandon S. Allbery KF8NH wrote: Use the source of unsafePerformIO as an example of how to write code which passes around RealWorld explicitly, but without unencapsulating it like unsafePerformIO does. The main problem here, I think, is that because all the GHC runtime's functions that interact with RealWorld (aside from unsafe*IO) are themselves only exported wrapped up in IO, you can't (as far as I know) get at the lower level internal (e.g.) putStrLn' :: RealWorld - String - (# RealWorld,() #) to do I/O in a direct/explicit/non-monadic style. In theory, one could export those and use them directly. Well, if you import GHC.IOBase then you get newtype IO a = IO (State# RealWorld - (# State# RealWorld, a #)) unIO :: IO a - (State# RealWorld - (# State# RealWorld, a #)) unIO (IO a) = a Then the type of putStrLn: -- putStrLn :: String - IO () means that putStrLn' can be defined as putStrLn' :: String - State# RealWorld - (# State# RealWorld, a #) putStrLn' = unIO . putStrLn Now you have the unboxed tuple and need to work with many 'case' statements to accomplish anything. Also you need to get you hand on State# RealWorld either (1) Honestly, by wrapping your code in IO again and using it normally (2) From a copy, via unsafeInterleaveIO (3) From nowhere, via unsafePerformIO (4) Honestly but unwrapped, by defining main in the same desugared way (takes State# RealWorld and returns (# State# RealWorld,a #) (or (# State# RealWorld,() #) if you stick to the H98 definition of main's type), allowing the runtime to pass it in and otherwise not doing anything other than propagating it. My real problem was that I incorrectly recalled IO's type to be based on ST, not State (i.e. had a forall to prevent anything from being able to do anything to/with the State# RealWorld other than pass it on unchanged without triggering a type error). I should have realized that was wrong because unsafePerformIO is itself expressible in Haskell (-fglasgow-exts is needed to make # an identifier character and to enable unboxed types and unboxed tuples, but does not make it possible to cross an existential type barrier). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Help parsing dates and times
I am trying to parse various date and time formats using the parseTime function found in (GHC 6.6.1) Data.Time.Format. The one that is giving me trouble looks like this: 2008-06-26T11:00:00.000-07:00 Specifically, the time zone offset isn't covered by the format parameters given. I can almost parse it with this: %FT%X.000 But that doesn't take into account the -07:00 bit. I'm sure this has been solved - can someone point me to the solution? Thanks in advance. Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell libraries for computer vision
http://alberrto.googlepages.com/easyvision An experimental Haskell system for fast prototyping of computer vision and image processing applications. Looks ridiculously cool. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help parsing dates and times
jgbailey: I am trying to parse various date and time formats using the parseTime function found in (GHC 6.6.1) Data.Time.Format. The one that is giving me trouble looks like this: 2008-06-26T11:00:00.000-07:00 Specifically, the time zone offset isn't covered by the format parameters given. I can almost parse it with this: %FT%X.000 But that doesn't take into account the -07:00 bit. I'm sure this has been solved - can someone point me to the solution? Thanks in advance. Is there anything in the parsedate library? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/parsedate-2006.11.10 http://hackage.haskell.org/packages/archive/parsedate/2006.11.10/doc/html/System-Time-Parse.html -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
Lennart Augustsson wrote, And Haskell embedded a logical programming language on accident. Well, we are just trying to fix that :) On 10/15/07, *Manuel M T Chakravarty* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Dan Piponi wrote, On 10/12/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: He wants to write entire programs in the type system, something like the crazies who write programs in C++ templates such that template expansion does all the work at compile time Crazies? :-) http://homepage.mac.com/sigfpe/Computing/peano.html Having switched from C++ to Haskell (at least in my spare time) I thought I'd escaped that kind of type hackery but it seems to be following me... The way I see, we are trying to come up with a clean way of providing type-level computations (ie, we use and extend the standard theory of HM type systems). C++ embedded a functional language in the type systems mostly by accident, whereas we do it on purpose. Manuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: do
On 10/15/07, ChrisK [EMAIL PROTECTED] wrote: Also you need to get you hand on State# RealWorld either (1) Honestly, by wrapping your code in IO again and using it normally (2) From a copy, via unsafeInterleaveIO (3) From nowhere, via unsafePerformIO Or you can get it honestly via lifting: liftRawIO :: (State# RealWorld - (# State# RealWorld, a #)) - IO a liftRawIO = GHC.IOBase.IO main = liftRawIO rawMain rawMain :: State# RealWorld- (# State# RealWorld, () #) {- implement rawMain here -} -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: do
Oops, I read too fast, you mentioned that as #1. On 10/15/07, ChrisK [EMAIL PROTECTED] wrote: Also you need to get you hand on State# RealWorld either (1) Honestly, by wrapping your code in IO again and using it normally Silly me. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] System.Posix
Hello, In a Hugs environment, I am able to import System.Directory but not to import System.Posix. Here is my environment ... .;{Hugs}\packages\*;C:\ftp\CatTheory\Haskell\SOE\graphics\lib\win32\*. I really want to use the Posix module. Help!!! Kind regards, Bill Halchin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
On Tuesday 16 October 2007 11:45, Claus Reinke wrote: how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. Using the version number convention mentioned earlier, base-1.0 funcionality is provided by base-1.0.* only. A package can already specify that explicitly. not entirely correct. you said that major versions implied api changes. that does not imply that the api is no longer backwards compatible, only that there are sufficiently substantial new features that a version naming them seems called for. while base breaks backwards compatibility, other packages might not do so. and cabal does not allow me to specify anything but a name and a range of numbers as dependencies (there is exposed-modules:, but no imported-modules:), so i can't say which parts of base-1.0 my package depends on, and cabal can't decide which versions of base might be compatible with those more specific dependencies. I've been giving only cursory attention to this thread so I might have the wrong end of the stick, or indeed the entirely wrong shrub. If the convention for modifying package versions of form x.y.z is: - increment z for bugfixes/changes that don't alter the interface - increment y for changes that consist solely of additions to the interface, parts of the interface may be marked as deprecated - increment x for changes that include removal of deprecated parts of the interface - (optionally) x == 0 = no guarantee and package maintainers are rigorous in following these rules then specifying dependencies as foo-x, foo-x.y, foo-x.y.z should be sufficient. This rigour could largely be enforced by hackage or an automated build system. foo-x is a shortcut for foo-x.0.0 foo-x.y is a shortcut for foo-x.y.0 foo-x.y.z is satisfied by any foo-i.j.k where i=x, j.k=y.z The 'foo' package name is just an indicator of lineage. foo-2.xxx is not the same package as foo-1.xxx, it's interface is missing something that foo-1.xxx's interface provided. Dependencies of foo shouldn't appear in published cabal files. There is a case for their use in development where you are specifying that you want to depend on the very latest version of foo available, perhaps from darcs. When you publish that latest version number gets burned in, eg foo-2.1.20071016. As for provides/expects and imported-modules instead, isn't that just an arbitrary line drawn in the granularity sand? Perhaps package versions could be expanded to include the type of every function they expose, plus more information to indicate which bugfix version of those functions is present. That's maybe the Right Way... and probably a lot of work. A more convenient place to draw the line seems to be at the package level. I think what you're asking for is more than that: you want us to provide base-1.0, base-2.0 and base-3.0 at the same time, so that old packages continue to work without needing to be updated. That is possible, but much more work for the maintainer. Ultimately when things settle down it might make sense to do this kind of thing, but right now I think an easier approach is to just fix packages when dependencies change, and to identify sets of mutually-compatible packages (we've talked about doing this on Hackage before). yes. it's called automatic memory management!-) as long as there's a package X depending on package Y-a.b, package Y-a.b should not disappear. not having to waste time on such issues is one reason why programmers are supposed to prefer haskell over non-functional languages, right?-) I think it's a no-brainer that old versions of packages should remain available for people to use for 'a long time'. If their dependencies are specified properly they should continue building successfully as time passes. Isn't the main problem the use of foo dependencies and the resulting version guessing/ambiguity? Presumably it's not usually a problem if indirect package dependencies require incompatible versions of a package. Is this a problem with base because it implicitly has a dependency on a particular version of the GHC internals? Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
On Mon, Oct 15, 2007 at 10:57:48PM +0100, Claus Reinke wrote: so i wonder why everyone else claims to be happy with the status quo? We aren't happy with the status quo. Rather, we know that no matter how much we do, the situation will never improve, so most of us have stopped wasting out time. Furthermore, we know that people who DO offer alternatives instantly lose all public credibility - look at what happened to Alex Jacobson. Stefan (who will readily admit his bleak outlook) signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
stefanor: On Mon, Oct 15, 2007 at 10:57:48PM +0100, Claus Reinke wrote: so i wonder why everyone else claims to be happy with the status quo? We aren't happy with the status quo. Rather, we know that no matter how much we do, the situation will never improve, so most of us have stopped wasting out time. Furthermore, we know that people who DO offer alternatives instantly lose all public credibility - look at what happened to Alex Jacobson. Stefan (who will readily admit his bleak outlook) Be happy: we're about 15 years ahead of the lisp guys. 'cabal install xmonad' works, for example. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Of phantom types and type extentions
All, I've been casually developing a PacketBB (i.e. Generalized Manet Packet Format) library in Haskell. I think I have a need to pass state information as a phantom type - I'll step through the issue now. With the 'AddressBlock' (S5.2.1 packetBB draft 8), network addresses are abbreviated as sets of bytes (potentially just one byte each, with a head or tail identical with other addresses). How many bytes are in the set is determined, in part, by the type of address stored (ex: IPv4 or IPv6). Thus, when serializing, I need to provide this information. Saying this again, but in (simplified) code: data NetworkAddress a = AddressBlock a = AddrBlkWire { lenHd :: Word8, hd :: [Word8], lenTl :: Word8, tl :: [Word8], nrAddrs :: Word8, addrs :: [Word8] } | AddrBlkAbstract [a] data (NetworkAddress a) = SomeHigherLevelStruct a = SHLS (AddressBlock a) Word32 Word8 -- length (addrs x) == (TotalAddressLength - lenHd - lenTl) * nrAddrs I can think of several ways to convert between AddrBlkWire and ByteStrings: 1) Make separate instance of 'Binary' for each data type element of NetworkAddress. instance Binary (AddressBlock IPv4) where get = ... put = ... instance Binary (AddressBlock IPv6) where get = ... put = ... This solution immediately causes problems with every higher level structure you wish to serialize. For example, now you have to have individual instance for SHLS, you can't do: instance (NetworkAddress a) = Binary (SomeHigherLevelStruct a) where ... 2) You can pass another argument into a custom 'get' routine. I see this as a hack that makes me break a good naming convention. getNetworkAddress :: Int-- bytes per address - Get NetworkAddress 3) If you don't worry about decoding, only encoding, then an extra field in the data structure can fill the void of an extra argument. Also a hack. I'm hoping someone here has a better solution. Perhaps I am making a mountain out of a mole hill, or perhaps this requires one of those type system extensions I have yet to look hard at. The solution I would want looks like this: class NetworkAddress a where addressByteSize :: a - Int instance (NetworkAddress a) = Binary (AddressBlock a) where get = do lenH - get h- replicateM get (fromIntegral lenH) lenT - get t- replicateM get (fromIntegral lenT) nr - get let addrSize = addressByteSize (undefined :: a) bytes = (addrSize - lenH - lenT) * nr addrs - replicateM get (fromIntegral bytes) return ... The line 'addrSize = ' is what I don't know how to write. How does one call an instance of a type class without knowing the type at compile time? Thanks, Tom -- The philosophy behind your actions should never change, on the other hand, the practicality of them is never constant. - Thomas Main DuBuisson ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: System.Posix
Hello, I am fairly familiar with 1st order logic ... hence I think I understand where Z (Zed) is going ... i.e. http://en.wikipedia.org/wiki/Z_notation. It seems to be based on the ZFC formal notion of set theory. 1) I have a formal spec in Z (Zed) and the implementation is in ANSI C. Can I (easily!) develop a Haskell implementation from the Zed`specification? The reason I ask is that I don't want to waste a lot of time reading the Zed spec if useless. Kind regards, Vasili Galchin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: do
I actually got this done several hours ago, but my DSL is being annoying tonight... Anyway, here's a simple example of how to do explicit/non-monadic I/O in GHC. (It *only* works in GHC; other compilers have different internal implementations of IO.) I specifically modeled it to highlight its resemblance to State. {-# OPTIONS_GHC -fno-implicit-prelude -fglasgow-exts #-} import GHC.Base import GHC.IOBase import GHC.IO import GHC.Handle (stdout) {- This is horrible evil to demonstrate how to do I/O without the help of the IO monad. And yes, it is very much a help. The trick here is that the type IO is a state-like type: a value constructor which wraps a function. Thus, working with it manually requires that we have a runIO.(*) Naively, this looks like unsafePerformIO; but in fact it is not, as unsafePerformIO uses the magic builtin RealWorld# to create a new State# RealWorld on the fly, but in fact we are passing on the one we get from somewhere else (ultimately, the initial state for main). (Additionally, we don't unwrap the resulting tuple; we return it.) This is why runIO is really *safePerformIO* (i.e. entirely normal I/O). (*) Well, not absolutely. GHC.IOBase uses unIO instead: unIO (IO f) = f I think this is a little cleaner, and better demonstrates how IO is really not all that special, but simply a way to pass state around. -} -- treat IO like State, for demonstration purposes runIO :: IO a - State# RealWorld - (# State# RealWorld,a #) runIO (IO f) s = f s -- And here's our simple hello, world demo program main :: IO () main = IO (\s - runIO (putStrLn' hello, world) s) -- this is just to demonstrate how to compose I/O actions. we could just -- call the real putStrLn above instead; it is operationally identical. -- write a string followed by newline to stdout -- this is completely normal! putStrLn' :: String - IO () putStrLn' = hPutStrLn' stdout -- write a string followed by newline to a Handle hPutStrLn' :: Handle - String - IO () hPutStrLn' h str = IO (\s - let (# s',_ #) = runIO (hPutStr' h str) s in runIO (hPutChar h '\n') s') -- write a string, iteratively, to a Handle hPutStr' :: Handle - String - IO () hPutStr' _ [] = IO (\s - (# s,() #)) hPutStr' h (c:cs) = IO (\s - let (# s',_ #) = runIO (hPutChar h c) s in runIO (hPutStr' h cs) s') -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe