- Haskell - Haskell.org

Actual GHC memory usage for versions of 'any'
by Eric Shade 23 Jan '01

23 Jan '01

My questions about 'any' and 'all' really had more to do with pedagogy than anything else, but now that I got GHC figured out, I ran some tests using their profiler. I used version 4.08 on FreeBSD 4.2 and did not enable optimization. I called the function 'atLeastOne' instead of 'any' just to make sure I didn't confuse myself. Prelude Version --------------- GHC's default 'any' and 'or' differ from the Prelude specification, so I wrote the equivalent versions by hand. > default (Int) > main = print (atLeastOne (> 1000000) [0..999999]) > atLeastOne :: (a -> Bool) -> [a] -> Bool > atLeastOne p = foldr (||) False . map p Here are the results: Tue Jan 23 16:01 2001 Time and Allocation Profiling Report (Final) foo +RTS -p -RTS total time = 1.16 secs (58 ticks @ 20 ms) total alloc = 88,001,188 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc atLeastOne Main 63.8 54.5 main Main 36.2 45.5 SYSTEM MAIN 17.2 0.1 Total allocation due to atLeastOne: 0.545 * 88001188 = 47,960,647 bytes Recursive Version ----------------- I wrote 'atLeastOne' by hand so that it wouldn't use GHC's builtin version, which has rewrite rules that may allow better optimization. > default (Int) > main = print (atLeastOne (> 1000000) [0..999999]) > atLeastOne :: (a -> Bool) -> [a] -> Bool > atLeastOne _ [] = False > atLeastOne p (x:xs) = p x || atLeastOne p xs Here are the results: Tue Jan 23 16:01 2001 Time and Allocation Profiling Report (Final) bar +RTS -p -RTS total time = 0.76 secs (38 ticks @ 20 ms) total alloc = 64,001,096 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc atLeastOne Main 71.1 37.5 SYSTEM MAIN 39.5 0.2 main Main 28.9 62.5 Total allocation due to atLeastOne: 0.375 * 64001096 = 24,000,411 bytes Summary ------- I realize that this is not a perfect test, but it does say something. To those who read my previous post, when I said that 'any' takes linear space, I meant in the worst case. And as Tom Pledger pointed out to me privately via email, all of that space immediately becomes garbage, so it may not be fair to count it against the space requirements of the program. However, it does take time to reclaim it. Thanks to all who replied. -- Dr. Eric Shade, Associate Professor Computer Science Department (CSAB Accredited) Southwest Missouri State University

1 0

Specifications of 'any', 'all', 'findIndices'
by Eric Shade 23 Jan '01

23 Jan '01

I have some questions about the specifications of 'any', 'all', and 'findIndices' in the Haskell 98 reports. The specifications of 'any' and 'all' are any p = or . map p all p = and . map p While this is correct, it seems to me that it generates a lot of garbage because map will produce a list of Booleans until 'any' sees a True or 'all' sees a False. 'elem' and 'notElem' inherit the problem because they're defined in terms of 'any' and 'all'. I realize that this is only a specification, but Hugs at least uses this as its implementation. It seems clearer and more efficient to me to use the following definitions: any p [] = False any p (x:xs) = p x || any p xs all p [] = True all p (x:xs) = p x && all p xs leave 'elem' and 'notElem' as is, then define and = notElem False or = elem True There is a similar problem with findIndices, whose specification is findIndices p xs = [i | (x,i) <- zip xs [0..], p x] While this is admittedly cool, it also seems to generate a lot of garbage by producing pairs only to throw them away. I'm not yet up to speed on the implementation of lazy functional languages, so it may be that in all of these cases the compiler can easily optimize away the garbage. If so, it would be nice to see some documentation for non-wizards that explains what kinds of optimizations one can reasonably expect (like tail-recursion elimination in Scheme). Even if the apparent inefficiencies melt away, I think that my versions of 'any', 'all', 'and', and 'or' are clearer as specification than the current ones. -- Dr. Eric Shade, Associate Professor Computer Science Department (CSAB Accredited) Southwest Missouri State University

7 9

Accpeting command-line arguments in GHC/Hugs
by Shlomi Fish 23 Jan '01

23 Jan '01

How can I read the command-line arguments passed to the program. For instance, if I run my compiled program by typing "./foo hello -o file.txt", I wish to access the list ["hello", "-o", "file.txt"] somehow. TIA, Shlomi Fish ---------------------------------------------------------------------- Shlomi Fish shlomif(a)vipe.technion.ac.il Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: shlomif(a)techie.com The prefix "God Said" has the extraordinary logical property of converting any statement that follows it into a true one.

3 2

RE: Combinator library gets software prize
by Conal Elliott 23 Jan '01

23 Jan '01

> From: C.Reinke [mailto:C.Reinke@ukc.ac.uk] > Am I the only one who finds the exclusive emphasis on combinator > languages slightly disappointing [...]? > [...] > The paper somewhat downplays the role of embedding the > combinator-based DSL in a full functional language while also > mentioning that some features gained for free in the Haskell > prototype considerably complicate implementations in other > languages. I would be interested to hear more about these aspects: > [...] Another important consideration is whether the combinator library is higher-order. If so, it will be awkward to use from a language without a lightweight notation for (first-class) functions. This lack was a huge drawback in DirectAnimation, the now-defunct product cousin of Fran, which eviscerated the crucially higher-order event algebra. Similarly, when a combinator lib uses parametric polymorphism, it is painful to use from a language without. (Same example.) It seems that these features just weren't important in the case of "Composing Contracts". - Conal

