August 2009 - Haskell-Cafe

Re: Thinking about what's missing in our library coverage
by Alexander Dunlap 13 Aug '09

13 Aug '09

On Mon, Aug 3, 2009 at 4:44 PM, Don Stewart<dons(a)galois.com> wrote: > > Following Simon M's advice, I look over the typical "batteries" > categories, using Python as input: > > http://docs.python.org/library/index.html > > The following things were missing from the current Platform. There are many. > How would you identify the top, say, 5 libs to add? > > -- Don > > > * String support > o pcre regexes [pcre-light] [regex-pcre] — what’s our best regex lib? For something like this, it seems like all of the regex libs probably have pros and cons. It would be good if we could identify what these are and create a library that was the "best of all worlds" instead of just picking one and going with it. > o unicode text [text] [text-icu] — packed, unicode text This is essential, although I don't know if it is stable enough for the platform (?). > * text > o pandoc — markdown, reStructuredText, HTML, LaTeX, ConTeXt, Docbook, OpenDocument, ODT, RTF, MediaWiki, groff No. Pandoc is too actively developed to go into the HP. It's also much more of an end-user application than a "standard library" - it's applications are not general enough to be included in the standard distribution. > * math and numerics > o blas — BLAS > o cmath — C math functions > o dimensional — physical dimensions > o fftw > o mersenne-random — fast randoms The interfaces here should be unified more to create a general Haskell numerical library, IMO. > * compression > o bzip2 > o zip > o tar Definitely. > * file formats > o config parser This would be quite useful. > * crypto > o hmac, md5, sha, hashing Yes. > * systems > o getopt > o logging > o termio > o editline > o mmap All of these, at some point. > * Internet > o network-bytestring > o ssl > o json > o feed (rss, atom) > o mime > o base64 et al > o uuencode > o cgi > o fastcgi > o urls > o ftp, http, imap, smtp clients > o uuid > o url parsing > o http server > o xml-rpc Interface unification would help. Especially network-bytestring seems to be too ad-hoc for me - it would probably be better to put ByteString support into the regular Network library.... > * Internationalization > o gettext > o locale > o i18n Yes, although again, maturity? > * Development > o hscolour Yes. My main concern is with libraries like attoparsec and network-bytestring - these libraries seem to be somewhat ad-hoc conversion of traditional libraries to use ByteStrings. We should come up with a cleaner, more elegant way of dealing with the String/Text/Strict ByteString/Lazy ByteSTring gap, as most libraries that apply to one of those types also apply to the other two, as the first two and last two especially and more generally all four essentially represent the same thing. We shouldn't bless libraries that don't have a good way of applying equally to these three. A possible solution could be a standardized package-common, package-string, package-text, package-bytestring, package-lazybytestring naming convention, or a Category.Module, Category.Module.String, Category.Module.ByteString.Strict, Category.Module.ByteString.Lazy, Category.Module.Text convention. We could also work something up with type classes. I just don't like how a lot of libraries implement support for various string types just based on need rather than creating a clean, comprehensive interface. Alex

14 25

IFL 2009: Final Call for Papers and Participation
by IFL 2009 13 Aug '09

13 Aug '09

1 0

unsafeDestructiveAssign?
by Job Vranish 13 Aug '09

13 Aug '09

Does anybody know if there is some unsafe IO function that would let me do destructive assignment? Something like: a = 5 main = do veryUnsafeAndYouShouldNeverEveryCallThisFunction_DestructiveAssign a 8 print a > 8 and yes I am in fact insane... I'm also looking for a way to make actual copies of data. so I could do something like this: a = Node 5 [Node 2 [], Node 5 [a]] main = do b <- makeCopy a veryUnsafeAndYouShouldNeverEveryCallThisFunction_DestructiveAssign b (Node 0 []) -- 'a' is unchanged It would be even more fantastic, if the copy function was lazy. I think the traverse function might actually make a copy, but I would be happier with something more general (doesn't require membership in traversable), and more explicit (was actually designed for making real copies). Any ideas? Thanks, - Job

10 13

Parallel Symbolic Computing Research Post
by Trinder, Philip W 13 Aug '09

13 Aug '09

