Re: [Haskell-cafe] Music update
Yes, video was shot and several audio recordings taken. I'm mastering the audio and expect to have something in a week to share. On Mon, Sep 23, 2013 at 4:21 AM, Dan Krol orbliv...@gmail.com wrote: Will there be a video of the live premier? On Fri, Sep 20, 2013 at 12:14 PM, Mark Lentczner mark.lentcz...@gmail.com wrote: Some might remember me asking about music packages a while back... An update: I ended up using Euterpea, which in turn uses both Codec.Midi and Sound.PortMidi. My working environment was to have my code loaded up in ghci, play MIDI into a software MIDI bus, and pipe that into MainStage 3 which ran the synths. The piece I was working on premiered last night at a concert in Wellington, NZ. The live recording will take a while, but you can hear a studio synth recording (from the above setup) here: https://soundcloud.com/mtnviewmark/plain-changes-2-all-synth-mix The code for the piece is all open source: https://github.com/mzero/PlainChanges2. In particular, there is a somewhat improved MIDI playerhttps://github.com/mzero/PlainChanges2/blob/master/src/Sound/MidiPlayer.hs in there. Enjoy! - Mark P.S.: Yes, and now that that's done with, I can get on with the next Haskell Platform release! ___ 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] Music update
Some might remember me asking about music packages a while back... An update: I ended up using Euterpea, which in turn uses both Codec.Midi and Sound.PortMidi. My working environment was to have my code loaded up in ghci, play MIDI into a software MIDI bus, and pipe that into MainStage 3 which ran the synths. The piece I was working on premiered last night at a concert in Wellington, NZ. The live recording will take a while, but you can hear a studio synth recording (from the above setup) here: https://soundcloud.com/mtnviewmark/plain-changes-2-all-synth-mix The code for the piece is all open source: https://github.com/mzero/PlainChanges2. In particular, there is a somewhat improved MIDI playerhttps://github.com/mzero/PlainChanges2/blob/master/src/Sound/MidiPlayer.hs in there. Enjoy! - Mark P.S.: Yes, and now that that's done with, I can get on with the next Haskell Platform release! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS X ghci problem
Bizarre - this just happened to me today, too. Anyone? Did you figure out a work around? For the record, I'm trying to bring Euterpea up. My system is OS X 10.8.4, and I'm running HP 2013.2, so 7.6.3. And GLFW-0.5.1.0. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Music / MIDI help
I'm a little lost in the bewildering array of music packages for Haskell, and need some help. I'm looking to recreate one of my algorithmic music compositions from the 1980s. I can easily code the logic in Haskell. I'm looking for a the right set of packages and SW so that I can: a) generate short sequences and play them immediately, preferrably in ghci, -- but 'runHaskell Foo.hs | barPlayer' would be acceptable 2) generate MIDI files I'm on OS X. So far what I've found is: Haskore, the midi package, and the jack package - and then I'd need some MIDI software synth for the Mac, and Jack based patcher Or perhaps I want SuperCollider, and the Haskell bindings - but that seems rather low level for my needs here (I don't really need to patch together my instruments, and I don't want to have re-write the whole timing framework from scratch.) So - What's a quick easy path here? - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] tangential request...
On Mon, Jun 24, 2013 at 12:14 AM, Tobias Dammers tdamm...@gmail.com wrote: Well, there's only so many monospace fonts that are beautiful, reasonably unicode-complete, easy on the eyes, programming-friendly AND free (-ish). Not really quite so true: I easily came across about a dozen that are readily available, and many systems have several of these pre-installed. (Though one's defiinition of Unicode complete might affect this). And yet, just four fonts make up over 75% of the sample - and two of those are essentially identical! Also, the default for the most popular terminal emulators on Linux (e.g. xterm, rxvt) is actually a bitmap font. Unclear if those are the most popular terminal emulators on linux any more. The screen shots I received say otherwise: I can only tell the terminal emulator in about half of them - but again only 15% have a bitmap font. Controversial topic there, tread carefully ;) . Lots of folks are borderline militant when it comes to their terminal fonts, whether they're bitmapped or not. Again, I'd say the sample doesn't bear that out. The samples with console fonts showed no signs of customization, and so one might infer that it is more likely that people are using them because they just came that way (and/or changing it is too difficult for the perceived benefit.) Also, white-on-black vs. black-on-white seems to be an emotionally-charged question. This seems true, and really baffles me. White (or green) on black makes sense on mono-chrome CRT devices with very low resolution: The lit pixels bloom, and so a single pixel wide line of lit pixels is wider than a single pixel wide line of unlit pixels in a field of lit ones. Hence, small black characters on white (or green) would become anemic. Once you start using higher resolution, color CRT (which have less blooming), or LCDs (which have almost none), this reasoning makes no sense. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] tangential request...
(apologies for keeping this tangential topic alive for so long... but it is the cafe... and it is all for a good Haskell related cause...) The two fonts that are essentially identical are DejaVu Sans Mono and Menlo. Both derive from Vera Sans Mono, and in the ASCII range are different in only a few characters. Turns out that Monaco (older OSX default font) and Ubunutu Mono are also derivatives and very very similar, identical in many characters. So, perhaps Evan, the reason you didn't like any of them better than the default OS X terminal font is... they were basically the same as the default terminal font! If you want to try something different easily, try Andale Mono, which comes with OS X. If you like that, consider the very similar, but slightly more refined (and bolds better) Source Code Pro. As for basic color scheme: light-on-dark was represented 2:1 over dark-on-light. But share your suspicion that default settings in the stock terminal emulators may have a lot to do with this. Ah, the indomitable Mr. Parker, we meet again! While the other console fonts were nothing so much as an indiscriminate pile of plundered pixels from the trash can of crufty CRTs Your font was of such refined line and design that it clearly marked you as a man of distinction, wealth, fame, power, and fine scotch! A straight sided capital A, sporting a peaked top that actually comes to a point?!?!!! Well played! Game of Baccarat over martinis? — Mark On Mon, Jun 24, 2013 at 6:14 PM, Conrad Parker con...@metadecks.org wrote: On 24 June 2013 23:02, Mark Lentczner mark.lentcz...@gmail.com wrote: Again, I'd say the sample doesn't bear that out. The samples with console fonts showed no signs of customization, and so one might infer that it is more likely that people are using them because they just came that way (and/or changing it is too difficult for the perceived benefit.) Haha, you've succumbed to my adroit minimalism again, Mr. Lentczner. I have taken much pride in customizing my console font for readability, codeability and /pizzazz/. Next time you ask for a screenshot I shall rather send you a copy of my .Xdefaults file, pirate. Conrad. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] tangential request...
Thanks all, I’ve got what I needed. Brief results; Big variety in window and text sizes, but very few font and color choices. More than half the terminals seem to be basically default settings. Finally, 15% seem to be using horrid bitmap console fonts. _How can you stand to look at them?!?!_ (Don't worry, you'll have Plush soon enough...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] tangential request...
As you may know, I've been writing a shell in Haskell called Plushhttps://code.google.com/p/plush/ . I'm working on the look of the terminal input and output, and I want to do a little data gathering. I want to know what your terminal looks like! You can help me by: 1) Download this file: http://www.ozonehouse.com/mark/plush/TerminalDisplay.txt 2) Open a new terminal window 3) Do not resize the terminal window 4) cat the file 5) Take a screen shot of the whole terminal window 6) E-mail it to me: mark.lentczner+t...@gmail.com The file contains some sample text, including some screen codes to change colors and bold. This looks like: - in my terminal program http://www.ozonehouse.com/mark/plush/term.png - in Plush http://www.ozonehouse.com/mark/plush/term-plush.png (bleeding edge, not checked in yet) Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Haskell Platform 2013.2.0.0
On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 2013.2.0.0 *featuring* GHC 7.6.3 52 packages 650+ public modules 4 tools *New packages this release:* attoparsec case-insensitive hashable unordered-containers *and a major upgrade to* OpenGL and GLUT Get it now: Download Haskell Platform http://www.haskell.org/platform/index.html — for Windows http://www.haskell.org/platform/windows.html — for Mac OS X http://www.haskell.org/platform/mac.html — for Linux http://www.haskell.org/platform/linux.html (distributions updating soon) *N.B.: You will likely need to explicitly re-fresh those links when visiting in your browser - those pages tend to get cached for very long periods of time.* — Mark platform wrangler Lentczner ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] list comprehension doesn't work
module Stuff where import Data.List -- Let's translate your specification directly into a list comprehension s1 :: [(Integer, Integer)] s1 = [(x,y) | x - [1..]-- for this problem, better to have 0 ∉ N , let a = 1 -- if 1 ∈ N, , let b = x -- then by setting a = 1 and b = x , x == a * b-- we can have any x ∈ N, x = a · b, where a, b ∈ N , x 5 , x 500 , c - [1..]-- this is a problem, see below , let y = c * c , y = 1000 , y `mod` x == 0 ] -- Something is wrong with the a*b constraint as specified, since it has no -- effect. I bet the intention was that x is a composite number, not prime. -- We could insert a primality test, but it is easier to construct all possible -- x values that are clearly the composite of two numbers greater than 1: s2 :: [(Integer, Integer)] s2 = [(x,y) | a - [2..499] -- we know the upper bound , b - [2..a] -- a 'diagonalization', since one of the two numbers , let x = a * b -- must be same or smaller, let it be b , x 5 , x 500 , c - [1..]-- still a problem , let y = c * c , y 1000 , y `mod` x == 0 ] -- Let's fix the problem of having an infinite source in the middle of the -- the comprehension. -- -- To understand the problem, think about how the comprehension is evaluated. -- The whole expression after the vertical bar is a value in the list monad. -- You can think of each comma separated term being handled left to right. If -- the term is an -, then one value from the list is bound to the variable -- on the right, and the next term considered. If the term is a let, then it -- is just a binding. Finally, if the term is a condition, then if it holds, -- it goes on, otherwise it backtracks. If the end of the term list is reached -- then the expression before the vertical bar as produced as a value in the -- result list... and then we backtrack. Backtracking has the effect of -- backing up to the previous - and binding the next value in that list. If -- it runs out, then backtrack further. -- -- The problem is that if there is an infinite list in the middle of the -- comprehension, evaluation will never backtrack before it, as that list -- never ends. And hence, any prior - will never bind its next value. -- -- The fix is to have only finite lists in the middle. Here, we can fix -- an upper bound to c. s3 :: [(Integer, Integer)] s3 = [(x,y) | a - [2..499] , b - [2..a] , let x = a * b , x 5 , x 500 , c - [1..floor(sqrt 1000 :: Double)] , let y = c * c , y `mod` x == 0 ] -- The above will produce duplicates because there may be more than one way -- to produce a value x as the product of two values a and b. We can easily -- de-duplicate them with the library function nub: s4 :: [(Integer, Integer)] s4 = nub s3 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Release Candidates for Haskell Platform 2013.2
*Some of the release candidates for Haskell Platform 2013.2 are up.* *These are what I expect to simply re-brand as the release, unless anyone uncovers some issues.* *If you decide to test these out, please let me know how it goes.* * * The Mac OS X RC2 installers: *32bit: *Haskell Platform 2013.2.0.0 32bit rc2.signed.pkghttp://www.ozonehouse.com/mark/platform/Haskell%20Platform%202013.2.0.0%2032bit%20rc2.signed.pkg *64bit: *Haskell Platform 2013.2.0.0 64bit rc2.signed.pkghttp://www.ozonehouse.com/mark/platform/Haskell%20Platform%202013.2.0.0%2064bit%20rc2.signed.pkg The source tarball (RC1): haskell-platform-2013.2.0.0-rc1.tar.gzhttp://www.ozonehouse.com/mark/platform/haskell-platform-2013.2.0.0-rc1.tar.gz *Notable new things in Haskell Platform 2013.2:* - GHC 7.6.3 - Major update to *OpenGL* *GLUT* - New packages: - *attoparsec* - *case-insensitive* - *hashable* - *unordered-containers* — Mark mad releaser Lentczner ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Release Candidates for Haskell Platform 2013.2
OpenGL and GLUT were very down-rev for quite a number or HP releases. The recent changes are: - OpenGL http://hackage.haskell.org/package/OpenGL *2.2.3.1* ⟶ *2.8.0.0 * - GLUT http://hackage.haskell.org/package/GLUT *2.1.2.1* ⟶ *2.4.0.0* I know that this involved a fair bit of juggling and there are two new modules OpenGLRaw and GLURaw. Perhaps Jason D. can fill us in on the highlights? On Mon, May 13, 2013 at 7:58 AM, Alfredo Di Napoli alfredo.dinap...@gmail.com wrote: That's awesome :) I'm just curious to dig deeper inside the updates to OpenGL and GLUT, any link or change notes I can read? Thanks, A. On 13 May 2013 15:39, Mark Lentczner mark.lentcz...@gmail.com wrote: *Some of the release candidates for Haskell Platform 2013.2 are up.* *These are what I expect to simply re-brand as the release, unless anyone uncovers some issues.* *If you decide to test these out, please let me know how it goes.* * * The Mac OS X RC2 installers: *32bit: *Haskell Platform 2013.2.0.0 32bit rc2.signed.pkghttp://www.ozonehouse.com/mark/platform/Haskell%20Platform%202013.2.0.0%2032bit%20rc2.signed.pkg *64bit: *Haskell Platform 2013.2.0.0 64bit rc2.signed.pkghttp://www.ozonehouse.com/mark/platform/Haskell%20Platform%202013.2.0.0%2064bit%20rc2.signed.pkg The source tarball (RC1): haskell-platform-2013.2.0.0-rc1.tar.gzhttp://www.ozonehouse.com/mark/platform/haskell-platform-2013.2.0.0-rc1.tar.gz *Notable new things in Haskell Platform 2013.2:* - GHC 7.6.3 - Major update to *OpenGL* *GLUT* - New packages: - *attoparsec* - *case-insensitive* - *hashable* - *unordered-containers* — Mark mad releaser Lentczner ___ 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] Release Candidates for Haskell Platform 2013.2
It's a wiki - please feel free to do some maintenance when you find it! I fixed the ReleaseCandidates page. - Mark On Mon, May 13, 2013 at 8:21 AM, harry volderm...@hotmail.com wrote: Mark Lentczner mark.lentczner at gmail.com writes: Some of the release candidates for Haskell Platform 2013.2 are up.These are what I expect to simply re-brand as the release, unless anyone uncovers some issues. Will they go on http://trac.haskell.org/haskell-platform/wiki/ReleaseCandidates? (http://trac.haskell.org/haskell-platform/ has a few outdated links. Does anyone know what the current links are for the documentation sections?) ___ 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] BayHac '13
*Update:* - BayHac '13 http://www.haskell.org/haskellwiki/BayHac2013 is just *two weeks away*. - We have *over 60* sign-ups! - Please sign uphttps://docs.google.com/forms/d/1u502QHmyFC_Wi4fqv_jYTTRun8E6D_gwcbf6bB3dvrs/viewform, if you haven't already. - We've added an optional *Code Katahttps://docs.google.com/forms/d/1lFGAjnPAcvKdYEFdoGtw5-A7z9L3JKF68O_AF_aAEH4/viewformsession *. — Mark On Tue, Mar 12, 2013 at 10:47 PM, Mark Lentczner mark.lentcz...@gmail.comwrote: Please join us for a weekend of Haskell hacking: *BayHac '13* *May 17th ~ 19th, 2013* *Hacker Dojo* *Mountain View, CA* Full details on the Haskell Wiki: BayHac '13http://www.haskell.org/haskellwiki/BayHac2013 - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
On Thu, May 2, 2013 at 6:26 AM, Adrian May adrian.alexander@gmail.comwrote: How about the Haskell Platform? Is that ancient history? Certainly not: it doesn't compile on anything but the very newest GHC. I think you're missing the point of the platform! It is an explicit set of versions, including GHC, that make a stable reference set of packages on which to build, test, and deploy. Each version of the platform explicitly states with equality constraints the exact version of each component so that it will be the same for everyone. You use the HP - with the GHC it comes with (or specifies) - as a set. You want to use GHC 7.4.1? Use HP 2012.2.0.0. Once installed you can install newer versions of the component packages if needed (though cabal-dev or cabal sandboxing is strongly encouraged in such a case to avoid cabal hell.) And unless somebody can explain to me how I would rescue my business now if I had opted for WASH By patching it. Surely we are talking about minor changes here. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
On Thu, May 2, 2013 at 7:36 AM, Adrian May adrian.alexander@gmail.comwrote: I suppose I did miss the point of the platform: I was trying to build it, which requires at least part of the platform. This is not for the faint of heart. Like *ALL* language distributions I know (C++ included), boot-strapping the next rev is never easy. Consider building the stdc and stl for version gcc x with gcc x-1 - Or trying to assemble and test packages for python 2.x with only python 2.(x-1) just a bit of common sense instead of this bloodbath. Now you're being hysterical. The changes don't rise to that level at all. Vast swaths of haskell code have continued to work just fine over the last many years of changes. And many more have continued to work with only minimal maintenance. The changes over the last several years are no more extreme than I see in other systems. Consider that Mac OS X ships with Python2.5 and 2.6 and 2.7 all installed because of incompatibilities in the base set of libraries. If you are comparing it C++ library stability you are being myopic: The situation in C++ system libraries was so complex that it spurred the monster that is autoconf! That the most common libs have settled into a very stable set that can be expected to work over several years and major releases, has only been true in the last decade. The prior three decades of C (and later C++) were filled with tons of this sort of versioning difficulty, compounded by multiple systems. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] BayHac '13
Please join us for a weekend of Haskell hacking: *BayHac '13* *May 17th ~ 19th, 2013* *Hacker Dojo* *Mountain View, CA* Full details on the Haskell Wiki: BayHac '13http://www.haskell.org/haskellwiki/BayHac2013 - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] XCode Dependency for HP on Mac
As the README at that repository states, For 10.7 and later Apple now distributes a Command Line Tools package on the developer site. When I build and release the Haskell Platform, I confirm that works when just this package is installed (rather than all of Xcode). The Command Line Tools from Apple include not only the compiler and bin tools that GHC needs, but also the full suite of development headers and library stubs. Many people's OS X woes with HP have stemmed from non-standard development installations. If at all possible, I suggest you stick with Apple's distributions. Please keep us appraised of how it works for you after you've used it for a bit. I'm curious if, should you start installing some of Hackage's more complicated packages, if it continues to work out. - Mark (HP release manager) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime
Sorry to be reviving this thread so long after but I seem to be running into similar issues as Michael S. did at the start. In short, I'm using forkProcess with the threaded RTS, and see occasional hangs: - I see these only on Linux. On Mac OS X, I never do. - I'm using GHC 7.4.2 - I noticed the warning in the doc for forkProcess, but assumed I was safe, as I wasn't holding any shared resources at the time of the fork, and no shared resources in the program are used in the child. - WIth gdb, I've traced the hang to here in the run-time: forkProcess discardTasksExcept freeTask closeMutex(task-lock) pthread_mutex_destroy The discussion in this thread leaves me with these questions: - Is there reason to think the situation has gotten better in 7.6 and later? - Isn't the only reason *System.Process* is safer because it does an immediate exec in the child? Alas, I really want to just fork()sometimes. - Is it really true that even if my program has no shared resources with the child, that the IO subsystem and FFI system do anyway? Surely the RTS would take care of doing the right thing with those, no? - There should be no concern with exec w.r.t. library invariants since exec is wholesale replacement - all the libraries will reinitialize. Is there a problem here I'm missing? Alas, I've stopped using the threaded RTS until I understand this better. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announce: Haskell Platform 2012.4.0.0
Many people are asking why GHC 7.6 isn't in the platform and when it will be. As the Platform is intended to be a stable, just install it and it works solution - we want to include GHC version that is stable with respect to the community. This means that before we freeze the package version selections for a platform release, there needs to be enough time for packages to settle into a stable, consistent version set. We want this not only for the packages in the platform, but also for packages commonly installed from hackage. Since GHC provides almost half the packages in the platform, a new GHC version is a fair bit of version upheaval. GHC 7.6 was released September 6th, which gave only four weeks before the 2012.4.0.0 version freeze, which I didn't think was enough time. We might have been able to stabilize the platform's packages... but I'm still seeing people having version problems with 7.6 and some hackage packages. I was probably too conservative with the schedule this time round. Next release http://trac.haskell.org/haskell-platform/wiki/ReleaseTimetableI've pull in some phases, and tried to make it a little more speedy. The version freeze date is *April 8th, 2013* for a release *May 6th, 2013*. Whatever GHC is available *early-February* should be stable enough: It will give enough time for both the platform packages, and common hackage packages to adapt to it. If the community would like the platform to use a GHC that is released *in*February, then the platform team needs a) some advanced notice so we can start contacting package maintainers early, and b) support of the community to get common hackage packages working with that release before the April 8th date. - Mark On Mon, Nov 5, 2012 at 11:54 PM, Mark Lentczner mark.lentcz...@gmail.comwrote: I'm pleased to announce that Haskell Platform 2012.4.0.0http://www.haskell.org/platform/index.html#2012.4.0.0is now available. This release contains three new packages to the platform: - async-2.0.1.3http://lambda.haskell.org/platform/doc/current/packages/async-2.0.1.3/doc/html/index.html - split-0.2.1.1http://lambda.haskell.org/platform/doc/current/packages/split-0.2.1.1/doc/html/index.html - vector-0.10.0.1http://vector-0.10.0.1http://lambda.haskell.org/platform/doc/current/packages/vector-0.10.0.1/doc/html/index.html The remainder of the changes are small updates to the versions of GHC (now 7.4.2) and several other packages. Installers for Windows http://www.haskell.org/platform/windows.html, Mac OS X http://www.haskell.org/platform/mac.html, and the source tar ballhttp://www.haskell.org/platform/linux.htmlare all now available from the site. Linux distribution packages should be available shortly. On behalf of the Haskell Platform teamhttp://trac.haskell.org/haskell-platform/wiki/Members , - Mark mzero Lentczner, Release Manager ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Enemy of the Mutable State
A Haskell poster I made that you all might enjoy: http://www.ozonehouse.com/mark/enemy/ - mzero ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Release Candidate 2: HP 2014.4.0.0
Haskellistas - The second release candidate of HP 2014.4.0.0 is now available: - Source tarball: haskell-platform-2012.4.0.0-rc2.tar.gzhttp://ozonehouse.com/mark/platform/haskell-platform-2012.4.0.0-rc2.tar.gz - Mac 32-bit installer: Haskell Platform 2012.4.0.0 32bit rc2 signed.pkghttp://ozonehouse.com/mark/platform/Haskell%20Platform%202012.4.0.0%2032bit%20rc2%20signed.pkg Mac notes: This version is now digitally signed by me, and so will install without fuss on OS X 10.8. I'll put up 64-bit version soon. - Mark Changes since RC1: TODO [x] update vector and primitive versions (they had a point release to fix a bad bug, and the fix was very very simple) [x] remove Build.hs - it did all its work by shelling out anyway! [x] main .cabal file should not have versions commented out [x] this will require a way to extract the list of packages that need to be part of the source release [x] why not also extract the list of packages needed for core.packages [x] fix to build.hs (ticket #195) [x] bugs in build.sh (ticket #197) [x] build instructions in the tarball (ticket #207) [x] merge in shared library patch (ticket #198) MAC TODO [x] mac cabal script needs to quote things with $HOME or ~ in them (ticket #192) [x] If the cabal command is update then the wrapper script shouldn't do an update the first time through! [x] sign Mac installers (ticket #203) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
I'm the source of the 32-bit recommendation, and the HP Mac distribution builder To summarize what I read in this thread: 1. 32-bit GHC/HP didn't work with 64-bit Cario libs 2. Some libs available via brew were 64-bit, and 32-bit ones would have to be compiled 3. There is still some bug with 64-bit ghci and some graphics libs 4. There is a ghc bug with 64-bit on mac (bug #7040), which isn't fixed until 7.6 There seemed to be the implication that a 64-bit ghc would work with 32-bit libs, but I don't think that's true. Mac doesn't (generally) support mixed modes in the same executable. All system libs are shipped dual-architecture. I don't think there are any pre-installed libs that are shipped 64-bit only. The problem seen with Cairo would cut both ways: If one had installed the 32-bit version of Cairo, one would see the same problem with the 64-bit HP: wrong architecture. Since code compiled with the 32-bit system is both faster, and uses less memory, and it has been the case that all libs are either shipped dual-arch, or easily available as 32-bit, and there were known problems with the 64-bit version for some use cases, it seemed to me to be best to suggest the 32-bit version by default. The major source of the problems in the OP, seem to be that MacPorts and/or brew don't appear to follow the Mac OS X lib standard of installing libs dual arch. A brief look at the MacPorts page indicated that there were various rules (OS version and processor version) that determined which arch. it built by default. Perhaps we should tell people to install the HP architecture that matches the architecture that they use for MacPorts or brew. However, I bet most people don't know, so we'd need a pointer to where they could find out the defaults for those systems, or how to establish what their system is using. Finally, I note that HP 2012.4.0.0 (out in a month) will ship with GHC 7.4.2, and so will still have the above bugs. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Installation of the New Haskell Platform
As Brent said, each version of GHC needs to build its own copy of the packages you use in your projects. Conveniently, these are all kept in separate directories by GHC version, so you can leave your old ones around as you compile new ones with the new platform. However... Most users don't want multiple versions installed at once. The Mac Haskell Platform installer, since 2011.4.0.0, installs a command uninstall-hs on your system. You can use that command to uninstall prior versions of GHC and the Platform. You can safely run it either before or after your installation of 2012.2.0.0. It is a very cautious program, and you can just safely run it on the command line - it won't remove anything until explicitly instructed. Pay attention to it's output, including the last few lines which will explain how to proceed with actual removal. -Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Announce: Haskell Platform 2012.2.0.0
We're pleased to announce the next release of Haskell Platform: a single, standard Haskell distribution for everyone. Download Haskell Platform 2012.2.0.0: http://haskell.org/platform/ The specification, along with installers (including Windows, Macintosh, and Unix installers for a full Haskell environment) are available. Notable version changes with this release: ghc 7.4.1 cabal 1.14 cabal-install 0.14 mtl 2.1.1 transformers 0.3.0.0 alex 3.0.1 full package and version list: http://hackage.haskell.org/platform/changelog.html Thanks to: Joachim Breitner, George Colpitts, Duncan Coutts, Jason Dagit, Chris Dornan, Yitzchak Gale, Mikhail Glushenkov, Andres Löh, Gábor Páli, Jens Petersen, Don Stewart, David Terei, Johan Tibell, Mark Wright for their efforts and help in putting together this release. -- The Platform Infrastructure Team Mark Lentczner, release manager - The Haskell Platform is a single, standard Haskell distribution for every system, in the form of a blessed library and tool suite for Haskell distilled from the thousands of libraries on Hackage, along with installers for a wide variety of systems. It saves developers work picking and choosing the best Haskell libraries and tools to use for a task. When you install the Haskell Platform, you get the latest stable compiler, an expanded set of core libraries, additional development tools, and cabal-install – so you can download anything else you need from Hackage. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] BayHac '12
Please join us for a weekend of Haskell hacking: BayHac '12 April 20th ~ 22nd, 2012 Hacker Dojo Mountain View, CA This year will be concurrent with UHac in Utrecht, and technology willing, we'll be liking up to share the Hac between the continents! Full details on the Haskell Wiki: http://www.haskell.org/haskellwiki/BayHac2012 - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll: Do you want a mascot? -- please stop this
On 23/11/11 19:11, heathmatlock wrote: Question: Do you want a mascot? No. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] could not create compact unwind
The ld warning is benign. You can safely ignore it. It is a known issue with GHC and the latest Mac OS X tool chain, and we are stuck with it for awhile: http://hackage.haskell.org/trac/ghc/ticket/5019 The best way to remove versions of Haskell on a Mac is now my shiny new Mac uninstaller! I just put out a release candidate yesterday. You can find it here: Source: UninstallHS.hs (just runhaskell this)Executable: uninstall-hs.tgz (unpack and run if your ghc is broken) Running without will just list what's there and suggest what to do next. It is dry-run by default. - Mark PS.: rm -rf ~/.ghc only removes the package databases, not the packages themselves. It also removes your ghci configuration, so I don't recommend it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] XCode Dependency for HP on Mac
Hiho - I'm the maintainer of the Mac installer for HP. I thought I'd chime in a bit: On Mac OS X, developer tools is essentially synonymous with Xcode. That is, to get the set of standard utilities needed for development on compiled executables (notably the binutils), you install Xcode. True, it also includes the IDE called Xcode, but the vast bulk of that installation are things like headers, link libraries, command line tools, and other utilities for development of compiled executables in general. As several have pointed out, you can download Xcode for free. If you have Lion, you can get Xcode 4 for free from the Mac Store. Xcode 3 for 10.6 and 10.5. Traditionally, Apple has included Xcode on one of the CD-ROMs that came with a new computer, and/or as an installer already present on the hard disk. (I haven't bought a new Air... yet... but perhaps someone can check to see if the Xcode installer is one the SSD volume already?) It is conceivably possible to build and distribute some of those tools, but not the whole bundle. But the difficulty of getting such a build just right, and all the pieces in the right place, seems absurd to attempt to recreate when Apple has done it, and gives it away for free. Apple's versions of bintools also includes many extensions extra options for the OS X environment (like supporting multi-arch binaries) Finally, there is also licensing questions regarding the parts supplied by the OS vendor (headers, stub libs, debug libs, etc) Given the above, perhaps it is a little more clear why we choose to not include the system development tools in the Haskell Platform installer. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Posix IO Unicode lookup exception
My guess is that you are closing the file descriptor out from under the handle. It is probably the handle that has the open iconv connection, and since it is never closed, you run out of memory. Why not just interact with the handle? Use hPutStr instead of fdWrite, and hClose instead of closeFd. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Experimental 64 bit installer fails
Well that's no fun! The install looks like it mostly worked, execept that the final registration of the installed packages failed because for some reason the script has them out of order. You can fix up your install by doing this: cd /Library/Haskell/ghc-7.0.2/lib/registrations for c in *.conf; do echo == $c ==; ghc-pkg register --force $c; done I'll have to look into why that build of the package got the files out of order... - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding of Haskell source files
On Mon, Apr 4, 2011 at 3:52 PM, Roel van Dijk vandijk.r...@gmail.comwrote: I made an official proposal on the haskell-prime list: http://www.haskell.org/pipermail/haskell-prime/2011-April/003368.html Let's have further discussion there. I'm not on that mailing list, so I'll comment here: My only caveat is that the encoding provision should apply when Haskell source is presented to the compiler as a bare stream of octets. Where Haskell source is interchanged as a stream of Unicode characters, then encoding is not relevant -- but may be likely governed by some outer protocol - and hence may not be UTF-8 but nonetheless invisible at the Haskell level. Two examples where this might come into play are: 1) An IDE that stores module source in some database. It would not be relevant what encoding that IDE and database choose to store the source in if the source is presented to the integrated compiler as Unicode characters. 2) If a compilation system fetches module source via HTTP (I could imagine a compiler that chased down included modules directly off of Hackage, say), then HTTP already has a mechanism (via MIME types) of transmitting the encoding clearly. As such, there should be no problem if that outer protocol (HTTP) transmits the source to the compiler via some other encoding. There is no reason (and only potential interoperability restrictions) to enforce that UTF-8 be the only legal encoding here. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How large is the Haskell community ?
On Thu, Mar 17, 2011 at 1:25 PM, Vo Minh Thu not...@gmail.com wrote: Mm. Do 12000 lines of auto-generated code[0] count? Yes: The generator gets to be a member of the Haskell community! :-) - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] possible bug for ghc 7 + xcode 4 on snow leopard?
I don't have Xcode4 (yet), but I'd be very surprised if Apple created an environment that cut off development for older releases. In the past, the SDKs for some older releases have been an optional part of the install. That is, you've had to go to the customize installation screen and explicitly enable older SDKs. With the latest Xcodes, for example, the SDK for 10.3 was optional. I'm a little surprised that 10.5 would be put in that category... but it's possible. Can someone with Xcode4 start the installer and go to the Customize screen and see if the SDK for 10.5 is an option there? (You can do this safely even if you've already installed... in fact, prior installers let you install a previously not-installed component at this point.) - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Platform 2011.2
code.haskell.org is the release repo code.galois.com is current development repo - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] operations on lists with continuations
To make up for my total misunderstanding of what you were asking before, I hereby offer you the Plumbing module, available here: https://bitbucket.org/mtnviewmark/haskell-playground/src/2d022b576c4e/Plumbing.hs With it, I think you can construct the kinds of pipelines you describe with the composition aspects you desire: :load Plumbing.hs [1 of 1] Compiling Plumbing ( Plumbing.hs, interpreted ) Ok, modules loaded: Plumbing. let filterUntil cond start end = (passUntil (=start) =|= pfilter cond) =+= passWhile (end) let filterUntilPlus1 cond start end = filterUntil cond start end =+= pass 1 filterUntil even 10 15 `pump` [1..] [2,4,6,8,10,11,12,13,14] filterUntilPlus1 even 10 15 `pump` [1..] [2,4,6,8,10,11,12,13,14,15] - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Platform install instructions
* Should we document this somewhere in the Haskell Platform install process? I'm sure many old-time users of cabal are well aware that they need ~/.cabal/bin in the PATH, but new users will not be. In the next version of Haskell Platform, on Mac OS X, happy will be installed with the other platform files, and symlink'd into /usr/bin. The need to mention ~/.cabal/bin belongs to the empty user guide of cabal-install. I'm not sure what is meant by guide here. cabal-install has a symlink-bindir option. In the next version of Haskell Platform, on Mac OS X, if the user has no ~/.cabal directory at all, then I'm planning on having it install a ~/.cabal/config file that, among other things, will set this symlink-bindir to symlink into ~/bin. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OSX i386/x86 and x86_64 - time to switch supported platforms?
On Feb 3, 2011, at 5:55 PM, Max Cantor wrote: Yes. I'm saying that I believe that OSX x86_64 should be the officially supported platform instead of 32-bit x86 with all the associated guarantees and assurances. I wanted to see how people felt about that. I don't think this is such a good idea. There are plenty of Macs in the field that can only execute 32bit code. (I'm typing on one right now!) Anyone wanting to produce binaries that they can distribute or deploy will need an environment that produces either 32bit only binaries, or multi-arch 32bit/64bit binaries. My understanding is that GHC is quite a long way, if ever, from producing multi-arch binaries from a single compiler. To produce multi-arch binaries you'd need to install two copies of the GHC (one 32bit, one 64bit), build your code twice, once with each, and stitch the results together with lipo. Hence, for the Haskell developer needing to deploy code, the path of least resistance is going to be simply compiling and distributing 32bit for awhile. Because of this, the 32bit version should be officially supported just as much as the 64bit for at least the next few years. My plan for the upcoming Haskell Platform is to build and distribute two installers: one 32bit and 64bit. Most developers should take the 64bit one if their machine supports it. Developers with older machines, and those building binary distributions will need to take the 32bit. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for children? Any experience?
I think this is a wonderful idea! Fer land sakes, I remember when kids were taught BASIC or Fortran! I think Haskell will be a great improvement. Now, how'z'bout web sites? Kids love web sites, yes? I've been working on a small project, in quiet mode, to develop an all in the web browser development environment and tutorial on programming in Haskell with web programming as the main focus. So far the development environment part is up and running: you start like this: barley start playground ...project created Running on http://localhost:8080/ Now you browse to that URL and you have a Haskell development environment in the web page. Edit Haskell modules, and click save... bang! compiled with either in-line error messages, or if it runs, with a web page preview output. It's a lot of fun, actually. Here's the catch: The project isn't even at 0.1 yet: The above works, but there are some missing features from the development environment, and, most importantly, there is only the barest wisp of a tutorial yet. BUT - you aren't starting until next year, so help us write the tutorial! The project is, for now, here: https://github.com/mtnviewmark/barley But will be moving to code.google.com in a few weeks. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ m...@glyphic.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] UTF-8 BOM
On Jan 4, 2011, at 5:41 PM, Antoine Latter wrote: Are you thinking that the BOM should be automatically stripped from UTF8 text at some low level, if present? It should not. Wether or not a U+FFEF can be stripped depends on context in which it is found. There is no way that lower level code, even file primitives, can know this context. I'm thinking that it would be correct behavior to drop the BOM from the start of a UTF8 stream, even at a pretty low level. The FAQ seems to allow it as a means of identifying the stream as UTF8 (although it isn't a reliable means of identifying a stream as UTF8). §3.9 and §3.10 of the Unicode standard go into more depth on the issue and make things more clear. A leading U+FFEF is considered not part of the text, and dropped, only in the case that the encoding is UTF-16 or UTF-32. In all other cases (including the -BE and -LE variants of UTF-16 and UTF-32) the U+FFEF character is retained. The FAQ states that a leading byte sequence of EF BB BF in a stream indicates that the stream is UTF-8, though it doesn't go so far as to say that it can be stripped. Since Unicode doesn't want to encourage the use of BOM in UTF-8 (see end of §3.10), I imagine they don't want to promulgate it as a useful encoding indicator. So, it might be reasonable that when opening a file in UTF-16 mode (not UTF-16BE or UTF-16LE), that the system should read the initial bytes, determine the byte order, and remove the BOM if present[1]. But it isn't safe or correct to do this for UTF-8. On Jan 4, 2011, at 5:08 PM, Tony Morris wrote: I am reading files with System.IO.readFile. Some of these files start with a UTF-8 Byte Order Marker (0xef 0xbb 0xbf). For some functions that process this String, this causes choking so I drop the BOM as shown below. If you mean functions in the standard libs shouldn't have any problems with the BOM character. If they do, these are bugs. On the other hand, if you know the context of the files, and know for certain that the leading BOM is intended only as an encoding indicator, then by all means strip it off. But only you can know if this is true for your application, the system cannot. If so, your code doesn't look hackish to me at all. I'd only perhaps tidy up dropBOM a bit (but this is pure stylistic choice): readBomFile :: FilePath - IO String readBomFile p = dropBom `fmap` readFile p where dropBom (\xffef:s) = s -- U+FFEF at the start is a BOM dropBom s = s I'd keep dropBom private to readBomFile to ensure that it isn't used on arbitrary strings, since it is really only valid at the start of an encoded stream. - Mark [1] Software reading a single text stream that has been split across files would have a problem here. But this is perhaps an obscure and unlikely case. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] UTF-8 in Haskell.
On Dec 22, 2010, at 9:29 PM, Magicloud Magiclouds wrote: Thus under all situation (ascii, UTF-8, or even UTF-32), my program always send 4 bytes through the network. Is that OK? Generally, no. Haskell strings are sequences of Unicode characters. Each character has an integral code point value, from 0 to 0x10, but technically, the code point itself is just a number, not a pattern of bits to be exchanged. That is an encoding. In any protocol you need know the encoding before you exchange characters as bytes or words. In some protocols it is implicit, in others explicit in header or meta data, and in yet others (IRC comes to mind) it is undefined (which makes problems for the user). The UTF-8 encoding uses a variable number of bytes to represent each character, depending on the code point, not Word32 as you suggested. Converting from Haskell's String to various encodings can be done with either the text package or utf8-string package. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] haskell.org migration complete
On Dec 5, 2010, at 12:29 AM, Henning Thielemann wrote: How about an alternate CSS layout for the old Wiki style? Btw. unfortunately also in Konqueror CSS selections are not preserved across sessions. When logged in: My preferences Skin MonoBook ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Managing multiple installations of GHC
On Dec 1, 2010, at 8:38 PM, Antoine Latter wrote: If you're doing user installations of packages with 'cabal-install' it will take care of everything - all of the things that it installs are in per-GHC-version directories. ... Except for the haddock documentation that cabal-install installs - different versions of GHC/haddock are pretty much always breaking each other when I switch back and forth. This is because cabal's default layout *doesn't* install everything in per-GHC-version directories. The layout is: prefix -- /usr/local if --global, ~/.cabal if --user bin -- binaries ($bindir) lib -- ($libdir) pkgid compiler -- libraries .hi files ($libdir/$libsubdir, $dynlibdir) include -- include files ($includedir) libexec -- private binaries ($libexecdir) share -- ($datadir) pkgid -- data files ($datadir/$datasubdir) doc pkgid -- documentation ($docdir) html -- html doc ($htmldir, $haddockdir) man -- man pages ($mandir) Notice that only libraries, .hi files and includes are uner a per-compiler directory. All the other things aren't, and as you notice they clobber each other. I propose that the default in Cabal be changed to: prefix -- /usr/local/haskell if --global, ~/.cabal if --user, compiler pkgid bin -- binaries ($bindir) lib -- libraries .hi files ($libdir, $libdir/$libsubdir, $dynlibdir) include -- include files ($includedir) libexec -- private binaries ($libexecdir) share -- data files ($datadir, $datadir/$datasubdir) doc -- documentation ($docdir) html -- html doc ($htmldir, $haddockdir) man -- man pages ($mandir) bin -- symlinks to binaries doc html-- master index of html doc man -- symlinks to man pages current -- symlink to current compiler bin -- symlink to current/bin doc -- symlink to current/doc This would put everything under a per-compiler top level dir, which is how most other language systems install (for example perl and python both do it this way) This would also allow very easy removal of an old compiler and everything that was installed for it. Removing packages is also easier: you just one pkgid dir per compiler to find and get rid of -- and you can do it with a wildcard! Thoughts? - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] save the dates: SF Bay Area Haskell Hackathon: Feb 11~13, 2011
Bryan O'Sullivan and I are hosting a SF Bay Area Haskell Hackathon at the Hacker Dojo in Mountain View, California. Details are all sketchy at this point, but we plan on two components: 1) Haskell Project Hackathon 2) Learn Haskell Workshop See: http://wiki.hackerdojo.com/w/page/Haskell-Hackathon-2011 At this stage we're trying to gauge interest, size, and volunteers to help with organizing and running it. Either add yourself to that wiki page, or e-mail me. - Mark Lentczner Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type Directed Name Resolution
My tuppence:
I feel like the main impetus for TDNR is the awkwardness of records, especially
when there are multiple record types within a module (as there often are). Now,
if one proceeds as one has to today, then one may find:
data Foo = Foo { fooName :: String, fooValue :: Double }
data Bar = Bar { barName :: String, barValue :: [String], barSubbars :: [Bar] }
Let us, for sake of argument, ignore that perhaps fooName and barName represent
the same semantic concept and these should all somehow be refactored.
I suspect that the prime annoyance, the thing that makes us yearn for our old
C/C++/Java/Python ways, is the tediousness of having to prefix all the field
names with foo or bar. Especially when the data type name is large, one
ends up having to invent coding conventions one doesn't want to:
data ExecutionTraceSummary = ExecutionTraceSummary { etsStart :: Time; ... }
So imagine that we take the tedium out of typing all those prefixes by
anointing some initial character, say the apostrophe, as a sort of name mangler:
data Foo = Foo { 'name :: String, 'value :: Double }
data Bar = Bar { 'name :: String, 'value :: [String], 'subbars :: [bar] }
data ExecutionTraceSummary = ExecutionTraceSummary { 'start :: Time, ... }
Now, to use them, perhaps we have to explicitly write the full form:
showFoo :: Foo - String
showFoo f = Foo'name f ++ ( ++ show (Foo'value f) ++ )
We could allow a form of shortened local reference by allowing the full form to
flow through type declarations:
type ETS = ExecutionTraceSummary
logExecutionTraceSummary :: ExecutionTraceSummary - IO ()
logExecutionTraceSummary s = do
putStr $ ETS'start s
Mind you, I realize that apostrophe may not work here, and details haven't been
worked out.
[...that was the first pence, here comes the second...]
If you buy any of that, then one could allow, in the manner pointed out by some
(though in particular I'm thinking of David Menendez's example), that this
construction could imply a type class and associated type. That is, the first
appearance of 'name in a record implies this:
class C'name a where
type R'name a :: *
'name :: a - R'name a
and for each appearance of 'name :: X as a field of Foo:
instance C'name Foo where
type R'name Foo = X
'name = Foo'name
(Here, C and R are some unwritable prefixes used by the compiler. It
remains to be seen if these should be module scoped or program global.)
So, in the case (repeated from above):
data Foo = Foo { 'name :: String, 'value :: Double }
data Bar = Bar { 'name :: String, 'value :: [String], 'subbars :: [Bar] }
We get auto generated:
class C'name a where
type R'name a :: *
'name :: a - R'name a
class C'value a where
type R'value a :: *
'value :: a - R'value a
class C'subbars a where
type R'subbars a :: *
'subbars :: a - R'subbars a
instance C'name Foo where
type R'name Foo = String
'name = Foo'name
instance C'name Bar where
type R'name Bar = String
'name = Bar'name
instance C'value Foo where
type R'value Foo = Double
'value = Foo'value
instance C'value Bar where
type R'value Bar = [String]
'value = Bar'value
instance C'subbars Bar where
type R'subbars Bar = [Bar]
'subbars = Bar'subbars
*Now* one can write:
showFoo :: Foo - String
showFoo f = 'name f ++ ( ++ show ('value f) ++ )
nameBoth :: Foo - Bar - String
nameBoth f b = 'name f ++ ++ 'name b
None of this requires any more type machinery than already exists with
TypeFamilies. It perhaps suffer some of the prior objections to implying
semantic equivalence (in say the 'value fields) where none exists. But, it is
limited in scope to fields, and only when one uses the special naming sigil
(apostrophe here).
Of course, this approach would meld nicely with any better record/label system.
For starters:
class C'name a where
type R'name a :: *
'name :: a - R'name a
''name :: R'name a - a - a
instance C'name Foo where
type R'name Foo = String
'name = Foo'name
''name = \v x - x { Foo'name = v }
There now -- I feel like TNDR is placating the muscle memory in our fingers
that wants to type f.name ... and I hope we find a solution to replacing the
tedium of so many fooName fields, and perhaps solve the record update
ugliness as well!
- Mark
Mark Lentczner
http://www.ozonehouse.com/mark/
IRC: mtnviewmark
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell is a scripting language inspired by Python.
On Nov 3, 2010, at 7:00 PM, Jonathan Geddes wrote: http://www.datarecoverylabs.com/ultimate-computer-language-guide.html It's called The *Ultimate* Computer Language Guide, and it's on the internets, so it must be correct, right? Wow! Did you read the rest of that page? It is so full of fail! Can you imagine trusting your data to these people? Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
Some notes on the Haddock re-design: 1) HTML supports the concept of alternate style sheets. If present, then the idea was that browsers would give the user the choice, somewhere, to choose among them. While Firefox does this (View Page Style), and I'm told that Opera (View Style), and Konqueror (View Use StyleSheet) do, the other big-name browsers, IE, Safari, Chrome, do not. Since support is so lacking, the common thing to do, and what I implemented for Haddock, is to use Javascript to pull the alternate style sheet information out of the page and build a menu that is then placed back into the page. This is the Style menu in the top right of the page. If you have Javascript turned off, it won't appear as it is not part of the markup. The cookie, which is set from Javascript is so that you don't to re-pick the style on every page load. I'm assuming that those browsers that do implement a style sheet menu remember this per-site, but I don't know. It is a limitation of cookies that it can only remember your choice per-site. 2) What styles appear depend on what was specified when Haddock was run to produce the pages. By default it includes just the new Ocean theme. If --default-themes is specified (as it is on Hackage), then both Ocean and Classic are included. You can build your own themes and include them with --theme, alone or in combination with the built-in themes. If the resulting theme set is a singleton, then no Style menu will appear on the page. 3) Without really doing a tracking analysis (preferably by tracking eye movements, or at least mouse movements, and in all cases recording accurate view times and location of clicks), it isn't possible to optimize a web page down to the level of which menu links should be in in which order, or other such small changes. That isn't saying such changes won't have a big impact, only that it is hard to reason about them because the tracking results are often non-intuitive. In the absence of such things, all one can do is bring one's experience and design skills to bear. 4) While Haddock tries to minimize the use of Javascript, it still has some. There is a tension between wanting to produce pages that can be printed documentation, and creating a effective on-line reference. Between the theming ability, and the new LaTeX backend, it is now possible to achieve these two aims with separate Haddock outputs. In modern browsers, Javascript is very efficient and even moderate amounts of Javascript can be crafted to not affect load times. Haddock still has an issue here that the Javascript is repeated in every directory, thus ruining caching. When this is fixed, we'll be able to use more Javascript, which will enable us to make the reference easier and faster to navigate.[1] 5) It does not make sense for users to configure colors or fonts for web sites any more than it would for magazines or books. Effective presentation of information requires design including choice of fonts, colors, graphics and layout - and these vary by the information and intent of the content. There is no choice a user an make that works best for all. It is important for accessibility that those users that need to can override fonts and colors. All modern browsers allow this, and one of the major aims of the Haddock redesign was to output clean markup so that it worked in such situations, as well as with screen readers. In other words - if you want to override the fonts and colors you can now do so effectively. 6) Over the Summer the new style was made available on the web for people to look out for several months, and at one point I conducted a poll. In that poll only 81% preferred the newer look, and only 11% preferred the older. - Mark Haddock web scullion Lentczner [1] An example of an HTML reference work that is highly usable and uses plenty of Javascript (700k!) to achieve it, yet works very well: http://developer.android.com/reference/packages.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Haskell theme Haskellers design
You might have seen the post I did yesterday about the Haskell project I'm currently working on. In it I posted an screen shot or a web page, which you can find here: http://mtnviewmark.files.wordpress.com/2010/10/source-editing.png I think that page illustrates what I was thinking in terms of themes: It actually has yet a different color scheme, though it shares some colors with the basic pallet. What further ties it together, and what I'd like to propose Haskell sites use, is that top bar. It is the same as the top bar used in the Haddock Ocean theme. For sites, I suggest the top bar appear as it does in that image: The Haskell logotype on the left (linked to haskell.org), and some or all of the community links on the right. (Though I think the lambdas should be smaller versions of the logo.) Specific site branding and navigation goes under. Another way to use the bar would be like Haddock does: The left side contains the name of a major collection of pages. The links on the right are constant links to major sections. - Mark P.S.: The CSS for the top bar in that image can be found here: http://github.com/mtnviewmark/barley/blob/master/seed/static/scaffold.css Look for selectors with topbar in them. The CSS for the same bar in Haddock can be found here: http://code.haskell.org/haddock/html/Ocean.std-theme/ocean.css Look for selectors with package-header in them.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] UTF-8 problems when decoding JSON data coming from Network.HTTP
On Oct 17, 2010, at 5:37 AM, Michael Snoyman mich...@snoyman.com wrote: in the case of JSON, I believe this is always specified as UTF-8. RFC 4627 section 3 says that JSON must be encoded in Unicode, but all encodings are acceptable. The encoding is inferred by the firsthand four octets. So you need to be prepared to decode UTF-16 and UTF-32 and endian variants. - Mark___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Haskell theme
On Oct 6, 2010, at 12:10 PM, Don Stewart wrote: * haskell visual design group? + consistent color themes across haskell.org sites. + consistent haskell branding. On Oct 12, 2010, at 2:17 PM, Christopher Done wrote: To kick off discussion about Haskell's general theme, as discussed recently, here's some random ideas. I was there for the BoF discussion, and this was one of the topics I was there to discuss. I spent some time beforehand looking at what other successful language communities do w.r.t. visual design. I found that none of the communities had a single theme; most had two or three. but these themes were visually harmonious. Furthermore, I found that they were used consistently, and that the various themes were generally at the same level of polish. For Haskell I think this means that while it isn't essential that we have a single common theme on all properties, it is important that various site designers think of the whole look of Haskell when designing their projects. This means leaning toward consistent colors, and logo form, rather than exact layout. Further, it seems more important that our projects get designers who will do a thorough job, and less important that it be a single central design group. It is no accident that the new Haddock backend looks like the new wiki design: Thomas Schilling (nominolo) supplied the initial style sheet that the Haddock team used to build the Ocean theme. I think this exemplifies what we should strive for: The two projects look well together, look like they have a relationship, and both are full treatments of their subjects. It isn't so important that they have identical layouts or details. Since parts of the Hackage site integrate so closely with the Haddock output, I've been asked if I would take a stab at styling the new Hackage (or at least the package pages). I'll be aiming to make that fit, but without being 100% rigid about conformance to the Ocean output. http://img840.imageshack.us/img840/3577/ideasv.png Lovely ideas there and I think a Haskell project built on those lines would continue to look well with the wiki and Haddock. I don't know what I was thinking here but it seemed like fun: http://img412.imageshack.us/img412/1827/rect5935.png For some projects, I could imagine this feel would be more appropriate - yet still, there is enough tie-in to make it part of the family. Maybe we should do a theme poll like the logo poll. I don't know. Regardless, I think we do need to decide on something and stick with it. Should this discussion be taken to the web devel mailing list? Is that appropriate? I'd lean toward us putting these thoughts down in the wiki, and developing a set of guide posts for styling Haskell, rather than a strict set of policies. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)
On Oct 10, 2010, at 10:56 AM, Michael Snoyman wrote: I'm worried about spam accounts being featured on the homepage. Real Haskeller is not meant to be exclusive, it's a minimal level of oversight by the admins. A more common approach to the problem of spam accounts -- which is very real -- is to not allow accounts to appear before they have been vetted by an admin. Allowing accounts to appear on the site as they are created will, sooner or later, result in the site being over run with spam faster than you can keep up. For the community site I help run (http://www.contextfreeart.org/) had this problem a while back and we switched to all accounts being vetted. We use http://www.stopforumspam.com/ as source of information to easily help us make that determination. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0 - HTML vs. XHTML
On Sep 6, 2010, at 2:40 AM, Henning Thielemann wrote: ... focusing on a small set of assumed popular browsers ... I didn't want to assume either. I ran a survey of the Haskell community and got over a 150 responses. The multiple choice browser question yielded: Firefox: 59% Chrome: 51% Safari: 24% Other: 11% Opera:7% IE 8: 2% IE 7: 1% IE 6: 1% As I did the work on Haddock, I tested the results on five browser/os combinations on my own machines, and about 30 browser/os combinations via browsershots[1]. and complying to their quirks is the wrong way. I believe the only sop to browser quirks in the current Haddock output are three lines of CSS that came from YUI 3: CSS Fonts [2] to achieve consistent font sizing in IE. These are well researched and minimal. There were a few times where I tried something (usually a choice of markup and CSS) that looked nice in WebKit browsers (Safari and Chrome), but didn't work in Firefox or others. In those cases I retreated to other approaches. A notable example is the Portability box in the upper right. I wanted that to be a dl list, and could get it to style nicely in all browsers except Firefox on Linux! I retreated to a table in that case. Since both the thing I tried and the result were valid markup and CSS, I'm hoping you won't consider this a major concession to quirks. All these incompatibilities between browsers and common abuse in HTML and XHTML make it a nightmare for me to process web documents as in my online web-site enhancement :-) service: http://www.haskell.org.monadtransformer.parallelnetz.de/haskellwiki/Category:Monad An excellent service! I hope the new, cleaner markup of Haddock works with less pain. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark [1] http://browsershots.org/ [2] http://developer.yahoo.com/yui/3/cssfonts/___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Sep 2, 2010, at 11:24 AM, Yuras Shumovich wrote: Is it possible to switch back from frame version to non frame version? The Frames button disappears in frame mode... I usually just right-click on the main page and select Open frame in new window I could have made the Frames button become Unframe... do people think that's worth it? I was worried about clutter, but can add it in easy enough if folks think it makes sense. Also style changing works only inside the main frame. True - the Haddock team suspected that style changing was something people would play with a bit, pick a style they liked and leave it. Once you refresh the page - all the panels will change to the style you picked and continue to stay that way. I thought of adding logic to the Style menu to do this when in frames mode just didn't make the cut before we wanted to ship. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
We all seem to understand that there are a complex of issues surrounding the HTML and XHTML dialects, doc types, MIME Types, and file extensions. It is a tangle of intentions and compatibility issues, and one where experts and standards writers admit to practical compromises, which at times are even contradictory. The choice to generate Haddock output as XHTML 1.0 Transitional and Frames, stored into files with an extension of .html, and that would likely be served as text/html, was mine and I did so with review of current best practices. The output Haddock now generates renders correctly and consistently in all browses in use by the Haskell community (Firefox, Chrome, Safari, Opera, IE 6, IE 7, and IE 8), the Javascript is handled properly, and with one minor exception[1] it validates as served by the W3C. The main aim of the work was achieved: Being able to restyle the output with clear, semantic CSS, and do so in a way that works in all browsers, and all serving environments. If there is a particular issue that is causing the documentation generated to not be usable, please let me know. - Mark [1] John Milliken caught that anchor identifiers for groups didn't validate, though they did work in every browser. The fix is already coded and pushed to the development repo. The sample pages on my site updated. You can check the validation with: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.ozonehouse.com%2Fmark%2Fsnap-xhtml%2Fcontainers%2FData-Map.html This fix isn't crucial, and so I've recommended that we not produce a Haddock point release just for this.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Sep 2, 2010, at 5:00 AM, David Waern wrote: -- Haddock 2.8.0 A new version of Haddock, the Haskell documentation tool, is out! The biggest news this time is that we have a shiny new XHTML backend, created by Mark Lentczner, ... Included is a new default CSS theme created by Thomas Schilling, Mark and Johan Tibell, as well as the classic theme converted to work with the new backend. If you'd like to see the new look in action, I've generated some pages for a few packages here: http://www.ozonehouse.com/mark/snap-xhtml/ - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
I am well aware of the differences between HTML and XHTML. I choose to switch Haddock's output from HTML to XHTML mostly because I have found the consistency of rendering cross-browser to be greater and easier to achieve with XHTML. I'm not alone in this opinion: Many well respected web design authorities have promoted, and publish their own sites, in XHTML.[1] Even Microsoft's own developer web site uses it[2]! Indeed, there is just one kind of validation error in the pages: the ids for section headings within a page are pure numbers and need an alphabetic prefix. That said, they work just fine in all browsers. I did fix the very bad validation problems with other ids (those that link to specific program symbols), and several other classes of ids. I will push my fix for the remaining ids and it will appear in the next release.[3,4] As for extensions and doctypes, I believe that we are following best practices for the most interoperable result among browsers, and given that we need to produce output that will be served in a variety of ways including different web servers, and being browsed directly off the file system.[5] Of course, as soon as it is viable, I would love to move Haddock's output to HTML 5. However, given the pace of adoption of such standards, and the range, age and mix of browsers that readers of Haddock's output use, it is likely to be two years off. - Mark [1] See, for example: http://www.alistapart.com/ http://www.csszengarden.com/ http://www.quirksmode.org/ http://happycog.com/ http://www.w3.org/ all of which are published as XHTML [2] See: http://msdn.microsoft.com/en-us/default.aspx [3] Considerable thought was put into both making identifiers validating, while maximizing browser interoperability and forward/backward compatibility. See: http://projects.haskell.org/pipermail/haddock/2010-August/000623.html [4] Given that the prior Haddock produced pages with much more significant validation errors and they didn't seem to cause issues, I don't think we should rush a point fix just for this change. [5] I can't find any evidence for your assertion that Internet Explorer doesn't support XHTML, or the way Haddock names the files (and hence URLs). Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haddock New Look Survey results
Thank you to all who took the Haddock New Look Survey. We got a 161 responses. Some graphs of the results can be found here: http://www.ozonehouse.com/mark/snap-xhtml/Haddock-Survey-Summary.pdf I've read through all of the comments, and I'd like to share some initial thoughts with you: • Source links are indeed still supported in Haddock, I just happened to generate those sample pages with it turned off. Sorry for any confusion. The functionality remains exactly like it is in Haddock today. • I also failed to turn off all the alternate style bits on the index page, and many of you found it, explored the other styles, and then wondered why it failed on the module pages. I had intended for the survey to just give pages in the new style, and missed updating the index page. In the new Haddock, you can specify which themes you want to render your documentation with. If you include more than one, the pages have a style switcher menu added. The default themes that will come with Haddock include Classic which is a pretty faithful recreation of the current look. • Many great suggestions were made about ways to improve the UI experience of Synopsis drawer. Of course, the web is hardly a full featured UI framework, and to implement many of them we would have to decide to move to a much larger JavaScript framework. At present, Haddock attempts to use JavaScript very lightly, and only needs one small .js file. I think we are planning on keeping it that way for now. • Several people mentioned that perhaps we should have user preferences for things like where the Synopsis section goes. This is possible (the style switcher menu above uses such a preference), but know that a page can only set a cookie for a site. So if we do such things, they will stick per site, and users will have to choose their preference for each new site of Haddock docs they browse to. Fortunately, all of Hackage would count as one site, as does your local machine, and those two settings probably cover the bulk one's use. There were many many good suggestions, reported problems, and observations among the comments. I'm pulling together a short of list with the Haddock team of high priority changes based on these to be completed before the first release. To be sure, this will include: - fixing the layout issues on Firefox Chrome - improving the expanding/collapsing behavior in module lists The most difficult issue is how to handle the Synopsis. As evident both from the multiple choice question in the survey, and from the comments, there is no clear consensus. While 2/3rds of you like the Synopsis drawer, there is a wide range of how it should look and operate. Another 1/5th want it back where it was, in-line with the page. There were many other suggestions as well. I'm going to go have to spend some time mulling what to do. Finally, thanks for the huge amount of positive feedback. When working on open source, often on speculation that it is what the community will want, it is really great to hear that you've done good! I realize that there is no way that such a change as this can please everyone 100%, but I'm glad to see that we are, on the whole, people are really happy with the work. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ m...@glyphic.com irc: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
On Aug 4, 2010, at 5:11 AM, Magnus Therning wrote: Does the current stable version of Haddock really create a frame version? I've never seen one before... Yes it does. For example, the standaed GHC book packages doc has the frames version here: http://www.haskell.org/ghc/docs/6.12.2/html/libraries/frames.html Documentation on Hackage doesn't seems to be missing two of the generated files to enable the frames version to work for each package. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Preview the new haddock look and take a short survey
The Haddock team has spent the last few months revamping the look of the generated output. We're pretty close to done, but we'd like to get the community's input before we put it in the main release. Please take a look, and then give us your feedback through a short survey Sample pages: http://www.ozonehouse.com/mark/snap-xhtml/index.html Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html Survey: http://spreadsheets.google.com/viewform?formkey=dHcwYzdMNkl5WER1aVBXdV9HX1l5U3c6MQ Short link to same survey: http://bit.ly/9Zvs9B Thanks! - Mark Mark Lentczner http://www.ozonehouse.com/mark/ irc: MtnViewMark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] what's the best environment for haskell work?
On Jul 31, 2010, at 6:07 AM, Rustom Mody wrote: Do most people who work with haskell use emacs/vi/eclipse or something else?? I work on Mac OS X. On one machine I have Haskell Platform installed. On the other I have ghc, cabal-install, and various packages installed by hand. To edit, I use SubEthaEdit with a Haskell mode for editing. To run, I use various command line (via standard OS X Terminal) tools. I use ghci for poking around, and debugging in the small. For most of my projects, even small ones, I create .cabal files and unit test/quick check suites, then use cabal to build and test. - Mark SubEthaEdit: http://www.codingmonkeys.de/subethaedit/ Hasekll mode for it: http://www.codingmonkeys.de/subethaedit/modes/Haskell.mode.zip ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Design for 2010.2.x series Haskell Platform site
On Jul 16, 2010, at 11:09 AM, Don Stewart wrote: If anyone is interested in a 2010.2 series design for the HP site, the repository containing the stylesheet is here: http://code.haskell.org/haskell-platform/ I like the content. The layout has some flaws when rendered on my environment (Safari 4, but with perhaps narrower than most peoples windows): * The background image tiled looks pretty bad - since I see repeats and it doesn't really tile. * The three columns at the bottom overlap! Perhaps this is a valid case for a table rather than three divs and CSS layout. * The word Download isn't actually part of the download link. Many people might think to click on the Download text itself. Can we make that a link that auto-detects your OS and redirects appropriately? On Jul 17, 2010, at 7:21 AM, Thomas Schilling wrote: Webdesign for an open source project is pretty much doomed from the beginning. Design requires a few opinionated people rather than democracy. Truer words were never spoken! Good web sites always proceed from a single graphic designer's vision. Great ones combine that with, tweaking after deployment based on log analysis and A/B testing. I saw we just appoint a short group of designers and let them at it, and deploy it, and then see how it fares! I nominate Thomas and Christopher! As for CSS wrangling, I've got a fair bit of experience at that. I've even done it in the context of MediaWiki themes(*). If anyone needs some help on that aspect, I'm volunteering. I'm pretty sure I could reproduce Christopher's image in XHTML/CSS if desired. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark (*) My work on http://www.contextfreeart.org/ involves getting MediaWiki (used for the download and documentation sections), phpBB (for formus), custom PHP (for the gallery), and static pages to all style identically with CSS. I think I mostly succeeded. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haddock anchors
I've been re-working on the Haddock HTML back end to get it to generate semantic markup and legal XHTML. One of the problems is that the anchors that Haddock currently generate aren't always legal in HTML, XHTML, or XML. I'd like to fix the anchor generation so that they are. If I do, then links between old and new generated Haddock pages will land on the right page, but won't always get to the right spot on the page. Will this be a problem for anyone? On one's own machine, I imagine we can come up with a simple script that will just rebuild all the Haddock docs and that will take care of it. What about on Hackage? Eventually, as packages update, the issue will diminish. Can we just bulk re-build the haddock for the latest rev of all packages? - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HaskellWiki spam
On Jul 11, 2010, at 3:17 PM, Henk-Jan van Tuyl wrote: There are hundreds of HaskellWiki users created, their names all start with Buy and their user pages contain spam. I suppose the antispam measures were reverted when a backup of the site was loaded. (B.T.W. the site still displays the old logo.) Yikes! I see that the Haskell wiki is running Media Wiki 1.5.4 from 2005. Current version is 1.15.2 from 2010. That five year period seems to include many significant anti-spam fixes and numerous patches for all sorts of vulnerabilities. Migrating through that many revisions might be painful, but should be doable. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Getting started
On Jul 5, 2010, at 7:50 AM, Mrwibbly wrote: This adds the data to an empty database but I can't seem to call newRecord again and add another record to the existing database. The issue is that you need to use the new database returned by newRecord in subsequent executions of your main loop. I've coded a simpler data example showing how to do this: -- -- Pure, Functional Data Set -- type Name = String type DB = [Name] addName :: String - DB - DB addName name db = name : db initialDB :: DB initialDB = [ Amy, Bob ] -- -- UI Actions on DBs -- addNameAction :: DB - IO DB addNameAction db = do putStrLn Enter name to add: name - getLine return $ addName name db printNames :: DB - IO () printNames db = mapM_ print db -- -- Main Program -- mainLoop :: DB - IO () mainLoop db = do putStrLn 1 = Add a name to the DB putStrLn 2 = Print the DB putStrLn 3 = Exit input - getLine case read input of 1 - do newDB - addNameAction db mainLoop newDB 2 - do printNames db mainLoop db 3 - do return () main :: IO () main = mainLoop initialDB Notice how mainLoop is called recursively after the input is handled. This is how the changes to the database are propagated from one action to the next. Note: mainLoop is rather verbose, you would generally find this written as: mainLoop :: DB - IO () mainLoop db = do putStrLn 1 = Add a name to the DB putStrLn 2 = Print the DB putStrLn 3 = Exit input - getLine case read input of 1 - addNameAction db = mainLoop 2 - printNames db mainLoop db 3 - return () Once you've got that under your belt, consider this version, which is even more general: actions :: [(String, DB - IO ())] actions = [ (Add a name to the DB,\db - addNameAction db = mainLoop), (Print the DB,\db - printNames db mainLoop db), (Exit,\db - return ()) ] mainLoop :: DB - IO () mainLoop db = do mapM_ print $ zip [1..] $ map fst actions input - getLine let action = snd $ actions !! (read input - 1) action db - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are you a Haskell expert? [How easy is it to hire Haskell programmers]
I suppose that what qualifies as a good Haskell candidate depends on what you
are looking for in a software engineer in general. For my part, having hired
engineers into various groups over the last 20+ years, I've always preferred to
hire people who demonstrate a broad understanding of computing rather than a
deep knowledge of the particular domain at hand. So, for example, when hiring
into a C++ shop, I expect a medium level applicant to know templates, STL,
iostreams, boost, etc..., but I don't expect them to be able to rattle them off
off the top of their head. What I want is for them to be able to know what
tools are available, when they should consider using them, and where to go get
the details if they need them. An expert C++ programmer, who can rattle off
complicated template structures is not that useful to me if they don't have a
broader sense of what libraries are out there, or where to look, or even when
to use Python (or Haskell) instead!
On Jul 3, 2010, at 11:29 AM, Yves Parès wrote:
Back to initial topic, I have a sudden fear: do you have to master Template
Haskell so as to be regarded as a guru :-{ ?
Let it be no, please, let it be no...
Well, perhaps one doesn't really want that kind of guru! I've used Template
Haskell, I've written a Quasi-Quoter, but I've by no means mastered it. I've
got 77 packages installed in --user above and beyond Haskell Platform and while
I've not mastered all of them, what I know is what is there, and where to look
when needed. I've by no means mastered the various GHC extensions, but I've
written code with dependent types and know where to find the papers if I need a
deeper understanding. So, I think of myself as a general programming guru - one
who knows a pretty broad swath of computer science, and w.r.t. to many
programing languages one who knows enough about the language and libraries to
be able to find what I need to write excellent code. I suppose for Haskell I'd
call myself guru-in-training. Those are the kinds of gurus (or
gurus-in-training) that I've always looked to hire.
- Mark
Mark Lentczner
http://www.ozonehouse.com/mark/
IRC: mtnviewmark
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
On Jun 28, 2010, at 2:29 PM, Luke Palmer wrote: I proposed the following solution: http://lukepalmer.wordpress.com/2009/07/01/on-the-by-functions/ Seconded! I always want xxxOn and I almost never (perhaps never*) want xxxBy for xxx in sort, maximum, group and nub. - Mark (*) A quick scan of all the Haskell source I wrote on my machine reveals that I have never once used xxxBy without giving it a function of the form (==) on foo or comparing foo! Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project: A Haddock + Pandoc documentation tool
On Apr 8, 2010, at 6:55 PM, ViaToR (Alvaro V.) wrote: I just finished writing my GSoC proposal ... The project is about creating a new documentation tool for Haskell projects,... I've taken a brief look and this looks lovely. I'm currently deep at work on re-coding the Haddock backend to produce semantic XHTML rather than table-nested HTML. I'm pretty familiar now with the internals of the backends of Haddock and would be happy to help you. General GSoC question: Would this be good time to offer to be a mentor? Do we have too many mentors or would it be useful for me to help out here? If so, do I need to register on the GSoC site today or tomorrow? - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Time for a San Francisco Hackathon?
On Feb 11, 2010, at 10:00 PM, Bryan O'Sullivan wrote: I'm thinking it might be a good idea to organise a Haskell Hackathon for people in (and who'd like to visit) the Bay Area. I'm still up for this - are others? The tentative date I have in mind is the first weekend in May (conveniently May 1). On Feb 11, 2010, at 10:46 PM, Don Stewart wrote: Interesting. We were planning a PDX one for late April. May 1st is just four weeks away, so seems a little close. Also seems close if the PDX event is still on (is it?). If so - weekend of May 22nd? or June 5th? If you'd be interested in attending or helping to organise, Aside from helping secure a space, I'd be happy to help. In particular, I think it would be cool to offer a Haskell teach-in. Something like a half day, perhaps at one of the hacker locations, where we teach intro-Haskell with some slides, some talking, and lots of Haskell folks walking around to help people 1-on-1. We get them to install Haskell Platform, and write a few functions, and then perhaps something tiny bit bigger... Thoughts? - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bubble sort algorithm implementations (Haskell vs. C)
You might express the algorithm more directly in Haskell, without the reverse calls: bubblesort :: (Ord a) = [a] - [a] bubblesort [] = [] bubblesort (x0:xs) = case bubble x0 xs of (xs', True) - bubblesort xs' (xs', False) - xs' where bubble x1 (x2:xs) | x1 = x2 = merge x1 False $ bubble x2 xs | otherwise = merge x2 True $ bubble x1 xs bubble x1 [] = ([x1], False) merge x s (xs, s') = (x:xs, s || s') Here, the local bubble function does the job of bubbling a value through, and the merge function handles both rebuilding the new, bubbled list, and the swap flag. The case expression in bubblesort is a direct expression in Haskell of bubble through the list once, and if we swapped anything, do it again. This version clocks in at about 35% faster than your original. - Mark P.S.: Code and driver Main files can be found here: http://bitbucket.org/mtnviewmark/haskell-playground/src/tip/cafe/ Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] trouble with HDBC-mysql on Mac OS X
I'm having trouble with HDBC-mysql on Mac OS X (10.6, Snow Leopard). It compiles and builds fine, but when loaded (into ghci), the dynamic loader complains about not being able to find libmygcc.dylib. The issue is, MySQL's libmygcc is a static lib, not a dynamic one, so of course it won't find it. I've checked the build sequence that HDBC-mysql uses, and it calls upon mysql_config to generate the lib options. I've checked those and they are correct, expressly listing libmygcc statically (!). I've tried building against both the 64bit and 32bit versions of MySQL libs. (Suspect that only the 32bit should work.) Anyone have HDBC-mysql running on 10.6? Any ideas for me to try would be appreciated. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extracting all pruned sub trees
On Jan 20, 2010, at 10:09 AM, Tom Hawkins wrote: I'm looking for an elegant way to generate a list of all pruned trees where each pruned tree has one of its leaves removed. This turned out to be a thornier problem than I thought! (pun intended) -- | A simple Tree type. data Tree a = Leaf a | Branches [Tree a] deriving Show -- | Produce a list of all possible Trees that can result from pruning one Leaf allPrunings :: Tree a - [Tree a] allPrunings (Leaf _) = [] allPrunings (Branches ts) = Branches `fmap` pruneInTurn ts where pruneInTurn (a:as) = pruneOneWith a as ++ map (a:) (pruneInTurn as) pruneInTurn _ = [] pruneOneWith (Leaf _) as = [ as ] pruneOneWith aas = map (:as) (allPrunings a) The difficulty lies in the treatment of Branches vs Leaf: Pruning Branches laves a Tree who's head (well, root) is of the same form, whereas pruning Leaf leaves nothing (no valid Tree). This gives rise for the need for the pruneOneWith function. A more complete module with a small parser for a string tree language, and a nice, input and pring all prunings function can be found here: http://bitbucket.org/mtnviewmark/haskell-playground/src/tip/cafe/TreePrune.hs Enjoy! - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PROPOSAL: Web application interface
I like this project! Thanks for resurrecting it! Some thoughts: Methods in HTTP are extensible. The type RequestMethod should probably have a catchall constructor | Method B.ByteString Other systems (the WAI proposal on the Wiki, Hack, etc...) have broken the path into two parts: scriptName and pathInfo. While I'm not particularly fond of those names, they do break the path into traversed and non-traversed portions of the URL. This is very useful for achieving location independence of one's code. While this API is trying to stay agnostic to the web framework, some degree of traversal is pretty universal, and I think it would benefit being in here. The fields serverPort, serverName, and urlScheme are typically only used by an application to reconstruct URLs for inclusion in the response. This is a constant source of bugs in many web sites. It is also a problem in creating modular web frameworks, since the application can't be unaware of its context (unless the server interprets and re-writes HTML and other content on the fly - which isn't realistic.) Perhaps a better solution would be to pass a URL generating function in the Request and hide all this. Of course, web frameworks *could* use these data to dispatch on virtual host like configurations. Though, perhaps that is the provenance of the server side of the this API? I don't have a concrete proposal here, just a gut that the inclusion of these breaks some amount of encapsulation we'd like to achieve for the Applications. The HTTP version information seems to have been dropped from Request. Alas, this is often needed when deciding what response headers to generate. I'm in favor of a simple data type for this: data HttpVersion = Http09 | Http10 | Http11 Using ByteString for all the non-body values I find awkward. Take headers, for example. The header names are going to come from a list of about 50 well known ones. It seems a shame that applications will be littered with expressions like: [(B.pack Content-Type, B.pack text/html;charset=UTF-8)] Seems to me that it would be highly beneficial to include a module, say Network.WAI.Header, that defined these things: [(Hdr.contentType, Hdr.mimeTextHtmlUtf8)] Further, since non-fixed headers will be built up out of many little String bits, I'd just as soon have the packing and unpacking be done by the server side of this API, and let the applications deal with Strings for these little snippets both in the Request and the Response. For header names, in particular, it might be beneficial (and faster) to treat them like RequestMethod and make them a data type with nullary constructors for all 47 defined headers, and one ExtensionHeader String constructor. Finally, note that HTTP/1.1 actually does well define the character encoding of these parts of the protocol. It is a bit hard to find in the spec, but the request line, status line and headers are all transmitted in ISO-8859-1, (with some restrictions), with characters outside the set encoded as per RFC 2047 (MIME Message Header extensions). Mind you, I believe that most web servers *don't* do the 2047 decoding, and only either a) pass the strings as ISO-8859-1 strings, or decode that to native Unicode strings. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHC bug? Cabal bug? Haddock bug?
=== Short Story === If I build syb-with-class-0.6 via cabal (cabal configure; cabal build) in the unpacked tar directory, it builds correctly. If I build it via cabal install (either from the unpacked directory, or by letting cabal fetch it), then the resulting package is corrupted. In particular, the .hi interface file for Data.Generics.SYB.WithClass.Instances mentions symbols that aren't in the .a file. (Or rather, they have the wrong names.) I compared verbose logs of both builds and the differ only in temporary file names execpt that the cabal install version builds haddock, as my .cabal/conf file has documentation: True. Turns out that if turn documentation off, then then cabal install builds a .hi file that matches the .a file... and all is well. Is this a bug in cabal? cabal-install? ghc? haddock? I have saved logs of all this if anyone wants. - Mark (MtnViewMark) Lentczner ma...@glyphic.com http://www.ozonehouse.com/mark/ === Versions === [2373] : cabal -V cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library [2374] : ghc -V The Glorious Glasgow Haskell Compilation System, version 6.10.4 [2376] : ghc-pkg describe haddock | grep version version: 2.4.2 === Background Details === I was installing happstack on my Mac with my Haskell Platform (GHC 6.10.4) installation. I have successfully installed dozens of other packages in this environment before, and these results are annomalous. I kicked this off via: cabal install --user happstack This installs many packages, including syb-with-class-0.6, which compiled and installed just fine. When installing happstack-data, and compiling the file Happstack/Data/Proxy.hs, during the Template Haskell step (where things get loaded up in ghci), the build encounters this link error: [ 7 of 16] Compiling Happstack.Data.Proxy ( src/Happstack/Data/Proxy.hs, dist/build/Happstack/Data/Proxy.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package bytestring-0.9.1.5 ... linking ... done. Loading package containers-0.2.0.1 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package syb-with-class-0.6 ... linking ... done. (... many more loads elided...) Loading package HaXml-1.13.3 ... linking ... done. ghc: unknown symbol `_sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZMabOQZN_closure' That symbol decodes to something referring to: package: syb-with-class-0.6 module:Data.Generics.SYB.WithClass.Instances reference: dataType[abOQ] The reference turns out to be from Loading Happstack.Data.Default, which in turn imports Data.Generics.SYB.WithClass.Instances. Poking around, I found that the interface (.hi) file for Data.Generics.SYB.WithClass.Instances does indeed export such an object: [2324] : ghc --show-iface Data/Generics/SYB/WithClass/Instances.hi | fgrep dataType[a Data.Generics.SYB.WithClass.Instances.dataType[abOQ]) -} Data.Generics.SYB.WithClass.Instances.dataType[abSm]) -} dataType[abOQ] :: Data.Generics.SYB.WithClass.Basics.DataType dataType[abSm] :: Data.Generics.SYB.WithClass.Basics.DataType But, the library doesn't export it: [2325] : nm libHSsyb-with-class-0.6.a | fgrep dataTypeZMa 0001854c D _sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZMaeuiZN_closure 00018604 D _sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZMaexTZN_closure These refer to dataType[aeui] and dataType[aexT], which don't exist in the interface file. Something seems amiss here: The interface file is exporting generated names that don't match what the library is exporting. If I do the same investigation with the profiling versions of this module, they match: [2326] : ghc --show-iface Data/Generics/SYB/WithClass/Instances.p_hi | fgrep dataType[a Data.Generics.SYB.WithClass.Instances.dataType[anmx]) -} Data.Generics.SYB.WithClass.Instances.dataType[anq8]) -} dataType[anmx] :: Data.Generics.SYB.WithClass.Basics.DataType dataType[anq8] :: Data.Generics.SYB.WithClass.Basics.DataType ma...@mtree ~/Library/Haskell/packages/syb-with-class-0.6/lib/ghc-6.10.4 [2327] : nm libHSsyb-with-class-0.6_p.a | fgrep dataTypeZMa 00032704 D _sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZManmxZN_closure 0003282c D _sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZManq8ZN_closure
Re: [Haskell-cafe] GHC bug? Cabal bug? Haddock bug?
Indeed - all those look exactly like the same issue. And the workaround: http://groups.google.com/group/happs/msg/1e7761d421b0e5eb That doesn't fix the real issue: It causes happstack-data to not need the thing that is built wrong in syb-with-class. I believe my work-around (build syb-with-class w/o documentation) will be a more universal workaround, as at that point the syb-with-class install is no longer broken. Here's the GHC bug report: http://hackage.haskell.org/trac/ghc/ticket/3799 Registration for that trac is broken, so I couldn't update that ticket. I see that you've added pointers to my post, thank you! Perhaps you can also add a note that the issue seems to have to do with something that cabal does differently when there is a documentation step enabled. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC bug? Cabal bug? Haddock bug?
AHA! Note that after running cabal haddock we re-build all of our .hi and .o files EXCEPT ./dist/build/HSsyb-with-class-0.6.1.o And now, since TH generates random symbols, we have symbols in the new .hi files that aren't in the old (and only) HSsyb-with-class-0.6.1.o. So, this leaves us with two questions: 1) Why does cabal haddock rebuild the .hi and .o files? On the face of it, this seems odd: Build documentation and your library gets rebuilt? 2) Why doesn't Instances.o get rebuilt? Surely this has something to do with the fact that Instances.hs contains only orphan instances. But any answer here just leads to a raft of other questions: Surely this problem would plague other modules have have similar source files? What is Haddock doing? If Haddock needs the .hi files, why not just use them? If it just builds them to be sure, why in the dist tree and not some place temporary? If is going to build .o files, why not all? Curiouser. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: uuid-0.1.2
Antione and I are please to announce the release of uuid-0.1.2. CHANGES: - added functions toByteString and fromByteString - added 'nil' UUID - added unit tests and benchmarks, built when configured -ftest - major speed up of to/from functions (as well as in general) - added version-3 generation (deterministic based on MD5) - major changes to internal representation - now uses four strict Word32 values - internal ByteSource classes for easy construction (see Builder.hs) - Storable instance now stores in memory as system libraries in C do: 16 bytes derived from the network order of the fields, no matter what the host native endianess is. - fixed bugs in V1 time and clock stepping, and V1 generated values - builds cleanly under GHC's -Wall - added CHANGES file String conversions were sped up 4x to 7x! - Mark Mark Lentczner (MtnViewMark) http://www.ozonehouse.com/mark/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Seven ways to store 16 bytes
In preparing the speed ups in uuid-0.1.2, I investigated various ways to store 16 bytes of data in a Haskell object. Surprisingly, storing as 4 Word32 values in a standard data type worked best for that application. I've extracted out the testing work for that and put it here: http://bitbucket.org/mtnviewmark/haskell-playground/src/tip/16bytes/ There you can find the code that tests storing 16 bytes in various ways: import qualified Data.Array as A import qualified Data.Array.Unboxed as U import qualified Data.Array.Vector as V import qualified Data.ByteStringas B data InBytes = BY !Word8 !Word8 !Word8 !Word8 !Word8 !Word8 !Word8 !Word8 !Word8 !Word8 !Word8 !Word8 !Word8 !Word8 !Word8 !Word8 deriving (Eq, Ord) data InWords = WO !Word32 !Word32 !Word32 !Word32 deriving (Eq, Ord) data InList = LI [Word8] deriving (Eq, Ord) data InByteString = BS B.ByteString deriving (Eq, Ord) data InArray = AR (A.Array Int Word8) deriving (Eq, Ord) data InUArray = UA (U.UArray Int Word8) deriving (Eq, Ord) data InVector = VE (V.UArr Word8) deriving (Eq) Depending on operations will be needed most, different storage methods do best. Enjoy! - Mark Mark Lentczner (MtnViewMark) http://www.ozonehouse.com/mark/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] install-dirs on Mac OS X
First, we must look at how Apple intends the various Library directories to be used. Please see the Apple docs on it[* link below]. Essentially, /Library is the Mac OS X equivalent of /usr/local. However, I would be opposed to storing anything in /Library or /System. Those are for system use and sysadmin experience tells me never to mess with the system installs. You are only partially correct. /System/Library is for system installed pieces (those that come with OS X), /Library is for things that are available system wide, but have been installed after the OS, by the user. In particular, if you install Perl packages that don't come with OS X, they will end up in /Library/Perl. The same is true for Python and the other languages. /Library is the same place all sorts of user installed things go: MySQL components, video decoders, printer drivers, just to name few. Basically, anything that the user installs and expects to be available to all accounts is put there. So I agree, it would incorrect to ever touch /System/Library - and I'm not suggesting that we do. However, it seems completely in line with Apple's intended usage to put things in /Library. if anything happens in /Library or /System then it has to go through the framework packaging system IMO, This is not a requirement of /Library at all, and NONE of the other language systems on Mac OS X follow it. That is - none of them use Mac OS X's framework system for packages installed by the user. All of them use their native packaging layout. I suggest that we follow suit and use cabal's file layout. Overall, I'd like taking the cue to break things out by version number and then have some symlinking (or tool) in order to select one of many installed versions. As I mentioned, cabal already does this with a per compiler and version subdirectory with the package directory itself. It seems excessive to duplicate it again. The idea from cabal, as I understand it, is that the parts of a package that are not compiler or version dependent are installed only once. Only the compiled lib files are installed multiple times, once per version/compiler. Besides, if we used something like a $HASKELL_PATH, or a tool for querying and recording installation paths, then it doesn't really matter where the default is since people can choose their own. All that matters is the structure of the tree rooted there. For GHC, there is the ghc package system, and that takes care of all this already. And, it doesn't even require consistent package layout (!). So, not matter what we pick here, users will always be able to accommodate personal preference or special situations easily. I don't know about the other Haskell runtimes. Again, it's good not to mess with system internals (where GHC is the system here). In general we *want* Cabal to install things in a different location than the GHC base libraries. Yes- that is what I was suggesting. I believe GHC should continue to put it's packages within it's Framework bundle. I was suggesting that cabal installed packages go under /Library. Those languages ---Perl, Python, Java--- are all used internally by the OSX system itself in order to run startup scripts, maintain the system, etc. That is, they are provided *by* the system, *for* the system. Users are free to use them, but they should not alter them in any way. This isn't quite true. It is expected that users will install additional packages for those languages, explicitly for use with the version of those languages provided with the OS. In such cases, the standard place for such installs, is /Library (if made available to all users of the machine, which is the common default for such packages.) Of course the system installed set of packages for such languages are never touched, and live under /System. This is exactly the same state of affairs I'm proposing for Haskell. - Mark [*] The Apple guidelines for the /Library and ~/Library files are here:http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI Mark Lentczner http://www.ozonehouse.com/mark/ m...@glyphic.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pointfree-trouble
For the record, all of these compile with -O to exactly the same code! reMatr1 f m = Matr (f (unMatr m)) reMatr2 f m = Matr $ f $ unMatr m reMatr3 f m = Matr . f . unMatr $ m reMatr4 f = Matr . f . unMatr reMatr5 f = Matr . (flip (.) unMatr) f reMatr6 = (Matr .) . (. unMatr) And that code is the same as what reMatr1 compiles to with no optimization! Under no optimization, they all compile to direct implementations of their approach - and hence, reMatr1 is the most efficient. The others must wend through quite a number of library functions to do their work. Since there is no real efficiency issue (surely matrix manipulation code will be compiled -O for actual use), the only reason I can see to choose one of these over the other is how it conveys the intention from one programmer to the next. (Or one's self six months later...) In which case seems to me that reMatr4 most cleanly encapsulates the programmer's intention. Of course, I've had some Haskell experience and I get the idiom - to someone less versed in Haskell, reMatr1 is probably the clearest - to someone with much Haskell experience, perhaps reMatr6, though it just looks clever to me, rather than clear. I'm curious why the original poster was motivated to pursue pointfree style to the point of no explicit arguments? - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] install-dirs on Mac OS X
On Dec 22, 2009, at 12:35 PM, Duncan Coutts wrote: One thing I think I've seen said before however is that things in /Library and ~/Library are supposed to be app bundles or frameworks or some other special OSX packaging thing, rather than traditional Unix-style installations. Nope - not true. There are all sorts of things under the Library directories. Again, note the list of other languages that store things under /Library. In those cases, those systems are storing installed packages in just the normal way they would on Linux or other unix systems. On Dec 22, 2009, at 11:49 AM, Tom Tobin wrote: It usually drives me crazy when my more Unix-y tools stick stuff in my ~/Library/ directory; for instance, I had to actively fight with my copy of Aquamacs Emacs in order to get everything running from ~/.emacs.d/ rather than ~/Library/Preferences/Aquamacs Emacs/. I don't know the details, but that sounds inappropriate. If there is no graphic UI for such settings, then ~/Library/Preferences is the wrong place. Apple guidelines[*] are that users should generally not have to poke into ~/Library for normal tasks (such as editing their preferences). As for Haskell, I would suggest that ~/.cabal/config continue to be the location of the user configuration file. Only the installed packages themselves, if installed --user, would go into ~/Library - since these are files users don't edit or alter once installed. Of course, you'd still be free to easily reconfigure the location back to under ~/.cabal if you like, since those entries would still be in config for your editing, and ghc-pkg doesn't, thankfully, actually care where things are, once told. On Dec 22, 2009, at 2:49 AM, Heinrich Apfelmus wrote: +1 Excellent. Since there seems to be somewhat an interest in working this out, I've set up a wiki page: http://www.haskell.org/haskellwiki/Mac_OS_X_Common_Installation_Paths - Mark (mtnviewmark) [*] The Apple guidelines for the /Library and ~/Library files are here: http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI Mark Lentczner http://www.ozonehouse.com/mark/ m...@glyphic.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] install-dirs on Mac OS X
I have been thinking about the location of installed Haskell package files on Mac OS X. The choice of location affects: GHC other Haskell implementations Haskell Platform Cabal cabal-install Haddock If all those agreed on directory locations and layouts, I think the state of Haskell on Mac OS X would be nicer for users. In particular, my hope is for users to end up with an automatically complete Haddock documentation incorporating everything they install. 1) Packages the user installs --global I noticed that the default location for global installation with cabal is on Mac OS X is /usr/local: install-dirs global -- prefix: /usr/local This then intermingles all the Haskell package files along with all sorts of other things that live in /usr/local and environs. While this is arguably convenient for executables that end up in /usr/local/bin (in most people's PATH), it does make things less than tidy, and harder to clean up. Taking a cue from the various preinstalled language systems on Mac OS X, up over in /Library might be a better place: Python puts installed packages in: /Library/Python/version/site-packages Ruby puts installed packages in: /Library/Ruby/Gems/version /Library/Ruby/Site/version Java appears to use /Library/Java/Extensions and has a link to the packages that come the framework as: /Library/Java/Home Perl put installed packages in: /Library/Perl/version I suggest that the default place for global installs on Mac OS X be: /Library/Haskell/ Since cabal already by default interposes the compiler version into the lib dir, path, there doesn't appear to be a need to put a version dir level near the top. 2) Structure of package pieces I notice that cabal/cabal-install's default layout of where a package's pieces go, and GHC's layout of its base packages don't agree. Further, cabal/cabal-install's are not set up so that one can easily delete an installed package without hunting down its parts. cabal/cabal-install defaults the parts as follows: executables: --prefix--/bin libraries: --prefix--/lib/--pkgid--/--compiler-- data:--prefix--/share/--pkgid-- doc: --prefix--/share/doc/--pkgid--/ html:--prefix--/share/doc/--pkgid--/html That's at least four directories you need to hunt down if you want to clean out a package, and rummaging through bin to figure out which things to remove. (Not to mention libexec, which isn't used by any packages on my system, so I can't say where it goes...) GHC/Haskell Platform use a different layout: executables: --prefix--/bin libraries: --prefix--/lib/--compiler--/--pkgid-- data:--prefix--/share/--pkgid-- doc: --prefix--/share/doc/ghc/libraries/--pkgid--/ html:--prefix--/share/doc/ghc/libraries/--pkgid--/ I think it best if everything for a package is in one place - making removal very easy: executables: --prefix--/packages/--pkgid--/bin libraries: --prefix--/packages/--pkgid--/lib/--compiler-- data:--prefix--/packages/--pkgid--/share doc: --prefix--/packages/--pkgid--/doc html:--prefix--/packages/--pkgid--/doc I put the packages level at the top, so that other things, like a master Haddock index dir could be put easily directly under the prefix. 3) Symlinks for binaries This does suggest that it would be nice for the symlink-bindir facility (is that in cabal itself, or added by cabal-install?) to have a version for --global installs. Users could then either set something like: symlink-global-bindir: /usr/local/bin in .cabal/config. Or symlink-global-bindir: /Library/Haskell/bin and then put that in their PATH 4) Quick access to the Framework I like Java's convenience link 'Home', and suggest that /Library/Haskell/GHC be a symlink to where the framework's package files are stored: /Library/Frameworks/GHC.framework/Versions/Current/usr/ Other implementations could use the same idea. Having this here would also (I suspect) help in getting Haddock to be able to find all the bits needed to generate a comprehensive index. Thoughts? I'd be happy to help by supplying patches for various tools to normalize all this on some agreed upon layout. I admit that I'm a bit unclear where the directory choices are being made: Haskell Platform's build process, or GHC's? Cabal's defaults or cabal-install's? And then clearly parts of Haddock. Given the number of tools that need to agree, seems best that we hash it out (here or in the wiki) first, before making patches. - Mark (mtnviewmark) Mark Lentczner http://www.ozonehouse.com/mark/ m...@glyphic.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell Platform for Snow Leopard
On Dec 15, 2009, at 2:09 PM, R J wrote: Could someone provide the status and expected release date of the Haskell Platform for Snow Leopard (Mac OS X 10.6.2)? You can use the currently release version by following the instructions in the Haskell wiki after you've installed it: http://www.haskell.org/haskellwiki/Mac_OS_X#Mac_OS_X_10.6_.28Snow_Leopard.29 (If you have a 32bit only capable processor, then you won't even need to do that - just install and go!) - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC magic optimization ?
On Dec 4, 2009, at 2:43 AM, Luke Palmer wrote: So GHC leaves it to the user to specify sharing. If you want an expression shared, let bind it and reuse. Does GHC treat where and let the same in this regard? Or in code, are these treated the same? x'' = sum l + product l where l = [1..10^6] x' = let l = [1..10^6] in sum l + product l I couldn't tell if the report implies that or not. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ m...@glyphic.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling?
On Dec 1, 2009, at 2:29 AM, Heinrich Apfelmus wrote: data Train a b = Wagon a (Train a b) | Loco b Surely that should be: data Train a b = Wagon a (Train a b) | Caboose b ? - MtnViewMark Mark Lentczner http://www.ozonehouse.com/mark/ m...@glyphic.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Partially applied functions
-- Here's a expansion of the ideas presented for tracking the argument used
-- to create a partially applied function:
--
-- Based on simple pairs
--
add :: Int - Int - Int
add x y = x + y
addr :: Int - (Int, Int - Int)
addr a = (a, add a)
-- a list of partially applied functions
adds = [addr 3, addr 5, addr 7, addr 3, addr 5, addr 8]
-- an example usage of the list
k = map (\ f - (snd f) 10 ) adds
-- filtering
add3s = filter (\ f - fst f == 3) adds
addEvens = filter (\f - even $ fst f) adds --addEvens = [add 8]
k3 = map (\ f - (snd f) 10) add3s
keven = map (\ f - (snd f) 10) addEvens
--
-- Generalized:
--
data TaggedPartial a b c = TAG a (b - c)
tag :: (a - b - c) - a - TaggedPartial a b c
tag f a = TAG a (f a)
-- create a tagged partially applied function
tap :: TaggedPartial a b c - b - c
tap (TAG _ f) b = f b
-- tagged partial function apply
ttest :: TaggedPartial a b c - (a - Bool) - Bool
ttest (TAG a _) f = f a
-- tagged tag test
tadds = [tag add 3, tag add 5, tag add 7, tag add 3, tag add 5, tag add 8]
tk = map (\ f - tap f 10) tadds
tadd3s = filter (\ f - ttest f (==3)) tadds
taddEvens = filter (\ f - ttest f even) tadds
tk3 = map (\ f - tap f 10) tadd3s
tkeven = map (\ f - tap f 10) taddEvens
--
-- The examples of map and filter usage, show that the arguments to
-- tap and ttest are awkwardly flipped. Hence:
--
pat :: b - TaggedPartial a b c - c
pat = flip tap
testt :: (a - Bool) - TaggedPartial a b c - Bool
testt = flip ttest
tk' = map (pat 10) tadds
tadd3s' = filter (testt (==3)) tadds
taddEvens' = filter (testt even) tadds
tk3' = map (pat 10) tadd3s'
tkeven' = map (pat 10) taddEvens'
{-
Mark Lentczner
http://www.ozonehouse.com/mark/
m...@glyphic.com
-}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary and error handling
I'm in the same quandary: Data.Binary from the binary package has no error handling Data.Serialize from the cereal package uses only strict ByteString I was going to add error handling to Binary as a weekend project (it isn't that hard), but when I contacted the developers of binary, I was pointed at cereal. But as my project can parse multi-megabyte objects off the wire, I really want lazy ByteString support. I understand from the cereal creators that lazy ByteStrings are not in the future of cereal, since they got a big speed boost by going to strict ByteStrings only. I understand that Bryan O'Sullivan might have done work on adding errors to Binary... Bryan? If that's available, can we get it? If not, shall I do the work to add error handling? It's a long weekend... I've got time! - Mark Mark Lentczner http://www.ozonehouse.com/mark/ m...@glyphic.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] surrogate code points in a Char
On Nov 18, 2009, at 7:28 AM, Manlio Perillo wrote: The Unicode Standard (version 4.0, section 3.9, D31 - pag 76) says: Because surrogate code points are not included in the set of Unicode scalar values, UTF-32 code units in the range D800 .. DFFF are ill-formed The current version of Unicode is 5.1. This text is now in D90, though otherwise the same. My references below are to the 5.1 documents (freely available on line at: http://www.unicode.org/versions/Unicode5.1.0/ ) However GHC does not reject this code units: Prelude print '\xD800' '\55296' Is this a correct behaviour? I don't think you should consider Char to be UTF-32. Think of Char as representing a Unicode code point. Unicode code points are defined as all in integers in the range \x0 through \x10, inclusive. Values in the range \xD800 through \xDFFF are all valid code points. (§2.4 in general; §3.4, D9, D10) Not all Unicode code points are Unicode scalar values. Only Unicode scalar values can be encoded in the standard Unicode encodings. Unicode scalar values are defined a \x0 through \xD7FF and \xE000 through \x10 - All code points except the surrogate pair area. (§3.9, D76) Not all code points are characters. In particular, \xFFFE, \x are Noncharacters: They are representable in Unicode encodings, but should not be interchanged. Less well known is the range \xFDD0 though \xFDEF which are also noncharacters. (§2.4, Table 2-3; §3.4, D14, §16.7) In particular, note the stance of Unicode toward application internal forms: Applications are free to use any of these noncharacter code points. internally but should never attempt to exchange them. - §16.7 ¶3 Accordingly, it is fine for Haskell's Char to support these values, as they are code points. The place to impose any special handling is in Haskell's various Unicode encoding libraries: When decoding, code points \xD800 through \xDFFF cannot be received, and noncharacters can be either retained or silently dropped (Unicode conformance allows this.) When encoding, code points \xD800 through \xDFFF and noncharacters should either error or just be silently dropped. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ m...@glyphic.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Coercing numeric and string constants
I'm looking for a good way to handle a library interface that accepts both
strings and numbers in particular argument positions:
Start with the following definitions. I've defined ResourceTree as a class here
since the details don't matter.
data Segment = Key String | Index Int
deriving (Eq, Show)
type Path = [Segment]
class ResourceTree a where
lookupPath :: Path - a - Maybe String
What I'm after is to make the following code, representative of intended client
usage to work:
examples :: (ResourceTree a) = a - [Maybe String]
examples r = [
r `at` status,
r `at` 7,
r `at` part ./ sku,
r `at` items ./ 2,
r `at` 7 ./ name,
r `at` 7 ./ 9
]
The first way I thought to do this was with type classes:
classSegmentable a where { toSegment :: a - Segment }
instance Segmentable Segment where { toSegment = id }
instance Segmentable String where { toSegment = Key }
instance Segmentable Int where { toSegment = Index }
classPathable a where { toPath :: a - Path }
instance Pathable Path where { toPath = id }
instance Pathable String where { toPath s = [ Key s ] }
instance Pathable Intwhere { toPath i = [ Index i ] }
(./) :: (Segmentable a, Pathable b) = a - b - Path
a ./ b = toSegment a : toPath b
infixr 4 ./
at :: (ResourceTree a, Pathable b) = a - b - Maybe String
a `at` b = lookupPath (toPath b) a
infix 2 `at`
This works great for all uses in the client code where the type of the numeric
arguments are known or otherwise forced to be Int. However, when used with
numeric constants (as in the function example above), it fails due to the way
that numeric constants are defined in Haskell. For example, the constant 9 in
example results in this error:
Ambiguous type variable `t4' in the constraints:
`Pathable t4' arising from a use of `./' at Test.hs:48:15-20
`Num t4' arising from the literal `9' at Test.hs:48:20
Probable fix: add a type signature that fixes these type variable(s)
I suppose that even though there is only one type that is both an instance of
Num and of Pathable (Int), that can't be deduced with certainty.
In the client code, one could fix this by typing the constants thus:
r `at` (7::Int) ./ (9::Int)
But to me that makes a hash out of the concise syntax I was trying to achieve.
Also, this code requires both FlexibleInstances and TypeSynonymInstances
pragmas (though the later requirement could be worked around.), though I'm lead
to understand that those are common enough. I think also that, these are only
needed in the library, not the client code.
The other way I thought to do this is by making Path and Segment instances of
Num and IsString:
instance Num Segment where { fromInteger = Index . fromInteger }
instance IsString Segment where { fromString = Key . fromString }
instance Num Pathwhere { fromInteger i = [ Index $ fromInteger i ] }
instance IsString Pathwhere { fromString s = [ Key $ fromString s ] }
(./) :: Segment - Path - Path
a ./ b = a : b
infixr 4 ./
at :: (ResourceTree a) = a - Path - Maybe String
a `at` b = lookupPath b a
infix 2 `at`
This works but has two downsides: 1) Segment and Path are poor instances of
Num, eliciting errors for missing methods and resulting in run-time errors
should any client code accidentally use them as such. 2) It requires the
OverloadedStrings pragma in every client module.
Any comments on these two approaches would be appreciated, How to improve them?
Which is the lesser of two evils?
On the other hand, I realize that many may object that intended interface isn't
very Haskell like. The data object I need to represent (ResourceTree) comes
from external input and really does have the strange paths of strings or
integers construction, I can't change that. And it is expected that much
client code will use constant paths to access and manipulate various parts of
such objects, hence the desire for a concise operator set that works with
constants. Given that there are actually several operations on ResourceTree
involving paths (where the operation requires the whole Path as a single
value), any thoughts on a more Haskell like construction?
Thanks,
- MtnViewMark
Mark Lentczner
http://www.ozonehouse.com/mark/
m...@glyphic.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What does the `forall` mean ?
On Nov 12, 2009, at 2:59 PM, Sean Leather wrote: foo :: forall x y. (x - x) - y bar :: forall y. (forall x . x - x) - y While neither function is seemingly useful, the second says that the higher-order argument must be polymorphic. I see two options: AHA! This is the bit of insight I needed! My confusion over forall was I thought that I understood that all Haskell types were as if there was a forall for all free type variables in front of the expression. For example, I think the following are the same: fizz :: a - String - [a] fizz :: forall a. a - String - [a] So why would you need forall? The example Sean explained is that if you want to control the scope of the existential quantification. And you can only push the scope inward, since the outer most scope basically foralls all the free type variables (after type inference, I suppose.) I also think I understand that the implicit 'forall' inherent in Haskell falls at different places in various constructs, which also had me confused. For example, while the above two function type declarations are equivalent, these two data declarations aren't: data Fizzle a = Fizzle (b - (a, b)) a data Fizzle a = forall b. Fizzle (b - (a, b)) a This would be because the implicit 'forall' is essentially to the left of the 'data Fizzle a' section. I'm guessing that the same holds true for type and newtype constructs. Have I got this all correct? Would I be correct in thinking: The difference between these two is that the type b can be fixed upon application of amy to the first two arguments (given context), whereas bob applied to two arguments MUST return a function that is applicable to every type. amy :: Int - a - b - [Either a b] bob :: Int - a - (forall b. b) - [Either a b] Thanks for helping me understand... - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghci REPL output under Haskell Platform on Mac OS X
On Nov 1, 2009, at 1:05 PM, Henning Thielemann wrote: I had a similar problem with Haskeline and an too old version of terminfo. I assume Haskeline is used by your GHC instead of readline. Aha! That led me to find it: I had TERM set to 'ansi'. ghci + Haskeline works find if TERM is set to any of rxvt, vt52, vt100, vt102 or xterm. Don't know what in terminfo Haskeline is relying on, but 'ansi' doesn't have it! - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ghci REPL output under Haskell Platform on Mac OS X
My ghci installation has a very annoying behavior: When it takes input, the result is displayed on the same line as the input, overwriting the prompt and input. Viz.: [1015] : ghci GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. 7relude 3 + 4 Prelude Note the 7 that overwrites the P in Prelude. I have had several prior versions of ghci installed, most recently 6.10.1, and they never had this problem. (In other words, I saw: Prelude 3 + 4 7 Prelude Those prior gchi's were installed from the GHC binaries. Most recently I decided to give Haskell Platform a try, and I installed that. That is the point at which this behavior started. My environment: Haskell Platform 2009.2.0.2 GHC 6.10.4 (installed w/Haskell Platform) Mac OS X 10.6.1 Oddly, I have GHC 6.10.4 installed from GHC binaries on a Mac OS X 10.5 machine at work, and the newline behavior is correct. So the issue could be Haskell Platform vs. GHC installs... or it could be 10.5 vs. 10.6 Anyone seen anything like this? - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
