Re: [Haskell-cafe] ANNOUNCE: text 0.8.0.0, fast Unicode text support
On 1 September 2010 15:14, John Millikin jmilli...@gmail.com wrote: [aside] does anybody know how to get a list of what packages somebody's uploaded to Hackage? I think I've updated all mine for the new text version dependency, but I'm worried I forgot some. Unfortunately, no; I've often wished the same thing (not for my packages, but because I could have sworn someone uploaded a package that did something, I remembered the maintainer but not the name of the package...). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: text 0.8.0.0, fast Unicode text support
On Wed, Sep 1, 2010 at 07:14, John Millikin jmilli...@gmail.com wrote: Don't forget, you can always improve the text library yourself. I love to receive patches, requests for improvement, and bug reports. Are there any areas in particular you'd like help with, for either library? I'm happy to assist any effort which will help reduce use of String. As a Haskell noob I'm curious about this statement, is there something intrinsically wrong with String? Or is it more a performance/resource problem when dealing with large amounts of text for example? (Like having to use StringBuilder in Java if you want to avoid the penalty of repeated String allocations when simply concatenating for example) Cheers, -Tako ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Statically tracking validity - suggestions?
does anybody know of anything on Hackage for testing whether two values are approximately equal? http://hackage.haskell.org/package/approximate-equality -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: text 0.8.0.0, fast Unicode text support
2010/9/1 Tako Schotanus t...@codejive.org: As a Haskell noob I'm curious about this statement, is there something intrinsically wrong with String? String is just a linked list of Char which are unicode code points; which is probably not the optimal way to store text. For intensive use of text it takes too much memory, and/or it's not fast enough. Sometimes I'd love if I could program using String and the compiler would automatically convert that to Text, or Bytestrings, but of course it's wishful thinking. David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: text 0.8.0.0, fast Unicode text support
Hi Tako, The issues involved with String, ByteString, Text and a few related libraries were discussed at great length recently in this thread: http://groups.google.com/group/haskell-cafe/browse_thread/thread/52a21cf61ffb21b0/ Basically, Chars are 32 bit integers and Strings are represented as a list of Chars. This is very convenient for small computations but often very inefficient for anything large scale. The String API is also missing various encoding related features. Because of the limitations of String, various alternative libraries have been proposed. Text is one important option. You'll find much more detail on the above referenced thread. Kevin On Sep 1, 8:13 am, Tako Schotanus t...@codejive.org wrote: On Wed, Sep 1, 2010 at 07:14, John Millikin jmilli...@gmail.com wrote: Don't forget, you can always improve the text library yourself. I love to receive patches, requests for improvement, and bug reports. Are there any areas in particular you'd like help with, for either library? I'm happy to assist any effort which will help reduce use of String. As a Haskell noob I'm curious about this statement, is there something intrinsically wrong with String? Or is it more a performance/resource problem when dealing with large amounts of text for example? (Like having to use StringBuilder in Java if you want to avoid the penalty of repeated String allocations when simply concatenating for example) Cheers, -Tako ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://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] Re: questions about Arrows
On Tue, 2010-08-31 at 20:39 -0700, Ben wrote: Hello -- Three related questions, going from most specific to most general : 1 ) Consider the stream processing arrow which computes a running sum, with two implementations : first using generic ArrowCircuits (rSum); second using Automaton (rSum2) : module Foo where import Control.Arrow import Control.Arrow.Operations import Control.Arrow.Transformer import Control.Arrow.Transformer.All rSum :: ArrowCircuit a = a Int Int rSum = proc x - do rec out - delay 0 - out + x returnA - out rSum2 = Automaton (f 0) where f s n = let s' = s + n in (s', Automaton (f s')) runAuto _ [] = [] runAuto (Automaton f) (x:xs) = let (y, a) = f x in y : runAuto a xs take 10 $ runAuto rSum [1..] [0,1,3,6,10,15,21,28,36,45] take 10 $ runAuto rSum2 [1..] [1,3,6,10,15,21,28,36,45,55] Note that the circuit version starts with the initial value zero. Is there a way to write rSum2 in the general ArrowCircuit form, or using ArrowLoop? rSum2 :: ArrowCircuit a = a Int Int rSum2 = proc x - do rec out - delay 0 - out + x returnA - out + x 2) Are the ArrowLoop instances for (-), Kleisli Identity, and Kleisli ((-) r) all morally equivalent? (e.g., up to tagging and untagging?) Yes 3) One can define fix in terms of trace and trace in terms of fix. trace f x = fst $ fix (\(m, z) - f (x, z)) fix f = trace (\(x, y) - (f y, f y)) undefined Does this mean we can translate arbitrary recursive functions into ArrowLoop equivalents? Yes. In fact fix is used on functional languages that do not support recursion to have recursion (or so I heard) Best regards, Ben Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Three new implementations of multi-prompt delimited control
The monadic framework for delimited continuations described in the paper by Dybvig, Peyton Jones and Sabry (JFP 2007) has found many applications, for example, fair backtracking search, final zippers, direct-style web programming, direct-style code generation, and probabilistic programming. The extensive experience suggested improvements in efficiency and, mainly, programmer's convenience. The three new libraries are novel implementations of the enhanced framework. Prompts, for instance, can now be bound to top-level identifiers and do not have to be passed around explicitly or through the extra Reader monad. The new libraries benefited from the experience of implementing delimited control on several platforms. All three libraries provide monad transformers, with basic operations to capture and reinstall delimited continuations: pushPrompt, shift, shift0, control, takeSubCont/pushSubCont. All three libraries support multiple, typed prompts. All three libraries are quite distinct from the original implementation in Dybvig, Peyton Jones, Sabry's paper. For instance, none of the new libraries use unsafeCoerce. All three implementations are derived from the specification of delimited control: from the reduction semantics or from the definitional interpreter. The new libraries differ in -- performance -- ease of understanding -- constraints on the base monad or the prompt types -- flavors of prompts and support for global prompts The libraries are named CCRef, CCExc and CCCxe. The complete code of the libraries along with the regression test suite are publicly available at http://okmij.org/ftp/continuations/CCmonad/ The directory includes sample code (Generator1.hs and Generator2.hs), implementing generators like those of Python. A more extensive example is the porting of the LogicT library (of fair backtracking monad transformers), from the old CC implementation to CCExc/CCCxe: http://okmij.org/ftp/Haskell/LogicT.tar.gz One of the sample applications of LogicT, of a computer playing 5x5 tic-tac-toe against itself, was used as a macro-benchmark of the libraries. The end of the file TicTacToe.hs summarizes the results. The new libraries are faster (so the reader who may wish to play will have less time to think). The library CCRef is closest to the interface of Dybvig, Peyton Jones and Sabry. CCRef is derived from the definitional interpreter using the implementation techniques described and justified in the FLOPS 2010 paper. The monad transformer CC implemented by CCRef requires the base monad to support reference cells. In other words, the base monad must be a member of the type class Mutable: that is, must be IO, ST, STM or their transformer. CCRef adds to the original interface the frequently used function abortP as a primitive. As one may notice from their names, the libraries CCExc and CCCxe are closely related. CCCxe is derived as a CPS version of CCExc. CCCxe is sometimes more efficient; it is always less perspicuous. Both libraries provide the identical interface and are interchangeable. It seems that CCExc is faster at delimited control but imposes more overhead on the conventional code; CCCxe is dual. It pays to use CCCxe in code with long stretches of determinism punctuated by fits and restarts. We now explain new features of CCExc. It is the most direct implementation of the bubble-up (bottom-up) reduction semantics of multi-prompt delimited control, described on PDF page 57 of http://okmij.org/ftp/gengo/CAG-talk.pdf Unlike all other implementations of delimited control in Haskell, CCExc is _not_ based on the continuation monad. Rather, the monad of CCExc is an extension of the Error monad: a monad for restartable exceptions. CCExc offers not one monad transformer but a family (CC p), parameterized by the prompt flavor p. The library defines several prompt flavors; the users are welcome to define their own. Prompt flavors are inherently like exception flavors (the FLOPS 2010 paper even calls prompts `exception types' or `exception envelopes'). Control.Exception defines singular global exceptions such as BlockedOnDeadMVar. There are global exceptions like ErrorCall, parameterized by the error string. There are closed global variants, such as ArithException, with the fixed number of alternatives. There are also open variants, SomeException, with any number of potential alternatives. Users may define their own exception types, whose visibility may be restricted to a module or a package. Finally, one may even generate distinct expression types dynamically, although that is seldom needed. The libraries CCExc and CCCxe support all these flavors. On one end is the prompt flavor (PS w). There is only one prompt of that flavor, which is globally defined and does not have to be passed around. The monad transformer (CC (PS w)) then is the monad transformer for regular, single-prompt delimited continuations, for the answer-type w. Danvy/Filinski test, which looks in
Re: [Haskell-cafe] :Trace has no history
The debugger only instruments interpreted code, so evaluations occurring inside library code do not show up in :trace. This is not a terrible problem in practice, since usually seeing the evaluations occurring in your code is what you need to debug the problem. But since :trace is not showing you any evaluations at all, I wonder if the problem might be that your code is not interpreted. In order to ensure that it is, delete all the *.hi and *.o temporary files lying around. You can also simply invoke ghci with the -fbyte-code command line option. If that fails, please complete the paste of your session below with your invocation of ghci. There might be something else going on. Thanks, pepe On Wednesday, September 1, 2010, Steve Severance st...@medwizard.net wrote: How do I tell? Does this mean that if the exception is occurring in a haskell library I can't get to it? I am trying to run down a Prelude.read: No Parse error and I need to see the value that it is failing to parse on. Thanks. Steve On Tue, Aug 31, 2010 at 11:05 AM, Pepe Iborra pepeibo...@gmail.com wrote: Hi Steve The debugger only traces calls in interpreted code. Perhaps the call to myMethod is being made from object code? Admittedly, the ghci debugger can take some effort to learn to use properly. Make sure that you give a look to the ghc user guide if you haven't done so yet. Best, pepe On Tuesday, August 31, 2010, Steve sseve...@gmail.com wrote: I am trying to debug a problem in GHCI. I invoke my method with trace but when it breaks on exception i can't get this history. Output is below. Thanks. relude Symbols :set -fbreak-on-exception Prelude Symbols :trace myMethod Loading package HUnit-1.2.2.1 ... linking ... done. Loading package syb-0.1.0.2 ... linking ... done. Loading package base-3.0.3.2 ... linking ... done. Loading package old-locale-1.0.0.2 ... linking ... done. Loading package time-1.1.4 ... linking ... done. Loading package random-1.0.0.2 ... linking ... done. Loading package QuickCheck-1.2.0.0 ... linking ... done. Loading package Decimal-0.1.0 ... linking ... done. Loading package array-0.3.0.0 ... linking ... done. Loading package Diff-0.1.2 ... linking ... done. Loading package bytestring-0.9.1.5 ... linking ... done. Loading package containers-0.3.0.0 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package old-time-1.0.0.3 ... linking ... done. Loading package convertible-1.0.9 ... linking ... done. Loading package utf8-string-0.3.4 ... linking ... done. Loading package HDBC-2.2.6 ... linking ... done. Loading package HDBC-mysql-0.6.3 ... linking ... done. Loading package parsec-2.1.0.1 ... linking ... done. Loading package network-2.2.1.7 ... linking ... done. Loading package HTTP-4000.0.9 ... linking ... done. Loading package binary-0.5.0.2 ... linking ... done. Loading package digest-0.0.0.8 ... linking ... done. Loading package filepath-1.1.0.3 ... linking ... done. Loading package unix-2.4.0.0 ... linking ... done. Loading package directory-1.0.1.0 ... linking ... done. Loading package pretty-1.0.1.1 ... linking ... done. Loading package zlib-0.5.2.0 ... linking ... done. Loading package zip-archive-0.1.1.6 ... linking ... done. Loading package Core-0.0.1 ... linking ... done. Beginning Update Stopped at exception thrown _exception :: e = GHC.Exception.SomeException (GHC.Exception.D:Exception _ (GHC.Show.D:Show ...) ) (GHC.IO.Exception.IOError Nothing GHC.IO.Exception.UserError ) [exception thrown] Prelude Symbols :history Empty history. Perhaps you forgot to use :trace? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- -- José Iborra http://www.dsic.upv.es/~jiborra -- UPV Valencia Telf. (+34) 96 387 00 00 (ext) 83529 -- Camino de Vera s/n. 46022 Valencia (Spain) -- Steve Severance c. 240.472.9645 e. st...@medwizard.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- -- José Iborrahttp://www.dsic.upv.es/~jiborra -- UPV Valencia Telf. (+34) 96 387 00 00 (ext) 83529 -- Camino de Vera s/n. 46022 Valencia (Spain) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Projects that could use student contributions?
Brent Yorgey byorgey at seas.upenn.edu writes: Hi all, This fall I'll be teaching a half-credit introduction to Haskell to some undergrads. As a final project I am thinking of giving them the option of (instead of developing some program/project of their own) contributing to an existing open-source Haskell project. Of course, this requires the existence of projects they could contribute to. I'm sure they exist, but need your help to figure out what they are. So, do you maintain, or know of, any projects with the following characteristics? * might conceivably be interesting to undergraduate CS majors * simple enough that someone could make some non-trivial contributions in the space of 3 or 4 weeks * could use some help! This is a little non-traditional, so we'll see how it goes! -Brent Hi Brent, The following projects might be of interest: HCodecs * Description: A library to read, write and manipulate MIDI, WAVE, and SoundFont2 files. * Hackage Package: http://hackage.haskell.org/package/HCodecs * Git repository: http://github.com/giorgidze/HCodecs * Possible tasks: Add more codecs and/or improve the performance of existing codecs * Student will learn/use: Monadic parser combinators, parsing of binary data, how to test Haskell code using QuickCheck and HPC YampaSynth * Description: Software synthesizer * Hackage Package : http://hackage.haskell.org/package/YampaSynth * Git Repository: http://github.com/giorgidze/YampaSynth * Possible tasks: Add new audio filters and generators, use in other reactive applications, improve performance * Student will learn/use: Programming with arrows, Functional Reactiver Programming (FRP) in Yampa, audio synthesis Cheers, George ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: text 0.8.0.0, fast Unicode text support
Hi Kevin, thanks for the pointer, although I was aware of the thread and had followed it quite closely, it was quite interesting. But it never explained if and why String should be avoided, all I read is test and decide depending on the circumstances, which in itself is good advise, but I'd like to have an idea of the reasons so I can form in idea before actually having to code any benchmarks :) Knowing that String literally is a linked list of Char makes it a lot clearer. I figured that maybe Haskell could be using some more efficient mechanism for Strings internally, only treating it outwardly as a [Char]. But I guess that in a lot of circumstances where you're just working with small pieces of text in non-performance critical code it's perfectly okay to use String. Cheers, -Tako On Wed, Sep 1, 2010 at 08:31, Kevin Jardine kevinjard...@gmail.com wrote: Hi Tako, The issues involved with String, ByteString, Text and a few related libraries were discussed at great length recently in this thread: http://groups.google.com/group/haskell-cafe/browse_thread/thread/52a21cf61ffb21b0/ Basically, Chars are 32 bit integers and Strings are represented as a list of Chars. This is very convenient for small computations but often very inefficient for anything large scale. The String API is also missing various encoding related features. Because of the limitations of String, various alternative libraries have been proposed. Text is one important option. You'll find much more detail on the above referenced thread. Kevin On Sep 1, 8:13 am, Tako Schotanus t...@codejive.org wrote: On Wed, Sep 1, 2010 at 07:14, John Millikin jmilli...@gmail.com wrote: Don't forget, you can always improve the text library yourself. I love to receive patches, requests for improvement, and bug reports. Are there any areas in particular you'd like help with, for either library? I'm happy to assist any effort which will help reduce use of String. As a Haskell noob I'm curious about this statement, is there something intrinsically wrong with String? Or is it more a performance/resource problem when dealing with large amounts of text for example? (Like having to use StringBuilder in Java if you want to avoid the penalty of repeated String allocations when simply concatenating for example) Cheers, -Tako ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp:// www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Announce: Significant performance improvements for Data.Map
darcs get http://code.haskell.org/~dons/code/containers/ I was giving this a try, and this soon hosed ghc (6.12.3): * (starting from a pristine ghc, from a binary package) * cabal install for containers-0.4.0.0 (the above package) * then cabal install for some package that uses template-haskell * then ghc-pkg check: There are problems in package ghc-6.12.3: dependency template-haskell-2.4.0.1-e9e9c63092746bd4a3f64cc37ddb1e06 doesn't exist I seems template-haskell.cabal contains containers (without any version constraints) as a dependency, so cabal install goes to rebuild this (since it prefers the fresh containers version). this looks like http://hackage.haskell.org/trac/hackage/ticket/675 but not quite. could cabal install (or ghc-pkg register?) please please refuse to install a package that would break others (especially, if others = ghc). what's the proper way to use containers-0.4 now? (I was going to suggest can you just put it on hackage but given the above, this would probably be a bad idea.) I plug the new containers into a ghc source tree? J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Fwd: Semantics of iteratees, enumerators, enumeratees?
Tilo Wiklund wrote: Daniel Fischer wrote: [...] Well, I just gave an example where one would want chunking for reasons other than performance. That iteratees don't provide the desired functionality is a different matter. [...] In the case of hashing, wouldn't it be more reasonable to consider iterators over streams of fixed (or at least predictable) sized chunks (where a set of chunks can themselves be chunked), with the chunking behaviour being given by another iteratee over the original stream? It seems to me that one of the major points of iteratees is to provide an abstraction from the kind of chunking irrelevant to the parsing logic, otherwise I fail to see any difference (at least relevant to chunking) to plain strict IO. I thought so, too, but I was informed[1] that iteratees are just a small step up the abstraction ladder. The difference compared to an ordinary file Handle is that you can now reuse one and the same iteratee for reading from a String , for instance, without changing the source code of the iteratee. Furthermore, iteratees can be suspended, which facilities resource management like closing files handles after they've been read. [1]: http://www.reddit.com/r/haskell/comments/ar4wb/understanding_iteratees/c0j0f3r Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: text 0.8.0.0, fast Unicode text support
On Wednesday 01 September 2010 06:08:07, Bryan O'Sullivan wrote: New in this release: - Substantial performance improvements. - Bug fixes, and better quality assurance via automated QuickCheck and HPC tests and coverage. - An even nicer API than before. Good job. The text library provides an efficient packed, immutable Unicode text type (both strict and lazy), with a powerful loop fusion optimization framework. The 'Text' type represents Unicode character strings, in a time and space-efficient manner. This package provides text processing capabilities that are optimized for performance critical use, both in terms of large data quantities and high speed. Hmm, I have to throw a few grains of salt into that. File: big.txt from Peter Norvig's spelling checker (6.2MiB) 1. read the file and output it to stdout (redirected to /dev/null) ByteString.Lazy: = 0.01s text-0.7.2.1 (Lazy): 0.68s text-0.8.0.0 (Lazy): 0.26s String: 0.35s ByteString doesn't do any de/encoding or validity checking, so it's clear that can be way faster than I/O which does. The interesting part is the comparison between text and vanilla String I/O, the difference is smaller than I expected for text-0.8.0.0. It came as a surprise that text-0.7.2.1 actually had much worse performance than vanilla Strings. Okay, now we know how long the I/O takes, let's measure some work. 2. read the file, replace some string, output to stdout (redirected to /dev/null) a) Professor - Teacher stringsearch (Lazy): 0.02s, 2MB total text-0.7.2.1 (Lazy): 0.92s, 28MB total text-0.7.2.1 (Strict): 0.90s, 65MB total text-0.8.0.0 (Lazy): 0.44s, 12MB total text-0.8.0.0 (Strict): 0.36S, 55MB total String (naive): 0.51s, 1MB total String (KMP): 0.46s, 1MB total b) deteriorate - worsen stringsearch (Lazy): 0.02s, 2MB total text-0.7.2.1 (Lazy): 1.01s, 39MB total text-0.7.2.1 (Strict): 0.91s, 65MB total text-0.8.0.0 (Lazy): 0.45s, 17MB total text-0.8.0.0 (Strict): 0.36s, 55MB total String (naive): 0.52s, 1MB total String (KMP): 0.50s, 1MB total c) hen - here stringsearch (Lazy): 0.04s, 2MB total text-0.7.2.1 (Lazy): 1.10s, 2MB total text-0.7.2.1 (Strict): 0.95s, 65MB total text-0.8.0.0 (Lazy): 0.66s, 2MB total text-0.8.0.0 (Strict): 0.41s, 55MB total String (naive): 0.53s, 1MB total String (KMP): 0.51s, 1MB total d) kre - here stringsearch (Lazy): 0.03s, 2MB total text-0.7.2.1 (Lazy): 1.23s, 39MB total text-0.7.2.1 (Strict): 0.96s, 65MB total text-0.8.0.0 (Lazy): 0.65s, 17MB total text-0.8.0.0 (Strict): 0.40s, 55MB total String (naive): 0.51s, 1MB total String (KMP): 0.47s, 1MB total The performance of text-0.8.0.0 has improved significantly over that of text-0.7.2.1 (for the tested features), the improvement of the replacing algorithm is however not as impressive as that of I/O. Replacing isn't much faster than for Strings, however, for (some?) very short patterns, even slower. That's not so good. What's *really* bad is the space behaviour. My tests suggest that the space usage (for Text.Lazy) depends on the index of the pattern to replace, the later it appears (if at all), the more memory is used by text. Apparently it doesn't deliver the beginning before a match has been found (or the whole string has been scanned). That space leak ought to be fixed. The space behaviour of the strict variant doesn't show that problem, it seems to only depend on the file, but it uses disproportionally much memory. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: text 0.8.0.0, fast Unicode text support
Hi, Daniel - Thanks for taking the new code for a test drive! The interesting part is the comparison between text and vanilla String I/O, the difference is smaller than I expected for text-0.8.0.0. Yes. Much of this is due to the new encoding stuff on Handles in GHC 6.12, which is slow. Its performance wasn't so noticeable when it was only shipping String around, but it's much more visible with Text. It's far slower on a Mac than on Linux, in case that's relevant. The performance of text-0.8.0.0 has improved significantly over that of text-0.7.2.1 (for the tested features), the improvement of the replacing algorithm is however not as impressive as that of I/O. I'd bet you that's mostly because the program is I/O bound, in the sense that it's spending time going through the layers of buffering and translation that now make up a Handle. Any improvement in other code is going to be hard to see because of that. The other major consideration, both for this case and the first one you note, is that the inliner in 6.12 chokes on code that uses stream fusion: it boxes and unboxes vast quantities of state. That kills performance due to both the boxing and unboxing overhead and the increased number of nursery GCs. The marvelous new 6.13 inliner does a *much* better job here - that's where I see those 3x performance improvements for free. What's *really* bad is the space behaviour. What are you using to measure that? Also, please don't forget to post your benchmark code when you make observations like this, as that way I can reproduce your measurements and fix problems. I appreciate your help! Regards, Bryan. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: text 0.8.0.0, fast Unicode text support
On Tue, Aug 31, 2010 at 10:14 PM, John Millikin jmilli...@gmail.com wrote: Is there a summary of the API changes available? I see a new module, but Precis is choking on Data.Text and Data.Text.Lazy, so I'm not sure what existing signatures have been modified. Ouch. I'll try to do a diff and follow up, probably not until much later. Are there any areas in particular you'd like help with, for either library? I'm happy to assist any effort which will help reduce use of String. For the text library, my main interest is performance. I've been far more focused on making the code correct and complete than on making it fast, but now that the API is stable and the test coverage is solid, performance deserves more attention. What specifics would be useful? - Reproducible, realistic (but preferably small) benchmarks - Patches that speed things up Thanks for asking! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ICFP Hotel Room
I've found a roommate now. So I don't need any more replies. :-) On Sun, Aug 29, 2010 at 11:45 PM, Michael D. Adams mdmko...@gmail.com wrote: Hi all, I'm a graduate student (male) and am looking for a (male) roommate to split the cost of a hotel room at ICFP. If anyone is interested in splitting a room, please drop me a line. I will be attending the workshops collocated with ICFP so I currently have a reservation at the conference hotel (at the conference rate) with check-in on September 24 (the day before the first workshop) and check-out on October 3 (the day after the last workshop). Michael D. Adams Ph.D. Student, Indiana University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] open and closed
This is probably widely known already but I just realized you can sort-of have closed classes as it is: module SomeModule( SomeClass, someMethod ) where class SomeClassInternal a where someMethodInternal :: a - Integer instance SomeClassInternal Integer where someMethodInternal = id instance SomeClassInternal [a] where someMethodInternal = fromIntegral . length instance SomeClassInternal Bool where someMethodInternal False = 0 someMethodInternal True = 42 class SomeClassInternal a = SomeClass a instance SomeClass Integer instance SomeClass [a] instance SomeClass Bool someMethod :: SomeClass a = a - Integer someMethod = someMethodInternal Basically, not exporting a class is a very obvious way to prevent people from declaring new instances. The problem is that they also can't refer to it in any way, and if it shows up in the public API in a significant way (besides it being just weird) they have to try and manage their business without using type signatures. The solution is pretty simple: declare a private class with private methods, and a corresponding public class which implies the private one, with instances for all the same types, and have everything in the public API use the public class instead. That way people still can't declare new instances for the private class (it's not visible), nor for the public one (because they can't satisfy the superclass constraint), but otherwise they're free to use it in type signatures and do whatever they want. I don't think the compiler would use this to reason about the code in new ways (i.e. the typechecker would still treat it as open), but it's at least something. (You could also use UndecidableInstances and `instance SomeClassInternal a = SomeClass a` for less repetition and easier maintainability; the advantage of not doing so is that you don't need UndecidableInstances, and the resulting Haddocks are friendlier, especially if/when Haddock gets updated to hide instances of non-exported classes.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: questions about Arrows
Thanks for the prompt reply. Some questions / comments below : On Wed, Sep 1, 2010 at 12:33 AM, Maciej Piechotka uzytkown...@gmail.com wrote: rSum2 :: ArrowCircuit a = a Int Int rSum2 = proc x - do rec out - delay 0 - out + x returnA - out + x Wow, that was simple. I guess I never thought to do this because it evaluates (out + x) twice, but one can always write rSum3 :: ArrowCircuit a = a Int Int rSum3 = proc x - do rec let next = out + x out - delay 0 - next returnA - next I have a follow-up question which I'll ask in a new thread. 3) One can define fix in terms of trace and trace in terms of fix. trace f x = fst $ fix (\(m, z) - f (x, z)) fix f = trace (\(x, y) - (f y, f y)) undefined Does this mean we can translate arbitrary recursive functions into ArrowLoop equivalents? Yes. In fact fix is used on functional languages that do not support recursion to have recursion (or so I heard) In which case my question is, why is the primitive for Arrows based on trace instead of fix? Best regards, Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: questions about Arrows
On Wed, 2010-09-01 at 11:49 -0700, Ben wrote: Thanks for the prompt reply. Some questions / comments below : On Wed, Sep 1, 2010 at 12:33 AM, Maciej Piechotka uzytkown...@gmail.com wrote: rSum2 :: ArrowCircuit a = a Int Int rSum2 = proc x - do rec out - delay 0 - out + x returnA - out + x Wow, that was simple. I guess I never thought to do this because it evaluates (out + x) twice, but one can always write rSum3 :: ArrowCircuit a = a Int Int rSum3 = proc x - do rec let next = out + x out - delay 0 - next returnA - next I have a follow-up question which I'll ask in a new thread. Possibly it should be written as rSum4 :: ArrowCircuit a = a Int Int rSum4 = proc x - do rec let !next = out + x out - delay 0 - next returnA - next 3) One can define fix in terms of trace and trace in terms of fix. trace f x = fst $ fix (\(m, z) - f (x, z)) fix f = trace (\(x, y) - (f y, f y)) undefined Does this mean we can translate arbitrary recursive functions into ArrowLoop equivalents? Yes. In fact fix is used on functional languages that do not support recursion to have recursion (or so I heard) Ups. Sorry - my dyslexia came to me and I read recursive instead of ArrowLoop. My fault IMHO it is not possible. In which case my question is, why is the primitive for Arrows based on trace instead of fix? How would you define loop in terms of fixA :: ArrowLoop a = a b b - a c b fixA f = loop (second f arr (\(_, x) - (x, x))) The only way that comes to my mind is: loopA :: (ArrowLoop a, ArrowApply a) = a (b, d) (c, d) - a b c loopA f = proc (x) - do arr fst fixA (proc (m, z) - do f - (x, z)) - x Which requires ArrowApply. So as long as arrow is ArrowLoop and ArrowApply it is possible. Best regards, Ben Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: text 0.8.0.0, fast Unicode text support
On Wednesday 01 September 2010 18:15:19, Bryan O'Sullivan wrote:
Hi, Daniel -
Thanks for taking the new code for a test drive!
The interesting part is the comparison between text and vanilla String
I/O, the difference is smaller than I expected for text-0.8.0.0.
Yes. Much of this is due to the new encoding stuff on Handles in GHC
6.12, which is slow. Its performance wasn't so noticeable when it was
only shipping String around, but it's much more visible with Text. It's
far slower on a Mac than on Linux, in case that's relevant.
I'm on Linux. I guess that's another point in favour of it:)
Do you happen to know why it's slower on a Mac?
The performance of text-0.8.0.0 has improved significantly over that
of text-0.7.2.1 (for the tested features), the improvement of the
replacing algorithm is however not as impressive as that of I/O.
I'd bet you that's mostly because the program is I/O bound, in the sense
that it's spending time going through the layers of buffering and
translation that now make up a Handle. Any improvement in other code is
going to be hard to see because of that.
Maybe. As a rough measure, I took (total time - time for just reading and
outputting) for an approximation of the processing (replacing) time.
For the first example (Lazy), that yields
0.7.2.1: 0.92s - 0.68s = 0.24s
0.8.0.0: 0.44s - 0.26s = 0.18s,
for the fourth
0.7.2.1: 1.23s - 0.68s = 0.55s
0.8.0.0: 0.65s - 0.26s = 0.39s
Yes, I know it's very crude, but TIO.readFile file = TIO.putStrLn does no
less translation than with a replacing in between, or does it?
So I tentatively believe most of the difference is spent doing the
replacements.
The other major consideration, both for this case and the first one you
note, is that the inliner in 6.12 chokes on code that uses stream
fusion: it boxes and unboxes vast quantities of state. That kills
performance due to both the boxing and unboxing overhead and the
increased number of nursery GCs.
I haven't looked at the core, so I take your word for it. I know the
behaviour from other situations.
The marvelous new 6.13 inliner does a *much* better job here - that's
where I see those 3x performance improvements for free.
That's nice. Maybe I should go get the HEAD before 6.14.1 will be released.
What's *really* bad is the space behaviour.
What are you using to measure that?
+RTS -s and top. The figures I gave were the total memory in use of
+RTS -s, maximum residency was 20MB (vs. 39 total) for 0.7 and 12MB (vs. 17
total) for 0.8 in the bad tests.
Also, please don't forget to post your benchmark code when you make
observations like this,
It's not very interesting,
{-# LANGUAGE BangPatterns #-}
module Main (main) where
import System.Environment (getArgs)
import qualified Data.Text.Lazy as T
import qualified Data.Text.Lazy.IO as TIO
main :: IO ()
main = do
(file : pat : sub : _) - getArgs
let !spat = T.pack pat
!ssub = T.pack sub
work = T.replace spat ssub
TIO.readFile file = TIO.putStrLn . work
with the obvious changes of imports for the strict Text and the almost
obvious changes for the ByteString code.
as that way I can reproduce your measurements
and fix problems. I appreciate your help!
I can now say more. Looking at Data.Text.Lazy.replace,
replace s d = intercalate d . split s
, I also got a space leak with that for BS.Lazy's intercalate and
stringsearch's split. Looking at intercalate,
intercalate t = concat . (Data.List.intersperse t)
, that's where you definitely get a space leak, because
intersperse :: a - [a] - [a]
intersperse _ [] = []
intersperse _ [x] = [x]
intersperse sep (x:xs) = x : sep : intersperse sep xs
isn't lazy enough.
Given the context, it's not hard to see what's wrong here. Before
intersperse produces any output, it checks whether the list contains at
least two elements (if any). If a is a list-like type, like String, lazy
ByteStrings or lazy Text, where the elements of the list are lazily
produced one after the other, as is the case for split, each element must
be complete before it can be delivered and then consumed.
So indeed, replace needs O(index pat) space :(
I don't think that fixing Data.List.intersperse will fix your space leak,
though.
split pat src
| null pat= emptyError split
| isSingleton pat = splitBy (== head pat) src
| otherwise = go 0 (indices pat src) src
where
go _ [] cs = [cs]
go !i (x:xs) cs = let h :*: t = splitAtWord (x-i) cs
in h : go (x+l) xs (dropWords l t)
l = foldlChunks (\a (T.Text _ _ b) - a + fromIntegral b) 0 pat
Using the list of indices of the pattern, split can't deliver anything
before the first (next) occurrence of the pattern has been located (or the
end of the string reached). Again, that forces O(index pat) space
consumption.
I don't see how to avoid that without duplicating a large part of indices'
logic in a dedicated
[Haskell-cafe] Laziness bug in Data.List.intersperse (was: ANNOUNCE: text 0.8.0.0, fast Unicode text support)
On Wednesday 01 September 2010 21:29:47, Daniel Fischer wrote: that's where you definitely get a space leak, because intersperse :: a - [a] - [a] intersperse _ [] = [] intersperse _ [x] = [x] intersperse sep (x:xs) = x : sep : intersperse sep xs isn't lazy enough. Ticket created, http://hackage.haskell.org/trac/ghc/ticket/4282 I'm not keen on subscribing to libraries@ to follow the official proposal process, any takers? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On to applicative
michael rice wrote: Prelude Data.Either let m = Just 7 Prelude Data.Either :t m m :: Maybe Integer So to create a value of type (Maybe ...), you can use Just. Prelude Data.Either let l = 2:[] Prelude Data.Either :t l l :: [Integer] So to create a value of type [...], you can use (:) and []. Prelude Data.Either let g = getLine Prelude Data.Either :t g g :: IO String So to create a value of type (IO ...), you can use getLine. Prelude Data.Either let e = Right abc Prelude Data.Either :t e e :: Either a [Char] So to create a value of type (Either ... ...), you can use Right. How can I similarly create an instance of (-) [...] ? An instance of (-) is usually called a function. And functions are created by lambda abstraction: Prelude let f = \x - x Prelude :t f f :: t - t So to create a value of type (... - ...), you can use \. Just like Either, - is a binary type constructor. Just like (Either a b) is a type, (a - b) is a type. And very much like you can create (Either a b) values with Left and Right, you can create (a - b) values with \. Tillmann PS. After studying how to construct values, it may be instructive to study how to take them apart. For example, Bool values can be taken apart by if-then-else expressions. What about Either, IO and - values? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ArrowCircuit, delay and space leaks
Hello Arrow-theorists -- In a previous email Maciej Piechotka showed me how to construct a recursive function I wanted via ArrowCircuits. This computes the running sum of a stream of Ints. rSum :: ArrowCircuit a = a Int Int rSum = proc x - do rec let next = out + x out - delay 0 - next returnA - next Although this arrow runs in linear time, it exhausts the stack (I've compiled with ghc -02.) The obvious strict non-arrow version runs in linear time and constant space : rSum :: [Int] - [Int] rSum = rSum' 0 where rSum' _ [] = [] rSum' n (x:xs) = let n' = x+n in n' `seq` n' : rSum n' xs It is ironic because arrows were used in the past to plug space leaks. It seems that using delay here introduces a growing stack of thunks. I have tried decorating everything I could think of with `seq` in the pointfree and pointed versions, to no avail. Is there a (pointed or point-free) version which runs in linear time and constant space? Best regards, Ben PS I tried manually translating the ArrowCircuit into a length-preserving stream function (SF in Hughes's paper) to try to understand what was going on. I ended up with rSum :: [Int] - [Int] rSum xs = zipWith (+) xs $ 0 : rSum xs which is not quite right as it is quadratic. But I think it captures the basic idea of the translation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Unnecessarily strict implementations
Hi, there is a new ticket that Data.List.intersperse is not as non-strict as possible (http://hackage.haskell.org/trac/ghc/ticket/4282). I have observed some other functions which are unnecessarily strict and it might be advantageous to change their definitions as well. I think it is known that the current implementations of inits and tails are too strict. At least I think I have once read a post to haskell-cafe about this topic. Furthermore intersect is too strict. We have intersect _|_ [] = _|_ and the current implementation is linear in the size of xs if we evaluate intersect xs []. I think simply adding a rule intersect _ [] = [] to the current implementation solves this issue. The implication (=) :: Bool - Bool - Bool is too strict as well. We have False = _|_ = _|_ as well as _|_ = True = _|_ while one of these cases could yield True. The problem is that (=) is defined by means of compare. This effect shows up for all data types with a least element if the default implementation of (=) by means of compare is used. Furthermore there are a couple of functions which are too strict but whose minimally strict implementations do not provide benefits. For example, reverse is too strict as has already been observed by Olaf Chitil (http://www.cs.kent.ac.uk/people/staff/oc/Talks/ifl2006NonStrictProgramming.pdf ). Cheers, Jan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On to applicative
Hi Tillman, Prelude Control.Monad Control.Monad.Instances Control.Applicative let f = \x - x:[] Prelude Control.Monad Control.Monad.Instances Control.Applicative :t f f :: a - [a] Prelude Control.Monad Control.Monad.Instances Control.Applicative let g = \x - Just x Prelude Control.Monad Control.Monad.Instances Control.Applicative :t g g :: a - Maybe a Prelude Control.Monad Control.Monad.Instances Control.Applicative :t z z :: Integer - Integer Prelude Control.Monad Control.Monad.Instances Control.Applicative Data.Char :t y y :: Char - Int Can you think of a situation for \x - f x that would require x to have a declared type, or is it always inferred by the type of f? Michael --- On Wed, 9/1/10, Tillmann Rendel ren...@mathematik.uni-marburg.de wrote: From: Tillmann Rendel ren...@mathematik.uni-marburg.de Subject: Re: [Haskell-cafe] On to applicative To: michael rice nowg...@yahoo.com Cc: haskell-cafe@haskell.org Date: Wednesday, September 1, 2010, 5:28 PM michael rice wrote: Prelude Data.Either let m = Just 7 Prelude Data.Either :t m m :: Maybe Integer So to create a value of type (Maybe ...), you can use Just. Prelude Data.Either let l = 2:[] Prelude Data.Either :t l l :: [Integer] So to create a value of type [...], you can use (:) and []. Prelude Data.Either let g = getLine Prelude Data.Either :t g g :: IO String So to create a value of type (IO ...), you can use getLine. Prelude Data.Either let e = Right abc Prelude Data.Either :t e e :: Either a [Char] So to create a value of type (Either ... ...), you can use Right. How can I similarly create an instance of (-) [...] ? An instance of (-) is usually called a function. And functions are created by lambda abstraction: Prelude let f = \x - x Prelude :t f f :: t - t So to create a value of type (... - ...), you can use \. Just like Either, - is a binary type constructor. Just like (Either a b) is a type, (a - b) is a type. And very much like you can create (Either a b) values with Left and Right, you can create (a - b) values with \. Tillmann PS. After studying how to construct values, it may be instructive to study how to take them apart. For example, Bool values can be taken apart by if-then-else expressions. What about Either, IO and - values? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Statically tracking validity - suggestions?
On Mon, Aug 30, 2010 at 11:24:06PM -0700, strejon wrote:
I'm aware of phantom types and the like, but I've been unable to
work out how to use them (or another type system extension)
to properly track validity on the type level. I'd want something
like:
validate :: Certificate Possibly_Valid - Maybe (Certificate Valid)
With later functions only accepting values of type Certificate Valid.
Is there a simple way to do this?
Yup. just do it just like you say :)
declare your certificate like so (note: a is not used in the body)
data Certificate a = Certificate { .. }
then the valid data type
data Valid
There is no need for a Possibly_Valid type as it can be represented by
just leaving the type unbound. so you will have
validate :: forall a . Certificate a - Maybe (Certificate Valid)
so validate will take any certificate, and perhaps return a validated
one. Then just use (Certificate Valid) in the types of functions that
require valid certificates.
This also means your functions are polymorphic in their validity by
default, like
mapName :: (String - String) - Certificate a - Certificate a
will work on valid or invalid certificates.
Just note that when changing a phantom type you need to reconstruct the
type fully. so for
data A
data B
data Foo a = Foo Int
conv :: Foo A - Foo B
you can't write
conv x = x
you need to write
conv (Foo x) = Foo x
since the argument is changing type.
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ArrowCircuit, delay and space leaks
My apologies, my space leak was in my implementation of runAuto. Ignore me! b On Wed, Sep 1, 2010 at 3:01 PM, Ben midfi...@gmail.com wrote: Hello Arrow-theorists -- In a previous email Maciej Piechotka showed me how to construct a recursive function I wanted via ArrowCircuits. This computes the running sum of a stream of Ints. rSum :: ArrowCircuit a = a Int Int rSum = proc x - do rec let next = out + x out - delay 0 - next returnA - next Although this arrow runs in linear time, it exhausts the stack (I've compiled with ghc -02.) The obvious strict non-arrow version runs in linear time and constant space : rSum :: [Int] - [Int] rSum = rSum' 0 where rSum' _ [] = [] rSum' n (x:xs) = let n' = x+n in n' `seq` n' : rSum n' xs It is ironic because arrows were used in the past to plug space leaks. It seems that using delay here introduces a growing stack of thunks. I have tried decorating everything I could think of with `seq` in the pointfree and pointed versions, to no avail. Is there a (pointed or point-free) version which runs in linear time and constant space? Best regards, Ben PS I tried manually translating the ArrowCircuit into a length-preserving stream function (SF in Hughes's paper) to try to understand what was going on. I ended up with rSum :: [Int] - [Int] rSum xs = zipWith (+) xs $ 0 : rSum xs which is not quite right as it is quadratic. But I think it captures the basic idea of the translation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unnecessarily strict implementations
On Thursday 02 September 2010 00:05:03, Jan Christiansen wrote: Hi, there is a new ticket that Data.List.intersperse is not as non-strict as possible (http://hackage.haskell.org/trac/ghc/ticket/4282). It's not that it's not as non-strict as possible per se. (Sorry, had to :) It's that intersperse's current definition (in GHC at least) can cause a space leak. In this case, making the function less strict can cure it, in other cases, more strictness might be the solution. I have observed some other functions which are unnecessarily strict and it might be advantageous to change their definitions as well. I think it is known that the current implementations of inits and tails are too strict. At least I think I have once read a post to haskell-cafe about this topic. It's been mentioned. I don't see any drawbacks to making them less strict, so I'd support that. Furthermore intersect is too strict. We have intersect _|_ [] = _|_ On the other hand, we currently have intersect [] _|_ = [] and one of intersect _|_ [] and intersect [] _|_ must give _|_. Which one is a matter of choice. and the current implementation is linear in the size of xs if we evaluate intersect xs []. Yes, that's bad. I think simply adding a rule intersect _ [] = [] to the current implementation solves this issue. And before that, the rule intersect [] _ = [] if the current behaviour of intersect [] should be retained. The implication (=) :: Bool - Bool - Bool is too strict as well. We have False = _|_ = _|_ as well as _|_ = True = _|_ while one of these cases could yield True. I'm not convinced either should (nor that they shouldn't). The problem is that (=) is defined by means of compare. This effect shows up for all data types with a least element if the default implementation of (=) by means of compare is used. Furthermore there are a couple of functions which are too strict but whose minimally strict implementations do not provide benefits. For example, reverse is too strict as has already been observed by Olaf Chitil (http://www.cs.kent.ac.uk/people/staff/oc/Talks/ifl2006NonStrictProgramm ing.pdf ). The last slide lists among the problems proposes undesirably inefficient functions (reverse). I wouldn't equate 'not minimally strict' with 'too strict'. Minimal strictness also can have negative effects, one must look at each case individually. Cheers, Jan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: text 0.8.0.0, fast Unicode text support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/01/2010 02:44 AM, Ivan Lazar Miljenovic wrote: On 1 September 2010 16:27, David Virebayre dav.vire+hask...@gmail.com wrote: Sometimes I'd love if I could program using String and the compiler would automatically convert that to Text, or Bytestrings, but of course it's wishful thinking. Well, there's OverloadedStrings for String literals... But the problem with automagic conversion would be one of encoding for Bytestrings at least. This reminds me: it would be nice if Text, ByteString, etc. exported their own definitions of type String. As most users have to import them qualified to avoid collisions with Data.List (and the Prelude?) anyway, this would enable someone to import their desired module as, say, S, then use type S.String and string ops S.foo. Anyone who *did* use them unqualified would have to add (hiding (String)) to their imports, of course. The flip side of this would be a module which contained the definition for String and re-exported Data.List, so that the above S.mumble could work for String as well. (The obvious choice would be Data.String, but that's taken for IsString and of course that would be required to pull this off so it can't just have the list implementation stuffed into it.) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx/FsQACgkQIn7hlCsL25Vk8ACeKco9/IFwGi+8gc+BxSyT3QwY oP8An3oabG1lbXHChShbenEWj9HWEq6Q =PQsO -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HDBC-postgresql and safe/unsafe FFI calls
On Wed, Sep 1, 2010 at 7:40 PM, David Powell da...@drp.id.au wrote: Greetings, I'm having an issue with the HDBC-postgresql package that requires me to manually patch it before installation for most of my use cases. All the FFI calls in this package are marked unsafe. Unfortunately, this means that whenever I issue a slow sql query, all other processing stops. In most places that I want to use this module, I've had to manually patch it to at least mark the PQexec and PQexecParams calls as safe. Is there any reason these calls should not be marked as safe? I understand that there a little extra runtime overhead with this, but I'd have thought that negligible given all the other processing that goes on with these particular calls under the hood. Have you read this? http://blog.ezyang.com/2010/07/safety-first-ffi-and-threading/ Perhaps it answers your questions? Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HDBC-postgresql and safe/unsafe FFI calls
Thanks Jason, I think I had read that - I quite enjoy Edward's posts. Re-reading, seems to confirm what I thought, most (all?) of the FFI calls in HDBC-postgresql should be changed to safe. -- David On Thu, Sep 2, 2010 at 2:47 PM, Jason Dagit da...@codersbase.com wrote: On Wed, Sep 1, 2010 at 7:40 PM, David Powell da...@drp.id.au wrote: Greetings, I'm having an issue with the HDBC-postgresql package that requires me to manually patch it before installation for most of my use cases. All the FFI calls in this package are marked unsafe. Unfortunately, this means that whenever I issue a slow sql query, all other processing stops. In most places that I want to use this module, I've had to manually patch it to at least mark the PQexec and PQexecParams calls as safe. Is there any reason these calls should not be marked as safe? I understand that there a little extra runtime overhead with this, but I'd have thought that negligible given all the other processing that goes on with these particular calls under the hood. Have you read this? http://blog.ezyang.com/2010/07/safety-first-ffi-and-threading/ Perhaps it answers your questions? Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HDBC-postgresql and safe/unsafe FFI calls
On Wed, Sep 1, 2010 at 10:00 PM, David Powell da...@drp.id.au wrote: Thanks Jason, I think I had read that - I quite enjoy Edward's posts. Re-reading, seems to confirm what I thought, most (all?) of the FFI calls in HDBC-postgresql should be changed to safe. Yes I think so. Unless you know the call is going to always return quickly, then to me it sounds like you want safe. For example, C's sine function would make sense to be imported unsafe, but if you're doing a slow query or an http request, better to use safe. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
