- Haskell - Haskell.org

RE: fixity for (\\)
by Simon Peyton-Jones 26 Jan '01

26 Jan '01

This proposal makes sense to me, but I'm only supposed to be fixing serious bugs in the Haskell 98 definition, not making unforced changes. So even though this change would be non-invasive and break no programs I'm reluctant to adopt it. Adding those extra parens is no big deal. Unless there's a lot of support, I propose to make no change (in H98, that is). Simon | -----Original Message----- | From: Koen Claessen [mailto:koen@cs.chalmers.se] | Sent: 17 January 2001 15:32 | To: The Haskell Mailing List | Subject: fixity for (\\) | | | 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 | | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell |

1 0

RE: Question about 'Tackling the Awkward Squad'
by Simon Peyton-Jones 26 Jan '01

26 Jan '01

Don Crumbs! You're right! The MVars that are drawn as heavy black boxes in Figure 7 of Tackling the Awkward Squad are used to block the consumer when it catches up with the producer. But if there is more than one consumer, it's not OK to leave these MVars empty. Instead, getChan should do a put after its take; or, more elegantly, should use readMVar, which has the semantics of take-followed-by-put: getchan (read, write) = do { head_var <- takeMVar read ; MkItem val new_head <- readMVar head_var ; putMVar read new_head ; return val } Concurrent programming is tricky. I owe you a beer! I'll fix the version on the Web Simon | when I ran across what appears to be an error. On page 34, while | discussing Channels, he proposes a function called dupChan: | | dupChan (read, write) | = do { new_read <- newEmptyMVar ; | hole <- takeMVar write ; | putMVar write hole ; | putMVar new_read hole ; | return (new_read, write) } | | The rationale is given thusly: | | "For example, consider a multi-cast channel, in which there are | multiple readers, each of which should see all the values written to | the channel ... The idea is that the channel returned by dupChan can | be read independently of the original, and sees all (and only) the | data written to the channel after the dupChan call." | | But earlier he has defined getChan thusly: | | getchan (read, write) | = do { head_var <- takeMVar read ; | MkItem val new_head <- takeMVar head_var ; | putMVar read new_head ; | return val } | | Since the line which performs the 'takeMVar head_var' leaves the MVar | referenced by head_var empty, the dupChan 'new_read' Stream | should block | when the reader tries to *also* use getChan on this Stream, isn't this | so? Am I missing some subtlety? I drew all the pictures :^)~ | | -- | Don Wakefield Mentor Graphics Corporation | (503) 685-1262 8005 S.W. Boeckman Road | don_wakefield(a)mentorg.com Wilsonville, OR 97070-7777 | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell |

1 0

Question about 'Tackling the Awkward Squad'
by Don Wakefield 25 Jan '01

25 Jan '01

I posed the following question on comp.lang.functional, and a helpful reader emailed me to suggest that I should ask it here. Briefly, I dabble in Haskell to exercise my mind in a way that my C++ heritage doesn't, so if I'm asking silly questions or missing seemingly obvious notions, I beg forgiveness. The Question. I was reading Simon Peyton Jones' fascinating paper: Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell (the January 9th 2001 draft) when I ran across what appears to be an error. On page 34, while discussing Channels, he proposes a function called dupChan: dupChan (read, write) = do { new_read <- newEmptyMVar ; hole <- takeMVar write ; putMVar write hole ; putMVar new_read hole ; return (new_read, write) } The rationale is given thusly: "For example, consider a multi-cast channel, in which there are multiple readers, each of which should see all the values written to the channel ... The idea is that the channel returned by dupChan can be read independently of the original, and sees all (and only) the data written to the channel after the dupChan call." But earlier he has defined getChan thusly: getchan (read, write) = do { head_var <- takeMVar read ; MkItem val new_head <- takeMVar head_var ; putMVar read new_head ; return val } Since the line which performs the 'takeMVar head_var' leaves the MVar referenced by head_var empty, the dupChan 'new_read' Stream should block when the reader tries to *also* use getChan on this Stream, isn't this so? Am I missing some subtlety? I drew all the pictures :^)~ -- Don Wakefield Mentor Graphics Corporation (503) 685-1262 8005 S.W. Boeckman Road don_wakefield(a)mentorg.com Wilsonville, OR 97070-7777

