Re: [Haskell-cafe] Re: [web-devel] statically compiled css
On Mon, Aug 9, 2010 at 4:14 PM, Liam O'Connor wrote: > @Michael: Have you seen the JSMacro package on hackage? I think it might be > a better fit as it adds some nice syntactic goodies to JS in addition to > variable interpolation. > > I assume you're referring to JMacro, correct? I wasn't able to get it to build at the moment, and even if it *did* build, it has a lot of dependencies, which isn't something I'd like to subject Hamlet users to. Also, probably the most important feature for me in the Javascript templating will be type-safe URLs, which I don't think JMacro supports. Also, I thought I'd publish the results of the naming survey[1]. Summary: overwhelming support for Cassius, Julius and Mustard. I thought I'd also publish some of the best comments here, please feel free to claim them: Thank you for replacing some layers of brittle duck tape with good static duct type :) I hope you don't end up with a mismatch like Camlet and Jsaesar; that would be awkward. Also, I just noticed this, but Camlet might lead to some confusion with the Caml family of languages. I bathe in the blood of my enemies; eating it would be disgusting! I'm just running a few compiles to make sure everything went fine, and will then be pushing to github. Michael [1] http://spreadsheets.google.com/pub?key=0Aj9dwvcPwQ9ldHVOU2p6OVRkcWVQVG10d01OWk8yU2c&hl=en&output=html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCE] (and request for review): directory-tree v0.9.0
On Tue, Aug 10, 2010 at 5:54 PM, Brandon Simmons < brandon.m.simm...@gmail.com> wrote: > On Tue, Aug 10, 2010 at 4:34 PM, Jason Dagit wrote: > > > > > > On Mon, Aug 9, 2010 at 10:48 PM, Brandon Simmons > > wrote: > >> > >> Greetings Haskellers! > >> > >> directory-tree is a module providing a directory-tree-like datatype > >> along with Foldable and Traversable instances, along with a simple, > >> high-level IO interface. You can see the package along with some > >> examples here (apologies if the haddock docs haven't been generated > >> yet) : > >> > >>http://hackage.haskell.org/package/directory-tree > > > > If I understand what you're saying, then your library is very similar to > an > > abstraction that darcs had for years knows as "Slurpy". The experience > in > > the darcs project was that it lead to performance issues and correctness > > issues that were hard to find/fix. > >> > >> This primary change in this release is the addition of two > >> experimental "lazy" functions: `readDirectoryWithL` and `buildL`. > >> These functions use `unsafePerformIO` behind the scenes to traverse > >> the filesystem as required by pure computations consuming the returned > >> DirTree data structure. I believe I am doing this safely and sanely > >> but would love if some more experienced folks could comment on the > >> code. > > > > unsafePerformIO or unsafeInterleaveIO? > > Either way, to me it seems a bit dangerous to be doing this sort of lazy > IO. > > If the directory structure is large will I run out of file handles? How > > will IO errors be handled? Will I receive the exceptions in pure code or > > inside my IO actions? Will I run into space leaks if something holds on > to > > 1 file and then references it "after" the directory traversal? I might > have > > my history wrong, but as I recall darcs started with lazy slurpies and > moved > > to doing things strictly due to space leaks, running out of file > > descriptors, file descriptor leaks (not running out, but having the file > be > > locked long after darcs should have been 'done' with it), and exception > > delivery. > > IO Errors are caught in a pure constructor called "Failed". In > practice I think my unsafe version is better in many of those respects > than the original, for example with regard to running out of file > handles. Are you referring to lazy IO in general, which those problems > you mention seem to apply to, or the use of unsafePerformIO? > It boils down to the same thing right? > > I certainly want this module to be as useful and problem-free as > possible, but I will be content if it is no less problematic than lazy > IO is problematic. > > Could you elaborate on > >> "Will I run into space leaks if something holds on to1 file and > then references >> it "after" the directory traversal"? > > Let me give you an example. Prelude's readFile is lazy. That is, it returns immediately and then only fetches from the file as you demand the contents of the file. This makes it possible to stream the file. If you process it chunks, say 1 line at a time, then you can do so in constant space. If you then let the contents of the file escape, meaning somewhere else in the processing references it, then you'll stop streaming it and start holding on to the whole thing at once. Something like this, untested: notleaky1 = do xs <- readFile "foo" mapM_ print (lines xs) notleaky2 = do xs <- readFile "foo" print (length xs) leaky = do xs <- readFile "foo" mapM_ print (lines xs) print (length xs) handleleak = do xs <- readFile "foo" return (take 10 xs) Now, in leaky if you calculated the length and printed the lines in the same iteration, the leak would go away. In the handleleak example the file stays open even after handleleak produces all 10 elements. Now imagine those examples in terms of directory traversals instead of read from a file. This would still be a problem even if replace readFile with readFile': readFile' f = unsafePerformIO (readFile f) I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCE] (and request for review): directory-tree v0.9.0
On Tue, Aug 10, 2010 at 4:34 PM, Jason Dagit wrote: > > > On Mon, Aug 9, 2010 at 10:48 PM, Brandon Simmons > wrote: >> >> Greetings Haskellers! >> >> directory-tree is a module providing a directory-tree-like datatype >> along with Foldable and Traversable instances, along with a simple, >> high-level IO interface. You can see the package along with some >> examples here (apologies if the haddock docs haven't been generated >> yet) : >> >> http://hackage.haskell.org/package/directory-tree > > If I understand what you're saying, then your library is very similar to an > abstraction that darcs had for years knows as "Slurpy". The experience in > the darcs project was that it lead to performance issues and correctness > issues that were hard to find/fix. >> >> This primary change in this release is the addition of two >> experimental "lazy" functions: `readDirectoryWithL` and `buildL`. >> These functions use `unsafePerformIO` behind the scenes to traverse >> the filesystem as required by pure computations consuming the returned >> DirTree data structure. I believe I am doing this safely and sanely >> but would love if some more experienced folks could comment on the >> code. > > unsafePerformIO or unsafeInterleaveIO? > Either way, to me it seems a bit dangerous to be doing this sort of lazy IO. > If the directory structure is large will I run out of file handles? How > will IO errors be handled? Will I receive the exceptions in pure code or > inside my IO actions? Will I run into space leaks if something holds on to > 1 file and then references it "after" the directory traversal? I might have > my history wrong, but as I recall darcs started with lazy slurpies and moved > to doing things strictly due to space leaks, running out of file > descriptors, file descriptor leaks (not running out, but having the file be > locked long after darcs should have been 'done' with it), and exception > delivery. IO Errors are caught in a pure constructor called "Failed". In practice I think my unsafe version is better in many of those respects than the original, for example with regard to running out of file handles. Are you referring to lazy IO in general, which those problems you mention seem to apply to, or the use of unsafePerformIO? I certainly want this module to be as useful and problem-free as possible, but I will be content if it is no less problematic than lazy IO is problematic. Could you elaborate on > "Will I run into space leaks if something holds on to1 file and then references > it "after" the directory traversal"? ? > It's a seductive path but one that does not seem to have a good ending. > I'm not sure what darcs uses these days. Perhaps that's what hashed-storage > provides, although I haven't been able to find any documentation on > hashed-storage other than the haddocks (which only document the api with no > overview or explanation of the problem hashed-storage solves). > Jason Eric Kow just pointed out the existence of hashed-storage to me (I believe you are right that it is what darcs does/will use) and it will be interesting to see the approach in there, if I can grok it. Thanks a lot for the input. Brandon Simmons http://coder.bsimmons.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] StablePtr overhead?
greg: > Hi all, > > Can anyone explain what the overhead of using StablePtrs is? > Specifically I am interested in knowing the time/space complexity of the > various Foreign.StablePtr operations and how many memory indirections > are involved when using deRefStablePtr. There's a hashtable in the runtime that maps pointers to stable pointers. So you have that overhead. Create N StablePtrs, and get a correspondingly large hashtable. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] StablePtr overhead?
Hi all, Can anyone explain what the overhead of using StablePtrs is? Specifically I am interested in knowing the time/space complexity of the various Foreign.StablePtr operations and how many memory indirections are involved when using deRefStablePtr. G -- Gregory Collins ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
On Sun, Aug 08, 2010 at 01:08:30AM +, Mathew de Detrich wrote: > In my opinion the most "reliable" approach would actually to produce the C > that wraps around NDK (for any code that could be possible) which would > obviously interface with the Java libraries. Probably the biggest bane of > Android is the fact that its able to run on almost all machines means that > there *would* be issues using LLVM to just produce code for the generic ARM. I have heard anecdotal reports that the output from jhc can be compiled with the NDK to android aps with minor changes. If anyone wanted to run with this, I'd add it as a first class target platform for jhc. 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
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
On Tue, Aug 10, 2010 at 4:23 PM, Mathew de Detrich wrote: > > There still however leaves the problem with what to do with Java, because a > proper Android app (not a linux app compiled for ARM) needs to link with > Java to interface with Android I'm interested in getting jvm-bridge working again, but I've run into problems with understanding how it interfaces with 3rd party source. I would welcome the help if anyone else is also interested :) (are the original authors still around?). The basic capabilities seem to work fine with minor build fixes -- the examples that only use the core java libraries were easy to use. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
I just did some further talking with Liam, and it appears that the NDK really just produces an ARM binary which ends up getting linked into the Dalvik VM files (it isn't platform independant as I thought) which means that using LLVM to produce an ARM ASM output is a fine choice. By the sounds of it the NDK is designed to be platform dependant (not independent) so it appears that if any Android system does come out in the future that doesn't use ARM, you would have the same issue with NDK There still however leaves the problem with what to do with Java, because a proper Android app (not a linux app compiled for ARM) needs to link with Java to interface with Android On Tue, Aug 10, 2010 at 8:21 PM, Karel Gardas wrote: > On 08/08/10 03:08, Mathew de Detrich wrote: > > Well the other issue is of course that Android being available on a wide > > variety of phones, not all of which run ARM (the phone I am about to get > for > > example has a custom built CPU), although I guess one could use a > "generic" > > ASM branch for "mobile" devices (if one exists). btw the phone I am about > to > > receive is a Samsung Galaxy-S, which has a hummingbird chip (no idea what > > Assembler Instruction set it uses, I believe its a closed chip) > > This should be S5PC110 if I google correctly which is "just" yet another > ARM Cortex A8: > > http://www.samsung.com/global/business/semiconductor/newsView.do?news_id=1043 > > Karel > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On 8/10/10 23:53, Felipe Lessa wrote:
and the result is "IO Int". When we "replace the function call by its
result", I think it is fair to replace the C function call by an "int"
and the Haskell function call by an "IO Int", because that is what
those functions return.
Fair enough. :-)
Also, a correction to what I said earlier: it's not C's = that
corresponds to a bind <-, it's (...args...) that does. I think.
On a side note, imperative languages with first-class
functions/delegates can express your Haskell example. For example,
Javascript:
var x = function() { return randomNumber(10, 15); }
return x() + x();
Martijn.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On Tue, Aug 10, 2010 at 6:36 PM, Martijn van Steenbergen wrote: > On 8/10/10 23:27, Felipe Lessa wrote: >> >> If we had in C: >> >> return (randomNumber(10, 15) + randomNumber(10, 15)) >> >> That would not be the same as: >> >> int x = randomNumber(10, 15) >> return (x + x) > > That's not fair. You're comparing C's '=' with Haskell's '='. But you should > be comparing C's '=' with Haskell's '<-'. > > In your Haskell example, x :: IO Int. In your C example, x :: Int. Well, then maybe we will agree with eachother when we decide on what is "fair". =) You quoted: Given the definition of a Haskell function, Haskell is a pure language. The notion of a function in other languages is not: int randomNumber(); The result of this function is an integer. You can't replace the function call by its result without changing the meaning of the program. So, given the functions int randomNumber(int, int) randomNumber :: Int -> Int -> IO Int what is "replace the function call by its result"? Function call in C is, for example, randomNumber(10, 15); and the result of this call has type "int". In Haskell, what is a function call? Well, it's randomNumber 10 15 and the result is "IO Int". When we "replace the function call by its result", I think it is fair to replace the C function call by an "int" and the Haskell function call by an "IO Int", because that is what those functions return. To fit your definition of fairness I would have to say that function application is \cont -> randomNumber 10 15 >>= \x -> cont x which has type "(Int -> IO a) -> IO a". I don't think this is function call at all, and only works for monads. IMHO, Ertugrul was pointing out the difference of C's int and Haskell's IO Int. An 'IO Int' may be passed around and you don't change the meaning of anything. Cheers, =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On 8/10/10 23:27, Felipe Lessa wrote: If we had in C: return (randomNumber(10, 15) + randomNumber(10, 15)) That would not be the same as: int x = randomNumber(10, 15) return (x + x) That's not fair. You're comparing C's '=' with Haskell's '='. But you should be comparing C's '=' with Haskell's '<-'. In your Haskell example, x :: IO Int. In your C example, x :: Int. Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On Tue, 10 Aug 2010 18:27:49 -0300, you wrote: >Nope. For example, suppose we have: > > int randomNumber(int min, int max); > >Equivalentely: > > randomNumber :: Int -> Int -> IO Int > >In Haskell if we say > > (+) <$> randomNumber 10 15 <*> randomNumber 10 15 > >That's the same as > > let x = randomNumber 10 15 > in (+) <$> x <*> x > >If we had in C: > > return (randomNumber(10, 15) + randomNumber(10, 15)) > >That would not be the same as: > > int x = randomNumber(10, 15) > return (x + x) I think you're misinterpreting what Martijn is saying. He's not talking about referential transparency at all. What he's saying is that in a language like C, you can always replace a function call with the code that constitutes the body of that function. In C-speak, you can "inline" the function. -Steve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On Tue, Aug 10, 2010 at 6:21 PM, Martijn van Steenbergen wrote: > On 8/2/10 7:09, Ertugrul Soeylemez wrote: >> >> Given the definition of a Haskell function, Haskell is a pure language. >> The notion of a function in other languages is not: >> >> int randomNumber(); >> >> The result of this function is an integer. You can't replace the >> function call by its result without changing the meaning of the program. > > I'm not sure this is fair. It's perfectly okay to replace a call > "randomNumber()" by that method's *body* (1), which is what you argue is > okay in Haskell. Nope. For example, suppose we have: int randomNumber(int min, int max); Equivalentely: randomNumber :: Int -> Int -> IO Int In Haskell if we say (+) <$> randomNumber 10 15 <*> randomNumber 10 15 That's the same as let x = randomNumber 10 15 in (+) <$> x <*> x If we had in C: return (randomNumber(10, 15) + randomNumber(10, 15)) That would not be the same as: int x = randomNumber(10, 15) return (x + x) Cheers! -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unused import warnings.
Fantastic. It was the bug mentioned. On Wed, Aug 11, 2010 at 5:00 AM, Martijn van Steenbergen wrote: > Are you saying that GHC complains about an unused import that is in fact > used? Perhaps you've run into this bug: > http://hackage.haskell.org/trac/ghc/ticket/1148 > > Are you using a recent version of GHC? > > Groetjes, > > Martijn. > > > On 8/10/10 22:22, Lyndon Maydwell wrote: >> >> Hi Cafe. >> >> I have written some QuickCheck properties in my source and am using >> these for testing, however, when I compile my program I get warned >> about unused imports: >> >>> Warning: Module `Test.QuickCheck' is imported, but nothing from it is >>> used >> >> Is there a way to suppress these warnings for a particular module by >> using a pragma directive or something similar? >> >> >> Thanks! >> >> - Lyndon >> ___ >> 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] Re: Can we come out of a monad?
On 8/2/10 7:09, Ertugrul Soeylemez wrote: Given the definition of a Haskell function, Haskell is a pure language. The notion of a function in other languages is not: int randomNumber(); The result of this function is an integer. You can't replace the function call by its result without changing the meaning of the program. I'm not sure this is fair. It's perfectly okay to replace a call "randomNumber()" by that method's *body* (1), which is what you argue is okay in Haskell. Martijn. (1) Modulo some renaming, and modulo the complicated non-compositional meanings of control statements such as "return", etc. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unused import warnings.
Are you saying that GHC complains about an unused import that is in fact used? Perhaps you've run into this bug: http://hackage.haskell.org/trac/ghc/ticket/1148 Are you using a recent version of GHC? Groetjes, Martijn. On 8/10/10 22:22, Lyndon Maydwell wrote: Hi Cafe. I have written some QuickCheck properties in my source and am using these for testing, however, when I compile my program I get warned about unused imports: Warning: Module `Test.QuickCheck' is imported, but nothing from it is used Is there a way to suppress these warnings for a particular module by using a pragma directive or something similar? Thanks! - Lyndon ___ 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] cabal haddock doesn't work for me on win7
I'm not sure what's going on, here's the error I get: C:\haskell\ListZipper-1.1.1.0>cabal haddock Running Haddock for ListZipper-1.1.1.0... Preprocessing library ListZipper-1.1.1.0... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: Cabal-1.8.0.2, QuickCheck-2.1.0.3, Win32-2.2.0.1, array-0.3.0.0, base-3.0.3.2, base-4.2.0.0, bin-package-db-0.0.0.0, ffi-1.0, rts-1.0, bytestring-0.9.1.5, containers-0.3.0.0, directory-1.0.1.0, extensible-exceptions-0.1.1.1, filepath-1.1.0.3, ghc-6.12.1, ghc-binary-0.5.0.2, ghc-prim-0.2.0.0, hpc-0.5.0.4, integer-gmp-0.2.0.0, mtl-1.1.0.2, old-locale-1.0.0.2, old-time-1.0.0.3, pretty-1.0.1.1, process-1.0.1.2, random-1.0.0.2, syb-0.1.0.2, template-haskell-2.4.0.0, time-1.1.4 Warning: Data.List.Zipper: could not find link destinations for: GHC.Classes.Eq GHC.Show.Show Test.QuickCheck.Arbitrary.Arbitrary Test.QuickCheck.Arbitrary.CoArbitrary GHC.Bool.Bool Data.Maybe.Maybe haddock: internal Haddock or GHC error: E:\Program Files (x86)\Haskell\haddock-2.7.2\html\haddock.css: openFile: does not exist (No such file or directory) Haskell platform is installed on "C:", I have no idea where it's getting the "E:" from. I can specify the correct css location with --css, but then I get the same error looking for haskell_icon.gif. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unused import warnings.
Is there a way to just ignore the warnings for QuickCheck?
On Wed, Aug 11, 2010 at 4:32 AM, Christopher Done
wrote:
> On 10 August 2010 22:25, Lyndon Maydwell wrote:
>> On Wed, Aug 11, 2010 at 4:23 AM, Christopher Done
>> wrote:
>>> On 10 August 2010 22:22, Lyndon Maydwell wrote:
Hi Cafe.
I have written some QuickCheck properties in my source and am using
these for testing, however, when I compile my program I get warned
about unused imports:
> Warning: Module `Test.QuickCheck' is imported, but nothing from it is used
Is there a way to suppress these warnings for a particular module by
using a pragma directive or something similar?
>>>
>>> You can do:
>>>
>>> import Test.QuickCheck ()
>>>
>> I'm using qualified properties with (import Test.QuickCheck ((==>)))
>> so that may not be possible.
>
> Ah, ok. In that case you can use -fno-warn-unused-imports. You can
> pass that to GHC, or put it in as an OPTIONS pragma:
>
> {-# OPTIONS -fno-warn-unused-imports #-}
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCE] (and request for review): directory-tree v0.9.0
On Mon, Aug 9, 2010 at 10:48 PM, Brandon Simmons < brandon.m.simm...@gmail.com> wrote: > Greetings Haskellers! > > directory-tree is a module providing a directory-tree-like datatype > along with Foldable and Traversable instances, along with a simple, > high-level IO interface. You can see the package along with some > examples here (apologies if the haddock docs haven't been generated > yet) : > >http://hackage.haskell.org/package/directory-tree If I understand what you're saying, then your library is very similar to an abstraction that darcs had for years knows as "Slurpy". The experience in the darcs project was that it lead to performance issues and correctness issues that were hard to find/fix. > > > This primary change in this release is the addition of two > experimental "lazy" functions: `readDirectoryWithL` and `buildL`. > These functions use `unsafePerformIO` behind the scenes to traverse > the filesystem as required by pure computations consuming the returned > DirTree data structure. I believe I am doing this safely and sanely > but would love if some more experienced folks could comment on the > code. > unsafePerformIO or unsafeInterleaveIO? Either way, to me it seems a bit dangerous to be doing this sort of lazy IO. If the directory structure is large will I run out of file handles? How will IO errors be handled? Will I receive the exceptions in pure code or inside my IO actions? Will I run into space leaks if something holds on to 1 file and then references it "after" the directory traversal? I might have my history wrong, but as I recall darcs started with lazy slurpies and moved to doing things strictly due to space leaks, running out of file descriptors, file descriptor leaks (not running out, but having the file be locked long after darcs should have been 'done' with it), and exception delivery. It's a seductive path but one that does not seem to have a good ending. I'm not sure what darcs uses these days. Perhaps that's what hashed-storage provides, although I haven't been able to find any documentation on hashed-storage other than the haddocks (which only document the api with no overview or explanation of the problem hashed-storage solves). Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unused import warnings.
On 10 August 2010 22:25, Lyndon Maydwell wrote:
> On Wed, Aug 11, 2010 at 4:23 AM, Christopher Done
> wrote:
>> On 10 August 2010 22:22, Lyndon Maydwell wrote:
>>> Hi Cafe.
>>>
>>> I have written some QuickCheck properties in my source and am using
>>> these for testing, however, when I compile my program I get warned
>>> about unused imports:
>>>
Warning: Module `Test.QuickCheck' is imported, but nothing from it is used
>>>
>>> Is there a way to suppress these warnings for a particular module by
>>> using a pragma directive or something similar?
>>
>> You can do:
>>
>> import Test.QuickCheck ()
>>
> I'm using qualified properties with (import Test.QuickCheck ((==>)))
> so that may not be possible.
Ah, ok. In that case you can use -fno-warn-unused-imports. You can
pass that to GHC, or put it in as an OPTIONS pragma:
{-# OPTIONS -fno-warn-unused-imports #-}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unused import warnings.
I'm using qualified properties with (import Test.QuickCheck ((==>))) so that may not be possible. On Wed, Aug 11, 2010 at 4:23 AM, Christopher Done wrote: > On 10 August 2010 22:22, Lyndon Maydwell wrote: >> Hi Cafe. >> >> I have written some QuickCheck properties in my source and am using >> these for testing, however, when I compile my program I get warned >> about unused imports: >> >>> Warning: Module `Test.QuickCheck' is imported, but nothing from it is used >> >> Is there a way to suppress these warnings for a particular module by >> using a pragma directive or something similar? > > You can do: > > import Test.QuickCheck () > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unused import warnings.
On 10 August 2010 22:22, Lyndon Maydwell wrote: > Hi Cafe. > > I have written some QuickCheck properties in my source and am using > these for testing, however, when I compile my program I get warned > about unused imports: > >> Warning: Module `Test.QuickCheck' is imported, but nothing from it is used > > Is there a way to suppress these warnings for a particular module by > using a pragma directive or something similar? You can do: import Test.QuickCheck () ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Unused import warnings.
Hi Cafe. I have written some QuickCheck properties in my source and am using these for testing, however, when I compile my program I get warned about unused imports: > Warning: Module `Test.QuickCheck' is imported, but nothing from it is used Is there a way to suppress these warnings for a particular module by using a pragma directive or something similar? Thanks! - Lyndon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: zip-archive performance/memmory usage
Thanks for your comments John. I appreciate your work. I think pandoc is fantastic! I'm interested to solve this problem, but time is also an issue. I'll try to toy around with it. Thanks, Pieter On Tue, Aug 10, 2010 at 7:06 PM, John MacFarlane wrote: > Hi all, > > I'm the author of zip-archive. I wrote it for a fairly special purpose -- > I wanted to create and read ODT files in pandoc -- and I know it could be > improved. > > The main problem is that the parsing algorithm is kind of stupid; it just > reads the whole archive in sequence, storing the files as it comes to them. > So a file listing will take almost as much time as a full extract. > > There's a better way: The zip archive ends with an "end of central > directory > record", which contains (among other things) the offset of the central > directory from the beginning of the file. So, one could use something like > the > following strategy: > > 1. read the "end of central directory record", which should be the last 22 > bytes of the file. I think it should be possible to do this without > allocating > memory for the whole file. > > 2. parse that to determine the offset of the central directory. > > 3. seek to the offset of the central directory and parse it. This will give > you a list of file headers. Each file header will tell you the name of a > file > in the archive, how it is compressed, and where to find it (its offset) in > the > file. > > At this point you'd have the list of files, and enough information to seek > to > any file and read it from the archive. The API could be changed to allow > lazy > reading of a single file without reading all of them. > > I don't think these changes would be too difficult, since you wouldn't have > to > change any of the functions that do the binary parsing -- it would just be > a > matter of changing the top-level functions. > > I don't have time to do this right now, but if one of you wants to tackle > the > problem, patches are more than welcome! There's some documentation on the > ZIP > format in comments in the source code. > > John > > > +++ Neil Brown [Aug 10 10 12:35 ]: > > On 10/08/10 00:29, Pieter Laeremans wrote: > > >Hello, > > > > > >I'm trying some haskell scripting. I'm writing a script to print > > >some information > > >from a zip archive. The zip-archive library does look nice but > > >the performance of zip-archive/lazy bytestring > > >doesn't seem to scale. > > > > > >Executing : > > > > > > eRelativePath $ head $ zEntries archive > > > > > >on an archive of around 12 MB with around 20 files yields > > > > > >Stack space overflow: current size 8388608 bytes. > > > > > > > > >The script in question can be found at : > > > > > >http://github.com/plaeremans/HaskellSnipplets/blob/master/ZipList.hs > > > > > >I'm using the latest version of haskell platform. Are these > > >libaries not production ready, > > >or am I doing something terribly wrong ? > > > > I downloaded your program and compiled it (GHC 6.12.1, zip-archive > > 0.1.1.6, bytestring 0.9.1.5). I ran it on the JVM src.zip (20MB, > > ~8000 files) and it sat there for a minute (67s), taking 2.2% memory > > according to top, then completed successfully. Same behaviour with > > -O2. Which compares very badly in time to the instant return when I > > ran unzip -l on the same file, but I didn't see any memory problems. > > Presumably your archive is valid and works with unzip and other > > tools? > > > > Thanks, > > > > Neil. > > > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Pieter Laeremans "The future is here. It's just not evenly distributed yet." W. Gibson ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Couple of questions about *let* within *do*
michael rice wrote:
OK, then there's also an implicit *in* after the *let* in this code. Must the
implicit (or explicit) *in* actually use the calculated value(s)?
And, the monad can "continue on" after the *let* (with or without the *in*) as
below, i.e., the *let* needn't be the last statement in the *do*?
More specifically, there is an implicit "in do". So given some code,
foo = do
something
let x = bar
y = baz
thingsome
somesome
First there's the insertion of braces and semicolons implied by the
layout rules.
foo = do
{ something
; let { x = bar
; y = baz
}; thingsome
; somesome
}
Then we desugar the let-do notation,
foo = do
{ something
; let { x = bar
; y = baz
} in do
{ thingsome
; somesome
}}
Or with prettier typesetting,
foo = do
{ something
; let
{ x = bar
; y = baz
} in do
{ thingsome
; somesome
}
}
and finally we can desugar do notation into (>>=), (>>), and fail.
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell in Industry
Henning Thielemann wrote: about functional programming jobs in investment banking ... Ketil Malde schrieb: Tom Hawkins writes: (Yes, I realize that's were the money is [...]) Exactly. I don't think this is bad: having talented people recruited to work on functional programming will improve the technology for all of us. I'm not sure I follow this opinion in general. Analogously I could say: Supporting military is a good idea, since they invest in new technologies. That's not my opinion. Maybe the next financial crisis leads us into the next world war. But that analogy is a bit disingenuous. If investment bankers care so much about performance (because a few milliseconds delay in transactions can cost a lot) then getting a lot of talented functional programmers in finance means there will be a good deal of work in figuring out how to improve performance. Thus, anyone who wants performance will benefit directly; regardless of attendant outcomes. While the military invests in technology, they invest mainly in technology that advances a particular goal. Thus, it's good for them to have smart people if you would like improvements to that particular kind of technology. (Which includes the Internet and natural language processing ---for very militaristic reasons, both of them---, as well as the obvious.) Investment banking isn't likely to lead to improvements in zygohistomorphic prepromorphisms. If that's where you think we need to be improving our technology, then having smart people in investment banking doesn't help. But that's a different claim than the claim that they'd improve performance or overall acceptance in the job market. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: QuickCheck and Pairing Heaps
> Hi, I'm trying to figure out QuickCheck > and how to generate arbitrary test data form complex data structures; sometimes the following workaround is enough: if you have a function that makes a tree (heap) from a list, then generate an "arbitrary" list, and make the tree from that. of course this might restrict your test set. similarly, if you want to test a property that needs an ordered list (as input), just generate an arbitrary list and use a trusted sort function. oh, and try Smallcheck as well. http://www.cs.york.ac.uk/fp/smallcheck/ Similar idea, but using complete (instead of random) enumeration. Sometimes that's easier to control. Regards, J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Couple of questions about *let* within *do*
So all the Xs would be in scope at s6. Important point. Thanks, Michael --- On Tue, 8/10/10, Alex Stangl wrote: From: Alex Stangl Subject: Re: [Haskell-cafe] Couple of questions about *let* within *do* To: "michael rice" Cc: "Tillmann Rendel" , haskell-cafe@haskell.org Date: Tuesday, August 10, 2010, 2:21 PM On Tue, Aug 10, 2010 at 11:01:28AM -0700, michael rice wrote: > Hi all, > > Then, > > do s1 > s2 > let x1 = e1 > x2 = e2 > s3 > s4 > let x3 = e3 > x4 = e4 > s5 > s6 > > becomes > > do s1 > s2 > let x1 = e1 > x2 = e2 in do s3 > s4 > let x3 = e3 > x4 = e4 in do s5 > s6? do s1 s2 let x1 = e1 x2 = e2 in do s3 s4 let x3 = e3 x4 = e4 in do s5 s6 HTH, Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Couple of questions about *let* within *do*
On Tue, Aug 10, 2010 at 11:01:28AM -0700, michael rice wrote: > Hi all, > > Then, > > do s1 > s2 > let x1 = e1 > x2 = e2 > s3 > s4 > let x3 = e3 > x4 = e4 > s5 > s6 > > becomes > > do s1 > s2 > let x1 = e1 > x2 = e2 in do s3 >s4 > let x3 = e3 > x4 = e4 in do s5 >s6? do s1 s2 let x1 = e1 x2 = e2 in do s3 s4 let x3 = e3 x4 = e4 in do s5 s6 HTH, Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] QuickCheck and Pairing Heaps
Hi, I'm trying to figure out QuickCheck and how to generate arbitrary test
data form complex data structures; I thought an interesting experiment would
be Pairing Heaps.
A pairing heap is essentially just a tree whose nodes obey the heap property
(for all nodes A in a pairing whose nodes can be compared, the value of A is
greater then the value of any descendants of A).
I came with a definition that I think seems reasonable
\begin{code}
data (Ord a) => Heap a = Heap a [Heap a]
\end{code}
But I cannot think of a way to generate arbitrary heaps, I see three main
issues:
1. Based on the examples I have seen, I understand how you could define
arbitrary so that it uses frequency to choose either a leaf or a branch, but
how would you generate a variable number of children?
2. That would hardcode the probably size of the heap, how would you define
an arbitrary heap that was dependent on some sort of size parameter?
3. The way I see it, you could generate arbitrary heaps of type A (where A
is an instance of Arbitrary and Ord), but how would you make sure that each
node of the generated tree was heapy (the max of all its descendants)?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Couple of questions about *let* within *do*
Hi all, Thanks. I think I've got it. It nice to have come far enough with this to be thinking about how the pieces fit together. One more question: Since do s1 s2 let x1 = e1 x2 = e2 s3 s4 becomes do s1 s2 let x1 = e1 x2 = e2 in do s3 s4 Then, do s1 s2 let x1 = e1 x2 = e2 s3 s4 let x3 = e3 x4 = e4 s5 s6 becomes do s1 s2 let x1 = e1 x2 = e2 in do s3 s4 let x3 = e3 x4 = e4 in do s5 s6? Michael --- On Tue, 8/10/10, Tillmann Rendel wrote: From: Tillmann Rendel Subject: Re: [Haskell-cafe] Couple of questions about *let* within *do* To: "michael rice" Cc: haskell-cafe@haskell.org Date: Tuesday, August 10, 2010, 1:35 PM michael rice wrote: > OK, then there's also an implicit *in* after the *let* in this code. If you want to understand let statements in terms of let ... in ... expressions, you can do the following transformation: do s1 s2 let x1 = e1 x2 = e2 s3 s4 becomes do s1 s2 let x1 = e1 x2 = e2 in do s3 s4 So in a sense, there is an implicit "in do". > Must the implicit (or explicit) *in* actually use the calculated value(s)? No. By the way, note that lazy evaluation applies, so the expressions bound in the let may or may not be evaluated, depending on the rest of the program. > And, the monad can "continue on" after the *let* (with or without the *in*) > as below, i.e., the *let* needn't be the last statement in the *do*? Yes, there can be more statements after the let statement. In fact, the let statement must not be the last statement in the do-expression, because a do-expression has to end with an expression statement. Otherwise, what would the result of the do-expression be? Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Couple of questions about *let* within *do*
On Tue, Aug 10, 2010 at 2:40 PM, Bill Atkins wrote:
> They're not really statements, they're just named expressions and are still
> subject to lazy evaluation.
>
> In:
>
> let x = putStrLn "Name" >> getLine
> putStrLn "Welcome"
> x
Yes, 'putStrLn "name" >> getLine' is an expression. However, the
whole line 'let x = putStrLn "Name" >> getLine' inside the
do-block is an statement. Althought the word 'let' is used in
both cases, they are defined in different places of the grammar
(see the links of my previous mail).
So when you write
do ...
let ... -- stmt
...
you are using a let statement. You can use a let expression in a
do-block as well:
do ...
let ...
in ... -- expr
...
Note, however, that you must indent the 'in' part, as you would
need to indent an if expression inside a do-block.
do ...do {...
let ... -- exprgets parsed as ;let ... -- stmt
in ... --;in ... -- ???
... ;...}
Cheers,
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Couple of questions about *let* within *do*
The let's aren't really statements, they're just named expressions and are still subject to lazy evaluation. In: let x = putStrLn "Name" >> getLine putStrLn "Welcome" x The program will print: Welcome Name? and then prompt for input, even though the let comes first. And if you never ran the 'x' action, then the user would just see "Welcome" and the block of code would finish (because lazy evaluation still applies). On Tuesday Aug 10, 2010, at 12:49 PM, Felipe Lessa wrote: > The (let ... in ...) construct is an expression, while the (let ...) > inside 'do' is a statement. The (do ...) itself is an expression. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Couple of questions about *let* within *do*
On Tuesday 10 August 2010 19:12:57, michael rice wrote: > OK, then there's also an implicit *in* after the *let* in this code. Yes. do let x = foo bar baz is desugared to let x = foo in (bar >> baz) > Must the implicit (or explicit) *in* actually use the calculated > value(s)? No, and if the values aren't used, they're not calculated (unless you force the calculation in the bindings, e.g. with bangs). > > And, the monad can "continue on" after the *let* (with or without the > *in*) as below, i.e., the *let* needn't be the last statement in the > *do*? It *mustn't* be the last statement; the last statement in a do-block must be an expression (return blah, putStrLn whatever, ...) > > main = do > gen <- getStdGen > let code = genCode gen > putStrLn $ "Code is " ++ show code > putStrLn "..." > > > Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Couple of questions about *let* within *do*
michael rice wrote: OK, then there's also an implicit *in* after the *let* in this code. If you want to understand let statements in terms of let ... in ... expressions, you can do the following transformation: do s1 s2 let x1 = e1 x2 = e2 s3 s4 becomes do s1 s2 let x1 = e1 x2 = e2 in do s3 s4 So in a sense, there is an implicit "in do". Must the implicit (or explicit) *in* actually use the calculated value(s)? No. By the way, note that lazy evaluation applies, so the expressions bound in the let may or may not be evaluated, depending on the rest of the program. And, the monad can "continue on" after the *let* (with or without the *in*) as below, i.e., the *let* needn't be the last statement in the *do*? Yes, there can be more statements after the let statement. In fact, the let statement must not be the last statement in the do-expression, because a do-expression has to end with an expression statement. Otherwise, what would the result of the do-expression be? Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell in Industry
about functional programming jobs in investment banking ... Ketil Malde schrieb: > Tom Hawkins writes: >> (Yes, I realize that's were the money is [...]) > > Exactly. > > I don't think this is bad: having talented people recruited to work > on functional programming will improve the technology for all of us. I'm not sure I follow this opinion in general. Analogously I could say: Supporting military is a good idea, since they invest in new technologies. That's not my opinion. Maybe the next financial crisis leads us into the next world war. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Couple of questions about *let* within *do*
OK, then there's also an implicit *in* after the *let* in this code. Must the implicit (or explicit) *in* actually use the calculated value(s)? And, the monad can "continue on" after the *let* (with or without the *in*) as below, i.e., the *let* needn't be the last statement in the *do*? main = do gen <- getStdGen let code = genCode gen putStrLn $ "Code is " ++ show code putStrLn "..." Michael --- On Tue, 8/10/10, Job Vranish wrote: From: Job Vranish Subject: Re: [Haskell-cafe] Couple of questions about *let* within *do* To: "michael rice" Cc: haskell-cafe@haskell.org Date: Tuesday, August 10, 2010, 12:52 PM Yes, and yes :) For example: import Data.Char main = do let prompt s = do putStrLn s getLine firstName <- prompt "What's your first name?" lastName <- prompt "What's your last name?" let bigFirstName = map toUpper firstName bigLastName = map toUpper lastName putStrLn $ "hey " ++ bigFirstName ++ " " ++ bigLastName ++ ", how are you?" - Job On Tue, Aug 10, 2010 at 12:40 PM, michael rice wrote: From: Learn You a Haskell === Remember let bindings? If you don't, refresh your memory on them by reading this section. They have to be in the form of let bindings in expression, where bindings are names to be given to expressions and expression is the expression that is to be evaluated that sees them. We also said that in list comprehensions, the in part isn't needed. Well, you can use them in do blocks pretty much like you use them in list comprehensions. Check this out: import Data.Char main = do putStrLn "What's your first name?" firstName <- getLine putStrLn "What's your last name?" lastName <- getLine let bigFirstName = map toUpper firstName bigLastName = map toUpper lastName putStrLn $ "hey " ++ bigFirstName ++ " " ++ bigLastName ++ ", how are you?" === Questions: 1) Is there an implicit *in* before the last line above? 2) Within a do "in" the IO monad (or any other monad), can a *let* do something like this? let x = do -- in a different monad Michael ___ 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: zip-archive performance/memmory usage
Hi all, I'm the author of zip-archive. I wrote it for a fairly special purpose -- I wanted to create and read ODT files in pandoc -- and I know it could be improved. The main problem is that the parsing algorithm is kind of stupid; it just reads the whole archive in sequence, storing the files as it comes to them. So a file listing will take almost as much time as a full extract. There's a better way: The zip archive ends with an "end of central directory record", which contains (among other things) the offset of the central directory from the beginning of the file. So, one could use something like the following strategy: 1. read the "end of central directory record", which should be the last 22 bytes of the file. I think it should be possible to do this without allocating memory for the whole file. 2. parse that to determine the offset of the central directory. 3. seek to the offset of the central directory and parse it. This will give you a list of file headers. Each file header will tell you the name of a file in the archive, how it is compressed, and where to find it (its offset) in the file. At this point you'd have the list of files, and enough information to seek to any file and read it from the archive. The API could be changed to allow lazy reading of a single file without reading all of them. I don't think these changes would be too difficult, since you wouldn't have to change any of the functions that do the binary parsing -- it would just be a matter of changing the top-level functions. I don't have time to do this right now, but if one of you wants to tackle the problem, patches are more than welcome! There's some documentation on the ZIP format in comments in the source code. John +++ Neil Brown [Aug 10 10 12:35 ]: > On 10/08/10 00:29, Pieter Laeremans wrote: > >Hello, > > > >I'm trying some haskell scripting. I'm writing a script to print > >some information > >from a zip archive. The zip-archive library does look nice but > >the performance of zip-archive/lazy bytestring > >doesn't seem to scale. > > > >Executing : > > > > eRelativePath $ head $ zEntries archive > > > >on an archive of around 12 MB with around 20 files yields > > > >Stack space overflow: current size 8388608 bytes. > > > > > >The script in question can be found at : > > > >http://github.com/plaeremans/HaskellSnipplets/blob/master/ZipList.hs > > > >I'm using the latest version of haskell platform. Are these > >libaries not production ready, > >or am I doing something terribly wrong ? > > I downloaded your program and compiled it (GHC 6.12.1, zip-archive > 0.1.1.6, bytestring 0.9.1.5). I ran it on the JVM src.zip (20MB, > ~8000 files) and it sat there for a minute (67s), taking 2.2% memory > according to top, then completed successfully. Same behaviour with > -O2. Which compares very badly in time to the instant return when I > ran unzip -l on the same file, but I didn't see any memory problems. > Presumably your archive is valid and works with unzip and other > tools? > > Thanks, > > Neil. > > ___ > 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] Re: Can we come out of a monad?
Excerpts from Ertugrul Soeylemez's message of Tue Aug 10 03:40:02 -0400 2010: > Then you can only run evalCont, if r = a, which makes that function > quite pointless: > > evalCont :: Cont r r -> r > evalCont = runCont id Ah, yes, that was what I was imagining. I don't think the function is useless (though it is pointless ;-); it lets you transform continuation-style code into normal code. Also, r is usually not fixed (unless you use mapCont or similar), so it might be more accurately described as Cont a a -> a. Cheers, Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Couple of questions about *let* within *do*
Yes, and yes :) For example: import Data.Char main = do let prompt s = do putStrLn s getLine firstName <- prompt "What's your first name?" lastName <- prompt "What's your last name?" let bigFirstName = map toUpper firstName bigLastName = map toUpper lastName putStrLn $ "hey " ++ bigFirstName ++ " " ++ bigLastName ++ ", how are you?" - Job On Tue, Aug 10, 2010 at 12:40 PM, michael rice wrote: > > From: Learn You a Haskell > > === > > Remember let bindings? If you don't, refresh your memory on them by reading > this section. They have to be in the form of let bindings in expression, > where bindings are names to be given to expressions and expression is the > expression that is to be evaluated that sees them. We also said that in list > comprehensions, the in part isn't needed. Well, you can use them in do > blocks pretty much like you use them in list comprehensions. Check this out: > > > import Data.Char > > main = do > putStrLn "What's your first name?" > firstName <- getLine > putStrLn "What's your last name?" > lastName <- getLine > let bigFirstName = map toUpper firstName > bigLastName = map toUpper lastName > putStrLn $ "hey " ++ bigFirstName ++ " " ++ bigLastName ++ ", how are > you?" > > === > > Questions: > > 1) Is there an implicit *in* before the last line above? > > 2) Within a do "in" the IO monad (or any other monad), can a *let* do > something like this? > > let x = do -- in a different monad > > > Michael > > > > ___ > 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] Couple of questions about *let* within *do*
On Tue, Aug 10, 2010 at 1:40 PM, michael rice wrote: > 1) Is there an implicit *in* before the last line above? The (let ... in ...) construct is an expression, while the (let ...) inside 'do' is a statement. The (do ...) itself is an expression. See the report: http://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-440003.12 http://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-470003.14 > 2) Within a do "in" the IO monad (or any other monad), can a *let* do > something like this? > > let x = do -- in a different monad Yes =). For example, > main = do -- IO monad > putStrLn "Hello!" > let x = do i <- [1..5] -- list monad (i.e. []) > j <- [i..5] > return (i*j) > mapM print x -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Couple of questions about *let* within *do*
From: Learn You a Haskell === Remember let bindings? If you don't, refresh your memory on them by reading this section. They have to be in the form of let bindings in expression, where bindings are names to be given to expressions and expression is the expression that is to be evaluated that sees them. We also said that in list comprehensions, the in part isn't needed. Well, you can use them in do blocks pretty much like you use them in list comprehensions. Check this out: import Data.Char main = do putStrLn "What's your first name?" firstName <- getLine putStrLn "What's your last name?" lastName <- getLine let bigFirstName = map toUpper firstName bigLastName = map toUpper lastName putStrLn $ "hey " ++ bigFirstName ++ " " ++ bigLastName ++ ", how are you?" === Questions: 1) Is there an implicit *in* before the last line above? 2) Within a do "in" the IO monad (or any other monad), can a *let* do something like this? let x = do -- in a different monad Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell in Industry
The former. On Tue, Aug 10, 2010 at 2:59 PM, Ivan Lazar Miljenovic wrote: > Lennart Augustsson writes: > >> Rather than high turnover it indicates (in my experience) that it's >> difficult to fill positions in finance. >> That's one reason they are advertised repeatedly. > > Because you can't find people that are good enough (in terms of required > skill sets, etc.) or because no-one wants the job? > > -- > 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: Haskell in Industry
Lennart Augustsson writes: > Rather than high turnover it indicates (in my experience) that it's > difficult to fill positions in finance. > That's one reason they are advertised repeatedly. Because you can't find people that are good enough (in terms of required skill sets, etc.) or because no-one wants the job? -- 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: Haskell in Industry
Rather than high turnover it indicates (in my experience) that it's difficult to fill positions in finance. That's one reason they are advertised repeatedly. On Tue, Aug 10, 2010 at 12:27 PM, Ivan Lazar Miljenovic wrote: > Malcolm Wallace writes: > It's disproportionate. 95% of the job offerings in functional programming are with investment firms. >> >> I'm not sure that is really true. You might see more adverts for >> financial jobs, but often those jobs may be advertised multiple times, >> because different headhunters see an opportunity to earn a slice of >> the pie. By contrast, non-financial FP jobs are likely to be >> advertised only once, or not at all, because candidates are easily >> found. > > It could also indicate high turn-over for investment firm > jobs... (i.e. people get sick of it). > > -- > 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 > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] zip-archive performance/memmory usage
On 10/08/10 00:29, Pieter Laeremans wrote: Hello, I'm trying some haskell scripting. I'm writing a script to print some information from a zip archive. The zip-archive library does look nice but the performance of zip-archive/lazy bytestring doesn't seem to scale. Executing : eRelativePath $ head $ zEntries archive on an archive of around 12 MB with around 20 files yields Stack space overflow: current size 8388608 bytes. The script in question can be found at : http://github.com/plaeremans/HaskellSnipplets/blob/master/ZipList.hs I'm using the latest version of haskell platform. Are these libaries not production ready, or am I doing something terribly wrong ? I downloaded your program and compiled it (GHC 6.12.1, zip-archive 0.1.1.6, bytestring 0.9.1.5). I ran it on the JVM src.zip (20MB, ~8000 files) and it sat there for a minute (67s), taking 2.2% memory according to top, then completed successfully. Same behaviour with -O2. Which compares very badly in time to the instant return when I ran unzip -l on the same file, but I didn't see any memory problems. Presumably your archive is valid and works with unzip and other tools? Thanks, Neil. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] zip-archive performance/memmory usage
I was interested to see if I could determine what was happening with this. After some playing around, I noticed the code was running significantly faster if I *didn't* compile it, but ran it with 'runghc' instead (running under ghci was also fast). Here are the running times I found. The 'Zip.hs' program comes with the zip-archive package. The runtime of the compiled version didn't seem to be affected by optimisations. Regardless, I'm quite surprised running interpreted was significantly faster than compiled. > time runghc ./Zip.hs -l ~/jdk1.6.0_05-src.zip 1.48s user 0.17s system 97% cpu 1.680 total > time ./dist/build/Zip/Zip -l ~/jdk1.6.0_05-src.zip 89.00s user 1.06s system 98% cpu 1:31.84 total The file 'jdk1.6.0_05-src.zip' was just an 18MB zip file I had lying around. I'm using ghc 6.12.1 Cheers, -- David Powell On Tue, Aug 10, 2010 at 12:10 PM, Jason Dagit wrote: > > > On Mon, Aug 9, 2010 at 4:29 PM, Pieter Laeremans wrote: > >> Hello, >> >> I'm trying some haskell scripting. I'm writing a script to print some >> information >> from a zip archive. The zip-archive library does look nice but the >> performance of zip-archive/lazy bytestring >> doesn't seem to scale. >> >> Executing : >> >>eRelativePath $ head $ zEntries archive >> >> on an archive of around 12 MB with around 20 files yields >> >> Stack space overflow: current size 8388608 bytes. >> > > So it's a stack overflow at about 8 megs. I don't have a strong sense of > what is normal, but that seems like a small stack to me. Oh, actually I > just check and that is the default stack size :) > > I looked at Zip.hs (included as an example). The closest I see to your > example is some code for listing the files in the archive. Perhaps you > should try the supplied program on your archive and see if it too has a > stack overflow. > > The line the author uses to list files is: > List-> mapM_ putStrLn $ filesInArchive archive > > But, you're taking the head of the entries, so I don't see how you'd be > holding on to too much data. I just don't see anything wrong with your > program. Did you remember to compile with optimizations? Perhaps try the > author's way of listing entries and see if performance changes? > > >> >> The script in question can be found at : >> >> http://github.com/plaeremans/HaskellSnipplets/blob/master/ZipList.hs >> >> I'm using the latest version of haskell platform. Are these libaries not >> production ready, >> or am I doing something terribly wrong ? >> > > Not production ready would be my assumption. I think an iteratee style > might be more appropriate for these sorts of nested streams of potentially > large size anyway. I'm skeptical of anything that depends on lazy > bytestrings or lazy io. In this case, the performance would appear to be > depend on lazy bytestrings. > > You might want to experiment with increasing the stack size. Something > like this: > ./ZipList +RTS -K100M -RTS foo.zip > > Jason > > ___ > 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] Re: Haskell in Industry
Malcolm Wallace writes: >>> It's disproportionate. 95% of the job offerings in functional >>> programming are with investment firms. > > I'm not sure that is really true. You might see more adverts for > financial jobs, but often those jobs may be advertised multiple times, > because different headhunters see an opportunity to earn a slice of > the pie. By contrast, non-financial FP jobs are likely to be > advertised only once, or not at all, because candidates are easily > found. It could also indicate high turn-over for investment firm jobs... (i.e. people get sick of it). -- 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] iPhone/Android and Haskell [Was: Embedded funcional programming?]
On 08/08/10 03:08, Mathew de Detrich wrote: > Well the other issue is of course that Android being available on a wide > variety of phones, not all of which run ARM (the phone I am about to get for > example has a custom built CPU), although I guess one could use a "generic" > ASM branch for "mobile" devices (if one exists). btw the phone I am about to > receive is a Samsung Galaxy-S, which has a hummingbird chip (no idea what > Assembler Instruction set it uses, I believe its a closed chip) This should be S5PC110 if I google correctly which is "just" yet another ARM Cortex A8: http://www.samsung.com/global/business/semiconductor/newsView.do?news_id=1043 Karel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell in Industry
It's disproportionate. 95% of the job offerings in functional programming are with investment firms. I'm not sure that is really true. You might see more adverts for financial jobs, but often those jobs may be advertised multiple times, because different headhunters see an opportunity to earn a slice of the pie. By contrast, non-financial FP jobs are likely to be advertised only once, or not at all, because candidates are easily found. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
On 08/08/10 01:44, Don Stewart wrote: > > Only problem is rewriting the GHC runtime in Java... :-) > Perhaps I don't understand the problem domain correctly, but IMHO this project was already once done in LambdaVM: http://wiki.brianweb.net/LambdaVM/LambdaVM. Karel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can we come out of a monad?
On Tue, Aug 10, 2010 at 6:48 AM, Edward Z. Yang wrote: > Excerpts from Luke Palmer's message of Tue Aug 10 01:04:04 -0400 2010: >> Except, of course, you want the signature >> >> evalCont :: Cont r a -> a >> >> Which is not possible. But I am not sure where all this discussion is >> coming from, Maybe and (r ->) cannot be broken out of. Isn't that >> example enough? > > I'm confused... that's the type of evalCont, no? Except that I messed up and "evalCont" doesn't compile. The type would have to be evalCont :: Cont a a -> a ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Is there any experience using Software Transactional Memory in substantial applications?
| Recently we discussed Haskell and especially types in Russian part of | LiveJournal and of course we talk about STM. | | My opponent gave me that link: | http://logicaloptimizer.blogspot.com/2010/06/so-microsofts-experiments-with- | software.html | | It says that performance with STM in Microsoft Research was more than | horrible. I can't resist replying to this. Several things to say: * STM requires runtime logging of every memory read and write. In an imperative language (such as C#), in which the very fabric of computation involves reads and writes, STM is bound to be expensive. [Lots of work has been done to omit redundant logging based on program analysis, but it's still expensive.] In contrast, in a pure functional language there are no reads and writes, so all the pure part has zero overhead. Only when you do 'readTVar' and 'writeTVar' do you pay the overhead; these are a tiny fraction of all memory accesses. So we get a huge win from the fact that Haskell's computational fabric is pure. * When do you need readTVar/writeTVar? Answer, precisely when you are manipulating state shared between threads. If you do a *lot* of this, your program is *bound* to perform badly; data has to be shuffled between processors, caches have to do their thing, etc. The key to high performance in parallel applications is to minimise sharing. If you do that, then you'll (dynamically) have few readTVar/writeTVars, and so regardless of how expensive they are it'll run fast. There are occasional data structures that are (a) necessarily shared and (b) necessarily hot-spots. Then STM is perhaps not the best solution, which is why GHC provides a range of primitives: as well as STM we've kept MVars, and we also have atomicModifyIORef which is even cheaper. Horses for courses. * The GHC STM implementation is simple. It's a direct implementation of our paper "Composable Memory Transactions". We could make strong simplifying assumptions. In contrast, the Microsoft .NET project had to tackle a much more challenging set of requirements. In particular, they thought that programmers would *require* to be able to manipulate the same locations both *inside* and *outside* a transaction. It turns out that this simple requirement dramatically complicates the implementation [see multiple papers by Tim Harris on this topic]. Also they wanted nested transactions, and a raft of other complications. Each of these features was strongly motivated, and the MS guys in Redmond are extremely smart, but the result was necessarily complex and, as it turned out, unacceptably slow. Summary: it's simplistic to say "STM good" or "STM bad". For STM to work well you need - very limited side effects in the computational fabric - limited communication between threads - a simple design Then STM can work extremely well. And it does in Haskell. But it's not a silver bullet; concurrency is too complex to be slain with one bullet. Indeed those precise words appear in every talk about STM I have given (eg http://research.microsoft.com/en-us/um/people/simonpj/papers/stm) Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell in Industry
Tom Hawkins writes: >> Second, I would like to know what exactly is bad about a Haskell >> job in investment banking as a lot of good programmers work in this >> industry. > It's disproportionate. 95% of the job offerings in functional > programming are with investment firms. I believe investment banking > is important, but does it really need to dominate a large percentage > of the world's top tier programmers? I suspect it is because it is an industry where software performance matters. Doing things just a bit better than your competitors can make all the difference (and a big difference) to the bottom line. Thus it is an industry that is willing to invest in new technology. Most other industry seems to be conservative; nobody got fired for choosing IBM, nobody gets criticized for choosing Java. Being good enough is usually sufficient, you don't have to be best, or even better. > Is computing the risk of derivative contracts more important than > pursuing sustainable energy, new drug discovery, improving crop > yields, etc. More important? - I don't know. More willing to invest in software quality - apparently. > (Yes, I realize that's were the money is [...]) Exactly. I don't think this is bad: having talented people recruited to work on functional programming will improve the technology for all of us. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Can we come out of a monad?
"Edward Z. Yang" wrote: > Excerpts from Ertugrul Soeylemez's message of Tue Aug 10 02:31:14 -0400 2010: > > There is no evalCont, there is runCont: > > > > runCont :: (a -> r) -> Cont r a -> r > > > > Note that Cont/ContT computations result in a value of type 'r': > > > > newtype Cont r a = Cont ((a -> r) -> r) > > Yes, but if you pass in 'id' as the continuation to 'runCont', the > entire expression will result in 'a'. The continuation monad doesn't > act globally... Then you can only run evalCont, if r = a, which makes that function quite pointless: evalCont :: Cont r r -> r evalCont = runCont id 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