The next generation of HPC platform will provide teraflop performance from 10^5 or more cores. A major challenge is to develop the programming models and software infrastructures to effectively exploit these architectures. In the HPC-GAP project (High Performance Computational Algebra and Discrete Mathematics EPSRC EP/G055181) we aim to address this challenge for the GAP Group Algebra package. You will join a team of four researchers in an ambitious programme to adapt the GAP computational algebra system to take advantage of modern high performance computers. You will collaborate with other HPC-GAP members at Aberdeen and St Andrews and Edinburgh Universities. You will take part in and publish research using the software you develop. You will have excellent parallel system engineering expertise, a degree in computer science, an appropriate PhD or equivalent, and good teamwork skills. Desirable criteria include functional language experience e.g. Haskell, a track record of academic publications, experience preparing research grant applications, and experience with a range of software technologies. You will start on 1 September 2009 and continue until the end of the grant in August 2013. Full details at www.jobs.ac.uk/jobs/SP072/Research_Associate_-_Parallel_Symbolic_Computi ng/ -------------------------------------------- Phil Trinder School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh, EH14 4AS E: P.W.Trinder(a)hw.ac.uk T: +44 (0)131 451 3435 F: +44 (0)131 451 3327 I: www.macs.hw.ac.uk/~trinder -- Heriot-Watt University is a Scottish charity registered under charity number SC000278.

1 0

Re: unsafeDestructiveAssign?
by John Lato 13 Aug '09

13 Aug '09

> From: John Meacham <john(a)repetae.net> > Subject: Re: [Haskell-cafe] unsafeDestructiveAssign? > On Wed, Aug 12, 2009 at 06:48:33PM +0100, John Lato wrote: > > On Wed, Aug 12, 2009 at 2:39 PM, Derek Elkins<derek.a.elkins(a)gmail.com> wrote: > > > > > > (To Alberto as well.) > > > > > > Unsurprisingly, Lennart stated the real issue, but I'll re-emphasize > > > it. Â As much trouble as such a profound violation of purity would > > > cause, it's not the biggest problem. Â If that were all, you could > > > easily write a C/assembly function that would do what was desired. > > > The real problem is that there isn't necessarily any "data chunk" at > > > all, i.e. there may not be anything to mutate. > > > > > > > Lennart is right of course, but wouldn't his example just be a > > specific case of my argument? That is, the compiler decided to > > evaluate the data at compile time by replacing it with the primitive > > value and inlining it? It seems to me that in the absence of putting > > some scope or sequencing upon the mutating function, there's no way > > for such an unsafeMutate* to have any defined meaning in Haskell. And > > once you have provided either scope or evaluation order, it would be > > equivalent to just using a monad (although not necessarily IO). > > > The inherent problem is that 'heap locations' are not first class values in > haskell. There is no way to refer to 'the location holding a variable', > not so much because they don't exist, but because it is just > inexpressible in haskell. for instance, Thanks for this clear explanation. The concept of an unsafeDestructiveAssign function really caught my attention because it seemed inexpressible. This makes perfect sense, including an explanation for mutable data in IO (because IORef, Ptr, and the like make a "data location" a first class value). I like to have a solid foundation for my nonsense. Cheers, John

1 0

DDC compiler and effects
by oleg＠okmij.org 13 Aug '09

13 Aug '09

Combining non-strict evaluation and even laziness (non-strictness plus sharing) with effects is of course possible. That is the topic of the ICFP09 paper of Sebastian Fischer et al., which describes the combination of laziness with non-determinism. The ideas of the paper have been implemented in a Hackage package and in the embedded probabilistic DSL Hansei. In the presence of effects, call-by-name is no longer observationally equivalent to call-by-need: one has to be explicit what is shared. Curry's call-time-choice seems a good choice: variables always denote values rather than computations and can be shared at will (of the run-time system). The language is still non-strict, and computations whose results are not demanded are not evaluated and none of their effects are performed. Since any computable effect can be modeled by delimited control, call-by-name shift/reset calculi provide general treatment of effects and non-strictness. Call-by-name delimited control calculi have been developed by Herbelin (POPL08). A different call-by-name shift/reset calculus (containing call-by-value calculus as a proper subset) is described in http://okmij.org/ftp/Computation/Continuations.html#cbn-shift The latter, cbn-xi, calculus includes effect sub-typing, which is common in effect calculi. A call-by-name function whose argument type is effectful can always be applied to a pure term. A pure term can be regarded as potentially having any effect. On the other hand, a function whose argument type is pure can only be applied to a pure term. The cbn-xi calculus also supports strict functions. Their argument type is always a pure type and they can be applied to terms regardless of their effect, because the effect will occur before the application. Pure functions thus provide a measure of effect-polymorphism. The cbn-xi and the other CBN calculi with delimited control are deterministic. The best application for the cbn-xi calculus I could find was in linguistics. The calculus was used to represent various effects in natural language: quantification, binding, raised and in-situ wh-questions. Importantly, several effects -- several question words, anaphora with quantification, superiority -- could be represented. One may view ML and Haskell as occupying two ends of the extreme. ML assumes any computation to be effectful and every function to have side effects. Therefore, an ML compiler cannot do optimizations like reordering (even apply commutative laws where exists), unless it can examine the source code and prove that computations to reorder are effect-free. That obviously all but precludes separate compilation; the only aggressive optimizing ML compiler, MLton, is a whole-program compiler. Haskell, on the other hand, assumes every expression pure. Lots algebraic properties become available and can be exploited, by compilers and people. Alas, that precludes any effects. Hence monads were introduced, bringing back control dependencies disguised as a data dependency. Monadic language forms a restrictive subset of Haskell (for example, we can't use monadic expressions in guards, `if' and `case' statements). In the monadic sublanguage, Haskell swings to another extreme and assumes, like ML, that everything is impure. Thus in an expression, do x <- e1 y <- e2 ... the two binding cannot be commuted, even if e1 and e2 are both 'return'. If the compiler sees the source code of e1 and e2 and is sufficiently smart to apply monadic laws, the compiler can determine the two bindings can be reordered. However, if e1 and e2 are defined in a separate module, I don't think that any existing compiler would even think about reordering. Hopefully a system like DDC will find the middle ground.

