January 2001 - Haskell

RE: Question about 'Tackling the Awkward Squad'
by Steinitz, Dominic J 29 Jan '01

29 Jan '01

This is probably superfluous now but I still don't understand Hugs' behaviour. I ran the following with ghc 4.08.1: module Main(main) where import Concurrent main = do chan <- newChan writeChan chan "One" dup <- dupChan chan writeChan chan "Two" x <- readChan dup y <- readChan chan z <- readChan chan putStrLn (x++y++z) I expected the answer "TwoOneTwo" but instead got $ ./main d:\dom\hugs98\concurrent\main.exe: no threads to run: infinite loop or deadlock? which confirmed the problem that Don highlighted. With Hugs I got the following: Main> main (232 reductions, 458 cells) which was puzzling. I'm running Version: May 1999 with -98. Dominic. simonpj(a)microsoft.com on 28/01/2001 11:18:00 To: don_wakefield haskell cc: bcc: Dominic Steinitz Subject: RE: Question about 'Tackling the Awkward Squad' 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 | _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

Re: Combinator library gets software prize
by Ronald Legere 27 Jan '01

27 Jan '01

--- "C.Reinke" <C.Reinke(a)ukc.ac.uk> wrote: >Even within combinator languages, I am not always > sure whether those > reporting on the paper are aware how much the DSL > gains by being > embedded in a full functional language, and how > simply exporting the > core DSL to another context would severe all those > useful connections. > Heh, this is something that I ran into when trying to write a combinator language for Java based on Haskore. I gave up when I realized i really needed those other features of a functinal language to :). It is a bit difficult in many domains to seperate what you are defining from the language you are defining it in, so I guess this is not such a large suprise. __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/

1 0

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

26 Jan '01

[oops, somehow this ended up in my drafts folder, not on the list; sorry for the delay] First, to avoid confusion: I'm not criticising the work described. I'm just pointing out that, in my view, the major advantages of functional programming lie beyond what is used in this application (in other words, there is yet more to be gained, and we should not underestimate the role of the facilities imported from the functional host language, such as functional abstraction). [one quibble: I don't like the idea of using floating point numbers to represent real money without further comments. Even after avoiding representation error surprises by using base10 instead of binary floating points, aren't there precise standards for rounding in the financial market? Or have I missed an explanation of this in the paper?] > > 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)? > > What declarative approach(es) (other than combinators) are you > referring to here? Mostly lambda-calculus; more generally, all approaches that deal explicitly with variables and variable binding, and the resulting languages, which are general enough that DSLs for many domains can be embedded in them. Even within combinator languages, I am not always sure whether those reporting on the paper are aware how much the DSL gains by being embedded in a full functional language, and how simply exporting the core DSL to another context would severe all those useful connections. In the present context, most of the excitement seems to focus on the contract combinators, because they bring a new approach towards order in the application domain. They can be viewed as a first-order functional language on contracts. This core part of the DSL could be used in other modern languages as well, provided their expression sub-language is sufficiently expressive (although the syntax, e.g., new And(..) and new Give(..) in Java, or <Give>..</Give> in other contexts, would quite likely annoy the user). But the paper goes beyond that, e.g., it defines and uses some higher-order features for observables. Also, functional programmers will be tempted to use partially applied contract combinators in higher-order compositions (as a simple example, take "all = foldr and zero :: [Contract] -> Contract" -- acquiring "all contracts" acquires a list of contracts). Such uses are already slightly more difficult (and typically much more ugly) in non-functional languages, so simply providing the same basic DSL as a library embedded in a non-functional language will not necessarily give the same flexibility (and a dedicated implementation of the DSL would have to decide between supporting only simple uses of the combinators or adding some more advanced features). Of course, in addition to combinators, we also need definitions, so that we can give names to useful combinations of combinators. This comes for free if the DSL is embedded in Haskell, but if we take it out of this context, we need to start thinking about what kind of definitions we can or want to support: parameters? certainly. what types of parameters? what types of things can be defined? how are parameters passed?.. And suddenly, we're into the definition and implementation of a little (higher-order?) functional language, with support for functional abstraction (how much support?). Does the host language (or the dedicated implementation) support all the things we want in the way we expect? In any case, the core contract combinator DSL doesn't stand in isolation - we need to work with the contracts, operate on dates, evaluate options, iterate through sequences or alternatives, .. Do we do this in functional style, or by shouting imperatives at those poor contract combinations? > > 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. > > Why is that? I'm new to the functional programming world, and haven't > reallystruck the concept of combinator libraries elsewhere. I assumed > they were largely a functional programming concept. Even though I can > see how they could be implemented in imperative languages, it doesn't > seem that they would be a nice fit. That's my point. But so far, I don't see any external commitment to a functional host language for the core combinators. Of course, that impression could well be wrong.. The paper suggests the Haskell implementation as a prototype to help the development of an existing C++ implementation as well as a new implementation in OCaml (implementation language, not host language). Most positive external comments seem to focus on the core contract combinators as a possible means to standardize the way professionals and software are talking about contracts (XML-like). Now, if you cut out the contract combinators from the DSL embedded in Haskell and try to find something that can be used across C++,OCaml,XML-processing Java, etc., you might end up writing for-loops, assigning contract combinations to global variables, sending messages to contract objects, and all the other funny non-functional things that are so happily used outside the Haskell world. > > [Several interesting elided] > > More generally, is there any more information or forums on declarative > approaches to financial engineering? I found this paper intriguing, as > it focuses on both my current academic interests, and my work! I'm not an expert in this area, but from the few references in the paper, it seems that there hasn't been much work, and from the comments on the paper, it seems there there is a growing interest. Perhaps there are enough people interested now to warrant setting up such a forum. Claus

1 0

RE: Yet more on functional dependencies
by Simon Peyton-Jones 26 Jan '01

26 Jan '01

| | I am finding functional dependencies confusing. (I suspect I am | | not alone.) Should the following code work? | | | | class HasConverter a b | a -> b where | | convert :: a -> b | | | | instance (HasConverter a b,Show b) => Show a where | | show value = show (convert value) | | It's a separate issue. There's no reason why a system using | functional dependencies *should* support this. But it is an | attractive and useful extension that such a system would | probably *want* to include. (i.e., it's a desirable feature, | not a requirement.) There are two things going on here a) The 'head' of the instance declaration is just "Show a", so this purports to give an instance declaration for all types "a". So it overlaps with other instance declarations, and GHC currently rejects it for that reason. (Arguably, if you accept overlapping instance declarations, then this should be acceptable too.) b) There's a "b" in the instance declaration context that doesn't appear in the head. This is quite OK, because the functional dependency ensures that "a" uniquely determines "b". So here's a variant that works in the (as-yet-unreleased) GHC 5.0: data Foo a = MkFoo a instance (HasConverter a b,Show b) => Show (Foo a) where show (MkFoo value) = show (convert value) [Incidentally, functional dependencies don't work at all in GHC 4.08; don't even try.] Simon

1 0

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 25 Jan '01

25 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