1 0

'any' and 'all' compared with the rest of the Report
by Eric Shade 24 Jan '01

24 Jan '01

I didn't mean to get into a discussion about 'specification vs. implementation' or 'clarity vs. conciseness', although those are important distinctions. In my original post I didn't do a good job of putting my objections in the proper context, so let me take one more whack at it and then I'll leave it alone. As a newcomer to Haskell, I read the entire Report, including all of the purely functional code in the Prelude and Libraries (I glossed over the monadic stuff initially). The code is not only clear as a *specification*, but also seems perfectly suitable as a default *implementation*. All the code seemed to have the time and space requirements that one would expect. Then I get to 'any' and 'all', whose specification requires linear time and *linear* space when it should run in constant space. (By the way, I checked and GHC does *not* use the Prelude definitions but rather the obvious recursive ones, and most of its optimizations based on "good consumers/producers" use meta-linguistic rewrite rules. So without knowing the specific optimizations that a compiler provides, I think it's safe to assume that the Prelude 'any' and 'all' *will* require linear space.) This is jarring; all the other code is clear *and* efficient, but 'any' and 'all' are not. I start to question whether I really understand the language after all. (Do 'or' and 'map' work differently than I thought? Did I misunderstand laziness? ...) After all, why would the authors (who presumably know more about the language than anyone on the planet) intentionally provide inefficient code in *this* case when they provided efficient code for all the *other* functions? This is why I don't think that the specifications are good; they're OK in isolation but not in the context of the rest of the Report. For me (and apparently for others), these specifications didn't enhance my understanding; they led me to question it. I know that the Report clearly says that these are just specifications, but that's one short paragraph. When I read 20 pages of code that appears to be reasonably efficient as well, I assume that that's by design and not accident. It would be one thing if the Report were littered with functions whose specifications were obviously not intended as implementations. But 'any', 'all', and 'findIndices' were the only inefficient ones I noticed out of the entire Report. And it's obvious that clarity is not the only goal in the specifications. For example, why bother to write a messy O(log n) version of x^n when the following is more clear *and* more concise? x ^ n | n >= 0 = product (replicate n x) _ ^ _ = error "Prelude.^: negative exponent" Since the specifications of 'any' and 'all' are part of the Report, they are part of the documentation for the language. They should be judged by how well they help people understand the language. The direct recursive versions, though slightly less concise, are equally clear and will not cause any confusion. That's why I prefer them. -- Dr. Eric Shade, Associate Professor Computer Science Department (CSAB Accredited) Southwest Missouri State University

5 4

Re: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
by Malcolm Wallace 24 Jan '01

24 Jan '01

