September 2008 - Haskell-Cafe

Is it usual to read a Maybe (IORef a) ?
by minh thu 05 Sep '08

05 Sep '08

Hi, I'd like to write a data structure to be used inside the IO monad. The structure has some handles of type Maybe (IORef a), i.e. IORef are pointers and the Maybe is like null pointers. So I came up with the following functions : readHandle :: Maybe (IORef a) -> IO (Maybe a) readField :: (a -> b) -> Maybe (IORef a) -> IO (Maybe b) readHandle Nothing = do return Nothing readHandle (Just r) = do v <- readIORef r return $ Just v readField f h = do m <- readHandle h return $ fmap f m Is it something usual ? Are there any related functions in the standard libraries ? Thanks, Thu

10 13

Re: [Haskell-cafe] Re: [Haskell] Top Level <-
by Ganesh Sittampalam 05 Sep '08

05 Sep '08

On Sun, 31 Aug 2008, Adrian Hey wrote: > Ganesh Sittampalam wrote: >> On Sun, 31 Aug 2008, Adrian Hey wrote: >> >>> Thanks for taking the time to do this Dan. I think the safety requirement >>> has been met, but I think it fails on the improved API. The main complaint >>> would be what I see as loss of modularity, in that somehow what should be >>> a small irrelevant detail of the implementation of some obscure module >>> somewhere has propogated it's way all the way upto main. >> >> That's the key point, as I see it - they aren't "irrelevant details of the >> implementation", they are requirements the implementation places on its >> context in order for that implementation to be correct. So they should be >> communicated appropriately. > > Eh? Please illustrate your point with Data.Unique. What requirements > does it place on it's context? (whatever that might mean :-) It requires that its context initialises it precisely once. Data.Unique is actually a poor example, as it is actually fine to initialise it multiple times as long as the resulting Unique values aren't treated as coming from the same datatype. But equally it can be implemented with IORefs, so it's not a good advert for the need for global variables. > The real irony of your remark is that making APIs this robust is > practically impossible *without* using global variables, and you're > now saying that because they've done this work to eliminate these > constraints they now have to be held to account for this with > an absurd API. I think there are two cases to consider here. A Data.Unique style library, which requires genuinely *internal* state, and which is agnostic to having multiple copies of itself loaded simultaneously. In that case, there is no requirement for a process-level scope for <-, just that each instance of the library is only initialised once - the RTS can do this, as can any dynamic loader. The other is some library that really cannot be safely loaded multiple times, because it depends on some lower-level shared resource. Such a library simply cannot be made safe without cooperation from the thing that controls that shared resource, because you cannot prevent a second copy of it being loaded by something you have no control over. If the <- proposal were only about supporting the first of these applications, I would have far fewer objections to it. But it would have nothing to do with process-level scope, then. Ganesh

5 11

Categorical language
by Maurício 04 Sep '08

04 Sep '08