1 0

Working around file locking in Windows
by Patai Gergely 13 Aug '09

13 Aug '09

Hello all, I'm trying to make the hp2any suite to be fully functional under Windows, but I'm running into permission errors when I try to read the heap profile that's still being written by its producer. Is there a way to solve this problem without turning to the Win32 interface and having to write platform specific code? Gergely -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html

2 1

unsafeDestructiveAssign?
by John Lato 13 Aug '09

13 Aug '09

Hi Job, I don't think this hypothetical function could exist; you may as well call it "notEverSafeOhTheHumanity" and be done with it. Since Haskell provides no guarantees about when (if ever) any given function/data will be evaluated, you would need some mechanism to tell the compiler that a data chunk has a certain value at one time and a different value at another. The language provides this in the IO (and ST) monads. So the function would need to live within IO, and you don't gain anything. If you try to take it outside of IO, with e.g. unsafePerformIO, then the compiler will no longer treat it like IO and the result is free to be evaluated whenever, so you're back where you started. Also, keep in mind that purity is a language requirement in Haskell and such a function really would "break everything". Specifically, you would get differing output depending on the exact transformations performed by the compiler, which in general would be difficult to predict in advance, probably not the same between different compiler versions, changed by compiler flags and phases of the moon, etc. I have an example in a darcs repo somewhere... Cheers, John > From: Job Vranish <jvranish(a)gmail.com> > Subject: Re: [Haskell-cafe] unsafeDestructiveAssign? > > Ga! Before to many people start flooding me responses of "This is really > dumb idea don't do it!" I would like to clarify that for the most part > IKnowWhatI'mDoing(TM) > > I am well aware of the usual ST/IORefs as the usual solutions to data > mutability in haskell. > I very very much understand purity, and why it is a good thing, and why we > should try to stay away from IO and ST as much as possible. > I am very much away that even if I had such a function that it will probably > break everything. > I am not just trying to make things run faster. > > What I am trying to do is hyper unusual and I really do need an > unsafeHorribleThings to do it. > > - Job

4 4

ANNOUNCE: GLFW-0.4.1
by Paul L 13 Aug '09

13 Aug '09

I'm glad to announce a new version of GLFW, 0.4.1, has been uploaded to HackageDB. Notable changes include: * workaround for a FFI bug that affects GHC < 6.10 on 64-bit machines. * fix for the compilation problem on OS X for GHC > 6.10.1 * compatibility fix to work with both OpenGL 2.3.0.0 and older versions. * choice of a "dynamic" flag to link with dynamic GLFW C library instead. * a number of other fixes, cleanups and improvements. Many thanks goes to Brian Lewis, Sönke Hahn, and other people who sent in bug reports, patches, and suggestions. If you have any problem with this new version, you can either reply this email, or send to my other account (paul at thev.net) -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale

1 0

Chicago Haskell User Group?
by Tom Tobin 13 Aug '09

13 Aug '09

There isn't a Chicago-area Haskell group, is there? If not, would anyone be interested in forming one? I used to run Chicago's Django (a Python web framework) group, but lost interest (and since I lived in the suburbs back then, got sick of the commute). Unlike Python, I'm still very much a beginner with Haskell, so I feel I'd be able to benefit quite a bit from picking the brains of more skilled users and cooperating with other beginners. My particular interests are web development (as that's my professional field) and multimedia organization (I'm working on a Haskell audio tagging library to help teach myself the language), but I'm open to learning just about anything. :-)

4 8