Re: [Haskell-cafe] Python is lazier than Haskell
On Fri, Apr 29, 2011 at 12:42 AM, Gregg Reynolds d...@mobileink.com wrote: On Thu, Apr 28, 2011 at 11:38 PM, Ben Lippmeier b...@ouroborus.net wrote: Laziness at the value level causes space leaks, and laziness at the type level causes mind leaks. Neither are much fun. If the designers could find a way to support laziness at the programmer level I for one would be very grateful. I believe I saw a specification for such a language once. Unfortunately it was also lazy at the ontological level, and since nothing logically required the spec to exist it actually didn't. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Iteratee: manyToOne
Thank you! Working implementation is even more than I've expected. 2011/4/28 Felipe Almeida Lessa felipe.le...@gmail.com On Thu, Apr 28, 2011 at 1:10 PM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: On Thu, Apr 28, 2011 at 12:09 PM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: I foresee one problem: what is the leftover of 'manyToOne xs' if each x in xs needs different lengths of input? One possible untested-but-compiling solution: [snip] Like I said, that manyToOne implementation isn't very predictable about leftovers. But I guess that if all your iteratees consume the same input OR if you don't care about leftovers, then it should be okay. Sorry for replying to myself again. =) I think you can actually give predictable semantics to manyToOne: namely, the leftovers from the last iteratee are returned. This new implementation should be better: import Data.Monoid (mappend) import qualified Data.Enumerator as E manyToOne :: Monad m = [E.Iteratee a m b] - E.Iteratee a m [b] manyToOne is = E.Iteratee $ mapM E.runIteratee is = E.runIteratee . go where go [step] = fmap (:[]) (E.returnI step) go (E.Yield b _ : xs) = fmap (b:) (go xs) go (E.Error exc : _) = E.returnI (E.Error exc) go (E.Continue f : xs) = E.continue $ go' (E.Continue f : xs) go [] = return [] go' xs stream = manyToOne $ feed xs where feed [E.Yield b s] = [E.yield b (s `mappend` stream)] feed (E.Continue f : ys) = f stream : feed ys feed (step : ys) = E.returnI step : feed ys feed [] = [] With the same test as before: *Main E.run $ E.enumList 1 [5 :: Int, 6, 7] E.$$ manyToOne [return 1, maybe 2 id `fmap` E.head, return 3, maybe 4 id `fmap` (E.head E.head)] = \xs - (,) xs `fmap` E.head Right ([1,5,3,6],Just 7) *Main E.run $ E.enumList 10 [5 :: Int, 6, 7] E.$$ manyToOne [return 1, maybe 2 id `fmap` E.head, return 3, maybe 4 id `fmap` (E.head E.head)] = \xs - (,) xs `fmap` E.head Right ([1,5,3,6],Just 7) When the last iteratee doesn't consume anything: *Main E.run $ E.enumList 1 [5 :: Int, 6, 7] E.$$ manyToOne [return 1, maybe 2 id `fmap` E.head, return 3, maybe 4 id `fmap` (E.head E.head), return 10] = \xs - (,) xs `fmap` E.head Right ([1,5,3,6,10],Just 5) *Main E.run $ E.enumList 10 [5 :: Int, 6, 7] E.$$ manyToOne [return 1, maybe 2 id `fmap` E.head, return 3, maybe 4 id `fmap` (E.head E.head), return 10] = \xs - (,) xs `fmap` E.head Right ([1,5,3,6,10],Just 5) HTH, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wai and http-enumerator not as lazy as I'd like
On Fri, Apr 29, 2011 at 2:49 AM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Antoine Latter wrote: None of the lbs functions in http-enumerator can operate in constant space - they are all built on top of the utility function lbsIter which provides a warning: Convert the HTTP response into a Response value. Even though a Response contains a lazy bytestring, this function does not utilize lazy I/O, and therefore the entire response body will live in memory. If you want constant memory usage, you'll need to write your own iteratee and use http or httpRedirect directly. Thanks Antoine. I know I read the documention a number of times but still managed to fall into that trap. I think it was because I tired using httpDirect, couldn't figure it out and then fell back to using the non-lazy lbs version. Basically I need a serveRequest function with a signature: import qualified Network.HTTP.Enumerator as HE import qualified Network.Wai as Wai serveRequest :: (MonadControlIO m, Failure HE.HttpException m) = HE.Request m - m Wai.Response that calls httpRedirect to do a lazy download of the specified data and returns it as a Wai.Response using the ResponseEnumerator constructor. Unfortunately, I've tried a bunch if stuff and nothing I've come up with even comes close t type checking. Has anyone done anything like this and care to shed some light? It's a little bit complicated, but hopefully this should help out: import qualified Network.Wai as Wai import qualified Network.Wai.Handler.Warp as Warp import qualified Network.HTTP.Enumerator as HTTP import Control.Monad.IO.Class (liftIO) import Data.Maybe (fromJust) import qualified Data.Enumerator as Enum import qualified Data.Enumerator.List as EnumList import Data.Enumerator ((=$)) import Blaze.ByteString.Builder (fromByteString) main :: IO () main = Warp.run 3000 app app :: Wai.Application app _ = liftIO $ HTTP.withManager $ \m - return $ Wai.ResponseEnumerator $ \f - Enum.run_ $ HTTP.httpRedirect myReq (toBuilder f) m where toBuilder f a b = EnumList.map fromByteString =$ f a b myReq :: HTTP.Request m myReq = fromJust $ HTTP.parseUrl http://www.yesodweb.com/; Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python is lazier than Haskell
On 29 Apr 2011, at 05:38, Ben Lippmeier b...@ouroborus.net wrote: Laziness at the value level causes space leaks, This is well-worn folklore, but a bit misleading. Most of my recent space leaks have been caused by excessive strictness. Space leaks occur in all kinds of programs and languages, and I am not convinced there is a strong correlation between laziness and leakiness. If anything, I think there is observation bias: lazy programmers have good tools for identifying, finding, and removing leaks. Others do not. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Binary and Serialize classes
When I need to comply with a specific binary format, I never rely on
Binary/Serialize class instances - I always fall back on the primitive
operations on Words of varying sizes (perhaps defining my own type
classes for convenience). The 'Builder' type makes this pretty easy.
If I were writing binary data to disk, in my mind that would fall
under complying with a specific binary format.
Indeed, and I was starting to do that... well, I would make my own
project specific Serialize class, since the type dispatch is useful.
But copy pasting a UTF8 encoder, or the variable length Integer
encoder, or whatever seemed kinda unpleasant. Surely we could expose
that stuff in a library, whose explicit goal was that they *would*
remain compatible ways to serialize various basic types, and then just
reuse those functions? E.g. that is already done for words with the
putWordN{be,le} functions, and is available separately for UTF8.
I do, however, rely on the SafeCopy class (or the equivalent
Happstack.Data.Serialize class) to be able to read it's own data back
from persistent storage - it is a specific design goal of the library
Indeed, I also wound up inventing my own versioning format, which
looks basically the same as safe copy, except much simpler, I just put
a version byte, and then case on that for deserialization. However, I
only put the version on things I have reason to change, and that
doesn't include built-in data types, like Integer or String. So it's
all my own data types, which I control the instance declarations for
anyway, so I'm not really worried about those.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How often is the planet updated?
On Thu, Apr 28, 2011 at 11:27:49PM -0600, Luke Palmer wrote: On Thu, Apr 28, 2011 at 4:26 AM, Magnus Therning mag...@therning.orgwrote: I see that Planet Haskell hasn't been updated since April 26. Is something wrong with it, or does it really not update more often than that? In the past it has reliably updated within an hour of my publishing a new post. Yes, that's my experience too. Currently the updating seems to be broken though, still no update since the 26th. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay pgpgCQ8DZB4lI.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make ghc 7 with llvm?
Others have answered your real question (I think) adequately, but if I'm pedantic and answer precisely what you ask: You can compile GHC with llvm by adding -fllvm to your build.mk file: GhcHcOpts += -fllvm Cheers, Edward Excerpts from Magicloud Magiclouds's message of Thu Apr 28 21:49:11 -0400 2011: Hi, As I recalled, ghc started to support llvm from version 7. But there is a problem: there is no option to make ghc with llvm. So Library within ghc source will be in gcc's binary format. Then when I install other packages, they may complain that the binary format is not llvm, so they install some libraries again. Any way I could make ghc 7 with llvm? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Iteratee: manyToOne
From: Felipe Almeida Lessa felipe.le...@gmail.com On Thu, Apr 28, 2011 at 1:10 PM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: On Thu, Apr 28, 2011 at 12:09 PM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: I foresee one problem: what is the leftover of 'manyToOne xs' if each x in xs needs different lengths of input? One possible untested-but-compiling solution: [snip] Like I said, that manyToOne implementation isn't very predictable about leftovers. ?But I guess that if all your iteratees consume the same input OR if you don't care about leftovers, then it should be okay. Sorry for replying to myself again. =) I think you can actually give predictable semantics to manyToOne: namely, the leftovers from the last iteratee are returned. This new implementation should be better: If you do this, the user needs to take care to order the iteratees so that the last iteratee has small leftovers. Consider: manyToOne [consumeALot, return ()] In this case, the entire stream consumed by the first iteratee will need to be retained and passed on by manyToOne. In many cases, the user may not know how much each iteratee will consume, which can make these semantics problematic. Iteratee has 'enumPair', (renamed 'zip' in HEAD) which returns the leftovers from whichever iteratee consumes more. This avoids the problem of retaining extra data, and seems simpler to reason about. Although if you really need to consume a predictable amount of data, the safest is probably to run the whole thing in a 'take'. John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python is lazier than Haskell
On 29/04/2011, at 6:08 PM, Malcolm Wallace wrote: On 29 Apr 2011, at 05:38, Ben Lippmeier b...@ouroborus.net wrote: Laziness at the value level causes space leaks, This is well-worn folklore, but a bit misleading. :-) Like permanent markers in the hands of children causes suffering. It's not a tautology, but an overgeneralisation that holds more often than not. If anything, I think there is observation bias: lazy programmers have good tools for identifying, finding, and removing leaks. Others do not. Sharp tools well honed through years of hunting them down. If only they were never there in the first place. I don't disagree with you. My original comment was more bait than anything else. Ben. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python is lazier than Haskell
On 29 Apr 2011, at 10:42, Ben Lippmeier wrote: On 29/04/2011, at 6:08 PM, Malcolm Wallace wrote: On 29 Apr 2011, at 05:38, Ben Lippmeier b...@ouroborus.net wrote: Laziness at the value level causes space leaks, This is well-worn folklore, but a bit misleading. :-) Like permanent markers in the hands of children causes suffering. It's not a tautology, but an overgeneralisation that holds more often than not. I completely disagree, like Malcolm Wallace, space leaks in my code have *more often* been to do with being too strict than being too non-strict. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python is lazier than Haskell
Chris Smith cdsm...@gmail.com wrote: Sometimes I wish for a -fphp flag that would turn some type errors into warnings. Example: v.hs:8:6: Couldn't match expected type `[a]' against inferred type `()' In the first argument of `a', namely `y' In the expression: a y In the definition of `c': c = a y GHC could substitute 'y = error Couldn't match expected type `[a]' against inferred type `()'' and compile anyway. Would that bring Haskell closer to Python? It would make people abuse that feature. I don't want it. I do, particularly in GHCi. I don't mind if Haskell refuses to build a binary, but having to comment out coded in order to load bits in GHCi is definitely a pain. I wonder why I don't have to do that. You may be thinking in a different language. With the semantics of Haskell also comes a certain programming style, I think. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Iteratee: manyToOne
On Fri, Apr 29, 2011 at 6:32 AM, John Lato jwl...@gmail.com wrote: If you do this, the user needs to take care to order the iteratees so that the last iteratee has small leftovers. Consider: manyToOne [consumeALot, return ()] In this case, the entire stream consumed by the first iteratee will need to be retained and passed on by manyToOne. In many cases, the user may not know how much each iteratee will consume, which can make these semantics problematic. Iteratee has 'enumPair', (renamed 'zip' in HEAD) which returns the leftovers from whichever iteratee consumes more. This avoids the problem of retaining extra data, and seems simpler to reason about. Although if you really need to consume a predictable amount of data, the safest is probably to run the whole thing in a 'take'. My motivation is: in general it is difficult (impossible?) to choose the iteratee that consumed more data because you don't know what the data is. For example, if you give 'Chunks [a,b]' to two iteratees and one of them returns 'Chunks [c]' and the other one returns 'Chunks [d]', which one consumed more data? The answer is that it depends on the types. If they are Ints, both consumed the same, if they are ByteStrings, you would need to check if one is prefix of the other. What if one returns 'Chunks [c]' and the other one returns 'Chunks [d,e]'? If they are ByteStrings, should we compare 'c' against 'd ++ e'? So I thought it would be easier to program with an API that is predictable and immune to changes in block sizes. If you don't want leftovers, just use 'manyToOne [..., dropWhile (const True)]', which guarantees that you won't leak. Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Iteratee: manyToOne
On Fri, Apr 29, 2011 at 12:20 PM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: On Fri, Apr 29, 2011 at 6:32 AM, John Lato jwl...@gmail.com wrote: If you do this, the user needs to take care to order the iteratees so that the last iteratee has small leftovers. Consider: manyToOne [consumeALot, return ()] In this case, the entire stream consumed by the first iteratee will need to be retained and passed on by manyToOne. In many cases, the user may not know how much each iteratee will consume, which can make these semantics problematic. Iteratee has 'enumPair', (renamed 'zip' in HEAD) which returns the leftovers from whichever iteratee consumes more. This avoids the problem of retaining extra data, and seems simpler to reason about. Although if you really need to consume a predictable amount of data, the safest is probably to run the whole thing in a 'take'. My motivation is: in general it is difficult (impossible?) to choose the iteratee that consumed more data because you don't know what the data is. For example, if you give 'Chunks [a,b]' to two iteratees and one of them returns 'Chunks [c]' and the other one returns 'Chunks [d]', which one consumed more data? The answer is that it depends on the types. If they are Ints, both consumed the same, if they are ByteStrings, you would need to check if one is prefix of the other. What if one returns 'Chunks [c]' and the other one returns 'Chunks [d,e]'? If they are ByteStrings, should we compare 'c' against 'd ++ e'? This situation results from the implementation in the enumerator package. In iteratee it doesn't arise with well-behaved* iteratees, because only one chunk is ever processed at a time. It's only necessary to check the length of the returned chunks to see which consumed more data. By well-behaved, I mean that the chunk returned by an iteratee must be a tail of the provided input. In other words, it returns only unconsumed data from the stream and doesn't alter the stream. At least in the iteratee package, an iteratee which violates this rule is likely to result in undefined behavior (in general, not just this function). So I thought it would be easier to program with an API that is predictable and immune to changes in block sizes. If you don't want leftovers, just use 'manyToOne [..., dropWhile (const True)]', which guarantees that you won't leak. Iteratees should be immune to changes in block sizes anyway, although it's been a while since I looked at the enumerator implementation so it could be different. If you use 'manyToOne [..., dropWhile (const True)]', when does it terminate? John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Inputs to classic FRP: unsafeInterleaveIO/unsafePerformIO
Ryan Ingram wrote: Heinrich Apfelmus wrote: However, even in a demand-driven implementation, there is one optimization that I would like make: when there are multiple external events, say e1 and e2, the network splits into subnetworks that react only to one of the inputs. For instance, your example would split into two graphs e1 e2 | \ | \ e3 e4 and e3 e4 | || | e5 e5 e5 e5 that are independent of each other. Unlike successful filters, these subnetworks are known *statically* and it's worth splitting them out. Yeah, I realize that as well, although you can get the same problem with a single source, it just makes the network a bit more complicated: e0 = source e1 = fromLeft $ filter isLeft e1 e2 = fromRight $ filter isRight e1 -- rest of network the same Anyways, the problem I was getting at is that lets say that e1 and e2 are both Event Bool, and e1 has a True event at the same time that e2 has a False event. Then a behavior derived from e3 is False for that time (assuming behaviors take the 'last' event in the list?), and a behavior from e4 is True for that time. Yep, that's precisely what will happen. Internally, the four pillars in the graph e1e2 | \-A | \ A-\ e3e3 e4e4 | | || e5e5 e5e5 1 2 3 4-- pillar will simply be executed from left to right (in particular not in depth-first search order). The edge connecting e1 and e4 signifies that the value of e1 will be cached when the first pillar is executed, so that it is available again a few pillars later when it's time for the fourth pillar. Concerning the behaviors, also note that a behaviors change slightly later than the events from which they are derived. Semantically, we have stepper x ex = \time - last $ x : [y | (time', y) - ex, time' time] In particular, the strict comparisonmeans that the behavior still has the previous value when the event happens. So, indeed, a behavior derived from e3 will pick up the last False while a behavior derived from e4 will pick up the last True. Best 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] A small Darcs anomoly
On 28/04/2011 03:21 PM, Chris Smith wrote: On Thu, 2011-04-28 at 08:04 +0200, Bardur Arantsson wrote: There's also the fact that using in-repo branches means that all the tooling doesn't have to rely on any (fs-specific) conventions for finding branches. As someone who has admin'd a reasonably large Bazaar setup (where branch == directory similarly to Darcs) I can honestly say that this would be a HUGE boon. Just keep in mind that adding branches withing the repository is a massive increase in the conceptual complexity of the system, and it would IMO be very un-darcs-like to adopt something like that into the core mental model you need to use a darcs repository, only because of incidental conveniences Convention, rather than baking answers into tools, is the right way to solve organizational problems, and that's essentially what we're talking about here. And adding complexity every time someone has an awkward use case will lead (has led, in more systems than I can count) to an unusable result in the end. It seems half the people here think that having multiple branches per repo is a fantastic idea, while the other half think it's a stupid idea. Perhaps there is room for more than one revision control system based on change-sets in this world? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Iteratee: manyToOne
In my case leftover is not important. But in common case... Just an idea... What if we provide iterWhile :: Iteratee a m () - Iteratee a m b - Iteratee a m b The first Iteratee only control when the result should be yeilded and feed an input to second Iteratee. Then we can change manyToOne to manyToOne' :: Iteratee a m () - [Iteratee a m b] - Iteratee a m [b] manyToOne' iw = iterWhile iw . manyToOne 2011/4/29 Felipe Almeida Lessa felipe.le...@gmail.com On Fri, Apr 29, 2011 at 6:32 AM, John Lato jwl...@gmail.com wrote: If you do this, the user needs to take care to order the iteratees so that the last iteratee has small leftovers. Consider: manyToOne [consumeALot, return ()] In this case, the entire stream consumed by the first iteratee will need to be retained and passed on by manyToOne. In many cases, the user may not know how much each iteratee will consume, which can make these semantics problematic. Iteratee has 'enumPair', (renamed 'zip' in HEAD) which returns the leftovers from whichever iteratee consumes more. This avoids the problem of retaining extra data, and seems simpler to reason about. Although if you really need to consume a predictable amount of data, the safest is probably to run the whole thing in a 'take'. My motivation is: in general it is difficult (impossible?) to choose the iteratee that consumed more data because you don't know what the data is. For example, if you give 'Chunks [a,b]' to two iteratees and one of them returns 'Chunks [c]' and the other one returns 'Chunks [d]', which one consumed more data? The answer is that it depends on the types. If they are Ints, both consumed the same, if they are ByteStrings, you would need to check if one is prefix of the other. What if one returns 'Chunks [c]' and the other one returns 'Chunks [d,e]'? If they are ByteStrings, should we compare 'c' against 'd ++ e'? So I thought it would be easier to program with an API that is predictable and immune to changes in block sizes. If you don't want leftovers, just use 'manyToOne [..., dropWhile (const True)]', which guarantees that you won't leak. Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Leksah 0.10.0
My guess is that you're doing all indexing work inside a single GHC API session. When loading external packages GHC caches all .hi files in memory -- and never unloads them. Therefore, if you have a large package DB, that'll consume a lot of memory. For similar reasons you can also run into problems with redefined instances if you happen to process two packages that define the same instances because they too are cached and never flushed. The workaround is to start multiple sessions and then combine the resulting output. I don't know how much of a problem the Haddock + TH issue is that David mentioned. In any case you should make sure that haddock can see the installed packages so it doesn't need to compile any dependencies for TH. On 28 April 2011 09:04, jutaro j...@arcor.de wrote: Hi Daniel, that seemed to be a real odyssey. I will try to install the statistics package when I find time. Guess it is this one on hackage: http://hackage.haskell.org/package/statistics. Just some remarks: In case of problems with metadata it is helpful to stop the GUI and call leksah-server from the command line. (leksah-server -s collects metainfo for new packages). What happens then is that leksah-server calls GHC-API and Haddock as a library, which itself uses GHC-API. So its a bit like running Haddock on a package, which usually may fail, but it is uncommon to have this kind of problems. (It happened one time before with a type level library, which defined all integers between 1 and several thousands...). Jürgen PS: The server at leksah.org has reached its limit yesterday, the Windows installer alone was downloaded about 2000 times! But it should work now. -- View this message in context: http://haskell.1045720.n5.nabble.com/ANN-Leksah-0-10-0-tp4332741p4345891.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make ghc 7 with llvm?
On Fri, 29 Apr 2011, Erik de Castro Lopo wrote: Magicloud Magiclouds wrote: Then when I install other packages, they may complain that the binary format is not llvm, so they install some libraries again. You seem to think there is a problem where this is no problem :-). Nontheless it might be interesting to let GHC emit LLVM bitcode. As far as I understand, this would enable LLVM's Link Time Optimizations. http://llvm.org/docs/LinkTimeOptimization.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] versioning of Haskell packages
Hello list I have an idea on versioning of Haskell packages and a small question about release model of Haskell Platform. Since the latter is shorter let's start with it. So, what is the release model of Haskell Platform? Is it released every N months and frozen at that point? Or some intermediate package/compiler updates can make the new version to appear out of schedule? Now, about package versioning. Haskell packages are flourishing and evolving at a high speed. Packages depend on other package and they evolve asynchronously. In result it is easy to end up in need of multiple versions of the same package in one program or maybe stumble upon other conflicts/problems. I'm expressing myself a little vaguely because I don't have a good example in my head right now. However, the idea is to maintain not just multi-digit version names that don't carry any semantics except that 1.1.3 is later than 1.1.2, but also somehow describe compatibility between versions. This way, even if the package A has jumped from 1.0 to 1.5 and the dependent package B has been stagnant all this time (and B depends on A 1.0), if we have information that 1.5 is compatible with 1.0, then we can safely use A 1.5 while building B. Or we could use whatever version of A is found in the system as long as its compatible with A 1.0 that B depends on. The compatibility relation can be made more fine grained and be applied not at the level of packages but that of modules, for example. This way, if we only use modules that are compatible with the version we depend on, it's fine to go with the newer version. Even if the package as a whole is not compatible. Also, when doing this at the level of modules, package authors could deliberately maintain compatibility by leaving the API of old modules intact and making them sort of wrappers to the new API which itself is not compatible with the older version. Of course, if the case when a newer version is backwards compatible is rare for most Haskell packages, then the idea doesn't make a lot of sense. But if it's common, then this could simplify building packages/programs and maintaining installed packages. What do you think? -- Daniil Elovkov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] versioning of Haskell packages
On Sat, Apr 30, 2011 at 02:05:39AM +0400, Daniil Elovkov wrote: Hello list I have an idea on versioning of Haskell packages and a small question about release model of Haskell Platform. Since the latter is shorter let's start with it. So, what is the release model of Haskell Platform? Is it released every N months and frozen at that point? Or some intermediate package/compiler updates can make the new version to appear out of schedule? Now, about package versioning. Haskell packages are flourishing and evolving at a high speed. Packages depend on other package and they evolve asynchronously. In result it is easy to end up in need of multiple versions of the same package in one program or maybe stumble upon other conflicts/problems. I'm expressing myself a little vaguely because I don't have a good example in my head right now. However, the idea is to maintain not just multi-digit version names that don't carry any semantics except that 1.1.3 is later than 1.1.2, but also somehow describe compatibility between versions. This way, even if the package A has jumped from 1.0 to 1.5 and the dependent package B has been stagnant all this time (and B depends on A 1.0), if we have information that 1.5 is compatible with 1.0, then we can safely use A 1.5 while building B. Or we could use whatever version of A is found in the system as long as its compatible with A 1.0 that B depends on. The compatibility relation can be made more fine grained and be applied not at the level of packages but that of modules, for example. This way, if we only use modules that are compatible with the version we depend on, it's fine to go with the newer version. Even if the package as a whole is not compatible. Also, when doing this at the level of modules, package authors could deliberately maintain compatibility by leaving the API of old modules intact and making them sort of wrappers to the new API which itself is not compatible with the older version. Of course, if the case when a newer version is backwards compatible is rare for most Haskell packages, then the idea doesn't make a lot of sense. But if it's common, then this could simplify building packages/programs and maintaining installed packages. What do you think? Why is dependencies expressed as ranges not enough to cover this? In fact, Cabal allows not only ranges, but also rather more complicated logical expressions of versions, for dependencies. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay pgpUUgdtMLUQc.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make ghc 7 with llvm?
Hi, Henning Thielemann lemming at henning-thielemann.de writes: Nontheless it might be interesting to let GHC emit LLVM bitcode. As far as I understand, this would enable LLVM's Link Time Optimizations. You can already emit .ll code with -ddump-llvm. All LLVM tools that take .bc files as input (llc/opt/llvm-link) can also read .ll (look at llvm/Support/IRReader.h). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make ghc 7 with llvm?
Henning Thielemann lemming at henning-thielemann.de writes: Nontheless it might be interesting to let GHC emit LLVM bitcode. As far as I understand, this would enable LLVM's Link Time Optimizations. And if you really need .bc, there is always llvm-as. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] versioning of Haskell packages
On Fri, Apr 29, 2011 at 3:05 PM, Daniil Elovkov daniil.elov...@gmail.com wrote: Hello list I have an idea on versioning of Haskell packages and a small question about release model of Haskell Platform. Since the latter is shorter let's start with it. So, what is the release model of Haskell Platform? Is it released every N months and frozen at that point? Or some intermediate package/compiler updates can make the new version to appear out of schedule? Now, about package versioning. Haskell packages are flourishing and evolving at a high speed. Packages depend on other package and they evolve asynchronously. In result it is easy to end up in need of multiple versions of the same package in one program or maybe stumble upon other conflicts/problems. I'm expressing myself a little vaguely because I don't have a good example in my head right now. However, the idea is to maintain not just multi-digit version names that don't carry any semantics except that 1.1.3 is later than 1.1.2, but also somehow describe compatibility between versions. This way, even if the package A has jumped from 1.0 to 1.5 and the dependent package B has been stagnant all this time (and B depends on A 1.0), if we have information that 1.5 is compatible with 1.0, then we can safely use A 1.5 while building B. Or we could use whatever version of A is found in the system as long as its compatible with A 1.0 that B depends on. I think the PVP (Package Versioning Policy) covers a lot of what you're discussing, but I may misunderstand: http://www.haskell.org/haskellwiki/Package_versioning_policy We *do* still have some trouble maintaining / enforcing the PVP in general, and there are a few things that it doesn't cover (I don't believe exception behavior is covered, for example, although I'd argue that throwing more exceptions than a previous version introduces a substantial API change. Anyhow, that's a different rant. ;). Finer granularity would be great -- if it can be done autonomously. I think that raising awareness of the PVP and refining the tools to check for necessary version bumps would be a great step in the right direction. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
