Re: [Haskell-cafe] Memory-aware Haskell?
On Thu, Dec 24, 2009 at 11:38 PM, Roman Cheplyaka r...@ro-che.info wrote: So, let's think what we can do at runtime. Suppose RTS takes the parameter -- upper limit of consumed memory. When it sees that memory consumption is close to upper bound, it can: 1. force garbage collection This is already implemented. See the -M RTS option. 2. apply some heuristics to find and reduce some chunks which will benefit from reduction in terms of size For example, by un-evaluating them. It would often be possible to reduce size like that, just so long as they aren't evaluated again the next second. Well, this one would be hard. 3. if nothing helps, throw an exeption. It can be caught in IO and memory-aware program can make apropriate decision -- e.g. abort opening a large file and gracefully warn the user. That should be relative simple. Get implementing, will you?:D (And there still is a problem of foreign code whose memory consumption we know nothing about...) In theory, you could deal with that by hooking malloc. -- Svein Ove Aas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] problem with editline install
i tried to install editline (because i wanted to install djinn, which depends on it): with cabal install and with downloading and runghc Setup.lhs configure i got the same error: checking for completion_matches... no configure: error: editline not found, so this package cannot be built See `config.log' for more details. in the log i did not see anything helpful (at my level of understanding). i could then install with synaptic because a deb package existed for ubuntu). what did i wrong? thanks for helpful comments andrew ps. in this case a wiki would have been helpful. it would have been a less intruding form to communicate than sending an email to the developer. especially in the case i assume i made some error. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why does HXT use Arrows?
Stephen Tetley wrote: Hello Gregory I've never used HXT, but looking at the source there are many functions with types like this one: getElemNodeSet:: ArrowXml a = a XmlTree XmlTree - a XmlTree XmlNodeSet They are functions where the arrow is 'a XmlTree _something_. The input to the arrow is an XmlTree and the ouput is variable. If all the functions were like this they could be replaced by a monad. However there are quite a few like this: mkCmt :: a String XmlTree mkElement :: QName - a n XmlTree - a n XmlTree - a n XmlTree Here the input type to the arrow computation varies - this is the key - monads can produce output in many ways (wrapping it in a Maybe, tupling it with state, many results - list monad) but they can only take input as function parameters. Arrows can consume input in different ways... Which begets the question of whether HXT actually uses a way of taking input other than as function parameter. It appears to me that it doesn't. Put differently, I suspect that all of HXT can be rewritten to mkCmt :: String - M XmlTree mkElement :: QName - (n - M XmlTree) - (n - M XmlTree) - (n - M XmlTree) ArrowXML a = a b c ~=~ b - M c with M a = [a] being the list monad or some list augmented with IO. At least, that's what I gather from the presentation in the original paper Wallace und Runciman. Haskell and XML: Generic Combinators or Type-Based Translation? http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.39.4029 I am not convinced that the abstract arrow interface is more convenient than an explicit b - M c version. 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] Haskell Users in Leipzig
Perhaps you can ask on the Ocaml mailing list too. Done. I know Standard ML, never wrote any big software in it due to the lack of libraries. Yes, same problem here. Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory-aware Haskell?
On Fri, Dec 25, 2009 at 5:14 AM, Svein Ove Aas svein@aas.no wrote: On Thu, Dec 24, 2009 at 11:38 PM, Roman Cheplyaka r...@ro-che.info wrote: So, let's think what we can do at runtime. Suppose RTS takes the parameter -- upper limit of consumed memory. When it sees that memory consumption is close to upper bound, it can: 1. force garbage collection This is already implemented. See the -M RTS option. Correct me if I'm wrong - it's been a while since I tried to use the -M option to deal with Gitit memory usage on darcs.net - but doesn't -M just kill the program after it reaches a set RAM, and doesn't trigger any GCs? -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory-aware Haskell?
Am Freitag 25 Dezember 2009 15:45:29 schrieb Gwern Branwen: On Fri, Dec 25, 2009 at 5:14 AM, Svein Ove Aas svein@aas.no wrote: On Thu, Dec 24, 2009 at 11:38 PM, Roman Cheplyaka r...@ro-che.info wrote: So, let's think what we can do at runtime. Suppose RTS takes the parameter -- upper limit of consumed memory. When it sees that memory consumption is close to upper bound, it can: 1. force garbage collection This is already implemented. See the -M RTS option. Correct me if I'm wrong - it's been a while since I tried to use the -M option to deal with Gitit memory usage on darcs.net - but doesn't -M just kill the program after it reaches a set RAM, and doesn't trigger any GCs? It does affect GC behaviour. According to the user's guide: -Msize [Default: unlimited] Set the maximum heap size to size bytes. The heap normally grows and shrinks according to the memory requirements of the program. The only reason for having this option is to stop the heap growing without bound and filling up all the available swap space, which at the least will result in the program being summarily killed by the operating system. The maximum heap size also affects other garbage collection parameters: when the amount of live data in the heap exceeds a certain fraction of the maximum heap size, compacting collection will be automatically enabled for the oldest generation, and the -F parameter will be reduced in order to avoid exceeding the maximum heap size. Reducing the -F parameter (amount of memory reserved for the older generations as a factor of the amount of live data) triggers more GCs. So it tries to not exceed the limit you've given. You can indeed reduce the memory used by your programme via the -M option, but only to some extent. As far as I know it will not collect data held on to by live data to be reconstructed later if needed again. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell type system and Barendregt's Lambda Cube classification
Dear All,
Recently, I've been playing with self-application and fixed-point
combinators definition in Haskell.
It is possible to type them in Haskell using recursive types.
I took Y U combinators:
newtype Rec a = In { out :: Rec a - a }
u :: Rec a - a
u x = out x x
y :: (a - a) - a
y f = let uf = f . u in uf (In uf)
Recursive types are part of System F-omega, which corresponds to
lambda omega in Barendregt's Lambda Cube.
For all type systems in Lambda Cube it is proven that they are
strongly normalizing. But using y I can easily construct a term even
without a normal form.
So, I got a contradition and conclude that type system implementation
in Haskell contains something, that is absent from System F-omega.
My question is: what's particular feature in Haskell type system, that
breaks strong normalization property? Or am I totally wrong
classifying it in terms of Lambda Cube?
Best regards,
Vladimir Ivanov
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell type system and Barendregt's Lambda Cube classification
Dear All,
Recently, I've been playing with self-application and fixed-point
combinators definition in Haskell.
It is possible to type them in Haskell using recursive types.
I took Y U combinators:
newtype Rec a = In { out :: Rec a - a }
u :: Rec a - a
u x = out x x
y :: (a - a) - a
y f = let uf = f . u in uf (In uf)
Recursive types are part of System F-omega, which corresponds to
lambda omega in Barendregt's Lambda Cube.
For all type systems in Lambda Cube it is proven that they are
strongly normalizing. But using y I can easily construct a term even
without a normal form.
So, I got a contradition and conclude that type system implementation
in Haskell contains something, that is absent from System F-omega.
My question is: what's particular feature in Haskell type system, that
breaks strong normalization property? Or am I totally wrong
classifying it in terms of Lambda Cube?
Best regards,
Vladimir Ivanov
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance of functional priority queues
On Friday 25 December 2009 06:09:55 Matt Morrow wrote: On 12/23/09, Jon Harrop j...@ffconsultancy.com wrote: And your results above indicate that the fastest imperative heap is over 3x faster than the fastest functional heap? It's saying that (1) Using an imprecise an inefficient-relative-to-a-accurate-GC-that-doesn't- have-to-assume-the-entire-memory-space-is-live-then-find-what's-dead is a recipe for inefficiency. How is that relevant to what I wrote? (2) And (1) even more so when you're comparing it to the same language with manual memory management and zero GC overhead. There should be no GC overhead in the imperative case anyway. (from here on out I disregard the C numbers (i like C, too)) (3) So now, it's saying that (given this sample, yada yada) among languages where this comparison is possible (i.e. the mutable version still has the GC running) the functional version is on average 1.8 times slower. ghci ((126/70) + (290/150) + (1895/1123)) / 3 1.8069258929454834 You're assuming that other languages will not be a lot faster than Java even though C already is. On Tuesday 16 June 2009 23:50:45 Richard O'Keefe wrote: I've now done some benchmarks myself in C, Java, and Smalltalk, comparing imperative versions of leftist heaps with functional ones. For what it's worth, on a 2.16GHz Intel Core 2 Duo Mac, the coefficient in front of the log(n) part was C JavaST(A) ST(B) Imperative40 70 150 1123 Functional 240 126 290 1895 where ST(A) was a native-code Smalltalk and ST(B) a byte-code one. The C/Functional case used the Boehm collector, untuned. Times are in nanoseconds. Values of n ranged from 2 to 100; the correspondent was saying that small sizes were important. It seems that a factor of 2 for *this* problem is credible; a factor of 10 is not. Post the code and I'll port it to F#. Merry Christmas, -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem with editline install
On Fri, Dec 25, 2009 at 2:17 AM, Andrew U. Frank fr...@geoinfo.tuwien.ac.at wrote: i tried to install editline (because i wanted to install djinn, which depends on it): with cabal install and with downloading and runghc Setup.lhs configure i got the same error: checking for completion_matches... no configure: error: editline not found, so this package cannot be built See `config.log' for more details. in the log i did not see anything helpful (at my level of understanding). i could then install with synaptic because a deb package existed for ubuntu). what did i wrong? thanks for helpful comments You probably need to install the Ubuntu libedit-dev package, which contains the necessary C headers. Note that's different than the libeditline-dev package, which is an old version of the library missing some important features. Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance of functional priority queues
On Mon, Jun 15, 2009 at 4:18 AM, Richard O'Keefe o...@cs.otago.ac.nz wrote: There's a current thread in the Erlang mailing list about priority queues. I'm aware of, for example, the Brodal/Okasaki paper and the David King paper. I'm also aware of James Cook's priority queue package in Hackage, have my own copy of Okasaki's book, and have just spent an hour searching the web. One of the correspondents in that thread claims that it is provably impossible to have an efficient priority queue implementation without mutability. I think he's cuckoo. But I'd like to have some numbers to back me up. Regardless of whether he is correct or not, the result would not apply to haskell. Lazyness can be considered to be a controlled form of mutation, which Okasaki takes advantage of in a number of his data structures. Most (all I've seen) arguments stating that purely functional languages have asymptotic performance worse than mutating languages simply don't apply to lazy ones. -- Svein Ove Aas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance of functional priority queues
2009/12/25 Svein Ove Aas svein@aas.no: On Mon, Jun 15, 2009 at 4:18 AM, Richard O'Keefe o...@cs.otago.ac.nz wrote: There's a current thread in the Erlang mailing list about priority queues. I'm aware of, for example, the Brodal/Okasaki paper and the David King paper. I'm also aware of James Cook's priority queue package in Hackage, have my own copy of Okasaki's book, and have just spent an hour searching the web. One of the correspondents in that thread claims that it is provably impossible to have an efficient priority queue implementation without mutability. I think he's cuckoo. But I'd like to have some numbers to back me up. Regardless of whether he is correct or not, the result would not apply to haskell. Lazyness can be considered to be a controlled form of mutation, which Okasaki takes advantage of in a number of his data structures. Most (all I've seen) arguments stating that purely functional languages have asymptotic performance worse than mutating languages simply don't apply to lazy ones. To be fair, I am not aware of any asymptotically efficient (as efficient as their imperative counterparts) purely functional (t.i. not using mutation) implementations of, say, the union-find datastructure. However, that does not pose any constraints on the efficiency of Haskell because of the existence of the ST monad. -- Svein Ove Aas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell type system and Barendregt's Lambda Cube classification
On Friday 25 December 2009 11:35:38 am Vladimir Ivanov wrote:
Dear All,
Recently, I've been playing with self-application and fixed-point
combinators definition in Haskell.
It is possible to type them in Haskell using recursive types.
I took Y U combinators:
newtype Rec a = In { out :: Rec a - a }
u :: Rec a - a
u x = out x x
y :: (a - a) - a
y f = let uf = f . u in uf (In uf)
Recursive types are part of System F-omega, which corresponds to
lambda omega in Barendregt's Lambda Cube.
For all type systems in Lambda Cube it is proven that they are
strongly normalizing. But using y I can easily construct a term even
without a normal form.
So, I got a contradition and conclude that type system implementation
in Haskell contains something, that is absent from System F-omega.
My question is: what's particular feature in Haskell type system, that
breaks strong normalization property? Or am I totally wrong
classifying it in terms of Lambda Cube?
General recursive types are not part of F_omega. It only has...
1) Type functions of arbitrary order
/\ F : * - *. /\ T : *. F T
2) Universal quantification over the above spaces
Pi F : * - *. Pi T : (* - *) - *. T F
You can encode inductive and coinductive types in such a type system. If F is
the shape functor, then the encoding of the inductive type is:
Pi R : *. (F R - R) - R
and the encoding of the coinductive type is:
Ex R : *. F R * R
where:
Ex R : *. T[R] = Pi Q : *. (Pi R : *. T[R] - Q) - Q
and:
A * B = Pi R : *. (A - B - R) - R
(and
A + B = Pi R : *. (A - R) - (B - R) - R
if you need it to encode F R, although often one may be able to massage F into
a more suitable form to avoid using the * and + encodings).
However, as you can imagine, Rec cannot be encoded. Allowing such types adds
general recursion back in. In type theories that do support Haskell-alike
algebraic/(co)inductive definitions (which none in the lambda cube do; they're
plain lambda calculi), the total ones restrict what types you can declare (to
strictly positive types, usually) to make types like Rec illegal.
-- Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance of functional priority queues
One of the correspondents in that thread claims that it is provably impossible to have an efficient priority queue implementation without mutability. I think he's cuckoo. But I'd like to have some numbers to back me up. He is cuckoo, and here's proof: http://www.brics.dk/RS/96/37/BRICS-RS-96-37.pdf http://www.brics.dk/RS/96/37/BRICS-RS-96-37.pdfThis demonstrates a functional priority queue that performs every desired operation in asymptotically optimal time. Granting that its constant factor could be significantly improved, realize that there are more complicated functional data structures with similar asymptotic guarantees. (Observation: I'm pretty sure that the Fibonacci heap is actually surprisingly functional.) Louis Wasserman wasserman.lo...@gmail.com http://profiles.google.com/wasserman.louis ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem with editline install
Andrew U. Frank fr...@geoinfo.tuwien.ac.at writes: checking for completion_matches... no configure: error: editline not found, so this package cannot be built See `config.log' for more details. Do you have the editline (sometimes also called libedit) C library installed? -- 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] Re: Why does HXT use Arrows?
On Fri, 25 Dec 2009, Heinrich Apfelmus wrote: Which begets the question of whether HXT actually uses a way of taking input other than as function parameter. It appears to me that it doesn't. Put differently, I suspect that all of HXT can be rewritten to mkCmt :: String - M XmlTree mkElement :: QName - (n - M XmlTree) - (n - M XmlTree) - (n - M XmlTree) ArrowXML a = a b c ~=~ b - M c with M a = [a] being the list monad or some list augmented with IO. I think this is the way, HXT was designed first. The functions are still available in hxt-filter. ___ 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
Mark Lentczner wrote: [*] 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 Thanks for the link. I followed through to a couple of other links that broadly support your position: [1] http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html [2] http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/Articles/Domains.html But, on reading [1], I also see Although an application can use this directory [/Library] to store internal data or temporary files, it is not intended for storage of the application bundle itself or for user data files. Application bundles belong in an appropriate /Applications directory, while user data belongs in the user’s home directory. This makes me question whether /Application might be the appropriate place? I'm pleased to see this issue is getting some serious consideration: I haven't actually used Haskell for a while, and since I last did I've switched to using a Mac for much ogf my development, so when I return to the Haskell fold it will be nice to have the system play nicely with the host environment. #g ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Continuable and serializable parsers.
Serguey Zefirov sergu...@gmail.com wrote:
1) How to write a parser that could be restarted? Like, it will be
represented by a function that returns something along the lines
data ParseStepResult input result =
Success (Maybe (input - ParseStepResult input result)) (Maybe result)
| Failure
(ie, parsers using stream combinators like Fudgets have that property)
ie, either a continuation of parsing process and result or failure flag.
I think you're looking for `iteratees'.
| newtype IterateeG c el m a
| = IterateeG {runIter :: StreamG c el - m (IterGV c el m a)}
|
| data IterGV c el m a
| = Done a (StreamG c el) | Cont (IterateeG c el m a) (Maybe ErrMsg)
|
| data StreamG c el = EOF (Maybe ErrMsg) | Chunk (c el)
See
http://okmij.org/ftp/Streams.html
http://hackage.haskell.org/package/iteratee
See also
http://www.haskell.org/haskellwiki/Enumerator_and_iteratee
http://therning.org/magnus/archives/735/comment-page-1#comment-188128
http://comonad.com/reader/2009/iteratees-parsec-and-monoid/
http://inmachina.net/~jwlato/haskell/iter-audio/
--
vvv
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Continuable and serializable parsers.
2009/12/25 Valery V. Vorotyntsev valery...@gmail.com: 1) How to write a parser that could be restarted? Like, it will be represented by a function that returns something along the lines data ParseStepResult input result = Success (Maybe (input - ParseStepResult input result)) (Maybe result) | Failure (ie, parsers using stream combinators like Fudgets have that property) ie, either a continuation of parsing process and result or failure flag. I think you're looking for `iteratees'. I am looking more for the way to serialize intermediate parser computations. The first problem is, actually, easy one. ;) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Continuable and serializable parsers.
On Fri, Dec 25, 2009 at 11:25:41PM +0200, Serguey Zefirov wrote: I am looking more for the way to serialize intermediate parser computations. The first problem is, actually, easy one. ;) Probably you'll have to create a data constructor for each step of your parser. AFAIK, one of HAppS modules does a similar transformation via Template Haskell. The functions specify transactions, and each transaction is converted to a serializable data type. Then it's possible to create a transaction log by serializing them before their execution. Of course you could also modify Happy instead of writing a TH transformation. Both are preprocessor. TH would be more convenient, though. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Continuable and serializable parsers.
On Fri, Dec 25, 2009 at 4:55 PM, Felipe Lessa felipe.le...@gmail.com wrote: On Fri, Dec 25, 2009 at 11:25:41PM +0200, Serguey Zefirov wrote: I am looking more for the way to serialize intermediate parser computations. The first problem is, actually, easy one. ;) Probably you'll have to create a data constructor for each step of your parser. AFAIK, one of HAppS modules does a similar transformation via Template Haskell. The functions specify transactions, and each transaction is converted to a serializable data type. Then it's possible to create a transaction log by serializing them before their execution. Of course you could also modify Happy instead of writing a TH transformation. Both are preprocessor. TH would be more convenient, though. The happstack transaction serialization doesn't support higher-order types. Whether or not that's too much of a restriction depends on what you want your parsers to look like. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Continuable and serializable parsers.
2009/12/25 Felipe Lessa felipe.le...@gmail.com: I am looking more for the way to serialize intermediate parser computations. The first problem is, actually, easy one. ;) Probably you'll have to create a data constructor for each step of your parser. AFAIK, one of HAppS modules does a similar transformation via Template Haskell. The functions specify transactions, and each transaction is converted to a serializable data type. Then it's possible to create a transaction log by serializing them before their execution. Of course you could also modify Happy instead of writing a TH transformation. Both are preprocessor. TH would be more convenient, though. Thank you very much. I think, I will try Template Haskell approach, I prefer combinators over the generators. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Continuable and serializable parsers.
AFAIK, one of HAppS modules does a similar transformation via Template Haskell. The functions specify transactions, and each transaction is converted to a serializable data type. Then it's possible to create a transaction log by serializing them before their execution. The happstack transaction serialization doesn't support higher-order types. Whether or not that's too much of a restriction depends on what you want your parsers to look like. Higher-order like data A m a = A (m a)? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Continuable and serializable parsers.
On Fri, Dec 25, 2009 at 5:06 PM, Serguey Zefirov sergu...@gmail.com wrote: AFAIK, one of HAppS modules does a similar transformation via Template Haskell. The functions specify transactions, and each transaction is converted to a serializable data type. Then it's possible to create a transaction log by serializing them before their execution. The happstack transaction serialization doesn't support higher-order types. Whether or not that's too much of a restriction depends on what you want your parsers to look like. Higher-order like data A m a = A (m a)? In that case, You'll be able to serialize that as long as you can serialize (m a). I meant higher-order as in function-types. So you wouldn't be able to serialize: string :: String - Parser String Unless you had some way to reify the particular function to data. I'm also hazy on how you could encode a fully monadic expression - n applicative style parser may be a bit more modest. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance of functional priority queues
On Friday 25 December 2009 19:59:39 Louis Wasserman wrote: One of the correspondents in that thread claims that it is provably impossible to have an efficient priority queue implementation without mutability. I think he's cuckoo. But I'd like to have some numbers to back me up. He is cuckoo, and here's proof: http://www.brics.dk/RS/96/37/BRICS-RS-96-37.pdf http://www.brics.dk/RS/96/37/BRICS-RS-96-37.pdfThis demonstrates a functional priority queue that performs every desired operation in asymptotically optimal time... You're assuming he meant asymptotic time complexity. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Continuable and serializable parsers.
On Fri, Dec 25, 2009 at 05:12:22PM -0500, Antoine Latter wrote: In that case, You'll be able to serialize that as long as you can serialize (m a). I meant higher-order as in function-types. So you wouldn't be able to serialize: string :: String - Parser String Unless you had some way to reify the particular function to data. That's the idea, to create something like data MyParser = FunString String | ... interpret :: MyParser - Parser String interpret (FunString str) = string str However you're right in a sense, you can't use this scheme to serialize any functions taking functions, like something :: (a - Parser a) - a - Parser a because data MyParser = FunSomething (a - MyParser) a wouldn't be serializable. Well, maybe if your parsers were arrows... :) -- Felipe. ___ 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
Graham Klyne wrote: Mark Lentczner wrote: [*] 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 Thanks for the link. I followed through to a couple of other links that broadly support your position: [1] http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html [2] http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/Articles/Domains.html But, on reading [1], I also see Although an application can use this directory [/Library] to store internal data or temporary files, it is not intended for storage of the application bundle itself or for user data files. Application bundles belong in an appropriate /Applications directory, while user data belongs in the user’s home directory. This makes me question whether /Application might be the appropriate place? /Applications is typically for GUI applications as opposed to commandline programs. Though again, there are a few examples of toolchains which cross that boundary and use /Applications (e.g., TeX Live). Commandline apps which are deemed sufficiently GUI tend to go in /Applications/Utilities which is another option (not that Haskell really belongs there). -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