> Here is what is currently supported: > {-# LINE 100 "Foo.hs #-} | # 100 "Foo.hs" I recently discovered that some of the GHC toolset actually generates and recognises {-# LINE 100 "Foo.hs -} which is somewhere in between a comment and a pragma. Has this been fixed yet? > I would choose LINE pragma. In this case nhc98 should be taught > about it. The 1.00 release of nhc98 (incorrectly) rejects almost all pragmas. The 1.01 (CVS) version correctly accepts (but ignores) almost all pragmas. In time, it will learn to use the information from a small number of pragmas. When that happens, LINE can certainly be one of them. Regards, Malcolm

4 4

FLOPS 2001 - 2nd Call for Participation
by Herbert Kuchen 24 Jan '01

24 Jan '01

********************************************************************* * SECOND CALL FOR PARTICIPATION * * * * FLOPS 2001 * * Fifth International Symposium on Functional and Logic Programming * * * * Waseda University, Tokyo, Japan * * March 7-9, 2001 * * * * http://www.ueda.info.waseda.ac.jp/flops2001/ * ********************************************************************* The symposium is a forum for research on all issues concerning functional programming and logic programming. In particular, it aims to stimulate the cross-fertilization as well as integration of the two paradigms. This is the fifth in the series of FLOPS symposia held every 1.5 years in Japan. The symposium program will consist of 3 invited talks and 21 technical research talks. The proceedings will be published by Springer-Verlag in the Lecture Notes in Computer Science series. Invited Talks ============= Gopalan Nadathur (Univ. of Minnesota, USA) "The Metalanguage lambda-Prolog and Its Implementation" George C. Necula (Univ. of California, Berkeley, USA) "A Scalable Architecture for Proof-Carrying Code" Taisuke Sato (Tokyo Institute of Technology, Japan) "Parameterized Logic Programs where Computing Meets Learning" Important Dates =============== Early Registration Deadline: January 30, 2001 Symposium: March 7-9, 2001 Venue ===== The symposium will be held at the Conference Room 1 (third floor) of the International Conference Center of Waseda University, which is located in central Tokyo and can be accessed easily. For details, please visit the FLOPS2001 Web page http://www.ueda.info.waseda.ac.jp/flops2001/ . Registration and Hotel Information ================================== Details of registration and hotel booking information are available on the FLOPS2001 Web page. Registration fees are as follows: Before Jan. 30 After Jan. 31 Regular 22,000 yen 32,000 yen Student 12,000 yen 22,000 yen The fees include participation, proceedings, banquet and refreshments for one person. Additional banquet tickets are available. The current exchange rate for Japanese yen is US$1 = 116 yen and 1 Euro = 109 yen. Detailed information on accommodations near the conference site, ranging from luxuary to inexpensive, is available on the FLOPS Web page. Preliminary Programme ===================== Wednesday, March 7 09:00 - 09:30 Registration 09:30 - 09:45 Opening 09:45 - 11:00 Invited Talk 1 The Metalanguage lambda-Prolog and Its Implementation Gopalan Nadathur 11:00 - 11:30 Break 11:30 - 12:30 Lambda-Calculus A Simply Typed Context Calculus with First-Class Environments Masahiko Sato, Takafumi Sakurai, and Yukiyoshi Kameyama Refining the Barendregt Cube using Parameters Fairouz Kamareddine, Twan Laan, and Rob Nederpelt 12:30 - 14:00 Lunch 14:00 - 15:30 Functional Logic Programmig 1 A Framework for Goal-Directed Bottom-Up Evaluation of Functional Logic Programs Jesus M. Almendros-Jimenez and Antonio Becerra-Teron Theoretical Foundations for the Declarative Debugging of Lazy Functional Logic Programs Rafael Caballero, Francisco J. Lopez-Fraguas, and Mario Rodriguez-Artalejo Adding Linear Constrains over Real Numbers to Curry Wolfgang Lux 15:30 - 16:00 Break 16:00 - 17:30 Logic Programming A Higher-Order Logic Programming Language with Constraints Javier Leach and Susana Nieva Specifying and Debugging Security Protocols via Hereditary Harrop Formulas and lambdaProlog --- A Case-study Giorgio Delzanno An Effective Bottom-Up Semantics for First-Order Linear Logic Programs Marco Bozzano, Giorgio Delzanno, and Maurizio Martelli Thursday, March 8 09:30 - 10:30 Program Analysis and Transformation 1 A Framework for Analysis of Typed Logic Programs Vitaly Lagoon and Peter J. Stuckey Abstract Compilation for Sharing Analysis Gianluca Amato and Fausto Spoto 10:30 - 11:00 Break 11:00 - 12:15 Invited Talk 2 Parameterized Logic Programs where Computing Meets Learning Taisuke Sato 12:15 - 13:45 Lunch 13:45 - 15:15 Functional Logic Programming 2 A Complete Selection Function for Lazy Conditional Narrowing Taro Suzuki and Aart Middeldorp An Abstract Machine Based System for a Lazy Narrowing Calculus Teresa Hortala-Gonzalez and Eva Ullan Incremental Learning of Functional Logic Programs Cesar Ferri-Ramirez, Jose Hernandez-Orallo, and Maria Jose Ramirez-Quintana 15:15 - 15:45 Break 15:45 - 17:15 Functional Programming Proving Syntactic Properties of Exceptions in an Ordered Logical Framework Jeff Polakow and Kwangkeun Yi A Higher-Order Colon Translation Olivier Danvy and Lasse R. Nielsen Compiling Lazy Functional Programs Based on the Spineless Tagless G-machine for the Java Virtual Machine Kwanghoon Choi, Hyun-il Lim, and Taisook Han 18:45 - 21:00 Banquet at Rihga Royal Hotel Friday, March 9 09:30 - 10:30 Program Analysis and Transformation 2 A Practical Partial Evaluator for a Multi-Paradigm Declarative Language Elvira Albert, Michael Hanus, and German Vidal A Simple Take on Typed Abstract Syntax in ML-like Languages Olivier Danvy and Morten Rhiger 10:30 - 11:00 Break 11:00 - 12:15 Invited Talk 3 A Scalable Architecture for Proof-Carrying Code George C. Necula 12:15 - 13:45 Lunch 13:45 - 15:15 Types A General Type Inference Framework for Hindley/Milner Style Systems Martin Sulzmann Monadic Encapsulation with Stack of Regions Koji Kagawa Well-Typed Logic Programs Are not Wrong Pierre Deransart and Jan-Georg Smaus 15:15 - 15:30 Closing Symposium Organization ====================== Program Co-Chairs: Herbert Kuchen Univ. of Muenster, Germany Kazunori Ueda Waseda Univ., Tokyo, Japan Program Committee: Sergio Antoy Portland State Univ., USA Gopal Gupta New Mexico State Univ., USA Michael Hanus Univ. of Kiel, Germany Fergus Henderson Univ. of Melbourne, Australia Zhenjiang Hu Univ. of Tokyo, Japan Herbert Kuchen Univ. of Muenster, Germany Giorgio Levi Univ. of Pisa, Italy Michael Maher Griffith Univ., Brisbane, Australia Dale Miller Pennsylvania State Univ., USA I.V. Ramakrishnan State Univ. of New York at Stony Brook, USA Olivier Ridoux IRISA, France Mario Rodriguez-Artalejo Complutense Univ., Madrid, Spain Colin Runciman Univ. of York, UK Akihiko Takano Hitachi Ltd., Japan Peter Thiemann Freiburg Univ., Germany Yoshihito Toyama Tohoku Univ., Japan Kazunori Ueda Waseda Univ., Tokyo, Japan Local Arrangements Chair: Zhenjiang Hu Univ. of Tokyo, Japan Sponsors ======== FLOPS2001 is sponsored by Japan Society of Software Science and Technology (JSSST), Special Interest Group on Principles of Programming, and held in cooperation with Association for Logic Programming.

1 0

optimization in the report's prelude, again
by Timmy Douglas 23 Jan '01

23 Jan '01

well, I'm a newbie and I was looking through the prelude to try to learn some more haskell and I came across the sample definition of the (^) operator on page 98. i saw a post for optimization, but and it got mostly negative replies so i'll go the other way. if we are writing for clarity and not efficency as it says, then would it be better to write it as something like n ^ e | n >= 0 = product $ take (e+1) (1 : repeat n) _ ^ _ = error "negative exponent" well, i could care less, but i have nothing better to do so i thought i'd just ask if this was ok technique or something. or maybe someone can tell me if there is like an order of "clearest ways"... for example, using pattern matching if convenient first, then using standard functions, then list comp., then guards, etc. because i sometimes think that filter might be clearer as: filter' f list = [ item | item <- list, f item] rather than using guards... oh well, enough ranting. thanks for replies.

1 0

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