Hi, I’ve been thinking about this and would like your opinion: what could be a “categorical language”? Something like a language where categories and functors are first class; does that makes sense at all? (Sorry if this is insane, I'm a begginer in categories, I've read just the first chapter of Mac Lane's book.) Thanks, Maurício

4 3

Linux version of ghc-6.8.3 won't intall or run for me: "Floating point exception".
by Alan Mackenzie 04 Sep '08

04 Sep '08

Hi, Haskell! I've downloaded the ghc-6.8.3-i386-unknown-linux.tar.bz2 tarball, which I expected to work on my GNU/Linux box (1.2 GHz Athlon, Debian Sarge). I'm new at this game, though I'm thoroughly experienced with (and bear deep battle scars from) GNU software in general. ./configure fails with "checking for path to top of build tree... configure: error: cannot determine current directory". This has been reported before in this list, but I don't think anybody ever explained the fault. Further delving finds that the following statement in the configure script triggers it: hardtop=`utils/pwd/pwd forwardslash` . utils/pwd/pwd, no matter how I call it, always crashes with "Floating point exception". Surely real numbers aren't involved in determining a configuration - probably some floating point library or other is missing from my system. What is utils/pwd/pwd? What's its purpose? It's 460kB large (compared with 14kb for /bin/pwd). Is it a haskell implementation of Unix's pwd, primarily intented for non-unixy OSs? configure is supposed to ascertain my machine's config, so it's particularly disappointing that it crashes because my config isn't what it expects. Should I report this as a bug? ######################################################################### Anyhow, I hacked the configure script by replacing the above line by a hard-coded value, thusly: hardtop=/home/acm/haskell/ghc-6.8.3 , and the configure script finished. ;-) So I did "make install", and the turgid messages rolled up my screen until it crashed, the last few lines being: nstall/lib/ghc-6.8.3"' -DPKG_DATADIR='"/home/acm/haskell/ghc-install/share/ghc-6.8.3"' package.conf.in \ | grep -v '^#pragma GCC' \ | sed -e 's/""//g' -e 's/:[ ]*,/: /g' \ | /home/acm/haskell/ghc-6.8.3/utils/ghc-pkg/ghc-pkg.bin --global-conf /home/acm/haskell/ghc-install/lib/ghc-6.8.3/package.conf update - --force make[1]: *** [install] Error 136 make[1]: Leaving directory `/home/acm/haskell/ghc-6.8.3/rts' make: *** [install] Error 2 Ah yes! Error 136. ;-) Don't we just love GNU bread and butter software? It's not documented on the install man page either - or the info page. Neither is Error 8. Hey, you've all been through this too: enthusiasm -> 0 as t -> infinity. :-( ######################################################################### So, I thought, who needs to install? It's a binary package, so somewhere there's going to be a top-level callable program, probably called something like "ghc". Hey, yes, compile/Stage3/ghc-6.8.3. Guess what: "Floating point exception". :-( I hate binary packages - I utterly loathe them. They never work. At least they never work for me. Or the distro package manager stuffs your cron config with resource hoggers you really don't want, and forgets to ask you first. I suppose they might work if your OS has been installed or updated within the last few months; otherwise, forget it. Source distributions are so much faster and easier to install because the cranial clutter you have to cope with is that much less. Trouble is, to build haskell from source, you need a working haskell to build it with. Presumably, sometime in the recent past (as measured on archaeological time scales), ghc was bootstrapped from C (or some other lowest common denomiator language). Is this route still available? Some proto-proto haskell written in C, sufficiently powerful to build a proto-haskell, sufficiently powerful to build the compiler? ######################################################################### I'd really love to play with haskell. But the time I've wasted so far, trying to get it working, is almost at the stage where I just can't be bothered any more. I've been here before, and I can see that I've got 1 - 3 days x 8 hours of grinding drudgery before I finally get ghc-6.8.3 working. I suppose that's just the way GNU systems are. If anybody could give me some tips as to getting a decent haskell running on my system in a reasonable, predictable amount of time, in a way which doesn't involve diagnosing and fixing problems, I'd be very grateful indeed. Thanks! -- Alan Mackenzie (Nuremberg, Germany).

5 7

Consequences of implementing a library in Haskell for C consumption?
by Justin Bailey 04 Sep '08

04 Sep '08

I am thinking of writing a simple library in Haskell which would be useful in a number of different scenarios, and not always with programs written in Haskell. That makes me think the library should be C-compatible and able to link with C programs. Reading over chapter 9 of the GHC manual ("Foreign function interface"), it seems simple to do. However, what are the consequences of such an implementation? Would any program using my library need to link the entire GHC runtime? The library will not expose any higher-order functions or other business. It would be straightforward but tedious to write in C, which is why I'd rather use Haskell. Thanks in advance for any thoughts. Justin

2 1

Parsec 3 Description
by John Van Enk 04 Sep '08

04 Sep '08

I'm looking for a document describing the differences between Parsec 3 and Parsec 2. My google-foo must be off because I can't seem to find one. Does any one know where to find that information? -- /jve

3 4

Compiler's bane
by Andrew Coppin 04 Sep '08

04 Sep '08

Hi guys. I'm writing a simple interpretter for a small extended-lambda-calculus sort of language. And I'd just like to say... RECURSIVE LET-BINDS! GAAAAH!!! >_< No other part of the program has consumed nearly as much brain power as me trying to figure out when it is and isn't safe to replace a variable with its RHS. To illustrate: let x = f x; y = 5 in x y A simple-minded interpretter might try to replace every occurrance of "x" with "f x". This yields let y = 5 in (f x) y ...and x is now a free variable. OOPS! Trying to tease out exactly under which conditions you can and cannot perform the substitution is utterly maddening. Since this is a Haskell mailing list and as such it is populated by vast numbers of people with PhDs and so forth... does anybody happen to know the *correct* solution to this conundrum? Before I become clinically insane...? o_O By the way... To all those people who work on projects like GHC and so on, who have to get this stuff right "for real": you have my infinite respect!

10 29

[POPL logo design contest]
by Don Stewart 04 Sep '08

04 Sep '08

This sounds relevant to our interests... ----- Forwarded message from Swarat Chaudhuri <swarat(a)cse.psu.edu> ----- Date: Thu, 04 Sep 2008 09:13:55 -0400 From: Swarat Chaudhuri <swarat(a)cse.psu.edu> To: types-list(a)lists.seas.upenn.edu Subject: [TYPES] POPL logo design contest [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ] Dear POPL community members: We know that you are all holding your breath for POPL 2009; here's some diversion to take your mind off the wait. We are planning to select a logo for POPL---after all, if the Olympics can have one, why not us? Accordingly, we announce the first-ever Contest on POPL Logo Design and Implementation (not to be confused with the other, gentler PLDI). Participants should send submissions in jpg, gif or png formats to Swarat Chaudhuri (swarat at cse.psu.edu) by November 20, 2008. The submission should contain: 1) A logo that doesn't mention the year (e.g., 2010) of the conference. 2) Logos mentioning the years 2010, 2011, and 2012. The contest will be judged by: * Luca Cardelli (Microsoft Cambridge) * Benjamin Pierce (Penn) * Shriram Krishnamurthi (Brown) We do not currently need high-resolution images, but will request them from the winner(s). From 2010 on, the logo will appear on POPL's webpage---in addition to the winning logo, the POPL 2010 webpage will also link to any other logo the judges find noteworthy. The winner(s) and runners-up will be presented t-shirts and cookies during the PC Chair's presentation at POPL 2009. So here's to citius, altius, etc. Get your design juices flowing! Best, Swarat Chaudhuri (Penn State) Publicity chair POPL 2010-2012 ----- End forwarded message -----

1 0

Haskell and i18n (aka gettext) support
by Gour 04 Sep '08

04 Sep '08

Dear Haskellers, Some time ago the question was asked on gtk2hs mailing list about how to work with *.po files, i.e. how to make Haskell program i18n-aware. (see http://thread.gmane.org/gmane.comp.lang.haskell.gtk2hs/592) The answer was that Gtk2hs does not have gettext support (http://article.gmane.org/gmane.comp.lang.haskell.gtk2hs/593) but that it is something which is needed (http://article.gmane.org/gmane.comp.lang.haskell.gtk2hs/598) but it's not clear how to do it. As potential 'solution the 'i18n' package was mentioned (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/i18n) with the remark that its API is not the most beautiful. Moreover, by looking at i18n's *.cabal file one can see it is labelled as 'experimental'. Moreover, if one inspects GNU gettext manual one can see the list of languages with the explanations how to make the program i18n-ready. The list is, unfortunately, without Haskell: * C: C, C++, Objective C * sh: sh - Shell Script * bash: bash - Bourne-Again Shell Script * Python: Python * Common Lisp: GNU clisp - Common Lisp * clisp C: GNU clisp C sources * Emacs Lisp: Emacs Lisp * librep: librep * Scheme: GNU guile - Scheme * Smalltalk: GNU Smalltalk * Java: Java * C#: C# * gawk: GNU awk * Pascal: Pascal - Free Pascal Compiler * wxWidgets: wxWidgets library * YCP: YCP - YaST2 scripting language * Tcl: Tcl - Tk's scripting language * Perl: Perl * PHP: PHP Hypertext Preprocessor * Pike: Pike * GCC-source: GNU Compiler Collection sources Real World Haskell book is at the door and it will bring army of new Haskell programmers to find out that Haskell misses one of the important items in its "battery set". :-( So, we think that i18n issue or proper gettext support should have a stable and well documented implementation and has to be part of "batteries included" or Haskell Platform (http://www.haskell.org/haskellwiki/Haskell_Platform) However, don't ask me 'how' :-D We got some hints on the IRC yesterday, but considering it is important issue for the whole Haskell community, we are bringing it here so that smarter and more skillful (than ourselves) souls can discuss it. I hope you are not seeing it as critique of the Haskell, but rather as attempt to improve our beloved language with the feature necessary to be included in the arsenal of every general programming language. Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ----------------------------------------------------------------

2 1

Research language vs. professional language
by Ryan Ingram 03 Sep '08

03 Sep '08

Jonathan, I think we are going to end up just disagreeing on this subject, but I'd like to point out the reasons why we disagree. On Sun, Aug 31, 2008 at 7:27 PM, Jonathan Cast <jonathanccast(a)fastmail.fm> wrote: > This concept of `day-to-day work' is a curious one. Haskell is not a > mature language, and probably shouldn't ever be one. I see where you are coming from here, but I think that train has already started and can't be stopped. I find Haskell interesting as a professional programmer for these four reasons: it's pure, it's functional, it's lazy, and it's got a great compiler. I don't know of any other "mature" language that can fill these shoes; Haskell is the most mature of them. If I'm missing another language that fits my requirements and would be better for day-to-day programming, let me know! The serious competitors I can see are Clean (Hackage blows away anything I've seen from that community) and O'CaML, which is neither pure nor lazy. Meanwhile, Haskell is getting more suitable for regular "professional" use every day. Look at the success of Hackage and the soon-to-be-published "Real World Haskell" book for evidence. Haskell solves many of the problems I have with existing languages today, and makes me a better programmer at the same time. > There will always be new discoveries in purely functional programming, > and as the art advances, features like this ad-hoc overloading hack > (and ACIO) will become obsolete and have to be thrown over-board. This is a good point. However, it seems to me that the pure programming language research is moving towards dependently typed languages, and that progress in Haskell has been more application-side; transactional memory and data-parallel, along with research on various fusion techniques, for example. I also think ACIO is a good theoretical starting point for research on what initialization means, and has potential for work to influence the commutative monads problem in general which could improve the syntax and number of lines of code devoted to working around the verbosity of effectful computations in Haskell. > I'd rather (much rather!) people concerned with day-to-day programming > for writing programs people actually use incorporate Haskell's features > into other, more practical, languages (as those who *actually* care about > such things are) rather than incorporating features from day-to-day > production languages into Haskell. This is already happening, of course; I think ML is going to become pure soon, although I don't think it will ever be non-strict. And I predict that within the next few years, lots of languages will be leaning heavily on the concurrency research that is going on in Haskell right now. But Haskell's community is also growing and becoming more results-oriented. If you want to blame someone for this, Don Stewart is probably your guy :) I'm just one of the johnny-come-latelies who is realizing what a great tool Simon and the rest of the ghc team has built. So, my question for you is: if Haskell is a research language, what direction should it be taking? What changes should be happening at the language (not the library) level that are in the interests of improving the state-of-the-art in functional programming? My goal is to make it not be a joke when I go to work and suggest that we use Haskell for part of our next project. What is yours? -- ryan

7 7