1 0

Doing IO in foldr repeats lines?
by Ian Lynagh 23 Jan '01

23 Jan '01

Hi all The following code: > module Main (main) where > import IO > main :: IO() > main = do _ <- foldl foo (return 14) ["qq\n", "ww\n", "ee\n"] > putStr "" > foo :: IO Int -> String -> IO Int > foo io_l s = do l <- io_l > () <- putStr s > io_l prints (with both GHC and hugs): qq ww qq ee qq ww qq and I really don't understand why. Is the code re-evaluated every time foldl is expanded or something? Thanks Ian, confused

3 3

ѡ��ѻ��Լ��װ�λ�...
by Onwall.net 23 Jan '01

23 Jan '01

春节快要到了! 你是否准备把爱家装饰一新呢？是否正为送亲朋好友什么礼物发愁呢？快来我们的网站定制合适自己或你朋友的装饰画、电影海报啦！选画、裱画、自己定制装饰画... http://www.onwall.net E-mail:Server@onwall.net QQ装裱支持:28888808 抱歉在未征得您同意的情况下发送本邮件但愿我们的网站真能为你提供服务! 使用极星邮件群发，无须通过邮件服务器，直达对方邮箱，速度绝对一流！下载网址：http://love2net.51.net/，更多免费的超酷软件等你来下…… ---------------------------------------------------- INFORMATION This message has been sent using a trial-run version of the TSmtpRelayServer Delphi Component. ----------------------------------------------------

1 0

Re: Combinator library gets software prize
by C.Reinke 22 Jan '01

22 Jan '01

> > This article is very good, and having read the conference paper earlier > > in the year I finished it with only one question: What's a 'quant' ... > > and is it good or bad to be one? > > > > "Ten years ago, Jean-Marc Eber, then a quant at Société > > Générale, ..." > > The OED has: .. > So perhaps he was tall, thin and fond of wearing a cap? > > :-) You might want to try http://www.dictionary.com/cgi-bin/dict.pl?term=quant An expert in the use of mathematics and related subjects, particularly in investment management and stock trading. ... http://www.investorwords.com/q1.htm#quant One who performs quantitative analyses. Or more generally, a securities analyst. Am I the only one who finds the exclusive emphasis on combinator languages slightly disappointing (in fact, the article seems to equate functional language with domain-specific combinator languages, which is more than a bit mistleading)? This is a Haskell forum, not one on Backus' FP, so readers are well aware of the advantages of functional abstraction. Domain-specific languages, if embedded in Haskell, tend to inherit these advantages, even if the language in question was designed as a pure combinator language. The consequence (and the intention, as far as one can gather from the paper) of the limitation to combinators is that this language can and will be used mainly in non-functional languages, not inheriting all that much from a functional style of programming. The same will probably hold for any communication standards based on it. This appplication is undoubtely a success and a good step forward, but there is more to functional languages. The paper somewhat downplays the role of embedding the combinator-based DSL in a full functional language while also mentioning that some features gained for free in the Haskell prototype considerably complicate implementations in other languages. I would be interested to hear more about these aspects: - Is the strictly combinator-based approach a pragmatic necessity ("one step at a time") or is there no need for more advanced features (especially abstraction) in the application area? - Has there been a comparison of the way the combinators of the DSL are used in Haskell and in other implementations? I would think that the use of abstraction to define more complex instruments in terms of the basic combinators should play a rather dominant role. On the other hand, I can imagine that users would want to have each complex instrument explicitly named and studied, instead of trusting large amounts of money to anonymous abstractions created on-the-fly. - What about interactive exploration of new instruments, e.g., in a Hugs or OCaml session (as opposed to changing a C++ implementation, or a stand-alone executable generated by an OCaml compiler, for every experiment)? Claus

2 1

fixity for (\\)
by Koen Claessen 22 Jan '01

22 Jan '01

Hi all, The Haskell report defines the fixity of (\\) to be: infix 5 \\ I propose that it gets the following fixity: infixl 5 \\ This means that one can write: as \\ bs \\ cs \\ ds Which means: (((as \\ bs) \\ cs) \\ ds) I think that one less often means the following: as \\ (bs \\ (cs \\ ds)) /Koen. -- Koen Claessen http://www.cs.chalmers.se/~koen phone:+46-31-772 5424 mailto:koen@cs.chalmers.se ----------------------------------------------------- Chalmers University of Technology, Gothenburg, Sweden

3 2

RE: Combinator library gets software prize
by David Bakin 22 Jan '01

22 Jan '01

This article is very good, and having read the conference paper earlier in the year I finished it with only one question: What's a 'quant' ... and is it good or bad to be one? "Ten years ago, Jean-Marc Eber, then a quant at Société Générale, ..." -- Dave -----Original Message----- From: Simon Peyton-Jones Sent: Saturday, January 20, 2001 5:10 AM To: haskell(a)haskell.org Subject: Combinator library gets software prize You might enjoy this article, in Risk Magazine, a journal of the financial engineering industry. Combinators in the real world! http://www.risk.net/riskawards2001/softwareproduct.htm <http://www.risk.net/riskawards2001/softwareproduct.htm> Simon _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell <http://www.haskell.org/mailman/listinfo/haskell>

2 1

RE: Combinator library gets software prize
by Ashley Yakeley 21 Jan '01

21 Jan '01

At 2001-01-21 10:57, David Bakin wrote: >What's a 'quant' ... >and is it good or bad to be one? I think that depends on exactly how much of a quant you are. -- Ashley Yakeley, Seattle WA

1 0