From chaddai.fouche at gmail.com Tue Apr 1 00:06:45 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Tue Apr 1 00:02:53 2008 Subject: [Haskell-cafe] [Newbie] Problem with Data.Map (or something else ?) In-Reply-To: <1464be950803310851j7658f795qfe69a827c671bebd@mail.gmail.com> References: <1464be950803310851j7658f795qfe69a827c671bebd@mail.gmail.com> Message-ID: 2008/3/31, Bruno Carnazzi : > Dears Haskellers, > > As an Haskell newbie, I'm learning Haskell by trying to resolve Euler > Project problems (http://projecteuler.net/ ). I'm hanging on problem > 14 (Collatz problem). > > I've written the following program... Which does not end in a reasonable time :( > My algorithm seems ok to me but I see that memory consumption is gigantic... > Is this a memory problem with Data.Map ? Or an infinite loop ? (Where ?) > In a more general way, how can I troubleshoot these kind of problem ? Others have pointed potential source of memory leaks, but I must say that using Data.Map for the cache in the first place appear to me as a very bad idea... Data.Map by nature take much more place than necessary. You have an integer index, why not use an array instead ? > import Data.Array > import Data.List > import Data.Ord > > syrs n = a > where a = listArray (1,n) $ 0:[ syr n x | x <- [2..n]] > syr n x = if x' <= n then a ! x' else 1 + syr n x' > where x' = if even x then x `div` 2 else 3 * x + 1 > > main = print $ maximumBy (comparing snd) $ assocs $ syrs 1000000 This solution takes 2 seconds (on my machine) to resolve the problem. On the other hand, now that I have read your solution, I see that using Map was the least of the problem... All those Map.map, while retaining the original Map... Your solution is too clever (twisted) for its own good, I suggest you aim for simplicity next time. -- Jeda? From dons at galois.com Tue Apr 1 00:45:40 2008 From: dons at galois.com (Don Stewart) Date: Tue Apr 1 00:41:44 2008 Subject: [Haskell-cafe] [Newbie] Problem with Data.Map (or something else ?) In-Reply-To: References: <1464be950803310851j7658f795qfe69a827c671bebd@mail.gmail.com> Message-ID: <20080401044540.GA3764@scytale.galois.com> chaddai.fouche: > 2008/3/31, Bruno Carnazzi : > > Dears Haskellers, > > > > As an Haskell newbie, I'm learning Haskell by trying to resolve Euler > > Project problems (http://projecteuler.net/ ). I'm hanging on problem > > 14 (Collatz problem). > > > > I've written the following program... Which does not end in a reasonable time :( > > My algorithm seems ok to me but I see that memory consumption is gigantic... > > Is this a memory problem with Data.Map ? Or an infinite loop ? (Where ?) > > In a more general way, how can I troubleshoot these kind of problem ? > > Others have pointed potential source of memory leaks, but I must say > that using Data.Map for the cache in the first place appear to me as a > very bad idea... Data.Map by nature take much more place than > necessary. You have an integer index, why not use an array instead ? > > > import Data.Array > > import Data.List > > import Data.Ord > > > > syrs n = a > > where a = listArray (1,n) $ 0:[ syr n x | x <- [2..n]] > > syr n x = if x' <= n then a ! x' else 1 + syr n x' > > where x' = if even x then x `div` 2 else 3 * x + 1 > > > > main = print $ maximumBy (comparing snd) $ assocs $ syrs 1000000 > > This solution takes 2 seconds (on my machine) to resolve the problem. > > On the other hand, now that I have read your solution, I see that > using Map was the least of the problem... All those Map.map, while > retaining the original Map... Your solution is too clever (twisted) > for its own good, I suggest you aim for simplicity next time. > and if its got Int indices, Data.IntMap is always a better option than Data.Map and usually outperforms the HashTable type, while being pure. From simonpj at microsoft.com Tue Apr 1 06:18:25 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Apr 1 06:14:39 2008 Subject: [Haskell-cafe] FW: Haskell Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> Dear Haskell Cafe members Here's an open-ended question about Haskell vs Scheme. Don't forget to cc Douglas in your replies; he may not be on this list (yet)! Simon -----Original Message----- From: D. Gregor [mailto:kerrangster@gmail.com] Sent: 30 March 2008 07:58 To: Simon Peyton-Jones Subject: Haskell Hello, In your most humble opinion, what's the difference between Haskell and Scheme? What does Haskell achieve that Scheme does not? Is the choice less to do with the language, and more to do with the compiler? Haskell is a pure functional programming language; whereas Scheme is a functional language, does the word "pure" set Haskell that much apart from Scheme? I enjoy Haskell. I enjoy reading your papers on parallelism using Haskell. How can one answer the question--why choose Haskell over Scheme? Regards, Douglas From jeremy.odonoghue at gmail.com Tue Apr 1 06:35:20 2008 From: jeremy.odonoghue at gmail.com (Jeremy O'Donoghue) Date: Tue Apr 1 06:31:22 2008 Subject: [Haskell-cafe] ANN: wxHaskell 0.10.3 Message-ID: <1207046120.21995.1245402907@webmail.messagingengine.com> The wxHaskell development team is pleased to announce the release of wxHaskell 0.10.3, a Haskell binding for the wxWidgets GUI library. The Haskell support is built on a reasonably complete C language binding, which could be used as the basis for wxWidgets support on other languages/platforms which do not have easy mechanisms for linking with C++ code. The feature set is the same as wxHaskell 0.10.3 rc1 and rc2, with a number of additional bugfixes. This is the first full release since June 2005, and is the result of a great deal of work by a new team of contributors. Highlights of 0.10.3 include: - Support for Unicode builds of wxWidgets - Support for additional widgets including calendar, toolbar divider, styled text control (wxScintilla), media control - Support for clipboard, drag and drop - Support for 64bit (Linux) targets - Support for wxWidgets 2.6.x (support for wxWidgets 2.4.2 if you compile from source). wxWidgets 2.8 is not yet supported - Support for building with GHC 6.6.x and 6.8.x - Parts of wxHaskell are now built with Cabal - New test cases - Removed support GHC version < 6.4 - Profiling support - Smaller generated binary sizes (using --split-objs) Binary packages are available from the wxHaskell download site at http://sourceforge.net/project/showfiles.php?group_id=73133, for the following platforms: - Debian - Windows - OS X (Intel and PPC platforms) - Source code .tar.gz and .zip - Documentation (cross-platform) The wxHaskell libraries (wxcore and wx) are also available from Hackage (http://hackage.haskell.org). About wxHaskell --------------- wxHaskell is a Haskell binding to the wxWidgets GUI library for recent versions of the Glasgow Haskell Compiler. It provides a native look and feel on Windows, OS X and Linux, and a medium level programming interface. The main project page for wxHaskell is at http://wxhaskell.sourceforge.net. The latest source code for wxHaskell can always be obtained from http://darcs.haskell.org/wxhaskell. There are developer (wxhaskell-devel@lists.sourceforge.net and user (wxhaskell-users@lists.sourceforge.net) mailing lists, and a wiki page at http://haskell.org/haskellwiki/WxHaskell which can provide more information to those interested. wxHaskell was originally created by Daan Leijen. The contributors to this new release include: - Eric Kow - shelarcy - Arie Middelkoop - Mads Lindstroem - Jeremy O'Donoghue - Lennart Augustson The C language binding for wxHaskell was derived from an original C language binding created for the Eiffel programming language by the ELJ project (http://elj.sourceforge.net). -- Jeremy O'Donoghue jeremy.odonoghue@gmail.com From prstanley at ntlworld.com Tue Apr 1 06:40:35 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Tue Apr 1 06:36:25 2008 Subject: [Haskell-cafe] Function Precedence Message-ID: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> Hi If f x = x and g y = y then f g x returns an error because f takes only one argument. Why can't we have function application implemented outwardly (inside-out). So f g x would be applied with gx first followed by its return value passed to f instead of putting g x in brackets. Cheers, Paul From voigt at tcs.inf.tu-dresden.de Tue Apr 1 06:48:20 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Tue Apr 1 06:44:22 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> Message-ID: <47F212F4.4010206@tcs.inf.tu-dresden.de> PR Stanley wrote: > Hi > If > f x = x > and > g y = y > then > f g x > returns an error because f takes only one argument. Why can't we have > function application implemented outwardly (inside-out). Why should it be so? > So > f g x would be applied with > gx first followed by its return value passed to f instead of putting g x > in brackets. You can get the same behavior with f . g $ x if you mislike brackets. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From nornagon at gmail.com Tue Apr 1 06:50:57 2008 From: nornagon at gmail.com (Jeremy Apthorp) Date: Tue Apr 1 06:46:58 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> Message-ID: <14d615330804010350x46c549b9r668c79c997902a7c@mail.gmail.com> On 01/04/2008, PR Stanley wrote: > Hi > If > f x = x > and > g y = y > then > f g x > returns an error because f takes only one argument. Why can't we have > function application implemented outwardly (inside-out). So > f g x would be applied with > gx first followed by its return value passed to f instead of putting > g x in brackets. Think about this: map (+1) [1..10] What should it do? How about: f 1 2 3 Should that be f (1 (2 3)), or ((f 1) 2) 3? Jeremy From bulat.ziganshin at gmail.com Tue Apr 1 07:02:54 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Apr 1 07:00:46 2008 Subject: [Haskell-cafe] FW: Haskell In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <804685025.20080401150254@gmail.com> Hello Simon, Tuesday, April 1, 2008, 2:18:25 PM, you wrote: > How can one answer the question--why choose Haskell over Scheme? 1. static typing with type inference - imho, must-be for production code development. as many haskellers said, once compiler accept your program, you may be 95% sure that it contains no bugs. just try it! 2. lazy evaluation - reduces complexity of language. in particular, all control structures are usual functions while in scheme they are macros 3. great, terse syntax. actually, the best syntax among several dozens of languages i know 4. type classes machinery, together with type inference, means that code for dealing with complex data types (say, serialization) is generated on the fly and compiled right down to machine code -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jules at jellybean.co.uk Tue Apr 1 07:06:46 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Tue Apr 1 07:02:44 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> Message-ID: <47F21746.9020508@jellybean.co.uk> PR Stanley wrote: > Why can't we have > function application implemented outwardly (inside-out). No reason we can't. We could. We just don't. People have spent some time thinking and experimenting and have decided this way round is more convenient. It's certainly possible to disagree. Jules From jerzy.karczmarczuk at info.unicaen.fr Tue Apr 1 07:35:18 2008 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Tue Apr 1 07:31:18 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> Message-ID: Paul Stanley writes: > Hi > If > f x = x > and > g y = y > then > f g x > returns an error because f takes only one argument. Why can't we have > function application implemented outwardly (inside-out).... etc. Paul, There were already some answers, but it seems that people did not react to the statement that f g x fails. It doesn't, in normal order everything should go smoothly, f g 5 returns 5 = (f g) 5 = g 5, unless I am terribly mistaken... Where did you see an error? Jerzy Karczmarczuk From nominolo at googlemail.com Tue Apr 1 08:02:11 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Apr 1 07:58:22 2008 Subject: [Haskell-cafe] FW: Haskell In-Reply-To: <804685025.20080401150254@gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> <804685025.20080401150254@gmail.com> Message-ID: <11FDE5A2-4D5D-44D8-8B84-3B1B3B320AED@googlemail.com> On 1 apr 2008, at 13.02, Bulat Ziganshin wrote: > Hello Simon, > > Tuesday, April 1, 2008, 2:18:25 PM, you wrote: > >> How can one answer the question--why choose Haskell over Scheme? > > 1. static typing with type inference - imho, must-be for production > code development. as many haskellers said, once compiler accept your > program, you may be 95% sure that it contains no bugs. just try it! > > 2. lazy evaluation - reduces complexity of language. in particular, > all control structures are usual functions while in scheme they are > macros > > 3. great, terse syntax. actually, the best syntax among several > dozens of languages i know > > 4. type classes machinery, together with type inference, means that > code for dealing with complex data types (say, serialization) is > generated on the fly and compiled right down to machine code 3 and 4 are no convincing arguments for a Scheme programmer. Syntax is subjective and there Scheme implementations that can serialize entire continuations (closures), which is not possible in Haskell (at least not without GHC-API). Static typing, though it might sound constraining at first, can be liberating! How that? Because it allows you to let the type-checker work for you! By choosing the right types for your API, you can enforce invariants. For example you can let the type-checker ensure that inputs from a web-application are always quoted properly, before using them as output. A whole class of security problems is taken care of forever, because the compiler checks them for you. If you're used to REPL-based programming, it can be a bit annoying that you can't run non-type-checking code, but you get used to it. After a while you will miss the safety when you program in Scheme again. There's more, but I count on others to step in here. From toman144 at student.liu.se Tue Apr 1 08:03:27 2008 From: toman144 at student.liu.se (Tomas Andersson) Date: Tue Apr 1 07:59:40 2008 Subject: [Haskell-cafe] FW: Haskell In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <200804011403.28229.toman144@student.liu.se> On Tuesday 01 April 2008 12.18.25 Simon Peyton-Jones wrote: > How can one answer the question--why choose Haskell over Scheme? > > Regards, > > Douglas > For me, who is still a Haskell newbie, the following are the main reasons why I fell in love with Haskell and prefer it over Scheme/Common Lisp today. 1) Pattern matching Being able to type for example: fact 0 = 1 fact n = n * (fact (n - 1)) instead of having to write the conditionals and if/case statements every time I write a function is amazing. It makes simple funtctions _much_ shorter, easier to understand and faster to write 2) Static typing Having static typing eliminates tons of bugs at compile time that wouldn't show up until runtime in a dynamic language and does it while giving very clear error messages. And most of the time I don't even have to do anything to get it. The compiler figures it out all by is self. 3) Prettier syntax Yes, S-expressions are conceptually amazing. Code is data is code, macros, backquotes and so on. But I've found that most of the code I write doesn't need any of that fancy stuff and is both shorter and clearer in Haskell 4) List comprehension I fell in love with in in Python and Haskells version is even more beautiful/powerful. Being able to write in one line expression that would normally require multiple 'map's and 'filters' is something I'll have a hard time living without now. Later I've found even more reasons to prefer Haskell over Scheme, for example monads, classes, speed, parallellism, laziness, arrows and Parsec but the list above are the first things that caught my eye and made me switch. /Tomas Andersson From loup.vaillant at gmail.com Tue Apr 1 08:05:34 2008 From: loup.vaillant at gmail.com (Loup Vaillant) Date: Tue Apr 1 08:01:35 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: <47F21746.9020508@jellybean.co.uk> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <47F21746.9020508@jellybean.co.uk> Message-ID: <6f9f8f4a0804010505t1cfa08fer5bb770b3587e74f8@mail.gmail.com> 2008/4/1, Jules Bean : > PR Stanley wrote: > > Why can't we have > > function application implemented outwardly (inside-out). > > No reason we can't. > > We could. > > We just don't. > > People have spent some time thinking and experimenting and have decided > this way round is more convenient. It's certainly possible to disagree. I bet this "time and thinking" involved currying. For instance, with: f :: int -> int -> int f a b = a + b + 3 Let's explore the two possibilities (1) f 4 2 <=> (f 4) 2 -- don't need parentheses (2) f 4 2 <=> f (4 2) -- do need parentheses: (f 4) 2 Curried functions are pervasive, so (1) just saves us more brakets than (2) does. > > f g x > > returns an error because f takes only one argument. Do not forget that *every* function take only one argument. The trick is that the result may also be a function. Therefore, f g 5 <=> id id 5 <=> (id id) 5 <=> id 5 <=> 5 indeed do run smoothly (just checked in the Ocaml toplevel, thanks to Jerzy for pointing this out). Loup From loup.vaillant at gmail.com Tue Apr 1 09:19:40 2008 From: loup.vaillant at gmail.com (Loup Vaillant) Date: Tue Apr 1 09:15:42 2008 Subject: [Haskell-cafe] FW: Haskell In-Reply-To: <804685025.20080401150254@gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> <804685025.20080401150254@gmail.com> Message-ID: <6f9f8f4a0804010619h5da8fc27kf1992d779920c95@mail.gmail.com> 2008/4/1, Bulat Ziganshin : > Hello Simon, > > > Tuesday, April 1, 2008, 2:18:25 PM, you wrote: > > > How can one answer the question--why choose Haskell over Scheme? > > > 1. static typing with type inference - imho, must-be for production > code development. as many haskellers said, once compiler accept your > program, you may be 95% sure that it contains no bugs. just try it! > > 2. lazy evaluation - reduces complexity of language. in particular, > all control structures are usual functions while in scheme they are > macros > > 3. great, terse syntax. actually, the best syntax among several > dozens of languages i know > > 4. type classes machinery, together with type inference, means that > code for dealing with complex data types (say, serialization) is > generated on the fly and compiled right down to machine code In my opinion, (1) and (3), as they are stated, are a bit dangerous if you want to convince a lisper: they represent two long standing religious wars. About (3), I see a trade-off: a rich syntax is great as long as we don't need macros. Thanks to lazy evaluation and monads, we rarely need macros in Haskell, even when writing DSLs. Sometimes, however, we do need macros (remember the arrow notation, whose need was at some time unforeseen). I think the only way we could compare the two is to make a s-expression syntax for Haskell, add macros to it (either hygienic, or with some kind of gensym), and (re)write some programs in both syntaxes. I bet it would be very difficult (if not impossible) to eliminate the trade-off. About (1), In most (if not all) dynamic vs static debate, the dynamic camp argues that the safety brought by a static type system comes at the price of lost flexibility. If we compare duck-typing and Hindley-Milner, they are right: heterogeneous collections are at best clumsy in Hindley-Milner, and overloading is near impossible. Thanks to some geniuses (could someone name them?), we have type classes and higher order types in Haskell (and even more). These two features eliminate most (if not all) need for a dynamic type system. About (4), I think type classes shines even more on simple and mundane stuff. No more clumsy "+" for ints and "+." for floats. No more passing around the "compare" fucntion. No more "should I return a Maybe type or throw an exception?" (monads can delay this question). No more . For more impressive stuff, I think quick-check is a great example. About (2), I'm clueless. The consequences of lazy evaluation are so far-reaching I wouldn't dare entering the "Lazy vs Strict" debate. Loup From voigt at tcs.inf.tu-dresden.de Tue Apr 1 09:28:58 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Tue Apr 1 09:25:00 2008 Subject: [Haskell-cafe] FW: Haskell In-Reply-To: <6f9f8f4a0804010619h5da8fc27kf1992d779920c95@mail.gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> <804685025.20080401150254@gmail.com> <6f9f8f4a0804010619h5da8fc27kf1992d779920c95@mail.gmail.com> Message-ID: <47F2389A.4060903@tcs.inf.tu-dresden.de> Loup Vaillant wrote: > Thanks to some geniuses (could someone name them?), we have type > classes and higher order types in Haskell (and even more). As far as names go: ... for type classes, of course Wadler, but also Blott and Kaes. ... for higher order types, well, where to start? -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From haberg at math.su.se Tue Apr 1 10:08:43 2008 From: haberg at math.su.se (Hans Aberg) Date: Tue Apr 1 10:04:49 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> Message-ID: <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> On 1 Apr 2008, at 12:40, PR Stanley wrote: > Why can't we have function application implemented outwardly > (inside-out). So > f g x would be applied with > gx first followed by its return value passed to f instead of > putting g x in brackets. It seems me it may come from an alteration of math conventions: Normally (x) = x, and function application is written as f(x), except for a few traditional names, like for example sin x. So if one reasons that f(x) can be simplified to f x, then f g x becomes short for f(g)(x) = (f(g))(x). It is just a convention. In math, particularly in algebra, one sometimes writes "f of x" as x f or (x)f, so that one does not have to reverse the order for example in diagrams. Hans Aberg From bagdanov at gmail.com Tue Apr 1 10:42:50 2008 From: bagdanov at gmail.com (Andrew Bagdanov) Date: Tue Apr 1 10:38:50 2008 Subject: [Haskell-cafe] FW: Haskell In-Reply-To: <804685025.20080401150254@gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> <804685025.20080401150254@gmail.com> Message-ID: <6d996c210804010742m53eaa55as6fb70e4326c1ff02@mail.gmail.com> On Tue, Apr 1, 2008 at 1:02 PM, Bulat Ziganshin wrote: > Hello Simon, > > > Tuesday, April 1, 2008, 2:18:25 PM, you wrote: > > > How can one answer the question--why choose Haskell over Scheme? > Well as a longtime Scheme and OCaml programmer, and Haskell-cafe lurker, I'll take a stab at this... > 1. static typing with type inference - imho, must-be for production > code development. as many haskellers said, once compiler accept your > program, you may be 95% sure that it contains no bugs. just try it! > I think this is the biggest, and most obvious, difference to consider when choosing either Scheme or Haskell over the other -- for a particular problem. Dynamic and static typing each have their advantages, depending on the context. I think it's dangerous to try to answer the question "Scheme or Haskell?" without a problem context. > 2. lazy evaluation - reduces complexity of language. in particular, > all control structures are usual functions while in scheme they are > macros > Well, if I don't have side effects (and don't mind extra, unneeded evaluations), I can write my conditionals as functions in Scheme too. Heck, now that I think of it I can even avoid those extra evaluations and side-effect woes if i require promises for each branch of the conditional. No macros required... I think some problems are just more naturally modeled with lazy thinking, and a language with implicit support for lazy evaluation is a _huge_ win then. I written plenty of lazy Scheme, and OCaml for that matter, code where I wished and wished that it just supported lazy evaluation semantics by default. Again, I think this is highly problem dependent, though I think you win more with lazy evaluation in the long run. Do more experienced Haskellers than me have the opposite experience? I mean, do you ever find yourself forcing strict evaluation so frequently that you just wish you could switch on strict evaluation as a default for a while? > 3. great, terse syntax. actually, the best syntax among several > dozens of languages i know > I think this is possibly the weakest reason to choose Haskell over Scheme. Lispers like the regularity of the syntax of S-expressions, the fact that there is just one syntactic form to learn, understand, teach, and use. For myself, I find them to be exactly the right balance between terseness and expressiveness. For me, Haskell syntax can be a bit impenetrable at times unless I squint (and remember I'm also an OCaml programmer). Once you "get it," though, I agree that the brevity and expressiveness of Haskell is really beautiful. > 4. type classes machinery, together with type inference, means that > code for dealing with complex data types (say, serialization) is > generated on the fly and compiled right down to machine code > This is obviously related to #1, and Haskell sure does provide a lot of fancy, useful machinery for manipulating types -- machinery whose functionality is tedious at best to mimic in Scheme, when even possible. In short, I think the orginal question must be asked in context. For some problems, types are just a natural way to start thinking about them. For others dynamic typing, with _judicious_ use of macros to model key aspects, is the most natural approach. For the problems that straddle the fence, I usually pick the language I am most familiar with (Scheme) if there are any time constraints on solving it, and the language I'm least familiar with (Haskell, right now) if I have some breathing room and can afford to learn something in the process. Cheers, -Andy > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From loup.vaillant at gmail.com Tue Apr 1 10:55:53 2008 From: loup.vaillant at gmail.com (Loup Vaillant) Date: Tue Apr 1 10:51:55 2008 Subject: [Haskell-cafe] FW: Haskell In-Reply-To: <6d996c210804010742m53eaa55as6fb70e4326c1ff02@mail.gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> <804685025.20080401150254@gmail.com> <6d996c210804010742m53eaa55as6fb70e4326c1ff02@mail.gmail.com> Message-ID: <6f9f8f4a0804010755r1946db37h5ae188741cadd1e8@mail.gmail.com> 2008/4/1, Andrew Bagdanov : > > In short, I think the orginal question must be asked in context. For > some problems, types are just a natural way to start thinking about > them. For others dynamic typing, with _judicious_ use of macros to > model key aspects, is the most natural approach. Do you have any example? I mean, you had to choose between Scheme and Ocaml, sometimes, right? Ocaml is not Haskell, but maybe the reasons which influenced your choices would have been similar if you knew Haskell instead of Ocaml. Cheers, Loup From gale at sefer.org Tue Apr 1 11:12:44 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Apr 1 11:08:45 2008 Subject: [Haskell-cafe] Unescaping with HaXmL (or anything else!) In-Reply-To: <47EC494B.2040105@appsolutions.com> References: <47EC494B.2040105@appsolutions.com> Message-ID: <2608b8a80804010812s4c34e18boc7e7f2fb6d8896f1@mail.gmail.com> On Fri, Mar 28, 2008 at 4:26 AM, Anton van Straaten wrote: > I want to unescape an encoded XML or HTML string, e.g. converting " > to the quote character, etc. > Since I'm using HaXml anyway, I tried using xmlUnEscapeContent with no > luck Hi Anton, I only noticed your post today, sorry for the delay. I also need this. In fact, it seems to me that it would be generally useful. I hope that simple functions to escape/unescape a string will be added to the API. In the meantime, you are right that it is a bit tricky to do this in HaXml. Besides the wrappers that you found to be needed, there are two other issues: One issue is that you need to lex and then parse the text first. If you tell HaXml that your string is a CString, it will believe you and just use the text the way it is without any further processing. The other issue is that HaXml's lexer currently can only deal with XML content that begins with an XML tag. (I've pointed this out to Malcolm Wallace, the author of HaXml.) So in order to use it, you need to wrap your content in a tag and then unwrap it after parsing. The code below works for me (obviously it would be better to remove the "error" calls): Regards, Yitz import Text.XML.HaXml import Text.XML.HaXml.Parse (xmlParseWith, document) import Text.XML.HaXml.Lex (xmlLex) unEscapeXML :: String -> String unEscapeXML = concatMap ctext . xmlUnEscapeContent stdXmlEscaper . unwrapTag . either error id . fst . xmlParseWith document . xmlLex "oops, lexer failed" . wrapWithTag "t" where ctext (CString _ txt _) = txt ctext (CRef (RefEntity name) _) = '&' : name ++ ";" -- skipped by escaper ctext (CRef (RefChar num) _) = '&' : '#' : show num ++ ";" -- ditto ctext _ = error "oops, can't unescape non-cdata" wrapWithTag t s = concat ["<", t, ">", s, ""] unwrapTag (Document _ _ (Elem _ _ c) _) = c unwrapTag _ = error "oops, not wrapped" From cdsmith at twu.net Tue Apr 1 11:37:57 2008 From: cdsmith at twu.net (Chris Smith) Date: Tue Apr 1 11:34:11 2008 Subject: [Haskell-cafe] Re: FW: Haskell References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> <804685025.20080401150254@gmail.com> <6d996c210804010742m53eaa55as6fb70e4326c1ff02@mail.gmail.com> Message-ID: Just random thoughts here. Andrew Bagdanov wrote: > Well, if I don't have side effects (and don't mind extra, unneeded > evaluations), I can write my conditionals as functions in Scheme too. > Heck, now that I think of it I can even avoid those extra evaluations > and side-effect woes if i require promises for each branch of the > conditional. No macros required... This is essentially doing lazy evaluation in Scheme. It's certainly possible; just clumsy. You must explicitly say where to force evaluation; but if you think about it, the run-time system already knows when it needs a value. This is very analogous to having type inference instead of explicitly declaring a bunch of types as in Java or C++. > Again, I think this is highly problem > dependent, though I think you win more with lazy evaluation in the long > run. Do more experienced Haskellers than me have the opposite > experience? I mean, do you ever find yourself forcing strict evaluation > so frequently that you just wish you could switch on strict evaluation > as a default for a while? The first thing I'd say is that Haskell, as a purely functional language that's close enough to the pure lambda calculus, has unique normal forms. Furthermore, normal order (and therefore lazy) evaluation is guaranteed to be an effective evaluation order for reaching those normal forms. Therefore, forcing strictness can never be needed to get a correct answer from a program. (Applicative order evaluation does not have this property.) Therefore, strictness is merely an optimization. In some cases, it can improve execution time (by a constant factor) and memory usage (by a lot). In other cases, it can hurt performance by doing calculations that are not needed. In still more cases, it is an incorrect optimization and can actually break the code by causing certain expressions that should have an actual value to become undefined (evaluate to bottom). I've certainly seen all three cases. There are certainly situations where Haskell uses a lot of strictness annotations. For example, see most of the shootout entries. In practice, though, code isn't written like that. I have rarely used any strictness annotations at all. Compiling with optimization in GHC is usually good enough. The occasional bang pattern (often when you intend to run something in the interpreter) works well enough. (As an aside, this situation is quite consistent with the general worldview of the Haskell language and community. Given that strictness is merely an optimization of laziness, the language itself naturally opts for the elegant answer, which is lazy evaluation; and then Simon and friends work a hundred times as hard to make up for it in GHC!) > I think this is possibly the weakest reason to choose Haskell over > Scheme. Lispers like the regularity of the syntax of S-expressions, the > fact that there is just one syntactic form to learn, understand, teach, > and use. I am strongly convinced, by the collective experience of a number of fields of human endeavor, that noisy syntax gets in the way of understanding. Many people would also say that mathematical notation is a bit impenetrable -- capital sigmas in particular seem to scare people -- but I honestly think we'd be a good ways back in the advancement of mathematical thought if we didn't have such a brief and non-obstructive syntax for these things. Mathematicians are quite irregular. Sometimes they denote that y depends on x by writing y(x); sometimes by writing y_x (a subscript); and sometimes by writing y and suppressing x entirely in the notation. These are not arbitrary choices; they are part of how human beings communicate with each other, by emphasizing some things, and suppressing others. If one is to truly believe that computer programs are for human consumption, then striving for regularity in syntax doesn't seem consistent. Initially, syntax appears to be on a completely different level from all the deep "semantic" differences; but they are in reality deeply interconnected. The earlier comment I made about it being clumsy to do lazy programming in Scheme was precisely that the syntax is too noisy. Other places where lazy evaluation helps, in particular compositionality, could all be simulated in Scheme, but you'd have to introduce excessive syntax. The result of type inference is also a quieter expression of code. So if concise syntax is not desirable, then one may as well throw out laziness and type inference as well. Also, sections and currying. Also, do notation. And so on. > In short, I think the orginal question must be asked in context. For > some problems, types are just a natural way to start thinking about > them. For others dynamic typing, with _judicious_ use of macros to > model key aspects, is the most natural approach. I wouldn't completely rule out, though, the impact of the person solving the problem on whether type-based problem solving is a natural and useful way to solve problems. Indeed, I would guess this probably ends up being a greater factor, in the end, than the problem. Unfortunately, we (as a general programming community) have caged ourselves into a box with the mantra "use the right tool for the job" such that we find it far too easy to dismiss something as the wrong tool merely because it is unfamiliar. My not being able to use a tool well may be a good reason for me, but it's a lousy reason for me to advise someone else. From bagdanov at gmail.com Tue Apr 1 12:17:46 2008 From: bagdanov at gmail.com (Andrew Bagdanov) Date: Tue Apr 1 12:13:50 2008 Subject: [Haskell-cafe] FW: Haskell In-Reply-To: <6f9f8f4a0804010755r1946db37h5ae188741cadd1e8@mail.gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> <804685025.20080401150254@gmail.com> <6d996c210804010742m53eaa55as6fb70e4326c1ff02@mail.gmail.com> <6f9f8f4a0804010755r1946db37h5ae188741cadd1e8@mail.gmail.com> Message-ID: <6d996c210804010917x2755641aw34dcb896573730b7@mail.gmail.com> On Tue, Apr 1, 2008 at 4:55 PM, Loup Vaillant wrote: > 2008/4/1, Andrew Bagdanov : > > > > > In short, I think the orginal question must be asked in context. For > > some problems, types are just a natural way to start thinking about > > them. For others dynamic typing, with _judicious_ use of macros to > > model key aspects, is the most natural approach. > > Do you have any example? I mean, you had to choose between Scheme and > Ocaml, sometimes, right? Ocaml is not Haskell, but maybe the reasons > which influenced your choices would have been similar if you knew > Haskell instead of Ocaml. > Sure. This may not be the best example, but it's the most immediate one for me. I'll try to be brief and hopefully still clear... Years ago I implemented an image processing system based on algorithmic patterns of IP defined over algebraic pixel types (algebraic in the ring, field, vector space sense). Here's a link to the chapter from my dissertation, for the chronically bored: http://www.micc.unifi.it/~bagdanov/thesis/thesis_08.pdf This was partially motivated by the observation that a lot of image processing is about _types_ and about getting them _right_. There's a complex interplay between the numerical, computational and perceptual semantics of the data you need to work with. A functional programming language with strict typing and type inference seemed ideal for modeling this. You get plenty of optimizations for "free" when lifting primitive operations to work on images (except OCaml functors really let me down here), and you don't have to worry figuring out what someone means when convolving a greyscale image with a color image -- unless you've already defined an instantiation of the convolution on these types that has a meaningful interpretation. Where "meaningful" is of course up to the implementor. In retrospect, if I had it all over to do again, I might choose Scheme over OCaml specifically because of dynamic typing. Or more flexible typing, rather. To completely define a new pixel datatype it is necessary to define a flotilla of primitive operations on it (e.g. add, mul, neg, div, dot, abs, mag, ...) but for many higher-level operations, only a handful were necessary. For example, for a standard convolution, mul and add are sufficient. In cases like this, I would rather explicitly dispatch at a high level -- in a way that admits partial implementations of datatypes to still play in the system. In retro-retrospect, the structural typing of OCaml objects could probably do this pretty well too... Oh well. This is a case where the resulting system was difficult to use in the exploratory, experimental it was intended to be used, in my opinion because typing got in the way. Strict typing and type inference were a huge boon for the design and implementation. I would consider Haskell this time around too (I think I did all those years ago too), as I think lazy evaluation semantics, direct support of monadic style, and yes, even it's terse syntax, could address other aspects of the domain that are untouched. I don't have a clear enough understanding of or experience with Haskell type classes, but my intuition is that I'd have the same problems with typing as I did with OCaml. Cheers, -Andy > Cheers, > Loup > From jgbailey at gmail.com Tue Apr 1 12:57:43 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Tue Apr 1 12:53:44 2008 Subject: [Haskell-cafe] FW: Haskell In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On Tue, Apr 1, 2008 at 3:18 AM, Simon Peyton-Jones wrote: > Dear Haskell Cafe members > > Here's an open-ended question about Haskell vs Scheme. Don't forget to cc Douglas in your replies; he may not be on this list (yet)! > > Simon No one seems to have pointed out how friendly the Haskell community is. Not only can you email the language designers (and they respond) - they'll even help you answer your question! I don't want to encourage more unsolicited email to Simon, but I'm impressed. Justin From simonmarhaskell at gmail.com Tue Apr 1 13:15:12 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 1 13:11:14 2008 Subject: [Haskell-cafe] Re: all threads are blocked by recvFrom In-Reply-To: References: Message-ID: <47F26DA0.2030409@gmail.com> Vitaliy Akimov wrote: > Hello, I have a problem with building multithreaded UDP server. If > main thread is waiting for new request in recvFrom all other threads > are blocked too. I've checked every variant with > forkIO,forkOS,-threaded etc, nothing's helped. After reading GHC docs > I've understood this is happened becouse foreign function call from > recvFrom (network library) is marked to be unsefe, so it's execution > blocks every other thread. How can I resolve it? Sorry for the late reply. This will be fixed in GHC 6.8.3: http://hackage.haskell.org/trac/ghc/ticket/1129 Cheers, Simon From bcarnazzi at gmail.com Tue Apr 1 13:50:30 2008 From: bcarnazzi at gmail.com (Bruno Carnazzi) Date: Tue Apr 1 13:46:30 2008 Subject: [Haskell-cafe] [Newbie] Problem with Data.Map (or something else ?) In-Reply-To: References: <1464be950803310851j7658f795qfe69a827c671bebd@mail.gmail.com> Message-ID: <1464be950804011050i60cb7f08g57a8ae7bf3d19182@mail.gmail.com> 2008/4/1, Chadda? Fouch? : > 2008/3/31, Bruno Carnazzi : > > > Dears Haskellers, > > > > As an Haskell newbie, I'm learning Haskell by trying to resolve Euler > > Project problems (http://projecteuler.net/ ). I'm hanging on problem > > 14 (Collatz problem). > > > > I've written the following program... Which does not end in a reasonable time :( > > My algorithm seems ok to me but I see that memory consumption is gigantic... > > Is this a memory problem with Data.Map ? Or an infinite loop ? (Where ?) > > In a more general way, how can I troubleshoot these kind of problem ? > > > Others have pointed potential source of memory leaks, but I must say > that using Data.Map for the cache in the first place appear to me as a > very bad idea... Data.Map by nature take much more place than > necessary. You have an integer index, why not use an array instead ? Because I don't know anything about arrays in Haskell. Thank you for pointing this, I have to read some more Haskell manuals :) > > > import Data.Array > > import Data.List > > import Data.Ord > > > > syrs n = a > > where a = listArray (1,n) $ 0:[ syr n x | x <- [2..n]] > > syr n x = if x' <= n then a ! x' else 1 + syr n x' > > where x' = if even x then x `div` 2 else 3 * x + 1 > > > > main = print $ maximumBy (comparing snd) $ assocs $ syrs 1000000 > The logic and the complexity in this algorithm is comparable to mine but the performance difference is huge, which is not very intuitive in my mind (There is no "1+1+1+1+1..." problem with array ?) > This solution takes 2 seconds (on my machine) to resolve the problem. > > On the other hand, now that I have read your solution, I see that > using Map was the least of the problem... All those Map.map, while > retaining the original Map... Your solution is too clever (twisted) > for its own good, I suggest you aim for simplicity next time. > > > -- > Jeda? > Thank you, Bruno. From prstanley at ntlworld.com Tue Apr 1 15:21:37 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Tue Apr 1 15:17:24 2008 Subject: [Haskell-cafe] function type def Message-ID: <7.0.1.0.0.20080401202101.01cf4588@ntlworld.com> HI It's one of those things - I know sort of instinctively why it is so but can't think of the formal rationale for it: f g x = g (g x) :: (t -> t) -> (t -> t) Why not (t -> t) -> t -> (t -> t) to take account of the argument x for g? Cheers Paul From ketil at malde.org Tue Apr 1 15:28:39 2008 From: ketil at malde.org (Ketil Malde) Date: Tue Apr 1 15:24:30 2008 Subject: [Haskell-cafe] function type def In-Reply-To: <7.0.1.0.0.20080401202101.01cf4588@ntlworld.com> (PR Stanley's message of "Tue\, 01 Apr 2008 20\:21\:37 +0100") References: <7.0.1.0.0.20080401202101.01cf4588@ntlworld.com> Message-ID: <877ifhpe6w.fsf@nmd9999.imr.no> PR Stanley writes: > It's one of those things - I know sort of instinctively why it is so > but can't think of the formal rationale for it: > f g x = g (g x) :: (t -> t) -> (t -> t) (t -> t) -> (t -> t) So g :: t -> t x :: t Thus f :: (t -> t) -> t -> t (The last parenthesis is not necessary, but implies that the type of the partial application f g is a function t -> t .) -k -- If I haven't seen further, it is by standing in the footprints of giants From jerzy.karczmarczuk at info.unicaen.fr Tue Apr 1 15:35:16 2008 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Tue Apr 1 15:31:17 2008 Subject: [Haskell-cafe] function type def In-Reply-To: <7.0.1.0.0.20080401202101.01cf4588@ntlworld.com> References: <7.0.1.0.0.20080401202101.01cf4588@ntlworld.com> Message-ID: PR Stanley: > I know sort of instinctively why it is so but > can't think of the formal rationale for it: > f g x = g (g x) :: (t -> t) -> (t -> t) First of all - it is not the definition f g x = ... :: (t-> ... but the type of the function which might be specified: f :: (t->t)->t->t Then, the answer to: > Why not > (t -> t) -> t -> (t -> t) > to take account of the argument x for g? is simple. If t is the type of x, then g must be g :: t->t, you're right. So f :: (t->t) -> t -> [the type of the result] But this result is of the type t, it is g(g x), not (t->t), it is as simple as that. Perhaps you didn't recognize that "->" is syntactically a right-associative op, so a->b->c is equivalent to a->(b->c), or (t->t)->t->t equiv. to (t->t)->(t->t) Jerzy Karczmarczuk From manlio_perillo at libero.it Tue Apr 1 15:51:32 2008 From: manlio_perillo at libero.it (Manlio Perillo) Date: Tue Apr 1 15:47:33 2008 Subject: [Haskell-cafe] [GSoC] Student applications deadline extended one week In-Reply-To: <396556a20803311609h4028112bob42a72b6857bd3e2@mail.gmail.com> References: <20080331173255.GB32132@scytale.galois.com> <47F134D7.3000403@libero.it> <396556a20803311609h4028112bob42a72b6857bd3e2@mail.gmail.com> Message-ID: <47F29244.5040501@libero.it> Adam Langley ha scritto: > On Mon, Mar 31, 2008 at 12:00 PM, Manlio Perillo > wrote: >> Since Nginx is asynchronous, how can be solved the producer-consumer >> problem (that is, the Haskell program produces more data that Nginx can >> send to the client without blocking)? > > I assume that the Haskell process is connected to nginx over a pipe or > socket. No, the idea is to have the Haskell application embedded in nginx. > In which case, nginx can use flow control to block the sending > side of the pipe and the Haskell code will backup on that. > > If many connections need to be multiplexed over the same > flow-controlled entity (i.e. a pipe), without head-of-line blocking > then you can just suspend the current thread using an MVar or the STM > objects. > > Alternatively, with Network.MiniHTTP the problem is turned inside out. > Request handlers give return a Source object, which can be asked to > generate more data on request. This would be similar to generators in > Python. > This (the first suggestion) seems very interesting, thanks. > > AGL > Manlio Perillo From prstanley at ntlworld.com Tue Apr 1 16:31:29 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Tue Apr 1 16:27:16 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: <14d615330804010350x46c549b9r668c79c997902a7c@mail.gmail.co m> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <14d615330804010350x46c549b9r668c79c997902a7c@mail.gmail.com> Message-ID: <7.0.1.0.0.20080401212332.01d57e38@ntlworld.com> >Think about this: > >map (+1) [1..10] > >What should it do? > take (+1) and return a function which takes a list as its > argument and finally return a list. >How about: > >f 1 2 3 > >Should that be f (1 (2 3)), or ((f 1) 2) 3? The latter, of course, but that's not really what I'm driving at. I'm asking why we can't have a function treated differently with regard to the precedence and associativity rules. f 1 2 is indeed ((f 1) 2). Why not f 1 g 2 == ((f 1) (g 2))? Cheers, Paul From cdsmith at twu.net Tue Apr 1 16:45:49 2008 From: cdsmith at twu.net (Chris Smith) Date: Tue Apr 1 16:41:58 2008 Subject: [Haskell-cafe] Re: Function Precedence References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <14d615330804010350x46c549b9r668c79c997902a7c@mail.gmail.com> <7.0.1.0.0.20080401212332.01d57e38@ntlworld.com> Message-ID: PR Stanley wrote: >>Should that be f (1 (2 3)), or ((f 1) 2) 3? > The latter, of course, but that's not really what I'm > driving at. I'm asking why we can't have a function treated differently > with regard to the precedence and associativity rules. f 1 2 is indeed > ((f 1) 2). Why not f 1 g 2 == ((f 1) (g 2))? Are you asking why one doesn't change the rules for all functions? Or are you asking why Haskell doesn't include a system of user-defined precedence and associativity for function application so that one could declare that g binds more tightly than f? I see good reasons for both questions, but I'm unsure which you mean. In both cases, it comes down to consistency of the syntax rules. In order for (f 1 g 2) to parse as (f 1) (g 2), one would have to do something surprising. It's unclear what that is: perhaps treat literals differently from variables? Somehow determine a precedence level for (f 1)? Or maybe favor shorter argument lists for grouping function application? If you have a very clear kind of grouping that you think makes sense in all cases, feel free to mention it. It seems unlikely to me, but perhaps everyone will agree, once they see it, that it is in fact better than the current parsing rules. -- Chris Smith From apfelmus at quantentunnel.de Tue Apr 1 16:55:14 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Tue Apr 1 16:51:25 2008 Subject: [Haskell-cafe] Re: FW: Haskell In-Reply-To: <47F2389A.4060903@tcs.inf.tu-dresden.de> References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> <804685025.20080401150254@gmail.com> <6f9f8f4a0804010619h5da8fc27kf1992d779920c95@mail.gmail.com> <47F2389A.4060903@tcs.inf.tu-dresden.de> Message-ID: Janis Voigtlaender wrote: > Loup Vaillant wrote: >> Thanks to some geniuses (could someone name them?), we have type >> classes and higher order types in Haskell (and even more). > > As far as names go: > > .... for type classes, of course Wadler, but also Blott and Kaes. > > .... for higher order types, well, where to start? Girard and Reynolds? Regards, apfelmus From prstanley at ntlworld.com Tue Apr 1 17:07:00 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Tue Apr 1 17:02:46 2008 Subject: [Haskell-cafe] Re: Function Precedence In-Reply-To: References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <14d615330804010350x46c549b9r668c79c997902a7c@mail.gmail.com> <7.0.1.0.0.20080401212332.01d57e38@ntlworld.com> Message-ID: <7.0.1.0.0.20080401220510.01d5cec0@ntlworld.com> Are you asking why one doesn't change the rules for all functions? Or are you asking why Haskell doesn't include a system of user-defined precedence and associativity for function application so that one could declare that g binds more tightly than f? I see good reasons for both questions, but I'm unsure which you mean. In both cases, it comes down to consistency of the syntax rules. In order for (f 1 g 2) to parse as (f 1) (g 2), one would have to do something surprising. It's unclear what that is: perhaps treat literals differently from variables? Somehow determine a precedence level for (f 1)? Or maybe favor shorter argument lists for grouping function application? If you have a very clear kind of grouping that you think makes sense in all cases, feel free to mention it. It seems unlikely to me, but perhaps everyone will agree, once they see it, that it is in fact better than the current parsing rules. Paul: All you'd have to do is to give the inner most function the highest precdence therefore f g x == f (g x) let f x = x^2 let g x = x`div`2 f g 4 == error while f (g 4) == 4 I'm beginning to wonder if I fully understand the right associativity rule for the -> operator. Cheers, Paul From lgreg.meredith at biosimilarity.com Tue Apr 1 17:08:38 2008 From: lgreg.meredith at biosimilarity.com (Greg Meredith) Date: Tue Apr 1 17:04:38 2008 Subject: [Haskell-cafe] Haskell vs Scheme Message-ID: <5de3f5ca0804011408k33001014g6944b9ada53d5ef0@mail.gmail.com> Douglas, Excellent questions you posed to Simon P-J -- who then forwarded them to the Haskell Cafe list. By way of answering i should say i was a Schemer from the get-go; it was really the first programming language i studied as an undergraduate majoring in maths at Oberlin in the early 80's. Eventually, i went on to design and build my own language (at MCC with Christine Tomlinson, the principal investigator) called Rosette. While Scheme was Sussman and Abelson's way of making sense of Hewitt's ideas in a sequential setting Rosette was our way of doing the full banana -- including the actor-based form of concurrency as well as both structural and 3-Lisp-style procedural reflection and a whole host of other advanced features. So, i was naturally profoundly frustrated when the world at large turned to languages like C, C++ and even Java. i have been waiting more than 20 years for the industry to catch up to the joys of advanced language design. Now that the industry has taken a shine to functional languages again i have been spending more time with the various modern flavors and have to say that while each of the major contenders (ML, OCaml, Erlang, Scala, Haskell) have something to be said for them, Haskell stands out among them. Haskell enjoys a particular form of mental hygiene that few other languages enjoy. Its syntax, by comparison with Scheme, is remarkably concise -- and, the importance of syntax is almost impossible to gauge because at the end of the day it is code one is staring at ;-). The chief semantic differences that make a difference to my mind may be classified as follows. - types - monads - meta-programming In order, then: at its outset Haskell made a strong commitment to a potent (static) typing scheme. Even if types can be layered on Scheme, the two language design vectors are remarkably different and give programming a different feel. As a result of my academic and professional training i have come to rely heavily on types as a development discipline. In fact, if i cannot devise a sensible type "algebra" for a given (application) domain then i feel i don't really have a good understanding of the domain. One way of seeing this from the Schemer point if view is that the deep sensibility embodied in the Sussman and Abelson book of designing a DSL to solve a problem is further refined by types. Types express an essential part of the grammar of that language. In Haskell the close connection between typing and features like pattern-matching are also part of getting a certain kind of coherence between data and control. Again, this can be seen as taking the coherence between data and control -- already much more evident in Scheme than say C or C++ or even Java -- up a notch. Haskell's language-level and library support for monads are really what set this language apart. i feel pretty confident when i voice my opinion that the most important contribution to computing (and science) that functional programming has made in the last 15 years has been to work out practical presentations of the efficacy of the notion of monad. As a Schemer i'm sure you understand the critical importance of composition and compositional design. The monad provides an important next step in our understanding of composition effectively by making the notion parametric along certain dimensions. This allows a programmer to capture very general container patterns and control patterns (as well as other phenomena) with a very concise abstraction. Again, this could be layered onto Scheme, but Haskell embraced monad as a central abstraction at the language design level and this leads to very different approaches to programming. Now, the place where Haskell and the other statically typed functional languages have some catching up to do is meta-programming. Scheme, Lisp and other languages deriving from the McCarthy branch of the investigation of lambda-calculus-based programming languages enjoy a much longer and deeper investigation of meta-programming constructs. While MetaOCaml stands out as a notable exception i think it safe to say that 3-Lisp and Brown are pretty strong evidence of the long history and much richer investigation of meta-programming notions along the McCarthy branch than along the Milner branch. The industry as a whole, i think, has embraced the value of meta-programming -- witness (structural) reflection in such mainstream languages as Java and C#. And the Milner branch family of languages are moving rapidly to catch up -- see the efforts on generic programming like S P-J's SYB or TemplateHaskell -- but the deep coherence evident in the simplicity of the monadic abstraction has not met up with the deep coherence of 3-Lisp, yet. Anyway, that's my two cents... but i note that US currency is not worth what it used to be. Best wishes, --greg Message: 21 Date: Tue, 1 Apr 2008 11:18:25 +0100 From: Simon Peyton-Jones Subject: [Haskell-cafe] FW: Haskell To: Haskell Cafe Cc: "kerrangster@gmail.com" Message-ID: < 638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com > Content-Type: text/plain; charset="us-ascii" Dear Haskell Cafe members Here's an open-ended question about Haskell vs Scheme. Don't forget to cc Douglas in your replies; he may not be on this list (yet)! Simon -----Original Message----- From: D. Gregor [mailto:kerrangster@gmail.com] Sent: 30 March 2008 07:58 To: Simon Peyton-Jones Subject: Haskell Hello, In your most humble opinion, what's the difference between Haskell and Scheme? What does Haskell achieve that Scheme does not? Is the choice less to do with the language, and more to do with the compiler? Haskell is a pure functional programming language; whereas Scheme is a functional language, does the word "pure" set Haskell that much apart from Scheme? I enjoy Haskell. I enjoy reading your papers on parallelism using Haskell. How can one answer the question--why choose Haskell over Scheme? Regards, Douglas -- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080401/7186747c/attachment.htm From prstanley at ntlworld.com Tue Apr 1 17:17:27 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Tue Apr 1 17:13:13 2008 Subject: [Haskell-cafe] function type def In-Reply-To: References: <7.0.1.0.0.20080401202101.01cf4588@ntlworld.com> Message-ID: <7.0.1.0.0.20080401221023.01d5edf8@ntlworld.com> Try putting this through your GHCI: :t twice f x = f (f x) I'd presume that based on the inference of (f x) f is (t -> t) and x :: t Yes, Maybe I should get the right associativity rule cleared first. Cheers, Paul At 20:35 01/04/2008, you wrote: >PR Stanley: >>I know sort of instinctively why it is so but can't think of the >>formal rationale for it: >>f g x = g (g x) :: (t -> t) -> (t -> t) > >First of all - it is not the definition f g x = ... :: (t-> ... >but the type of the function which might be specified: >f :: (t->t)->t->t >Then, the answer to: >>Why not >>(t -> t) -> t -> (t -> t) >>to take account of the argument x for g? > >is simple. If t is the type of x, then g must be g :: t->t, you're right. >So f :: (t->t) -> t -> [the type of the result] >But this result is of the type t, it is g(g x), not (t->t), it is as >simple as that. Perhaps you didn't recognize that "->" is syntactically >a right-associative op, so >a->b->c is equivalent to a->(b->c), or >(t->t)->t->t equiv. to (t->t)->(t->t) > >Jerzy Karczmarczuk >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe@haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe From allbery at ece.cmu.edu Tue Apr 1 17:30:39 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Apr 1 17:26:40 2008 Subject: [Haskell-cafe] Re: Function Precedence In-Reply-To: <7.0.1.0.0.20080401220510.01d5cec0@ntlworld.com> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <14d615330804010350x46c549b9r668c79c997902a7c@mail.gmail.com> <7.0.1.0.0.20080401212332.01d57e38@ntlworld.com> <7.0.1.0.0.20080401220510.01d5cec0@ntlworld.com> Message-ID: <0050D574-3565-4EC5-9CC3-91E135993CF2@ece.cmu.edu> On Apr 1, 2008, at 17:07 , PR Stanley wrote: > I'm beginning to wonder if I fully understand the right > associativity rule for the -> operator. Read a parenthesized unit as an argument: > (a -> (b -> (c -> d))) (((f 1) 2) 3) > (((a -> b) -> c) -> d) (f (1 (2 3))) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From bagdanov at gmail.com Tue Apr 1 17:50:38 2008 From: bagdanov at gmail.com (Andrew Bagdanov) Date: Tue Apr 1 17:46:41 2008 Subject: [Haskell-cafe] Re: FW: Haskell In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> <804685025.20080401150254@gmail.com> <6d996c210804010742m53eaa55as6fb70e4326c1ff02@mail.gmail.com> Message-ID: <6d996c210804011450u53d766c1vf8ea9b60ee047537@mail.gmail.com> On Tue, Apr 1, 2008 at 5:37 PM, Chris Smith wrote: > Just random thoughts here. > Same here... > > Andrew Bagdanov wrote: > > Well, if I don't have side effects (and don't mind extra, unneeded > > evaluations), I can write my conditionals as functions in Scheme too. > > Heck, now that I think of it I can even avoid those extra evaluations > > and side-effect woes if i require promises for each branch of the > > conditional. No macros required... > > This is essentially doing lazy evaluation in Scheme. It's certainly > possible; just clumsy. You must explicitly say where to force > evaluation; but if you think about it, the run-time system already knows > when it needs a value. This is very analogous to having type inference > instead of explicitly declaring a bunch of types as in Java or C++. > Boy is it ever clumsy, and I like your analogy too. But lazy evaluation semantics typically come with purity, which is also a fairly heavy burden to foist onto the user... Certainly not without benefits, but at times a burden nonetheless... > > > Again, I think this is highly problem > > dependent, though I think you win more with lazy evaluation in the long > > run. Do more experienced Haskellers than me have the opposite > > experience? I mean, do you ever find yourself forcing strict evaluation > > so frequently that you just wish you could switch on strict evaluation > > as a default for a while? > > The first thing I'd say is that Haskell, as a purely functional language > that's close enough to the pure lambda calculus, has unique normal > forms. Furthermore, normal order (and therefore lazy) evaluation is > guaranteed to be an effective evaluation order for reaching those normal > forms. Therefore, forcing strictness can never be needed to get a > correct answer from a program. (Applicative order evaluation does not > have this property.) > I thought that in a pure functional language any evaluation order was guaranteed to reduce to normal form. But then it's been a very, very long time since I studied the lambda calculus... > Therefore, strictness is merely an optimization. In some cases, it can > improve execution time (by a constant factor) and memory usage (by a > lot). In other cases, it can hurt performance by doing calculations that > are not needed. In still more cases, it is an incorrect optimization and > can actually break the code by causing certain expressions that should > have an actual value to become undefined (evaluate to bottom). I've > certainly seen all three cases. > > There are certainly situations where Haskell uses a lot of strictness > annotations. For example, see most of the shootout entries. In > practice, though, code isn't written like that. I have rarely used any > strictness annotations at all. Compiling with optimization in GHC is > usually good enough. The occasional bang pattern (often when you intend > to run something in the interpreter) works well enough. > > (As an aside, this situation is quite consistent with the general > worldview of the Haskell language and community. Given that strictness > is merely an optimization of laziness, the language itself naturally opts > for the elegant answer, which is lazy evaluation; and then Simon and > friends work a hundred times as hard to make up for it in GHC!) > Yeah, I'm actually pretty convinced on the laziness issue. Lazy evaluation semantics are a big win in many ways. > > > I think this is possibly the weakest reason to choose Haskell over > > Scheme. Lispers like the regularity of the syntax of S-expressions, the > > fact that there is just one syntactic form to learn, understand, teach, > > and use. > > I am strongly convinced, by the collective experience of a number of > fields of human endeavor, that noisy syntax gets in the way of > understanding. Many people would also say that mathematical notation is > a bit impenetrable -- capital sigmas in particular seem to scare people > -- but I honestly think we'd be a good ways back in the advancement of > mathematical thought if we didn't have such a brief and non-obstructive > syntax for these things. Mathematicians are quite irregular. Sometimes > they denote that y depends on x by writing y(x); sometimes by writing y_x > (a subscript); and sometimes by writing y and suppressing x entirely in > the notation. These are not arbitrary choices; they are part of how > human beings communicate with each other, by emphasizing some things, and > suppressing others. If one is to truly believe that computer programs > are for human consumption, then striving for regularity in syntax doesn't > seem consistent. > All good points, but "noisy" is certainly in the eye of the beholder. I'd make a distinction between background and foreground noise. A simple, regular syntax offers less background noise. I don't have to commit lots of syntactic idioms and special cases to memory to read and write in that language. Low background noise in Scheme, and I'm responsible for whatever foreground noise I create with my syntactic extensions. Haskell, with more inherent syntax, has more background noise but perhaps limits the amount of foreground noise I can introduce because it constrains me from the beginning... OK, this analogy is starting to suck, so I'll move on... More on the mathematical notation analogy below. > Initially, syntax appears to be on a completely different level from all > the deep "semantic" differences; but they are in reality deeply > interconnected. The earlier comment I made about it being clumsy to do > lazy programming in Scheme was precisely that the syntax is too noisy. > Other places where lazy evaluation helps, in particular compositionality, > could all be simulated in Scheme, but you'd have to introduce excessive > syntax. The result of type inference is also a quieter expression of > code. So if concise syntax is not desirable, then one may as well throw > out laziness and type inference as well. Also, sections and currying. > Also, do notation. And so on. > Well, yes. However, I think, and have found through personal experience, that notation is one of the most personal aspects of mathematics, and one of the most difficult things to get "right." Or even "pretty good." Good notation that conveys meaning without distraction and confusion (ah yes, the interconnection between syntax and semantics rears it's head again) is extremely difficult to invent. Like in mathematics, at the boundaries of creativity, I prefer the freedom to create my own notation and syntax in order to express my ideas about computation, and to adapt them to whatever relevant community standards are appropriate (physicists, signal processors, and image processing folks all have their own notations for convolution). Haskell has an elegant and expressive, but already quite defined and complex, syntax that is not particularly malleable. Returning to your line of reasoning, why should one have to commit to a single, already defined syntax instead of a minimal, regular one which admits the possibility of extending and modifying the syntax to fit my needs? It's a double-edged blade, obviously, because if I botch my syntax extensions I ruin the regularity and simplicity I originally had and don't communicate clearly to others or myself. It's the same risk as in mathematics, and just a hard to get "right." Do notation and sections are both syntactic constructs that irk me at an almost visceral level about Haskell syntax, but I certainly see the convenience of both and recognize that my opinion is wholly subjective. That Scheme applications are non-currying by default is one of the things that irks me now about Scheme... > > > In short, I think the orginal question must be asked in context. For > > some problems, types are just a natural way to start thinking about > > them. For others dynamic typing, with _judicious_ use of macros to > > model key aspects, is the most natural approach. > > I wouldn't completely rule out, though, the impact of the person solving > the problem on whether type-based problem solving is a natural and useful > way to solve problems. Indeed, I would guess this probably ends up being > a greater factor, in the end, than the problem. Unfortunately, we (as a > general programming community) have caged ourselves into a box with the > mantra "use the right tool for the job" such that we find it far too easy > to dismiss something as the wrong tool merely because it is unfamiliar. > My not being able to use a tool well may be a good reason for me, but > it's a lousy reason for me to advise someone else. > Yes and no. I see your point about the person being central to the problem solving itself, and "the right tool for the right job" implicitly assumes that there is on "right" solution for a problem. However, I can pretty much only base my advice to someone about what tools to use on my own experience with those tools (qualified, of course, with the upfront admission that it's based on personal experience), and I would likewise be wary myself of someone giving advice that wasn't tempered by experience. Theoretical discussions about the theoretical underpinnings of tools seem to be an equally lousy basis for such advice. Cheers, -Andy > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From artem at AA5779.spb.edu Tue Apr 1 18:27:08 2008 From: artem at AA5779.spb.edu (Artem V. Andreev) Date: Tue Apr 1 18:23:23 2008 Subject: [Haskell-cafe] FW: Haskell In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> (Simon Peyton-Jones's message of "Tue, 1 Apr 2008 11:18:25 +0100") References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <87ej9p6wjn.fsf@artemsmp.local> Simon Peyton-Jones writes: > Dear Haskell Cafe members > > Here's an open-ended question about Haskell vs Scheme. Don't forget to cc Douglas in your replies; he may not be on this list (yet)! > > Simon > > -----Original Message----- > From: D. Gregor [mailto:kerrangster@gmail.com] > Sent: 30 March 2008 07:58 > To: Simon Peyton-Jones > Subject: Haskell > > Hello, > > In your most humble opinion, what's the difference between Haskell and > Scheme? What does Haskell achieve that Scheme does not? Is the choice less > to do with the language, and more to do with the compiler? Haskell is a > pure functional programming language; whereas Scheme is a functional > language, does the word "pure" set Haskell that much apart from Scheme? I > enjoy Haskell. I enjoy reading your papers on parallelism using Haskell. > How can one answer the question--why choose Haskell over Scheme? In my most humble of opinions, the comparison between Haskell and Scheme is just methodologically incorrect. What I mean is that these are actually different kinds of entities, despite they both are called "programming languages". In particular, Scheme is nothing but a minimal core of a programming language -- despite it being Turing complete, one can hardly write any serious, "real-world" program in pure Scheme, as defined by IEEE or whatever. So Scheme is, to my mind, what is it called -- a scheme, which different implementors supply with various handy additions. And we do not have any "leading" Scheme implementation that would count as a de facto definition of a "real" Scheme language. Thus we conclude that the term "Scheme" denotes not a programming language, but rather a family of programming languages. On the other hand, Haskell, as defined by The Report (well, plus FFI addendum) is a true solid "real-world" language which can actually be used for real-world programming as it is. And we do have a dominating implementation as well, etc etc. Thus: a methodologically correct comparison should be done either between two implementations (Bigloo vs GHC, or MIT Scheme vs Hugs or Stalin vs Jhc or whatever you like) or on the level of PL families and then we'd have Scheme versus Haskell+Helium+Clean+maybe even Miranda+whatever else. In the latter case we'd have two choices again: comparing "upper bounds" or "lower bounds", that is, comparing sets of features provided by any representative of a class or by *all* representatives. Needless to say that the outcome would differ drastically depending on which way we take. -- S. Y. A(R). A. From nominolo at googlemail.com Tue Apr 1 18:36:04 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Apr 1 18:32:09 2008 Subject: [Haskell-cafe] FW: Haskell In-Reply-To: <87ej9p6wjn.fsf@artemsmp.local> References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> <87ej9p6wjn.fsf@artemsmp.local> Message-ID: <527D6C5F-D210-4AEC-A6B2-BCBA1FDDC5FB@googlemail.com> On 2 apr 2008, at 00.27, Artem V. Andreev wrote: > Needless to say that the outcome would differ drastically > depending on which way we take. > Right. Hence we try to answer Douglas' request in best faith to give him most useful answers. From westondan at imageworks.com Tue Apr 1 18:41:30 2008 From: westondan at imageworks.com (Dan Weston) Date: Tue Apr 1 18:37:52 2008 Subject: [Haskell-cafe] FW: Haskell In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <47F2BA1A.4020706@imageworks.com> This one's easy to answer: When I studied Scheme, I did not have an uncontrollable urge to pore through arcane papers trying to find out what the heck a natural transformation was, or a Kleisli arrow, or wonder how you can download Theorems for Free instead of having to pay for them, or see if I really could write a program only in point-free fashion. Nor did I use to take perfectly working code and refactor it until it cried for mercy, and then stay awake wondering if there was some abstraction out there I was missing that would really make it sing. You can debate the role of Haskell as a programming language per se, but when it comes to consciousness-raising, the jury is in...Haskell is my drug of choice! Dan Simon Peyton-Jones wrote: > Dear Haskell Cafe members > > Here's an open-ended question about Haskell vs Scheme. Don't forget to cc Douglas in your replies; he may not be on this list (yet)! > > Simon > > -----Original Message----- > From: D. Gregor [mailto:kerrangster@gmail.com] > Sent: 30 March 2008 07:58 > To: Simon Peyton-Jones > Subject: Haskell > > Hello, > > In your most humble opinion, what's the difference between Haskell and > Scheme? What does Haskell achieve that Scheme does not? Is the choice less > to do with the language, and more to do with the compiler? Haskell is a > pure functional programming language; whereas Scheme is a functional > language, does the word "pure" set Haskell that much apart from Scheme? I > enjoy Haskell. I enjoy reading your papers on parallelism using Haskell. > How can one answer the question--why choose Haskell over Scheme? > > Regards, > > Douglas > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From cdsmith at twu.net Tue Apr 1 19:20:56 2008 From: cdsmith at twu.net (Chris Smith) Date: Tue Apr 1 19:17:03 2008 Subject: [Haskell-cafe] Re: Function Precedence References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <14d615330804010350x46c549b9r668c79c997902a7c@mail.gmail.com> <7.0.1.0.0.20080401212332.01d57e38@ntlworld.com> <7.0.1.0.0.20080401220510.01d5cec0@ntlworld.com> Message-ID: PR Stanley wrote: > All you'd have to do is to give the inner most function the highest > precdence therefore > f g x == f (g x) > let f x = x^2 > let g x = x`div`2 > f g 4 == error while > f (g 4) == 4 I'm afraid I still don't understand what you're proposing. How can f g x mean f (g x), and yet f g 4 is different from f (g 4)? Maybe it'll help to point out that using functions as first-class concepts -- including passing them around as data -- is fundamental to functional programming languages. In other words, anything in the world could be a function, whether it's acting like a function right now or not. So distinguishing between (f g 4) and (f 1 2) is probably not wise. They either need to both parse like ((f g) 4), or they need to both parse like (f (1 2)). It has been the experience of the Haskell, ML, and other related languages that left associativity for function application works best. > I'm beginning to wonder if I fully understand the right associativity > rule for the -> operator. It just means that if I have a string of things separated by ->, I can put parentheses around all but the leftmost one, and it doesn't change the meaning. -- Chris Smith From cdsmith at twu.net Tue Apr 1 19:43:48 2008 From: cdsmith at twu.net (Chris Smith) Date: Tue Apr 1 19:39:55 2008 Subject: [Haskell-cafe] Re: FW: Haskell References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> <804685025.20080401150254@gmail.com> <6d996c210804010742m53eaa55as6fb70e4326c1ff02@mail.gmail.com> <6d996c210804011450u53d766c1vf8ea9b60ee047537@mail.gmail.com> Message-ID: I've just got a minute, so I'll answer the factual part. Andrew Bagdanov wrote: > I thought that in a pure functional language any evaluation order was > guaranteed to reduce to normal form. But then it's been a very, very > long time since I studied the lambda calculus... If you don't have strong normalization, such as is the case with Haskell, then you can look at the language as being a restriction of the pure untyped lambda calculus. In that context, you know that: (a) a given expression has at most one normal form, so that *if* you reach a normal form, it will always be the right one; and (b) normal order evaluation (and therefore lazy evaluation) will get you to that normal form if it exists. Other evaluation strategies may or may not reach the normal form, even if the expression does have a normal form. You may be thinking of typed lambda calculi, which tend to be strongly normalizing. Unlike the case with the untyped lambda calculus, in sound typed lambda calculi every (well-typed) term has exactly one normal form, and every evaluation strategy reaches it. However, unrestricted recursive types break normalization. This is not entirely a bad thing, since a strongly normalizing language can't be Turing complete. So real- world programming languages tend to provide recursive types and other features that break strong normalization. I'm sure there are others here who know this a lot better than I. I'm fairly confident everything there is accurate, but I trust someone will correct me if that confidence is misplaced. -- Chris Smith From vigalchin at gmail.com Tue Apr 1 21:16:57 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Tue Apr 1 21:13:02 2008 Subject: [Haskell-cafe] unix support Message-ID: <5ae4f2ba0804011816t38d4492bv7630157b08d8cd8b@mail.gmail.com> Hello, On my personal computer, I added some functionality to the unix package and now I want to test this functionality. Basically I did a cabal install to the global env on my laptop. I just ran a session of ghci: vigalchin@ubuntu:~$ ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m System.Posix Prelude System.Posix> :t openFd openFd :: FilePath -> OpenMode -> Maybe FileMode -> OpenFileFlags -> IO Fd Prelude System.Posix> :t mqOpen :1:0: Not in scope: `mqOpen' There is a signature for openFd (existing functionality) but not mqOpen (new functionality!) The new functionality got some warnings vis-a-vis Storage because I have defined "alignment" and something else yet. However, when I did "runhaskell Setup.hs install" everything seemed to get installed. ??? Thanks, B. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080401/83252ab1/attachment.htm From ok at cs.otago.ac.nz Tue Apr 1 21:40:49 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Tue Apr 1 21:36:51 2008 Subject: [Haskell-cafe] How can I represent 4x4 map in haskell In-Reply-To: <16396290.post@talk.nabble.com> References: <16396273.post@talk.nabble.com> <16396290.post@talk.nabble.com> Message-ID: <78706703-A432-4B8F-AC80-E44F355CFC54@cs.otago.ac.nz> On 1 Apr 2008, at 3:51 am, iliali16 wrote: > so my question is if this is ok to represent a map. If yes I will > try to > write the function which makes it 4 x 4 myself. What I jsut need as an > answer is Yes or No. Just to let you know is that I am trying to > build the > Wumpus World What you should know is that there is no rule that the Wumpus World has to be 4 x 4. Quoting http://web.inf.tu-dresden.de/~mit/LRAPP/wumpus/wumpus.htm "The size of the grid may vary for different scenarios." You are tacitly assuming that if you want to know what's where in the wumpus world you have to store an *image* of that world. But this is not so. The wumpus may be dead, in which case we don't care where it is, or it may be in some specific location: wumpus :: Maybe Location The gold may have been grabbed, in which case we know where it is without looking (we have it), or it may be in some specific place: gold :: Maybe Location In some versions of the wumpus world, there may be more than one piece of gold. In that case, gold :: [Location] There is some number of pits. There might be none. All we really want to know is whether a particular square is a pit or not. is_pit :: Location -> Bool It's not clear to me whether the gold or the wumpus might be in a pit. Since it's deadly to enter a pit anyway, we don't really care. The gold and the wumpus might well be in the same cell. So we can do this: type Location = (Int, Int) data Wumpus_World = Wumpus_World { bounds :: Location, wumpus :: Maybe Location, gold :: Maybe Location, is_pit :: Location -> Bool } initial_world = Wumpus_World { bounds = (4,4), wumpus = Just (3,3), gold = Just (3,3), is_pit = \loc -> case loc of (2,1) -> True (4,3) -> True _ -> False } -- I just made this one up holds :: Eq a => Maybe a -> a -> Bool holds (Just x) y = x == y holds (Nothing) _ = False has_wumpus, has_gold :: Wumpus_World -> Location -> Bool has_wumpus world location = wumpus world `holds` location has_gold world location = wumpus world `holds` location There are lots of other ways to do this, and whether this is a good one depends on what you need to do with it. It might be better to have has_wumpus :: Location -> Bool has_gold :: Location -> Bool as the field members directly, for example. One thing that is right about it is that it doesn't build in any specific idea of the size of the world. Another good thing is that it postpones the decision about how to tell where the pits are. But of course there are two maps: the complete map of how the world really is, which the world simulator has to have, and the "agent's" partial map recording what it has seen so far. They might have similar representations, or they might not. It's a really good idea to write as much of the code as you can so that it doesn't know what the map representation is. From chaddai.fouche at gmail.com Tue Apr 1 23:41:55 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Tue Apr 1 23:37:53 2008 Subject: [Haskell-cafe] [Newbie] Problem with Data.Map (or something else ?) In-Reply-To: <1464be950804011050i60cb7f08g57a8ae7bf3d19182@mail.gmail.com> References: <1464be950803310851j7658f795qfe69a827c671bebd@mail.gmail.com> <1464be950804011050i60cb7f08g57a8ae7bf3d19182@mail.gmail.com> Message-ID: 2008/4/1, Bruno Carnazzi : > Because I don't know anything about arrays in Haskell. Thank you for > pointing this, I have to read some more Haskell manuals :) A good place to learn about Haskell's array (which come in many flavours) is this wiki page : http://www.haskell.org/haskellwiki/Modern_array_libraries > > > > > import Data.Array > > > import Data.List > > > import Data.Ord > > > > > > syrs n = a > > > where a = listArray (1,n) $ 0:[ syr n x | x <- [2..n]] > > > syr x = if x' <= n then 1 + a ! x' else 1 + syr x' > > > where x' = if even x then x `div` 2 else 3 * x + 1 > > > > > > main = print $ maximumBy (comparing snd) $ assocs $ syrs 1000000 > > > > > The logic and the complexity in this algorithm is comparable to mine > but the performance difference is huge, which is not very intuitive in > my mind (There is no "1+1+1+1+1..." problem with array ?) Array or Map isn't really the problem here (my algorithm with a Map instead only take 6s to find the solution) as I thought at first. The main problem in your code I think is that because of Map.map, you create multiple copies of your smaller Maps in memory and union force them to materialize, while the fact that you don't evaluate the value means the GC won't collect them. Anyway, your algorithm by itself is pretty slow I think, since for every step to a number which is not already recorded you must add 1 to all the numbers you passed on the way. -- Jeda? From voigt at tcs.inf.tu-dresden.de Wed Apr 2 03:08:38 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Wed Apr 2 03:04:38 2008 Subject: [Haskell-cafe] Re: FW: Haskell In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> <804685025.20080401150254@gmail.com> <6f9f8f4a0804010619h5da8fc27kf1992d779920c95@mail.gmail.com> <47F2389A.4060903@tcs.inf.tu-dresden.de> Message-ID: <47F330F6.9010808@tcs.inf.tu-dresden.de> apfelmus wrote: > Janis Voigtlaender wrote: > >> Loup Vaillant wrote: >> >>> Thanks to some geniuses (could someone name them?), we have type >>> classes and higher order types in Haskell (and even more). >> >> >> As far as names go: >> >> .... for type classes, of course Wadler, but also Blott and Kaes. >> >> .... for higher order types, well, where to start? > > > Girard and Reynolds? Yes, that's the obvious suspects, of course. But I'm not sure I would say they brought polymorphism (assuming that's what is meant by "higher order types") to Haskell. Not in the same way Wadler and co. brought type classes, quite specifically, to Haskell. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From loup.vaillant at gmail.com Wed Apr 2 04:26:10 2008 From: loup.vaillant at gmail.com (Loup Vaillant) Date: Wed Apr 2 04:22:07 2008 Subject: [Haskell-cafe] Re: FW: Haskell In-Reply-To: <47F330F6.9010808@tcs.inf.tu-dresden.de> References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> <804685025.20080401150254@gmail.com> <6f9f8f4a0804010619h5da8fc27kf1992d779920c95@mail.gmail.com> <47F2389A.4060903@tcs.inf.tu-dresden.de> <47F330F6.9010808@tcs.inf.tu-dresden.de> Message-ID: <6f9f8f4a0804020126ye6e724cvb023b127e5b65198@mail.gmail.com> 2008/4/2, Janis Voigtlaender : > apfelmus wrote: > > > Janis Voigtlaender wrote: > > > > > Loup Vaillant wrote: > > > > Thanks to some geniuses (could someone name them?), we have type > > > > classes and higher order types in Haskell (and even more). > > > > > > As far as names go: > > > > > > .... for type classes, of course Wadler, but also Blott and Kaes. > > > > > > .... for higher order types, well, where to start? > > > > Girard and Reynolds? > > Yes, that's the obvious suspects, of course. But I'm not sure I would > say they brought polymorphism (assuming that's what is meant by "higher > order types") to Haskell. Not in the same way Wadler and co. brought > type classes, quite specifically, to Haskell. By "higher order types", I meant the type of runST (ST monad), or dpSwich (in yampa). I meant things like "(forall a, a-> b) -> a -> b", and maybe existential types as well. But now you mention it, I don't know who came up with mere parametric polymorphism. (Hindley, Damas, Milner?) Anyway, thanks for the names (now I have more papers to swallow :-). Loup From voigt at tcs.inf.tu-dresden.de Wed Apr 2 05:01:38 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Wed Apr 2 04:57:35 2008 Subject: [Haskell-cafe] Re: FW: Haskell In-Reply-To: <6f9f8f4a0804020126ye6e724cvb023b127e5b65198@mail.gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> <804685025.20080401150254@gmail.com> <6f9f8f4a0804010619h5da8fc27kf1992d779920c95@mail.gmail.com> <47F2389A.4060903@tcs.inf.tu-dresden.de> <47F330F6.9010808@tcs.inf.tu-dresden.de> <6f9f8f4a0804020126ye6e724cvb023b127e5b65198@mail.gmail.com> Message-ID: <47F34B72.6030301@tcs.inf.tu-dresden.de> Loup Vaillant wrote: > By "higher order types", I meant the type of runST (ST monad), > or dpSwich (in yampa). I meant things like > "(forall a, a-> b) -> a -> b" That's then usually called "higher-rank polymorphic types", just in case you need more keywords for literature search ;-) -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From lemming at henning-thielemann.de Wed Apr 2 05:22:31 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Apr 2 05:27:33 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> Message-ID: On Tue, 1 Apr 2008, Hans Aberg wrote: > On 1 Apr 2008, at 12:40, PR Stanley wrote: > > Why can't we have function application implemented outwardly > > (inside-out). So > > f g x would be applied with > > gx first followed by its return value passed to f instead of > > putting g x in brackets. > > It seems me it may come from an alteration of math conventions: > Normally (x) = x, and function application is written as f(x), except > for a few traditional names, like for example sin x. So if one > reasons that f(x) can be simplified to f x, then f g x becomes short > for f(g)(x) = (f(g))(x). In functional analysis you write e.g. D f(x) meaning (D f)(x) not D(f(x)), so I wouldn't say there is any convention of precedence of function application in mathematics. Even more, in functional analysis it is common to omit the parentheses around operator arguments, and since there are a lot of standard functions like 'sin', I wouldn't say that using argument parentheses is more common than omitting them. (Btw. in good old ZX Spectrum BASIC it was also allowed to omit argument parentheses.) From haberg at math.su.se Wed Apr 2 05:59:57 2008 From: haberg at math.su.se (Hans Aberg) Date: Wed Apr 2 05:57:39 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> Message-ID: <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> On 2 Apr 2008, at 11:22, Henning Thielemann wrote: >> It seems me it may come from an alteration of math conventions: >> Normally (x) = x, and function application is written as f(x), except >> for a few traditional names, like for example sin x. So if one >> reasons that f(x) can be simplified to f x, then f g x becomes short >> for f(g)(x) = (f(g))(x). > > In functional analysis you write e.g. D f(x) meaning (D f)(x) not D > (f(x)), > so I wouldn't say there is any convention of precedence of function > application in mathematics. When I take a quick look into H?rmander's book on distributions, then he writes (D f)(phi), and not D f(phi). So there might be a difference between math that is drawn towards pure or applied math. > Even more, in functional analysis it is common > to omit the parentheses around operator arguments, and since there > are a > lot of standard functions like 'sin', ... I think that in RTL, one do that as well: x tau, instead of (x)tau. > ...I wouldn't say that using argument > parentheses is more common than omitting them.(Btw. in good old ZX > Spectrum BASIC it was also allowed to omit argument parentheses.) Math usage is probably in minority these days. As I noted, looking into books on axiomatic set theory, one construct tuplets it so that (x) = x. So it seems possible, although for function application f(z) seems the normal notation. But one should also be able to write (f+g)(x). - This does not work in Haskell, because Num requires an instance of Eq and Show. Hans From jerzy.karczmarczuk at info.unicaen.fr Wed Apr 2 07:51:59 2008 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Wed Apr 2 07:47:56 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> Message-ID: Hans Aberg writes: ... > But one should also be able to write (f+g)(x). - This does not work in > Haskell, because Num requires an instance of Eq and Show. So, declare them, even if they are vacuous. I did it several times, I am still alive, so no need to say "this does not work". Jerzy Karczmarczuk From haberg at math.su.se Wed Apr 2 08:14:27 2008 From: haberg at math.su.se (Hans Aberg) Date: Wed Apr 2 08:10:27 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> Message-ID: On 2 Apr 2008, at 13:51, jerzy.karczmarczuk@info.unicaen.fr wrote: >> But one should also be able to write (f+g)(x). - This does not >> work in Haskell, because Num requires an instance of Eq and Show. > > So, declare them, even if they are vacuous. I did it several times, > I am > still alive, so no need to say "this does not work". That is possible, of course - I did that, too. But it means that the syntax and semantics do not work together; an invitation to pitfalls. So this ought to be avoided, except if there are no other workarounds. It would be better to write a new Prelude. :-) Hans From jerzy.karczmarczuk at info.unicaen.fr Wed Apr 2 08:27:31 2008 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Wed Apr 2 08:23:29 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> Message-ID: Hans Aberg comments my remark to his observation: >>> But one should also be able to write (f+g)(x). - This does not work in >>> Haskell, because Num requires an instance of Eq and Show. >> >> So, declare them, even if they are vacuous. I did it several times, I am >> still alive, so no need to say "this does not work". > > That is possible, of course - I did that, too. But it means that the > syntax and semantics do not work together; an invitation to pitfalls. So > this ought to be avoided, except if there are no other workarounds. I am more tolerant. The question - for me - is not an interplay between syntax and semantics, syntax here is irrelevant, the fact that (+) is a popular infix operator plays no role. The calamity comes from the fact that it is not possible to write serious and "natural" instances of Eq and Show for functions, and that for God knows which reasons, the Num instance demands them ! This requirement is not rational, although intuitive. But I violated it several times, when I needed arithmetic for lazy infinite objects... So, I can't say that this should be avoided. I don't see "obvious" pitfalls therein. > It would be better to write a new Prelude. :-) Oh, yes, our common dream... Jerzy Karczmarczuk From haberg at math.su.se Wed Apr 2 09:16:51 2008 From: haberg at math.su.se (Hans Aberg) Date: Wed Apr 2 09:12:54 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> Message-ID: On 2 Apr 2008, at 14:27, jerzy.karczmarczuk@info.unicaen.fr wrote: >> That is possible, of course - I did that, too. But it means that >> the syntax and semantics do not work together; an invitation to >> pitfalls. So this ought to be avoided, except if there are no >> other workarounds. > > I am more tolerant. The pragmatics is to decide whether to program Haskell, or making a new language. I am interested in the latter, but realistically nobody will singly be able prdocue the programingg capacity that the now mature Haskell has. > The question - for me - is not an interplay between > syntax and semantics, ... That interplay, between notation and notions, is very important in math, as if the do not flow together, one will not be able to describe very complex logical structures. > ...syntax here is irrelevant, the fact that (+) is a > popular infix operator plays no role. The calamity comes from the > fact that > it is not possible to write serious and "natural" instances of Eq and > Show for functions, ... A correct Eq would require a theorem prover. Show could be implemented by writing out the function closures, but I think the reason it is not there is that it would create overhead in compiled code. > ...and that for God knows which reasons, the Num instance > demands them ! This requirement is not rational, although intuitive. Probably pragmatics. More general implementations were not considered at the time. > But > I violated it several times, when I needed arithmetic for lazy > infinite > objects... So, I can't say that this should be avoided. I don't see > "obvious" pitfalls therein. The pitfall is when somebody which does not know the code well tries to use it. Define a library with false = True true = False Perfectly logical, but it will be thwarted by peoples expectations. >> It would be better to write a new Prelude. :-) > > Oh, yes, our common dream... Such changes will require a new standard. Haskell seems rather fixed, so it will perhaps then happen in a new language. :-) Hans From haberg at math.su.se Wed Apr 2 09:47:20 2008 From: haberg at math.su.se (Hans Aberg) Date: Wed Apr 2 09:43:21 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> Message-ID: <21F4B14D-6539-46B4-9F64-C4A3CD5D553F@math.su.se> On 2 Apr 2008, at 14:27, jerzy.karczmarczuk@info.unicaen.fr wrote: >> It would be better to write a new Prelude. :-) > > Oh, yes, our common dream... One may not need to write a wholly new Prelude, by something like: module NewPrelude where import Prelude hiding -- Num, (+). class AdditiveSemiMonoid a where (+) :: a -> a -> a ... class (Eq a, Show a, AdditiveSemiMonoid a) => Num a where (+) :: a -> a -> a -- Stuff of Prelude using Num. Then import NewPrelude instead, and instance AdditiveSemiMonoid (a -> b) where f + g = \x -> f(x) + g(x) or something. Hans From loup.vaillant at gmail.com Wed Apr 2 10:20:10 2008 From: loup.vaillant at gmail.com (Loup Vaillant) Date: Wed Apr 2 10:16:07 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: <21F4B14D-6539-46B4-9F64-C4A3CD5D553F@math.su.se> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> <21F4B14D-6539-46B4-9F64-C4A3CD5D553F@math.su.se> Message-ID: <6f9f8f4a0804020720t72785b35wcb8f20d69b783be6@mail.gmail.com> 2008/4/2, Hans Aberg : > On 2 Apr 2008, at 14:27, jerzy.karczmarczuk@info.unicaen.fr > wrote: > > > > It would be better to write a new Prelude. :-) > > > > Oh, yes, our common dream... > > One may not need to write a wholly new Prelude, by something like: > > module NewPrelude where > > import Prelude hiding -- Num, (+). > > class AdditiveSemiMonoid a where > (+) :: a -> a -> a Err, why *semi* monoid? Plain "monoid" would not be accurate? While we're at it, what about adding even more classes, like "group" or "ring"? Algebra in a whole class hierachy. :-) Loup From haberg at math.su.se Wed Apr 2 10:27:12 2008 From: haberg at math.su.se (Hans Aberg) Date: Wed Apr 2 10:23:14 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: <6f9f8f4a0804020720t72785b35wcb8f20d69b783be6@mail.gmail.com> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> <21F4B14D-6539-46B4-9F64-C4A3CD5D553F@math.su.se> <6f9f8f4a0804020720t72785b35wcb8f20d69b783be6@mail.gmail.com> Message-ID: <7D7FCCF6-716A-4D59-9AB8-4DE8B34CCCEC@math.su.se> On 2 Apr 2008, at 16:20, Loup Vaillant wrote: >> class AdditiveSemiMonoid a where >> (+) :: a -> a -> a > > Err, why *semi* monoid? Plain "monoid" would not be accurate? A monoid has a unit: class (AdditiveSemiMonoid a) => AdditiveMonoid a where o :: a The semimonoid is also called semigroup, I think. > > While we're at it, what about adding even more classes, like "group" > or "ring"? Algebra in a whole class hierachy. :-) Only ambition required :-). It is probably easier to make a copy of Prelude.hs to say NewPrelude.hs, and modify it directly, by inserting intermediate classes. Hans From allbery at ece.cmu.edu Wed Apr 2 10:30:12 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Apr 2 10:26:11 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: <7D7FCCF6-716A-4D59-9AB8-4DE8B34CCCEC@math.su.se> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> <21F4B14D-6539-46B4-9F64-C4A3CD5D553F@math.su.se> <6f9f8f4a0804020720t72785b35wcb8f20d69b783be6@mail.gmail.com> <7D7FCCF6-716A-4D59-9AB8-4DE8B34CCCEC@math.su.se> Message-ID: On Apr 2, 2008, at 10:27 , Hans Aberg wrote: > On 2 Apr 2008, at 16:20, Loup Vaillant wrote: >>> >> While we're at it, what about adding even more classes, like "group" >> or "ring"? Algebra in a whole class hierachy. :-) > > Only ambition required :-). http://www.haskell.org/haskellwiki/Mathematical_prelude_discussion --- go nuts. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From haberg at math.su.se Wed Apr 2 11:54:13 2008 From: haberg at math.su.se (Hans Aberg) Date: Wed Apr 2 11:50:19 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> <21F4B14D-6539-46B4-9F64-C4A3CD5D553F@math.su.se> <6f9f8f4a0804020720t72785b35wcb8f20d69b783be6@mail.gmail.com> <7D7FCCF6-716A-4D59-9AB8-4DE8B34CCCEC@math.su.se> Message-ID: On 2 Apr 2008, at 16:30, Brandon S. Allbery KF8NH wrote: >>> While we're at it, what about adding even more classes, like "group" >>> or "ring"? Algebra in a whole class hierachy. :-) >> >> Only ambition required :-). > > http://www.haskell.org/haskellwiki/Mathematical_prelude_discussion > --- go nuts. There is a Math Prelude, but perhaps one can simplify and divide into parts that refines the current Prelude, and stuff built on top of a refined Prelude. The problem with the current one is that for example Num claims (+), insists on Eq and Show, and there is no way to get rid of those requirements. So inserting some classes, like AdditiveSemiMonoid would be less ambitious than writing a whole new algebra oriented Prelude. Perhaps a better chance of success. Hans From martindemello at gmail.com Wed Apr 2 13:21:36 2008 From: martindemello at gmail.com (Martin DeMello) Date: Wed Apr 2 13:17:35 2008 Subject: [Haskell-cafe] FW: Haskell In-Reply-To: <47F2BA1A.4020706@imageworks.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> <47F2BA1A.4020706@imageworks.com> Message-ID: On Tue, Apr 1, 2008 at 3:41 PM, Dan Weston wrote: > Nor did I use to take > perfectly working code and refactor it until it cried for mercy, and then > stay awake wondering if there was some abstraction out there I was missing > that would really make it sing. I find myself doing this in Scheme and Ruby too - it's actually one of my rules-of-thumb for picking languages that I'd like to invest in. martin From dpiponi at gmail.com Wed Apr 2 15:46:53 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Wed Apr 2 15:42:50 2008 Subject: [Haskell-cafe] Re: Function Precedence In-Reply-To: <7.0.1.0.0.20080401220510.01d5cec0@ntlworld.com> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <14d615330804010350x46c549b9r668c79c997902a7c@mail.gmail.com> <7.0.1.0.0.20080401212332.01d57e38@ntlworld.com> <7.0.1.0.0.20080401220510.01d5cec0@ntlworld.com> Message-ID: <625b74080804021246i71c90e2cgbb39b2ff8594f761@mail.gmail.com> On Tue, Apr 1, 2008 at 2:07 PM, PR Stanley wrote: > All you'd have to do is to give the inner most function the highest > precdence What's the innermost function in "f g x" here? test :: (a -> b -> c) -> a -> b -> c test f g x = f g x -- Dan From loup.vaillant at gmail.com Wed Apr 2 16:13:28 2008 From: loup.vaillant at gmail.com (Loup Vaillant) Date: Wed Apr 2 16:09:40 2008 Subject: [Haskell-cafe] Re: Function Precedence In-Reply-To: <625b74080804021246i71c90e2cgbb39b2ff8594f761@mail.gmail.com> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <14d615330804010350x46c549b9r668c79c997902a7c@mail.gmail.com> <7.0.1.0.0.20080401212332.01d57e38@ntlworld.com> <7.0.1.0.0.20080401220510.01d5cec0@ntlworld.com> <625b74080804021246i71c90e2cgbb39b2ff8594f761@mail.gmail.com> Message-ID: <6f9f8f4a0804021313i510819akbe113a7f6160d5d3@mail.gmail.com> 2008/4/2, Dan Piponi : > On Tue, Apr 1, 2008 at 2:07 PM, PR Stanley wrote: > > All you'd have to do is to give the inner most function the highest > > precdence > > > What's the innermost function in "f g x" here? > > test :: (a -> b -> c) -> a -> b -> c > test f g x = f g x g (if I followed correctly). But we have a problem: If I want f g x to be parsed as f (g x), I would probably want, f g x y to be parsed as f (g x y), considering g as the innermost function, again. I'm almost certain that it would render type inference impossible, and maybe partial application as well. (id 4 is a total application, but id (\x -> x+1) is a partial one...) The only choices left are right associativity or left associativity. Loup From simonpj at microsoft.com Wed Apr 2 17:06:25 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Apr 2 17:02:22 2008 Subject: [Haskell-cafe] Template Haskell -- when are things evaluated? In-Reply-To: <6a7c66fc0803130649u14f85224kf13f904b4bfdfb26@mail.gmail.com> References: <47D8DF1E.4070909@cs.chalmers.se> <6a7c66fc0803130149n6b452127l390563e96d65ccf5@mail.gmail.com> <47D8FE66.6020108@cs.chalmers.se> <6a7c66fc0803130649u14f85224kf13f904b4bfdfb26@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32ABA0485FE@EA-EXMSG-C334.europe.corp.microsoft.com> | > I'm reading the following rule from your answer: | > | > [|exp|] normally returns the unevaluated AST of exp. However, if exp | contains | > local variables, these are lifted using Language.Haskell.TH.lift (i.e. | evaluated | > before lifting). | > | > Is that correct? | > | > | > / Emil | | Yes, that seems to be true. I'm not an expert in the internals of TH | though, so I have inferred that rule by extensive use of TH ;). | | SPJ can confirm if it's right. Sorry, been busy with the ICFP deadline. I think you are asking this: module M(f) where f :: Int -> Q Exp f x = let expensive :: Int -> Int expensive p = p*p + x*x in let y = expensive x in [| y+1 |] module Test where import M test n = n + $(f 4) When compiling module Test, TH will evaluate (f 4), returning a syntax tree which it will splice in place of the call $(f 4). What expression will it return? Two candidates: $(f 4) --> 24+1 $(f 4) --> expensive 4 + 1 In TH you get the former, which is I think what you understood. Why? Apart from anything else, 'expensive' isn't even in scope in module Test -- it was a local binding inside the invocation of f. Second, this is partly what staging is about; you get to specify when you want things to be done. If you want the splice to contain the call to expensive (rather than its result), you'll need to float out expensive to the top level (which means lambda-lifting). And then you can say this: expensive :: Int -> Int -> Int expensive x p = p*p + x*x f :: Int -> Q Exp f x = let y = [| expensive x x |] in [| $y+1 |] By putting the call in a quote we delay its evaluation. If someone felt like transcribing this little thread into a FAQ-like thing on the GHC user wiki (I'm disconnected at the moment) that would be a fine thing to do. Thanks. Simon From porrifolius at gmail.com Wed Apr 2 17:22:37 2008 From: porrifolius at gmail.com (porrifolius) Date: Wed Apr 2 17:18:40 2008 Subject: [Haskell-cafe] Role based access control via monads or arrows or... something Message-ID: <200804031022.38072.porrifolius@gmail.com> Hello. I've been playing around trying to write a framework to support/enforce access control to resources. So far my efforts have yielded little but bruised forehead and compressed plaster-board. What I'd like is a solution that: (1) prevents access to resources except via a fine-grained permissions checking gateway (2) supports on-the-fly permissions eg Bob can see Fred's salary (3) supports dynamic role constraints eg Bob can't be both appointor and appointee of secret agent status (4) allows lack of permission to optionally act as a filter rather than cause an abort, eg Bob viewing all salaries returns Fred's but doesn't return Tom's rather than aborting altogether because Bob lacks the permission over Tom (5) well defined behaviour when checking permissions for actions that change permissions (6) it must be pure, no need for IO. (7) ideally required permissions would appear (and accumulate) in type signatures via inference so application code knows which are required and type checker can reject static/dynamic role constraint violations I've attempted a solution using arrows based loosely upon ideas in [1] and [2]. I can't figure out how to make it work, even if I did get it working I now suspect it can be done far more simply, and I don't think it could ever provide feature (7). For what it's worth it's attached. Ideally you kind folk could help me come up with a type-level solution to satisfy (7), so you could have something like: deptAveSal :: (HasPerms subject? Read Salary [person]?, HasPerm subject? Read Employees dept?, HasRole subject? Manager dept?) => Department -> Salary Failing that how to do it in a more simple fashion? I now think that a State-like monad exposing only functions taking values in a wrapper type that carries required permissions may be sufficient, but still probably couldn't satisfy (7). Failing that my existing attempt has me stumped for a few reasons: how do I get hold of the subject and resource so I can build the correct permission in Test? eg the Person whose Salary is needed in salary, and who's trying to get it where do I get the System from in Test? eg fakeSystem in personByName how to implement the filter functionality in RBAC? Parametric over container types? I think that perhaps the Validator would need to be a monad that holds the initial state of the System to provide a stable set of permissions/roles and that the subject and System should also be threaded through the arrows for use/modification. Any help you can offer for my aching cranium will be _much_ appreciated. Thanks. [1] Encoding Information Flow in Haskell - Peng Li, Steve Zdancewic. http://www.seas.upenn.edu/~lipeng/homepage/flowarrow.html [2] A Library for Secure Multi-threaded Information Flow in Haskell - Alejandro Russo, Tsa-chung Tsai, John Hughes. http://www.cs.chalmers.se/~russo/publications.html -------------- next part -------------- A non-text attachment was scrubbed... Name: RBAC.hs Type: text/haskell Size: 2742 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080403/e06534c4/RBAC-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Test.hs Type: text/haskell Size: 1625 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080403/e06534c4/Test-0001.bin From michael at schmong.org Wed Apr 2 19:12:16 2008 From: michael at schmong.org (michael@schmong.org) Date: Wed Apr 2 19:08:16 2008 Subject: [Haskell-cafe] installing ghc-6.8.2 Message-ID: <20080402231216.GB31117@schmong.org> It seems there is no ghc 6.8.2 for my version of debian. So I am compiling from source. I ran config with no problem. make generated some errors. I omit all output except the end. Let me know if Ileft something important out please. make all /usr/bin/ghc -H16m -O -w -I. -Iinclude -Rghc-timing -ignore-package Cabal -ignore-package filepath -I../libraries -fglasgow-exts -no-recomp -c System/FilePath/Posix.hs -o System/FilePath/Posix.o -ohi System/FilePath/Posix.hi cc1: error: unrecognized option `-fno-unit-at-a-time' <> make[2]: *** [System/FilePath/Posix.o] Error 1 make[1]: *** [boot] Error 2 make: *** [stage1] Error 1 so it's this line that seems of the most interesting cc1: error: unrecognized option `-fno-unit-at-a-time' any tips on how to deal with this would be most helpful. Michael Litchard From igloo at earth.li Wed Apr 2 19:29:51 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Apr 2 19:25:48 2008 Subject: [Haskell-cafe] SYB with class: Bug in Derive.hs module In-Reply-To: References: Message-ID: <20080402232951.GA9864@matrix.chaos.earth.li> On Mon, Mar 31, 2008 at 03:47:04PM +0200, Alexey Rodriguez Yakushev wrote: > > The Data instance that Derive generates is as follows: > > > instance (Data ctx a, > > Data ctx (BinTree a), > > Sat (ctx (BinTree a))) => > > Data ctx (BinTree a) where > > Note the recursive |Data ctx (BinTree a)| in the context. This looks like it is related to these tickets: http://hackage.haskell.org/trac/ghc/ticket/1470 http://hackage.haskell.org/trac/ghc/ticket/1735 Thanks Ian From igloo at earth.li Wed Apr 2 19:50:46 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Apr 2 19:46:42 2008 Subject: [Haskell-cafe] installing ghc-6.8.2 In-Reply-To: <20080402231216.GB31117@schmong.org> References: <20080402231216.GB31117@schmong.org> Message-ID: <20080402235046.GA10143@matrix.chaos.earth.li> On Wed, Apr 02, 2008 at 07:12:16PM -0400, michael@schmong.org wrote: > > so it's this line that seems of the most interesting > > cc1: error: unrecognized option `-fno-unit-at-a-time' It looks like your version of ghc isn't designed to be used with the version of gcc you have. Putting this in mk/build.mk ought to let the build go through: SRC_HC_OPTS = -fasm GhcStage1HcOpts = -fasm Thanks Ian From lennart at augustsson.net Wed Apr 2 20:40:07 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Apr 2 20:36:02 2008 Subject: [Haskell-cafe] Re: FW: Haskell In-Reply-To: <47F330F6.9010808@tcs.inf.tu-dresden.de> References: <638ABD0A29C8884A91BC5FB5C349B1C32AB9FA8B7B@EA-EXMSG-C334.europe.corp.microsoft.com> <804685025.20080401150254@gmail.com> <6f9f8f4a0804010619h5da8fc27kf1992d779920c95@mail.gmail.com> <47F2389A.4060903@tcs.inf.tu-dresden.de> <47F330F6.9010808@tcs.inf.tu-dresden.de> Message-ID: Mark Jones brought higher order polymorphism to Haskell. On Wed, Apr 2, 2008 at 8:08 AM, Janis Voigtlaender < voigt@tcs.inf.tu-dresden.de> wrote: > apfelmus wrote: > > > Janis Voigtlaender wrote: > > > > Loup Vaillant wrote: > > > > > > Thanks to some geniuses (could someone name them?), we have type > > > > classes and higher order types in Haskell (and even more). > > > > > > > > > > > > > As far as names go: > > > > > > .... for type classes, of course Wadler, but also Blott and Kaes. > > > > > > .... for higher order types, well, where to start? > > > > > > > > > Girard and Reynolds? > > > > Yes, that's the obvious suspects, of course. But I'm not sure I would > say they brought polymorphism (assuming that's what is meant by "higher > order types") to Haskell. Not in the same way Wadler and co. brought > type classes, quite specifically, to Haskell. > > -- > Dr. Janis Voigtlaender > http://wwwtcs.inf.tu-dresden.de/~voigt/ > mailto:voigt@tcs.inf.tu-dresden.de > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080403/92832e84/attachment.htm From michael at schmong.org Wed Apr 2 20:45:14 2008 From: michael at schmong.org (michael@schmong.org) Date: Wed Apr 2 20:41:10 2008 Subject: [Haskell-cafe] installing ghc-6.8.2 In-Reply-To: <20080402235046.GA10143@matrix.chaos.earth.li> References: <20080402231216.GB31117@schmong.org> <20080402235046.GA10143@matrix.chaos.earth.li> Message-ID: <20080403004514.GB16483@schmong.org> Apologies to Ian, I think I sent him direct mail on my first attempt to reply. Adding those lines to mk/build.mk did not work. I hope Idon't have to build a newer gcc. This is what I have right now. michael@schmong:~/src/gcc$ gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.5 (Debian 1:3.3.5-13) On Thu, Apr 03, 2008 at 12:50:46AM +0100, Ian Lynagh wrote: > On Wed, Apr 02, 2008 at 07:12:16PM -0400, michael@schmong.org wrote: > > > > so it's this line that seems of the most interesting > > > > cc1: error: unrecognized option `-fno-unit-at-a-time' > > It looks like your version of ghc isn't designed to be used with the > version of gcc you have. > > Putting this in mk/build.mk ought to let the build go through: > > SRC_HC_OPTS = -fasm > GhcStage1HcOpts = -fasm > > > Thanks > Ian From lrpalmer at gmail.com Wed Apr 2 20:45:49 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Wed Apr 2 20:41:44 2008 Subject: [Haskell-cafe] Role based access control via monads or arrows or... something In-Reply-To: <200804031022.38072.porrifolius@gmail.com> References: <200804031022.38072.porrifolius@gmail.com> Message-ID: <7ca3f0160804021745p48edeac0x606416ce0af1e7d3@mail.gmail.com> 2008/4/2 porrifolius : > (7) ideally required permissions would appear (and accumulate) in type > signatures via inference so application code knows which are required and > type checker can reject static/dynamic role constraint violations If you mean what I think you mean by "dynamic", that these are runtime permissions, then you're not going to get the type checker to check them... of course. What did you mean by dynamic? > I've attempted a solution using arrows based loosely upon ideas in [1] and > [2]. I can't figure out how to make it work, even if I did get it working I > now suspect it can be done far more simply, and I don't think it could ever > provide feature (7). For what it's worth it's attached. > > Ideally you kind folk could help me come up with a type-level solution to > satisfy (7), so you could have something like: > deptAveSal :: (HasPerms subject? Read Salary [person]?, HasPerm subject? Read > Employees dept?, HasRole subject? Manager dept?) => Department -> Salary What comes to mind is that you could pass proofs around which represent required permissions. The hard part is coming up with a data type algebra for expressing your "theorems" (permission requirements). If you want a rich system of permissions, it's pretty unlikely that you'll get inference. data HasRole role dept = HasRole -- do not expose this constructor data HasPerm perm obj dept = HasPerm -- nor this one class Department d where deptAveSal :: (Department dept) => HasPerm ReadPerm Employees dept -> HasRole ManagerRole dept -> dept -> Salary And then dole out HasRoles and HasPerms through your module interface. However, I'm pretty sure any solution to (7) will be unsatisfactory to you, considering your long list of requirements. Haskell's type system is not SQL, it will have a hard time supporting these things. If you're interested in programming with type-safe permissions you might want to look into dependent types (Epigram, Agda 2), but those languages are not what you would consider "mature" or "fast" (it takes 1 second to verify that 113 is prime in Agda 2... now you see what I mean?). It would be an academic exercise. Here's my ill-informed advice (since I don't know what problem you're trying to solve, only what solution you want to have): Forget (7), stay away from arrows for this, and avoid overengineering (this kind of problem especially likes to attract overengineers). My hunch is that you only need two things: a data type witnessing a permission. That is, don't worry about the subject? stuff; if the program can get its hands on a witness of a permission, then it has that permission. I would start with KISS, just a plain unparameterized data type: -- keep this type abstract and do not expose the constructors data Perm = ReadSalaryPermission Employee | ... And then maybe introduce separation and type parameters as you start to use them and see where the logical boundaries are. Of the possible ways you can put this into a monad, I would say "Access t" is a computation which results in a value of type t after receiving witnesses of required permissions. I considered: data Access a = Access { value :: a, required :: Set Perm } But I like to avoid ad-hoc checks like this and actually put the checks right in the code. newtype Access' a = Access' (Set Perm -> Maybe a) Or: data Access'' a = Result a | NeedPermissions (Set PermSpec) (Set Perm -> Access'' a) Or something like that. Let the computation figure out how to verify the permissions. Notice how Perm and PermSpec are different in the last example, because of the witness model. You don't want to give someone the permissions to do something when you're just trying to tell them what permissions they need. In particular, though, there is nothing arrow-like about this problem. Arrows abstract the notion of function, and this problem is all about values. Luke From jgoerzen at complete.org Wed Apr 2 21:17:21 2008 From: jgoerzen at complete.org (John Goerzen) Date: Wed Apr 2 21:13:24 2008 Subject: [Haskell-cafe] ANN: hdbc-odbc 1.1.4.1 Message-ID: <200804022017.21765.jgoerzen@complete.org> Hi folks, HDBC-ODBC 1.1.4.1 has been uploaded to http://software.complete.org/hdbc-odbc and to Hackage. Bryn Keller reported a build problem on Windows with GHC 6.8.x, which has been fixed. -- John From lemming at henning-thielemann.de Thu Apr 3 01:59:32 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Apr 3 01:54:11 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> Message-ID: On Wed, 2 Apr 2008, Hans Aberg wrote: > But one should also be able to write (f+g)(x). - This does not work in > Haskell, because Num requires an instance of Eq and Show. You could define these instances with undefined function implementations anyway. But also in a more cleaner type hierarchy like that of NumericPrelude you should not define this instance, because it would open new surprising sources of errors: http://www.haskell.org/haskellwiki/Num_instance_for_functions From lemming at henning-thielemann.de Thu Apr 3 02:07:18 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Apr 3 02:02:18 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> Message-ID: On Wed, 2 Apr 2008, Hans Aberg wrote: > Show could be implemented by writing out the function closures, but I > think the reason it is not there is that it would create overhead in > compiled code. It would also not give referential transparent answers, because the same function can be implemented in different ways: http://www.haskell.org/haskellwiki/Show_instance_for_functions From haberg at math.su.se Thu Apr 3 04:19:36 2008 From: haberg at math.su.se (Hans Aberg) Date: Thu Apr 3 04:15:49 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> Message-ID: <25B66FFC-7C33-49BD-9C63-7A05A46A9487@math.su.se> On 3 Apr 2008, at 07:59, Henning Thielemann wrote: >> But one should also be able to write (f+g)(x). - This does not >> work in Haskell, because Num requires an instance of Eq and Show. > > You could define these instances with undefined function > implementations anyway. But also in a more cleaner type hierarchy > like that of NumericPrelude you should not define this instance, > because it would open new surprising sources of errors: > http://www.haskell.org/haskellwiki/Num_instance_for_functions This problem is not caused by defining f+g, but by defining numerals as constants. In some contexts is natural to let the identity be written as 1, and then 2 = 2*1 is not a constant. With this definition, a (unitary) ring may be identified with an additive category with only one object. In mathematical terms, the set of functions is a (math) module ("generalized vectorspace"), not a ring. Anyway, Num is a type for unifying some common computer numerical types, and not for doing algebra. If its (+) is derived from an additive monoid (or magma) type, then defining f+g will not interfere with Num. Hans From haberg at math.su.se Thu Apr 3 04:51:18 2008 From: haberg at math.su.se (Hans Aberg) Date: Thu Apr 3 04:47:17 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> Message-ID: <1A3A60D3-CB5A-4E3B-B27F-4471EA8234E8@math.su.se> On 3 Apr 2008, at 08:07, Henning Thielemann wrote: >> Show could be implemented by writing out the function closures, >> but I think the reason it is not there is that it would create >> overhead in compiled code. > > It would also not give referential transparent answers, because the > same function can be implemented in different ways: > http://www.haskell.org/haskellwiki/Show_instance_for_functions You can define scalars as constant functions, making the set of functions into a ring, and then implicit multiplication would not work. The way I view implicit multiplication though, is as an abbreviation of the explicit multiplication. So from that point of view, it is no stranger than other notational simplifications that may or may not take place, for example the use of parenthesizes. So if one defines scalars as constants, one will have accept that implicit multiplication cannot take place. But that should not be a problem in Haskell, as it does not admit that anyway: one knows that x (y) always is function application. Anyway, in math, the context may change. So sometimes it may be useful to let a number r denote a constant function, but if r is in a ring R, the it may be useful to let it denote the function that is multiplication of r. Now in a computer language, the problem is to avoid setting one such possibility in stone at fundamental level so that by that it excludes the other variations. Hans From Ben.Lippmeier at anu.edu.au Thu Apr 3 05:58:33 2008 From: Ben.Lippmeier at anu.edu.au (Ben Lippmeier) Date: Thu Apr 3 05:54:29 2008 Subject: [Haskell-cafe] Typing with co/contra-variance. Message-ID: <47F4AA49.2050004@anu.edu.au> Hi all, I have some quick questions for the type theory people: If I write an expression: (if .. then 23 else "Erk") In Haskell this would be an error, but perhaps I can assign it the type 'Top' (or 'Any') and then use reflection ala Data.Dynamic to inspect the type of this object at runtime and cast it back to something useful... But if I write: isEven "Erk" where isEven :: Int -> Bool isEven i = case i of 1 -> False 2 -> True ... Then this would be a genuine type error, because the case-expression demands an actual Int at runtime. Questions: 1) Could I perhaps wave my arms around and say something about the Int in the type of isEven being in a contra-variant position? Is this what is actually happening?, and can someone point me to a good paper? 2) This seems simpler than real intersection types, which I know are problematic. If I only want 'Top' and not a real object system like in Scala or Java, then can I just add this to a HM/unification style inference algorithm and expect it to work? I'm thinking the unifier only needs to know the variance of the types it's unifying to decide whether to throw an error or return Top - or will there be problems with higher order functions etc? I had a read through the subtyping chapter in "Types and Programming Languages" by Pierce - it gives the typing rules but don't mention inference or implementations. Scala seems to have this (http://www.scala-lang.org/intro/variances.html) but as I understand it, their system doesn't support full type inference without user supplied annotations... BTW: searching for 'the any type' in Google helps even less than you might expect :) Thanks, Ben. From jinwoo68 at gmail.com Thu Apr 3 06:03:30 2008 From: jinwoo68 at gmail.com (Jinwoo Lee) Date: Thu Apr 3 05:59:24 2008 Subject: [Haskell-cafe] Doing without IORef Message-ID: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> Hi, Recently I wrote a code that uses readline library (System.Console.Readline). I had to maintain a state (file path) and do IO throughout the code, so I decided to use StateT monad. The problem was that in order to retrieve the current state (file path) inside the handler that had been registered by using bindKey function of readline, I had to resort back to using IORef rather than using the state stored in the StateT monad. It's because the handler for bindKey should have the type of Int -> Char -> IO Int. Here is my code snippet. type MyState a = StateT FilePath IO a rootDir :: FilePath rootDir = "/root/" main :: IO () main = do hSetBuffering stdout NoBuffering execStateT (do pwd <- get pwdRef <- lift $ newIORef pwd lift $ bindKey '\t' (tabHandler pwdRef) lift $ bindKey '\^L' ctlLHandler commandLoop pwdRef) rootDir return () tabHandler :: IORef FilePath -> Int -> Char -> IO Int tabHandler pwdRef _ _ = do *pwd <- readIORef pwdRef* insertText pwd return 0 ... commandLoop :: IORef FilePath -> MyState () commandLoop pwdRef = commandLoop' where commandLoop' = do pwd <- get *lift $ writeIORef pwdRef pwd* maybeLine <- lift $ readline $ makePrompt $ dropTrailingPathSeparator pwd case maybeLine of Nothing -> return () Just "exit" -> return () Just line -> do let tokens = words line case tokens of [] -> commandLoop' ("exit":_) -> return () _ -> do lift $ addHistory line processLine tokens commandLoop' ... Is there any way in which I can do without IORef in tabHandler and commandLoop (written in red and bold, if you can see)? Thanks, Jinwoo -- Jinwoo Lee Always remember that you are unique. Just like everyone else. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080403/32876846/attachment.htm From alfonso.acosta at gmail.com Thu Apr 3 06:08:15 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Thu Apr 3 06:04:12 2008 Subject: [Haskell-cafe] Doing without IORef In-Reply-To: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> References: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> Message-ID: <6a7c66fc0804030308q7e065938r6d4e818bbcec0e78@mail.gmail.com> > type MyState a = StateT FilePath IO a > Is there any way in which I can do without IORef in tabHandler and > commandLoop (written in red and bold, if you can see)? How about keeping the IORef but storing it inside the state? type MySate a = StateT (IORef FilePath) IO a From claudiusmaximus at goto10.org Thu Apr 3 06:41:50 2008 From: claudiusmaximus at goto10.org (Claude Heiland-Allen) Date: Thu Apr 3 06:34:30 2008 Subject: [Haskell-cafe] Doing without IORef In-Reply-To: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> References: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> Message-ID: <47F4B46E.1060606@goto10.org> Jinwoo Lee wrote: > Hi, > > Recently I wrote a code that uses readline library > (System.Console.Readline). > I had to maintain a state (file path) and do IO throughout the code, so > I decided to use StateT monad. > > The problem was that in order to retrieve the current state (file path) > inside the handler that had been registered by using bindKey function of > readline, I had to resort back to using IORef rather than using the > state stored in the StateT monad. It's because the handler for bindKey > should have the type of Int -> Char -> IO Int. [snip] > Is there any way in which I can do without IORef in tabHandler and > commandLoop (written in red and bold, if you can see)? Probably not, but this is worth a read if you want to hide the plumbing behind the scenes a bit: "Monadic tunnelling: the art of threading one monad through another" http://www.haskell.org/pipermail/haskell-cafe/2007-July/028501.html Claude -- http://claudiusmaximus.goto10.org From Christian.Maeder at dfki.de Thu Apr 3 08:15:42 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Apr 3 08:11:36 2008 Subject: [Haskell-cafe] Re: installing ghc-6.8.2 In-Reply-To: <20080402231216.GB31117@schmong.org> References: <20080402231216.GB31117@schmong.org> Message-ID: <47F4CA6E.5040701@dfki.de> michael@schmong.org wrote: > It seems there is no ghc 6.8.2 for my version of debian. So I am > compiling from source. this requires a working compiler! > /usr/bin/ghc this compiler does not work with your gcc. if you cannot install http://www.haskell.org/ghc/dist/6.8.2/ghc-6.8.2-i386-unknown-linux.tar.bz2 you'll have to try an older version. > cc1: error: unrecognized option `-fno-unit-at-a-time' Maybe it helps, if your remove this option from your file /lib/ghc-6.8.2/extra-gcc-opts Christian From droundy at darcs.net Thu Apr 3 09:18:13 2008 From: droundy at darcs.net (David Roundy) Date: Thu Apr 3 09:14:06 2008 Subject: [Haskell-cafe] Role based access control via monads or arrows or... something In-Reply-To: <7ca3f0160804021745p48edeac0x606416ce0af1e7d3@mail.gmail.com> References: <200804031022.38072.porrifolius@gmail.com> <7ca3f0160804021745p48edeac0x606416ce0af1e7d3@mail.gmail.com> Message-ID: <20080403131812.GP16717@darcs.net> On Thu, Apr 03, 2008 at 12:45:49AM +0000, Luke Palmer wrote: > 2008/4/2 porrifolius : > > (7) ideally required permissions would appear (and accumulate) in > > type signatures via inference so application code knows which are > > required and type checker can reject static/dynamic role constraint > > violations > > If you mean what I think you mean by "dynamic", that these are runtime > permissions, then you're not going to get the type checker to check > them... of course. What did you mean by dynamic? With GADTs you can certainly get pretty easy compile-time type checking of dynamic constraints. The catch is that GADTs aren't properly integrated with type classes, and this sort of permissions problem may not be expressible without class constraints, in which case the system may require olegish code complexity. At the simplest (and stupidest) level, one could define data CanReadA data CanReadB -- etc data HavePermission perms where HaveAPerm :: HavePermission CanReadA HaveBPerm :: HavePermission CanReadB and if you then restricted access to the constructors of HavePermission, you could write code like data RestrictedData permrequired a = Data a -- constructor obviously not exported, or you'd lose any safety readRestrictedData :: HavePermission perm -> RestrictedData perm a -> a and now if you export readRestrictedData only, then only folks with the proper permissions could access the data (and this could be done at runtime). But this is far from an elegant or satisfactory (or complete) solution. -- David Roundy Department of Physics Oregon State University From cdsmith at twu.net Thu Apr 3 10:07:53 2008 From: cdsmith at twu.net (Chris Smith) Date: Thu Apr 3 10:03:56 2008 Subject: [Haskell-cafe] Re: Function Precedence References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> <25B66FFC-7C33-49BD-9C63-7A05A46A9487@math.su.se> Message-ID: Hans Aberg wrote: > This problem is not caused by defining f+g, but by defining numerals as > constants. Yup. So the current (Num thing) is basically: 1. The type thing is a ring 2. ... with signs and absolute values 3. ... along with a natural homomorphism from Z into thing 4. ... and with Eq and Show. If one wanted to be perfectly formally correct, then each of 2-4 could be split out of Num. For example, 2 doesn't make sense for polynomials or n by n square matrices. 4 doesn't make sense for functions. 3 doesn't make sense for square matrices of dimension greater than 1. And, this quirk about 2(x+y) can be seen as an argument for not wanting it in the case of functions, either. I'm not sure I find the argument terribly compelling, but it is there anyway. On the other hand, I have enough time already trying to explain Num, Fractional, Floating, RealFrac, ... to new haskell programmes. I'm not sure it's an advantage if someone must learn the meaning of an additive commutative semigroup in order to understand the type signatures inferred from code that does basic math in Haskell. At least in the U.S., very few computer science students take an algebra course before getting undergraduate degrees. > In mathematical terms, the set of functions is a (math) module > ("generalized vectorspace"), not a ring. Well, I agree that functions are modules; but it's hard to agree that they are not rings. After all, it's not too difficult to verify the ring axioms. From bulat.ziganshin at gmail.com Thu Apr 3 10:15:17 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Apr 3 10:18:21 2008 Subject: [Haskell-cafe] Re: Function Precedence In-Reply-To: References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> <25B66FFC-7C33-49BD-9C63-7A05A46A9487@math.su.se> Message-ID: <296672245.20080403181517@gmail.com> Hello Chris, Thursday, April 3, 2008, 6:07:53 PM, you wrote: > On the other hand, I have enough time already trying to explain Num, > Fractional, Floating, RealFrac, ... to new haskell programmes. I'm not > sure it's an advantage if someone must learn the meaning of an additive > commutative semigroup in order to understand the type signatures inferred > from code that does basic math in Haskell. At least in the U.S., very > few computer science students take an algebra course before getting > undergraduate degrees. we already need to learn Category Theory to say "Hello, World" :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jerzy.karczmarczuk at info.unicaen.fr Thu Apr 3 10:44:33 2008 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Thu Apr 3 10:40:29 2008 Subject: [Haskell-cafe] Re: Function Precedence In-Reply-To: References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> <25B66FFC-7C33-49BD-9C63-7A05A46A9487@math.su.se> Message-ID: Chris Smith writes: > ... So the current (Num thing) is basically: > > 1. The type thing is a ring > 2. ... with signs and absolute values > 3. ... along with a natural homomorphism from Z into thing > 4. ... and with Eq and Show. > > If one wanted to be perfectly formally correct, then each of 2-4 could be > split out of Num. For example, 2 doesn't make sense for polynomials or n > by n square matrices. 4 doesn't make sense for functions. 3 doesn't > make sense for square matrices of dimension greater than 1. And, this > quirk about 2(x+y) can be seen as an argument for not wanting it in the > case of functions, either. I'm not sure I find the argument terribly > compelling, but it is there anyway. Why "formally correct"?? This is *your* vision. I might say that fromInteger makes sense for square matrices, mapping to a multiple of the unity matrix. 4 makes sense for functions on finite domains. The full Ring property requires a unit, which might not be there "formally". The "absolute value" might be a buzzword for <> which *can* be defined for polynomials. In short, Num is a conventional hybrid, and trying to squeeze it into *any* math formal structure is asking for trouble. > On the other hand, I have enough time already trying to explain Num, > Fractional, Floating, RealFrac, ... to new haskell programmes. > ... At least in the U.S., very > few computer science students take an algebra course before getting > undergraduate degrees. Not only in US. >> In mathematical terms, the set of functions is a (math) module >> ("generalized vectorspace"), not a ring. > > Well, I agree that functions are modules; but it's hard to agree that > they are not rings. After all, it's not too difficult to verify the ring > axioms. Oh. What is the function multiplication? You say: (f*g)(x) = f x * g x ?? I agree. But if you say that the multiplication IS the *composition* (for example for the popular implementation of Peano/Church numerals), then I will also agree. So, there isn't any obvious instance for the function multiplication. (The composition works even if neither "x" nor "f x" belong to any ring). BTW functions "are" or are not members of modules/vector spaces depending on the codomain structure, so this requires a constrained instance specification. Fractional, Floating, etc. are also horrible. Why the square root needs to be floating? It can belong to the algebraic number domain. We can continue this ad infinitum. I cared very much about this stuff some 10 years ago, I gave up... I would like, sure, to have the possibility to derive in Haskell some mathematical subsumptions, e.g., that the ring of integers modulo N becomes a field if N is prime. Or, that every additive group is a module over integers. But it seems that we are very far from such a dream. Jerzy Karczmarczuk From jgoerzen at complete.org Thu Apr 3 10:10:37 2008 From: jgoerzen at complete.org (John Goerzen) Date: Thu Apr 3 11:04:09 2008 Subject: [Haskell-cafe] Re: HDBC, character encoding References: <257E3FFB-EF08-4D64-8AD5-4034A2F2250B@inf.fu-berlin.de> Message-ID: On 2008-04-01, Peter Gammie wrote: > On 31/03/2008, at 11:42 PM, Bjorn Bringert wrote: > >> 2008/3/26 Adrian Neumann : >>> Hi, >>> >>> I wrote a CGI program to access a Postgres database using HDBC. [...] >> >> I think that Peter Gammie (copied) has some code to deal with this. > > I added some stuff to HSQL (not HDBC) and HaskellDB so that UTF8 can > be used to talk to the database. It's not very pretty though, so I > haven't tried to get it merged. Do you have a diff somewhere? I'd be interested in your approach, to see if the same thing would make sense in HDBC. I had generally been of the opinion that HDBC should just pass data through, however it is obtained, and let the programmer set the encoding as desired. If this approach isn't working for people, I'd like to fix it, but want to make sure it's done right. From haberg at math.su.se Thu Apr 3 11:09:36 2008 From: haberg at math.su.se (Hans Aberg) Date: Thu Apr 3 11:05:38 2008 Subject: [Haskell-cafe] Re: Function Precedence In-Reply-To: References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> <25B66FFC-7C33-49BD-9C63-7A05A46A9487@math.su.se> Message-ID: <548BF70B-48C7-4B6E-8B3A-8B531CF1634F@math.su.se> On 3 Apr 2008, at 16:07, Chris Smith wrote: >> This problem is not caused by defining f+g, but by defining >> numerals as >> constants. > > Yup. So the current (Num thing) is basically: > > 1. The type thing is a ring > 2. ... with signs and absolute values > 3. ... along with a natural homomorphism from Z into thing > 4. ... and with Eq and Show. > > If one wanted to be perfectly formally correct, then each of 2-4 > could be > split out of Num. For example, 2 doesn't make sense for > polynomials or n > by n square matrices. Or ordinals. > 4 doesn't make sense for functions. 3 doesn't > make sense for square matrices of dimension greater than 1. And, this > quirk about 2(x+y) can be seen as an argument for not wanting it in > the > case of functions, either. I'm not sure I find the argument terribly > compelling, but it is there anyway. > > On the other hand, I have enough time already trying to explain Num, > Fractional, Floating, RealFrac, ... to new haskell programmes. I'm > not > sure it's an advantage if someone must learn the meaning of an > additive > commutative semigroup in order to understand the type signatures > inferred > from code that does basic math in Haskell. At least in the U.S., very > few computer science students take an algebra course before getting > undergraduate degrees. It is probably not worth to change Num, as code already depends on it. But by inserting some extra classes, and letting it derive, makes it possible to use operators such as (+) without tying it to Eq, Show, etc. >> In mathematical terms, the set of functions is a (math) module >> ("generalized vectorspace"), not a ring. > > Well, I agree that functions are modules; but it's hard to agree that > they are not rings. After all, it's not too difficult to verify > the ring > axioms. It is the set of function that may be a module or ring, and what it is depends on how you define it. - It may be different in different contexts. And there is a different question finding unambiguous notation. How would a explicit constant like 2 be defined in HAskell as a constant so that 2(sin) becomes possible? INs't OK to write (const 2)? Hans From apfelmus at quantentunnel.de Thu Apr 3 11:16:40 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Thu Apr 3 11:12:44 2008 Subject: [Haskell-cafe] Re: Typing with co/contra-variance. In-Reply-To: <47F4AA49.2050004@anu.edu.au> References: <47F4AA49.2050004@anu.edu.au> Message-ID: Ben Lippmeier wrote: > If I write an expression: > (if .. then 23 else "Erk") > > In Haskell this would be an error, but perhaps I can assign it the type > 'Top' (or 'Any') and then use reflection ala Data.Dynamic to inspect the > type of this object at runtime and cast it back to something useful... > > can someone point me to a good paper? I have absolutely no clue about the subject, but I would start a "bibliographic paper chase" with Philip Wadler, Robby Findler. Well-typed programs can't be blamed. http://homepages.inf.ed.ac.uk/wadler/topics/links.html#blame-icfp Talk slides from Bay FP meeting: http://bayfp.org/talks/slides/philip_wadler_1_jan_08_bayfp.pdf Regards, apfelmus From apfelmus at quantentunnel.de Thu Apr 3 11:31:16 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Thu Apr 3 11:27:29 2008 Subject: [Haskell-cafe] Re: Role based access control via monads or arrows or... something In-Reply-To: <20080403131812.GP16717@darcs.net> References: <200804031022.38072.porrifolius@gmail.com> <7ca3f0160804021745p48edeac0x606416ce0af1e7d3@mail.gmail.com> <20080403131812.GP16717@darcs.net> Message-ID: David Roundy wrote: > Luke Palmer wrote: >> porrifolius wrote: >>> (7) ideally required permissions would appear (and accumulate) in >>> type signatures via inference so application code knows which are >>> required and type checker can reject static/dynamic role constraint >>> violations >> >> If you mean what I think you mean by "dynamic", that these are runtime >> permissions, then you're not going to get the type checker to check >> them... of course. What did you mean by dynamic? > > > At the simplest (and stupidest) level, one could define > > data CanReadA > data CanReadB > -- etc > > data HavePermission perms where > HaveAPerm :: HavePermission CanReadA > HaveBPerm :: HavePermission CanReadB > > and if you then restricted access to the constructors of HavePermission, > you could write code like > > data RestrictedData permrequired a = Data a > -- constructor obviously not exported, or you'd lose any safety > > readRestrictedData :: HavePermission perm -> RestrictedData perm a -> a > > and now if you export readRestrictedData only, then only folks with the > proper permissions could access the data (and this could be done at > runtime). At runtime, are you sure? I mean, if I want to use it like in foo = ... readRestrictedData permission secret ... I must know that the type of my permission matches the the type of secret , either by knowing them in advance or by propagating this as type variable into the type of foo. In any case, I may only write foo if I know statically that permission is going to match the secret . No runtime involved? In other words, I fail to see how this GADT example is different from a normal phantom type (modulo different naming) data Permission p = Permitted -- not exported low :: Permission Low -- same role as HaveAPerm high :: Permission High -- a module which knows these constants has -- corresponding permissions data Restricted p a = Restricted a readRestricted :: Permission p -> Restricted p a -> a Regards, apfelmus From apfelmus at quantentunnel.de Thu Apr 3 11:37:53 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Thu Apr 3 11:33:57 2008 Subject: [Haskell-cafe] Re: Sorting with a weaker form of Ord (Re: Type constraints for class instances) In-Reply-To: References: <220e47b40803201900u4bcc564ard2ab8ad6d1d32a81@mail.gmail.com> <220e47b40803230539i42796fa1h480210020720e879@mail.gmail.com> Message-ID: >> Krzysztof Skrz?tnicki wrote: >>> class YOrd a where >>> ycmp :: a -> a -> (a,a) >> >>> Unfortunately, the performance of ysort is rather low. I believe that >>> it is impossible to create any sorting algorithm that uses ycmp >>> instead of compare, that is faster than O(n^2). Ok, it is possible to be faster, namely O(n (log n)^2) and even better. Sorting algorithms based on a comparator function like ycmp are called "sorting networks" and in fact well-known. See also http://en.wikipedia.org/wiki/Sorting_network Regards, apfelmus From droundy at darcs.net Thu Apr 3 11:51:39 2008 From: droundy at darcs.net (David Roundy) Date: Thu Apr 3 11:47:33 2008 Subject: [Haskell-cafe] Re: Role based access control via monads or arrows or... something In-Reply-To: References: <200804031022.38072.porrifolius@gmail.com> <7ca3f0160804021745p48edeac0x606416ce0af1e7d3@mail.gmail.com> <20080403131812.GP16717@darcs.net> Message-ID: <20080403155130.GQ16717@darcs.net> On Thu, Apr 03, 2008 at 05:31:16PM +0200, apfelmus wrote: > David Roundy wrote: > >Luke Palmer wrote: > >>porrifolius wrote: > >>> (7) ideally required permissions would appear (and accumulate) in > >>> type signatures via inference so application code knows which are > >>> required and type checker can reject static/dynamic role constraint > >>> violations > >> > >>If you mean what I think you mean by "dynamic", that these are runtime > >>permissions, then you're not going to get the type checker to check > >>them... of course. What did you mean by dynamic? > > > > > >At the simplest (and stupidest) level, one could define > > > >data CanReadA > >data CanReadB > >-- etc > > > >data HavePermission perms where > > HaveAPerm :: HavePermission CanReadA > > HaveBPerm :: HavePermission CanReadB > > > >and if you then restricted access to the constructors of HavePermission, > >you could write code like > > > >data RestrictedData permrequired a = Data a > >-- constructor obviously not exported, or you'd lose any safety > > > >readRestrictedData :: HavePermission perm -> RestrictedData perm a -> a > > > >and now if you export readRestrictedData only, then only folks with the > >proper permissions could access the data (and this could be done at > >runtime). > > At runtime, are you sure? I mean, if I want to use it like in > > foo = ... readRestrictedData permission secret ... > > I must know that the type of my permission matches the the type of > secret , either by knowing them in advance or by propagating this as > type variable into the type of foo. In any case, I may only write foo > if I know statically that permission is going to match the secret . > No runtime involved? > > In other words, I fail to see how this GADT example is different from a > normal phantom type (modulo different naming) The difference is that I can inspect at runtime what permissions I have. I see that I didn't demonstrate this. You can introduce a function checkPerms :: HavePermission p -> HavePermission p' -> EqCheck checkPerms HaveAPerm HaveAPerm = IsEq checkPerms HaveBPerm HaveBPerm = IsEq checkPerms _ _ = NotEq data EqCheck a b where IsEq :: EqCheck a a NotEq :: EqCheck a b which allows you to compare permissions at runtime and make use of them. -- David Roundy Department of Physics Oregon State University From lemming at henning-thielemann.de Thu Apr 3 11:53:23 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Apr 3 11:48:15 2008 Subject: [Haskell-cafe] Re: Function Precedence In-Reply-To: References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> <25B66FFC-7C33-49BD-9C63-7A05A46A9487@math.su.se> Message-ID: On Thu, 3 Apr 2008, jerzy.karczmarczuk@info.unicaen.fr wrote: > Fractional, Floating, etc. are also horrible. Why the square root needs to > be floating? It can belong to the algebraic number domain. At least in NumericPrelude we have separated these issues. From allbery at ece.cmu.edu Thu Apr 3 11:58:13 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Apr 3 11:54:08 2008 Subject: [Haskell-cafe] Doing without IORef In-Reply-To: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> References: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> Message-ID: <4512DF62-26F1-4526-91F8-76A4AC342D3E@ece.cmu.edu> On Apr 3, 2008, at 6:03 , Jinwoo Lee wrote: > Recently I wrote a code that uses readline library > (System.Console.Readline). > I had to maintain a state (file path) and do IO throughout the > code, so I decided to use StateT monad. > > The problem was that in order to retrieve the current state (file > path) inside the handler that had been registered by using bindKey > function of readline, I had to resort back to using IORef rather > than using the state stored in the StateT monad. It's because the > handler for bindKey should have the type of Int -> Char -> IO Int. You can hide the IORef inside the StateT... but this is one of several cases where I *really* wish the callbacks were MonadIO a => ... -> a t. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From tanimoto at arizona.edu Thu Apr 3 12:44:26 2008 From: tanimoto at arizona.edu (Paulo Tanimoto) Date: Thu Apr 3 12:40:18 2008 Subject: [Haskell-cafe] installing ghc-6.8.2 In-Reply-To: <20080403004514.GB16483@schmong.org> References: <20080402231216.GB31117@schmong.org> <20080402235046.GA10143@matrix.chaos.earth.li> <20080403004514.GB16483@schmong.org> Message-ID: Michael, Don't the available binaries work for you? From the output it seems you are on x86, which is of course supported. The requirements are just libreadline.so.4 and libncurses.so.5. Also, if you still want to compile from source, you could grab those binaries and them to compile GHC yourself, then perhaps make a debian package. Although those binaries have been created on Fedora, I'm on Ubuntu and they work flawlessly. By the way, you can have multiple versions of GHC coexisting too. Best, Paulo On Wed, Apr 2, 2008 at 5:45 PM, wrote: > Apologies to Ian, I think I sent him direct mail on my first attempt to > reply. > Adding those lines to mk/build.mk did not work. > I hope Idon't have to build a newer gcc. This is what I have right now. > michael@schmong:~/src/gcc$ gcc -v > > Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs > Configured with: ../src/configure -v > --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr > --mandir=/usr/share/man --infodir=/usr/share/info > --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared > --enable-__cxa_atexit --with-system-zlib --enable-nls > --without-included-gettext --enable-clocale=gnu --enable-debug > --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc > i486-linux > Thread model: posix > gcc version 3.3.5 (Debian 1:3.3.5-13) > > > > > > On Thu, Apr 03, 2008 at 12:50:46AM +0100, Ian Lynagh wrote: > > On Wed, Apr 02, 2008 at 07:12:16PM -0400, michael@schmong.org wrote: > > > > > > so it's this line that seems of the most interesting > > > > > > cc1: error: unrecognized option `-fno-unit-at-a-time' > > > > It looks like your version of ghc isn't designed to be used with the > > version of gcc you have. > > > > Putting this in mk/build.mk ought to let the build go through: > > > > SRC_HC_OPTS = -fasm > > GhcStage1HcOpts = -fasm > > > > > > Thanks > > Ian > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From chaddai.fouche at gmail.com Thu Apr 3 13:07:19 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Thu Apr 3 13:03:12 2008 Subject: [Haskell-cafe] [GSoC] Porting HaRe to use the GHC API In-Reply-To: <217e01c89414$600bec30$e6278351@cr3lt> References: <638ABD0A29C8884A91BC5FB5C349B1C32ABA047733@EA-EXMSG-C334.europe.corp.microsoft.com> <217e01c89414$600bec30$e6278351@cr3lt> Message-ID: 2008/4/1, Claus Reinke : > as for the project, the are actually two APIs to consider, > GHC's and HaRe's, and the main stumbling points are those > things that are not in those APIs (explicitly or at all): > > Many thanks for the valuable insights. I intend to work in close collaboration with the Kent team, indeed I'll do an internship over the summer with Simon Thompson ! Don't worry on this point. Of course I'll also try to work with the GHC developers on the subject of the GHC API. My objective is to make it work on the 6.8 API but if it appears that certain functions would be useful in the future API I'll be sure to report this to the GHC team. If I can, I would also like to be present during the discussion between the two Simon. Another notion I was interested in was to be able to reproduce a sequence of multi-module refactorings even in the absence of the initial module. It would allow to present a kind of "interface diff" for a distribution which would allow the developer of a module which depends on the distribution to update the call to this library. Of course it wouldn't be perfect and wouldn't convey the semantic modifications of the interface but it would help for all the renaming and usual modifications of external interfaces. To refactor modules that use CPP, I can see some possibilities : transforming the macro into placeholders (undefined) and inversing the transformation after the refactoring, trying every combination of the variables for the #ifdef/ifndef, forgetting those that don't compile and confronting the refactorisation of the others to see if they merge... That would need some work and would probably be very inefficient as it is But all of that should wait after we get HaRe working with the GHC API. :-) -- Chadda? From prstanley at ntlworld.com Thu Apr 3 13:13:40 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Thu Apr 3 13:09:26 2008 Subject: [Haskell-cafe] Precedence (Part 2) Message-ID: <7.0.1.0.0.20080403180328.01cf57c0@ntlworld.com> Hi folks > let f = sum.map (^2).filter even > f [1..4] 20 So far so good! > sum.map (^2).filter even [1..4] returns an error. How is it that the composition above as part of a function equation doesn't return any errors while on its own it requires parentheses? I can understand the need for the parentheses - the composition operator takes two arguments/operand,s each of which is a mapping which must correspond to specific domain and range requirements i.e. (b->c -> (a->b) -> (a->c) Why aren't the parentheses required in the function definition? Cheers, Paul From allbery at ece.cmu.edu Thu Apr 3 13:33:41 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Apr 3 13:29:36 2008 Subject: [Haskell-cafe] Precedence (Part 2) In-Reply-To: <7.0.1.0.0.20080403180328.01cf57c0@ntlworld.com> References: <7.0.1.0.0.20080403180328.01cf57c0@ntlworld.com> Message-ID: <361B90B5-2005-4968-997F-2CADB6F442D1@ece.cmu.edu> On Apr 3, 2008, at 13:13 , PR Stanley wrote: > Hi folks > > > let f = sum.map (^2).filter even > > f [1..4] > 20 > > So far so good! > > > sum.map (^2).filter even [1..4] > returns an error. > > How is it that the composition above as part of a function equation > doesn't return any errors while on its own it requires parentheses? You seem to have expression evaluation confused with cpp/m4 macros. The `f' in `f [1..4]' is not expanded as text to `sum.map (^2).filter even [1..4]'; it is evaluated as a function whose definition will (when needed! lazy language) eventually turn out to be `sum.map (^2).filter even'. If you really must view it as a text macro substitution, then imagine that every macro expansion has a set of parentheses added around it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From lrpalmer at gmail.com Thu Apr 3 13:41:54 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Apr 3 13:37:46 2008 Subject: [Haskell-cafe] Typing with co/contra-variance. In-Reply-To: <47F4AA49.2050004@anu.edu.au> References: <47F4AA49.2050004@anu.edu.au> Message-ID: <7ca3f0160804031041r474cd4c2y14c155662677d899@mail.gmail.com> On Thu, Apr 3, 2008 at 9:58 AM, Ben Lippmeier wrote: > Hi all, > I have some quick questions for the type theory people: > > If I write an expression: > (if .. then 23 else "Erk") > > In Haskell this would be an error, but perhaps I can assign it the type > 'Top' (or 'Any') and then use reflection ala Data.Dynamic to inspect the > type of this object at runtime and cast it back to something useful... > > > But if I write: > > isEven "Erk" > > where > isEven :: Int -> Bool > isEven i > = case i of > 1 -> False > 2 -> True > ... > > Then this would be a genuine type error, because the case-expression > demands an actual Int at runtime. > > > Questions: > 1) Could I perhaps wave my arms around and say something about the Int in > the type of isEven being in a contra-variant position? Is this what is > actually happening?, and can someone point me to a good paper? This is related to "gradual typing". I don't know how much work has been done into inference for gradual typing, but I'll bet you could hack on the HM algorithm a little and get something usable. Here's a relevant paper: http://www.cs.colorado.edu/~siek/pubs/pubs/2006/siek06:_gradual.pdf Enjoy. Luke From prstanley at ntlworld.com Thu Apr 3 13:42:09 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Thu Apr 3 13:37:54 2008 Subject: [Haskell-cafe] Precedence (Part 2) In-Reply-To: <361B90B5-2005-4968-997F-2CADB6F442D1@ece.cmu.edu> References: <7.0.1.0.0.20080403180328.01cf57c0@ntlworld.com> <361B90B5-2005-4968-997F-2CADB6F442D1@ece.cmu.edu> Message-ID: <7.0.1.0.0.20080403184137.01d6cd50@ntlworld.com> Hi folks > let f = sum.map (^2).filter even > f [1..4] 20 So far so good! > sum.map (^2).filter even [1..4] returns an error. How is it that the composition above as part of a function equation doesn't return any errors while on its own it requires parentheses? You seem to have expression evaluation confused with cpp/m4 macros. The `f' in `f [1..4]' is not expanded as text to `sum.map (^2).filter even [1..4]'; it is evaluated as a function whose definition will (when needed! lazy language) eventually turn out to be `sum.map (^2).filter even'. If you really must view it as a text macro substitution, then imagine that every macro expansion has a set of parentheses added around it. -- Okay, so it's not expanded like a CPP macro. How is it evaluated? What happens to the sum.map ... definition if it's not simply used to substitute f? Thanks, Paul From greg at maptuit.com Thu Apr 3 13:49:34 2008 From: greg at maptuit.com (Gregory Collins) Date: Thu Apr 3 13:53:49 2008 Subject: [Haskell-cafe] Precedence (Part 2) In-Reply-To: <7.0.1.0.0.20080403180328.01cf57c0@ntlworld.com> (PR Stanley's message of "Thu, 03 Apr 2008 18:13:40 +0100") References: <7.0.1.0.0.20080403180328.01cf57c0@ntlworld.com> Message-ID: PR Stanley writes: > Hi folks > >> let f = sum.map (^2).filter even >> f [1..4] > 20 > > So far so good! > >> sum.map (^2).filter even [1..4] > returns an error. > > How is it that the composition above as part of a function equation > doesn't return any errors while on its own it requires parentheses? I > can understand the need for the parentheses - the composition operator > takes two arguments/operand,s each of which is a mapping which must > correspond to specific domain and range requirements i.e. (b->c -> > (a->b) -> (a->c) > Why aren't the parentheses required in the function definition? The answer is precedence. The (.) operator is right-associative and has lower precedence than function application, meaning that: a . b . c . d . e == a . (b . (c . (d . e))) so the second form is equivalent to: sum . ((map (^2)) . (filter even [1..4])) Typing :t (filter even [1..4]) should give you your explanation. If you want to avoid parentheses, you can write that expression as: sum . map (^2) . filter even $ [1..4] which really means (sum . map (^2) . filter even) [1..4] which is the same as "f [1..4]" above. Hope that helps, G From phercek at gmail.com Thu Apr 3 14:08:09 2008 From: phercek at gmail.com (Peter Hercek) Date: Thu Apr 3 14:04:15 2008 Subject: [Haskell-cafe] Re: Doing without IORef In-Reply-To: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> References: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> Message-ID: Jinwoo Lee wrote: > Is there any way in which I can do without IORef in tabHandler and > commandLoop (written in red and bold, if you can see)? You could just always redefine the key binding for \t with a new closure which contains the updated "pwd" value (or the whole state if you like it more that way). I suppose readline supports key binding redefinition (???). But I do not think I like it more that IORef, I rather use IORefs with imperative interfaces :-) Peter. From michael at schmong.org Thu Apr 3 14:40:25 2008 From: michael at schmong.org (michael@schmong.org) Date: Thu Apr 3 14:36:18 2008 Subject: [Haskell-cafe] trying to install ghc-6.8.2 both binaries and sources Message-ID: <20080403184025.GB7767@schmong.org> I am operating under the assumption that Idid have a broken gcc. I installed a new one This is what happened when I tried compiling ghc-6.8.2 make all /usr/bin/ghc -H16m -O -w -I. -Iinclude -Rghc-timing -ignore-package Cabal -ignore-package filepath -I../libraries -fglasgow-exts -no-recomp -c System/FilePath/Posix.hs -o System/FilePath/Posix.o -ohi System/FilePath/Posix.hi cc1: error: unrecognized option `-fno-unit-at-a-time' <> make[2]: *** [System/FilePath/Posix.o] Error 1 make[1]: *** [boot] Error 2 make: *** [stage1] Error 1 this is exactly what happened prior to installing a new gcc. Here's what config.log says $ ./configure --prefix=/home/michael ## --------- ## ## Platform. ## ## --------- ## hostname = schmong.org uname -m = i686 uname -r = 2.6.16.33-vpsX uname -s = Linux uname -v = #2 SMP Tue Jan 23 22:53:20 EST 2007 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = i686 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/bin/X11 PATH: /usr/games PATH: /usr/lib ## ----------- ## ## Core tests. ## ## ----------- ## running configure, to aid debugging if configure makes a mistake. It was created by The Glorious Glasgow Haskell Compilation System configure 6.8. 2, which was generated by GNU Autoconf 2.59. Invocation command line was $ ./configure --prefix=/home/michael ## --------- ## ## Platform. ## ## --------- ## hostname = schmong.org uname -m = i686 uname -r = 2.6.16.33-vpsX uname -s = Linux uname -v = #2 SMP Tue Jan 23 22:53:20 EST 2007 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = i686 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/bin/X11 PATH: /usr/games PATH: /usr/lib ## ----------- ## ## Core tests. ## ## ----------- ## configure:1502: checking build system type configure:1520: result: i686-pc-linux-gnu configure:1528: checking host system type configure:1542: result: i686-pc-linux-gnu configure:1550: checking target system type configure:1564: result: i686-pc-linux-gnu configure:2121: checking for ghc configure:2139: found /usr/bin/ghc configure:2151: result: /usr/bin/ghc configure:2175: checking version of ghc The Glorious Glasgow Haskell Compilation System, version 6.6 configure:2204: result: 6.6 configure:2217: checking for ghc-pkg matching /usr/bin/ghc configure:2229: result: /usr/bin/ghc-pkg configure:2275: checking whether ghc has readline package configure:2286: result: yes configure:2296: checking for nhc configure:2329: result: no configure:2296: checking for nhc98 configure:2329: result: no configure:2338: checking for hbc configure:2371: result: no configure:2508: checking for ld configure:2526: found /usr/bin/ld configure:2538: result: /usr/bin/ld configure:2642: checking for path to top of build tree configure:2667: result: /home/michael/src/ghcsrc/ghc-6.8.2 configure:2728: checking whether #! works in shell scripts configure:2745: result: yes configure:2796: checking for perl configure:2814: found /usr/bin/perl configure:2826: result: /usr/bin/perl configure:2852: checking if your perl works in shell scripts configure:2870: result: yes configure:2875: checking for python configure:2893: found /usr/bin/python configure:2905: result: /usr/bin/python configure:2959: checking for gcc configure:2985: result: /home/michael/bin/gcc configure:3229: checking for C compiler version configure:3232: /home/michael/bin/gcc --version &5 gcc (GCC) 3.4.6 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3235: $? = 0 configure:3237: /home/michael/bin/gcc -v &5 Reading specs from /home/michael/lib/gcc/i686-pc-linux-gnu/3.4.6/specs I have also tried to install the binaries, this may be more promising. ./configure --prefix=$HOME checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu Which we'll further canonicalise into: i386-unknown-linux checking for path to top of build tree... pwd: timer_create: Operation not supported configure: error: cannot determine current directory this is exactly what happened when I tried to install the binaries with the old gcc. Here's the config.log $ ./configure --prefix=/home/michael ## --------- ## ## Platform. ## ## --------- ## hostname = schmong.org uname -m = i686 uname -r = 2.6.16.33-vpsX uname -s = Linux uname -v = #2 SMP Tue Jan 23 22:53:20 EST 2007 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = i686 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/bin/X11 PATH: /usr/games PATH: /usr/lib ## ----------- ## ## Core tests. ## ## ----------- ## configure:1692: checking build system type configure:1710: result: i686-pc-linux-gnu configure:1732: checking host system type configure:1747: result: i686-pc-linux-gnu configure:1769: checking target system type configure:1784: result: i686-pc-linux-gnu configure:1907: checking for path to top of build tree configure:1923: error: cannot determine current directory ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=i686-pc-linux-gnu ac_cv_env_CC_set=set ac_cv_env_CC_value=/home/michael/bin/gcc ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_host=i686-pc-linux-gnu ac_cv_target=i686-pc-linux-gnu ## ----------------- ## ## Output variables. ## ## ----------------- ## ArCmd='' CC='/home/michael/bin/gcc' CFLAGS='' CPP='' CPPFLAGS='' DEFS='' ECHO_C='' ECHO_N='-n' ECHO_T='' EXEEXT='' GccExtraViaCOpts='' GccVersion='' HaveGcc='' INSTALL_DATA='' INSTALL_PROGRAM='' INSTALL_SCRIPT='' LDFLAGS='' LIBOBJS='' LIBS='' LN_S='' LTLIBOBJS='' OBJEXT='' PACKAGE_BUGREPORT='' PACKAGE_NAME='' PACKAGE_STRING='' PACKAGE_TARNAME='' PACKAGE_VERSION='' PATH_SEPARATOR=':' PerlCmd='' RANLIB='' SHELL='/bin/sh' SedCmd='' TargetPlatform='i386-unknown-linux' ac_ct_CC='' bindir='${exec_prefix}/bin' build='i686-pc-linux-gnu' build_alias='' build_cpu='i686' build_os='linux-gnu' build_vendor='pc' datadir='${datarootdir}' datarootdir='${prefix}/share' docdir='${datarootdir}/doc/${PACKAGE}' dvidir='${docdir}' exec_prefix='NONE' exeext='' fp_prog_ar_raw='' hardtop='' host='i686-pc-linux-gnu' host_alias='' host_cpu='i686' host_os='linux-gnu' host_vendor='pc' htmldir='${docdir}' includedir='${prefix}/include' infodir='${datarootdir}/info' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localedir='${datarootdir}/locale' localstatedir='${prefix}/var' mandir='${datarootdir}/man' oldincludedir='/usr/include' pdfdir='${docdir}' prefix='/home/michael' program_transform_name='s,x,x,' psdir='${docdir}' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target='i686-pc-linux-gnu' target_alias='' target_cpu='i686' target_os='linux-gnu' target_vendor='pc' ## ----------- ## ## confdefs.h. ## ## ----------- ## #define PACKAGE_NAME "" #define PACKAGE_TARNAME "" #define PACKAGE_VERSION "" #define PACKAGE_STRING "" #define PACKAGE_BUGREPORT "" configure: exit 1 whew. Okay can anyone give me ideas on how to proceed? I have also verified I have the correct libreadline.so.5, libncurses.so.5. michael litchard From westondan at imageworks.com Thu Apr 3 14:41:32 2008 From: westondan at imageworks.com (Dan Weston) Date: Thu Apr 3 14:38:44 2008 Subject: [Haskell-cafe] Re: Role based access control via monads or arrows or... something In-Reply-To: <20080403155130.GQ16717@darcs.net> References: <200804031022.38072.porrifolius@gmail.com> <7ca3f0160804021745p48edeac0x606416ce0af1e7d3@mail.gmail.com> <20080403131812.GP16717@darcs.net> <20080403155130.GQ16717@darcs.net> Message-ID: <47F524DC.7040706@imageworks.com> Is this type-level design flexible enough for future requirement changes? The best answer to "Why is this door locked?" may not be "You don't have permission to open it", but rather "What door?". Suppose a client comes along later with a requirement that the permissions themselves are secret (e.g. I don't want you to know that I have permission to read your email). Now the permissions themselves have to be reflected somehow. And this reflection has permissions of its own. And permissions might have to nest not like locked doors but like trap doors. The most effective permission denial is the illusion that there is nothing there. Also, doesn't the type-level correspond to an intuitionistic logic, so it is difficult to express the concept of not-having-permission (a Vice President has permission to nuke some defenseless country only if the President's permission has been revoked through impeachment). Moreover, I see no way to have side effects (if someone peeks into your secret documents, let them look rather than tip them that you are on to them, but monitor their movements to see who they sell them to). Finally, type checking always halts, but it may desirable (in a Kafkaesque way) simply not to answer, such as when a dissident applies for an exit visa she is entitled by law to receive. Some many ways for a rigid design to fail. Dan David Roundy wrote: > On Thu, Apr 03, 2008 at 05:31:16PM +0200, apfelmus wrote: >> David Roundy wrote: >>> Luke Palmer wrote: >>>> porrifolius wrote: >>>>> (7) ideally required permissions would appear (and accumulate) in >>>>> type signatures via inference so application code knows which are >>>>> required and type checker can reject static/dynamic role constraint >>>>> violations >>>> If you mean what I think you mean by "dynamic", that these are runtime >>>> permissions, then you're not going to get the type checker to check >>>> them... of course. What did you mean by dynamic? >>> >>> At the simplest (and stupidest) level, one could define >>> >>> data CanReadA >>> data CanReadB >>> -- etc >>> >>> data HavePermission perms where >>> HaveAPerm :: HavePermission CanReadA >>> HaveBPerm :: HavePermission CanReadB >>> >>> and if you then restricted access to the constructors of HavePermission, >>> you could write code like >>> >>> data RestrictedData permrequired a = Data a >>> -- constructor obviously not exported, or you'd lose any safety >>> >>> readRestrictedData :: HavePermission perm -> RestrictedData perm a -> a >>> >>> and now if you export readRestrictedData only, then only folks with the >>> proper permissions could access the data (and this could be done at >>> runtime). >> At runtime, are you sure? I mean, if I want to use it like in >> >> foo = ... readRestrictedData permission secret ... >> >> I must know that the type of my permission matches the the type of >> secret , either by knowing them in advance or by propagating this as >> type variable into the type of foo. In any case, I may only write foo >> if I know statically that permission is going to match the secret . >> No runtime involved? >> >> In other words, I fail to see how this GADT example is different from a >> normal phantom type (modulo different naming) > > The difference is that I can inspect at runtime what permissions I have. I > see that I didn't demonstrate this. You can introduce a function > > checkPerms :: HavePermission p -> HavePermission p' -> EqCheck > checkPerms HaveAPerm HaveAPerm = IsEq > checkPerms HaveBPerm HaveBPerm = IsEq > checkPerms _ _ = NotEq > > data EqCheck a b where > IsEq :: EqCheck a a > NotEq :: EqCheck a b > > which allows you to compare permissions at runtime and make use of them. From atomb at galois.com Thu Apr 3 16:24:20 2008 From: atomb at galois.com (Aaron Tomb) Date: Thu Apr 3 16:20:24 2008 Subject: [Haskell-cafe] Typing with co/contra-variance. In-Reply-To: <7ca3f0160804031041r474cd4c2y14c155662677d899@mail.gmail.com> References: <47F4AA49.2050004@anu.edu.au> <7ca3f0160804031041r474cd4c2y14c155662677d899@mail.gmail.com> Message-ID: On Apr 3, 2008, at 10:41 AM, Luke Palmer wrote: > On Thu, Apr 3, 2008 at 9:58 AM, Ben Lippmeier > wrote: >> Questions: >> 1) Could I perhaps wave my arms around and say something about the >> Int in >> the type of isEven being in a contra-variant position? Is this >> what is >> actually happening?, and can someone point me to a good paper? > > This is related to "gradual typing". I don't know how much work has > been done into inference for gradual typing, but I'll bet you could > hack on the HM algorithm a little and get something usable. > > Here's a relevant paper: > http://www.cs.colorado.edu/~siek/pubs/pubs/2006/siek06:_gradual.pdf Yeah, there is work on inference for gradual types: http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-1039-08.pdf Aaron From olivier.boudry at gmail.com Thu Apr 3 17:27:17 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Thu Apr 3 17:23:13 2008 Subject: [Haskell-cafe] Shouldn't this loop indefinitely => take (last [0..]) [0..] Message-ID: Hi all, If you compile and run this: main = do putStrLn $ show $ take (last [0..]) [0..] or simply run: take (last [0..]) [0..] in ghci, it first hang for about one minute and then starts to generate an infinite list. I was expecting "last [0..]" to never produce a value and the "take" function to never take from the [0..] list. I found that line of code in a friend's "Skype Message", lauched it in ghci and forgot it. When I came back to my ghci window a couple minutes later it was listing numbers, which was really unexpected. If I just run "last [0..]" it doesn't return a value and my computer will quickly start to paginate to death. Am I missing something? Some laziness magic? Rewrite rules? Thanks, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080403/9198713b/attachment.htm From dons at galois.com Thu Apr 3 17:34:46 2008 From: dons at galois.com (Don Stewart) Date: Thu Apr 3 17:30:40 2008 Subject: [Haskell-cafe] Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: References: Message-ID: <20080403213446.GB2783@scytale.galois.com> olivier.boudry: > Hi all, > > If you compile and run this: > > main = do > putStrLn $ show $ take (last [0..]) [0..] > > or simply run: > > take (last [0..]) [0..] > > in ghci, it first hang for about one minute and then starts to generate an > infinite list. I was expecting "last [0..]" to never produce a value and > the "take" function to never take from the [0..] list. I can't reproduce this with ghc 6.8.2 on a 64 bit arch, both just sit running in constant space, at full cpu. Are you perhaps constraining it to an Int type somewhere (so that [0..] terminates at maxBound)? I.e. this kind of thing: Prelude> last [1..] :: Int8 127 but for maxBound on Int32? -- Don From bos at serpentine.com Thu Apr 3 17:35:59 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Apr 3 17:31:52 2008 Subject: [Haskell-cafe] Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: References: Message-ID: <47F54DBF.7040403@serpentine.com> Olivier Boudry wrote: > main = do > putStrLn $ show $ take (last [0..]) [0..] > > or simply run: > > take (last [0..]) [0..] > > in ghci, it first hang for about one minute and then starts to generate > an infinite list. It's not an infinite list. It's a list of length maxBound::Int, as required by the fact that take's first argument is an Int. The second argument is probably defaulting to Integer. <361B90B5-2005-4968-997F-2CADB6F442D1@ece.cmu.edu> <7.0.1.0.0.20080403184137.01d6cd50@ntlworld.com> Message-ID: PR Stanley wrote: Just a meta-point. The dash-dash-space sequence introduces a signature. If you write your reply after the dash-dash-space, as you did here, a lot of us won't see your reply because we have our mail/news clients set up to ignore signatures. I had to view the original message source to see what was going on. As for the main point, you can look at it as a substitution; it's just that you have to jump through some hoops to think of it as substituting plain text. For example, put parentheses around the bit that's been substituted. A slightly more accurate model would be to view things as substitution of parse trees. Then one can point out that instead of doing straight substitution, what actually happens is that subexpressions are shared. But that only effects performance; the observable behavior is the same as if you did substitution (of parse trees, or of text but adding the parentheses in the right places). From olivier.boudry at gmail.com Thu Apr 3 18:03:31 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Thu Apr 3 17:59:30 2008 Subject: [Haskell-cafe] Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <47F54DBF.7040403@serpentine.com> References: <47F54DBF.7040403@serpentine.com> Message-ID: On Thu, Apr 3, 2008 at 10:35 PM, Bryan O'Sullivan wrote: > > It's not an infinite list. It's a list of length maxBound::Int, as > required by the fact that take's first argument is an Int. The second > argument is probably defaulting to Integer. > > Right! The first arg of "take" makes the first list into a int list. I did not wait long enough to see the end of the list and I'm so used to represent infinite lists with [0..] that I didn't think it could be limited. Thanks for the explanation! Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080403/77afb60e/attachment.htm From cdsmith at twu.net Thu Apr 3 18:06:02 2008 From: cdsmith at twu.net (Chris Smith) Date: Thu Apr 3 18:06:03 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] References: <47F54DBF.7040403@serpentine.com> Message-ID: Bryan O'Sullivan wrote: > It's not an infinite list. It's a list of length maxBound::Int, as > required by the fact that take's first argument is an Int. The second > argument is probably defaulting to Integer. Which, incidentally, also explains why Don couldn't reproduce it on a 64- bit system. There, instead of hanging for about a minute before printing out the list, it would hang for about 4 billion minutes. -- Chris Smith From dons at galois.com Thu Apr 3 18:13:06 2008 From: dons at galois.com (Don Stewart) Date: Thu Apr 3 18:09:03 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: References: <47F54DBF.7040403@serpentine.com> Message-ID: <20080403221306.GA7948@scytale.galois.com> cdsmith: > Bryan O'Sullivan wrote: > > It's not an infinite list. It's a list of length maxBound::Int, as > > required by the fact that take's first argument is an Int. The second > > argument is probably defaulting to Integer. > > Which, incidentally, also explains why Don couldn't reproduce it on a 64- > bit system. There, instead of hanging for about a minute before printing > out the list, it would hang for about 4 billion minutes. It's also interesting how our 32 bit machines are fast enough now to make Int indices noticeably problematic. And thankfully, 64 bit machines are common enough now that the 32 bit Int issues are less of an issue. length, take, drop and index working on machine-sized Ints by default are really a bit of a wart, aren't they? -- Don From bos at serpentine.com Thu Apr 3 18:26:05 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Apr 3 18:21:57 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <20080403221306.GA7948@scytale.galois.com> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> Message-ID: <47F5597D.9080701@serpentine.com> Don Stewart wrote: >> Which, incidentally, also explains why Don couldn't reproduce it on a 64- >> bit system. There, instead of hanging for about a minute before printing >> out the list, it would hang for about 4 billion minutes. A billion minutes here, a billion minutes there, and pretty soon you're talking about enough time to brew a nice cup of tea. > It's also interesting how our 32 bit machines are fast enough now > to make Int indices noticeably problematic. And thankfully, 64 bit > machines are common enough now that the 32 bit Int issues are less of > an issue. Alas, we've swapped that for a big performance slowdown due to the doubled size of pointers, courtesy of STG's addiction thereto. take (last [0..]) [0..] In-Reply-To: <20080403221306.GA7948@scytale.galois.com> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> Message-ID: On Thu, Apr 3, 2008 at 11:13 PM, Don Stewart wrote: > length, take, drop and index working on machine-sized Ints by default > are really a bit of a wart, aren't they? > > -- Don Agreed, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080403/fcee41a2/attachment.htm From vigalchin at gmail.com Thu Apr 3 18:50:42 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Thu Apr 3 18:46:35 2008 Subject: [Haskell-cafe] compile-time question Message-ID: <5ae4f2ba0804031550h1bfb6121re52510be7daa949a@mail.gmail.com> hello, I have added new function definitions to the namespace of an existing module. I did 1: runhaskell Setup.hs configure 2. runhaskell Setup.hs build 3) runhaskell Setup.hs install successfully so that a Linux .a(rchive) is installed. I write a small test case that references one of the new functions; however, when I build the test case, I get an "Out of scope" message indicated that at ghc(i) compile time the new function symbol cannot be found. Why? kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080403/e2aef1d2/attachment.htm From bulat.ziganshin at gmail.com Thu Apr 3 19:01:57 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Apr 3 19:01:37 2008 Subject: [Haskell-cafe] compile-time question In-Reply-To: <5ae4f2ba0804031550h1bfb6121re52510be7daa949a@mail.gmail.com> References: <5ae4f2ba0804031550h1bfb6121re52510be7daa949a@mail.gmail.com> Message-ID: <141279460.20080404030157@gmail.com> Hello Galchin, Friday, April 4, 2008, 2:50:42 AM, you wrote: > 3) runhaskell Setup.hs install? > ? > I write a small test case that references one of the new > functions; however,?when I build the test case, I get an "Out of > scope" message indicated that at ghc(i) compile time the new function symbol cannot?be found.? ? i think you should add -package to your ghci cmdline -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jeremy at n-heptane.com Thu Apr 3 19:32:52 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Thu Apr 3 19:28:02 2008 Subject: [Haskell-cafe] Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: References: Message-ID: <87fxu2ms4b.wl%jeremy@n-heptane.com> Hello, Sadly, as others have pointed out, [0..] is not an infinite list in that context, so nothing too exciting is happening. You can making something almost exciting happen if you define some Peano numbers: > data P = Z | S P > inf = S Z [bunch of class instances skipped] > main = print $ genericTake (inf :: P) [0..] you still can not get output from: > main = print $ genericTake (last [0..] :: P) [0..] -- wont produce output because the compiler won't recognize that (last [0..]) is equalivent to 'inf'. You could add a rewrite rule which turned: last [0..] -> inf however, I think that would be a bit bogus, because, in Haskell, the value returned isn't really the same: last [0..] === _|_ inf = S S S S S S S S S ... I think this is a bit of an interesting case to consider. As proponents of declarative programming, we often talk about how declarative languages free you from having to tell the machine how to do everything (as compared to imperative languages). So, I think it is interesting to note that even in declarative languages, there is a still a degree of describing how to do a computation. I wonder if there are any dependently types languages where: last [0..] === inf Assuming that statement is true, of course. It seems like it ought to be provable, but my proof skills are weak. (I suppose in a strict language, you might consider them to both be _|_, but that is the less exciting case). j. ps. I have attached a working demo. I did not finish all the instance declarations, only enough to run the example. -------------- next part -------------- import Data.List main = do -- print $ genericTake (last [0..] :: P) [0..] -- wont produce output print $ genericTake (inf :: P) [0..] -- will produce output inf :: P inf = S inf data P = Z | S P instance Show P where show Z = "Z" show (S n) = "S " ++ show n instance Enum P where toEnum 0 = Z toEnum n = S (toEnum (n - 1)) fromEnum Z = 0 fromEnum (S p) = 1 + (fromEnum p) instance Ord P where (S x) > Z = True Z > Z = False (S x) > (S y) = x > y Z <= _ = True _ <= Z = False (S x) <= (S y) = x <= y instance Eq P where Z == Z = True (S x) == Z = False x == (S y) = False (S x) == (S y) = x == y instance Num P where Z + y = Z (S x) + y = S (x + y) x - Z = x Z - _ = error "negative numbers not supported." (S x) - (S y) = x - y fromInteger n | n < 0 = error "negative numbers not supported." fromInteger 0 = Z fromInteger n = S (fromInteger (n - 1)) instance Real P instance Integral P where -------------- next part -------------- At Thu, 3 Apr 2008 22:27:17 +0100, Olivier Boudry wrote: > > [1 ] > [1.1 ] > Hi all, > > If you compile and run this: > > main = do > putStrLn $ show $ take (last [0..]) [0..] > > or simply run: > > take (last [0..]) [0..] > > in ghci, it first hang for about one minute and then starts to generate an > infinite list. I was expecting "last [0..]" to never produce a value and the > "take" function to never take from the [0..] list. > > I found that line of code in a friend's "Skype Message", lauched it in ghci > and forgot it. When I came back to my ghci window a couple minutes later it > was listing numbers, which was really unexpected. > > If I just run "last [0..]" it doesn't return a value and my computer will > quickly start to paginate to death. Am I missing something? Some laziness > magic? Rewrite rules? > > Thanks, > > Olivier. > [1.2 ] > > [2 ] > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From claus.reinke at talk21.com Thu Apr 3 20:00:44 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Apr 3 19:57:36 2008 Subject: [Haskell-cafe] [GSoC] Porting HaRe to use the GHC API References: <638ABD0A29C8884A91BC5FB5C349B1C32ABA047733@EA-EXMSG-C334.europe.corp.microsoft.com><217e01c89414$600bec30$e6278351@cr3lt> Message-ID: <018e01c895e7$0ff35b50$191c8351@cr3lt> |Another notion I was interested in was to be able to reproduce a |sequence of multi-module refactorings even in the absence of the |initial module. It would allow to present a kind of "interface diff" |for a distribution which would allow the developer of a module which |depends on the distribution to update the call to this library. Of |course it wouldn't be perfect and wouldn't convey the semantic |modifications of the interface but it would help for all the renaming |and usual modifications of external interfaces. refactorings crossing external APIs are a very real problem, and when i last checked (several years ago..), published solutions went little further than establishing informal work-patterns ("if you do it like this, you'll save yourself and us some trouble. if you want to stay on our project, you'd better do it like this") or boundaries to limit the spread of refactoring effects over distributed projects. my own favourite approach expresses the process as a "buffered refactoring", with an adapter module serving as the buffer and formal spec of your "interface diff" (with apologies for ascii art;-): L: some library code I: L's external API C: some external client of L 0. C uses L, via I: L |I| C 1. introduce internal proxy/adapter A: { L |I| A } |I| C 2. refactor internally, leaving external API I unchanged while creating new internal API I': { L' |I'| A' } |I| C 3. publish L's new interface I', together with refactored adapter A', and deprecate old interface I: L' |I'| { A' |I| C } 4. clients can refactor to new interface, eliminating adapter A': L' |I1'| C' when it works, this approach has the advantage of formalizing every part of the process as a sequence of refactorings, and clients have the choice either to continue using the adaptor, ignoring the new interface in favour of the old one, or to get rid of the indirection and to use the new interface directly, by pushing the refactoring that started in the library code into their own code base. you could combine that with giving clients the sequence of refactorings that turned A (just re-export) into A' (implement old API in terms of new one), as it might help them to proceed. |But all of that should wait after we get HaRe working with the GHC API. :-) good to hear that - it is all too easy to get side-tracked when there are so many interesting problems!-) i just wanted to point out that soon after you get it working, there might be some disappointments due to GHC's source-less distribution installation model, use of cpp, etc. .. which just means that there'll be more work left after this necessary first step. claus From jinwoo68 at gmail.com Thu Apr 3 21:07:24 2008 From: jinwoo68 at gmail.com (Jinwoo Lee) Date: Thu Apr 3 21:03:48 2008 Subject: [Haskell-cafe] Doing without IORef In-Reply-To: <6a7c66fc0804030308q7e065938r6d4e818bbcec0e78@mail.gmail.com> References: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> <6a7c66fc0804030308q7e065938r6d4e818bbcec0e78@mail.gmail.com> Message-ID: <7070515b0804031807x139ce977m393d520d977c78e9@mail.gmail.com> But I still have to use IORef this way. On Thu, Apr 3, 2008 at 7:08 PM, Alfonso Acosta wrote: > > type MyState a = StateT FilePath IO a > > > > > Is there any way in which I can do without IORef in tabHandler and > > commandLoop (written in red and bold, if you can see)? > > How about keeping the IORef but storing it inside the state? > > type MySate a = StateT (IORef FilePath) IO a > -- Jinwoo Lee Always remember that you are unique. Just like everyone else. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080404/7484dfc7/attachment.htm From jinwoo68 at gmail.com Thu Apr 3 21:14:22 2008 From: jinwoo68 at gmail.com (Jinwoo Lee) Date: Thu Apr 3 21:10:15 2008 Subject: [Haskell-cafe] Re: Doing without IORef In-Reply-To: References: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> Message-ID: <7070515b0804031814y18dfe594g235e5023de7e3dc0@mail.gmail.com> Thanks everyone! Now I think using IORef is the most practical way to do this. And Claude, I will look into the article that you mentioned. jinwoo On Fri, Apr 4, 2008 at 3:08 AM, Peter Hercek wrote: > Jinwoo Lee wrote: > > > Is there any way in which I can do without IORef in tabHandler and > > commandLoop (written in red and bold, if you can see)? > > > > You could just always redefine the key binding for \t with > a new closure which contains the updated "pwd" value (or > the whole state if you like it more that way). I suppose > readline supports key binding redefinition (???). > But I do not think I like it more that IORef, I rather > use IORefs with imperative interfaces :-) > > Peter. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Jinwoo Lee Always remember that you are unique. Just like everyone else. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080404/56edf069/attachment-0001.htm From allbery at ece.cmu.edu Thu Apr 3 21:17:25 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Apr 3 21:13:21 2008 Subject: [Haskell-cafe] Doing without IORef In-Reply-To: <7070515b0804031807x139ce977m393d520d977c78e9@mail.gmail.com> References: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> <6a7c66fc0804030308q7e065938r6d4e818bbcec0e78@mail.gmail.com> <7070515b0804031807x139ce977m393d520d977c78e9@mail.gmail.com> Message-ID: <757C3C83-EED0-45D2-8665-A57DD587C502@ece.cmu.edu> On Apr 3, 2008, at 21:07 , Jinwoo Lee wrote: > But I still have to use IORef this way. You can't escape the IORef unless you can convince the library to thread your state everywhere that it needs to be modified *and* where it needs to be read, without copying it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From jinwoo68 at gmail.com Thu Apr 3 21:53:47 2008 From: jinwoo68 at gmail.com (Jinwoo Lee) Date: Thu Apr 3 21:49:38 2008 Subject: [Haskell-cafe] Doing without IORef In-Reply-To: <757C3C83-EED0-45D2-8665-A57DD587C502@ece.cmu.edu> References: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> <6a7c66fc0804030308q7e065938r6d4e818bbcec0e78@mail.gmail.com> <7070515b0804031807x139ce977m393d520d977c78e9@mail.gmail.com> <757C3C83-EED0-45D2-8665-A57DD587C502@ece.cmu.edu> Message-ID: <7070515b0804031853h358a34a0v283b9435582832cb@mail.gmail.com> OK. I understand it now. I think the article Claude suggested is worth a read because it shows how to hide using IORef in simple APIs. Thanks, jinwoo On Fri, Apr 4, 2008 at 10:17 AM, Brandon S. Allbery KF8NH < allbery@ece.cmu.edu> wrote: > > On Apr 3, 2008, at 21:07 , Jinwoo Lee wrote: > > > But I still have to use IORef this way. > > > > You can't escape the IORef unless you can convince the library to thread > your state everywhere that it needs to be modified *and* where it needs to > be read, without copying it. > > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > -- Jinwoo Lee Always remember that you are unique. Just like everyone else. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080404/c1c13fad/attachment.htm From ajb at spamcop.net Fri Apr 4 01:07:07 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Fri Apr 4 01:03:00 2008 Subject: [Haskell-cafe] Re: Doing without IORef In-Reply-To: <7070515b0804031814y18dfe594g235e5023de7e3dc0@mail.gmail.com> References: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> <7070515b0804031814y18dfe594g235e5023de7e3dc0@mail.gmail.com> Message-ID: <20080404010707.b4hmrd149w4okc8k@webmail.spamcop.net> G'day all. Quoting Jinwoo Lee : > Thanks everyone! > Now I think using IORef is the most practical way to do this. Just a suggestion: Store it in a ReaderT instead of a StateT. Cheers, Andrew Bromage From peteg42 at gmail.com Fri Apr 4 02:06:21 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Fri Apr 4 02:02:24 2008 Subject: [Haskell-cafe] Re: HDBC, character encoding In-Reply-To: References: <257E3FFB-EF08-4D64-8AD5-4034A2F2250B@inf.fu-berlin.de> Message-ID: On 03/04/2008, at 9:10 PM, John Goerzen wrote: > On 2008-04-01, Peter Gammie wrote: >> I added some stuff to HSQL (not HDBC) and HaskellDB so that UTF8 can >> be used to talk to the database. It's not very pretty though, so I >> haven't tried to get it merged. > > Do you have a diff somewhere? I'd be interested in your approach, to > see if the same thing would make sense in HDBC. My approach is simple: when creating a connection to the database, ask for two functions (a codec pair) and stash them with the rest of the DB state. The types involved are [Word8] and String. I started out trying to use ByteString instead of [Word8] but it didn't bring much to the table in my case. > I had generally been of the opinion that HDBC should just pass data > through, however it is obtained, and let the programmer set the > encoding as desired. If this approach isn't working for people, I'd > like to fix it, but want to make sure it's done right. Assuming you're talking about the FFI's mandated behaviour, I'm not very comfortable with the encoding depending on the C locale, for two main reasons: - the program I'm hacking runs on some web host's server that is an unknown quantity. - GHC has a few quirks in how it implements the FFI, better to avoid the part that interprets characters. If you want to be general, I guess you could abandon String (at the HDBC level) and use [Word8]/ByteString everywhere, then provide some convenience wrappers. Then you can uniformly handle binary and textual data. I am not familiar with your project though. cheers peter From Christian.Maeder at dfki.de Fri Apr 4 03:56:22 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Apr 4 03:52:16 2008 Subject: [Haskell-cafe] Re: trying to install ghc-6.8.2 both binaries and sources In-Reply-To: <20080403184025.GB7767@schmong.org> References: <20080403184025.GB7767@schmong.org> Message-ID: <47F5DF26.8070301@dfki.de> michael@schmong.org wrote: > I am operating under the assumption that Idid have a broken gcc. Your gcc is not broken, but a bit old (for a new ghc-6.8.2) > Which we'll further canonicalise into: i386-unknown-linux > checking for path to top of build tree... pwd: timer_create: Operation > not supported > configure: error: cannot determine current directory This timer_create error is due to an old glibc. If it comes from the installation of http://www.haskell.org/ghc/dist/6.8.2/ghc-6.8.2-i386-unknown-linux.tar.bz2 than you have to install an older version (i.e. ghc-6.4.2) http://www.haskell.org/ghc/download_ghc_642.html#x86linux If you (or what or however installs your software) installed my version http://www.haskell.org/ghc/dist/6.8.2/maeder/ghc-6.8.2-i386-unknown-linux.tar.bz2 (or your version was created differently) than try the above ghc-6.8.2 version first. Usually ghc is installed under /usr/local/ so the binary script is /usr/local/bin/ghc. If no idea why your ghc is /usr/bin/ghc. It's either a link or it was installed using --prefix=/usr. (debian users may know) Cheers Christian From jinwoo68 at gmail.com Fri Apr 4 05:28:07 2008 From: jinwoo68 at gmail.com (Jinwoo Lee) Date: Fri Apr 4 05:23:58 2008 Subject: [Haskell-cafe] Re: Doing without IORef In-Reply-To: <20080404010707.b4hmrd149w4okc8k@webmail.spamcop.net> References: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> <7070515b0804031814y18dfe594g235e5023de7e3dc0@mail.gmail.com> <20080404010707.b4hmrd149w4okc8k@webmail.spamcop.net> Message-ID: <7070515b0804040228p7775ff5ck8f1ec22a9b9498f9@mail.gmail.com> Hi Andrew, I haven't used ReaderT. What are the advantages when using ReaderT instead of StateT in this case? Thanks, jinwoo On Fri, Apr 4, 2008 at 2:07 PM, wrote: > G'day all. > > Quoting Jinwoo Lee : > > Thanks everyone! > > Now I think using IORef is the most practical way to do this. > > > > Just a suggestion: Store it in a ReaderT instead of a StateT. > > Cheers, > Andrew Bromage > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Jinwoo Lee Always remember that you are unique. Just like everyone else. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080404/3e5562cf/attachment.htm From ndmitchell at gmail.com Fri Apr 4 07:34:54 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Apr 4 07:30:52 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <20080403221306.GA7948@scytale.galois.com> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> Message-ID: <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> Hi > length, take, drop and index working on machine-sized Ints by default > are really a bit of a wart, aren't they? Yes. Also, having strict Int's by default is a bit ugly, in an otherwise lazy-by-default language. It's a place where Haskell decided to remove mathematical elegance for pragmatic speed... (Not that it isn't a worthwhile trade off, but it is still loosing something to gain something else) Thanks Neil From aneumann at inf.fu-berlin.de Fri Apr 4 08:55:02 2008 From: aneumann at inf.fu-berlin.de (Adrian Neumann) Date: Fri Apr 4 08:52:56 2008 Subject: [Haskell-cafe] Windows CE, Xscale Compiler? Message-ID: <47F62526.2030407@inf.fu-berlin.de> Is there any Haskell compiler for Windows CE on a XScale platform? I googled around a bit and found references to a Hugs implementation but couldn't find any place to download it. I have the opportunity to program a teledrive[1] and would very much like to avoid something disfunctional like C. [1] http://www.iavproducts.com/de/produkte/teledrive/teledrive.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080404/a27c9b8a/signature.bin From prstanley at ntlworld.com Fri Apr 4 09:07:15 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Fri Apr 4 09:03:06 2008 Subject: [Haskell-cafe] Windows CE, Xscale Compiler? In-Reply-To: <47F62526.2030407@inf.fu-berlin.de> References: <47F62526.2030407@inf.fu-berlin.de> Message-ID: <7.0.1.0.0.20080404140556.01d28158@ntlworld.com> I'm surprised you can't use the Glasgow implementation on CE. At 13:55 04/04/2008, you wrote: >Is there any Haskell compiler for Windows CE on a XScale platform? I >googled around a bit and found references to a Hugs implementation >but couldn't find any place to download it. > >I have the opportunity to program a teledrive[1] and would very much >like to avoid something disfunctional like C. > >[1] http://www.iavproducts.com/de/produkte/teledrive/teledrive.php > > > > >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe@haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe From prstanley at ntlworld.com Fri Apr 4 09:46:24 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Fri Apr 4 09:42:15 2008 Subject: [Haskell-cafe] Windows CE, Xscale Compiler? In-Reply-To: <47F62F17.4030808@inf.fu-berlin.de> References: <47F62526.2030407@inf.fu-berlin.de> <7.0.1.0.0.20080404140556.01d28158@ntlworld.com> <47F62F17.4030808@inf.fu-berlin.de> Message-ID: <7.0.1.0.0.20080404144540.01d76ec8@ntlworld.com> At 14:37 04/04/2008, you wrote: >And how would I cross compile something for that platform with ghc? >(There seems to be no port, which is fine) > > Don't look at me mate. :-) >PR Stanley schrieb: >>I'm surprised you can't use the Glasgow implementation on CE. >>At 13:55 04/04/2008, you wrote: >>>Is there any Haskell compiler for Windows CE on a XScale platform? >>>I googled around a bit and found references to a Hugs >>>implementation but couldn't find any place to download it. >>> >>>I have the opportunity to program a teledrive[1] and would very >>>much like to avoid something disfunctional like C. >>> >>>[1] http://www.iavproducts.com/de/produkte/teledrive/teledrive.php >>> >>> >>> >>> >>>_______________________________________________ >>>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 > > > > From droundy at darcs.net Fri Apr 4 10:33:03 2008 From: droundy at darcs.net (David Roundy) Date: Fri Apr 4 10:28:55 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> Message-ID: <20080404143301.GV16717@darcs.net> On Fri, Apr 04, 2008 at 12:34:54PM +0100, Neil Mitchell wrote: > > length, take, drop and index working on machine-sized Ints by default > > are really a bit of a wart, aren't they? > > Yes. Also, having strict Int's by default is a bit ugly, in an > otherwise lazy-by-default language. It's a place where Haskell decided > to remove mathematical elegance for pragmatic speed... > > (Not that it isn't a worthwhile trade off, but it is still loosing > something to gain something else) Personally, I like Ints. -- David Roundy Department of Physics Oregon State University From jgoerzen at complete.org Fri Apr 4 10:27:35 2008 From: jgoerzen at complete.org (John Goerzen) Date: Fri Apr 4 11:04:08 2008 Subject: [Haskell-cafe] Re: HDBC, character encoding References: <257E3FFB-EF08-4D64-8AD5-4034A2F2250B@inf.fu-berlin.de> Message-ID: On 2008-04-04, Peter Gammie wrote: >> through, however it is obtained, and let the programmer set the >> encoding as desired. If this approach isn't working for people, I'd >> like to fix it, but want to make sure it's done right. > > Assuming you're talking about the FFI's mandated behaviour, I'm not > very comfortable with the encoding depending on the C locale, for two > main reasons: > > - the program I'm hacking runs on some web host's server that is an > unknown quantity. > - GHC has a few quirks in how it implements the FFI, better to avoid > the part that interprets characters. > > If you want to be general, I guess you could abandon String (at the > HDBC level) and use [Word8]/ByteString everywhere, then provide some > convenience wrappers. Then you can uniformly handle binary and textual > data. I am not familiar with your project though. I've looked at the Data.ByteString.Internal API, and it looks like that ought to work. Oddly, the Data.ByteString.Lazy.Internal API does not seem to export enough to work with it in FFI. I can see this being a performance and ease-of-use win in some situations. I don't think it's an actual feature difference, though. If you can represent it as a [Word8], you can represent it as a [Char], and it will be converted to the same underlying data for the trip through FFI. -- John From loup.vaillant at gmail.com Fri Apr 4 11:37:07 2008 From: loup.vaillant at gmail.com (Loup Vaillant) Date: Fri Apr 4 11:33:33 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> Message-ID: <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> 2008/4/4, Neil Mitchell : > > Also, having strict Int's by default is a bit ugly, in an > otherwise lazy-by-default language. You do mean that, for example (\x -> x + 1) (1/0 :: Int) <=> _|_ ? Does it bites often (and how, if you have any example)? cheers, Loup From ndmitchell at gmail.com Fri Apr 4 11:46:22 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Apr 4 11:43:26 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> Message-ID: <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> > > > Also, having strict Int's by default is a bit ugly, in an > > > otherwise lazy-by-default language. > > I meant: > (\x (y :: Int) -> x + 1) 1 (1/0 :: Int) <=> _|_ ? Division by 0 is still an error. What I mean is: length xs == length ys Where length xs = 1 and ys = 1000. This takes 1000 steps to tell the Int's aren't equal, since we don't have proper lazy naturals. If we did, it would take 2 steps. Read this: http://citeseer.ist.psu.edu/45669.html - it argues the point I am trying to make, but much better. Thanks Neil From magnus at therning.org Fri Apr 4 12:10:55 2008 From: magnus at therning.org (Magnus Therning) Date: Fri Apr 4 12:06:51 2008 Subject: [Haskell-cafe] mostly for Neil: tagsoup problems Message-ID: Neil, and others, Does the cabal file for Tagsoup require a version of Cabal newer than 1.1.6? In case it does it doesn't say so. I suspect this is the cause of the rather cryptic error message: "setup: tagsoup.cabal:20: 'Executable' stanza starting with field 'ghc-options'". I also noticed that the Haddock-umentation on Neil's side is for version 0.1, while Hackage has version 0.4. I was rather confused by that at first, since the module names had changed :) /M -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080404/7febce25/attachment.htm From loup.vaillant at gmail.com Fri Apr 4 12:31:30 2008 From: loup.vaillant at gmail.com (Loup Vaillant) Date: Fri Apr 4 12:27:21 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> Message-ID: <6f9f8f4a0804040931i42040dib28bd523db349e70@mail.gmail.com> 2008/4/4, Neil Mitchell : > > > > Also, having strict Int's by default is a bit ugly, in an > > > > otherwise lazy-by-default language. > > > > > I meant: > > (\x (y :: Int) -> x + 1) 1 (1/0 :: Int) <=> _|_ ? > > Division by 0 is still an error. What I mean is: Yes, but this particular one need not be performed. Will it be? > length xs == length ys > > Where length xs = 1 and ys = 1000. This takes 1000 steps to tell the > Int's aren't equal, since we don't have proper lazy naturals. If we > did, it would take 2 steps. Err, really? I mean, could we calculate this equality without reducing length ys to weak head normal form (and then to plain normal form)? What do you mean by "proper Lazy naturals"? Peano ones? Loup From ndmitchell at gmail.com Fri Apr 4 12:37:53 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Apr 4 12:33:42 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <6f9f8f4a0804040931i42040dib28bd523db349e70@mail.gmail.com> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> <6f9f8f4a0804040931i42040dib28bd523db349e70@mail.gmail.com> Message-ID: <404396ef0804040937n3ea7151cj235b60330c3a4aa6@mail.gmail.com> Hi > > > I meant: > > > (\x (y :: Int) -> x + 1) 1 (1/0 :: Int) <=> _|_ ? > > > > Division by 0 is still an error. What I mean is: > > Yes, but this particular one need not be performed. Will it be? Oh, sorry, I misread that. Even with current Haskell's Int's that is lazy enough to work, and won't crash. > > Where length xs = 1 and ys = 1000. This takes 1000 steps to tell the > > Int's aren't equal, since we don't have proper lazy naturals. If we > > did, it would take 2 steps. > > Err, really? I mean, could we calculate this equality without reducing > length ys to weak head normal form (and then to plain normal form)? Not without lazy naturals, or some other way of returning the result of length lazily. > What do you mean by "proper Lazy naturals"? Peano ones? Yes Thanks Neil From ndmitchell at gmail.com Fri Apr 4 12:43:40 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Apr 4 12:39:33 2008 Subject: [Haskell-cafe] mostly for Neil: tagsoup problems In-Reply-To: References: Message-ID: <404396ef0804040943yabb2570v520f2fedf3a10204@mail.gmail.com> Hi Magnus, > Does the cabal file for Tagsoup require a version of Cabal newer than 1.1.6? > In case it does it doesn't say so. I suspect this is the cause of the > rather cryptic error message: "setup: tagsoup.cabal:20: 'Executable' stanza > starting with field 'ghc-options'". The version in the darcs repo has a Cabal-Version field, asking for 1.2 or above. I'll try and make a new release with this change included in the next week. > I also noticed that the Haddock-umentation on Neil's side is for version > 0.1, while Hackage has version 0.4. I was rather confused by that at first, > since the module names had changed :) Woops. I had linked directly to the haddock of the central module, rather than the haddock index. I will fix this later today. Thanks Neil From bos at serpentine.com Fri Apr 4 12:56:35 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Apr 4 12:52:25 2008 Subject: [Haskell-cafe] Re: Doing without IORef In-Reply-To: <7070515b0804040228p7775ff5ck8f1ec22a9b9498f9@mail.gmail.com> References: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> <7070515b0804031814y18dfe594g235e5023de7e3dc0@mail.gmail.com> <20080404010707.b4hmrd149w4okc8k@webmail.spamcop.net> <7070515b0804040228p7775ff5ck8f1ec22a9b9498f9@mail.gmail.com> Message-ID: <47F65DC3.1080902@serpentine.com> Jinwoo Lee wrote: > I haven't used ReaderT. What are the advantages when using ReaderT > instead of StateT in this case? A StateT lets you replace one IORef with another, since it gives you mutable state. A ReaderT gives you *immutable* state, so the type system guarantees that you'll always be using the same IORef. References: <257E3FFB-EF08-4D64-8AD5-4034A2F2250B@inf.fu-berlin.de> Message-ID: <47F65E67.2050402@serpentine.com> John Goerzen wrote: > I've looked at the Data.ByteString.Internal API, and it looks like > that ought to work. Oddly, the Data.ByteString.Lazy.Internal API does > not seem to export enough to work with it in FFI. It doesn't usually make sense to use lazy ByteStrings directly with the FFI. Most often, you'll work with the strict chunks, and wrap them up. One exception would be for C functions that let you do scatter/gather I/O, such as writev. You'd still be dealing with strict chunks when calling the function, but the wrapper API might expose a lazy interface. take (last [0..]) [0..] In-Reply-To: <6f9f8f4a0804040931i42040dib28bd523db349e70@mail.gmail.com> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> <6f9f8f4a0804040931i42040dib28bd523db349e70@mail.gmail.com> Message-ID: <836B0293-D3D3-4FA2-995B-6B18E4C610CA@gmail.com> On Apr 4, 2008, at 11:31 AM, Loup Vaillant wrote: > I mean, could we calculate this equality without reducing > length ys to weak head normal form (and then to plain normal form)? Yes. Suppose equality over Nat is defined something like: Z == Z = True S x == S y = x == y x == y = False And also suppose the length function actually returns a Nat instead of an Int. Now the expression reduces as: length xs == length ys S (length xs') == S (length ys') Z == S (length ys'') False That would not be possible without lazy Nats. - Jake From ketil at malde.org Fri Apr 4 14:54:04 2008 From: ketil at malde.org (Ketil Malde) Date: Fri Apr 4 14:49:44 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> (Neil Mitchell's message of "Fri\, 4 Apr 2008 12\:34\:54 +0100") References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> Message-ID: <873aq1pi2b.fsf@nmd9999.imr.no> "Neil Mitchell" writes: >> length, take, drop and index working on machine-sized Ints by default >> are really a bit of a wart, aren't they? > Yes. Also, having strict Int's by default is a bit ugly, [..] > (Not that it isn't a worthwhile trade off, but it is still loosing > something to gain something else) Presumably you refer to the latter point - Int strictness - here? I don't think "optimizing" list operations (take, length etc) to Int buys you much performance - traversing the list is going to be far more expensive. (Or so I believe - anybody care to benchmark it?) Unfortunately, the "genericLenght" name is about as clumsy syntactically as Int is semantically, so it's about an even trade-off :-) -k -- If I haven't seen further, it is by standing in the footprints of giants From prstanley at ntlworld.com Fri Apr 4 15:58:06 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Fri Apr 4 15:54:00 2008 Subject: [Haskell-cafe] The range operator Message-ID: <7.0.1.0.0.20080404205536.01d8bb70@ntlworld.com> Hi folks [x, y..z] What's the role of x? Cheers, Paul From stefanor at cox.net Fri Apr 4 16:00:25 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Fri Apr 4 15:56:15 2008 Subject: [Haskell-cafe] The range operator In-Reply-To: <7.0.1.0.0.20080404205536.01d8bb70@ntlworld.com> References: <7.0.1.0.0.20080404205536.01d8bb70@ntlworld.com> Message-ID: <20080404200025.GA3156@localhost.localdomain> On Fri, Apr 04, 2008 at 08:58:06PM +0100, PR Stanley wrote: > Hi folks > [x, y..z] > What's the role of x? > Cheers, > Paul First number in the output; also all pairs differ as much as the first two numbers do. Try e.g [1, 2 .. 10] and [0, 2 .. 10] Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080404/23505866/attachment.bin From kili at outback.escape.de Fri Apr 4 16:19:50 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Fri Apr 4 16:15:58 2008 Subject: [Haskell-cafe] The range operator In-Reply-To: <7.0.1.0.0.20080404205536.01d8bb70@ntlworld.com> References: <7.0.1.0.0.20080404205536.01d8bb70@ntlworld.com> Message-ID: <20080404201949.GA2343@petunia.outback.escape.de> On Fri, Apr 04, 2008 at 08:58:06PM +0100, PR Stanley wrote: > [x, y..z] > What's the role of x? It's the first argument passed to enumFromThenTo. See sections 3.10 and 6.3.4 of the Haskell report. Ciao, Kili -- There's a limit to how many buttons a shirt should have. -- Theo de Raadt From andrewcoppin at btinternet.com Fri Apr 4 16:49:01 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri Apr 4 16:45:11 2008 Subject: [Haskell-cafe] The range operator In-Reply-To: <20080404200025.GA3156@localhost.localdomain> References: <7.0.1.0.0.20080404205536.01d8bb70@ntlworld.com> <20080404200025.GA3156@localhost.localdomain> Message-ID: <47F6943D.5030700@btinternet.com> Stefan O'Rear wrote: > On Fri, Apr 04, 2008 at 08:58:06PM +0100, PR Stanley wrote: > >> Hi folks >> [x, y..z] >> What's the role of x? >> Cheers, >> Paul >> > > First number in the output; also all pairs differ as much as the first > two numbers do. > > Try e.g [1, 2 .. 10] and [0, 2 .. 10] > More to the point, the range y..z goes in steps of y-z. ;-) From gtener at gmail.com Fri Apr 4 17:36:16 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Fri Apr 4 17:32:06 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <836B0293-D3D3-4FA2-995B-6B18E4C610CA@gmail.com> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> <6f9f8f4a0804040931i42040dib28bd523db349e70@mail.gmail.com> <836B0293-D3D3-4FA2-995B-6B18E4C610CA@gmail.com> Message-ID: <220e47b40804041436h4237d53p42a74a03d7239793@mail.gmail.com> On Fri, Apr 4, 2008 at 7:14 PM, Jake Mcarthur wrote: > On Apr 4, 2008, at 11:31 AM, Loup Vaillant wrote: > > > I mean, could we calculate this equality without reducing > > length ys to weak head normal form (and then to plain normal form)? > > > > Yes. Suppose equality over Nat is defined something like: > > Z == Z = True > S x == S y = x == y > x == y = False > > And also suppose the length function actually returns a Nat instead of an > Int. Now the expression reduces as: > > length xs == length ys > S (length xs') == S (length ys') > Z == S (length ys'') > False > > That would not be possible without lazy Nats. One thing to notice is that with lazy Nats this code: length [] == length [1..] would terminate, while on 64 bit platform it is "almost bottom" :-) Theoretically it is even worse: genericLength [] == genericLength [1..] :: Integer will never terminate and eat infinite amount of memory along the way, while genericLength [] == genericLength [1..] :: Nat will do just fine. We can however write function like this: eqLengths [] [] = True eqLengths (x:xs) (y:ys) = eqLengths ys xs eqLengths _ _ = False which looks just fine for me. Christopher Skrz?tnicki From ndmitchell at gmail.com Fri Apr 4 17:44:16 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Apr 4 17:40:17 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <220e47b40804041436h4237d53p42a74a03d7239793@mail.gmail.com> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> <6f9f8f4a0804040931i42040dib28bd523db349e70@mail.gmail.com> <836B0293-D3D3-4FA2-995B-6B18E4C610CA@gmail.com> <220e47b40804041436h4237d53p42a74a03d7239793@mail.gmail.com> Message-ID: <404396ef0804041444t194de5a9t11c518ce75612a5b@mail.gmail.com> Hi > We can however write function like this: > > eqLengths [] [] = True > eqLengths (x:xs) (y:ys) = eqLengths ys xs > eqLengths _ _ = False > > which looks just fine for me. I have this defined function. I also have lenEq1, lenGt1, and a few other variants. It works, but it just doesn't feel elegant. Note: In case anyone gets the wrong impression, I am not suggesting lazy naturals be the standard numeric type in Haskell, just that by not going that way we have paid a cost in terms of elegance. Thanks Neil From dons at galois.com Fri Apr 4 17:45:36 2008 From: dons at galois.com (Don Stewart) Date: Fri Apr 4 17:41:40 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <404396ef0804041444t194de5a9t11c518ce75612a5b@mail.gmail.com> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> <6f9f8f4a0804040931i42040dib28bd523db349e70@mail.gmail.com> <836B0293-D3D3-4FA2-995B-6B18E4C610CA@gmail.com> <220e47b40804041436h4237d53p42a74a03d7239793@mail.gmail.com> <404396ef0804041444t194de5a9t11c518ce75612a5b@mail.gmail.com> Message-ID: <20080404214536.GH12163@scytale.galois.com> ndmitchell: > Hi > > > We can however write function like this: > > > > eqLengths [] [] = True > > eqLengths (x:xs) (y:ys) = eqLengths ys xs > > eqLengths _ _ = False > > > > which looks just fine for me. > > I have this defined function. I also have lenEq1, lenGt1, and a few > other variants. It works, but it just doesn't feel elegant. > > Note: In case anyone gets the wrong impression, I am not suggesting > lazy naturals be the standard numeric type in Haskell, just that by > not going that way we have paid a cost in terms of elegance. > I'd be happy if we had an (unbounded) Nat type in the first place... -- Don From cdsmith at twu.net Fri Apr 4 18:05:07 2008 From: cdsmith at twu.net (Chris Smith) Date: Fri Apr 4 18:01:20 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> Message-ID: Don Stewart wrote: > length, take, drop and index working on machine-sized Ints by default > are really a bit of a wart, aren't they? Definitely. See http://cdsmith.wordpress.com/2007/07/05/find-the-bug/ for my account of this problem when I ran into it last summer. In particular, the combination of these functions using Int and too much reliance on type inference can be fatal. Overflow is possible in most languages; but in Haskell you get used to not dealing with it by assuming that numeric types default to Integer. Then, in some remote corner somewhere, just one use of 'length' may result in an inferred type of Int for half the numbers in the program. The problem is likely to be in a piece of code completely unrelated to where the symptoms occur. -- Chris Smith From fruehr at willamette.edu Fri Apr 4 21:34:12 2008 From: fruehr at willamette.edu (Fritz Ruehr) Date: Fri Apr 4 21:30:05 2008 Subject: [Haskell-cafe] Bug in Hugs, Haskell behavior question Message-ID: <78B6E2AA-B213-4656-BE3C-9733CFD5871E@willamette.edu> In lab the other day I was showing pattern bindings to a student and broached a limiting case, one with no variables to be bound in the pattern. I was surprised to find that Hugs crashed when I tried a pattern binding at top level like this: (2,[1,4],5) = (2,[1,4],5) It also crashed on the simpler: [2] = [2] On the other hand, this turns out to be acceptable: 2 = 2 In fact, even this goes through without a hitch! 2 = 3 I'm not sure from the language definition yet whether this last should give an "Unmatched pattern" error, but if it's intended behavior, it does look a little odd. Would anyone care to argue for or against allowing this? In any case, the more structured patterns cause the latest (Sep 06) Hugs release to crash, with "INTERNAL ERROR: compileGlobalFunction". (GHC allows the strange "2 = 3" and handles the structured ones fine, including even "(1,[2,3],4) = (4,[3,37],42)". I haven't checked any other compilers.) -- Fritz From derek.a.elkins at gmail.com Fri Apr 4 21:49:41 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Fri Apr 4 21:45:49 2008 Subject: [Haskell-cafe] Bug in Hugs, Haskell behavior question In-Reply-To: <78B6E2AA-B213-4656-BE3C-9733CFD5871E@willamette.edu> References: <78B6E2AA-B213-4656-BE3C-9733CFD5871E@willamette.edu> Message-ID: <1207360181.19465.8.camel@derek-laptop> On Fri, 2008-04-04 at 18:34 -0700, Fritz Ruehr wrote: > In lab the other day I was showing pattern bindings to a student and > broached a limiting case, one with no variables to be bound in the > pattern. I was surprised to find that Hugs crashed when I tried a > pattern binding at top level like this: > > (2,[1,4],5) = (2,[1,4],5) > > It also crashed on the simpler: > > [2] = [2] > > On the other hand, this turns out to be acceptable: > > 2 = 2 > > In fact, even this goes through without a hitch! > > 2 = 3 > > I'm not sure from the language definition yet whether this last > should give an "Unmatched pattern" error, but if it's intended > behavior, it does look a little odd. > > Would anyone care to argue for or against allowing this? > > In any case, the more structured patterns cause the latest (Sep 06) > Hugs release to crash, with "INTERNAL ERROR: compileGlobalFunction". > > (GHC allows the strange "2 = 3" and handles the structured ones fine, > including even "(1,[2,3],4) = (4,[3,37],42)". I haven't checked any > other compilers.) Top-level bindings are irrefutable, so 2 = 3 is fine, if vacuous. From ryani.spam at gmail.com Fri Apr 4 21:53:04 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Fri Apr 4 21:48:53 2008 Subject: [Haskell-cafe] Bug in Hugs, Haskell behavior question In-Reply-To: <78B6E2AA-B213-4656-BE3C-9733CFD5871E@willamette.edu> References: <78B6E2AA-B213-4656-BE3C-9733CFD5871E@willamette.edu> Message-ID: <2f9b2d30804041853s42d62592wdcb87532261fd6cd@mail.gmail.com> On 4/4/08, Fritz Ruehr wrote: > In fact, even this goes through without a hitch! > > 2 = 3 This is hilarious. Maybe bindings that don't actually bind anything should be an error? Or at least a warning? In ghci: Prelude> let 2 = 3 -- no problem Prelude> let (2,x) = (3,4) -- no problem Prelude> x *** Exception: :1:4-16: Irrefutable pattern match failed for pattern (2,x) -- ryan From fruehr at willamette.edu Fri Apr 4 23:15:48 2008 From: fruehr at willamette.edu (Fritz Ruehr) Date: Fri Apr 4 23:11:40 2008 Subject: [Haskell-cafe] Bug in Hugs, Haskell behavior question In-Reply-To: <2f9b2d30804041853s42d62592wdcb87532261fd6cd@mail.gmail.com> References: <78B6E2AA-B213-4656-BE3C-9733CFD5871E@willamette.edu> <2f9b2d30804041853s42d62592wdcb87532261fd6cd@mail.gmail.com> Message-ID: <2EC84037-F999-4AC0-92CA-C1C59AF119F4@willamette.edu> Derek: yes, I caught this in the language description not long after hitting "send": I had forgotten about that. But then I anticipated the behavior Ryan shows below, where using a variable that's part of a "strange" pattern will cause an error (I didn't want to check it while driving home--cell phone user/drivers are bad enough!--so thanks, Ryan, for verifying :) ). In any case, opinions about the behavior aside, there is a Hugs internal error here, so I hope that much is useful. The strange cases make for interesting academic discussions, at least. -- Fritz On Fri 4 Apr 08, at 6:49 pm, Derek Elkins wrote: > Top-level bindings are irrefutable, so 2 = 3 is fine, if vacuous. On Fri 4 Apr 08, at 6:53 pm, Ryan Ingram wrote: > On 4/4/08, Fritz Ruehr wrote: >> In fact, even this goes through without a hitch! >> >> 2 = 3 > > This is hilarious. > > Maybe bindings that don't actually bind anything should be an error? > Or at least a warning? > > In ghci: > > Prelude> let 2 = 3 > -- no problem > Prelude> let (2,x) = (3,4) > -- no problem > Prelude> x > *** Exception: :1:4-16: Irrefutable pattern match failed > for pattern (2,x) > > -- ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080404/8fc1ca82/attachment.htm From allbery at ece.cmu.edu Fri Apr 4 23:21:30 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Apr 4 23:17:21 2008 Subject: [Haskell-cafe] Bug in Hugs, Haskell behavior question In-Reply-To: <2EC84037-F999-4AC0-92CA-C1C59AF119F4@willamette.edu> References: <78B6E2AA-B213-4656-BE3C-9733CFD5871E@willamette.edu> <2f9b2d30804041853s42d62592wdcb87532261fd6cd@mail.gmail.com> <2EC84037-F999-4AC0-92CA-C1C59AF119F4@willamette.edu> Message-ID: <2EE6D8BE-3FF5-4B84-874D-D44B66D68B72@ece.cmu.edu> On Apr 4, 2008, at 23:15 , Fritz Ruehr wrote: > In any case, opinions about the behavior aside, there is a Hugs > internal error here, so I hope that much is useful. I am not greatly surprised by that: a numeric constant like `2' is really a polymorphic value `(fromInteger 2 :: Num a => a)' per the Report, and if Hugs does that conversion at the wrong time then it might well end up attempting to turn a function call into a pattern (normally impossible in Haskell, as any attempt would either shadow the function or raise a syntax error). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From peteg42 at gmail.com Sat Apr 5 00:11:20 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Sat Apr 5 00:07:28 2008 Subject: [Haskell-cafe] Re: HDBC, character encoding In-Reply-To: References: <257E3FFB-EF08-4D64-8AD5-4034A2F2250B@inf.fu-berlin.de> Message-ID: <1D9A494D-82AE-4608-B1FF-D04BE16173FA@gmail.com> On 04/04/2008, at 9:27 PM, John Goerzen wrote: > > I can see this being a performance and ease-of-use win in some > situations. I don't think it's an actual feature difference, though. > If you can represent it as a [Word8], you can represent it as a > [Char], and it will be converted to the same underlying data for the > trip through FFI. Sure. I prefer to keep things separate: Char is for Unicode characters, [Word8]/ByteString is for concrete representations. It's more about type safety than efficiency. cheers peter From v.reshetnikov at gmail.com Sat Apr 5 04:00:59 2008 From: v.reshetnikov at gmail.com (Vladimir Reshetnikov) Date: Sat Apr 5 03:56:51 2008 Subject: [Haskell-cafe] Strange behavior of float literals Message-ID: <4770d2590804050100p1cb6e3c1p8867543af13a25c7@mail.gmail.com> The float literal 1e-100000000000000000000000000000000000000000000 in GHC evaluates to 1.0, and 1e-999999999999999999999999999999999999999999999 evaluates to 10.0. Is it a bug, or a documented overflow behavior? What it the correct place to submit bug reports concerning GHC? -- Thank you, Vladimir Reshetnikov (aka nikov), Microsoft MVP From dbenbenn at gmail.com Sat Apr 5 04:46:23 2008 From: dbenbenn at gmail.com (David Benbennick) Date: Sat Apr 5 04:42:12 2008 Subject: [Haskell-cafe] Strange behavior of float literals In-Reply-To: <4770d2590804050100p1cb6e3c1p8867543af13a25c7@mail.gmail.com> References: <4770d2590804050100p1cb6e3c1p8867543af13a25c7@mail.gmail.com> Message-ID: On Sat, Apr 5, 2008 at 1:00 AM, Vladimir Reshetnikov wrote: > The float literal 1e-100000000000000000000000000000000000000000000 in > GHC evaluates to 1.0, and > 1e-999999999999999999999999999999999999999999999 evaluates to 10.0. > Is it a bug, or a documented overflow behavior? Sounds like a bug to me. I wasn't able to test your example in GHCi because it started consuming all my memory. In GHCi 6.8.2 I got: Prelude> let x = 1e-1000000 *** Exception: stack overflow I tried compiling the following program with "ghc -O --make", and it again started consuming all memory: x = 1e-100000000 :: Double main = print x > What it the correct place to submit bug reports concerning GHC? http://hackage.haskell.org/trac/ghc/wiki/ReportABug -- I'm doing Science and I'm still alive. From miguelimo38 at yandex.ru Sat Apr 5 04:58:24 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Sat Apr 5 04:54:22 2008 Subject: [Haskell-cafe] Strange behavior of float literals In-Reply-To: <4770d2590804050100p1cb6e3c1p8867543af13a25c7@mail.gmail.com> References: <4770d2590804050100p1cb6e3c1p8867543af13a25c7@mail.gmail.com> Message-ID: <71EED083-634E-4006-92A8-055C2B90638F@yandex.ru> I don't know if it is a bug, but 100000000000000000000000000000000000000000000 = 0 (mod 2^32), so, if GHC considers exponent as Int (not Integer), then it's the same as 1e0 = 1. In the same way, 999999999999999999999999999999999999999999999 = -1 (mod 2^32), and 1e-(-1) = 1e1 = 10. Note also that the function "exponent" from the RealFloat class has the type exponent :: a -> Int On 5 Apr 2008, at 12:00, Vladimir Reshetnikov wrote: > The float literal 1e-100000000000000000000000000000000000000000000 in > GHC evaluates to 1.0, and > 1e-999999999999999999999999999999999999999999999 evaluates to 10.0. > Is it a bug, or a documented overflow behavior? > > What it the correct place to submit bug reports concerning GHC? > -- > Thank you, > > Vladimir Reshetnikov (aka nikov), > Microsoft MVP > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From jinwoo68 at gmail.com Sat Apr 5 09:23:08 2008 From: jinwoo68 at gmail.com (Jinwoo Lee) Date: Sat Apr 5 09:18:55 2008 Subject: [Haskell-cafe] Re: Doing without IORef In-Reply-To: <47F65DC3.1080902@serpentine.com> References: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> <7070515b0804031814y18dfe594g235e5023de7e3dc0@mail.gmail.com> <20080404010707.b4hmrd149w4okc8k@webmail.spamcop.net> <7070515b0804040228p7775ff5ck8f1ec22a9b9498f9@mail.gmail.com> <47F65DC3.1080902@serpentine.com> Message-ID: <7070515b0804050623w1f036628we8161ca4d7c16def@mail.gmail.com> Thanks Bryan, To summarize, embed IORef inside ReaderT and use that IORef to read/change the file path info, both in IO monad and MyState monad. Is this right? Thank you all! jinwoo On Sat, Apr 5, 2008 at 1:56 AM, Bryan O'Sullivan wrote: > Jinwoo Lee wrote: > > > I haven't used ReaderT. What are the advantages when using ReaderT > > instead of StateT in this case? > > A StateT lets you replace one IORef with another, since it gives you > mutable state. A ReaderT gives you *immutable* state, so the type > system guarantees that you'll always be using the same IORef. > > -- Jinwoo Lee Always remember that you are unique. Just like everyone else. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080405/fde546d5/attachment.htm From bos at serpentine.com Sat Apr 5 10:49:19 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sat Apr 5 10:45:06 2008 Subject: [Haskell-cafe] Re: Doing without IORef In-Reply-To: <7070515b0804050623w1f036628we8161ca4d7c16def@mail.gmail.com> References: <7070515b0804030303l1e859759l728a759834aaccdd@mail.gmail.com> <7070515b0804031814y18dfe594g235e5023de7e3dc0@mail.gmail.com> <20080404010707.b4hmrd149w4okc8k@webmail.spamcop.net> <7070515b0804040228p7775ff5ck8f1ec22a9b9498f9@mail.gmail.com> <47F65DC3.1080902@serpentine.com> <7070515b0804050623w1f036628we8161ca4d7c16def@mail.gmail.com> Message-ID: <47F7916F.20409@serpentine.com> Jinwoo Lee wrote: > To summarize, embed IORef inside ReaderT and use that IORef to > read/change the file path info, both in IO monad and MyState monad. Is > this right? Yep. In case you ever want to multithread your program, you might want to use an MVar instead of an IORef. Call for Talks and Tutorials ACM SIGPLAN 2008 Developer Tracks on Functional Programming http://www.deinprogramm.de/defun-2008/ Victoria, BC, Canada, 25, 27 September, 2008 The workshop will be held in conjunction with ICFP 2008. http://www.icfpconference.org/icfp2008/ Important dates Proposal Deadline: June 27, 2008, 0:00 UTC Notification: July 14, 2008 DEFUN 2008 invites functional programmers who know how to solve problems with functional prorgamming to give talks and lead tutorials at the The ICFP Developer Tracks. We want to know about your favorite programming techniques, powerful libraries, and engineering approaches you've used that the world should know about and apply to other projects. We want to know how to be productive using functional programming, write better code, and avoid common pitfals. We invite proposals for presentations in the following categories: How-to talks: 45-minute "how-to" talks that provide specific information on how to solve specific problems using functional programming. These talks focus on concrete examples, but provide useful information for developers working on different projects or in different contexts. Examples: - "How I made Haskell an extension language for SAP R/3." - "How I replaced /sbin/init by a Scheme program." - "How I hooked up my home appliances to an Erlang control system." - "How I got an SML program to drive my BMW." General language tutorials Half-day general language tutorials for specific functional languages, given by recognized experts for the respective languages. Technology tutorials Half-day tutorials on techniques, technologies, or solving specific problems in functional programming such as: - how to make the best use of specific FP programming techniques - how to inject FP into a development team used to more conventional technologies - how to connect FP to existing libraries / frameworks / platforms - how to deliver high-performance systems with FP - how to deliver high-reliability systems with FP Remember that your audience will include computing professionals who are not academics and who may not already be experts on functional programming. Presenters of tutorials will receive free registration to ICFP 2008. Submission guidelines Submit a proposal of 150 words or less for either a 45-minute talk with a short Q&A session at the end, or a 300-word-or-less proposal for a 3-hour tutorial, where you present your material, but also give participants a chance to practice it on their own laptops. Some advice: - Give it a simple and straightforward title or name; avoid fancy titles or puns that would make it harder for attendees to figure out what you'll be talking about. - Clearly identify the level of the talk: What knowledge should people have when they come to the presentation or tutorial? - Explain why people will want to attend: is the language or library useful for a wide range of attendees? Is the pitfall you're identifying common enough that a wide range of attendees is likely to encounter it? - Explain what benefits attendees are expected to take home to their own projects. - For a tutorial, explain how you want to structure the time, and what you expect to have attendees to do on their laptops. List what software you'll expect attendees to have installed prior to coming. Submit your proposal in plain text electronically to defun-2008-submission-AT-deinprogramm.de by the beginning of Friday, June 27, Universal Coordinated Time. Organizers Kathleen Fisher AT&T Labs Simon Peyton Jones Microsoft Research Mike Sperber (co-chair) DeinProgramm Don Stewart (co-chair) Galois From gwern0 at gmail.com Sat Apr 5 12:43:48 2008 From: gwern0 at gmail.com (gwern0@gmail.com) Date: Sat Apr 5 12:40:21 2008 Subject: [Haskell-cafe] Re: [Haskell] Some old and quite old news. In-Reply-To: <47F781A8.3010505@ipmce.ru> References: <47F37E69.4060203@ipmce.ru> <20080404174538.GA912259@localhost> <47F781A8.3010505@ipmce.ru> Message-ID: <20080405164348.GA467797@localhost> On 2008.04.05 17:42:00 +0400, Serguey Zefirov scribbled 0.6K characters: > gwern0@gmail.com ?????: >> Hmm. I'm having trouble getting it through SVN: >> >> gwern@localhost:1003~>svn co http://thesz.mskhug.ru/browser/hiersort [ >> 1:44PM] >> svn: PROPFIND request failed on '/browser/hiersort' >> svn: PROPFIND of '/browser/hiersort': 200 OK (http://thesz.mskhug.ru) >> >> Is there some trick that as a Darcser I don't know about? >> > Actually, I do not know too. Maybe, just a version mismatch? > > Did you tried to access files using just a web browser? > > I CC'd that to myself at home and will try to resolve matters ASAP. At > least I will make a tarball and post it somewhere at MskHUG website. > > Thank you for your interest. ;) Well, I looked at some of the files with a browser, and that worked fine. It's just when I tried to do a checkout that fails. I've asked the guys in #svn, and they said the 'real' repo is elsewhere, so I went and asked #trac where the real repo's URL is. One of them said 12:37 < thatch> gwern: the faq can't cover it. Trac only knows the local filesystem path to the repo, not its web-accessible path. So I dunno. After some guessing, thatch came up with as the repo URL. It's downloading now, although slowly. -- gwern Z7 Service NSG Sayeret FIPS140-1 encryption data-haven continuous black-bag illuminati -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080405/f8270463/attachment.bin From paul at cogito.org.uk Sat Apr 5 14:05:41 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Sat Apr 5 14:01:31 2008 Subject: [Haskell-cafe] Beginners arrow question Message-ID: <47F7BF75.1060609@cogito.org.uk> I'm using arrows for the first time, with HXT. I think I'm getting the hang of it, but one problem has me stumped. I have a function "lookupFormatter" which takes a string and returns an arrow, and I want to use that arrow. Something like this: myProblem :: (ArrowXml a) -> a XmlTree String myProblem = proc xml do name <- getAttrValue "name" -< xml fmt <- arr lookupFormatter -< name fmt -< xml But I can't figure out how to do it. I get "fmt: not in scope". Can anyone help? Thanks, Paul. From miguelimo38 at yandex.ru Sat Apr 5 14:19:24 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Sat Apr 5 14:15:22 2008 Subject: [Haskell-cafe] Beginners arrow question In-Reply-To: <47F7BF75.1060609@cogito.org.uk> References: <47F7BF75.1060609@cogito.org.uk> Message-ID: You can't use variables introduced in "proc" anywhere except on the right side of "-<". OK, you actually can do this, but your arrow should be an instance of ArrowApply (which means that you don't really need it at all, since all such arrows are in fact monads). Your "myProblem" is desugared as something like arr (\xml -> (xml,xml)) >>> second (getAttrValue "name") >>> second (arr (\name -> (name,name))) >>> second (second (arr lookupFormatter)) >>> arr (\(xml,(name,fmt)) -> xml) >>> fmt On 5 Apr 2008, at 22:05, Paul Johnson wrote: > I'm using arrows for the first time, with HXT. I think I'm getting > the hang of it, but one problem has me stumped. I have a function > "lookupFormatter" which takes a string and returns an arrow, and I > want to use that arrow. Something like this: > > myProblem :: (ArrowXml a) -> a XmlTree String > myProblem = proc xml do > name <- getAttrValue "name" -< xml > fmt <- arr lookupFormatter -< name > fmt -< xml > > But I can't figure out how to do it. I get "fmt: not in scope". > > Can anyone help? > > Thanks, > > Paul. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From claudiusmaximus at goto10.org Sat Apr 5 14:27:33 2008 From: claudiusmaximus at goto10.org (Claude Heiland-Allen) Date: Sat Apr 5 14:20:03 2008 Subject: [Haskell-cafe] Beginners arrow question In-Reply-To: <47F7BF75.1060609@cogito.org.uk> References: <47F7BF75.1060609@cogito.org.uk> Message-ID: <47F7C495.1030303@goto10.org> Paul Johnson wrote: > I'm using arrows for the first time, with HXT. I think I'm getting the > hang of it, but one problem has me stumped. I have a function > "lookupFormatter" which takes a string and returns an arrow, and I want > to use that arrow. Something like this: > > myProblem :: (ArrowXml a) -> a XmlTree String > myProblem = proc xml do > name <- getAttrValue "name" -< xml > fmt <- arr lookupFormatter -< name > fmt -< xml > > But I can't figure out how to do it. I get "fmt: not in scope". ArrowApply is one way, if there is an instance for it: module Main where import Control.Arrow adder :: (Arrow a) => Int -> a Int Int adder i = arr (i+) adderUser :: (ArrowApply a, Arrow a) => a Int Int adderUser = proc x -> do a <- arr adder -< x y <- app -< (a,x) returnA -< y main = mapM_ (print . (adderUser :: (->) Int Int)) [1..10] Claude -- http://claudiusmaximus.goto10.org From conal at conal.net Sat Apr 5 17:49:07 2008 From: conal at conal.net (Conal Elliott) Date: Sat Apr 5 17:44:53 2008 Subject: [Haskell-cafe] lhs2TeX --> html? Message-ID: Has anyone fiddled with hooking up lhs2TeX a tex->html tool like jsMath, for lovely code in a web page? - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080405/df5f3192/attachment.htm From hjgtuyl at chello.nl Sat Apr 5 17:50:00 2008 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat Apr 5 17:45:55 2008 Subject: [Haskell-cafe] Problems installing OpenAL / compiling an OpenAL program Message-ID: L.S., I downloaded OpenAL from Hackage and tried to compile a program that uses it (on a Windows XP computer). I got a long list of messages in the linking phase; I found a related ticket, http://hackage.haskell.org/trac/ghc/ticket/1140 with a patch. I applied the patch manually and removed the package and installed it again. The problem remained. The output from the compiler run: ghc -Wall --make TestOpenAL.hs -i"C:\Programs\Haskell\Libs" -dcore-lint -o TestO penAL.exe [1 of 1] Compiling Main ( TestOpenAL.hs, TestOpenAL.o ) TestOpenAL.hs:57:8: Warning: This binding for `s' shadows an existing binding In a pattern binding in a 'do' expression Linking TestOpenAL.exe ... C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.8.2/libHSOpenAL-1.3.1.1.a(Buffer.o )(.text+0x1de):fake: undefined reference to `alGetBufferi@12' C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.8.2/libHSOpenAL-1.3.1.1.a(Buffer.o )(.text+0x5f7):fake: undefined reference to `alBufferData@20' C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.8.2/libHSOpenAL-1.3.1.1.a(Buffer.o )(.text+0xa4e):fake: undefined reference to `alGetBufferi@12' C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.8.2/libHSOpenAL-1.3.1.1.a(Source.o )(.text+0x1b9):fake: undefined reference to `alSourcei@12' C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.8.2/libHSOpenAL-1.3.1.1.a(Source.o )(.text+0x30d):fake: undefined reference to `alIsSource@4' Etcetera. Then I downloaded OpenAL with the command: darcs get http://darcs.haskell.org/packages/OpenAL/ Trying to install this gives: Libs\OpenAL>runhaskell Setup.hs configure Configuring OpenAL-1.3.1.1... Libs\OpenAL>runhaskell Setup.hs build Preprocessing library OpenAL-1.3.1.1... Building OpenAL-1.3.1.1... Sound/OpenAL/Config.hs:40:0: HsOpenALConfig.h: No such file or directory My questions are: 1) How do I get a proper package installed? 2) How do I find tickets for a certain package? 3) Is there an automatic way of applying patches from the tickets? 4) Is the darcs repository version incomplete? -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- From cgibbard at gmail.com Sat Apr 5 18:00:38 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Sat Apr 5 17:56:24 2008 Subject: [Haskell-cafe] Beginners arrow question In-Reply-To: <47F7BF75.1060609@cogito.org.uk> References: <47F7BF75.1060609@cogito.org.uk> Message-ID: <89ca3d1f0804051500x516a97edr648f9803f3bf02f2@mail.gmail.com> On 05/04/2008, Paul Johnson wrote: > myProblem :: (ArrowXml a) -> a XmlTree String > myProblem = proc xml do > name <- getAttrValue "name" -< xml > fmt <- arr lookupFormatter -< name > fmt -< xml > GHC has a special syntax for using ArrowApply (which HXT is an instance of). Whenever the expression to the left of -< needs to involve a local variable, you can replace -< with -<< and it should work. To understand better what it means, you can read http://www.haskell.org/ghc/docs/latest/html/users_guide/arrow-notation.html -- it's basically just a shorthand for using 'app'. > myProblem :: (ArrowXml a) -> a XmlTree String > myProblem = proc xml do > name <- getAttrValue "name" -< xml > fmt <- arr lookupFormatter -< name > fmt -<< xml Try that and see how it goes. - Cale From lrpalmer at gmail.com Sat Apr 5 19:13:11 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sat Apr 5 19:09:02 2008 Subject: [Haskell-cafe] Beginners arrow question In-Reply-To: <89ca3d1f0804051500x516a97edr648f9803f3bf02f2@mail.gmail.com> References: <47F7BF75.1060609@cogito.org.uk> <89ca3d1f0804051500x516a97edr648f9803f3bf02f2@mail.gmail.com> Message-ID: <7ca3f0160804051613k49c32bb4tcada0b179a44e564@mail.gmail.com> On Sat, Apr 5, 2008 at 4:00 PM, Cale Gibbard wrote: > GHC has a special syntax for using ArrowApply (which HXT is an > instance of). Whenever the expression to the left of -< needs to > involve a local variable, you can replace -< with -<< and it should > work. To understand better what it means, you can read > http://www.haskell.org/ghc/docs/latest/html/users_guide/arrow-notation.html Sweet! I didn't know that; I knew that ArrowApply gave you the ability to use bindings in the arrows, but it always bugged me that I couldn't even when I did have an instance. Go GHC! :-) Luke From dave at zednenem.com Sun Apr 6 01:04:31 2008 From: dave at zednenem.com (David Menendez) Date: Sun Apr 6 01:00:17 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <20080404214536.GH12163@scytale.galois.com> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> <6f9f8f4a0804040931i42040dib28bd523db349e70@mail.gmail.com> <836B0293-D3D3-4FA2-995B-6B18E4C610CA@gmail.com> <220e47b40804041436h4237d53p42a74a03d7239793@mail.gmail.com> <404396ef0804041444t194de5a9t11c518ce75612a5b@mail.gmail.com> <20080404214536.GH12163@scytale.galois.com> Message-ID: <49a77b7a0804052204y6a86797aqe7bf79c3f732749b@mail.gmail.com> On Fri, Apr 4, 2008 at 5:45 PM, Don Stewart wrote: > ndmitchell: > > Note: In case anyone gets the wrong impression, I am not suggesting > > lazy naturals be the standard numeric type in Haskell, just that by > > not going that way we have paid a cost in terms of elegance. > > > > I'd be happy if we had an (unbounded) Nat type in the first place... The problem with Nat is that we can't comfortably make it an instance of Num. (Well, that's arguably a problem with Num.) -- Dave Menendez From apfelmus at quantentunnel.de Sun Apr 6 05:27:34 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Sun Apr 6 05:23:37 2008 Subject: [Haskell-cafe] Re: Role based access control via monads or arrows or... something In-Reply-To: <20080403155130.GQ16717@darcs.net> References: <200804031022.38072.porrifolius@gmail.com> <7ca3f0160804021745p48edeac0x606416ce0af1e7d3@mail.gmail.com> <20080403131812.GP16717@darcs.net> <20080403155130.GQ16717@darcs.net> Message-ID: David Roundy wrote: > apfelmus wrote: >> David Roundy wrote: >>> porrifolius wrote: >>>> (7) ideally required permissions would appear (and accumulate) in >>>> type signatures via inference so application code knows which are >>>> required and type checker can reject static/dynamic role constraint >>>> violations >> >> In other words, I fail to see how this GADT example is different from a >> normal phantom type (modulo different naming) > > The difference is that I can inspect at runtime what permissions I have. I > see that I didn't demonstrate this. You can introduce a function > > checkPerms :: HavePermission p -> HavePermission p' -> EqCheck > checkPerms HaveAPerm HaveAPerm = IsEq > checkPerms HaveBPerm HaveBPerm = IsEq > checkPerms _ _ = NotEq > > data EqCheck a b where > IsEq :: EqCheck a a > NotEq :: EqCheck a b > > which allows you to compare permissions at runtime and make use of them. Ah, so you are able to use case expressions casePerm :: (Permission Low -> a) -> (Permission High -> a) -> Permission any -> a which is not possible with a plain phantom type approach. One example use would be foo :: Permission p -> Either String Bar foo = casePerm (const $ Left "foo: permission too low") (\p -> readRestricted p ... ) Of course, you may not export HaveAPerm and HaveBPerm (at least not for construction, only for pattern matching), so you probably need such a special function casePerm anyway. Regards, apfelmus From wss at cs.nott.ac.uk Sun Apr 6 05:41:45 2008 From: wss at cs.nott.ac.uk (Wouter Swierstra) Date: Sun Apr 6 05:37:31 2008 Subject: [Haskell-cafe] Role based access control via monads or arrows or... something In-Reply-To: <200804031022.38072.porrifolius@gmail.com> References: <200804031022.38072.porrifolius@gmail.com> Message-ID: > Any help you can offer for my aching cranium will be _much_ > appreciated. You might also be interested in the paper Edwin Brady and Kevin Hammond just submitted to ICFP: http://www.cs.st-andrews.ac.uk/~eb/drafts/icfp08.pdf It describes how to manage resources, in particular locks, in a dependently-typed language. You didn't explicitly mention that it needed to be in Haskell, so it might be worth having a look. Best of luck, Wouter From t.h at gmx.info Sun Apr 6 08:07:22 2008 From: t.h at gmx.info (Timo B. =?utf-8?q?H=C3=BCbel?=) Date: Sun Apr 6 08:03:20 2008 Subject: [Haskell-cafe] ANN: Hayoo! beta 0.1 Message-ID: <200804061407.22507.t.h@gmx.info> Hello, we are pleased to announce the first beta release of Hayoo!, a Haskell API search engine providing advanced features like suggestions, find-as-you-type, fuzzy queries and much more. Visit Hayoo! here: http://holumbus.fh-wedel.de/hayoo Please bear in mind that this is still a beta release and we are continuously working on further improvements. Our plans for the future include: - Covering all documentation available at Hackage. - Compatibility with non-JavaScript enabled browsers. - Providing a web interface where people can point Hayoo! to an URI linking to Haddock documentation which will be automatically included in Hayoo!. Hayoo! was developed as a use-case for the Holumbus framework, which aims to help at the creation of very flexible and highly specialized search engines. Although Holumbus is still under heavy development and we have no official release yet, some informations and a Darcs repository are available at the Holumbus homepage: http://holumbus.fh-wedel.de Any suggestions and feedback is highly welcomed. Cheers, Timo B. H?bel & Sebastian M. Schlatt From john at repetae.net Sun Apr 6 10:12:24 2008 From: john at repetae.net (John Meacham) Date: Sun Apr 6 10:08:08 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> Message-ID: <20080406141224.GD31945@sliver.repetae.net> On Fri, Apr 04, 2008 at 04:46:22PM +0100, Neil Mitchell wrote: > Where length xs = 1 and ys = 1000. This takes 1000 steps to tell the > Int's aren't equal, since we don't have proper lazy naturals. If we > did, it would take 2 steps. > > Read this: http://citeseer.ist.psu.edu/45669.html - it argues the > point I am trying to make, but much better. I implemented this efficient lazy natural class once upon a time. it even has things like lazy multiplication: -- Copyright (c) 2007 John Meacham (john at repetae dot net) -- -- Permission is hereby granted, free of charge, to any person obtaining a -- copy of this software and associated documentation files (the -- "Software"), to deal in the Software without restriction, including -- without limitation the rights to use, copy, modify, merge, publish, -- distribute, sublicense, and/or sell copies of the Software, and to -- permit persons to whom the Software is furnished to do so, subject to -- the following conditions: -- -- The above copyright notice and this permission notice shall be included -- in all copies or substantial portions of the Software. -- -- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS -- OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF -- MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY -- CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, -- TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE -- SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -- efficient lazy naturals module Util.LazyNum where -- Nat data type is eqivalant to a type restricted lazy list that is strict in -- its elements. -- -- Invarients: (Sum x _) => x > 0 -- in particular (Sum 0 _) is _not_ valid and must not occur. data Nat = Sum !Integer Nat | Zero deriving(Show) instance Eq Nat where Zero == Zero = True Zero == _ = False _ == Zero = False Sum x nx == Sum y ny = case compare x y of EQ -> nx == ny LT -> nx == Sum (y - x) ny GT -> Sum (x - y) nx == ny instance Ord Nat where Zero <= _ = True _ <= Zero = False Sum x nx <= Sum y ny = case compare x y of EQ -> nx <= ny LT -> nx <= Sum (y - x) ny GT -> Sum (x - y) nx <= ny Zero `compare` Zero = EQ Zero `compare` _ = LT _ `compare` Zero = GT Sum x nx `compare` Sum y ny = case compare x y of EQ -> nx `compare` ny LT -> nx `compare` Sum (y - x) ny GT -> Sum (x - y) nx `compare` ny x < y = not (x >= y) x >= y = y <= x x > y = y < x instance Num Nat where Zero + y = y Sum x n1 + y = Sum x (y + n1) --x + Zero = x --Sum x n1 + Sum y n2 = Sum (x + y) (n1 + n2) Zero - _ = zero x - Zero = x Sum x n1 - Sum y n2 = case compare x y of GT -> Sum (x - y) n1 - n2 EQ -> n1 - n2 LT -> n1 - Sum (y - x) n2 negate _ = zero abs x = x signum Zero = zero signum _ = one fromInteger x = if x <= 0 then zero else Sum x Zero Zero * _ = Zero _ * Zero = Zero (Sum x nx) * (Sum y ny) = Sum (x*y) ((f x ny) + (nx * (fint y + ny))) where f y Zero = Zero f y (Sum x n) = Sum (x*y) (f y n) instance Real Nat where toRational n = toRational (toInteger n) instance Enum Nat where succ x = Sum 1 x pred Zero = Zero pred (Sum n x) = if n == 1 then x else Sum (n - 1) x enumFrom x = x:[ Sum n x | n <- [1 ..]] enumFromThen x y = x:y:f (y + z) where z = y - x f x = x:f (x + z) toEnum = fromIntegral fromEnum = fromIntegral -- d > 0 doDiv :: Nat -> Integer -> Nat doDiv n d = f 0 n where f _ Zero = 0 f cm (Sum x nx) = sum d (f m nx) where (d,m) = (x + cm) `quotRem` d sum 0 x = x sum n x = Sum n x doMod :: Nat -> Integer -> Nat doMod n d = f 0 n where f 0 Zero = Zero f r Zero = fint r f r (Sum x nx) = f ((r + x) `rem` d) nx instance Integral Nat where _ `div` Zero = infinity n1 `div` n2 | n1 < n2 = 0 | otherwise = doDiv n1 (toInteger n2) n1 `mod` Zero = n1 -- XXX n1 `mod` n2 | n1 < n2 = n1 | otherwise = doMod n1 (toInteger n2) n `divMod` Zero = (infinity,n) n `divMod` d | n < d = (0,n) | otherwise = let d' = toInteger d in (doDiv n d',doMod n d') quotRem = divMod quot = div rem = mod toInteger n = f 0 n where f n _ | n `seq` False = undefined f n Zero = n f n (Sum x n1) = let nx = n + x in nx `seq` f nx n1 -- convert to integer unless it is too big, in which case Nothing is returned natToInteger :: Integer -> Nat -> Maybe Integer natToInteger limit n = f 0 n where f n _ | n > limit = Nothing f n Zero = Just n f n (Sum x n1) = let nx = n + x in nx `seq` f nx n1 natShow :: Nat -> String natShow n = case natToInteger bigNum n of Nothing -> "(too big)" Just v -> show v natFoldr :: (Integer -> b -> b) -> b -> Nat -> b natFoldr cons nil n = f n where f Zero = nil f (Sum x r) = cons x (f r) -- some utility routines natEven :: Nat -> Bool natEven n = f True n where f r Zero = r f r (Sum x n) = if even x then f r n else f (not r) n natOdd :: Nat -> Bool natOdd n = not (natEven n) {-# RULES "even/natEven" even = natEven #-} {-# RULES "odd/natOdd" odd = natOdd #-} zero = Zero one = Sum 1 Zero infinity = Sum bigNum infinity bigNum = 100000000000 fint x = Sum x Zero -- random testing stuff for ghci ti op x y = (toInteger $ x `op` y, toInteger x `op` toInteger y) depth n | n <= 0 = error "depth exceeded" | otherwise = Sum n (depth $ n - 1) depth' n | n <= 0 = Zero | otherwise = Sum n (depth' $ n - 1) From felipe.lessa at gmail.com Sun Apr 6 10:30:20 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Sun Apr 6 10:26:04 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <20080406141224.GD31945@sliver.repetae.net> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> <20080406141224.GD31945@sliver.repetae.net> Message-ID: On Sun, Apr 6, 2008 at 11:12 AM, John Meacham wrote: > I implemented this efficient lazy natural class once upon a time. it > even has things like lazy multiplication: [...] > instance Num Nat where > Zero + y = y > Sum x n1 + y = Sum x (y + n1) > --x + Zero = x > --Sum x n1 + Sum y n2 = Sum (x + y) (n1 + n2) [...] May I ask you why the last line above was commented out? Thanks! -- Felipe. From r.kelsall at millstream.com Sun Apr 6 10:38:03 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Sun Apr 6 10:33:49 2008 Subject: [Haskell-cafe] ANN: Hayoo! beta 0.1 In-Reply-To: <200804061407.22507.t.h@gmx.info> References: <200804061407.22507.t.h@gmx.info> Message-ID: <47F8E04B.5060104@millstream.com> Timo B. H?bel wrote: > Hello, > > we are pleased to announce the first beta release of Hayoo!, a Haskell API > search engine providing advanced features like suggestions, find-as-you-type, > fuzzy queries and much more. > > Visit Hayoo! here: http://holumbus.fh-wedel.de/hayoo > > Please bear in mind that this is still a beta release and we are continuously > working on further improvements. Our plans for the future include: > > - Covering all documentation available at Hackage. > - Compatibility with non-JavaScript enabled browsers. Yes please. > - Providing a web interface where people can point Hayoo! to an URI linking > to Haddock documentation which will be automatically included in Hayoo!. > > Hayoo! was developed as a use-case for the Holumbus framework, which aims to > help at the creation of very flexible and highly specialized search engines. > > Although Holumbus is still under heavy development and we have no official > release yet, some informations and a Darcs repository are available at the > Holumbus homepage: http://holumbus.fh-wedel.de > > Any suggestions and feedback is highly welcomed. > Really like it. Looks very smart. Thank you! Little detail : After visiting a page that appears in the search results then doing a back button the search I did is no longer there. (On my eccentric Firefox setup anyway.) > Cheers, > Timo B. H?bel & Sebastian M. Schlatt From t.h at gmx.info Sun Apr 6 12:24:56 2008 From: t.h at gmx.info (Timo B. =?utf-8?q?H=C3=BCbel?=) Date: Sun Apr 6 12:20:43 2008 Subject: [Haskell-cafe] ANN: Hayoo! beta 0.1 In-Reply-To: <47F8E04B.5060104@millstream.com> References: <200804061407.22507.t.h@gmx.info> <47F8E04B.5060104@millstream.com> Message-ID: <200804061824.56919.t.h@gmx.info> On Sunday 06 April 2008 16:38:03 Richard Kelsall wrote: > Little detail : After visiting a page that appears in the search results > then doing a back button the search I did is no longer there. (On my > eccentric Firefox setup anyway.) Hm, that's strange. I know about this problem when using Konqueror, but my Firefox (Linux, 2.0.0.13) keeps the results even after visiting the documentation and hitting the back button. Which Firefox version do you use? From felipe.lessa at gmail.com Sun Apr 6 12:30:36 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Sun Apr 6 12:26:23 2008 Subject: [Haskell-cafe] ANN: Hayoo! beta 0.1 In-Reply-To: <200804061824.56919.t.h@gmx.info> References: <200804061407.22507.t.h@gmx.info> <47F8E04B.5060104@millstream.com> <200804061824.56919.t.h@gmx.info> Message-ID: On Sun, Apr 6, 2008 at 1:24 PM, Timo B. H?bel wrote: > Hm, that's strange. I know about this problem when using Konqueror, but my > Firefox (Linux, 2.0.0.13) keeps the results even after visiting the > documentation and hitting the back button. My Epiphany works fine. Anyway, I can't use back and forward to navigate between my searches (i.e. while on Hayoo!, pressing Back takes me to the page I was before going to Hayoo! instead of the page inside Hayoo! I was before reaching that point). It would be very nice if it was a history-friendly site. Keep up the good work! =) Thanks, -- Felipe. From r.kelsall at millstream.com Sun Apr 6 12:40:08 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Sun Apr 6 12:35:54 2008 Subject: [Haskell-cafe] ANN: Hayoo! beta 0.1 In-Reply-To: <200804061824.56919.t.h@gmx.info> References: <200804061407.22507.t.h@gmx.info> <47F8E04B.5060104@millstream.com> <200804061824.56919.t.h@gmx.info> Message-ID: <47F8FCE8.30809@millstream.com> Timo B. H?bel wrote: > On Sunday 06 April 2008 16:38:03 Richard Kelsall wrote: >> Little detail : After visiting a page that appears in the search results >> then doing a back button the search I did is no longer there. (On my >> eccentric Firefox setup anyway.) > > Hm, that's strange. I know about this problem when using Konqueror, but my > Firefox (Linux, 2.0.0.13) keeps the results even after visiting the > documentation and hitting the back button. > > Which Firefox version do you use? > I'm still on the old Firefox 1.5.0.5 : Mozilla/5.0 (X11; U; OpenBSD i386; en-US; rv:1.8.0.5) Gecko/20060902 Firefox/1.5.0.5 I expect most people have upgraded to by now so I wouldn't worry about it if it works in the new version. I just tried again switching off my Adblock and switching on Java and Javascript, but couldn't seem to get anything except a blank search page after clicking the back button. Maybe just my strange setup. Richard. From dons at galois.com Sun Apr 6 13:51:41 2008 From: dons at galois.com (Don Stewart) Date: Sun Apr 6 13:47:30 2008 Subject: [Haskell-cafe] ANN: Hayoo! beta 0.1 In-Reply-To: <200804061407.22507.t.h@gmx.info> References: <200804061407.22507.t.h@gmx.info> Message-ID: <20080406175141.GA25099@scytale.galois.com> t.h: > Hello, > > we are pleased to announce the first beta release of Hayoo!, a Haskell API > search engine providing advanced features like suggestions, find-as-you-type, > fuzzy queries and much more. > > Visit Hayoo! here: http://holumbus.fh-wedel.de/hayoo > > Please bear in mind that this is still a beta release and we are continuously > working on further improvements. Our plans for the future include: > > - Covering all documentation available at Hackage. > - Compatibility with non-JavaScript enabled browsers. > - Providing a web interface where people can point Hayoo! to an URI linking > to Haddock documentation which will be automatically included in Hayoo!. > > Hayoo! was developed as a use-case for the Holumbus framework, which aims to > help at the creation of very flexible and highly specialized search engines. > > Although Holumbus is still under heavy development and we have no official > release yet, some informations and a Darcs repository are available at the > Holumbus homepage: http://holumbus.fh-wedel.de > > Any suggestions and feedback is highly welcomed. > Very very nice! And with HPC coverage details! http://holumbus.fh-wedel.de/coverage/hpc_index.html Excellent work guys. -- Don From ganesh at earth.li Sun Apr 6 15:04:47 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sun Apr 6 15:00:30 2008 Subject: [Haskell-cafe] type families and type signatures Message-ID: Hi, The following program doesn't compile in latest GHC HEAD, although it does if I remove the signature on foo'. Is this expected? Cheers, Ganesh {-# LANGUAGE TypeFamilies #-} module Test7 where type family Id a type instance Id Int = Int foo :: Id a -> Id a foo = id foo' :: Id a -> Id a foo' = foo From t.h at gmx.info Sun Apr 6 15:44:57 2008 From: t.h at gmx.info (Timo B. =?utf-8?q?H=C3=BCbel?=) Date: Sun Apr 6 15:40:46 2008 Subject: [Haskell-cafe] ANN: Hayoo! beta 0.1 In-Reply-To: <47F916ED.7010909@daimi.au.dk> References: <200804061407.22507.t.h@gmx.info> <47F916ED.7010909@daimi.au.dk> Message-ID: <200804062144.57978.t.h@gmx.info> On Sunday 06 April 2008 20:31:09 you wrote: > Overall feedback: Cool! So far, I like Hayoo!, and I'm therefore > interested in Holumbus. Is there some technical overview available? Currently, only what you can find on http://holumbus.fh-wedel.de but we will try to extend the site in the near future. > transcript of my short test of hayoo, including nitty-picky feedback: > [...] Thanks for this extensive feedback, some of these are known issues we're already working on which will be fixed soon. The others are on my TODO list now :) Regards, Timo From batterseapower at hotmail.com Sun Apr 6 16:09:46 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Sun Apr 6 16:05:30 2008 Subject: [Haskell-cafe] Re: [Haskell] ANN: Hayoo! beta 0.1 In-Reply-To: <200804061407.22507.t.h@gmx.info> References: <200804061407.22507.t.h@gmx.info> Message-ID: <9d4d38820804061309g7f906d69w5a90736fad2b99de@mail.gmail.com> On 06/04/2008, Timo B. H?bel wrote: > Hello, > > we are pleased to announce the first beta release of Hayoo!, a Haskell API > search engine providing advanced features like suggestions, find-as-you-type, > fuzzy queries and much more. Very nice! I'm not sure if this is documented or not, but for those interested in creating a search template for Firefox, Quicksilver and the like, it is possible to use a URL such as this to enter a search term: http://holumbus.fh-wedel.de/hayoo/hayoo.html?query=catmaybes Cheers, Max From dons at galois.com Sun Apr 6 16:14:19 2008 From: dons at galois.com (Don Stewart) Date: Sun Apr 6 16:10:06 2008 Subject: [Haskell-cafe] ANN: Hayoo! beta 0.1 In-Reply-To: <200804061407.22507.t.h@gmx.info> References: <200804061407.22507.t.h@gmx.info> Message-ID: <20080406201419.GE25099@scytale.galois.com> t.h: > Hello, > > we are pleased to announce the first beta release of Hayoo!, a Haskell API > search engine providing advanced features like suggestions, find-as-you-type, > fuzzy queries and much more. > > Visit Hayoo! here: http://holumbus.fh-wedel.de/hayoo > > Please bear in mind that this is still a beta release and we are continuously > working on further improvements. Our plans for the future include: > > - Covering all documentation available at Hackage. > - Compatibility with non-JavaScript enabled browsers. > - Providing a web interface where people can point Hayoo! to an URI linking > to Haddock documentation which will be automatically included in Hayoo!. > > Hayoo! was developed as a use-case for the Holumbus framework, which aims to > help at the creation of very flexible and highly specialized search engines. > > Although Holumbus is still under heavy development and we have no official > release yet, some informations and a Darcs repository are available at the > Holumbus homepage: http://holumbus.fh-wedel.de Also, I see you have the QuickCheck and cabal badges, but your HPC use also qualifies for: http://projects.unsafeperformio.com/hpc/hpcbadge.jpg I'd argue :) From t.h at gmx.info Sun Apr 6 16:21:11 2008 From: t.h at gmx.info (Timo B. =?iso-8859-1?q?H=FCbel?=) Date: Sun Apr 6 16:16:59 2008 Subject: [Haskell-cafe] Re: [Haskell] ANN: Hayoo! beta 0.1 In-Reply-To: <9d4d38820804061309g7f906d69w5a90736fad2b99de@mail.gmail.com> References: <200804061407.22507.t.h@gmx.info> <9d4d38820804061309g7f906d69w5a90736fad2b99de@mail.gmail.com> Message-ID: <200804062221.11347.t.h@gmx.info> > I'm not sure if this is documented or not, but for those interested in > creating a search template for Firefox, Quicksilver and the like, it > is possible to use a URL such as this to enter a search term: > > http://holumbus.fh-wedel.de/hayoo/hayoo.html?query=catmaybes Well, it is not really documented, but if you visit the Hayoo! page using Firefox, it is possible to add Hayoo! as search engine to the small search box in the upper right corner using the drop down menu. Timo From kha-list-haskell-cafe at hemma.treskal.com Sun Apr 6 18:24:10 2008 From: kha-list-haskell-cafe at hemma.treskal.com (Karl =?iso-8859-1?Q?Hasselstr=F6m?=) Date: Sun Apr 6 18:19:54 2008 Subject: [Haskell-cafe] problems building hpodder Message-ID: <20080406222410.GA8408@diana.vm.bytemark.co.uk> I'm trying to build hpodder 1.1.2 with ghc 6.8.2. I successfully downloaded, built, and installed (the latest versions of) all its dependencies, but when building hpodder itself, I get FeedParser.hs:146:26: `Content' is not applied to enough type arguments Expected kind `??', but `Content' has kind `* -> *' In the type `Content -> Either String String' In the type `String -> Content -> Either String String' In the type signature for `strof_either': strof_either :: String -> Content -> Either String String I don't know enough Haskell to even determine what kind of problem this is -- wrong version of some dependency? Wrong version of ghc? Help appreciated. :-) ( FWIW, the hackage auto-builder thingie seems to have the exact same problem I have: http://hackage.haskell.org/packages/archive/hpodder/1.1.2/logs/failure/ghc-6.8 ) -- Karl Hasselstr?m, kha@treskal.com www.treskal.com/kalle From thomas.dubuisson at gmail.com Sun Apr 6 18:39:02 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Sun Apr 6 18:24:52 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: References: Message-ID: <1207521542.2438.17.camel@Clunker> Id is an operation over types yielding a type, as such it doesn't make much sense to me to have (Id a -> Id a) but rather something like (a -> Id a). One could make this compile by adding the obvious instance: > type instance Id a = a Curiously, is this a reduction from a real world use of families? I just can't think of how a (Fam a -> Fam a) function would be of use. Cheers, Thomas Ganesh Sittampalam wrote: > The following program doesn't compile in latest GHC HEAD, although it does > if I remove the signature on foo'. Is this expected? > > Cheers, > > Ganesh > > {-# LANGUAGE TypeFamilies #-} > module Test7 where > > type family Id a > > type instance Id Int = Int > > foo :: Id a -> Id a > foo = id > > foo' :: Id a -> Id a > foo' = foo > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From igloo at earth.li Sun Apr 6 18:50:02 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Apr 6 18:45:46 2008 Subject: [Haskell-cafe] ANNOUNCE: Well-Typed LLP - The Haskell Consultants Message-ID: <20080406225002.GA15145@matrix.chaos.earth.li> Fellow Haskellers, We (Bj?rn Bringert, Duncan Coutts and Ian Lynagh) are pleased to announce that we have recently set up a Haskell consultancy company, Well-Typed LLP (http://www.well-typed.com/). Our services include application development, library and tool maintenance, project advice, and training. Please see our website or drop us an e-mail for more details. We look forward to hearing from you in the future! -- Bj?rn Bringert, Duncan Coutts, Ian Lynagh http://www.well-typed.com/ info@well-typed.com From bulat.ziganshin at gmail.com Sun Apr 6 18:57:09 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Apr 6 18:56:37 2008 Subject: [Haskell-cafe] ANNOUNCE: Well-Typed LLP - The Haskell Consultants In-Reply-To: <20080406225002.GA15145@matrix.chaos.earth.li> References: <20080406225002.GA15145@matrix.chaos.earth.li> Message-ID: <161445998.20080407025709@gmail.com> Hello Ian, Monday, April 7, 2008, 2:50:02 AM, you wrote: > We (Bjorn Bringert, Duncan Coutts and Ian Lynagh) are pleased to > announce that we have recently set up a Haskell consultancy company, > Well-Typed LLP (http://www.well-typed.com/). my congrats! seems you are first in this business :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From nominolo at googlemail.com Sun Apr 6 19:15:44 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Sun Apr 6 19:11:35 2008 Subject: [Haskell-cafe] REMINDER: Next Hackathon (Hac4) starts in 4 days Message-ID: <405BB5B0-08E4-4A3A-8061-E680B0D045C3@googlemail.com> Hi Haskell Hackers! There are only 4 days left until the fourth Hackathon (http:// www.haskell.org/haskellwiki/Hac4) at Chalmers University in Gothenburg, Sweden. If you haven't registered, yet, please do so now! Registration deadline: Tuesday, April 8, 2008 To register, go to http://www.haskell.org/haskellwiki/Hac4/Register and follow the steps. For all those already registered, here's a short (not nearly complete) checklist: * Make sure you have an account on code.haskell.org. (See http:// www.haskell.org/haskellwiki/Hac4/Projects for how to do that.) * Decide what to work on if you haven't yet. (See http:// www.haskell.org/haskellwiki/Hac4/Projects for ideas.) * Make sure your laptop is working and that you take all required extra equipment. (If your wireless driver sucks, we can probably find some cables and a switch here.) * It would be good to have all the code you want to work on already on your computer. Also make sure it builds with your compiler version. If your distro doesn't have binaries, maybe install some software in advance, like Gobby or profiled versions of GHC, newest version of gtk2hs or whatever seems appropriate. It would just be a shame to waste hours of precious hacking time. * Make a backup. Just in case. ;) * Many hostels want a confirmation a few days before arrival, don't forget. * If you need some phone numbers of locals, check the wiki site, if you need some more help from us locals, you can ask us at our IRC channel #haskell-hac4. We're looking forward to a fun weekend! / The Hac4 Team From duncan.coutts at worc.ox.ac.uk Sun Apr 6 19:38:03 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 6 19:33:47 2008 Subject: [Haskell-cafe] ANNOUNCE: Well-Typed LLP - The Haskell Consultants In-Reply-To: <161445998.20080407025709@gmail.com> References: <20080406225002.GA15145@matrix.chaos.earth.li> <161445998.20080407025709@gmail.com> Message-ID: <1207525083.13231.55.camel@dell.linuxdev.us.dell.com> On Mon, 2008-04-07 at 02:57 +0400, Bulat Ziganshin wrote: > Hello Ian, > > Monday, April 7, 2008, 2:50:02 AM, you wrote: > > > We (Bjorn Bringert, Duncan Coutts and Ian Lynagh) are pleased to > > announce that we have recently set up a Haskell consultancy company, > > Well-Typed LLP (http://www.well-typed.com/). > > my congrats! Thank you. > seems you are first in this business :) Actually there are and have been a number of other individual consultants. So far as I know we're the first group specialising in Haskell consulting. The consultants page on the Haskell wiki lists some others and of course Alastair Reid did full time consulting for several years. Indeed he collected a list of other part time consultants. Duncan From john at repetae.net Sun Apr 6 20:59:29 2008 From: john at repetae.net (John Meacham) Date: Sun Apr 6 20:55:11 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> <20080406141224.GD31945@sliver.repetae.net> Message-ID: <20080407005929.GE31945@sliver.repetae.net> On Sun, Apr 06, 2008 at 11:30:20AM -0300, Felipe Lessa wrote: > On Sun, Apr 6, 2008 at 11:12 AM, John Meacham wrote: > > I implemented this efficient lazy natural class once upon a time. it > > even has things like lazy multiplication: > [...] > > instance Num Nat where > > Zero + y = y > > Sum x n1 + y = Sum x (y + n1) > > --x + Zero = x > > --Sum x n1 + Sum y n2 = Sum (x + y) (n1 + n2) > [...] > > May I ask you why the last line above was commented out? Notice it flips the order of the arguments with each iteration. This allows it to avoid space leaks in some cases, for instance if you have infinity + (space wasting thunk), the space wasting thunk will never be deallocated even though it isn't used. It also means that the strictness properties are more symmetric than they would be otherwise as people expect of (+). John -- John Meacham - ?repetae.net?john? From chak at cse.unsw.edu.au Sun Apr 6 22:49:35 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Apr 6 22:45:20 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: References: Message-ID: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> Ganesh Sittampalam: > The following program doesn't compile in latest GHC HEAD, although > it does if I remove the signature on foo'. Is this expected? Yes, unfortunately, this is expected, although it is very unintuitive. This is for the following reason. Let's alpha-rename the signatures and use explicit foralls for clarity: foo :: forall a. Id a -> Id a foo' :: forall b. Id b -> Id b GHC will try to match (Id a) against (Id b). As Id is a type synonym family, it would *not* be valid to derive (a ~ b) from this. After all, Id could have the same result for different argument types. (That's not the case for your one instance, but maybe in another module, there are additional instances for Id, where that is the case.) Now, as GHC cannot show that a and b are the same, it can also not show that (Id a) and (Id b) are the same. It does look odd when you use the same type variable in both signatures, especially as Haskell allows you to leave out the quantifiers, but the 'a' in the signature of foo and the 'a' in the signatures of foo' are not the same thing; they just happen to have the same name. BTW, here is the equivalent problem using FDs: class IdC a b | a -> b instance IdC Int Int bar :: IdC a b => b -> b bar = id bar' :: IdC a b => b -> b bar' = bar Given that this is a confusing issue, I am wondering whether we could improve matters by giving a better error message, or an additional hint in the message. Do you have any suggestion regarding what sort of message might have helped you? Manuel > {-# LANGUAGE TypeFamilies #-} > module Test7 where > > type family Id a > > type instance Id Int = Int > > foo :: Id a -> Id a > foo = id > > foo' :: Id a -> Id a > foo' = foo > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ganesh at earth.li Mon Apr 7 00:52:44 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Mon Apr 7 00:48:26 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: <1207521542.2438.17.camel@Clunker> References: <1207521542.2438.17.camel@Clunker> Message-ID: On Sun, 6 Apr 2008, Thomas M. DuBuisson wrote: > Id is an operation over types yielding a type, as such it doesn't make > much sense to me to have (Id a -> Id a) but rather something like (a -> > Id a). One could make this compile by adding the obvious instance: > >> type instance Id a = a > > Curiously, is this a reduction from a real world use of families? I > just can't think of how a (Fam a -> Fam a) function would be of use. Yes, it's cut down from an example where (I think) I really need the type signature to specialise a general function that does do something useful. The generalised intstance above wouldn't be valid or sensible in that context. Cheers, Ganesh From ganesh at earth.li Mon Apr 7 01:04:06 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Mon Apr 7 00:59:48 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> References: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> Message-ID: On Mon, 7 Apr 2008, Manuel M T Chakravarty wrote: > Ganesh Sittampalam: >> The following program doesn't compile in latest GHC HEAD, although it does >> if I remove the signature on foo'. Is this expected? > > Yes, unfortunately, this is expected, although it is very unintuitive. > This is for the following reason. > > Let's alpha-rename the signatures and use explicit foralls for clarity: > > foo :: forall a. Id a -> Id a > foo' :: forall b. Id b -> Id b > > GHC will try to match (Id a) against (Id b). As Id is a type synonym family, > it would *not* be valid to derive (a ~ b) from this. After all, Id could > have the same result for different argument types. (That's not the case for > your one instance, but maybe in another module, there are additional > instances for Id, where that is the case.) Can't it derive (Id a ~ Id b), though? > Now, as GHC cannot show that a and b are the same, it can also not show that > (Id a) and (Id b) are the same. It does look odd when you use the same type > variable in both signatures, especially as Haskell allows you to leave out > the quantifiers, but the 'a' in the signature of foo and the 'a' in the > signatures of foo' are not the same thing; they just happen to have the same > name. Sure, but forall a . Id a ~ Id a is the same thing as forall b . Id b ~ Id b. Thanks for the explanation, anyway. I'll need to have another think about what I'm actually trying to do (which roughly speaking is to specialise a general function over type families using a signature which I think I need for other reasons). Generally speaking, is there any way to give a signature to foo'? > Given that this is a confusing issue, I am wondering whether we could improve > matters by giving a better error message, or an additional hint in the > message. Do you have any suggestion regarding what sort of message might > have helped you? I can't think of anything good. Perhaps printing out the (type classes + equalities) context would have helped me to see that it was empty and understand why, but probably not. Cheers, Ganesh From apfelmus at quantentunnel.de Mon Apr 7 04:04:55 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Mon Apr 7 04:00:48 2008 Subject: [Haskell-cafe] Re: type families and type signatures In-Reply-To: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> References: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> Message-ID: Manuel M T Chakravarty wrote: > Ganesh Sittampalam: >> The following program doesn't compile in latest GHC HEAD, although it >> does if I remove the signature on foo'. >> >> {-# LANGUAGE TypeFamilies #-} >> module Test7 where >> >> type family Id a >> >> type instance Id Int = Int >> >> foo :: Id a -> Id a >> foo = id >> >> foo' :: Id a -> Id a >> foo' = foo >> >> Is this expected? > > Yes, unfortunately, this is expected, although it is very unintuitive. > This is for the following reason. Huh? This sounds very wrong to me, simply because foo and foo' have the very same type. > Let's alpha-rename the signatures and use explicit foralls for clarity: > > foo :: forall a. Id a -> Id a > foo' :: forall b. Id b -> Id b > > GHC will try to match (Id a) against (Id b). As Id is a type synonym > family, it would *not* be valid to derive (a ~ b) from this. After all, > Id could have the same result for different argument types. (That's not > the case for your one instance, but maybe in another module, there are > additional instances for Id, where that is the case.) While in general (Id a ~ Id b) -/-> (a ~ b) , parametricity makes it "true" in the case of foo . For instance, let Id a ~ Int . Then, the signature specializes to foo :: Int -> Int . But due to parametricity, foo does not care at all what a is and will be the very same function for every a with Id a ~ Int . In other words, it's as if the type variable a is not in scope in the definition of foo . > Now, as GHC cannot show that a and b are the same, it can also not show > that (Id a) and (Id b) are the same. It does look odd when you use the > same type variable in both signatures, especially as Haskell allows you > to leave out the quantifiers, but the 'a' in the signature of foo and > the 'a' in the signatures of foo' are not the same thing; they just > happen to have the same name. Since both type variables are quantified, the types as a whole are the same, alpha conversion notwithstanding. > BTW, here is the equivalent problem using FDs: > > class IdC a b | a -> b > instance IdC Int Int > > bar :: IdC a b => b -> b > bar = id > > bar' :: IdC a b => b -> b > bar' = bar Hugs rejects bar as ambiguous whereas GHC accepts bar but rejects bar' . Something is wrong here. I think that only rejecting both definitions due to ambiguity is correct, since bar has access to a from the class. For instance, consider class C a b | a -> b fromA :: a -> b oneA :: a instance C Int Int where fromA = const 1 oneA = 1 instance C Char Int where fromA = const 2 oneA = 'a' bar :: C a b => b -> b bar _ = fromA oneA This definition is clearly ambiguous, bar could be 1 or 2. The subtle difference in the type synonym family case is that a is "more parametric" there. At least, that's my feeling. In full System F , neither definition would be a problem since the type a is an explicit parameter. Regards, apfelmus From Tom.Schrijvers at cs.kuleuven.be Mon Apr 7 06:43:51 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Mon Apr 7 06:40:01 2008 Subject: [Haskell-cafe] Re: type families and type signatures In-Reply-To: References: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> Message-ID: >>> type instance Id Int = Int >>> >>> foo :: Id a -> Id a >>> foo = id >>> >>> foo' :: Id a -> Id a >>> foo' = foo >>> Is this expected? >> >> Yes, unfortunately, this is expected, although it is very unintuitive. >> This is for the following reason. > > Huh? This sounds very wrong to me, simply because foo and foo' have the > very same type. Type systems reject programs that don't go wrong. It's hard to understand on the basis of such a single program why it should be rejected. The problem is decidability. There is no algorithm that accepts all well-behaved programs and rejects all ill-behaved programs. There probably is an algorithm that accepts a particular program. So far we haven't found an algorithm that accepts this example, that is decidable and sufficiently general to cover many other useful cases. This is our motivation for rejecting this program. Consider it a challenge to find a better algorithm in the design space. Cheers, Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From alexander.kireyev+haskell.cafe at gmail.com Mon Apr 7 06:55:57 2008 From: alexander.kireyev+haskell.cafe at gmail.com (Alexander Kireyev) Date: Mon Apr 7 06:51:43 2008 Subject: [Haskell-cafe] Memory allocation in extractor function (newbie question) Message-ID: <63cfb5620804070355u49b61f87tf20b78d8859e55ed@mail.gmail.com> Hello, While trying to write a program for the countPaths Code Jam problem I ran into what seems to me as a weird behaviour in terms of memory allocation. The task is to count the number of way you can spell a certain "word" by walking some path on a board of letters. Being a newbie I started with a very straightforward recursive approach, which is not effective, but still helps to improve understanding of Haskell basics. Quite naturally I quickly hit the point where the program becomes too slow, so I tried to profile and optimize the code. I used 3 data types: data GridEntry = GridEntry {letter :: Char, neighbors :: [Point]} data Area = Area {letters :: (Array (Int, Int) GridEntry), width :: Int, height :: Int} data Point = Point { x :: Int, y :: Int} deriving (Show, Eq) With the recursive approach I had to retrieve GridEntries (a letter in a certain point of grid together with the list of its neighbours on the grid) a lot. Quite surprisingly I saw that this operation was overly expensive in my program. The most time was spent in these 2 functions: countPathsFrom :: Area -> Int -> String -> Point -> Int countPathsFrom _ count [] _ = count countPathsFrom area count (l:[]) point = count + if (letter (letterAt area point) == l) then 1 else 0 countPathsFrom area count (l:ls) point = let gridPt = letterAt area point points = neighbors gridPt in if (letter gridPt == l) then countForPoints area ls count points else count letterAt :: Area -> Point -> GridEntry letterAt area (Point x y) = letters area ! (x, y) The profiling log (./paths +RTS -P) shows the following time/space behaviour for them: countPathsFrom Main 181 11830476 37.8 52.3 59.5 82.2 28 1325013312 letterAt Main 184 11830476 21.6 29.9 21.6 29.9 16 757150464 What puzzles me here is how the function letterAt generates 64 bytes of garbage per call. Since there are no side-effects in this section of program - and noone can damage the 'area' structure - I would expect the compiler/runtime to use a reference to the data in the 'area' structure when returning values from letterAt. Instead it seems to make a copy of GridEntry and return that. The question here is whether (why?) this behaviour is normal and if it is possible to optimize the code in such cases. Thanks in advance, -Alexander From vandijk.roel at gmail.com Mon Apr 7 07:28:10 2008 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Mon Apr 7 07:23:51 2008 Subject: [Haskell-cafe] The range operator In-Reply-To: <47F6943D.5030700@btinternet.com> References: <7.0.1.0.0.20080404205536.01d8bb70@ntlworld.com> <20080404200025.GA3156@localhost.localdomain> <47F6943D.5030700@btinternet.com> Message-ID: On Fri, Apr 4, 2008 at 10:49 PM, Andrew Coppin wrote: > More to the point, the range y..z goes in steps of y-z. ;-) [x,y..z] goes in steps of y-x ;-), [y..z] goes in steps of 1 (depending on the type). From wnoise at ofb.net Mon Apr 7 07:36:59 2008 From: wnoise at ofb.net (Aaron Denney) Date: Mon Apr 7 07:32:52 2008 Subject: [Haskell-cafe] Re: Function Precedence References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> <25B66FFC-7C33-49BD-9C63-7A05A46A9487@math.su.se> Message-ID: On 2008-04-03, Chris Smith wrote: > Hans Aberg wrote: >> This problem is not caused by defining f+g, but by defining numerals as >> constants. > > Yup. So the current (Num thing) is basically: > > 1. The type thing is a ring > 2. ... with signs and absolute values > 3. ... along with a natural homomorphism from Z into thing > 4. ... and with Eq and Show. > > If one wanted to be perfectly formally correct, then each of 2-4 could be > split out of Num. For example, 2 doesn't make sense for polynomials or n > by n square matrices. 4 doesn't make sense for functions. 3 doesn't > make sense for square matrices of dimension greater than 1. And, this > quirk about 2(x+y) can be seen as an argument for not wanting it in the > case of functions, either. I'm not sure I find the argument terribly > compelling, but it is there anyway. Just a nit, but 3 seems to make perfect sense for square matrices -- n gets mapped onto I_d for any dimension d. fromInteger (n*m) == fromInteger n * fromInteger m fromInteger (n+m) == fromInteger n + fromInteger m -- Aaron Denney -><- From droundy at darcs.net Mon Apr 7 07:45:31 2008 From: droundy at darcs.net (David Roundy) Date: Mon Apr 7 07:41:14 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <20080406141224.GD31945@sliver.repetae.net> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> <20080406141224.GD31945@sliver.repetae.net> Message-ID: <20080407114531.GZ16717@darcs.net> On Sun, Apr 06, 2008 at 07:12:24AM -0700, John Meacham wrote: > On Fri, Apr 04, 2008 at 04:46:22PM +0100, Neil Mitchell wrote: > > Where length xs = 1 and ys = 1000. This takes 1000 steps to tell the > > Int's aren't equal, since we don't have proper lazy naturals. If we > > did, it would take 2 steps. > > > > Read this: http://citeseer.ist.psu.edu/45669.html - it argues the > > point I am trying to make, but much better. > > I implemented this efficient lazy natural class once upon a time. it > even has things like lazy multiplication: I wonder about the efficiency of this implementation. It seems that for most uses the result is that the size of a Nat n is O(n), which means that in practice you probably can't use it for large numbers. e.g. it seems like last [1..n :: Nat] should use O(n) space, where last [1..n :: Integer] should take O(1) space. And I can't help but imagine that there must be scenarios where the memory use goes from O(N) to O(N^2), which seems pretty drastic. I imagine this is an inherent cost in the use of lazy numbers? Which is probably why they're not a reasonable default, since poor space use is often far more devastating then simple inefficiency. And of course it is also not always more efficient than strict numbers. -- David Roundy Department of Physics Oregon State University From uwe at fh-wedel.de Mon Apr 7 07:50:46 2008 From: uwe at fh-wedel.de (Uwe Schmidt) Date: Mon Apr 7 07:45:39 2008 Subject: [Haskell-cafe] ANN: Hayoo! beta 0.1 In-Reply-To: <200804061407.22507.t.h@gmx.info> References: <200804061407.22507.t.h@gmx.info> Message-ID: <200804071350.46841.uwe@fh-wedel.de> Lieber Herr H?bel, lieber Herr Schlatt, ich habe gerade das Announcement von Holumbus in haskell.org gelesen und nat?rlich auch Holumbus ausprobiert. RICHTIG GUT! Viele Gruesse Uwe Schmidt From john at repetae.net Mon Apr 7 07:52:51 2008 From: john at repetae.net (John Meacham) Date: Mon Apr 7 07:48:31 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <20080407114531.GZ16717@darcs.net> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> <20080406141224.GD31945@sliver.repetae.net> <20080407114531.GZ16717@darcs.net> Message-ID: <20080407115251.GF31945@sliver.repetae.net> On Mon, Apr 07, 2008 at 04:45:31AM -0700, David Roundy wrote: > I wonder about the efficiency of this implementation. It seems that for > most uses the result is that the size of a Nat n is O(n), which means that > in practice you probably can't use it for large numbers. > > e.g. it seems like > > last [1..n :: Nat] > > should use O(n) space, where > > last [1..n :: Integer] > > should take O(1) space. And I can't help but imagine that there must be > scenarios where the memory use goes from O(N) to O(N^2), which seems pretty > drastic. I imagine this is an inherent cost in the use of lazy numbers? > Which is probably why they're not a reasonable default, since poor space > use is often far more devastating then simple inefficiency. And of course > it is also not always more efficient than strict numbers. Oh, yes. I certainly wouldn't recommend them as some sort of default, they were sort of a fun project and might come in handy some day. By efficient, I meant more efficient than the standard lazy number formulation of data Num = Succ Num | Zero not more efficient than strict types, which it very much is not. :) John -- John Meacham - ?repetae.net?john? From prstanley at ntlworld.com Mon Apr 7 08:07:54 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Mon Apr 7 08:03:44 2008 Subject: [Haskell-cafe] The range operator In-Reply-To: References: <7.0.1.0.0.20080404205536.01d8bb70@ntlworld.com> <20080404200025.GA3156@localhost.localdomain> <47F6943D.5030700@btinternet.com> Message-ID: <7.0.1.0.0.20080407130720.01d30828@ntlworld.com> At 12:28 07/04/2008, you wrote: >On Fri, Apr 4, 2008 at 10:49 PM, Andrew Coppin > wrote: > > More to the point, the range y..z goes in steps of y-z. ;-) >[x,y..z] goes in steps of y-x ;-), [y..z] goes in steps of 1 >(depending on the type). Could you elaborate please? >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe@haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe From mail at philip.in-aachen.net Mon Apr 7 08:14:37 2008 From: mail at philip.in-aachen.net (=?UTF-8?B?UGhpbGlwIE3DvGxsZXI=?=) Date: Mon Apr 7 08:10:06 2008 Subject: [Haskell-cafe] ANN: Hayoo! beta 0.1 In-Reply-To: <200804061407.22507.t.h@gmx.info> References: <200804061407.22507.t.h@gmx.info> Message-ID: <47FA102D.8090606@philip.in-aachen.net> On Sun, 06 Apr 2008 14:07:22 +0200, wrote: > Hello, > > we are pleased to announce the first beta release of Hayoo!, a Haskell > API > search engine providing advanced features like suggestions, > find-as-you-type, > fuzzy queries and much more. > > Visit Hayoo! here: http://holumbus.fh-wedel.de/hayoo Hi, first of all, I'm very pleased to hear that such a nice project comes from FH Wedel. However, I have found two bugs, or annoyances: Using Opera 9.27 or Internet Explorer 7, - Search results vanish when using the "back" button - the "Source" and ghc docs links always take me to the top of the pages, it seems the anchors don't work. In Firefox 2.0.0.13 these problems do not appear. > Any suggestions and feedback is highly welcomed. Keep up the good work! Regards Philip, who regrets that the FH Wedel TInf course of studies doesn't include the Haskell lecture. From wnoise at ofb.net Mon Apr 7 08:28:56 2008 From: wnoise at ofb.net (Aaron Denney) Date: Mon Apr 7 08:24:55 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> <6f9f8f4a0804040931i42040dib28bd523db349e70@mail.gmail.com> <404396ef0804040937n3ea7151cj235b60330c3a4aa6@mail.gmail.com> Message-ID: On 2008-04-04, Neil Mitchell wrote: >> What do you mean by "proper Lazy naturals"? Peano ones? > > Yes Not _strictly_ necessary. And I'd definitely like some suitable typeclass put in place. This represents positive arithmetic with a list homomorphism that forgets the elements and remembers only length. It's pretty much exactly equivalent to the function "map (const ())". This essentially unary representation isn't the only way to way to manipulate numbers by structure. You can do the same thing with many other data structures, such as trees, heaps, etc. In this case, yes, lists are the cleanest, being the underlying structure we're getting information about. (Aside: might as well just define the "less than" operation directly on the lists in this case -- or for any other arithmetic operation where we're not getting a list back. When we are, we usually can too, but it's a bit more fraught with concerns over whether that's really what we want -- we're throwing away information by replacing all elements with (), and perhaps we should have the typechecker warn us.[1]) But we can pull this trick with any container class. + corresponds to some merger or catenation, * to some cross product, zero to an empty data structure, and so forth. If you do this with Binomial heaps, out pop binary numbers. If you do this to certain types of efficient queues, "skew binary numbers" which support efficient increment and decrument pop out. This isn't surprising, as they were built using skew binary number for precisely this property. Those that haven't should take a look at Okasaki's _Purely Functional Data Structures_, particularly chapter 9: "Numerical Structures". http://books.google.com/books?id=SxPzSTcTalAC [1]: smallerThan :: [a] -> [b] -> Bool smallerThan [] [] = False smallerThan [] _ = True smallerThan _ [] = False smallerThan (_:as) (_:bs) = smallerThan as bs noGreaterThan :: [a] -> [b] -> Bool noGreaterThan [] _ = True noGreaterThan _ [] = False noGreaterThan (_:as) (_:bs) = noGreaterThan as bs are perfectly reasonable, but it's less clear that nattify = map const () (+) xs ys = (++) (nattify xs) (nattify ys) would be good universal definitions. -- Aaron Denney -><- From uwe at fh-wedel.de Mon Apr 7 08:31:56 2008 From: uwe at fh-wedel.de (Uwe Schmidt) Date: Mon Apr 7 08:26:49 2008 Subject: [Haskell-cafe] ANN: Hayoo! beta 0.1 In-Reply-To: <200804071350.46841.uwe@fh-wedel.de> References: <200804061407.22507.t.h@gmx.info> <200804071350.46841.uwe@fh-wedel.de> Message-ID: <200804071431.56465.uwe@fh-wedel.de> Uwe Schmidt wrote: > Lieber Herr H?bel, > lieber Herr Schlatt, sorry for spamming haskell-cafe Uwe From explicitcall at googlemail.com Mon Apr 7 08:46:02 2008 From: explicitcall at googlemail.com (Max Desyatov) Date: Mon Apr 7 08:41:44 2008 Subject: [Haskell-cafe] [GSoC] WWW::Mechanize-like package for Haskell In-Reply-To: References: Message-ID: Hi, I'm interested in working on a library for a stateful web browsing in Haskell during Google Summer of Code. The basic idea is described at http://hackage.haskell.org/trac/summer-of-code/ticket/1107. WWW::Mechanize is a ready to use library written in Perl, though I used python's mechanize when I wrote some simple scripts (http://wwwsearch.sourceforge.net/mechanize/), which provides much cleaner interface. Anyway, it gives simple and convenient way to retreive web-sites, to handle cookies, history and to process retrieved content and forms. There are basics of it Network.Browser module from Haskell's HTTP library (http://hackage.haskell.org/packages/archive/HTTP/3001.0.4/doc/html/Network-Browser.html), but it's ugly (uses unsafePerformIO for error reporting) and lacks a greater part of needed functionality. My aim is to greatly improve Network.Browser module and to make coding small scripts with it in more functional way possible. At this moment it uses BrowserAction state monad. Though, the deadline is approaching, I still seek some ways to improve my proposal. So here are the questions: are there any other data structures that will make programming with this library more convenient, besides simple state monad? Should we contrive more sophisticated system with other other separate data structures? What other improvements you'd like to see? Thanks in advance for any advice. -- Max. From nominolo at googlemail.com Mon Apr 7 09:11:52 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Apr 7 09:07:49 2008 Subject: [Haskell-cafe] [GSoC] WWW::Mechanize-like package for Haskell In-Reply-To: References: Message-ID: On 7 apr 2008, at 14.46, Max Desyatov wrote: > Hi, > > I'm interested in working on a library for a stateful web browsing in > Haskell during Google Summer of Code. The basic idea is described at > http://hackage.haskell.org/trac/summer-of-code/ticket/1107. > WWW::Mechanize is a ready to use library written in Perl, though I > used python's mechanize when I wrote some simple scripts > (http://wwwsearch.sourceforge.net/mechanize/), which provides much > cleaner interface. Anyway, it gives simple and convenient way to > retreive web-sites, to handle cookies, history and to process > retrieved content and forms. There are basics of it Network.Browser > module from Haskell's HTTP library > (http://hackage.haskell.org/packages/archive/HTTP/3001.0.4/doc/ > html/Network-Browser.html), > but it's ugly (uses unsafePerformIO for error reporting) and lacks a > greater part of needed functionality. > > My aim is to greatly improve Network.Browser module and to make coding > small scripts with it in more functional way possible. At this moment > it uses BrowserAction state monad. Though, the deadline is > approaching, I still seek some ways to improve my proposal. So here > are the questions: are there any other data structures that will make > programming with this library more convenient, besides simple state > monad? Should we contrive more sophisticated system with other other > separate data structures? What other improvements you'd like to see? > It doesn't have to be perfect. Make sure you know how to use monad transformers. Also take a look at tag soup and the various HTML/XML parsers. I'm sure there's plenty to work on. My guess would be, that you try to write non-trivial example applications and see what is needed. For example, you could write a script to download/upload a Haskell wiki page logging in if necessary. Take a look of what other WWW::Mechanize packages are used. That kind of stuff. Also, for a GSoC proposal you should try to convince the mentors, why your project is useful for Haskell in general. So maybe you have some more arguments there, too. / Thomas From gale at sefer.org Mon Apr 7 09:16:37 2008 From: gale at sefer.org (Yitzchak Gale) Date: Mon Apr 7 09:12:26 2008 Subject: [Haskell-cafe] Memory allocation in extractor function (newbie question) In-Reply-To: <63cfb5620804070355u49b61f87tf20b78d8859e55ed@mail.gmail.com> References: <63cfb5620804070355u49b61f87tf20b78d8859e55ed@mail.gmail.com> Message-ID: <2608b8a80804070616i29c9680ao8ad53cb17aed4b7f@mail.gmail.com> Alexander Kireyev wrote: > While trying to write a program for the countPaths Code Jam problem I > ran into what seems to me as a weird behaviour in terms of memory > allocation... > The profiling log (./paths +RTS -P) shows the following time/space > behaviour for them... Hi Alexander, I'm not sure I can fully explain your profiling behavior either, but I'll take a stab at what the problem might be anyway. You didn't show us the code for countForPoints. I'll bet you wrote something like countForPoints area ls count points = sum $ map (countPathsFrom area (count + 1) ls) points Unfortunately, the standard sum function is too lazy in many situations. And if you wrote out the recursion for countForPoints by hand, you may have run into the same problem. In either case, you'll be accumulating huge amounts of unevaluated (+) thunks instead of adding up the count as you go along. If this is the problem, you can fix it by using foldl', a strict version of foldl from Data.List, instead of sum: countForPoints area ls count points = foldl' (+) 0 $ map (countPathsFrom area (count + 1) ls) points Hope this helps, Yitz From vandijk.roel at gmail.com Mon Apr 7 09:22:13 2008 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Mon Apr 7 09:18:03 2008 Subject: [Haskell-cafe] The range operator In-Reply-To: <7.0.1.0.0.20080407130720.01d30828@ntlworld.com> References: <7.0.1.0.0.20080404205536.01d8bb70@ntlworld.com> <20080404200025.GA3156@localhost.localdomain> <47F6943D.5030700@btinternet.com> <7.0.1.0.0.20080407130720.01d30828@ntlworld.com> Message-ID: class Enum a where ... -- | Used in Haskell's translation of [n,n'..m]. enumFromThenTo :: a -> a -> a -> [a] So [x, y .. z] becomes "enumFromThenTo x y z". Each instance of Enum is free to implement enumFromThenTo and friends in any way it likes. So with Ints you have [1, 3 .. 10] :: [Int] == [1, 3, 5, 7, 9] but with Chars you get ['a', 'c' .. 'i'] :: [Char] == "acegi" and with Floats you curiously get [1, 3 .. 10] :: [Float] == [1.0, 3.0, 5.0, 7.0, 9.0, 11.0] On Mon, Apr 7, 2008 at 2:07 PM, PR Stanley wrote: > At 12:28 07/04/2008, you wrote: > > On Fri, Apr 4, 2008 at 10:49 PM, Andrew Coppin > > wrote: > > > More to the point, the range y..z goes in steps of y-z. ;-) > > [x,y..z] goes in steps of y-x ;-), [y..z] goes in steps of 1 > > (depending on the type). > > > Could you elaborate please? From gale at sefer.org Mon Apr 7 09:36:27 2008 From: gale at sefer.org (Yitzchak Gale) Date: Mon Apr 7 09:32:07 2008 Subject: [Haskell-cafe] [GSoC] WWW::Mechanize-like package for Haskell In-Reply-To: References: Message-ID: <2608b8a80804070636s6d631c67g4c9e1c5982f9d779@mail.gmail.com> Max Desyatov wrote: >> I'm interested in working on a library for a stateful web browsing in >> Haskell during Google Summer of Code. Thomas Schilling wrote: > Also, for a GSoC proposal you should try to convince the mentors, why your > project is useful for Haskell in general. So maybe you have some more > arguments there, too. There are obviously zillions of uses for automating interaction with web pages. Perhaps you are asking why not just do it Perl or Python? One classic application is unit testing and stress testing of web-based applications. There are also various lambdabot plugins that could be vastly cleaned up and extended. So it would be extremely useful to have an improved library for this in Haskell. The next step would be to build various nice testing libraries on top of this for QuickCheck and various web programming frameworks, but that's already too much for one GSoC project. Something we could look forward to though. Regards, Yitz From alexander.kireyev+haskell.cafe at gmail.com Mon Apr 7 10:10:30 2008 From: alexander.kireyev+haskell.cafe at gmail.com (Alexander Kireyev) Date: Mon Apr 7 10:06:17 2008 Subject: [Haskell-cafe] Memory allocation in extractor function (newbie question) In-Reply-To: <63cfb5620804070706x788a7d12gc22fb94134f230df@mail.gmail.com> References: <63cfb5620804070355u49b61f87tf20b78d8859e55ed@mail.gmail.com> <2608b8a80804070616i29c9680ao8ad53cb17aed4b7f@mail.gmail.com> <63cfb5620804070706x788a7d12gc22fb94134f230df@mail.gmail.com> Message-ID: <63cfb5620804070710n6ff15f7as351754fab410cd16@mail.gmail.com> On Mon, Apr 7, 2008 at 4:16 PM, Yitzchak Gale wrote: > You didn't show us the code for countForPoints. I'll bet you wrote > something like > > countForPoints area ls count points = > sum $ map (countPathsFrom area (count + 1) ls) points > > Unfortunately, the standard sum function is too lazy in many situations. > And if you wrote out the recursion for countForPoints by hand, you > may have run into the same problem. In either case, you'll be accumulating > huge amounts of unevaluated (+) thunks instead of adding up the > count as you go along. > > If this is the problem, you can fix it by using foldl', a strict version > of foldl from Data.List, instead of sum: > > countForPoints area ls count points = > foldl' (+) 0 $ map (countPathsFrom area (count + 1) ls) points Thanks for the pointer. In fact my version was already using the fold function, albeit the lazy version of it: countForPoints :: Area -> String -> Int -> [Point] -> Int countForPoints area goal count points = let newCount = foldl (countSubPaths area goal) count points in if countExceeded newCount then -1 else newCount countExceeded :: Int -> Bool countExceeded count = (count < 0) || (count > countLimit) countSubPaths :: Area -> String -> Int -> Point -> Int countSubPaths area goal count point = if (countExceeded count) then -1 else countPathsFrom area count goal point Switching to the strict version reduced the amount of garbage in that function and in countSubPaths, but the problem with 'letterAt' still shines. I was thinking that adding strictness to that function might help, but no amount of exclamation marks helped it so far. -Alexander // copying to the mailing list, because first reply didn't get through. From nominolo at googlemail.com Mon Apr 7 10:11:09 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Apr 7 10:07:13 2008 Subject: [Haskell-cafe] [GSoC] WWW::Mechanize-like package for Haskell In-Reply-To: <2608b8a80804070636s6d631c67g4c9e1c5982f9d779@mail.gmail.com> References: <2608b8a80804070636s6d631c67g4c9e1c5982f9d779@mail.gmail.com> Message-ID: On 7 apr 2008, at 15.36, Yitzchak Gale wrote: > Max Desyatov wrote: >>> I'm interested in working on a library for a stateful web >>> browsing in >>> Haskell during Google Summer of Code. > > Thomas Schilling wrote: >> Also, for a GSoC proposal you should try to convince the mentors, >> why your >> project is useful for Haskell in general. So maybe you have some >> more >> arguments there, too. > > There are obviously zillions of uses for automating interaction with > web pages. Perhaps you are asking why not just do it Perl or Python? > > One classic application is unit testing and stress testing of web- > based > applications. There are also various lambdabot plugins that could > be vastly cleaned up and extended. > > So it would be extremely useful to have an improved library for > this in > Haskell. > > The next step would be to build various nice testing libraries on top > of this for QuickCheck and various web programming frameworks, > but that's already too much for one GSoC project. Something we > could look forward to though. > I proposed this project last year, so I believe in its usefulness. But you just gave some very good reasons why mentors should rank Max's proposal highly. So I hope Max will incorporate the above motivations in his proposal. :) / Thomas From mpj at cs.pdx.edu Mon Apr 7 10:33:11 2008 From: mpj at cs.pdx.edu (Mark P Jones) Date: Mon Apr 7 10:29:12 2008 Subject: [Haskell-cafe] Re: type families and type signatures In-Reply-To: References: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> Message-ID: <47FA30A7.4000504@cs.pdx.edu> The surprising thing about this example is the fact that the definition of foo is accepted, and not the fact that the definition of foo' is rejected. At least in Manuel's "equivalent" program using functional dependencies, both functions have ambiguous types, and hence both would be rejected. It sounds like your implementation may be using a relaxed approach to ambiguity checking that delays ambiguity checking from the point of definition to the point of use. Although this is probably still sound, it can lead to puzzling error diagnostics ... All the best, Mark Tom Schrijvers wrote: >>>> type instance Id Int = Int >>>> >>>> foo :: Id a -> Id a >>>> foo = id >>>> >>>> foo' :: Id a -> Id a >>>> foo' = foo Is this expected? >>> >>> Yes, unfortunately, this is expected, although it is very >>> unintuitive. This is for the following reason. >> >> Huh? This sounds very wrong to me, simply because foo and foo' >> have the very same type. > > Type systems reject programs that don't go wrong. It's hard to > understand on the basis of such a single program why it should be > rejected. The problem is decidability. There is no algorithm that > accepts all well-behaved programs and rejects all ill-behaved programs. > There probably is an algorithm that accepts a particular program. > > So far we haven't found an algorithm that accepts this example, that is > decidable and sufficiently general to cover many other useful cases. > This is our motivation for rejecting this program. > > Consider it a challenge to find a better algorithm in the design space. > > Cheers, > > Tom > > -- > Tom Schrijvers > > Department of Computer Science > K.U. Leuven > Celestijnenlaan 200A > B-3001 Heverlee > Belgium > > tel: +32 16 327544 > e-mail: tom.schrijvers@cs.kuleuven.be > url: http://www.cs.kuleuven.be/~toms/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From mail at joachim-breitner.de Mon Apr 7 10:44:38 2008 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon Apr 7 10:40:25 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <404396ef0804041444t194de5a9t11c518ce75612a5b@mail.gmail.com> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> <6f9f8f4a0804040931i42040dib28bd523db349e70@mail.gmail.com> <836B0293-D3D3-4FA2-995B-6B18E4C610CA@gmail.com> <220e47b40804041436h4237d53p42a74a03d7239793@mail.gmail.com> <404396ef0804041444t194de5a9t11c518ce75612a5b@mail.gmail.com> Message-ID: <1207579478.25908.34.camel@otto.ehbuehl.net> Hi, Am Freitag, den 04.04.2008, 22:44 +0100 schrieb Neil Mitchell: > Hi > > > We can however write function like this: > > > > eqLengths [] [] = True > > eqLengths (x:xs) (y:ys) = eqLengths ys xs > > eqLengths _ _ = False > > > > which looks just fine for me. > > I have this defined function. I also have lenEq1, lenGt1, and a few > other variants. It works, but it just doesn't feel elegant. > > Note: In case anyone gets the wrong impression, I am not suggesting > lazy naturals be the standard numeric type in Haskell, just that by > not going that way we have paid a cost in terms of elegance. How about something like this: > data Length a = Length [a] > > instance Ord (Length a) where ?> compare (Length []) (Length []) = EQ ?> compare (Length []) (Length (_:_)) = LT ?> compare (Length (_:_)) (Length []) = GT ?> compare (Length (_:xs)) (Length (_:ys)) = compare (Length xs) (Length ys) > ?> ?instance Eq (Length a) where ?> l1 == l2 = compare l1 l2 == EQ then you can do at least lazy lengths comparisons relatively nice by writing > if Length list1 >= Length list2 then print "list1" else print "list2" (just a quick idea) Greetings Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080407/52a687a9/attachment.bin From droundy at darcs.net Mon Apr 7 10:49:59 2008 From: droundy at darcs.net (David Roundy) Date: Mon Apr 7 10:45:40 2008 Subject: [Haskell-cafe] Re: Shouldn't this loop indefinitely => take (last [0..]) [0..] In-Reply-To: <20080407115251.GF31945@sliver.repetae.net> References: <47F54DBF.7040403@serpentine.com> <20080403221306.GA7948@scytale.galois.com> <404396ef0804040434u2da99fdftd82ad3651bd4f331@mail.gmail.com> <6f9f8f4a0804040837n4db7b7ecrb41d4bfe416e2b6d@mail.gmail.com> <404396ef0804040846n390110d1u6cb3abf7a84cc7cf@mail.gmail.com> <20080406141224.GD31945@sliver.repetae.net> <20080407114531.GZ16717@darcs.net> <20080407115251.GF31945@sliver.repetae.net> Message-ID: <20080407144957.GA16717@darcs.net> On Mon, Apr 07, 2008 at 04:52:51AM -0700, John Meacham wrote: > On Mon, Apr 07, 2008 at 04:45:31AM -0700, David Roundy wrote: > > I wonder about the efficiency of this implementation. It seems that for > > most uses the result is that the size of a Nat n is O(n), which means that > > in practice you probably can't use it for large numbers. > > > > e.g. it seems like > > > > last [1..n :: Nat] > > > > should use O(n) space, where > > > > last [1..n :: Integer] > > > > should take O(1) space. And I can't help but imagine that there must be > > scenarios where the memory use goes from O(N) to O(N^2), which seems pretty > > drastic. I imagine this is an inherent cost in the use of lazy numbers? > > Which is probably why they're not a reasonable default, since poor space > > use is often far more devastating then simple inefficiency. And of course > > it is also not always more efficient than strict numbers. > > Oh, yes. I certainly wouldn't recommend them as some sort of default, > they were sort of a fun project and might come in handy some day. > > By efficient, I meant more efficient than the standard lazy number > formulation of > > data Num = Succ Num | Zero > > not more efficient than strict types, which it very much is not. :) Ah, that makes sense. And yes, they're definitely more efficient than that. :) The trouble (I suppose) is that for the common case in which lazy naturals are called for, which is situations where you compute (1+1+1+1...+1+0), you can't be more space-efficient than the standard lazy numbers without losing some of the laziness. Or at least, I can't see how you could do so. -- David Roundy Department of Physics Oregon State University From pkeir at dcs.gla.ac.uk Mon Apr 7 11:23:34 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Mon Apr 7 11:19:13 2008 Subject: [Haskell-cafe] Parsec Expected Type In-Reply-To: <20080330112935.GA31391@rbg.informatik.tu-darmstadt.de> References: <3CDFB8AFEA98E34CB599475AB11589C80CC9BF@EX2.ad.dcs.gla.ac.uk> <7ca3f0160803271726m21c444c5x7c417afd686eb9b6@mail.gmail.com> <3CDFB8AFEA98E34CB599475AB11589C80CC9C0@EX2.ad.dcs.gla.ac.uk> <3CDFB8AFEA98E34CB599475AB11589C80CC9C2@EX2.ad.dcs.gla.ac.uk> <20080330112935.GA31391@rbg.informatik.tu-darmstadt.de> Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80E8A42@EX2.ad.dcs.gla.ac.uk> Thanks. reservedOp is a better fit; ":+" should only be ":+". I also overcame my type issues in an ad-hoc manner, adding >> return () whenever I needed to. -----Original Message----- From: Tillmann Rendel [mailto:rendel@rbg.informatik.tu-darmstadt.de] Sent: 30 March 2008 12:30 To: Paul Keir; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Parsec Expected Type Paul Keir wrote: > What I'd like is to parse either the string "parameter", or the > string ":". I'm using 'reserved' and 'symbol' because they seem to > correspond well to the concepts in the language I'm parsing. You may consider using reservedOp for ":", depending on how ":+" should be parsed: for ":+" use reservedOp for ":" "+" use symbol If you use reserved, then ":name" will be parsed as ":name" not ":" "name" as you probably expect. generally, reserved is for identifier-like keywords, and reservedOp for operator-like keywords. > Perhaps I'd express my confusion better if I ask: Why are 'reserved' > and 'symbol' different types? I have no idea. They aren't in the Parsec manual on Daans site: http://legacy.cs.uu.nl/daan/download/parsec/parsec.html You can fix this by defining reserved name = ParsecToken.reserved tokenParser name >> return name instead of reserved = ParsecToken.reserved tokenParser to "import" the reserved component from the tokenParser to the toplevel. Now, reserved :: String -> CharParser st String Another option is to fix it the other way, by defining symbol name = ParsecToken.symbol tokenParser name >> return () or to fix it in a ad-hoc manner, by defining ignored = (>> return ()) and using it in the approbiate places, like parameterOrColon = reserved "parameter" <|> ignored (symbol ":") Tillmann From explicitcall at googlemail.com Mon Apr 7 11:35:15 2008 From: explicitcall at googlemail.com (Max Desyatov) Date: Mon Apr 7 11:30:56 2008 Subject: [Haskell-cafe] [GSoC] WWW::Mechanize-like package for Haskell In-Reply-To: References: Message-ID: On Mon, Apr 7, 2008 at 4:11 PM, Thomas Schilling wrote: > It doesn't have to be perfect. Make sure you know how to use monad > transformers. Also take a look at tag soup and the various HTML/XML > parsers. I'm sure there's plenty to work on. > > My guess would be, that you try to write non-trivial example applications > and see what is needed. For example, you could write a script to > download/upload a Haskell wiki page logging in if necessary. Take a look of > what other WWW::Mechanize packages are used. That kind of stuff. > > Also, for a GSoC proposal you should try to convince the mentors, why your > project is useful for Haskell in general. So maybe you have some more > arguments there, too. > > / Thomas There's many benefits of having such library in Haskell: improved automated testing (as Yitzchak Gale mentioned) due to pure nature of inner algorithms (BrowserAction can be pure and be transformed into IO only on demand), static typing (just hate a bunch of stupid bugs while writing all those scripts in python/perl). We can use powerful HTML/XML parsers available there in Haskell (HXT with its "arrowed" XML filters). Haskell community will definitely benefit from such library. Firstly, as I see, in indirect way: I know many people that don't want to use or learn more about Haskell, saying it lacks libraries for their everyday work. Network libraries still aren't "cool" enough, and personally I want to improve them at least to the point when I can say "look! here's the network libraries and they aren't worse than yours, even better: pure and checked!" :). Secondly, new libraries are useful for the community directly, we have aforementioned lambdabot, e.g. I'd like to write some bots looking at new changes at haskellwiki or something like that, thing I'm doomed to code in sh&curl/perl/python now. -- Max From sethg at ropine.com Mon Apr 7 11:38:27 2008 From: sethg at ropine.com (Seth Gordon) Date: Mon Apr 7 11:34:10 2008 Subject: [Haskell-cafe] ANNOUNCE: Well-Typed LLP - The Haskell Consultants In-Reply-To: <20080406225002.GA15145@matrix.chaos.earth.li> References: <20080406225002.GA15145@matrix.chaos.earth.li> Message-ID: <47FA3FF3.3070506@ropine.com> Ian Lynagh wrote: > Fellow Haskellers, > > We (Bj?rn Bringert, Duncan Coutts and Ian Lynagh) are pleased to > announce that we have recently set up a Haskell consultancy company, > Well-Typed LLP (http://www.well-typed.com/). Congratulations! Do you have a plan to market your services to people who might be interested in, say, natural-language processing technology, but who have no particular interest in Haskell? Or do you have clients and potential clients that are specifically looking for Haskell programmers? From pkeir at dcs.gla.ac.uk Mon Apr 7 11:39:31 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Mon Apr 7 11:35:09 2008 Subject: [Haskell-cafe] Parsec expressions with alphaNum operators Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80E8A43@EX2.ad.dcs.gla.ac.uk> Hi, I'm using buildExpressionParser, and I'd like to use alphanumeric operator characters. I get an (unexpected "a") error though. With a test string like "-a" if "a" is used in any of the "reservedOpNames". I'm aiming for the Fortran operators like ".and.". The listing below may be helpful. It's taken from the Haskell wiki's "Parsing expressions and statements" article (minus the statement part).I've added an ":a:" operator. The article uses "~" as a unary operator (I'm heading for +/-). It can be tested with: $ parseTest exprparser "~a" -- code begins module Main where import Control.Monad(liftM) import Text.ParserCombinators.Parsec import Text.ParserCombinators.Parsec.Expr import Text.ParserCombinators.Parsec.Token import Text.ParserCombinators.Parsec.Language data Expr = Var String | Con Bool | Uno Unop Expr | Duo Duop Expr Expr deriving Show data Unop = Not deriving Show data Duop = And | Iff deriving Show data Stmt = Nop | String := Expr | If Expr Stmt Stmt | While Expr Stmt | Seq [Stmt] deriving Show def = emptyDef{ commentStart = "{-" , commentEnd = "-}" , identStart = letter , identLetter = alphaNum , opStart = oneOf "~&=:" , opLetter = oneOf "~&=:a" , reservedOpNames = ["~", "&", "=", ":=", ":a:"] , reservedNames = ["true", "false", "nop", "if", "then", "else", "fi", "while", "do", "od"] } TokenParser{ parens = m_parens , identifier = m_identifier , reservedOp = m_reservedOp , reserved = m_reserved , semiSep1 = m_semiSep1 , whiteSpace = m_whiteSpace } = makeTokenParser def exprparser :: Parser Expr exprparser = buildExpressionParser table term "expression" table = [ [Prefix (m_reservedOp "~" >> return (Uno Not))] , [Infix (m_reservedOp "&" >> return (Duo And)) AssocLeft] , [Infix (m_reservedOp "=" >> return (Duo Iff)) AssocLeft] , [Infix (m_reservedOp ":a:" >> return (Duo Iff)) AssocLeft] ] term = m_parens exprparser <|> liftM Var m_identifier <|> (m_reserved "true" >> return (Con True)) <|> (m_reserved "false" >> return (Con False)) play :: String -> IO () play inp = case parse exprparser "" inp of { Left err -> print err ; Right ans -> print ans } -- code ends Cheers, Paul Keir Research Student University of Glasgow Department of Computing Science pkeir@dcs.gla.ac.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080407/517bf39d/attachment.htm From prstanley at ntlworld.com Mon Apr 7 12:12:30 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Mon Apr 7 12:08:07 2008 Subject: [Haskell-cafe] deriving Message-ID: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> Hi data Bool = False | True deriving (Eq, Or, Show, Read) Bool is an instance of Eq, Ord, Show and Read. It is derived form these classes. If that is the meaning of the keyword deriving then wouldn't a different keyword such as from or derivative or even derivation be closer to the semantics of the concept? Discuss :-) Cheers, Paul From conal at conal.net Mon Apr 7 12:25:32 2008 From: conal at conal.net (Conal Elliott) Date: Mon Apr 7 12:21:14 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> Message-ID: I'm not getting it. Are you thinking that Bool itself "is derived form these classes", rather than those four instances for Bool? - Conal On Mon, Apr 7, 2008 at 9:12 AM, PR Stanley wrote: > Hi > data Bool = False | True > deriving (Eq, Or, Show, Read) > > Bool is an instance of Eq, Ord, Show and Read. It is derived form these > classes. If that is the meaning of the keyword deriving then wouldn't a > different keyword such as from or derivative or even derivation be closer to > the semantics of the concept? > Discuss :-) > > Cheers, > Paul > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080407/6ff89024/attachment.htm From chris.casinghino at gmail.com Mon Apr 7 12:33:37 2008 From: chris.casinghino at gmail.com (Chris Casinghino) Date: Mon Apr 7 12:29:19 2008 Subject: [Haskell-cafe] Parsec expressions with alphaNum operators In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80E8A43@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80E8A43@EX2.ad.dcs.gla.ac.uk> Message-ID: Hi, 2008/4/7 Paul Keir : > I'm using buildExpressionParser, and I'd like to use alphanumeric operator > characters. I get an (unexpected "a") error though. With a test string like > "-a" if "a" is used in any of the "reservedOpNames". I'm aiming for the > Fortran operators like ".and.". > > ... reservedOp checks to make sure that whatever it parses isn't immediately followed by another valid operator character (the idea being, I think, that then whoever wrote the string being parsed probably meant for that other longer operator to be one token). This causes your error, since it can't parse the reservedOp "~", and "~a" itself is not anything. You'll notice that, for example, "~ a" parses just fine. I don't seen any perfect solution. If you want to use the token and expression modules in this way, you'll have to redefine your operators so as not to intersect with your valid identifiers. Alternatively, you can roll your own token parsers (though parsec does what it does for good reasons, so you might see some unexpected behavior). Or you could just mandate that operators must be followed by a space. Good luck! --Chris Casinghino From Tom.Schrijvers at cs.kuleuven.be Mon Apr 7 12:33:02 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Mon Apr 7 12:30:19 2008 Subject: [Haskell-cafe] Re: type families and type signatures In-Reply-To: <47FA30A7.4000504@cs.pdx.edu> References: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> <47FA30A7.4000504@cs.pdx.edu> Message-ID: On Mon, 7 Apr 2008, Mark P Jones wrote: > The surprising thing about this example is the fact that > the definition of foo is accepted, and not the fact that > the definition of foo' is rejected. At least in Manuel's > "equivalent" program using functional dependencies, both > functions have ambiguous types, and hence both would be > rejected. It sounds like your implementation may be using > a relaxed approach to ambiguity checking that delays > ambiguity checking from the point of definition to the > point of use. Although this is probably still sound, it > can lead to puzzling error diagnostics ... On the algorithmic level I don't see a relaxed approach to ambiguity checking. If alpha is a unifiction variable, you get for the first body (Id a -> Id a) ~ (alpha ~ alpha) where there is no ambiguity: the unique solution (modulo equality theory) is alpha := Id a. For the second body you get (Id a -> Id a) ~ (Id alpha -> Id alhpa) This equation reduces to Id a ~ Id alpha. Our algorithm stops here. There is in general no single solution for alpha (*) in such an equation, as opposed to the above case. I hope this clarifies our algorithm. Cheers, Tom > All the best, > Mark > > Tom Schrijvers wrote: >>>>> type instance Id Int = Int >>>>> >>>>> foo :: Id a -> Id a >>>>> foo = id >>>>> >>>>> foo' :: Id a -> Id a >>>>> foo' = foo Is this expected? >>>> >>>> Yes, unfortunately, this is expected, although it is very unintuitive. >>>> This is for the following reason. >>> >>> Huh? This sounds very wrong to me, simply because foo and foo' have >>> the very same type. >> >> Type systems reject programs that don't go wrong. It's hard to understand >> on the basis of such a single program why it should be rejected. The >> problem is decidability. There is no algorithm that accepts all >> well-behaved programs and rejects all ill-behaved programs. There probably >> is an algorithm that accepts a particular program. >> >> So far we haven't found an algorithm that accepts this example, that is >> decidable and sufficiently general to cover many other useful cases. This >> is our motivation for rejecting this program. >> >> Consider it a challenge to find a better algorithm in the design space. >> >> Cheers, >> >> Tom >> >> -- >> Tom Schrijvers >> >> Department of Computer Science >> K.U. Leuven >> Celestijnenlaan 200A >> B-3001 Heverlee >> Belgium >> >> tel: +32 16 327544 >> e-mail: tom.schrijvers@cs.kuleuven.be >> url: http://www.cs.kuleuven.be/~toms/ >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From prstanley at ntlworld.com Mon Apr 7 12:43:10 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Mon Apr 7 12:38:43 2008 Subject: [Haskell-cafe] deriving In-Reply-To: References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> Message-ID: <7.0.1.0.0.20080407173743.01d7f210@ntlworld.com> Hi >data Bool = False | True > deriving (Eq, Or, Show, Read) > >Bool is an instance of Eq, Ord, Show and Read. It is derived form >these classes. If that is the meaning of the keyword deriving then >wouldn't a different keyword such as from or derivative or even >derivation be closer to the semantics of the concept? >Discuss :-) > >Cheers, >Paul >I'm not getting it. Are you thinking that Bool itself "is derived >from these classes", rather than those four instances for Bool? - Conal >Paul: >I am aware that Bool is an instance of Eq, Ord, ... What I'm not >sure about is the terminology used here. Deriving, deriving what >from Eq, Ord, ...? How about data Bool = False | True from (Eq, Ord, Show, Read) although I have a feeling that "from" is already used somewhere in Haskell. Paul From haskell at colquitt.org Mon Apr 7 13:05:20 2008 From: haskell at colquitt.org (John Dorsey) Date: Mon Apr 7 13:01:16 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> Message-ID: <20080407170520.GA21314@colquitt.org> Paul, > Hi > data Bool = False | True > deriving (Eq, Or, Show, Read) > > Bool is an instance of Eq, Ord, Show and Read. It is derived form > these classes. No. "deriving ..." here does not mean that Bool is derived from those classes; it's not a statement about inheritance or anything similar. "deriving ..." means that the class instances for Bool, for those four type classes, are automatically derived from the definition of Bool. Does this make more sense? John From droundy at darcs.net Mon Apr 7 13:22:25 2008 From: droundy at darcs.net (David Roundy) Date: Mon Apr 7 13:18:07 2008 Subject: [Haskell-cafe] announcing the darcs 2.0.0 release Message-ID: <20080407172225.GB16717@darcs.net> Hello darcs users, I am pleased to announce the release of darcs 2.0.0! It's been a long time coming, and hopefully you will be pleased with the result. Notable new features include (in no particular order): * New ssh-connnection mode that dramatically improves connection times when darcs 2.0.0 is present on the server as well as the client. * New "hashed" format that improves darcs' robustness with regard to network or filesystem errors, and also allows for efficient (and safe) caching of patch data, greatly improving access times to a repository that you have had previous contact with--which is the common case of pulling, pushing or sending. This format allows patches to move back and forth with darcs1-format repositories, and is the recommended format (with an old-format mirror) if you do not wish to require darcs 2.0.0, but want to benefit from most of its improvements. * New "darcs-2" format, which features improved conflict handling, and also has all the benefits of the hashed format. Because this format features new and different semantics, it is not possible to interact with darcs 1.x, and care must be taken in switching to this format. It is the recommended format for new projects (although we haven't made it the default). * The --partial get is now replaced with a --lazy get when using hashed formats, and in fact if you forget to provide one of these flags on the command line, you can acheive a lazy get simply by hitting control-C after darcs prints a message suggesting you do this. Lazy repositories are identical to full repositories so long as you have a working network connection and the original repository is accessible, with patches downloaded as they are needed. When the original repository is no longer accessible, a lazy repository will behave like the old --partial repositories. * We have added support for pipelined http downloading via either libwww or a very recent version of libcurl. Neither of these is yet the default, but it is recommended that you try one of them if possible, as they greatly improve download times. * There is now a configurable global cache, which can help reduce network traffic if you have multiple local copies of the same--or similar--remote repositories. * I'm sure there are other new features, but this is all that comes to mind at the moment. BUGS There are numerous issues with the --darcs-2 repository semantics (see a discussion at http://wiki.darcs.net/DarcsWiki/DarcsTwo). In general, I believe the status is that anything you could do with darcs 1.x you can do with the darcs-2 semantics, but the high-level code hasn't been updated to take into account the new possibilities opened up by the new semantics. In particular, patch dependencies are much more complex. Alas, there has not been enough time (or sufficient contributors) to make the code take these complexities into account, and if you're clever you can reveal bugs. You have been warned. Darcs 2.0.0 contains some performance regressions when running with large repositories. It is possible that these regressions will be sufficient to prevent its effective use in some projects. If this describes your project--and the only way to know is to try it--then I recommend considering either switching to a different revision control system, or helping us to improve darcs. The former is certainly the easier path. If I knew how to easily make darcs dramatically faster, I would have done so. FUTURE DIRECTIONS FOR DARCS The existing model for darcs maintenance has been the use of two branches, a darcs-stable branch for well-tested changes, and a darcs-unstable branch for more experimental work. Each branch has a separate maintainer, so most patches will be reviewed by two maintainers before making it into a darcs release. This is quite a nice system. Unfortunately, it is also a rather labor-intensive process, and due to a lack of contributors, we've moving to a more streamlined process. Starting with the darcs 2.0.0 release, there will be just one central branch of darcs and only one maintainer: for now this is me, David Roundy. Moreover, I will be attempting to act as a much lower-profile maintainer than we've had previously. I will not be reading bug reports, reading the darcs-users email list or even the darcs-devel mailing list. I will only be reviewing patches that are contributed. I will not write up long user-friendly release announcements like this for future darcs releases. I will only be reviewing and applying contributed patches. What does this mean? It means that if darcs is to continue to improve, we need new contributors. If bug reports are to be read, responded to and bugs are to be fixed, we need new contributors. If darcs is to be made more efficient, we need new contributors. The new URL for the darcs repository is simply http://darcs.net. (Yes, this is a lame ending to the email, but I'm sending it anyhow, because I'm tired, and I've got to get this done.) From gusnieslu at student.gu.se Mon Apr 7 14:17:06 2008 From: gusnieslu at student.gu.se (ln) Date: Mon Apr 7 14:12:25 2008 Subject: [Haskell-cafe] Problem building HXT Message-ID: <47FA6522.1050007@student.gu.se> Hi, I would like to try HXT, but I can't manage to build it. I resolved all the dependencies, but I get the following error: > > ln@igemyvuci:~/Desktop/hxt$ make all > > make -C src all VERSION=7.5 > > make[1]: Entering directory `/home/ln/Desktop/hxt/src' > > make install_local_hxt > > make[2]: Entering directory `/home/ln/Desktop/hxt/src' > > ghc -Wall -O2 -fglasgow-exts -ignore-package hxt -package-name hxt-7.5 > > -package parsec -package HTTP -package tagsoup --make HXT.hs > > [ 1 of 143] Compiling Text.XML.HXT.Validator.RE ( > > Text/XML/HXT/Validator/RE.hs, Text/XML/HXT/Validator/RE.o ) > > (.....) > > [100 of 143] Compiling Text.XML.HXT.Parser.TagSoup ( > > Text/XML/HXT/Parser/TagSoup.hs, Text/XML/HXT/Parser/TagSoup.o ) > > Text/XML/HXT/Parser/TagSoup.hs:305:21: Not in scope: `options' > > make[2]: *** [libHShxt.a] Error 1 The alternative installation method with cabal leads to the same result. Using Ubuntu 8.04 Beta and GHC6.8. Maybe there are incompabilities with newer versions of the dependencies? Would appreciate any help. Regards Lukas From prstanley at ntlworld.com Mon Apr 7 14:27:38 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Mon Apr 7 14:23:16 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <20080407170520.GA21314@colquitt.org> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <20080407170520.GA21314@colquitt.org> Message-ID: <7.0.1.0.0.20080407192520.01d88170@ntlworld.com> > > Hi > > data Bool = False | True > > deriving (Eq, Or, Show, Read) > > > > Bool is an instance of Eq, Ord, Show and Read. It is derived form > > these classes. > >No. "deriving ..." here does not mean that Bool is derived from those >classes; it's not a statement about inheritance or anything similar. > >"deriving ..." means that the class instances for Bool, for those four >type classes, are automatically derived from the definition of Bool. > >Does this make more sense? No, sorry. I'm not sure how this differs from my definition. Could you elaborate please? Paul From bulat.ziganshin at gmail.com Mon Apr 7 14:28:12 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Apr 7 14:40:35 2008 Subject: [Haskell-cafe] announcing the darcs 2.0.0 release In-Reply-To: <20080407172225.GB16717@darcs.net> References: <20080407172225.GB16717@darcs.net> Message-ID: <1201735373.20080407222812@gmail.com> Hello David, Monday, April 7, 2008, 9:22:25 PM, you wrote: > * I'm sure there are other new features, but this is all that comes to > mind at the moment. there was some issues with efficiency of darcs 1.x. am i correctly understood that these issues was not addressed by new release? its hard to understand why darcs 2.0 is better than 1.x from your announcement. afair from gsoc project your primary goal was to improve patches flexibility? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From allbery at ece.cmu.edu Mon Apr 7 14:47:25 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Apr 7 14:43:07 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> Message-ID: <0C1776C0-43E3-471D-BE45-10BA55E2C99B@ece.cmu.edu> On Apr 7, 2008, at 12:12 , PR Stanley wrote: > Hi > data Bool = False | True > deriving (Eq, Or, Show, Read) > > Bool is an instance of Eq, Ord, Show and Read. It is derived form > these classes. If that is the meaning of the keyword deriving then > wouldn't a different keyword such as from or derivative or even > derivation be closer to the semantics of the concept? "deriving" doesn't declare superclasses; it means "please auto- generate code for me implementing instances for these classes". See http://haskell.org/onlinereport for the semantics of automatic instance deriving. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Mon Apr 7 14:53:19 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Apr 7 14:49:05 2008 Subject: [Haskell-cafe] announcing the darcs 2.0.0 release In-Reply-To: <1201735373.20080407222812@gmail.com> References: <20080407172225.GB16717@darcs.net> <1201735373.20080407222812@gmail.com> Message-ID: <3981A961-C902-4F40-BDB4-31FA29A9A513@ece.cmu.edu> On Apr 7, 2008, at 14:28 , Bulat Ziganshin wrote: > Hello David, > > Monday, April 7, 2008, 9:22:25 PM, you wrote: > >> * I'm sure there are other new features, but this is all that >> comes to >> mind at the moment. > > there was some issues with efficiency of darcs 1.x. am i correctly > understood that these issues was not addressed by new release? From discussion of the regressions on IRC, I'm given to understand that hashing makes many things faster but a few operations on very large repos are now slower. As darcs1 was uniformly almost unusably slow on such repos, the result is that they're somewhat faster in general but some operations are still very slow; work is still being done to optimize these. That said, I think a large part of the point behind darcs2 is to fix some of the odd corner cases in patch reconciliation that could lead to having to throw out your repo and start over in darcs1 (which I had to do several times with my ghc repo). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From droundy at darcs.net Mon Apr 7 15:08:08 2008 From: droundy at darcs.net (David Roundy) Date: Mon Apr 7 15:03:52 2008 Subject: [Haskell-cafe] announcing the darcs 2.0.0 release In-Reply-To: <1201735373.20080407222812@gmail.com> References: <20080407172225.GB16717@darcs.net> <1201735373.20080407222812@gmail.com> Message-ID: <20080407190806.GC16717@darcs.net> On Mon, Apr 07, 2008 at 10:28:12PM +0400, Bulat Ziganshin wrote: > Monday, April 7, 2008, 9:22:25 PM, you wrote: > > * I'm sure there are other new features, but this is all that comes to > > mind at the moment. > > there was some issues with efficiency of darcs 1.x. am i correctly > understood that these issues was not addressed by new release? Some efficiency issues have dramatically improved. Others have gotten worse. I don't know how better to summarize the situation than that. > its hard to understand why darcs 2.0 is better than 1.x from your > announcement. afair from gsoc project your primary goal was to improve > patches flexibility? Yes, it's much better at dealing with conflicts, if you use the darcs-2 format. And it's less buggy than 1.0.9 is, which directly relates to one slowdown that I'm aware of. Try it and you can see whether you like it more. There's also the factor that darcs 1.0.x isn't going to see another release. If you don't want to switch to eventually darcs 2.0, then I would strongly recommend that you switch to some other revision constrol system. -- David Roundy Department of Physics Oregon State University From haskell at colquitt.org Mon Apr 7 15:08:31 2008 From: haskell at colquitt.org (John Dorsey) Date: Mon Apr 7 15:04:12 2008 Subject: (forw) Re: [Haskell-cafe] deriving Message-ID: <20080407190828.GA24102@colquitt.org> I meant to send this reply to the cafe. ----- Forwarded message ----- Date: Mon, 7 Apr 2008 15:05:00 -0400 To: PR Stanley Subject: Re: [Haskell-cafe] deriving Paul, > No, sorry. I'm not sure how this differs from my definition. > Could you elaborate please? Gladly. I haven't tested any of the code below, so pardon any typos and thinkos. It sounded like you were trying to say that Bool derives from Eq, Ord, Show, and Read, and thus the keyword "from" would apply. Of course, I may have misunderstood your intent. I was countering by saying that the "deriving" keyword indicates something different. I'll try to describe what I meant in a little more detail. A type class definition defines properties of the type class. Eg., class Example a where foo :: a bar :: a -> a The class is then related to specific types by giving them instance declarations. The instance declarations can be explicit, as in data Xyzzy = Xy | Zzy instance Example Xyzzy where foo = Xy bar = const Zzy Sometimes the instance declaration can be automatically derived instead, which looks like: -- non-working code, see below data Xyzzy = Xy | Zzy deriving (Example) This lets the compiler derive the "obvious" class instance declaration. But it won't work for just any class, because the compiler needs to know how to derive "obvious" instances. A few classes have deriving machinery "built-in": Eq, Ord, Enum, Bounded, Show, Read. "deriving (Example)" won't work, since that machinery doesn't exist. With effort, you could implement this "automatic derivation" machinery for your own types, at least in GHC. I've never needed it, so I've never learned exactly how to do it. In short, so "data Foo [...] deriving (Eq)" means: "define a new type Foo, and automatically derive its class instance for Eq". Does this help? Regards, John ----- End forwarded message ----- From westondan at imageworks.com Mon Apr 7 15:15:13 2008 From: westondan at imageworks.com (Dan Weston) Date: Mon Apr 7 15:10:55 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> Message-ID: <47FA72C1.1060308@imageworks.com> Paul, To answer your second question (which everyone else ignored): Yes. A different keyword might have been more descriptive, such as "automatically_deriving_instances_for". There is always a struggle between concision [1] and descriptiveness in syntax. With short keywords, you pay up front. With longer keywords, there's no money down, but you have an endless monthly payment that gets really tedious after a while. Dan [1] Yes, I know that "conciseness" is the much more common and accepted word for this, but if we can say "precision", "decision", and "incision", then it seems foolish to not also use "concision". I will henceforth take on this quixotic quest to promote the use of "concision". PR Stanley wrote: > Hi > data Bool = False | True > deriving (Eq, Or, Show, Read) > > Bool is an instance of Eq, Ord, Show and Read. It is derived form these > classes. If that is the meaning of the keyword deriving then wouldn't a > different keyword such as from or derivative or even derivation be > closer to the semantics of the concept? > Discuss :-) > > Cheers, > Paul > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From haberg at math.su.se Mon Apr 7 15:42:16 2008 From: haberg at math.su.se (Hans Aberg) Date: Mon Apr 7 15:38:09 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <47FA72C1.1060308@imageworks.com> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> Message-ID: On 7 Apr 2008, at 21:15, Dan Weston wrote: > To answer your second question (which everyone else ignored): > > Yes. A different keyword might have been more descriptive, such as > "automatically_deriving_instances_for". They are called instantiations, which Haskell can supply automatically in some cases. And there is already a keyword "instance" for that - in general, it is good to keep down the number of keywords. So data Bool = False | True instance (Eq, Ord, Enum, Read, Show, Bounded) might have been better. But here, one would have to think about how the compiler should be able to distinguish data Bool = False | True instance (Eq) from data Bool = False | True instance Eq Bool where x == y = ... One wants to be able to do that with as little lookahead as possible. Hans Aberg From allbery at ece.cmu.edu Mon Apr 7 15:48:40 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Apr 7 15:44:22 2008 Subject: [Haskell-cafe] deriving In-Reply-To: References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> Message-ID: <0F57663B-B445-4057-ABBA-D093A81904C5@ece.cmu.edu> On Apr 7, 2008, at 15:42 , Hans Aberg wrote: > But here, one would have to think about how the compiler should be > able to distinguish > data Bool = False | True > instance (Eq) > from > data Bool = False | True > > instance Eq Bool where > x == y = ... Layout already does that, doesn't it? The former, being indented, is a continuation line. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From monnier at iro.umontreal.ca Mon Apr 7 16:04:21 2008 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Mon Apr 7 16:00:13 2008 Subject: [Haskell-cafe] Re: type families and type signatures References: <1207521542.2438.17.camel@Clunker> Message-ID: > Id is an operation over types yielding a type, as such it doesn't make > much sense to me to have (Id a -> Id a) but rather something like (a -> > Id a). Actually, it can make perfect sense: e.g. if the `Id' function acts as a constraint. Stefan From ganesh at earth.li Mon Apr 7 16:29:21 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Mon Apr 7 16:25:01 2008 Subject: [Haskell-cafe] translating from fundeps into type families Message-ID: Hi, Can I have some advice on translating the attached Test1.hs into type families? My attempt at doing so is in Test1a.hs, but firstly it requires FlexibleInstances where Test1.hs didn't, and secondly it fails because it can't infer the instance for Bar (Either Int Int) whereas the fundeps version had no problems there. (And yes, this is another cut down example of something I really want to do :-) Cheers, Ganesh -------------- next part -------------- A non-text attachment was scrubbed... Name: Test1.hs Type: text/x-haskell Size: 571 bytes Desc: Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080407/86359e51/Test1.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Test1a.hs Type: text/x-haskell Size: 482 bytes Desc: Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080407/86359e51/Test1a.bin From hpacheco at gmail.com Mon Apr 7 17:30:33 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Mon Apr 7 17:26:14 2008 Subject: [Haskell-cafe] Type Families: infinite compile process? Message-ID: <7b92c2840804071430p7bf0bff3vcebfaf38211b3fb6@mail.gmail.com> Hi guys, I have been experimenting some weird stuff (risky, yes I know) but the behaviour was certainly not the one I expected: {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} module Nest where data Nest a = Nil | Cons a (Nest (a,a)) type family F a x :: * type instance F (Nest a) x = Either () (a,F (Nest (a,a)) x) fnn :: F (Nest Int) (Nest Int) fnn = Left () The following module fails to compile (or better, compilation never ends). Maybe there is something very bad going on due to the undecidable-instances extension? Any clue? hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080407/6d2430db/attachment.htm From hpacheco at gmail.com Mon Apr 7 17:46:40 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Mon Apr 7 17:42:19 2008 Subject: [Haskell-cafe] Re: Type Families: infinite compile process? In-Reply-To: <7b92c2840804071430p7bf0bff3vcebfaf38211b3fb6@mail.gmail.com> References: <7b92c2840804071430p7bf0bff3vcebfaf38211b3fb6@mail.gmail.com> Message-ID: <7b92c2840804071446i3dd701adud562dd09fcd673b7@mail.gmail.com> The problem is that the representation probably does not reduce to a normal form. Say, for the case type instance F (Nest a) x = Either() (a,F a x) fnn :: F (Nest a) (Nest a) fnn = Left () it compiles ok. But why can't the representation be infinite, like any other infinite data type? Cheers, hugo On Mon, Apr 7, 2008 at 10:30 PM, Hugo Pacheco wrote: > Hi guys, > I have been experimenting some weird stuff (risky, yes I know) but the > behaviour was certainly not the one I expected: > > {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} > > module Nest where > > data Nest a = Nil | Cons a (Nest (a,a)) > > type family F a x :: * > type instance F (Nest a) x = Either () (a,F (Nest (a,a)) x) > > fnn :: F (Nest Int) (Nest Int) > fnn = Left () > > The following module fails to compile (or better, compilation never ends). > > Maybe there is something very bad going on due to the > undecidable-instances extension? > > Any clue? > hugo > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080407/d692d401/attachment.htm From mpj at cs.pdx.edu Mon Apr 7 17:56:44 2008 From: mpj at cs.pdx.edu (Mark P Jones) Date: Mon Apr 7 17:52:30 2008 Subject: [Haskell-cafe] Re: type families and type signatures In-Reply-To: References: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> <47FA30A7.4000504@cs.pdx.edu> Message-ID: <47FA989C.7000002@cs.pdx.edu> Hi Tom, It seems we are thinking of different things. I was referring to the characterization of a type of the form P => t as being "ambiguous" if there is a type variable in P that is not determined by the variables in t; this condition is used in Haskell to establish coherence (i.e., to show that a program has a well-defined semantics). I don't know if you have defined/studied corresponding notions of ambiguity/coherence in your framework. Instead, I was referring to what Manuel described as "the equivalent problem using FDs": class IdC a b | a -> b instance IdC Int Int bar :: IdC a b => b -> b bar = id bar' :: IdC a b => b -> b bar' = bar In this program, both bar and bar' have ambiguous types (the variable 'a' in each of the contexts is not uniquely determined by the variable 'b' appearing on the right), and so *neither* one of these definitions is valid. This behavior differs from what has been described for your approach, so perhaps Manuel's example isn't really "equivalent" after all. Technically, one could ignore the ambiguous type signature for bar, because the *principal* type of bar (as opposed to the *declared type*) is not ambiguous. However, in practice, there is little reason to allow the definition of a function with an ambiguous type because such functions cannot be used in practice: the ambiguity that is introduced in the type of bar will propagate to any other function that calls it, either directly or indirectly. For this reason, it makes sense to report the ambiguity at the point where bar is defined, instead of deferring that error to places where it is used, like the definition of bar'. (The latter is what I mean by "delayed" ambiguity checking.) Hope that helps, Mark Tom Schrijvers wrote: > On Mon, 7 Apr 2008, Mark P Jones wrote: > >> The surprising thing about this example is the fact that >> the definition of foo is accepted, and not the fact that >> the definition of foo' is rejected. At least in Manuel's >> "equivalent" program using functional dependencies, both >> functions have ambiguous types, and hence both would be >> rejected. It sounds like your implementation may be using >> a relaxed approach to ambiguity checking that delays >> ambiguity checking from the point of definition to the >> point of use. Although this is probably still sound, it >> can lead to puzzling error diagnostics ... > > On the algorithmic level I don't see a relaxed approach to ambiguity > checking. > > If alpha is a unifiction variable, you get for the first body > > (Id a -> Id a) ~ (alpha ~ alpha) > > where there is no ambiguity: the unique solution (modulo equality > theory) is alpha := Id a. > > For the second body you get > > (Id a -> Id a) ~ (Id alpha -> Id alhpa) > > This equation reduces to Id a ~ Id alpha. Our algorithm stops here. > There is in general no single solution for alpha (*) in such an > equation, as opposed to the above case. > > I hope this clarifies our algorithm. > > Cheers, > > Tom From haberg at math.su.se Mon Apr 7 18:28:53 2008 From: haberg at math.su.se (Hans Aberg) Date: Mon Apr 7 18:24:38 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <0F57663B-B445-4057-ABBA-D093A81904C5@ece.cmu.edu> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> <0F57663B-B445-4057-ABBA-D093A81904C5@ece.cmu.edu> Message-ID: On 7 Apr 2008, at 21:48, Brandon S. Allbery KF8NH wrote: >> But here, one would have to think about how the compiler should be >> able to distinguish >> data Bool = False | True >> instance (Eq) >> from >> data Bool = False | True >> >> instance Eq Bool where >> x == y = ... > > Layout already does that, doesn't it? The former, being indented, > is a continuation line. At least Hugs complains if one does not indent "deriving ...", but I do not know what the standard says. If is required, then it can be changed. Hans From bulat.ziganshin at gmail.com Mon Apr 7 18:30:12 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Apr 7 18:36:34 2008 Subject: [Haskell-cafe] deriving In-Reply-To: References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> <0F57663B-B445-4057-ABBA-D093A81904C5@ece.cmu.edu> Message-ID: <655352789.20080408023012@gmail.com> Hello Hans, Tuesday, April 8, 2008, 2:28:53 AM, you wrote: > At least Hugs complains if one does not indent "deriving ...", but I > do not know what the standard says. If is required, then it can be > changed. deriving is a part of data clause and indentation just allows us to continue clause from prev. line. if not indented, deriving will be parsed as separate clause (and btw such clause, "standalone deriving" was added to ghc 6.8) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From gwern0 at gmail.com Mon Apr 7 18:57:39 2008 From: gwern0 at gmail.com (gwern0@gmail.com) Date: Mon Apr 7 18:53:58 2008 Subject: [Haskell-cafe] problems building hpodder In-Reply-To: <20080406222410.GA8408@diana.vm.bytemark.co.uk> References: <20080406222410.GA8408@diana.vm.bytemark.co.uk> Message-ID: <20080407225739.GA649997@localhost> On 2008.04.07 00:24:10 +0200, Karl Hasselstr?m scribbled 0.9K characters: > I'm trying to build hpodder 1.1.2 with ghc 6.8.2. I successfully > downloaded, built, and installed (the latest versions of) all its > dependencies, but when building hpodder itself, I get > > FeedParser.hs:146:26: > `Content' is not applied to enough type arguments > Expected kind `??', but `Content' has kind `* -> *' > In the type `Content -> Either String String' > In the type `String -> Content -> Either String String' > In the type signature for `strof_either': > strof_either :: String -> Content -> Either String String > > I don't know enough Haskell to even determine what kind of problem > this is -- wrong version of some dependency? Wrong version of ghc? > Help appreciated. :-) > > ( FWIW, the hackage auto-builder thingie seems to have the exact same > problem I have: > http://hackage.haskell.org/packages/archive/hpodder/1.1.2/logs/failure/ghc-6.8 > ) > > -- > Karl Hasselstr?m, kha@treskal.com The issue here isn't GHC, but I think it's the former. If we open up the FeedParser.hs file, we see that the problem is that the type being inferred from what the code does clashes with the type gotten from what the code says. The issue is this Content type. A quick search shows that Content isn't defined in FeedParser.hs, and so if we comment out imports, we find that Content is coming from Text.XML.HaXml, and is documented here: . So almost certainly the issue is that HaXml has updated and changed things around in a way that broke Hpodder; not surprising, since HaXml-1.19.2 is as recent as 14 January 2008, and Goerzen may simply not have updated and discovered the error before he released Hpodder in February. If the problem is too-recent HaXml, there's an obvious work around. You could install HaXml-1.13.3 and edit the hpodder.cabal file to replace the 'HaXml>=' bit with 'HaXml==1.13.3'. That works for me. -- gwern Etacs FOSS NTIS SUPIR mindwar NATOA SARA niche DNR 3B2 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080407/50201930/attachment.bin From prstanley at ntlworld.com Mon Apr 7 19:29:28 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Mon Apr 7 19:25:04 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <20080407190500.GB21314@colquitt.org> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <20080407170520.GA21314@colquitt.org> <7.0.1.0.0.20080407192520.01d88170@ntlworld.com> <20080407190500.GB21314@colquitt.org> Message-ID: <7.0.1.0.0.20080408002802.01d156a8@ntlworld.com> Hi, Thank you very much for your helpful replies. So, we define (or is it declare) a class with a polymorphic value(s which will be used in defining function types or functions associated with that class. The data types are then used for deriving instances of that class specific to each data type. The function defined in the general class can be redefined if necessary. It sort of reminds me of specialisation in OO. Get thee behind me beast. :-) Any comments? Cheers, Paul At 20:05 07/04/2008, you wrote: >Paul, > > > No, sorry. I'm not sure how this differs from my definition. > > Could you elaborate please? > >Gladly. I haven't tested any of the code below, so pardon any typos >and thinkos. > >It sounded like you were trying to say that Bool derives from Eq, Ord, >Show, and Read, and thus the keyword "from" would apply. Of course, >I may have misunderstood your intent. > >I was countering by saying that the "deriving" keyword indicates something >different. I'll try to describe what I meant in a little more detail. > >A type class definition defines properties of the type class. Eg., > >class Example a where > foo :: a > bar :: a -> a > >The class is then related to specific types by giving them instance >declarations. The instance declarations can be explicit, as in > >data Xyzzy = Xy | Zzy >instance Example Xyzzy where > foo = Xy > bar = const Zzy > >Sometimes the instance declaration can be automatically derived instead, >which looks like: > >data Xyzzy = Xy | Zzy > deriving (Example) > >This lets the compiler derive the "obvious" class instance declaration. >But it won't work for just any class, because the compiler needs to know >how to derive "obvious" instances. A few classes have deriving >machinery "built-in": Eq, Ord, Enum, Bounded, Show, Read. > >"deriving (Example)" won't work, since that machinery doesn't exist. > >With effort, you could implement this "automatic derivation" machinery >for your own types, at least in GHC. I've never needed it, so I've >never learned exactly how to do it. > >In short, so "data Foo [...] deriving (Eq)" means: "define a new type Foo, >and automatically derive its class instance for Eq". > >Does this help? > >Regards, >John From ryani.spam at gmail.com Mon Apr 7 20:39:32 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Apr 7 20:35:12 2008 Subject: [Haskell-cafe] Type Families: infinite compile process? In-Reply-To: <7b92c2840804071430p7bf0bff3vcebfaf38211b3fb6@mail.gmail.com> References: <7b92c2840804071430p7bf0bff3vcebfaf38211b3fb6@mail.gmail.com> Message-ID: <2f9b2d30804071739w716a1754x57403c47d960961@mail.gmail.com> The type system requires strong normalization. By specifying "allow-undecidable-instances", you are agreeing to provide proofs of strong normalization outside of the compiler, instead of relying on the compiler to derive them for you. Because you have claimed that your instance is strongly normalizing, the compiler is attempting to evaluate your type to normal form, in order to verify that fnn has the correct type... F (Nest Int) (Nest Int) ~ Either () (Nest Int, F (Nest (Int, Int)) (Nest Int) ~ Either () (Nest Int, Either () (Nest (Int, Int), F (Nest ((Int,Int),(Int,Int)) (Nest Int))) ~ ... There is no concrete type for the type system to hold on to here; if this was allowed we get _|_ at the type level which I suspect makes the type system inconsistent. You can break the infinite recursion with a newtype, which gives the type system a concrete type to hold on to. This works: {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} module Nest where data Nest a type family F a x :: * newtype FWrap a x = FWrap (F a x) type instance F (Nest a) x = Either () (a, FWrap (Nest (a,a)) x) fnn :: F (Nest Int) (Nest Int) fnn = Left () fnn2 :: F (Nest Int) (Nest Int) fnn2 = Right (1, FWrap (Right ((2,3), FWrap (Left ())))) Some comments: 1) You don't ever use the contents of Nest so I reduced it to an empty datatype; it's just a constructor for F to case against.. 2) You never use the "x" argument of F; is that intentional? -- ryan On 4/7/08, Hugo Pacheco wrote: > Hi guys, > > I have been experimenting some weird stuff (risky, yes I know) but the > behaviour was certainly not the one I expected: > > {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} > > module Nest where > > > data Nest a = Nil | Cons a (Nest (a,a)) > > type family F a x :: * > type instance F (Nest a) x = Either () (a,F (Nest (a,a)) x) > > fnn :: F (Nest Int) (Nest Int) > fnn = Left () > > The following module fails to compile (or better, compilation never ends). > > Maybe there is something very bad going on due to the undecidable-instances > extension? > > Any clue? > hugo > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From ryani.spam at gmail.com Mon Apr 7 20:40:18 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Apr 7 20:35:58 2008 Subject: [Haskell-cafe] Type Families: infinite compile process? In-Reply-To: <2f9b2d30804071739w716a1754x57403c47d960961@mail.gmail.com> References: <7b92c2840804071430p7bf0bff3vcebfaf38211b3fb6@mail.gmail.com> <2f9b2d30804071739w716a1754x57403c47d960961@mail.gmail.com> Message-ID: <2f9b2d30804071740jdb73bfcu147381c848cfba76@mail.gmail.com> Actually, this even works without undecidable instances! On 4/7/08, Ryan Ingram wrote: > {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} From jgoerzen at complete.org Mon Apr 7 21:20:24 2008 From: jgoerzen at complete.org (John Goerzen) Date: Mon Apr 7 21:16:17 2008 Subject: [Haskell-cafe] problems building hpodder In-Reply-To: <20080407225739.GA649997@localhost> References: <20080406222410.GA8408@diana.vm.bytemark.co.uk> <20080407225739.GA649997@localhost> Message-ID: <200804072020.25068.jgoerzen@complete.org> On Monday 07 April 2008 5:57:39 pm gwern0@gmail.com wrote: > So almost certainly the issue is that HaXml has updated and changed things > around in a way that broke Hpodder; not surprising, since HaXml-1.19.2 is > as recent as 14 January 2008, and Goerzen may simply not have updated and > discovered the error before he released Hpodder in February. I won't be updating it anytime soon, in fact. 1.19.2 is a development version, according to the author, so I will stick with 1.13.3 -- the stable, released version. Unfortunately, Hackage has no way to indicate stable vs. alpha, I guess. (That would make life easier here.) I suppose I ought to also post something on the hpodder wiki and update the Cabal build-deps so it gets the right HaXml version. > > If the problem is too-recent HaXml, there's an obvious work around. You > could install HaXml-1.13.3 > > and edit the hpodder.cabal file to replace the 'HaXml>=' bit with > 'HaXml==1.13.3'. That works for me. > > -- > gwern > Etacs FOSS NTIS SUPIR mindwar NATOA SARA niche DNR 3B2 From gwern0 at gmail.com Mon Apr 7 22:25:41 2008 From: gwern0 at gmail.com (gwern0@gmail.com) Date: Mon Apr 7 22:22:28 2008 Subject: [Haskell-cafe] Problem building HXT In-Reply-To: <47FA6522.1050007@student.gu.se> References: <47FA6522.1050007@student.gu.se> Message-ID: <20080408022540.GA742043@localhost> On 2008.04.07 20:17:06 +0200, ln scribbled 1.1K characters: > Hi, > > I would like to try HXT, but I can't manage to build it. I resolved all > the dependencies, but I get the following error: > > > > ln@igemyvuci:~/Desktop/hxt$ make all > > > make -C src all VERSION=7.5 > > > make[1]: Entering directory `/home/ln/Desktop/hxt/src' > > > make install_local_hxt > > > make[2]: Entering directory `/home/ln/Desktop/hxt/src' > > > ghc -Wall -O2 -fglasgow-exts -ignore-package hxt -package-name hxt-7.5 > > > -package parsec -package HTTP -package tagsoup --make HXT.hs > > > [ 1 of 143] Compiling Text.XML.HXT.Validator.RE ( > > > Text/XML/HXT/Validator/RE.hs, Text/XML/HXT/Validator/RE.o ) > > > (.....) > > > [100 of 143] Compiling Text.XML.HXT.Parser.TagSoup ( > > > Text/XML/HXT/Parser/TagSoup.hs, Text/XML/HXT/Parser/TagSoup.o ) > > > > Text/XML/HXT/Parser/TagSoup.hs:305:21: Not in scope: `options' > > > make[2]: *** [libHShxt.a] Error 1 > > The alternative installation method with cabal leads to the same result. > > Using Ubuntu 8.04 Beta and GHC6.8. Maybe there are incompabilities with > newer versions of the dependencies? > > Would appreciate any help. > > Regards > Lukas You got it right. The issue is that in TagSoup.hs there is a line like 'parseTagsOptions (options { foo =...}'. That's invalid syntax AFAIK; more importantly, it's using functions from ndm's TagSoup library. TagSoup, with version 0.5, renamed the Options type to ParseOptions (we know the '(options {...' stuff is intended to be ParseOptions because parseTagsOptions handily comes with an explicit type signature). So if you simply edit the file such that 'options' -> 'ParseOptions', you should find it working for you. (I did this against the Darcs repo of HXT, and things compiled for me then on. I'm sending patches.) -- gwern 747 mailbomb the Alouette NSWT UKUSA Canine hitword fraud 1071 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080407/55a97620/attachment.bin From jackmarathon at gmail.com Mon Apr 7 22:51:05 2008 From: jackmarathon at gmail.com (Jackm139) Date: Mon Apr 7 22:46:43 2008 Subject: [Haskell-cafe] testing for same characters in lists of strings Message-ID: <16546167.post@talk.nabble.com> I'm new to Haskell, and I'm finding it is very different from any other language I have worked with. I have an assignment to make a program to test whether two lists use the same characters for each string. e.g. sameCharacter ["rock", "cab"] ["cork", "abc"] True My plan to tackle this was to use: nub to eliminate duplications, sort to put the characters in order, and map to put characters together.. and then somehow check to see if these characters are the same. My problem right now is just figuring out how to make a function that uses these three functions to give me a list of tuples. I know this is an awfully newbish question, and I'm not trying to get an answer to my homework problem. I just need some sort of working example syntax to off of. Any help would be appreciated! Thanks. -- View this message in context: http://www.nabble.com/testing-for-same-characters-in-lists-of-strings-tp16546167p16546167.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From k.kosciuszkiewicz+haskell at gmail.com Mon Apr 7 23:25:24 2008 From: k.kosciuszkiewicz+haskell at gmail.com (Krzysztof =?utf-8?Q?Ko=C5=9Bciuszkiewicz?=) Date: Mon Apr 7 23:21:29 2008 Subject: [Haskell-cafe] testing for same characters in lists of strings In-Reply-To: <16546167.post@talk.nabble.com> References: <16546167.post@talk.nabble.com> Message-ID: <20080408032524.GA22281@localdomain> On Mon, Apr 07, 2008 at 07:51:05PM -0700, Jackm139 wrote: > I have an assignment to make a program to test whether two lists use the > same characters for each string. > e.g. > > sameCharacter ["rock", "cab"] ["cork", "abc"] > True > > My plan to tackle this was to use: > nub to eliminate duplications, > sort to put the characters in order, > and map to put characters together.. and then somehow check to see if these > characters are the same. Probably you won't need to eliminate duplicates, sorting would be enough (although it depends on the assignment details). Comparing Chars (and Strings) can be accomplished with > (==) :: (Eq a) => a -> a -> Bool > My problem right now is just figuring out how to make a function that uses > these three functions to give me a list of tuples. To get list of tuples you can use > zip :: [a] -> [b] -> [(a, b)] or alternatively you can apply a binary function in a "pairwise way" using > zipWith :: (a -> b -> c) -> [a] -> [b] -> [c] as in > zipWith (+) [1, 2] [3, 4] > [4, 6] For chaining functions you can use function composition: > (.) :: (b -> c) -> (a -> b) -> a -> c as in > not :: Bool -> Bool > and :: [Bool] -> Bool > nand :: [Bool] -> Bool > nand = not . and or do without composition by specifying all arguments: > nand xs = not (and xs) Hope this helps, -- Krzysztof Ko?ciuszkiewicz Skype: dr.vee, Gadu: 111851, Jabber: kokr@jabberpl.org "Simplicity is the ultimate sophistication" -- Leonardo da Vinci From scook0 at gmail.com Mon Apr 7 23:33:28 2008 From: scook0 at gmail.com (Stuart Cook) Date: Mon Apr 7 23:29:06 2008 Subject: [Haskell-cafe] testing for same characters in lists of strings In-Reply-To: <16546167.post@talk.nabble.com> References: <16546167.post@talk.nabble.com> Message-ID: <49b351060804072033t4517eff3n759b9017e68bad1f@mail.gmail.com> On Tue, Apr 8, 2008 at 1:51 PM, Jackm139 wrote: > I have an assignment to make a program to test whether two lists use the > same characters for each string. > e.g. > > sameCharacter ["rock", "cab"] ["cork", "abc"] > True I would start with something smaller: try defining a function that will check if two *strings* use the same characters. It would look something like this: same :: String -> String -> Bool same xs ys = normalize xs == normalize ys normalize :: String -> String normalize xs = error "insert your implementation here" Define the "normalize" function so that it does whatever is necessary to make two strings with the same characters into the same string (using nub, sort, and/or whatever else is appropriate). Once you have the "same" function working, you can use it to define "sameCharacter". You might want to take a look at the functions "zip", "zipWith", "all", and "and", which can be found in the Prelude. Hopefully this will help you get started. Stuart From chak at cse.unsw.edu.au Mon Apr 7 23:56:07 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Apr 7 23:51:49 2008 Subject: [Haskell-cafe] translating from fundeps into type families In-Reply-To: References: Message-ID: <3BD29AEC-18E8-4A8C-B44F-3643D17A285B@cse.unsw.edu.au> Ganesh Sittampalam: > Can I have some advice on translating the attached Test1.hs into > type families? My attempt at doing so is in Test1a.hs, but firstly > it requires FlexibleInstances where Test1.hs didn't, and secondly it > fails because it can't infer the instance for Bar (Either Int Int) > whereas the fundeps version had no problems there. You need to write the instance as instance (b ~ TheFoo a, Foo a) => Bar (Either a b) where bar (Left a) = foo' a bar (Right b) = foo' (foo b :: a) Generally, you can't have type synonym families in instance heads. GHC should have complained about this despite your use of FlexibleInstances. (I'll fix that.) Unfortunately, the above will currently only go through if you specify UndecidableInstances. Nothing about it is undecidable, though, so the flag should not be required. Part of the trouble here is that, although we just completed a formal statement about the decidability of type checking for type families *without* taking context simplification into account , we are still lacking a formal statement about type checking for type families *with* context simplification. My conjecture at the moment is that equalities of the form tv ~ F tv1 .. tvn where tv and tvi are distinct type variables should always be fine in class instance contexts and correspond to what is permitted for FDs. (However, previous experience with FDs and TFs clearly shows that any statements about decidability and completeness in this space are to be regarded with caution until they have been formalised rigorously.) I'll create a trac ticket with your example. Cheers, Manuel From westondan at imageworks.com Tue Apr 8 00:10:58 2008 From: westondan at imageworks.com (Dan Weston) Date: Tue Apr 8 00:06:42 2008 Subject: [Haskell-cafe] testing for same characters in lists of strings In-Reply-To: <16546167.post@talk.nabble.com> References: <16546167.post@talk.nabble.com> Message-ID: <47FAF052.9050300@imageworks.com> I don't know how to calibrate my response to what you are really asking for. Depending on how "new" you are, maybe all you want is just "working syntax" to get you started. Here is a structurally similar problem, if it helps. (And if you are more advanced, try the extra credit!) Find the "average" of a string, i.e. the Char with the average ascii value of the string: e.g. (avgChar "ac") == 'b' and (avgChar "ffff") == 'f'. Things to watch out for: 1) What if the string is empty? [I will error out] 2) What if the average is not an integer? [Just use div to truncate] You should also provide guarantees to the caller in your documentation, if you can (and ideally, automated checks for them): 3) If the string is nonempty and contains only lowercase letters, is the average always a lowercase letter? 4) If I permute the string (e.g. sort it), does it give the same average? [Extra credit: can you prove 3 and 4 are true or false?] Here is one solution to the above problem. Save the code below to a file Avg.hs, then compile: ghc --make Avg When you run Avg, you should get 'j', the average of "hello". ------------------------------------------------------------------- main = putStrLn . show $ avg "hello" -- Should print 'j' -- How to convert a Char to its ascii value: charToAscii :: Char -> Int charToAscii c = fromEnum c -- Convert each element of the string: stringToAsciiList :: String -> [Int] stringToAsciiList s = map charToAscii s -- Get the average of a list of ints: avgIntListValue :: [Int] -> Int avgIntListValue [] = error "Dummy! I can't handle an empty list" avgIntListValue xs = sum xs `div` length xs -- Now convert the ascii back to a Char: asciiToChar :: Int -> Char asciiToChar i = toEnum i -- Now put it all together. Remember that the composition operator (.) -- works backwards: given two functions f :: a -> b and g :: b -> c, -- then g . f :: a -> c avgChar :: String -> Char avgChar s = (asciiToChar . avgIntListValue . stringToAsciiList) s -- NOTE: I could have left the argument off and defined the functions -- in a "point-free" style. For example, you can also write: avgChar' = asciiToChar . avgIntListValue . stringToAsciiList ------------------------------------------------------------------- Others have provided suggestions more specific to your particular assignment. Dan Jackm139 wrote: > I'm new to Haskell, and I'm finding it is very different from any other > language I have worked with. > > I have an assignment to make a program to test whether two lists use the > same characters for each string. > e.g. > > sameCharacter ["rock", "cab"] ["cork", "abc"] > True > > My plan to tackle this was to use: > nub to eliminate duplications, > sort to put the characters in order, > and map to put characters together.. and then somehow check to see if these > characters are the same. > > My problem right now is just figuring out how to make a function that uses > these three functions to give me a list of tuples. > > I know this is an awfully newbish question, and I'm not trying to get an > answer to my homework problem. > I just need some sort of working example syntax to off of. > > Any help would be appreciated! > Thanks. > > From chak at cse.unsw.edu.au Tue Apr 8 00:48:28 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Apr 8 00:44:20 2008 Subject: [Haskell-cafe] Re: type families and type signatures In-Reply-To: <47FA989C.7000002@cs.pdx.edu> References: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> <47FA30A7.4000504@cs.pdx.edu> <47FA989C.7000002@cs.pdx.edu> Message-ID: <4C824B5D-1FC1-4ABE-AC0A-E5BCCD33E38F@cse.unsw.edu.au> Hi Mark, > I don't know if you have defined/studied corresponding notions of > ambiguity/coherence in your framework. Instead, I was referring to > what Manuel described as "the equivalent problem using FDs": > > class IdC a b | a -> b > instance IdC Int Int > > bar :: IdC a b => b -> b > bar = id > > bar' :: IdC a b => b -> b > bar' = bar > > In this program, both bar and bar' have ambiguous types (the > variable 'a' in each of the contexts is not uniquely determined > by the variable 'b' appearing on the right), and so *neither* > one of these definitions is valid. This behavior differs from > what has been described for your approach, so perhaps Manuel's > example isn't really "equivalent" after all. > > Technically, one could ignore the ambiguous type signature for > bar, because the *principal* type of bar (as opposed to the > *declared type*) is not ambiguous. However, in practice, there > is little reason to allow the definition of a function with an > ambiguous type because such functions cannot be used in practice: > the ambiguity that is introduced in the type of bar will propagate > to any other function that calls it, either directly or indirectly. > For this reason, it makes sense to report the ambiguity at the > point where bar is defined, instead of deferring that error to > places where it is used, like the definition of bar'. (The latter > is what I mean by "delayed" ambiguity checking.) You are of course spot on, but this is a difference in how GHC handles functional dependencies compared to Hugs. Hugs does reject bar as being ambiguous, but GHC does not! In other words, it also uses "delayed" ambiguity checking for the FD version, and so raises an error only when seeing bar'. The implementation of type families just mirrors GHC's behaviour for FDs. (This is why I presented the FD example, but I should have mentioned that the equivalence is restricted to GHC.) The rational for the decision to use delayed ambiguity checking in GHC is that it is, in general, not possible to spot and report all ambiguous signatures and *only* those. So, there are three possible choices: (1) Reject all signatures that *may* be ambiguous (and hence reject some perfectly good programs). (2) Reject all signatures that are *guaranteed* to be ambiguous (and accept some programs with functions that can never be applied). (3) Don't check for ambiguity (or "delayed" ambiguity checking). As you wrote, all three choices are perfectly safe - we will never accept a type-incorrect program, but they vary in terms of the range of accepted programs and quality of error messages. Please correct me if I am wrong, but as I understand the situation, Hugs uses Choice (1) and GHC uses Choice (3). As an example, consider this contrived program: > class F a b | a -> b where > f1 :: a -> b > f2 :: b -> a > > instance F Int Int where > f1 = id > f2 = id > > class G x a b where > g :: x -> a -> b > > instance F a b => G Bool a b where > g c v = f1 v > > instance F b a => G Int a b where > g c v = f2 v > > foo1 :: (G Int a b) => a -> a > foo1 v = v > > foo2 :: (G Bool a b) => a -> a > foo2 v = v > > bar = foo2 (42::Int) Here foo1 is actually ambiguous, but foo2 is fine due to the FD in the instance context of the (G Bool a b) instance. GHC accepts this program (not checking for ambiguity) and allows you to evaluate bar. In contrast, Hugs rejects both the signature of foo1 and of foo2, arguably being overly restrictive with foo2. Cheers, Manuel From chak at cse.unsw.edu.au Tue Apr 8 01:01:05 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Apr 8 00:56:46 2008 Subject: [Haskell-cafe] Re: type families and type signatures In-Reply-To: References: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> Message-ID: apfelmus: > Manuel M T Chakravarty wrote: >> Ganesh Sittampalam: >> Let's alpha-rename the signatures and use explicit foralls for >> clarity: >> foo :: forall a. Id a -> Id a >> foo' :: forall b. Id b -> Id b >> GHC will try to match (Id a) against (Id b). As Id is a type >> synonym family, it would *not* be valid to derive (a ~ b) from >> this. After all, Id could have the same result for different >> argument types. (That's not the case for your one instance, but >> maybe in another module, there are additional instances for Id, >> where that is the case.) > > While in general (Id a ~ Id b) -/-> (a ~ b) , parametricity makes > it "true" in the case of foo . For instance, let Id a ~ Int . > Then, the signature specializes to foo :: Int -> Int . But due to > parametricity, foo does not care at all what a is and will be > the very same function for every a with Id a ~ Int . In other > words, it's as if the type variable a is not in scope in the > definition of foo . Be careful, Id is a type-indexed type family and *not* a parametric type. Parametricity does not apply. For more details about the situation with GADTs alone, see Foundations for Structured Programming with GADTs. Patricia Johann and Neil Ghani. Proceedings, Principles of Programming Languages 2008 (POPL'08). > In full System F , neither definition would be a problem since the > type a is an explicit parameter. You can't generally translate type family/GADT programs into System F. We proposed an extension of System F called System F_C(X); see our TLDI'07 paper: http://www.cse.unsw.edu.au/~chak/papers/SCPD07.html Manuel From lemming at henning-thielemann.de Tue Apr 8 01:33:36 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Apr 8 01:27:58 2008 Subject: [Haskell-cafe] testing for same characters in lists of strings In-Reply-To: <16546167.post@talk.nabble.com> References: <16546167.post@talk.nabble.com> Message-ID: On Mon, 7 Apr 2008, Jackm139 wrote: > > I'm new to Haskell, and I'm finding it is very different from any other > language I have worked with. > > I have an assignment to make a program to test whether two lists use the > same characters for each string. > e.g. > > sameCharacter ["rock", "cab"] ["cork", "abc"] > True > > My plan to tackle this was to use: > nub to eliminate duplications, > sort to put the characters in order, > and map to put characters together.. and then somehow check to see if these > characters are the same. How about converting the strings to Set Char and comparing the resulting lists? From chak at cse.unsw.edu.au Tue Apr 8 03:15:18 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Apr 8 03:11:00 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: References: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> Message-ID: Ganesh Sittampalam: > On Mon, 7 Apr 2008, Manuel M T Chakravarty wrote: > >> Ganesh Sittampalam: >>> The following program doesn't compile in latest GHC HEAD, although >>> it does if I remove the signature on foo'. Is this expected? >> >> Yes, unfortunately, this is expected, although it is very >> unintuitive. This is for the following reason. >> >> Let's alpha-rename the signatures and use explicit foralls for >> clarity: >> >> foo :: forall a. Id a -> Id a >> foo' :: forall b. Id b -> Id b >> >> GHC will try to match (Id a) against (Id b). As Id is a type >> synonym family, it would *not* be valid to derive (a ~ b) from >> this. After all, Id could have the same result for different >> argument types. (That's not the case for your one instance, but >> maybe in another module, there are additional instances for Id, >> where that is the case.) > > Can't it derive (Id a ~ Id b), though? That's what it does derive as a proof obligation and finds it can't prove. The error message you are seeing is GHC's way of saying, I cannot assert that (Id a ~ Id b) holds. >> Now, as GHC cannot show that a and b are the same, it can also not >> show that (Id a) and (Id b) are the same. It does look odd when >> you use the same type variable in both signatures, especially as >> Haskell allows you to leave out the quantifiers, but the 'a' in the >> signature of foo and the 'a' in the signatures of foo' are not the >> same thing; they just happen to have the same name. > > Sure, but forall a . Id a ~ Id a is the same thing as forall b . Id > b ~ Id b. > > Thanks for the explanation, anyway. I'll need to have another think > about what I'm actually trying to do (which roughly speaking is to > specialise a general function over type families using a signature > which I think I need for other reasons). > > Generally speaking, is there any way to give a signature to foo'? Sorry, but in the heat of explaining what GHC does, I missed the probably crucial point. Your function foo is useless, as is foo'. Not only can't you rename foo (to foo'), but you generally can't use it. It's signature is ambiguous. Try evaluating (foo (1::Int)). The problem is related to the infamous (show . read). Manuel From ganesh.sittampalam at credit-suisse.com Tue Apr 8 03:23:57 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Apr 8 03:19:59 2008 Subject: [Haskell-cafe] type families and type signatures Message-ID: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> Manuel Chakravarty wrote: >Ganesh Sittampalam: >> On Mon, 7 Apr 2008, Manuel M T Chakravarty wrote: >> >>> Ganesh Sittampalam: >>>> The following program doesn't compile in latest GHC HEAD, although >>>> it does if I remove the signature on foo'. Is this expected? >>> >>> Yes, unfortunately, this is expected, although it is very >>> unintuitive. This is for the following reason. >>> >>> Let's alpha-rename the signatures and use explicit foralls for >>> clarity: >>> >>> foo :: forall a. Id a -> Id a >>> foo' :: forall b. Id b -> Id b >>> >>> GHC will try to match (Id a) against (Id b). As Id is a type synonym >>> family, it would *not* be valid to derive (a ~ b) from this. After >>> all, Id could have the same result for different argument types. >>> (That's not the case for your one instance, but maybe in another >>> module, there are additional instances for Id, where that is the >>> case.) >> >> Can't it derive (Id a ~ Id b), though? > That's what it does derive as a proof obligation and finds it can't prove. > The error message you are seeing is GHC's way of saying, I cannot assert that > (Id a ~ Id b) holds. No, I meant can't it derive that equality when matching (Id a) against (Id b)? As you say, it can't derive (a ~ b) at that point, but (Id a ~ Id b) is known, surely? > > Generally speaking, is there any way to give a signature to foo'? > Sorry, but in the heat of explaining what GHC does, I missed the > probably crucial point. Your function foo is useless, as is foo'. > Not only can't you rename foo (to foo'), but you generally can't use > it. It's signature is ambiguous. Try evaluating (foo (1::Int)). The > problem is related to the infamous (show . read). My real code is somewhat analogous to (foo :: (Id Int -> Id Int)) (1::Int). Isn't that unambiguous in the same way as (show.read) is if I give show or read a signature? Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From vigalchin at gmail.com Tue Apr 8 03:32:00 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Tue Apr 8 03:27:39 2008 Subject: [Haskell-cafe] Quick check? Message-ID: <5ae4f2ba0804080032i43b2c4c5gbd175ea557fab431@mail.gmail.com> Hello, What are some examples of libraries in HackageDB that use either Quick Check (pure side) or Monad testing? Is there a way to use "darcs" to answer my question? Thanks, vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080408/10f473e6/attachment.htm From Tom.Schrijvers at cs.kuleuven.be Tue Apr 8 03:35:33 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Tue Apr 8 03:32:33 2008 Subject: [Haskell-cafe] Re: type families and type signatures In-Reply-To: <47FA989C.7000002@cs.pdx.edu> References: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> <47FA30A7.4000504@cs.pdx.edu> <47FA989C.7000002@cs.pdx.edu> Message-ID: > Hi Tom, > > It seems we are thinking of different things. I was referring to > the characterization of a type of the form P => t as being "ambiguous" > if there is a type variable in P that is not determined by the > variables in t; this condition is used in Haskell to establish > coherence (i.e., to show that a program has a well-defined semantics). [...] > Technically, one could ignore the ambiguous type signature for > bar, because the *principal* type of bar (as opposed to the > *declared type*) is not ambiguous. However, in practice, there > is little reason to allow the definition of a function with an > ambiguous type because such functions cannot be used in practice: > the ambiguity that is introduced in the type of bar will propagate > to any other function that calls it, either directly or indirectly. > For this reason, it makes sense to report the ambiguity at the > point where bar is defined, instead of deferring that error to > places where it is used, like the definition of bar'. (The latter > is what I mean by "delayed" ambiguity checking.) Thanks for explaining the ambiguity issue, Mark. I wasn't thinking about that. We have thought about ambiguity. See Section 7.3 in our paper http://www.cs.kuleuven.be/~toms/Research/papers/draft_type_functions_2008.pdf Note that neither Definition 3 nor Definition 4 demands that all unification variables are substituted with ground types during type checking. So we do allow for a form of ambiguity: when any type is valid (this has no impact on the semantics). Consider the initial program type family F a foo :: F a -> F a foo = id You propose to reject function Foo because it cannot be used unambiguously. We propose to accept foo, because the program could be extended with type instance F x = Int and, for instance, this would be valid: foo2 :: F Char -> F Bool foo2 = foo If you look at the level of the equality constraints: (F Char -> F Bool) ~ (F alpha -> F alpha) we normalise first wrt the instance F x = Int, and get (Int -> Int) ~ (Int -> Int) which is trivially true. In this process we do not substitute alpha. So alpha is ambiguous, but any solution will do and not have an impact on program execution. GHC already did this before type functions, for this kind of ambiguity, it substitutes alpha for an arbitrary type. That's not unreasonable, is it? Cheers, Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From ndmitchell at gmail.com Tue Apr 8 04:00:41 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Apr 8 03:56:19 2008 Subject: [Haskell-cafe] Problem building HXT In-Reply-To: <20080408022540.GA742043@localhost> References: <47FA6522.1050007@student.gu.se> <20080408022540.GA742043@localhost> Message-ID: <404396ef0804080100v34909a40v597976fca4697a45@mail.gmail.com> Hi > You got it right. The issue is that in TagSoup.hs there is a line like 'parseTagsOptions (options { foo =...}'. That's invalid syntax AFAIK; It's just record syntax, which is very handy. > more importantly, it's using functions from ndm's TagSoup library. TagSoup, with version 0.5, renamed the Options type to ParseOptions (we know the '(options {...' stuff is intended to be ParseOptions because parseTagsOptions handily comes with an explicit type signature). > I thought this might be version skew. The released TagSoup on Hackage should still have options, not parseOptions - which is only in the darcs version. If you install tagsoup from Hackage you should be fine. Thanks Neil From ketil at malde.org Tue Apr 8 04:15:07 2008 From: ketil at malde.org (Ketil Malde) Date: Tue Apr 8 04:10:38 2008 Subject: [Haskell-cafe] Quick check? In-Reply-To: <5ae4f2ba0804080032i43b2c4c5gbd175ea557fab431@mail.gmail.com> (Vasili Galchin's message of "Tue\, 8 Apr 2008 02\:32\:00 -0500") References: <5ae4f2ba0804080032i43b2c4c5gbd175ea557fab431@mail.gmail.com> Message-ID: <87prt07ofo.fsf@nmd9999.imr.no> "Galchin, Vasili" writes: > What are some examples of libraries in HackageDB that use either Quick > Check (pure side) or Monad testing? Is there a way to use "darcs" to answer my > question? I used the ByteString library as a guideline when developing testing (and to a lesser extent benchmarking) functionality based on QuickCheck. ByteString lives at: darcs get http://darcs.haskell.org/bytestring or http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-0.9.0.4 My stuff is at: darcs get http://malde.org/~ketil/biohaskell/biolib or http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bio-0.3.3.2 My time-measuring version of QuickCheck can be found in Test/QuickBench.hs, and the tests are driven from Bio/Test.hs and Bio/Bench.hs. Use 'make test' or 'make bench' to run them. -k -- If I haven't seen further, it is by standing in the footprints of giants From haberg at math.su.se Tue Apr 8 04:17:38 2008 From: haberg at math.su.se (Hans Aberg) Date: Tue Apr 8 04:13:21 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <655352789.20080408023012@gmail.com> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> <0F57663B-B445-4057-ABBA-D093A81904C5@ece.cmu.edu> <655352789.20080408023012@gmail.com> Message-ID: <3410B141-1684-4170-B1C4-BD5FE4F798B2@math.su.se> On 8 Apr 2008, at 00:30, Bulat Ziganshin wrote: >> At least Hugs complains if one does not indent "deriving ...", but I >> do not know what the standard says. If is required, then it can be >> changed. > > deriving is a part of data clause and indentation just allows us to > continue clause from prev. line. if not indented, deriving will be > parsed as separate clause (and btw such clause, "standalone deriving" > was added to ghc 6.8) So it seems that if one uses the word "instance" instead of "deriving", then the compiler can immediately tell when this word appears whether it is a part if the "data" clause, or the start of a new "instance" clause. So it can probably be changed, getting rid of "deriving" which I think is not used elsewhere. It will break a lot of code, but it is easy to change, and also easy to make a compatibility mode. Hans From pkeir at dcs.gla.ac.uk Tue Apr 8 04:46:49 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Tue Apr 8 04:42:27 2008 Subject: [Haskell-cafe] Parsec expressions with alphaNum operators In-Reply-To: References: <3CDFB8AFEA98E34CB599475AB11589C80E8A43@EX2.ad.dcs.gla.ac.uk> Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80E8A52@EX2.ad.dcs.gla.ac.uk> Thanks Chris, When I looked at the Fortran alphaNum operators (.and. .or. etc.) I had hoped that supplying Parsec's "opStart" with a dot would have been hitting the nail on the head. Oh well. I have noticed something interesting though. If I simply omit the "a" from "opLetter", the problem is gone. In fact, leaving "opStart", "opLetter", and "reservedOpNames" all empty works fine too. Perhaps I should aim to leave aside the "Language" part of Parsec altogether. Paul From bulat.ziganshin at gmail.com Tue Apr 8 04:47:39 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Apr 8 04:46:47 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <3410B141-1684-4170-B1C4-BD5FE4F798B2@math.su.se> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> <0F57663B-B445-4057-ABBA-D093A81904C5@ece.cmu.edu> <655352789.20080408023012@gmail.com> <3410B141-1684-4170-B1C4-BD5FE4F798B2@math.su.se> Message-ID: <11316405.20080408124739@gmail.com> Hello Hans, Tuesday, April 8, 2008, 12:17:38 PM, you wrote: > "deriving" which I think is not used elsewhere. It will break a lot > of code, but it is easy to change, and also easy to make a > compatibility mode. it's also easy to replace all the books, update all code repositories and reteach all the programmers if you ready to pay for it all :D -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From martin.sulzmann at gmail.com Tue Apr 8 04:51:31 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Tue Apr 8 04:47:12 2008 Subject: [Haskell-cafe] Re: type families and type signatures In-Reply-To: References: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> <47FA30A7.4000504@cs.pdx.edu> <47FA989C.7000002@cs.pdx.edu> Message-ID: <47FB3213.8000102@gmail.com> The point is that Mark proposes a *pessimistic* ambiguity check whereas Tom (as well as GHC) favors an *optimistic* ambiguity check. By pessimistic I mean that we immediately reject a program/type if there's a potential unambiguity. For example, class Foo a b forall a b. Foo a b => b -> b is potentially ambiguous assuming we encounter instance Foo Int Char instance Foo Bool Char But such instances might never arise. See Tom's example below which applies an optimistic ambiguity check. In the extreme case, the optimistic ambiguity check only checks for ambiguity when calling the ground top-level function main. At this point (latest), we must provide (unambiguously) evidence for type classes and type equations. In summary: - The pessimistic ambiguity check is more in line with Haskell's open world view (of type classes and type families/functions being open/extensible). Anything can happen in the future (we might add an new type instances). So let's assume the worst and immediately report any potential ambiguity. - The optimistic ambiguity check takes into account the set of available instance. Depending on the set of instances there may not be any ambiguity after all. Both strategies are backed up by theoretical results. See the Coherence Theorems in Mark's thesis and "A Theory of Overloading" (I'm happy to provide more concrete pointers if necessary). Martin Tom Schrijvers wrote: >> Hi Tom, >> >> It seems we are thinking of different things. I was referring to >> the characterization of a type of the form P => t as being "ambiguous" >> if there is a type variable in P that is not determined by the >> variables in t; this condition is used in Haskell to establish >> coherence (i.e., to show that a program has a well-defined semantics). > > [...] > >> Technically, one could ignore the ambiguous type signature for >> bar, because the *principal* type of bar (as opposed to the >> *declared type*) is not ambiguous. However, in practice, there >> is little reason to allow the definition of a function with an >> ambiguous type because such functions cannot be used in practice: >> the ambiguity that is introduced in the type of bar will propagate >> to any other function that calls it, either directly or indirectly. >> For this reason, it makes sense to report the ambiguity at the >> point where bar is defined, instead of deferring that error to >> places where it is used, like the definition of bar'. (The latter >> is what I mean by "delayed" ambiguity checking.) > > Thanks for explaining the ambiguity issue, Mark. I wasn't thinking > about that. We have thought about ambiguity. See Section 7.3 in our paper > > http://www.cs.kuleuven.be/~toms/Research/papers/draft_type_functions_2008.pdf > > > Note that neither Definition 3 nor Definition 4 demands that all > unification variables are substituted with ground types during type > checking. So we do allow for a form of ambiguity: when any type is > valid (this has no impact on the semantics). Consider the initial program > > type family F a > > foo :: F a -> F a > foo = id > > You propose to reject function Foo because it cannot be used > unambiguously. We propose to accept foo, because the program could be > extended with > > type instance F x = Int > > and, for instance, this would be valid: > > foo2 :: F Char -> F Bool > foo2 = foo > > If you look at the level of the equality constraints: > > (F Char -> F Bool) ~ (F alpha -> F alpha) > > we normalise first wrt the instance F x = Int, and get > > (Int -> Int) ~ (Int -> Int) > > which is trivially true. In this process we do not substitute alpha. > So alpha is ambiguous, but any solution will do and not have an impact > on program execution. GHC already did this before type functions, for > this kind of ambiguity, it substitutes alpha for an arbitrary type. > That's not unreasonable, is it? > > Cheers, > > Tom > > -- > Tom Schrijvers > > Department of Computer Science > K.U. Leuven > Celestijnenlaan 200A > B-3001 Heverlee > Belgium > > tel: +32 16 327544 > e-mail: tom.schrijvers@cs.kuleuven.be > url: http://www.cs.kuleuven.be/~toms/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From haberg at math.su.se Tue Apr 8 04:53:58 2008 From: haberg at math.su.se (Hans Aberg) Date: Tue Apr 8 04:49:39 2008 Subject: [Haskell-cafe] instance Monad m => Functor m Message-ID: <93A90667-13CD-4E88-B39B-BD878D24C0F5@math.su.se> Using 'hugs -98', I noticed it accepts: instance Monad m => Functor m where fmap f x = x >>= return.f Has this been considered (say) as a part of the upcoming Haskell Prime? Hans Aberg From haberg at math.su.se Tue Apr 8 05:02:26 2008 From: haberg at math.su.se (Hans Aberg) Date: Tue Apr 8 04:58:06 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <11316405.20080408124739@gmail.com> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> <0F57663B-B445-4057-ABBA-D093A81904C5@ece.cmu.edu> <655352789.20080408023012@gmail.com> <3410B141-1684-4170-B1C4-BD5FE4F798B2@math.su.se> <11316405.20080408124739@gmail.com> Message-ID: On 8 Apr 2008, at 10:47, Bulat Ziganshin wrote: >> "deriving" which I think is not used elsewhere. It will break a lot >> of code, but it is easy to change, and also easy to make a >> compatibility mode. > > it's also easy to replace all the books, update all code repositories > and reteach all the programmers if you ready to pay for it all :D I guess it is only the code breaking part that is any concern of standard. It is really up to the companies to pay for courses retraining programmers for the word change. As for the books, it is a good selling opportunity. Hans From chaddai.fouche at gmail.com Tue Apr 8 05:29:44 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Tue Apr 8 05:25:22 2008 Subject: [Haskell-cafe] translating from fundeps into type families In-Reply-To: <3BD29AEC-18E8-4A8C-B44F-3643D17A285B@cse.unsw.edu.au> References: <3BD29AEC-18E8-4A8C-B44F-3643D17A285B@cse.unsw.edu.au> Message-ID: 2008/4/8, Manuel M T Chakravarty : > You need to write the instance as > > instance (b ~ TheFoo a, Foo a) => Bar (Either a b) where > bar (Left a) = foo' a > bar (Right b) = foo' (foo b :: a) > If you do that, the program compile, but res still raise a panic in GHC6.8.2 . Before you sent your solution, I also tried to do class (TheFoo a ~ b) => Foo a b where ... instance (Foo a b) => Bar (Either a b) where ... But it didn't compile, it seems to me both versions should have the same behaviour ? -- Jeda? From haskell at orangesquash.org.uk Tue Apr 8 05:43:16 2008 From: haskell at orangesquash.org.uk (Iain Lane) Date: Tue Apr 8 05:39:07 2008 Subject: [Haskell-cafe] announcing the darcs 2.0.0 release In-Reply-To: <20080407172225.GB16717@darcs.net> References: <20080407172225.GB16717@darcs.net> Message-ID: <20080408093908.GA16155@cripps.orangesquash.org.uk> On Mon, Apr 07, 2008 at 10:22:25AM -0700, David Roundy wrote: > Hello darcs users, > > I am pleased to announce the release of darcs 2.0.0! It's been a long time > coming, and hopefully you will be pleased with the result. Notable new > features include (in no particular order): > Hello, Congrats for getting it out! I'd just like to let everyone know that I have made packages for Ubuntu Gutsy and Hardy available from my Launchpad PPA (personal package archive), available from [1]. These releases are intended only as a band-aid for the impatient until the official packages come out, or until I have time to talk to the appropriate people; I haven't tested them thoroughly - all the usual disclaimers apply ;). That said, they *do* appear to be working fine from my (very) limited testing. To install, add the lines given at [1] that correspond to your release to your /etc/apt/sources.list file, then perform an `apt-get update' and `apt-get dist-upgrade' or `apt-get install darcs' as appropriate. It appears that the same package builds on Debian unstable (sid), but I don't have a system available to test it on. Please let me know of any problems, and I will endeavour to fix them. I am on IRC as Laney. Thanks all, Iain [1] https://launchpad.net/~laney/+archive From wss at Cs.Nott.AC.UK Tue Apr 8 06:56:26 2008 From: wss at Cs.Nott.AC.UK (Wouter Swierstra) Date: Tue Apr 8 06:57:35 2008 Subject: [Haskell-cafe] ANN: The Monad.Reader Issue 10 Message-ID: I am pleased to announce that a new issue of The Monad.Reader is now available: http://www.haskell.org/haskellwiki/The_Monad.Reader Issue 10 consists of the following two articles: * Bernie Pope Step inside the GHCi debugger * Matthew Naylor Evaluating Haskell in Haskell The Monad.Reader is a quarterly magazine about functional programming. It is less formal than a journal, but somehow more enduring than a wiki page or blog post. If you'd like to write something for the next issue of The Monad.Reader, please get in touch. I haven't fixed the deadline for the next issue just yet. I hope to send out an official call for copy fairly soon. Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From uwe at fh-wedel.de Tue Apr 8 07:03:46 2008 From: uwe at fh-wedel.de (Uwe Schmidt) Date: Tue Apr 8 06:58:38 2008 Subject: [Haskell-cafe] Problem building HXT In-Reply-To: <47FA6522.1050007@student.gu.se> References: <47FA6522.1050007@student.gu.se> Message-ID: <200804081303.46511.uwe@fh-wedel.de> ln wrote: > I would like to try HXT, but I can't manage to build it. I resolved all > > the dependencies, but I get the following error: > > > ln@igemyvuci:~/Desktop/hxt$ make all > > > make -C src all VERSION=7.5 > > > make[1]: Entering directory `/home/ln/Desktop/hxt/src' > > > make install_local_hxt > > > make[2]: Entering directory `/home/ln/Desktop/hxt/src' > > > ghc -Wall -O2 -fglasgow-exts -ignore-package hxt -package-name hxt-7.5 > > > -package parsec -package HTTP -package tagsoup --make HXT.hs > > > [ 1 of 143] Compiling Text.XML.HXT.Validator.RE ( > > > Text/XML/HXT/Validator/RE.hs, Text/XML/HXT/Validator/RE.o ) > > > (.....) > > > [100 of 143] Compiling Text.XML.HXT.Parser.TagSoup ( > > > Text/XML/HXT/Parser/TagSoup.hs, Text/XML/HXT/Parser/TagSoup.o ) > > > > > > Text/XML/HXT/Parser/TagSoup.hs:305:21: Not in scope: `options' > > > make[2]: *** [libHShxt.a] Error 1 > > The alternative installation method with cabal leads to the same result. > > Using Ubuntu 8.04 Beta and GHC6.8. Maybe there are incompabilities with > newer versions of the dependencies? please use tagsoup version 0.4 from hackage. That's the version which works with hxt-7.5. We will specify the precise version in the cabal file of the next hxt release. Uwe From uwe at fh-wedel.de Tue Apr 8 07:40:30 2008 From: uwe at fh-wedel.de (Uwe Schmidt) Date: Tue Apr 8 07:35:20 2008 Subject: [Haskell-cafe] Re: HXT 7.4/7.5 leaking TCP connections In-Reply-To: <200804082300.52246.dm.maillists@gmail.com> References: <200804082300.52246.dm.maillists@gmail.com> Message-ID: <200804081340.30623.uwe@fh-wedel.de> Daniel McAllansmith wrote: > I'm having some problems with connections leaking when using 7.4. ?I've > just checked and it happens with 7.5 off of hackage as well. > > It appears that readDocument doesn't close the connection when using the > haskell http library, it works ok when curl is used though. > > Following is a program which demonstrates the problem. ?/tmp/list.txt just > has the name of files available from my local webserver, more than 1024 > files is enough to exhaust my open file limit. > > I think the garbage collector does collect the connections, but they don't > end up fully closed... that's another issue I'm planning on looking at. > > If you need any more information please ask. ?I may get a chance to try and > write a patch but using curl is a work around while I'm busy. > .... this is a known problem with HTTP package (version 3001.0.4). Paul Brown has described this somewere in his blog. (http://mult.ifario.us/t/haskell), but my firefox only shows an incomplete page of this blog, the solution is missing. Paul promissed in his blog to send a patch to Bj?rn Bringert. Here is the solution: edit the close function in HTTP/TCP.hs as follows: ---------------------------------------------------------------- close ref = do { c <- readIORef (getRef ref) ; closeConn c ; writeIORef (getRef ref) ConnClosed } where -- Be kind to peer & close gracefully. closeConn (ConnClosed) = return () closeConn (MkConn sk addr [] _) = mapM_ (flip Exception.catch $ \_ -> return ()) [ shutdown sk ShutdownSend , suck ref , shutdown sk ShutdownReceive , sClose sk ] suck :: Connection -> IO () suck cn = readLine cn >>= either (\_ -> return ()) -- catch errors & ignore (\x -> if null x then return () else suck cn) --------------------------------------------------------------------- I hope this will help. Cheers Uwe P.S. to Bj?rn: It would be nice, if you could include this change into the HTTP module and upload a new version to hackage. From marco-oweber at gmx.de Tue Apr 8 09:05:26 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Tue Apr 8 09:01:07 2008 Subject: [Haskell-cafe] Haskell IDE: Someone else interested in enhancing Shim ? / How to contact author Benedikt Schmidt ? Message-ID: <20080408130526.GC8116@gmx.de> Hi, I've added some features to shim. You can get my patches here: http://mawercer.de/~publicrepos/shim/ The Vim interface now supports :GrepScope regex Which greps the whole scope of all used packages by regex. Very useful to find all functions taking/ returning some type etc :ModulesExporting identifier returns all modules exporting identifiers. Can be used to add imports more automatically. Completion: camelCaseMatching Use pSL to get putStrLn If you want to join and add features contact me via irc or email. I'd like to talk to the author about my patches. I've send him two mails but I haven't received any response yet. Sincerly Marc Weber From prstanley at ntlworld.com Tue Apr 8 09:26:40 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Tue Apr 8 09:22:07 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <11316405.20080408124739@gmail.com> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> <0F57663B-B445-4057-ABBA-D093A81904C5@ece.cmu.edu> <655352789.20080408023012@gmail.com> <3410B141-1684-4170-B1C4-BD5FE4F798B2@math.su.se> <11316405.20080408124739@gmail.com> Message-ID: <7.0.1.0.0.20080408141630.01d09040@ntlworld.com> >Hello Hans, > >Tuesday, April 8, 2008, 12:17:38 PM, you wrote: > > > "deriving" which I think is not used elsewhere. It will break a lot > > of code, but it is easy to change, and also easy to make a > > compatibility mode. > >it's also easy to replace all the books, update all code repositories >and reteach all the programmers if you ready to pay for it all :D I'm sure you could introduce change gradually without too much pain. I personally think "deriving" is a descriptive term, now that I understand its role better. I suppose you could consider "specialize" or "instanciate" but both those terms are very closely associated with OO and deriving an instance of a class with a type isn't quite like instantiation or even specialisation. We want a single word which is equivalent to "derives from". Deriving by itself can seem a bit ambiguous at first. Cheers Paul From simonpj at microsoft.com Tue Apr 8 09:39:06 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Apr 8 09:34:44 2008 Subject: [Haskell-cafe] Re: Type Families: infinite compile process? In-Reply-To: <7b92c2840804071446i3dd701adud562dd09fcd673b7@mail.gmail.com> References: <7b92c2840804071430p7bf0bff3vcebfaf38211b3fb6@mail.gmail.com> <7b92c2840804071446i3dd701adud562dd09fcd673b7@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE39A267F@EA-EXMSG-C334.europe.corp.microsoft.com> You might find it helpful to read our new paper: Type checking with open type functions http://research.microsoft.com/%7Esimonpj/papers/assoc-types/index.htm From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Hugo Pacheco Sent: 07 April 2008 22:47 To: Haskell Cafe Subject: [Haskell-cafe] Re: Type Families: infinite compile process? The problem is that the representation probably does not reduce to a normal form. Say, for the case type instance F (Nest a) x = Either() (a,F a x) fnn :: F (Nest a) (Nest a) fnn = Left () it compiles ok. But why can't the representation be infinite, like any other infinite data type? Cheers, hugo On Mon, Apr 7, 2008 at 10:30 PM, Hugo Pacheco > wrote: Hi guys, I have been experimenting some weird stuff (risky, yes I know) but the behaviour was certainly not the one I expected: {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} module Nest where data Nest a = Nil | Cons a (Nest (a,a)) type family F a x :: * type instance F (Nest a) x = Either () (a,F (Nest (a,a)) x) fnn :: F (Nest Int) (Nest Int) fnn = Left () The following module fails to compile (or better, compilation never ends). Maybe there is something very bad going on due to the undecidable-instances extension? Any clue? hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080408/b9e3e9dd/attachment.htm From haberg at math.su.se Tue Apr 8 10:00:46 2008 From: haberg at math.su.se (Hans Aberg) Date: Tue Apr 8 09:56:26 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <7.0.1.0.0.20080408141630.01d09040@ntlworld.com> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> <0F57663B-B445-4057-ABBA-D093A81904C5@ece.cmu.edu> <655352789.20080408023012@gmail.com> <3410B141-1684-4170-B1C4-BD5FE4F798B2@math.su.se> <11316405.20080408124739@gmail.com> <7.0.1.0.0.20080408141630.01d09040@ntlworld.com> Message-ID: <29CFE110-7327-4574-A184-0B98AD210559@math.su.se> On 8 Apr 2008, at 15:26, PR Stanley wrote: > I'm sure you could introduce change gradually without too much pain. So then you only have to get the compilers to gradually understand it :-). > I personally think "deriving" is a descriptive term, now that I > understand its role better. There are two processes here: deriving, i.e., inheriting an interface; and instantiating, i.e., producing running code. Haskell denotes derivation by "=>". And "data deriving (b_1, ..., b_k)" is really a short for data instance b_1 where ... instance b_k where So "instance" seems the word that should have been used. But discussions of a change seems is likely just a caf? thing - I must go finishing mine :-). > I suppose you could consider "specialize" or "instanciate" but both > those terms are very closely associated with OO and deriving an > instance of a class with a type isn't quite like instantiation or > even specialisation. So then you introduce a new keyword and screwing up all existing code. > We want a single word which is equivalent to "derives from". > Deriving by itself can seem a bit ambiguous at first. What about the already used "=>"? Hans From chris.casinghino at gmail.com Tue Apr 8 10:15:51 2008 From: chris.casinghino at gmail.com (Chris Casinghino) Date: Tue Apr 8 10:11:29 2008 Subject: [Haskell-cafe] Parsec expressions with alphaNum operators In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80E8A52@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80E8A43@EX2.ad.dcs.gla.ac.uk> <3CDFB8AFEA98E34CB599475AB11589C80E8A52@EX2.ad.dcs.gla.ac.uk> Message-ID: On Tue, Apr 8, 2008 at 4:46 AM, Paul Keir wrote: > I have noticed something interesting though. If I simply omit the "a" > from "opLetter", the problem is gone. In fact, leaving "opStart", > "opLetter", and "reservedOpNames" all empty works fine too. That makes sense. opLetter is there to support "user-defined" operators, as many languages allow two distinct classes of identifiers - one which looks like variables and one which looks like symbolic operators. If you don't want to allow user-defined operators which contain "a", so that ":a:", a reserved keyword, is the only valid identifier which contains both "a" and another member of opLetter, you should be OK leaving "a" off of the list of opLetters. Indeed, you shouldn't actually need to specify ":a:" in reservedOpNames either, since "reservedOp" doesn't check that list, and the "operator" parser will already reject ":a:" because it contains a non-opLetter. Though, for sanity you might leave it there anyway. At least, I think so. --Chris From anton at appsolutions.com Tue Apr 8 10:32:13 2008 From: anton at appsolutions.com (Anton van Straaten) Date: Tue Apr 8 10:24:22 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <29CFE110-7327-4574-A184-0B98AD210559@math.su.se> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> <0F57663B-B445-4057-ABBA-D093A81904C5@ece.cmu.edu> <655352789.20080408023012@gmail.com> <3410B141-1684-4170-B1C4-BD5FE4F798B2@math.su.se> <11316405.20080408124739@gmail.com> <7.0.1.0.0.20080408141630.01d09040@ntlworld.com> <29CFE110-7327-4574-A184-0B98AD210559@math.su.se> Message-ID: <47FB81ED.3020609@appsolutions.com> Hans Aberg wrote: > There are two processes here: deriving, i.e., inheriting an interface; > and instantiating, i.e., producing running code. Haskell denotes > derivation by "=>". And "data deriving (b_1, ..., b_k)" is really a > short for > data > instance b_1 where > ... > instance b_k where > > So "instance" seems the word that should have been used. How about making "deriving x" an expression which means: instance x where This innovative solution will minimize changes to the Haskell compiler, documentation, and programmer's brains. Seriously, there's only so much connotational meaning you can pack into or extract from a keyword. Ultimately, programming language keywords follow the rule given by Humpty Dumpty: "When _I_ use a word, it means just what I choose it to mean -- neither more nor less." Anton From simon at joyful.com Tue Apr 8 10:25:20 2008 From: simon at joyful.com (Simon Michael) Date: Tue Apr 8 10:25:40 2008 Subject: [Haskell-cafe] Re: announcing the darcs 2.0.0 release In-Reply-To: <20080407172225.GB16717@darcs.net> References: <20080407172225.GB16717@darcs.net> Message-ID: <47FB8050.5050707@joyful.com> David, thank you for the last push, and clear re-org! And thanks to all darcs 2 contributors. -Simon From haberg at math.su.se Tue Apr 8 10:49:33 2008 From: haberg at math.su.se (Hans Aberg) Date: Tue Apr 8 10:45:13 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <47FB81ED.3020609@appsolutions.com> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> <0F57663B-B445-4057-ABBA-D093A81904C5@ece.cmu.edu> <655352789.20080408023012@gmail.com> <3410B141-1684-4170-B1C4-BD5FE4F798B2@math.su.se> <11316405.20080408124739@gmail.com> <7.0.1.0.0.20080408141630.01d09040@ntlworld.com> <29CFE110-7327-4574-A184-0B98AD210559@math.su.se> <47FB81ED.3020609@appsolutions.com> Message-ID: <45045CCC-B04B-432B-BE61-875D24868AF3@math.su.se> On 8 Apr 2008, at 16:32, Anton van Straaten wrote: >> There are two processes here: deriving, i.e., inheriting an >> interface; and instantiating, i.e., producing running code. >> Haskell denotes derivation by "=>". And "data deriving >> (b_1, ..., b_k)" is really a short for >> data >> instance b_1 where >> ... >> instance b_k where >> So "instance" seems the word that should have been used. > > How about making "deriving x" an expression which means: > > instance x where > > This innovative solution will minimize changes to the Haskell > compiler, documentation, and programmer's brains. So what is the difference from the current state? They way you have written it, one can say data A ... deriving Eq A Is that what you want? > Seriously, there's only so much connotational meaning you can pack > into or extract from a keyword. Ultimately, programming language > keywords follow the rule given by Humpty Dumpty: > > "When _I_ use a word, it means just what I choose it to mean -- > neither more nor less." That is why computer languages are what they are. Think of C "static". Hans From anton at appsolutions.com Tue Apr 8 10:57:11 2008 From: anton at appsolutions.com (Anton van Straaten) Date: Tue Apr 8 10:49:21 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <45045CCC-B04B-432B-BE61-875D24868AF3@math.su.se> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> <0F57663B-B445-4057-ABBA-D093A81904C5@ece.cmu.edu> <655352789.20080408023012@gmail.com> <3410B141-1684-4170-B1C4-BD5FE4F798B2@math.su.se> <11316405.20080408124739@gmail.com> <7.0.1.0.0.20080408141630.01d09040@ntlworld.com> <29CFE110-7327-4574-A184-0B98AD210559@math.su.se> <47FB81ED.3020609@appsolutions.com> <45045CCC-B04B-432B-BE61-875D24868AF3@math.su.se> Message-ID: <47FB87C7.3030503@appsolutions.com> Hans Aberg wrote: > On 8 Apr 2008, at 16:32, Anton van Straaten wrote: >>> There are two processes here: deriving, i.e., inheriting an >>> interface; and instantiating, i.e., producing running code. Haskell >>> denotes derivation by "=>". And "data deriving (b_1, ..., b_k)" >>> is really a short for >>> data >>> instance b_1 where >>> ... >>> instance b_k where >>> So "instance" seems the word that should have been used. >> >> How about making "deriving x" an expression which means: >> >> instance x where >> >> This innovative solution will minimize changes to the Haskell >> compiler, documentation, and programmer's brains. > > So what is the difference from the current state? None. See how efficient a solution it is? ;) From Christian.Maeder at dfki.de Tue Apr 8 11:03:21 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Apr 8 10:59:00 2008 Subject: [Haskell-cafe] Re: deriving In-Reply-To: <47FB81ED.3020609@appsolutions.com> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> <0F57663B-B445-4057-ABBA-D093A81904C5@ece.cmu.edu> <655352789.20080408023012@gmail.com> <3410B141-1684-4170-B1C4-BD5FE4F798B2@math.su.se> <11316405.20080408124739@gmail.com> <7.0.1.0.0.20080408141630.01d09040@ntlworld.com> <29CFE110-7327-4574-A184-0B98AD210559@math.su.se> <47FB81ED.3020609@appsolutions.com> Message-ID: <47FB8939.6020700@dfki.de> Anton van Straaten wrote: > How about making "deriving x" an expression which means: > > instance x where "deriving Eq" i.e. following "data List a = List a" creates an instance like: instance Eq a => Eq (List a) where The problem was discussed for Stand-alone deriving declarations: http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html Cheers Christian From haberg at math.su.se Tue Apr 8 11:46:54 2008 From: haberg at math.su.se (Hans Aberg) Date: Tue Apr 8 11:42:36 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <47FB87C7.3030503@appsolutions.com> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> <0F57663B-B445-4057-ABBA-D093A81904C5@ece.cmu.edu> <655352789.20080408023012@gmail.com> <3410B141-1684-4170-B1C4-BD5FE4F798B2@math.su.se> <11316405.20080408124739@gmail.com> <7.0.1.0.0.20080408141630.01d09040@ntlworld.com> <29CFE110-7327-4574-A184-0B98AD210559@math.su.se> <47FB81ED.3020609@appsolutions.com> <45045CCC-B04B-432B-BE61-875D24868AF3@math.su.se> <47FB87C7.3030503@appsolutions.com> Message-ID: On 8 Apr 2008, at 16:57, Anton van Straaten wrote: >> So what is the difference from the current state? > > None. See how efficient a solution it is? ;) So for a change, you propose it should be the same. So you are one of those A-programmers :-). > Seriously, there's only so much connotational meaning you can pack > into or extract from a keyword. Ultimately, programming language > keywords follow the rule given by Humpty Dumpty: > > "When _I_ use a word, it means just what I choose it to mean -- > neither more nor less." So your favorite language must be Humpty?! :-) Hans From haberg at math.su.se Tue Apr 8 11:54:16 2008 From: haberg at math.su.se (Hans Aberg) Date: Tue Apr 8 11:50:11 2008 Subject: [Haskell-cafe] Re: deriving In-Reply-To: <47FB8939.6020700@dfki.de> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> <0F57663B-B445-4057-ABBA-D093A81904C5@ece.cmu.edu> <655352789.20080408023012@gmail.com> <3410B141-1684-4170-B1C4-BD5FE4F798B2@math.su.se> <11316405.20080408124739@gmail.com> <7.0.1.0.0.20080408141630.01d09040@ntlworld.com> <29CFE110-7327-4574-A184-0B98AD210559@math.su.se> <47FB81ED.3020609@appsolutions.com> <47FB8939.6020700@dfki.de> Message-ID: On 8 Apr 2008, at 17:03, Christian Maeder wrote: > "deriving Eq" i.e. following "data List a = List a" creates an > instance > like: > > instance Eq a => Eq (List a) where > > The problem was discussed for Stand-alone deriving declarations: > > http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html There is a difference between data Foo a = Bar a | Baz String deriving instance Eq a => Eq (Foo a) and data Eq a => Foo a = Bar a | Baz String deriving (Eq) The second is more restrictive, as it requires Eq for the construction of Foo a, whereas the first could be construed to mean that Eq a is only required for the construction of Eq(Foo a). So the first could be used without Eq a if Eq(Foo a) is not needed. This is good when constructing libraries for general types. Hans From gusnieslu at student.gu.se Tue Apr 8 12:09:23 2008 From: gusnieslu at student.gu.se (ln) Date: Tue Apr 8 12:04:39 2008 Subject: [Haskell-cafe] Problem building HXT In-Reply-To: <404396ef0804080100v34909a40v597976fca4697a45@mail.gmail.com> References: <47FA6522.1050007@student.gu.se> <20080408022540.GA742043@localhost> <404396ef0804080100v34909a40v597976fca4697a45@mail.gmail.com> Message-ID: <47FB98B3.30209@student.gu.se> Neil Mitchell schrieb: > Hi > > >> You got it right. The issue is that in TagSoup.hs there is a line like 'parseTagsOptions (options { foo =...}'. That's invalid syntax AFAIK; >> > > It's just record syntax, which is very handy. > > >> more importantly, it's using functions from ndm's TagSoup library. TagSoup, with version 0.5, renamed the Options type to ParseOptions (we know the '(options {...' stuff is intended to be ParseOptions because parseTagsOptions handily comes with an explicit type signature). >> >> > > I thought this might be version skew. The released TagSoup on Hackage > should still have options, not parseOptions - which is only in the > darcs version. If you install tagsoup from Hackage you should be fine. > > Thanks > > Neil > Hey, thanks a lot for your advice. I fixed it by editing the TagSoup.hs file, it worked perfectly afterwards. Lukas From prstanley at ntlworld.com Tue Apr 8 12:26:42 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Tue Apr 8 12:22:10 2008 Subject: [Haskell-cafe] What's the difference? Message-ID: <7.0.1.0.0.20080408171921.01cfc1c0@ntlworld.com> Hi What is the difference between data T0 f a = MkT0 a instance Eq (T0 f a) where ... and data T0 f a = MkT0 a instance Eq a => Eq (T0 f a) where ... I've only seen the "=>" operator used for declaring extended classes but never with class instances. By the way, what is the correct terms for the "=>" and the "->"? Cheers Paul From paul at cogito.org.uk Tue Apr 8 12:43:16 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Tue Apr 8 12:38:55 2008 Subject: [Haskell-cafe] What's the difference? In-Reply-To: <7.0.1.0.0.20080408171921.01cfc1c0@ntlworld.com> References: <7.0.1.0.0.20080408171921.01cfc1c0@ntlworld.com> Message-ID: <47FBA0A4.2000502@cogito.org.uk> PR Stanley wrote: > Hi > What is the difference between > > data T0 f a = MkT0 a > instance Eq (T0 f a) where ... > > and > > data T0 f a = MkT0 a > instance Eq a => Eq (T0 f a) where ... > The second one says that "TO f a" is only an instance of "Eq" if "a" is, while the first says that "TO f a" is an instance regardless of the type of its arguments. You can regard an "instance" declaration as an inference rule for the type checker, with "=>" meaning "implies" (though I don't think its the answer to your other question about names). From jackmarathon at gmail.com Tue Apr 8 13:24:20 2008 From: jackmarathon at gmail.com (Jackm139) Date: Tue Apr 8 13:19:57 2008 Subject: [Haskell-cafe] testing for same characters in lists of strings In-Reply-To: <16546167.post@talk.nabble.com> References: <16546167.post@talk.nabble.com> Message-ID: <16568724.post@talk.nabble.com> Thanks for all the replies! I have it working somewhat. It works as long as there is only one string in each list, but if the lists contain more than one string it fails. here is what I have: import List same :: [[Char]] -> [[Char]] -> Bool same [xs] [ys] = map (normalize) [[xs]] == map (normalize) [[ys]] normalize :: [String] -> [String] normalize [xs] = [(sort (nub xs))] How can I make this work for lists that contain more than one string? -- View this message in context: http://www.nabble.com/testing-for-same-characters-in-lists-of-strings-tp16546167p16568724.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From paulrbrown+haskell-cafe at gmail.com Tue Apr 8 13:36:40 2008 From: paulrbrown+haskell-cafe at gmail.com (Paul Brown) Date: Tue Apr 8 13:32:20 2008 Subject: [Haskell-cafe] Re: HXT 7.4/7.5 leaking TCP connections In-Reply-To: References: <200804082300.52246.dm.maillists@gmail.com> <200804081340.30623.uwe@fh-wedel.de> Message-ID: <4249453d0804081036g58eff9acta02d4f421a70a4e7@mail.gmail.com> Hi, Bjorn and Uwe -- > > this is a known problem with HTTP package (version 3001.0.4). > > Paul Brown has described this somewere in his blog. > > (http://mult.ifario.us/t/haskell), but my firefox only shows > > an incomplete page of this blog, the solution is missing. > > Paul promissed in his blog to send a patch to Bj?rn Bringert. Here's the link to the article about SimpleHTTP; for some reason, it wasn't showing up. (Guess I have a bug to fix there...) http://mult.ifario.us/p/a-short-adventure-with-simplehttp > > P.S. to Bj?rn: It would be nice, if you could include this change into the > > HTTP module and upload a new version to hackage. > Thank you Daniel and Uwe for reporting this (again). Strangely, I > thought that I had already applied Paul's patch, but it seems I > haven't. Paul: I seem to recall us talking about this, but can't > remember the conclusion, nor find any e-mail about it. Do you remember > anything about this? I can't remember either; I'm sure that the darcs patch is lurking on one of my boxes. I'll track it down and send it your way so we can squash this one. Best. -- Paul -- paulrbrown@gmail.com http://mult.ifario.us/ From zooko at zooko.com Tue Apr 8 13:41:43 2008 From: zooko at zooko.com (zooko) Date: Tue Apr 8 13:37:30 2008 Subject: [Haskell-cafe] Re: [darcs-devel] announcing the darcs 2.0.0 release In-Reply-To: <20080407172225.GB16717@darcs.net> References: <20080407172225.GB16717@darcs.net> Message-ID: <543A4203-286A-4AE9-A6DB-D30BD5A48766@zooko.com> Hooray for the release of darcs-2! Way to go, David! Regards, Zooko From jgbailey at gmail.com Tue Apr 8 14:17:00 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Tue Apr 8 14:12:38 2008 Subject: [Haskell-cafe] testing for same characters in lists of strings In-Reply-To: <16568724.post@talk.nabble.com> References: <16546167.post@talk.nabble.com> <16568724.post@talk.nabble.com> Message-ID: On Tue, Apr 8, 2008 at 10:24 AM, Jackm139 wrote: > import List > > same :: [[Char]] -> [[Char]] -> Bool > same [xs] [ys] = map (normalize) [[xs]] == map (normalize) [[ys]] > > normalize :: [String] -> [String] > normalize [xs] = [(sort (nub xs))] > Your pattern binding [xs] and [ys] says to only match when the list contains one element. Otherwise, you get a pattern-matching failure at run-time. Use "normalize xs" to match a list of strings, and "same xs ys" to match lists of lists. xs and ys will have different types with those patterns, but you'll get it. Justin From westondan at imageworks.com Tue Apr 8 14:51:28 2008 From: westondan at imageworks.com (Dan Weston) Date: Tue Apr 8 14:47:07 2008 Subject: [Haskell-cafe] What's the difference? In-Reply-To: <47FBA0A4.2000502@cogito.org.uk> References: <7.0.1.0.0.20080408171921.01cfc1c0@ntlworld.com> <47FBA0A4.2000502@cogito.org.uk> Message-ID: <47FBBEB0.6050809@imageworks.com> Paul Johnson wrote: > You can regard an "instance" declaration as an inference rule for the > type checker, with "=>" meaning "implies" (though I don't think its the > answer to your other question about names). "implies" might be a bad word, because the direction is backwards: Eq a => Ord a is clearly false if read that "Eq a implies Ord a". It is Ord a that implies Eq a. I just read it as "required for" myself. Dan From mail at joachim-breitner.de Tue Apr 8 15:15:21 2008 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue Apr 8 15:11:01 2008 Subject: [Haskell-cafe] What's the difference? In-Reply-To: <47FBBEB0.6050809@imageworks.com> References: <7.0.1.0.0.20080408171921.01cfc1c0@ntlworld.com> <47FBA0A4.2000502@cogito.org.uk> <47FBBEB0.6050809@imageworks.com> Message-ID: <1207682121.6475.58.camel@otto.ehbuehl.net> Hi, Am Dienstag, den 08.04.2008, 11:51 -0700 schrieb Dan Weston: > Paul Johnson wrote: > > You can regard an "instance" declaration as an inference rule for the > > type checker, with "=>" meaning "implies" (though I don't think its the > > answer to your other question about names). > > "implies" might be a bad word, because the direction is backwards: > > Eq a => Ord a > > is clearly false if read that "Eq a implies Ord a". It is Ord a that > implies Eq a. > > I just read it as "required for" myself. I think both can be justified. Take > instance X a => Y a where ... "X a" is required so that the instance declaration can be used. But also: Given this declaration, having an instance "X a" implies that you will also have an instance "Y a". But not not every type with "Y b" will also have "Y a". Or were you talking about constraints in the class declaration, which your choice of Eq and Ord suggests? Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080408/d82ebcea/attachment.bin From haberg at math.su.se Tue Apr 8 15:23:33 2008 From: haberg at math.su.se (Hans Aberg) Date: Tue Apr 8 15:19:14 2008 Subject: [Haskell-cafe] Function Precedence In-Reply-To: <6f9f8f4a0804020720t72785b35wcb8f20d69b783be6@mail.gmail.com> References: <7.0.1.0.0.20080401113920.01d5fd30@ntlworld.com> <32910698-81AB-4BD9-BE0F-D62EA54CC1A2@math.su.se> <4E0E4674-7F3A-46F3-B963-D1B4848C1F6D@math.su.se> <21F4B14D-6539-46B4-9F64-C4A3CD5D553F@math.su.se> <6f9f8f4a0804020720t72785b35wcb8f20d69b783be6@mail.gmail.com> Message-ID: <5134F9AD-B802-4233-8A48-FC20AB02E7FA@math.su.se> On 2 Apr 2008, at 16:20, Loup Vaillant wrote: >> class AdditiveSemiMonoid a where >> (+) :: a -> a -> a > > Err, why *semi* monoid? Plain "monoid" would not be accurate? I found an example where it is crucial that the monoid has a unit: When given a monoid m, then one can also define an m-algebra, by giving a structure map (works in 'hugs -98'): class Monad m => MAlgebra m a where smap :: m a -> a Now, the set of lists on a set A is just the free monoid with base A; the list monad identifies the free monoids, i.e., the lists. So this then gives Haskell interpretation class Monoid a where unit :: a (***) :: a -> a -> a instance Monoid a => MAlgebra [] a where smap [] = unit smap (x:xs) = x *** smap xs Here, I use (***) to not clash with the Prelude (*). But the function "product" here shows up as the structure map of a multiplicative monoid. Similarly, "sum" is the structure map of the additive monoids. And (++) is just the monoid multiplication of the free monoids. Hans From t.h at gmx.info Tue Apr 8 15:36:57 2008 From: t.h at gmx.info (Timo B. =?utf-8?q?H=C3=BCbel?=) Date: Tue Apr 8 15:32:52 2008 Subject: [Haskell-cafe] ANN: Hayoo! beta 0.1 In-Reply-To: <47FA102D.8090606@philip.in-aachen.net> References: <200804061407.22507.t.h@gmx.info> <47FA102D.8090606@philip.in-aachen.net> Message-ID: <200804082136.57594.t.h@gmx.info> > However, I have found two bugs, or annoyances: > Using Opera 9.27 or Internet Explorer 7, > - Search results vanish when using the "back" button Yes, that is a known problem. Although I have no good idea how to solve this while keeping the AJAX stuff (that is, find as you type). > - the "Source" and ghc docs links always take me to the top of the pages, > it seems the anchors don't work. Hm, there is nothing special about these. Plain tags with an anchor, no fancy JavaScript stuff. Perhaps these browsers are generally irritated by inserting something into the DOM using JavaScript ... > In Firefox 2.0.0.13 these problems do not appear. Yes, and FF is what we recommend right now, as everything "just works". But I'll try to improve browser compatibility in future releases. > Keep up the good work! We'll try ;) Timo From lemming at henning-thielemann.de Tue Apr 8 16:10:54 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Apr 8 16:05:13 2008 Subject: [Haskell-cafe] testing for same characters in lists of strings In-Reply-To: <16568724.post@talk.nabble.com> References: <16546167.post@talk.nabble.com> <16568724.post@talk.nabble.com> Message-ID: On Tue, 8 Apr 2008, Jackm139 wrote: > > Thanks for all the replies! > I have it working somewhat. It works as long as there is only one string in > each list, but if the lists contain more than one string it fails. here is > what I have: > > > import List > > same :: [[Char]] -> [[Char]] -> Bool > same [xs] [ys] = map (normalize) [[xs]] == map (normalize) [[ys]] > > normalize :: [String] -> [String] > normalize [xs] = [(sort (nub xs))] 'normalize' (if correctly implemented) is essentially the same as 'Data.Set.fromList' From kha-list-haskell-cafe at hemma.treskal.com Tue Apr 8 16:21:34 2008 From: kha-list-haskell-cafe at hemma.treskal.com (Karl =?iso-8859-1?Q?Hasselstr=F6m?=) Date: Tue Apr 8 16:17:32 2008 Subject: [Haskell-cafe] problems building hpodder In-Reply-To: <200804072020.25068.jgoerzen@complete.org> References: <20080406222410.GA8408@diana.vm.bytemark.co.uk> <20080407225739.GA649997@localhost> <200804072020.25068.jgoerzen@complete.org> Message-ID: <20080408202134.GA14852@diana.vm.bytemark.co.uk> On 2008-04-07 20:20:24 -0500, John Goerzen wrote: > On Monday 07 April 2008 5:57:39 pm gwern0@gmail.com wrote: > > > So almost certainly the issue is that HaXml has updated and > > changed things around in a way that broke Hpodder; not surprising, > > since HaXml-1.19.2 is as recent as 14 January 2008, and Goerzen > > may simply not have updated and discovered the error before he > > released Hpodder in February. > > I won't be updating it anytime soon, in fact. 1.19.2 is a > development version, according to the author, so I will stick with > 1.13.3 -- the stable, released version. Unfortunately, Hackage has > no way to indicate stable vs. alpha, I guess. (That would make life > easier here.) I suppose I ought to also post something on the > hpodder wiki and update the Cabal build-deps so it gets the right > HaXml version. http://www.haskell.org/haskellwiki/Package_versioning_policy seems to have something relevant to say. build-depends: HaXml >= 1.13.3 && < 1.14 ought to do the trick, since any changes in the published interface are supposed to be accompanied by a version bump in one of the first two numbers. -- Karl Hasselstr?m, kha@treskal.com www.treskal.com/kalle From dm.maillists at gmail.com Tue Apr 8 16:24:41 2008 From: dm.maillists at gmail.com (Daniel McAllansmith) Date: Tue Apr 8 16:20:30 2008 Subject: [Haskell-cafe] Re: HXT 7.4/7.5 leaking TCP connections In-Reply-To: <4249453d0804081036g58eff9acta02d4f421a70a4e7@mail.gmail.com> References: <200804082300.52246.dm.maillists@gmail.com> <4249453d0804081036g58eff9acta02d4f421a70a4e7@mail.gmail.com> Message-ID: <200804090824.41940.dm.maillists@gmail.com> Hello all. On Wed, 09 Apr 2008 05:36:40 Paul Brown wrote: > Hi, Bjorn and Uwe -- > > > > this is a known problem with HTTP package (version 3001.0.4). > > > Paul Brown has described this somewere in his blog. > > > (http://mult.ifario.us/t/haskell), but my firefox only shows > > > an incomplete page of this blog, the solution is missing. > > > Paul promissed in his blog to send a patch to Bj?rn Bringert. I'm not so sure it's due to the bug that Paul has patched. http was my first suspect and I managed to find a google cache of Paul's page, which wouldn't load for me. I've tried patching http with both patches on that page (one by Paul, one suggested in a comment). I then incremented http's version and rebuilt, changed the dependencies to require that version of http in HXT 7.5 and rebuilt, then required those versions in my test program. It still leaks TCP connections. I think that means that everything is using the patched http. Can I query what installed packages are linked against somehow? Paul's patch looks to ensure connections are closed when there is an exception, I'm leaking (I think) every TCP connection. Here's the test code again for the -cafe. Is there something obvious wrong with it? ==================== module Main where import Control.Exception (bracket) import Control.Monad (unless) import Text.XML.HXT.Arrow import System.IO (IOMode(..), hClose, hGetLine, hIsEOF, openFile) --/tmp/list.txt is a list of files on a local webserver. main = bracket (openFile "/tmp/list.txt" ReadMode) hClose processAll processAll hdl = do b <- hIsEOF hdl if b then return "done" else processNext hdl processNext hdl = hGetLine hdl >>= process >> processAll hdl process s = runX (getXmlPageBad (buildURL s)) --process s = runX (getXmlPageOK (buildURL s)) buildURL = ("http://localhost.localdomain/" ++) getXmlPageOK = readDocument [ (a_use_curl, "1"), (a_parse_html, "1"), (a_encoding, isoLatin1), (a_issue_warnings, "0") ] getXmlPageBad = readDocument [ (a_parse_html, "1"), (a_encoding, isoLatin1), (a_issue_warnings, "0") ] =================== A related question is: what does an open TCP connection that gets garbage collected turn into? I've been seeing lines like the following is lsof, and they still count toward the open file limit, I suspect they're garbage collected connections. test 28300 daniel 1023u sock 0,4 13900773 can't identify protocol > > Here's the link to the article about SimpleHTTP; for some reason, it > wasn't showing up. (Guess I have a bug to fix there...) > > http://mult.ifario.us/p/a-short-adventure-with-simplehttp > > > > P.S. to Bj?rn: It would be nice, if you could include this change > > > into the HTTP module and upload a new version to hackage. > > > > Thank you Daniel and Uwe for reporting this (again). Strangely, I > > thought that I had already applied Paul's patch, but it seems I > > haven't. Paul: I seem to recall us talking about this, but can't > > remember the conclusion, nor find any e-mail about it. Do you remember > > anything about this? > > I can't remember either; I'm sure that the darcs patch is lurking on > one of my boxes. I'll track it down and send it your way so we can > squash this one. As I said, I've patched the latest darcs code with both the suggested patches on Pauls page, I can send either/both through to you if you would like Bj?rn. Cheers Daniel From jgoerzen at complete.org Tue Apr 8 16:43:22 2008 From: jgoerzen at complete.org (John Goerzen) Date: Tue Apr 8 16:39:05 2008 Subject: [Haskell-cafe] problems building hpodder In-Reply-To: <20080408202134.GA14852@diana.vm.bytemark.co.uk> References: <20080406222410.GA8408@diana.vm.bytemark.co.uk> <200804072020.25068.jgoerzen@complete.org> <20080408202134.GA14852@diana.vm.bytemark.co.uk> Message-ID: <200804081543.23279.jgoerzen@complete.org> On Tue April 8 2008 3:21:34 pm Karl Hasselstr?m wrote: > http://www.haskell.org/haskellwiki/Package_versioning_policy seems to > have something relevant to say. build-depends: HaXml >= 1.13.3 && < > 1.14 ought to do the trick, since any changes in the published > interface are supposed to be accompanied by a version bump in one of > the first two numbers. That syntax didn't work under testing, but HaXml >= 1.13.2, HaXml < 1.19 did the trick. -- John From kha-list-haskell-cafe at hemma.treskal.com Tue Apr 8 16:49:08 2008 From: kha-list-haskell-cafe at hemma.treskal.com (Karl =?iso-8859-1?Q?Hasselstr=F6m?=) Date: Tue Apr 8 16:44:49 2008 Subject: [Haskell-cafe] problems building hpodder In-Reply-To: <20080407225739.GA649997@localhost> References: <20080406222410.GA8408@diana.vm.bytemark.co.uk> <20080407225739.GA649997@localhost> Message-ID: <20080408204908.GB14852@diana.vm.bytemark.co.uk> On 2008-04-07 18:57:39 -0400, gwern0@gmail.com wrote: > So almost certainly the issue is that HaXml has updated and changed > things around in a way that broke Hpodder; not surprising, since > HaXml-1.19.2 is as recent as 14 January 2008, and Goerzen may simply > not have updated and discovered the error before he released Hpodder > in February. Yes, with an older HaXml it worked beautifully. Thanks! -- Karl Hasselstr?m, kha@treskal.com www.treskal.com/kalle From prstanley at ntlworld.com Tue Apr 8 17:05:10 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Tue Apr 8 17:00:39 2008 Subject: [Haskell-cafe] What's the difference? In-Reply-To: <47FBA0A4.2000502@cogito.org.uk> References: <7.0.1.0.0.20080408171921.01cfc1c0@ntlworld.com> <47FBA0A4.2000502@cogito.org.uk> Message-ID: <7.0.1.0.0.20080408220253.01d049d8@ntlworld.com> >>What is the difference between >> >> data T0 f a = MkT0 a >> instance Eq (T0 f a) where ... >> >> and >> >> data T0 f a = MkT0 a >> instance Eq a => Eq (T0 f a) where ... >The second one says that "TO f a" is only an instance of "Eq" if "a" >is, while the first says that "TO f a" is an instance regardless of >the type of its arguments. > More explanation please. :-) Much obliged, Paul From gtener at gmail.com Tue Apr 8 17:38:21 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Tue Apr 8 17:34:00 2008 Subject: [Haskell-cafe] What's the difference? In-Reply-To: <7.0.1.0.0.20080408220253.01d049d8@ntlworld.com> References: <7.0.1.0.0.20080408171921.01cfc1c0@ntlworld.com> <47FBA0A4.2000502@cogito.org.uk> <7.0.1.0.0.20080408220253.01d049d8@ntlworld.com> Message-ID: <220e47b40804081438k3abb9cb7rd7d1a4739d5b94e4@mail.gmail.com> On Tue, Apr 8, 2008 at 11:05 PM, PR Stanley wrote: > > > > > > > What is the difference between > > > > > > data T0 f a = MkT0 a > > > instance Eq (T0 f a) where ... > > > > > > and > > > > > > data T0 f a = MkT0 a > > > instance Eq a => Eq (T0 f a) where ... > > > > > The second one says that "TO f a" is only an instance of "Eq" if "a" is, > while the first says that "TO f a" is an instance regardless of the type of > its arguments. > > > > > More explanation please. :-) > Well, it's similar with functions. If we try: foo :: a -> a -> Bool foo x y = x < y We'll get an error: the usage of `<` requires `a` to be in Ord class, which we write down as type signature: foo :: (Ord a) => a -> a -> Bool The similar effect is for type classes. Here: > instance Eq a => Eq (T0 f a) where ... We can see that we can compare elements of type `a` for equality. It's kind of saying: "if you give me an element of type `a`, and that type is in Eq class, I can tell you how to tell equality of elements of type T0 f a". Regards Christopher Skrz?tnicki From westondan at imageworks.com Tue Apr 8 17:58:57 2008 From: westondan at imageworks.com (Dan Weston) Date: Tue Apr 8 18:01:52 2008 Subject: [Haskell-cafe] What's the difference? In-Reply-To: <1207682121.6475.58.camel@otto.ehbuehl.net> References: <7.0.1.0.0.20080408171921.01cfc1c0@ntlworld.com> <47FBA0A4.2000502@cogito.org.uk> <47FBBEB0.6050809@imageworks.com> <1207682121.6475.58.camel@otto.ehbuehl.net> Message-ID: <47FBEAA1.802@imageworks.com> Yes, sorry I should have read the post more carefully. I was talking specifically the use of => in class declarations, and this is a good example of how inconsistent the notation seems to me. It is in the class declaration that the arrow is backwards. (I imagine this decision was more syntactically motivated by the fact that <= is already the less-than-or-equal-to symbol, rather than intended semantic confusion?) class Necessary a => My a i.e. My a implies Necessary a instance Sufficient a => My a i.e. Sufficient a implies My a I pronounce the => in class declarations as "required for", and in instance definitions as "sufficient for". For me, the word "implies" is too tied in my brain to an arrow symbol to be useful to me in keeping the implications straight. Dan Joachim Breitner wrote: > Hi, > Am Dienstag, den 08.04.2008, 11:51 -0700 schrieb Dan Weston: >> Paul Johnson wrote: >>> You can regard an "instance" declaration as an inference rule for the >>> type checker, with "=>" meaning "implies" (though I don't think its the >>> answer to your other question about names). >> "implies" might be a bad word, because the direction is backwards: >> >> Eq a => Ord a >> >> is clearly false if read that "Eq a implies Ord a". It is Ord a that >> implies Eq a. >> >> I just read it as "required for" myself. > > I think both can be justified. Take > >> instance X a => Y a where ... > > "X a" is required so that the instance declaration can be used. > > But also: > > Given this declaration, having an instance "X a" implies that you will > also have an instance "Y a". But not not every type with "Y b" will also > have "Y a". > > Or were you talking about constraints in the class declaration, which > your choice of Eq and Ord suggests? > > Greetings, > Joachim > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From t.h at gmx.info Tue Apr 8 18:18:08 2008 From: t.h at gmx.info (Timo B. =?utf-8?q?H=C3=BCbel?=) Date: Tue Apr 8 18:13:52 2008 Subject: [Haskell-cafe] ANN: Hayoo! beta 0.1 In-Reply-To: <200804061407.22507.t.h@gmx.info> References: <200804061407.22507.t.h@gmx.info> Message-ID: <200804090018.08998.t.h@gmx.info> Hello, thanks for all the feedback so far! We have just deployed some minor updates for Hayoo!, mainly improving the ranking mechanism. It should now prefer modules from the Prelude as well as functions exactly matching the query terms. Additionally, we have started a blog about Hayoo! and Holumbus development which can be found here: http://holumbus.fh-wedel.de/blog Have fun using Hayoo! Timo From gwern0 at gmail.com Tue Apr 8 19:07:36 2008 From: gwern0 at gmail.com (gwern0@gmail.com) Date: Tue Apr 8 19:07:55 2008 Subject: [Haskell-cafe] problems building hpodder In-Reply-To: <200804081519.12746.jgoerzen@complete.org> References: <20080406222410.GA8408@diana.vm.bytemark.co.uk> <200804072020.25068.jgoerzen@complete.org> <20080408023104.GB742043@localhost> <200804081519.12746.jgoerzen@complete.org> Message-ID: <20080408230736.GA18206@localhost> On 2008.04.08 15:19:12 -0500, John Goerzen scribbled 1.1K characters: > On Mon April 7 2008 9:31:04 pm gwern0@gmail.com wrote: > > > > Well, changing the deps at least would be a good idea. > > Right. I've uploaded a new version of hpodder to hackage that will require > the correct HaXml versions. Great. > > And actually, there is a method - Cabal supports the 'stability:' field, > > but I don't believe it's enforced by cabal-install or anything. > > I think part of the problem is visibility in Hackage. Unless I'm wrong, > Hackage always takes you to the release with the highest version number. > There is no "latest stable version" list and "latest development version" > list, which would be helpful. Something akin to, say, > http://packages.debian.org/hpodder Yes, that's true. There is no good way of doing in Hackage that doesn't involve self-discipline or messing with release schedules. I do have a thought about the 'stability:' field, though. Feel free to weigh in at . > > (Personally, I'd update it, not just because of issues like this, but > > because there looked to be a number of changes necessary when I commented > > all the type sigs, and the longer you wait... &etc.) > > The thing is -- I don't want a stable hpodder to jump to a development > version of HaXml. The released version is working just fine, and when there > is a new stable release, I'll update then. XML parsing is quite central to > hpodder. > > -- John Sure, but there are costs to not transitioning just as there are costs to so doing. I was just saying which cost I found preferable. -- gwern JANET Salsa GSA TRANSEC LASINT A/B DJC Al BIOLWPN Xandros -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080408/228dc36d/attachment.bin From stevelihn at gmail.com Tue Apr 8 20:14:45 2008 From: stevelihn at gmail.com (Steve Lihn) Date: Tue Apr 8 20:10:22 2008 Subject: [Haskell-cafe] ANN: Hayoo! beta 0.1 In-Reply-To: <200804090018.08998.t.h@gmx.info> References: <200804061407.22507.t.h@gmx.info> <200804090018.08998.t.h@gmx.info> Message-ID: Bug report: I am using IE6. The "Powered by" bar at the bottom does not reposition as I scroll down. So there is a small portion on the page always masked by the "Powered by" bar. Nice work. Great google-like speed... Steve On 4/8/08, Timo B. H?bel wrote: > > Hello, > > thanks for all the feedback so far! We have just deployed some minor > updates > for Hayoo!, mainly improving the ranking mechanism. It should now prefer > modules from the Prelude as well as functions exactly matching the query > terms. > > Additionally, we have started a blog about Hayoo! and Holumbus development > which can be found here: http://holumbus.fh-wedel.de/blog > > Have fun using Hayoo! > > Timo > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080408/a06b6d50/attachment.htm From lrpalmer at gmail.com Tue Apr 8 20:34:12 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Apr 8 20:29:48 2008 Subject: [Haskell-cafe] ANN: graphics-drawingcombinators 0.1 Message-ID: <7ca3f0160804081734j34c4577k6f38f3434496bee4@mail.gmail.com> graphics-drawingcombinators 0.1 has just been uploaded to hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/graphics-drawingcombinators-0.1 Have you ever tried to write a simple 2D interface or game but found: * wxHaskell and gtk2hs are hard to install and learn * SDL does not provide enough by itself * OpenGL is gross and imperative? Then you're in luck, with the release of this very immature new module, Graphics.DrawingCombinators! This module is a wrapper around OpenGL with a functional interface, handling a small subset but still common set of 2D OpenGL functions. It currently handles some simple geometric primitives and transformations, loading images from files and SDL.Surfaces, and drawing text using SDL.TTF. I plan to add more support for lots of stuff in the future, the next priorities being: * A clean "picking" interface. * Ability to draw non-regular polygons (yeah, that's kinda important isn't it...) If there are any features which you would find useful (as long as it's in the 2D realm, I'm still contemplating how to do 3D stuff), I'd be glad to hear it and implement it. Look at example.hs in the distro for an example of how to use this with SDL. Enjoy! Luke From ok at cs.otago.ac.nz Tue Apr 8 21:49:14 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Tue Apr 8 21:44:53 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <47FA72C1.1060308@imageworks.com> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> Message-ID: On 8 Apr 2008, at 7:15 am, Dan Weston wrote: > [1] Yes, I know that "conciseness" is the much more common and > accepted word for this, but if we can say "precision", "decision", > and "incision", then it seems foolish to not also use "concision". I > will henceforth take on this quixotic quest to promote the use of > "concision". Please don't. There is already an English word "concision" that means something quite different. To quote the OED: "The action of cutting to pieces or cutting away; mutilation." To be honest, sense 3 in the OED is exactly what you want, but why take the risk of confusing people? And if you really don't like "conciseness", what's wrong with "brevity"? From westondan at imageworks.com Tue Apr 8 22:06:41 2008 From: westondan at imageworks.com (Dan Weston) Date: Tue Apr 8 22:02:21 2008 Subject: [Haskell-cafe] deriving In-Reply-To: References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> Message-ID: <47FC24B1.7020004@imageworks.com> Richard A. O'Keefe wrote: > On 8 Apr 2008, at 7:15 am, Dan Weston wrote: >> [1] Yes, I know that "conciseness" is the much more common and >> accepted word for this, but if we can say "precision", "decision", and >> "incision", then it seems foolish to not also use "concision". I will >> henceforth take on this quixotic quest to promote the use of "concision". > > Please don't. There is already an English word "concision" that means > something quite different. To quote the OED: > "The action of cutting to pieces or cutting away; mutilation." I thought that was called "circumcision". :) From chak at cse.unsw.edu.au Tue Apr 8 22:24:46 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Apr 8 22:20:31 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> Message-ID: <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> Sittampalam, Ganesh: > Manuel Chakravarty wrote: >> Ganesh Sittampalam: >>> On Mon, 7 Apr 2008, Manuel M T Chakravarty wrote: >>> >>>> Ganesh Sittampalam: >>>>> The following program doesn't compile in latest GHC HEAD, although >>>>> it does if I remove the signature on foo'. Is this expected? >>>> >>>> Yes, unfortunately, this is expected, although it is very >>>> unintuitive. This is for the following reason. >>>> >>>> Let's alpha-rename the signatures and use explicit foralls for >>>> clarity: >>>> >>>> foo :: forall a. Id a -> Id a >>>> foo' :: forall b. Id b -> Id b >>>> >>>> GHC will try to match (Id a) against (Id b). As Id is a type >>>> synonym >>>> family, it would *not* be valid to derive (a ~ b) from this. After >>>> all, Id could have the same result for different argument types. >>>> (That's not the case for your one instance, but maybe in another >>>> module, there are additional instances for Id, where that is the >>>> case.) >>> >>> Can't it derive (Id a ~ Id b), though? > >> That's what it does derive as a proof obligation and finds it can't >> prove. >> The error message you are seeing is GHC's way of saying, I cannot >> assert that >> (Id a ~ Id b) holds. > > No, I meant can't it derive that equality when matching (Id a) > against (Id b)? > As you say, it can't derive (a ~ b) at that point, but (Id a ~ Id b) > is known, > surely? No, it is not know. Why do you think it is? >>> Generally speaking, is there any way to give a signature to foo'? > >> Sorry, but in the heat of explaining what GHC does, I missed the >> probably crucial point. Your function foo is useless, as is foo'. >> Not only can't you rename foo (to foo'), but you generally can't use >> it. It's signature is ambiguous. Try evaluating (foo (1::Int)). >> The >> problem is related to the infamous (show . read). > > My real code is somewhat analogous to (foo :: (Id Int -> Id Int)) > (1::Int). > Isn't that unambiguous in the same way as (show.read) is if I give > show or > read a signature? No. The problem with a functions that has an ambiguous signature is that it contains type variables that are impossible to constrain by applying the function. Providing a type signature at the application site makes this no easier. Why? Consider what a type annotation means. By writing e :: t, you express your intent to use e at type t, but you also force the compiler to check that whatever type it derives for e is more general than t. It is this check for type subsumption that is the tricky bit when typing TFs (or FDs). See for more detail on why this is a hard problem. The problem with an ambiguous signature is that the subsumption check always fails, because the ambiguous signature contains some type variables for which the type checker cannot deduce a type instance. (You as a human reader may be able to *guess* an instance, but HM- based inference does generally not guess. It's a deterministic process.) The problem is really with foo and its signature, not with any use of foo. The function foo is (due to its type) unusable. Can't you change foo? Manuel From jonathanccast at fastmail.fm Tue Apr 8 22:26:26 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Tue Apr 8 22:22:03 2008 Subject: [Haskell-cafe] deriving In-Reply-To: <47FC24B1.7020004@imageworks.com> References: <7.0.1.0.0.20080407170534.01d2a628@ntlworld.com> <47FA72C1.1060308@imageworks.com> <47FC24B1.7020004@imageworks.com> Message-ID: On 8 Apr 2008, at 7:06 PM, Dan Weston wrote: > Richard A. O'Keefe wrote: >> On 8 Apr 2008, at 7:15 am, Dan Weston wrote: >>> [1] Yes, I know that "conciseness" is the much more common and >>> accepted word for this, but if we can say "precision", >>> "decision", and "incision", then it seems foolish to not also use >>> "concision". I will henceforth take on this quixotic quest to >>> promote the use of "concision". >> Please don't. There is already an English word "concision" that >> means >> something quite different. To quote the OED: >> "The action of cutting to pieces or cutting away; mutilation." > > I thought that was called "circumcision". :) Phillipians 3:2-3 (KJV) http://www.godrules.net/library/kjv/kjvphi3.htm jcc From chak at cse.unsw.edu.au Tue Apr 8 22:29:19 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Apr 8 22:25:01 2008 Subject: [Haskell-cafe] translating from fundeps into type families In-Reply-To: References: <3BD29AEC-18E8-4A8C-B44F-3643D17A285B@cse.unsw.edu.au> Message-ID: <6FDCFB3C-16E7-4327-8562-F7F8CA99E3D7@cse.unsw.edu.au> Chadda? Fouch?: > 2008/4/8, Manuel M T Chakravarty : >> You need to write the instance as >> >> instance (b ~ TheFoo a, Foo a) => Bar (Either a b) where >> bar (Left a) = foo' a >> bar (Right b) = foo' (foo b :: a) >> > > If you do that, the program compile, but res still raise a panic in > GHC6.8.2 . > > Before you sent your solution, I also tried to do > > class (TheFoo a ~ b) => Foo a b where ... > > instance (Foo a b) => Bar (Either a b) where ... > > But it didn't compile, it seems to me both versions should have the > same behaviour ? 6.8.2 has many bugs concerning type families that have been removed in the development version of GHC. Manuel From ganesh at earth.li Wed Apr 9 01:02:04 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Wed Apr 9 00:57:40 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> Message-ID: On Wed, 9 Apr 2008, Manuel M T Chakravarty wrote: > Sittampalam, Ganesh: >> No, I meant can't it derive that equality when matching (Id a) against >> (Id b)? As you say, it can't derive (a ~ b) at that point, but (Id a ~ >> Id b) is known, surely? > > No, it is not know. Why do you think it is? Well, if the types of foo and foo' were forall a . a -> a and forall b . b -> b, I would expect the type-checker to unify a and b in the argument position and then discover that this equality made the result position unify too. So why can't the same happen but with Id a and Id b instead? > The problem is really with foo and its signature, not with any use of foo. > The function foo is (due to its type) unusable. Can't you change foo? Here's a cut-down version of my real code. The type family Apply is very important because it allows me to write class instances for things that might be its first parameter, like Id and Comp SqlExpr Maybe, without paying the syntactic overhead of forcing client code to use Id/unId and Comp/unComp. It also squishes nested Maybes which is important to my application (since SQL doesn't have them). castNum is the simplest example of a general problem - the whole point is to allow clients to write code that is overloaded over the first parameter to Apply using primitives like castNum. I'm not really sure how I could get away from the ambiguity problem, given that desire. Cheers, Ganesh {-# LANGUAGE TypeFamilies, GADTs, UndecidableInstances, NoMonomorphismRestriction #-} newtype Id a = Id { unId :: a } newtype Comp f g x = Comp { unComp :: f (g x) } type family Apply (f :: * -> *) a type instance Apply Id a = a type instance Apply (Comp f g) a = Apply f (Apply g a) type instance Apply SqlExpr a = SqlExpr a type instance Apply Maybe Int = Maybe Int type instance Apply Maybe Double = Maybe Double type instance Apply Maybe (Maybe a) = Apply Maybe a class DoubleToInt s where castNum :: Apply s Double -> Apply s Int instance DoubleToInt Id where castNum = round instance DoubleToInt SqlExpr where castNum = SECastNum data SqlExpr a where SECastNum :: SqlExpr Double -> SqlExpr Int castNum' :: (DoubleToInt s) => Apply s Double -> Apply s Int castNum' = castNum From martin.sulzmann at gmail.com Wed Apr 9 02:20:53 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Wed Apr 9 02:16:30 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> Message-ID: <47FC6045.1040800@gmail.com> Manuel said earlier that the source of the problem here is foo's ambiguous type signature (I'm switching back to the original, simplified example). Type checking with ambiguous type signatures is hard because the type checker has to guess types and this guessing step may lead to too many (ambiguous) choices. But this doesn't mean that this worst case scenario always happens. Consider your example again type family Id a type instance Id Int = Int foo :: Id a -> Id a foo = id foo' :: Id a -> Id a foo' = foo The type checking problem for foo' boils down to verifying the formula forall a. exists b. Id a ~ Id b Of course for any a we can pick b=a to make the type equation statement hold. Fairly easy here but the point is that the GHC type checker doesn't do any guessing at all. The only option you have (at the moment, there's still lots of room for improving GHC's type checking process) is to provide some hints, for example mimicking System F style type application by introducing a type proxy argument in combination with lexically scoped type variables. foo :: a -> Id a -> Id a foo _ = id foo' :: Id a -> Id a foo' = foo (undefined :: a) Martin Ganesh Sittampalam wrote: > On Wed, 9 Apr 2008, Manuel M T Chakravarty wrote: > >> Sittampalam, Ganesh: > >>> No, I meant can't it derive that equality when matching (Id a) >>> against (Id b)? As you say, it can't derive (a ~ b) at that point, >>> but (Id a ~ Id b) is known, surely? >> >> No, it is not know. Why do you think it is? > > Well, if the types of foo and foo' were forall a . a -> a and forall b > . b -> b, I would expect the type-checker to unify a and b in the > argument position and then discover that this equality made the result > position unify too. So why can't the same happen but with Id a and Id > b instead? > >> The problem is really with foo and its signature, not with any use of >> foo. The function foo is (due to its type) unusable. Can't you >> change foo? > > Here's a cut-down version of my real code. The type family Apply is > very important because it allows me to write class instances for > things that might be its first parameter, like Id and Comp SqlExpr > Maybe, without paying the syntactic overhead of forcing client code to > use Id/unId and Comp/unComp. It also squishes nested Maybes which is > important to my application (since SQL doesn't have them). > > castNum is the simplest example of a general problem - the whole point > is to allow clients to write code that is overloaded over the first > parameter to Apply using primitives like castNum. I'm not really sure > how I could get away from the ambiguity problem, given that desire. > > Cheers, > > Ganesh > > {-# LANGUAGE TypeFamilies, GADTs, UndecidableInstances, > NoMonomorphismRestriction #-} > > newtype Id a = Id { unId :: a } > newtype Comp f g x = Comp { unComp :: f (g x) } > > type family Apply (f :: * -> *) a > > type instance Apply Id a = a > type instance Apply (Comp f g) a = Apply f (Apply g a) > type instance Apply SqlExpr a = SqlExpr a > type instance Apply Maybe Int = Maybe Int > type instance Apply Maybe Double = Maybe Double > type instance Apply Maybe (Maybe a) = Apply Maybe a > > class DoubleToInt s where > castNum :: Apply s Double -> Apply s Int > > instance DoubleToInt Id where > castNum = round > > instance DoubleToInt SqlExpr where > castNum = SECastNum > > data SqlExpr a where > SECastNum :: SqlExpr Double -> SqlExpr Int > > castNum' :: (DoubleToInt s) => Apply s Double -> Apply s Int > castNum' = castNum > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ganesh.sittampalam at credit-suisse.com Wed Apr 9 03:09:01 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Apr 9 03:06:45 2008 Subject: [Haskell-cafe] type families and type signatures Message-ID: <8C984B4799C04D4B8F80F746537145E116F4F683@elon12p32001.csfp.co.uk> OK, thanks. I think I'm finally understanding :-) Cheers, Ganesh -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Martin Sulzmann Sent: 09 April 2008 07:21 To: Ganesh Sittampalam Cc: Manuel M T Chakravarty; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] type families and type signatures Manuel said earlier that the source of the problem here is foo's ambiguous type signature (I'm switching back to the original, simplified example). Type checking with ambiguous type signatures is hard because the type checker has to guess types and this guessing step may lead to too many (ambiguous) choices. But this doesn't mean that this worst case scenario always happens. Consider your example again type family Id a type instance Id Int = Int foo :: Id a -> Id a foo = id foo' :: Id a -> Id a foo' = foo The type checking problem for foo' boils down to verifying the formula forall a. exists b. Id a ~ Id b Of course for any a we can pick b=a to make the type equation statement hold. Fairly easy here but the point is that the GHC type checker doesn't do any guessing at all. The only option you have (at the moment, there's still lots of room for improving GHC's type checking process) is to provide some hints, for example mimicking System F style type application by introducing a type proxy argument in combination with lexically scoped type variables. foo :: a -> Id a -> Id a foo _ = id foo' :: Id a -> Id a foo' = foo (undefined :: a) Martin Ganesh Sittampalam wrote: > On Wed, 9 Apr 2008, Manuel M T Chakravarty wrote: > >> Sittampalam, Ganesh: > >>> No, I meant can't it derive that equality when matching (Id a) >>> against (Id b)? As you say, it can't derive (a ~ b) at that point, >>> but (Id a ~ Id b) is known, surely? >> >> No, it is not know. Why do you think it is? > > Well, if the types of foo and foo' were forall a . a -> a and forall b > . b -> b, I would expect the type-checker to unify a and b in the > argument position and then discover that this equality made the result > position unify too. So why can't the same happen but with Id a and Id > b instead? > >> The problem is really with foo and its signature, not with any use of >> foo. The function foo is (due to its type) unusable. Can't you >> change foo? > > Here's a cut-down version of my real code. The type family Apply is > very important because it allows me to write class instances for > things that might be its first parameter, like Id and Comp SqlExpr > Maybe, without paying the syntactic overhead of forcing client code to > use Id/unId and Comp/unComp. It also squishes nested Maybes which is > important to my application (since SQL doesn't have them). > > castNum is the simplest example of a general problem - the whole point > is to allow clients to write code that is overloaded over the first > parameter to Apply using primitives like castNum. I'm not really sure > how I could get away from the ambiguity problem, given that desire. > > Cheers, > > Ganesh > > {-# LANGUAGE TypeFamilies, GADTs, UndecidableInstances, > NoMonomorphismRestriction #-} > > newtype Id a = Id { unId :: a } > newtype Comp f g x = Comp { unComp :: f (g x) } > > type family Apply (f :: * -> *) a > > type instance Apply Id a = a > type instance Apply (Comp f g) a = Apply f (Apply g a) type instance > Apply SqlExpr a = SqlExpr a type instance Apply Maybe Int = Maybe Int > type instance Apply Maybe Double = Maybe Double type instance Apply > Maybe (Maybe a) = Apply Maybe a > > class DoubleToInt s where > castNum :: Apply s Double -> Apply s Int > > instance DoubleToInt Id where > castNum = round > > instance DoubleToInt SqlExpr where > castNum = SECastNum > > data SqlExpr a where > SECastNum :: SqlExpr Double -> SqlExpr Int > > castNum' :: (DoubleToInt s) => Apply s Double -> Apply s Int castNum' > = castNum > > _______________________________________________ > 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 ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From lennart at augustsson.net Wed Apr 9 03:26:58 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Apr 9 03:22:34 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: <47FC6045.1040800@gmail.com> References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> Message-ID: Let's look at this example from a higher level. Haskell is a language which allows you to write type signatures for functions, and even encourages you to do it. Sometimes you even have to do it. Any language feature that stops me from writing a type signature is in my opinion broken. TFs as implemented in currently implemented ghc stops me from writing type signatures. They are thus, in my opinion, broken. A definition should either be illegal or it should be able to have a signature. I think this is a design goal. It wasn't true in Haskell 98, and it's generally agreed that this was a mistake. To summarize: I don't care if the definition is useless, I want to be able to give it a type signature anyway. (It's also pretty easy to fix the problem.) -- Lennart On Wed, Apr 9, 2008 at 7:20 AM, Martin Sulzmann wrote: > Manuel said earlier that the source of the problem here is foo's ambiguous > type signature > (I'm switching back to the original, simplified example). > Type checking with ambiguous type signatures is hard because the type > checker has to guess > types and this guessing step may lead to too many (ambiguous) choices. But > this doesn't mean > that this worst case scenario always happens. > > Consider your example again > > type family Id a > > type instance Id Int = Int > > foo :: Id a -> Id a > foo = id > > foo' :: Id a -> Id a > foo' = foo > > The type checking problem for foo' boils down to verifying the formula > > forall a. exists b. Id a ~ Id b > > Of course for any a we can pick b=a to make the type equation statement > hold. > Fairly easy here but the point is that the GHC type checker doesn't do any > guessing > at all. The only option you have (at the moment, there's still lots of > room for improving > GHC's type checking process) is to provide some hints, for example > mimicking > System F style type application by introducing a type proxy argument in > combination > with lexically scoped type variables. > > foo :: a -> Id a -> Id a > foo _ = id > > foo' :: Id a -> Id a > foo' = foo (undefined :: a) > > > Martin > > > > Ganesh Sittampalam wrote: > > > On Wed, 9 Apr 2008, Manuel M T Chakravarty wrote: > > > > Sittampalam, Ganesh: > > > > > > > No, I meant can't it derive that equality when matching (Id a) against > > > > (Id b)? As you say, it can't derive (a ~ b) at that point, but (Id a ~ Id b) > > > > is known, surely? > > > > > > > > > > No, it is not know. Why do you think it is? > > > > > > > Well, if the types of foo and foo' were forall a . a -> a and forall b . > > b -> b, I would expect the type-checker to unify a and b in the argument > > position and then discover that this equality made the result position unify > > too. So why can't the same happen but with Id a and Id b instead? > > > > The problem is really with foo and its signature, not with any use of > > > foo. The function foo is (due to its type) unusable. Can't you change foo? > > > > > > > Here's a cut-down version of my real code. The type family Apply is very > > important because it allows me to write class instances for things that > > might be its first parameter, like Id and Comp SqlExpr Maybe, without paying > > the syntactic overhead of forcing client code to use Id/unId and > > Comp/unComp. It also squishes nested Maybes which is important to my > > application (since SQL doesn't have them). > > > > castNum is the simplest example of a general problem - the whole point > > is to allow clients to write code that is overloaded over the first > > parameter to Apply using primitives like castNum. I'm not really sure how I > > could get away from the ambiguity problem, given that desire. > > > > Cheers, > > > > Ganesh > > > > {-# LANGUAGE TypeFamilies, GADTs, UndecidableInstances, > > NoMonomorphismRestriction #-} > > > > newtype Id a = Id { unId :: a } > > newtype Comp f g x = Comp { unComp :: f (g x) } > > > > type family Apply (f :: * -> *) a > > > > type instance Apply Id a = a > > type instance Apply (Comp f g) a = Apply f (Apply g a) > > type instance Apply SqlExpr a = SqlExpr a > > type instance Apply Maybe Int = Maybe Int > > type instance Apply Maybe Double = Maybe Double > > type instance Apply Maybe (Maybe a) = Apply Maybe a > > > > class DoubleToInt s where > > castNum :: Apply s Double -> Apply s Int > > > > instance DoubleToInt Id where > > castNum = round > > > > instance DoubleToInt SqlExpr where > > castNum = SECastNum > > > > data SqlExpr a where > > SECastNum :: SqlExpr Double -> SqlExpr Int > > > > castNum' :: (DoubleToInt s) => Apply s Double -> Apply s Int > > castNum' = castNum > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080409/7b9cf57b/attachment.htm From martin.sulzmann at gmail.com Wed Apr 9 03:53:07 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Wed Apr 9 03:48:44 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> Message-ID: <47FC75E3.4050902@gmail.com> I think it's not fair to say TFs as implemented in GHC are broken. Fine, they are situations where the current implementation is overly conservative. The point is that the GHC type checker relies on automatic inference. Hence, there'll always be cases where certain "reasonable" type signatures are rejected. For example, consider the case of "undecidable" and "non-confluent" type class instances. instance Foo a => Bar a -- (1) instance Erk a => Bar [a] -- (2) GHC won't accept the above type class instance (note: instances are a kind of type signature) because - instance (1) is potentially non-terminating (the size of the type term is not decreasing) - instance (2) overlaps with (1), hence, it can happen that during context reduction we choose the "wrong" instance. To conclude, any system with automatic inference will necessary reject certain type signatures/instances in order to guarantee soundness, completeness and termination. Lennart, you said > (It's also pretty easy to fix the problem.) What do you mean? Easy to fix the type checker, or easy to fix the program by inserting annotations to guide the type checker? Martin Lennart Augustsson wrote: > Let's look at this example from a higher level. > > Haskell is a language which allows you to write type signatures for > functions, and even encourages you to do it. > Sometimes you even have to do it. Any language feature that stops me > from writing a type signature is in my opinion broken. > TFs as implemented in currently implemented ghc stops me from writing > type signatures. They are thus, in my opinion, broken. > > A definition should either be illegal or it should be able to have a > signature. I think this is a design goal. It wasn't true in Haskell > 98, and it's generally agreed that this was a mistake. > > To summarize: I don't care if the definition is useless, I want to be > able to give it a type signature anyway. > > (It's also pretty easy to fix the problem.) > > -- Lennart > > On Wed, Apr 9, 2008 at 7:20 AM, Martin Sulzmann > > wrote: > > Manuel said earlier that the source of the problem here is foo's > ambiguous type signature > (I'm switching back to the original, simplified example). > Type checking with ambiguous type signatures is hard because the > type checker has to guess > types and this guessing step may lead to too many (ambiguous) > choices. But this doesn't mean > that this worst case scenario always happens. > > Consider your example again > > > type family Id a > > type instance Id Int = Int > > foo :: Id a -> Id a > foo = id > > foo' :: Id a -> Id a > foo' = foo > > The type checking problem for foo' boils down to verifying the formula > > forall a. exists b. Id a ~ Id b > > Of course for any a we can pick b=a to make the type equation > statement hold. > Fairly easy here but the point is that the GHC type checker > doesn't do any guessing > at all. The only option you have (at the moment, there's still > lots of room for improving > GHC's type checking process) is to provide some hints, for example > mimicking > System F style type application by introducing a type proxy > argument in combination > with lexically scoped type variables. > > foo :: a -> Id a -> Id a > foo _ = id > > foo' :: Id a -> Id a > foo' = foo (undefined :: a) > > > Martin > > > > Ganesh Sittampalam wrote: > > On Wed, 9 Apr 2008, Manuel M T Chakravarty wrote: > > Sittampalam, Ganesh: > > > No, I meant can't it derive that equality when > matching (Id a) against (Id b)? As you say, it can't > derive (a ~ b) at that point, but (Id a ~ Id b) is > known, surely? > > > No, it is not know. Why do you think it is? > > > Well, if the types of foo and foo' were forall a . a -> a and > forall b . b -> b, I would expect the type-checker to unify a > and b in the argument position and then discover that this > equality made the result position unify too. So why can't the > same happen but with Id a and Id b instead? > > The problem is really with foo and its signature, not with > any use of foo. The function foo is (due to its type) > unusable. Can't you change foo? > > > Here's a cut-down version of my real code. The type family > Apply is very important because it allows me to write class > instances for things that might be its first parameter, like > Id and Comp SqlExpr Maybe, without paying the syntactic > overhead of forcing client code to use Id/unId and > Comp/unComp. It also squishes nested Maybes which is important > to my application (since SQL doesn't have them). > > castNum is the simplest example of a general problem - the > whole point is to allow clients to write code that is > overloaded over the first parameter to Apply using primitives > like castNum. I'm not really sure how I could get away from > the ambiguity problem, given that desire. > > Cheers, > > Ganesh > > {-# LANGUAGE TypeFamilies, GADTs, UndecidableInstances, > NoMonomorphismRestriction #-} > > newtype Id a = Id { unId :: a } > newtype Comp f g x = Comp { unComp :: f (g x) } > > type family Apply (f :: * -> *) a > > type instance Apply Id a = a > type instance Apply (Comp f g) a = Apply f (Apply g a) > type instance Apply SqlExpr a = SqlExpr a > type instance Apply Maybe Int = Maybe Int > type instance Apply Maybe Double = Maybe Double > type instance Apply Maybe (Maybe a) = Apply Maybe a > > class DoubleToInt s where > castNum :: Apply s Double -> Apply s Int > > instance DoubleToInt Id where > castNum = round > > instance DoubleToInt SqlExpr where > castNum = SECastNum > > data SqlExpr a where > SECastNum :: SqlExpr Double -> SqlExpr Int > > castNum' :: (DoubleToInt s) => Apply s Double -> Apply s Int > castNum' = castNum > > _______________________________________________ > 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 > > From apfelmus at quantentunnel.de Wed Apr 9 04:45:11 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Wed Apr 9 04:41:03 2008 Subject: [Haskell-cafe] Re: type families and type signatures In-Reply-To: References: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> Message-ID: Manuel M T Chakravarty wrote: > apfelmus: >> Manuel M T Chakravarty wrote: >>> Let's alpha-rename the signatures and use explicit foralls for clarity: >>> foo :: forall a. Id a -> Id a >>> foo' :: forall b. Id b -> Id b >>> GHC will try to match (Id a) against (Id b). As Id is a type synonym >>> family, it would *not* be valid to derive (a ~ b) from this. After >>> all, Id could have the same result for different argument types. >>> (That's not the case for your one instance, but maybe in another >>> module, there are additional instances for Id, where that is the case.) >> >> While in general (Id a ~ Id b) -/-> (a ~ b) , parametricity makes >> it "true" in the case of foo . For instance, let Id a ~ Int . Then, >> the signature specializes to foo :: Int -> Int . But due to >> parametricity, foo does not care at all what a is and will be the >> very same function for every a with Id a ~ Int . In other words, >> it's as if the type variable a is not in scope in the definition of >> foo . > > Be careful, Id is a type-indexed type family and *not* a parametric > type. Parametricity does not apply. For more details about the > situation with GADTs alone, see > > Foundations for Structured Programming with GADTs. Patricia Johann and > Neil Ghani. Proceedings, Principles of Programming Languages 2008 > (POPL'08). Yes and no. In the GADT case, a function like bar :: forall a . GADT a -> String is clearly not "parametric" in a, in the sense that pattern matching on the GADT can specialize a which means that we have some form of "pattern matching" on the type a . The resulting String may depend on the type a . So, by "parametricity", I mean "type arguments may not be inspected". Likewise, bar :: forall a . Show a => Phantom a -> String is not parametric in a since the result may depend on the type a . However, I have this feeling that bar :: forall a . Id a -> String with a type family Id *is* parametric in the sense that no matter what a is, the result always has to be the same. Intuitively, that's because we may not "pattern match on the branch" of a definition like type instance Id String = .. type instance Id Int = .. .. So, in the special case of foo and foo' , solving Id b ~ Id a by guessing a ~ b is safe since foo is parametric in a . Every guess is fine. I don't think that this can be squeezed into a type inference/checking algorithm, though. >> In full System F , neither definition would be a problem since the >> type a is an explicit parameter. > > You can't generally translate type family/GADT programs into System F. > We proposed an extension of System F called System F_C(X); see our > TLDI'07 paper: > > http://www.cse.unsw.edu.au/~chak/papers/SCPD07.html Yes of course. I just wanted to remark that the whole ambiguity stuff is only there because we don't (want to) have explicit type application ? la System F(_C(X)). Regards, apfelmus From Tom.Schrijvers at cs.kuleuven.be Wed Apr 9 05:04:57 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Wed Apr 9 05:01:49 2008 Subject: [Haskell-cafe] Re: type families and type signatures In-Reply-To: References: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> Message-ID: > However, I have this feeling that > > bar :: forall a . Id a -> String > > with a type family Id *is* parametric in the sense that no matter what a > is, the result always has to be the same. Intuitively, that's because we may > not "pattern match on the branch" of a definition like > > type instance Id String = .. > type instance Id Int = .. > .. But in a degenerate case there could be just this one instance: type instance Id x = GADT x which then reduces this example to the GADT case of which you said that is was "clearly parametric". Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From jules at jellybean.co.uk Wed Apr 9 05:26:11 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Apr 9 05:21:44 2008 Subject: [Haskell-cafe] instance Monad m => Functor m In-Reply-To: <93A90667-13CD-4E88-B39B-BD878D24C0F5@math.su.se> References: <93A90667-13CD-4E88-B39B-BD878D24C0F5@math.su.se> Message-ID: <47FC8BB3.5040103@jellybean.co.uk> Hans Aberg wrote: > Using 'hugs -98', I noticed it accepts: > instance Monad m => Functor m where > fmap f x = x >>= return.f > > Has this been considered (say) as a part of the upcoming Haskell Prime? This forbids any Functors which are not monads. Unless you allow overlapping instances (which of course would not be h98 any more!). Other solutions, such as class Functor m => Monad m are frequently discussed. I see no H' ticket for it, though. Jules From claus.reinke at talk21.com Wed Apr 9 05:41:41 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Apr 9 05:37:23 2008 Subject: [Haskell-cafe] type families and type signatures References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> Message-ID: <007901c89a25$ebc876f0$e9217ad5@cr3lt> > type family Id a > > type instance Id Int = Int > > foo :: Id a -> Id a > foo = id n > > foo' :: Id a -> Id a > foo' = foo type function notation is slightly misleading, as it presents qualified polymorphic types in a form usually reserved for unqualified polymorphic types. rewriting foo's type helped me to see the ambiguity that others have pointed out: foo :: r ~ Id a => r -> r there's nowhere to get the 'a' from. so unless 'Id' itself is fully polymorphic in 'a' (Id a = a, Id a = Int, ..), 'foo' can't really be used. for each type variable, there needs to be at least one position where it is not used as a type family parameter. it might be useful to issue an ambiguity warning for such types? perhaps, with closed type families, one might be able to reason backwards (is there a unique 'a' such that 'Id a ~ Int'?), as with bidirectional FDs. but if you want to flatten all 'Maybe'-nests, even that direction isn't unique. > The type checking problem for foo' boils down to verifying the formula > > forall a. exists b. Id a ~ Id b naively, i'd have expected to run into this instead/first: (forall a. Id a -> Id a) ~ (forall b. Id b -> Id b) which ought to be true modulo alpha conversion, without guesses, making 'foo'' as valid/useless as 'foo' itself. where am i going wrong? claus ps. i find these examples and discussions helpful, if often initially puzzling - they help to clear up weak spots in the practice of type family use, understanding, and implementation, thereby improving all while making families more familiar!-) From claus.reinke at talk21.com Wed Apr 9 05:54:52 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Apr 9 05:50:35 2008 Subject: [Haskell-cafe] type families and type signatures References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> <47FC75E3.4050902@gmail.com> Message-ID: <00b901c89a27$c3594a30$e9217ad5@cr3lt> > The point is that the GHC type checker relies on automatic inference. > Hence, there'll > always be cases where certain "reasonable" type signatures are rejected. .. > To conclude, any system with automatic inference will necessary reject > certain type signatures/instances > in order to guarantee soundness, completeness and termination. i think Lennart's complaint is mainly about cases where GHC does not accept the very type signature it infers itself. all of which cases i'd consider bugs myself, independent of what type system feature they are related to. there are also the related cases of type signatures which cannot be expressed in the language but which might occur behind the scenes. all of these cases i'd consider language limitations that ought to be removed. the latter cases also mean that type errors are reported either in a syntax that can not be used in programs or in a misleading external syntax that does not fully represent the internal type. in this example, ghci infers a type for foo' that it rejects as a type signature for foo'. so, either the inferred type is inaccurately presented, or there's a gap in the type system, between inferred and declared types, right? claus From martin.sulzmann at gmail.com Wed Apr 9 05:57:09 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Wed Apr 9 05:52:47 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: <007901c89a25$ebc876f0$e9217ad5@cr3lt> References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> <007901c89a25$ebc876f0$e9217ad5@cr3lt> Message-ID: <47FC92F5.6010604@gmail.com> Claus Reinke wrote: >> type family Id a >> >> type instance Id Int = Int >> >> foo :: Id a -> Id a >> foo = id n >> >> foo' :: Id a -> Id a >> foo' = foo > > type function notation is slightly misleading, as it presents > qualified polymorphic types in a form usually reserved for unqualified > polymorphic types. > > rewriting foo's type helped me to see the ambiguity that > others have pointed out: > > foo :: r ~ Id a => r -> r > > there's nowhere to get the 'a' from. so unless 'Id' itself is > fully polymorphic in 'a' (Id a = a, Id a = Int, ..), 'foo' can't > really be used. for each type variable, there needs to be > at least one position where it is not used as a type family > parameter. > Correct because type family constructors are injective only. [Side note: With FDs you can enforce bijection class Inj a b | a -> b class Bij a b | a -> b, b -> a ] > it might be useful to issue an ambiguity warning for such types? > > perhaps, with closed type families, one might be able to > reason backwards (is there a unique 'a' such that 'Id a ~ Int'?), > as with bidirectional FDs. but if you want to flatten all > 'Maybe'-nests, even that direction isn't unique. > True, type checking with closed type families will rely on some form of solving and then we're more likely to guess (the right) types. >> The type checking problem for foo' boils down to verifying the formula >> >> forall a. exists b. Id a ~ Id b > > naively, i'd have expected to run into this instead/first: > > (forall a. Id a -> Id a) ~ (forall b. Id b -> Id b) > > which ought to be true modulo alpha conversion, without guesses, > making 'foo'' as valid/useless as 'foo' itself. > > where am i going wrong? You're notion of subsumption is too strong here. I've been using (forall as. C => t) <= (forall bs. C' => t') iff forall bs. (C' implies exist bs. (C /\ t=t')) where (forall as. C => t) is the inferred type (forall bs. C' => t') is the annotated type Makes sense? Even if we establish (forall a. Id a -> Id a) ~ (forall b. Id b -> Id b) we'd need to guess a ~ b (which is of course obvious) > claus > > ps. i find these examples and discussions helpful, if often initially > puzzling - they help to clear up weak spots in the practice > of type family use, understanding, and implementation, > thereby improving all while making families more familiar!-) Absolutely! Martin From martin.sulzmann at gmail.com Wed Apr 9 06:02:25 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Wed Apr 9 05:58:02 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: <00b901c89a27$c3594a30$e9217ad5@cr3lt> References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> <47FC75E3.4050902@gmail.com> <00b901c89a27$c3594a30$e9217ad5@cr3lt> Message-ID: <47FC9431.6020201@gmail.com> Claus Reinke wrote: >> The point is that the GHC type checker relies on automatic inference. >> Hence, there'll >> always be cases where certain "reasonable" type signatures are rejected. > .. >> To conclude, any system with automatic inference will necessary >> reject certain type signatures/instances >> in order to guarantee soundness, completeness and termination. > > i think Lennart's complaint is mainly about cases where GHC does not > accept the very type signature it infers itself. all of > which cases i'd consider bugs myself, independent of what > type system feature they are related to. > > there are also the related cases of type signatures which cannot be > expressed in the language but which might > occur behind the scenes. all of these cases i'd consider > language limitations that ought to be removed. > > the latter cases also mean that type errors are reported either in a > syntax that can not be used in programs or in a misleading external > syntax that does not fully represent the internal type. > > in this example, ghci infers a type for foo' that it rejects as a type > signature for foo'. so, either the inferred type > is inaccurately presented, or there's a gap in the type > system, between inferred and declared types, right? > Good point(s) which I missed earlier. Type inference (no annotations) is easy but type checking is much harder. Type checking is not all about pure checking, we also perform some inference, the Hindley/Milner unification variables which arise out of the program text (we need to satisfy these constraints via the annotation). To make type checking easier we should impose restrictions on inference. We (Tom/SimonPJ/Manuel) thought about this possibility. The problem is that it's hard to give an intuitive, declarative description of those restrictions. Martin From haberg at math.su.se Wed Apr 9 07:17:06 2008 From: haberg at math.su.se (Hans Aberg) Date: Wed Apr 9 07:12:46 2008 Subject: [Haskell-cafe] instance Monad m => Functor m In-Reply-To: <47FC8BB3.5040103@jellybean.co.uk> References: <93A90667-13CD-4E88-B39B-BD878D24C0F5@math.su.se> <47FC8BB3.5040103@jellybean.co.uk> Message-ID: On 9 Apr 2008, at 11:26, Jules Bean wrote: >> Using 'hugs -98', I noticed it accepts: >> instance Monad m => Functor m where >> fmap f x = x >>= return.f >> Has this been considered (say) as a part of the upcoming Haskell >> Prime? > > This forbids any Functors which are not monads. Unless you allow > overlapping instances... I see it as a Haskell limitation of not being able to indicate the function names in the class definition head: If one could write say class Monoid (a; unit, mult) where unit :: a mult :: a -> a -> a then it is possible to say instance Monoid ([]; [], (++)) where -- 'unit' already defined -- definition of (++) Similarly: class Functor (m; fmap) where fmap :: (a -> b) -> (m a -> m b) instance Monad m => Functor (m, mmap) where mmap f x = x >>= return.f - For backwards compatibility, if the function names are not indicated, one gets the declaration names as default. I don't know if it is possible to extend the syntax this way, but it would be closer to math usage. And one would avoid duplicate definitions just to indicate different operator names, like: class AdditiveMonoid a where o :: a (+) :: a -> a -> a as it could be create using class Monoid (a; o, (+)) > ...(which of course would not be h98 any more!). It does not work in 'hugs +98' mode; if I avoid the Prelude names by: class Munctor m where mmap :: (a -> b) -> (m a -> m b) instance Monad m => Munctor m where mmap f x = x >>= return.f I get ERROR - Syntax error in instance head (constructor expected) > Other solutions, such as class Functor m => Monad m are frequently > discussed. The point is that Monads have a code lifting property, so the functor is already conatained in the current definition. One might want to have away to override, so even if instance Monad m => Functor (m, mmap) functor specialization can take place if one has a more efficeint definition. For example instance Functor ([], mmap) where mmap = map Hans From lemming at henning-thielemann.de Wed Apr 9 09:23:55 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Apr 9 09:18:24 2008 Subject: [Haskell-cafe] instance Monad m => Functor m In-Reply-To: References: <93A90667-13CD-4E88-B39B-BD878D24C0F5@math.su.se> <47FC8BB3.5040103@jellybean.co.uk> Message-ID: On Wed, 9 Apr 2008, Hans Aberg wrote: > I don't know if it is possible to extend the syntax this way, but it would be > closer to math usage. And one would avoid duplicate definitions just to > indicate different operator names, like: > class AdditiveMonoid a where > o :: a > (+) :: a -> a -> a > as it could be create using > class Monoid (a; o, (+)) I also recognized that problem in the past, but didn't know how to solve it. In Haskell 98, methods are resolved using the types of the operands. How would the compiler find out which implementation of (+) to choose for an expression like x+y using your approach? From pete-expires-20080608 at kazmier.com Wed Apr 9 09:50:27 2008 From: pete-expires-20080608 at kazmier.com (Pete Kazmier) Date: Wed Apr 9 09:50:39 2008 Subject: [Haskell-cafe] Lock-Free Data Structures using STMs in Haskell Message-ID: <871w5fgmsc.fsf@coco.kazmier.com> I recently read the STM paper on lock-free data structures [1] which I found very informative in my quest to learn how to use STM. However, there are a few things I do not fully understand and was hoping someone might be able to explain further. In the STM version of the ArrayBlockingQueue, the following type is defined: data ArrayBlockingQueueSTM e = ArrayBlockingQueueSTM { shead :: TVar Int, stail :: TVar Int, sused :: TVar Int, slen :: Int, sa :: Array Int (TVar e) } It's unclear to me why the Array's elements must be wrapped in TVars. Why aren't the TVars on shead, stail, and sused sufficient? Here is the only function that reads from the queue: readHeadElementSTM :: ArrayBlockingQueueSTM e -> Bool -> Bool -> STM (Maybe e) readHeadElementSTM abq remove block = do u <- readTVar (sused abq) if u == 0 then if block then retry else return Nothing else do h <- readTVar (ihead abq) let tv = sa abq ! h -- Why are the array elements wrapped in TVars? e <- readTVar tv if remove then do let len = slen abq let newh = h `mod` len writeTVar (shead abq) $! newh writeTVar (sused abq) $! (u-1) else return () return (Just e) It is not immediately obvious to me why the elements need to be wrapped in TVars. Could someone help elaborate? The other question is in regards to section 2 where STM is introduced. The authors define the following: decT :: TVar Int -> IO () decT v = atomically (do x <- readTVar v if x == 0 then retry else return () writeTVar v (x-1)) And then go on to show how easy it is to compose STM types with this function: decPair v1 v1 :: TVar Int -> TVar Int -> IO () decPair v1 v2 = atomically (decT v1 `orElse` decT v2) Will this actually compile? I was under the impression that 'orElse' could only combine STM types, not IO () types. Thank you, Pete [1] Anthony Discolo, Tim Harris, Simon Marlow, Simon Peyton Jones, and Satnam Singh. Lock-free data structures using STMs in Haskell. In Eighth International Symposium on Functional and Logic Programming (FLOPS.06), April 2006. From haberg at math.su.se Wed Apr 9 10:06:23 2008 From: haberg at math.su.se (Hans Aberg) Date: Wed Apr 9 10:02:00 2008 Subject: [Haskell-cafe] instance Monad m => Functor m In-Reply-To: References: <93A90667-13CD-4E88-B39B-BD878D24C0F5@math.su.se> <47FC8BB3.5040103@jellybean.co.uk> Message-ID: On 9 Apr 2008, at 15:23, Henning Thielemann wrote: >> I don't know if it is possible to extend the syntax this way, but >> it would be closer to math usage. And one would avoid duplicate >> definitions just to indicate different operator names, like: >> class AdditiveMonoid a where >> o :: a >> (+) :: a -> a -> a >> as it could be create using >> class Monoid (a; o, (+)) > > I also recognized that problem in the past, but didn't know how to > solve it. In Haskell 98, methods are resolved using the types of > the operands. How would the compiler find out which implementation > of (+) to choose for an expression like x+y using your approach? Different names result in different operator hierarchies. So a class like class Monoid (a; unit, mult) where unit :: a mult :: a -> a -> a must have an instantiation that specifies the names of the operators. In particular, one will need a class (Monoid (a; 0; (+)), ...) => Num a ... if (+) should be used as Monoid.(+) together with Num.(+). Or give an example you think may cause problems, and I will give it a try. Hans From lemming at henning-thielemann.de Wed Apr 9 10:26:32 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Apr 9 10:21:00 2008 Subject: [Haskell-cafe] instance Monad m => Functor m In-Reply-To: References: <93A90667-13CD-4E88-B39B-BD878D24C0F5@math.su.se> <47FC8BB3.5040103@jellybean.co.uk> Message-ID: On Wed, 9 Apr 2008, Hans Aberg wrote: > Different names result in different operator hierarchies. So a class like > class Monoid (a; unit, mult) where > unit :: a > mult :: a -> a -> a > must have an instantiation that specifies the names of the operators. In > particular, one will need a > class (Monoid (a; 0; (+)), ...) => Num a ... > if (+) should be used as Monoid.(+) together with Num.(+). > > Or give an example you think may cause problems, and I will give it a try. I think a classical example are number sequences which can be considered as rings in two ways: 1. elementwise multiplication 2. convolution and you have some function which invokes the ring multiplication f :: Ring a => a -> a and a concrete sequence x :: Sequence Integer what multiplication (elementwise or convolution) shall be used for computing (f x) ? From haberg at math.su.se Wed Apr 9 10:32:13 2008 From: haberg at math.su.se (Hans Aberg) Date: Wed Apr 9 10:27:50 2008 Subject: [Haskell-cafe] instance Monad m => Functor m In-Reply-To: References: <93A90667-13CD-4E88-B39B-BD878D24C0F5@math.su.se> <47FC8BB3.5040103@jellybean.co.uk> Message-ID: <4C3D9A3E-F721-4140-85B7-08F11C821752@math.su.se> On 9 Apr 2008, at 15:23, Henning Thielemann wrote: > I also recognized that problem in the past, but didn't know how to > solve it. In Haskell 98, methods are resolved using the types of > the operands. How would the compiler find out which implementation > of (+) to choose for an expression like x+y using your approach? I might describe the idea via mangling. So if one has class Magma (a; unit, mult) where unit :: a mult :: a -> a -> a then instances Monoid (a; 0; (+)) Monoid (a; 1; (*)) should logically equivalent to Monoid_0_+ (a) 0 :: a (+) :: a -> a -> a Monoid_1_* (a) 1 :: a (*) :: a -> a -> a or whatever internal mangling that ensures that the names Monoid_0_+ and Monoid_1_* are different. Would this not work? - They code should be essentially a shortcut for defining new classes. Hans From haberg at math.su.se Wed Apr 9 10:48:22 2008 From: haberg at math.su.se (Hans Aberg) Date: Wed Apr 9 10:44:07 2008 Subject: [Haskell-cafe] instance Monad m => Functor m In-Reply-To: References: <93A90667-13CD-4E88-B39B-BD878D24C0F5@math.su.se> <47FC8BB3.5040103@jellybean.co.uk> Message-ID: On 9 Apr 2008, at 16:26, Henning Thielemann wrote: > I think a classical example are number sequences which can be > considered as rings in two ways: > 1. elementwise multiplication > 2. convolution > > and you have some function which invokes the ring multiplication > > f :: Ring a => a -> a > > and a concrete sequence > > x :: Sequence Integer > > what multiplication (elementwise or convolution) shall be used for > computing (f x) ? For that problem to arise, one must have, when defining Sequence class Ring (a; o, e, add, mult) ... class (Ring(a; o, e, add, (*)), Ring(a; o, e, add, (**)) => Sequence a It is a good question, but can be avoided by not admitting such constructs. - I will think a bit more on it. Hans From haberg at math.su.se Wed Apr 9 11:05:20 2008 From: haberg at math.su.se (Hans Aberg) Date: Wed Apr 9 11:00:55 2008 Subject: [Haskell-cafe] instance Monad m => Functor m In-Reply-To: References: <93A90667-13CD-4E88-B39B-BD878D24C0F5@math.su.se> <47FC8BB3.5040103@jellybean.co.uk> Message-ID: <0A14144B-88B1-4BC2-B448-25ED6BEF9611@math.su.se> On 9 Apr 2008, at 16:26, Henning Thielemann wrote: > 1. elementwise multiplication > 2. convolution > > and you have some function which invokes the ring multiplication > > f :: Ring a => a -> a > > and a concrete sequence > > x :: Sequence Integer > > what multiplication (elementwise or convolution) shall be used for > computing (f x) ? In math, if there is a theorem about a ring, and one wants to apply it to an object which more than one ring structure, one needs to indicate which ring to use. So if I translate, then one might get something like class Ring (a; o, e, add, mult) ... ... class Ring(a; o, e, add, (*)) => Sequence.mult a Ring(a; o, e, add, (**) => Sequence.conv a where ... Then Sequence.mult and Sequence.conv will be treated as different types whenever there is a clash using Sequence only. - I am not sure how this fits into Haskell syntax though. This might be useful, if it can be worked out. Hans From bos at serpentine.com Wed Apr 9 11:47:46 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed Apr 9 11:43:21 2008 Subject: [Haskell-cafe] Lock-Free Data Structures using STMs in Haskell In-Reply-To: <871w5fgmsc.fsf@coco.kazmier.com> References: <871w5fgmsc.fsf@coco.kazmier.com> Message-ID: <47FCE522.80508@serpentine.com> Pete Kazmier wrote: > data ArrayBlockingQueueSTM e = ArrayBlockingQueueSTM { > [...] > sa :: Array Int (TVar e) > } > > It's unclear to me why the Array's elements must be wrapped in TVars. To allow them to be modified. You can't otherwise modify the elements of an array without going into the ST monad. > decPair v1 v1 :: TVar Int -> TVar Int -> IO () > decPair v1 v2 = atomically (decT v1 `orElse` decT v2) > > Will this actually compile? I was under the impression that 'orElse' > could only combine STM types, not IO () types. The type of atomically is STM a -> IO a. Functor m In-Reply-To: <0A14144B-88B1-4BC2-B448-25ED6BEF9611@math.su.se> References: <93A90667-13CD-4E88-B39B-BD878D24C0F5@math.su.se> <47FC8BB3.5040103@jellybean.co.uk> <0A14144B-88B1-4BC2-B448-25ED6BEF9611@math.su.se> Message-ID: On Wed, 9 Apr 2008, Hans Aberg wrote: > On 9 Apr 2008, at 16:26, Henning Thielemann wrote: >> 1. elementwise multiplication >> 2. convolution >> >> and you have some function which invokes the ring multiplication >> >> f :: Ring a => a -> a >> >> and a concrete sequence >> >> x :: Sequence Integer >> >> what multiplication (elementwise or convolution) shall be used for >> computing (f x) ? > > In math, if there is a theorem about a ring, and one wants to apply it to an > object which more than one ring structure, one needs to indicate which ring > to use. So if I translate, then one might get something like > class Ring (a; o, e, add, mult) ... > ... > class Ring(a; o, e, add, (*)) => Sequence.mult a > Ring(a; o, e, add, (**) => Sequence.conv a > where ... > Then Sequence.mult and Sequence.conv will be treated as different types > whenever there is a clash using Sequence only. - I am not sure how this fits > into Haskell syntax though. Additionally I see the problem, that we put more interpretation into standard symbols by convention. Programming is not only about the most general formulation of an algorithm but also about error detection. E.g. you cannot compare complex numbers in a natural way, that is x < (y :: Complex Rational) is probably a programming error. However, some people might be happy if (<) is defined by lexicgraphic ordering. This way complex numbers can be used as keys in a Data.Map. But then accidental uses of (<) could no longer be detected. (Thus I voted for a different class for keys to be used in Data.Map, Data.Set et.al.) Also (2*5 == 7) would surprise people, if (*) is the symbol for a general group operation, and we want to use it for the additive group of integers. From haberg at math.su.se Wed Apr 9 12:04:30 2008 From: haberg at math.su.se (Hans Aberg) Date: Wed Apr 9 12:00:06 2008 Subject: [Haskell-cafe] instance Monad m => Functor m In-Reply-To: References: <93A90667-13CD-4E88-B39B-BD878D24C0F5@math.su.se> <47FC8BB3.5040103@jellybean.co.uk> <0A14144B-88B1-4BC2-B448-25ED6BEF9611@math.su.se> Message-ID: On 9 Apr 2008, at 17:49, Henning Thielemann wrote: > Additionally I see the problem, that we put more interpretation > into standard symbols by convention. Programming is not only about > the most general formulation of an algorithm but also about error > detection. E.g. you cannot compare complex numbers in a natural > way, that is > x < (y :: Complex Rational) > is probably a programming error. However, some people might be > happy if (<) is defined by lexicgraphic ordering. This way complex > numbers can be used as keys in a Data.Map. But then accidental uses > of (<) could no longer be detected. (Thus I voted for a different > class for keys to be used in Data.Map, Data.Set et.al.) I think there it might be convenient with a total order defined on all types, for that data-map sorting purpose you indicate. But it would then be different from the semantic order that some types have. So the former should have a different name. Also, one might have Ordering(LT, EQ, GT, Unrelated) so t can be used on all relations. > Also (2*5 == 7) would surprise people, if (*) is the symbol for a > general group operation, and we want to use it for the additive > group of integers. This is in fact as it should be; the idea is to admit such things: class Group(a; unit, inverse, mult) ... class (Group(a; 0, (-), (+)), Monoid(a; 1, (*)) => Ring(a; 0, 1, (-), (+), (*)) ... -- (or better variable names). instance Ring(a; 0, 1, (-), (+), (*)) => Integer A group can be written additively or multiplicatively, (+) is often reserved for commutative operations. But there is not way to express that, unless one can write class AbelianGroup(a; unit, inverse, mult) where ... satisfying mult a b = mult b a One would need pattern matching to Haskell in order to make this useful. Hans From lennart at augustsson.net Wed Apr 9 14:39:18 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Apr 9 14:34:54 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: <47FC75E3.4050902@gmail.com> References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> <47FC75E3.4050902@gmail.com> Message-ID: On Wed, Apr 9, 2008 at 8:53 AM, Martin Sulzmann wrote: > > Lennart, you said > > > (It's also pretty easy to fix the problem.) > > > > What do you mean? Easy to fix the type checker, or easy to fix the program > by inserting annotations > to guide the type checker? > > Martin > I'm referring to the situation where the type inferred by the type checker is illegal for me to put into the program. In our example we can fix this in two ways, by making foo' illegal even when it has no signature, or making foo' legal even when it has a signature. To make it illegal: If foo' has no type signature, infer a type for foo', insert this type as a signature and type check again. If this fails, foo' is illegal. To make it legal: If foo' with a type signature doesn't type check, try to infer a type without a signature. If this succeeds then check that the type that was inferred is alpha-convertible to the original signature. If it is, accept foo'; the signature doesn't add any information. Either of these two option would be much preferable to the current (broken) situation where the inferred signature is illegal. -- Lennart -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080409/5467d786/attachment-0001.htm From haberg at math.su.se Wed Apr 9 14:42:37 2008 From: haberg at math.su.se (Hans Aberg) Date: Wed Apr 9 14:38:13 2008 Subject: [Haskell-cafe] instance Monad m => Functor m In-Reply-To: References: <93A90667-13CD-4E88-B39B-BD878D24C0F5@math.su.se> <47FC8BB3.5040103@jellybean.co.uk> <0A14144B-88B1-4BC2-B448-25ED6BEF9611@math.su.se> Message-ID: On 9 Apr 2008, at 17:49, Henning Thielemann wrote: > Also (2*5 == 7) would surprise people, if (*) is the symbol for a > general group operation, and we want to use it for the additive > group of integers. One might resolve the "Num" binding of (+) problem by putting all operators into an implicit superclass: Roughly, let T be the set of of most general types, and for each t in T define a mangling string s(t). Then if the operator :: t is defined somewhere, it is internally defined as class Operator_s(t)_ t where :: t Then usages of it get implicit class (Operator_s(t)_ t, ...) => where ... and instance Operator_s(t)_ t where ... If I now have another class using (+), it need not be derived from Num, as both usages are derivable from an internal class Operator_(+) The mangling of the type via s(t) might be used to generate C++ style name overloading. It will then depend on how much ambiguity one wants to accept in the context. I do not see exactly how this works with Haskell current syntax; just an input. Hans From valgarv at gmx.net Wed Apr 9 15:23:59 2008 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Wed Apr 9 15:19:36 2008 Subject: [Haskell-cafe] Lock-Free Data Structures using STMs in Haskell In-Reply-To: <47FCE522.80508@serpentine.com> References: <871w5fgmsc.fsf@coco.kazmier.com> <47FCE522.80508@serpentine.com> Message-ID: <200804092223.59821.valgarv@gmx.net> > > decPair v1 v1 :: TVar Int -> TVar Int -> IO () > > decPair v1 v2 = atomically (decT v1 `orElse` decT v2) > > > > Will this actually compile? I was under the impression that 'orElse' > > could only combine STM types, not IO () types. > > The type of atomically is STM a -> IO a. But orElse :: STM a -> STM a -> STM a decT can be of type TVar Int -> STM () if you leave out the atomically. -- Ariel J. Birnbaum From valgarv at gmx.net Wed Apr 9 15:52:15 2008 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Wed Apr 9 15:47:52 2008 Subject: [Haskell-cafe] What's the difference? In-Reply-To: <47FBEAA1.802@imageworks.com> References: <7.0.1.0.0.20080408171921.01cfc1c0@ntlworld.com> <1207682121.6475.58.camel@otto.ehbuehl.net> <47FBEAA1.802@imageworks.com> Message-ID: <200804092252.15369.valgarv@gmx.net> > For me, the word "implies" is too tied in my brain to an arrow symbol to > be useful to me in keeping the implications straight. Pun implied? -- Ariel J. Birnbaum From duncan.coutts at worc.ox.ac.uk Wed Apr 9 16:13:30 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 9 16:09:06 2008 Subject: [Haskell-cafe] problems building hpodder In-Reply-To: <200804081543.23279.jgoerzen@complete.org> References: <20080406222410.GA8408@diana.vm.bytemark.co.uk> <200804072020.25068.jgoerzen@complete.org> <20080408202134.GA14852@diana.vm.bytemark.co.uk> <200804081543.23279.jgoerzen@complete.org> Message-ID: <1207772010.6082.11.camel@dell.linuxdev.us.dell.com> On Tue, 2008-04-08 at 15:43 -0500, John Goerzen wrote: > On Tue April 8 2008 3:21:34 pm Karl Hasselstr?m wrote: > > > http://www.haskell.org/haskellwiki/Package_versioning_policy seems to > > have something relevant to say. build-depends: HaXml >= 1.13.3 && < > > 1.14 ought to do the trick, since any changes in the published > > interface are supposed to be accompanied by a version bump in one of > > the first two numbers. > > That syntax didn't work under testing, but HaXml >= 1.13.2, HaXml < 1.19 did > the trick. Really? That's certainly supposed to work. Can you give more details we can use to reproduce the problem. Duncan From sebastian.sylvan at gmail.com Wed Apr 9 17:09:30 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Wed Apr 9 17:05:03 2008 Subject: [Haskell-cafe] Control.Parallel.Strategies Message-ID: <3d96ac180804091409j5fc59b33i414a5676b95fa0a6@mail.gmail.com> Hi, I was toying with the Control.Parallel.Strategies library, but can't seem to get it to actually do anything in parallel! Here's the code: import System.Random import Control.Parallel.Strategies fib :: Int -> Int fib 0 = 1 fib 1 = 1 fib n = fib (n-1) + fib (n-2) main = print $ parMap rnf fib $ take 80 $ randomRs (30,35) (mkStdGen 123) I compile with "-threaded", and run with +RTS -N2 -RTS, but yet it stays at 50% on my dual core machine! I should point out that any manual threading with forkIO does indeed use 100% of the CPU, and this problem happens on my work computer too (Vista on my home computer, XP on the work one). Anything I'm missing here? Thanks, -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080409/2f4252ad/attachment.htm From jgbailey at gmail.com Wed Apr 9 17:22:34 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Wed Apr 9 17:18:10 2008 Subject: [Haskell-cafe] Control.Parallel.Strategies In-Reply-To: <3d96ac180804091409j5fc59b33i414a5676b95fa0a6@mail.gmail.com> References: <3d96ac180804091409j5fc59b33i414a5676b95fa0a6@mail.gmail.com> Message-ID: 2008/4/9 Sebastian Sylvan : > main = print $ parMap rnf fib $ take 80 $ randomRs (30,35) (mkStdGen 123) Does the strategy "rwhnf" do it for you? Justin From sebastian.sylvan at gmail.com Wed Apr 9 17:25:39 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Wed Apr 9 17:21:13 2008 Subject: [Haskell-cafe] Control.Parallel.Strategies In-Reply-To: References: <3d96ac180804091409j5fc59b33i414a5676b95fa0a6@mail.gmail.com> Message-ID: <3d96ac180804091425n152b84c9scdba015f62d79a05@mail.gmail.com> On Wed, Apr 9, 2008 at 10:22 PM, Justin Bailey wrote: > 2008/4/9 Sebastian Sylvan : > > main = print $ parMap rnf fib $ take 80 $ randomRs (30,35) (mkStdGen > 123) > > Does the strategy "rwhnf" do it for you? > > Justin > Nope! This is GHC 6.8.2 btw, downloaded the binary from the web site, so it's nothing strange. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080409/27da6e66/attachment.htm From jgbailey at gmail.com Wed Apr 9 17:58:21 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Wed Apr 9 17:53:58 2008 Subject: [Haskell-cafe] Control.Parallel.Strategies In-Reply-To: <3d96ac180804091425n152b84c9scdba015f62d79a05@mail.gmail.com> References: <3d96ac180804091409j5fc59b33i414a5676b95fa0a6@mail.gmail.com> <3d96ac180804091425n152b84c9scdba015f62d79a05@mail.gmail.com> Message-ID: On Wed, Apr 9, 2008 at 2:25 PM, Sebastian Sylvan wrote: > Nope! > > This is GHC 6.8.2 btw, downloaded the binary from the web site, so it's > nothing strange. On my hyper-threaded CPU, your original code works fine. With -N2, I see 100% CPU. With N1, only 50%. I am also using GHC 6.8.2. Justin From sebastian.sylvan at gmail.com Wed Apr 9 18:03:26 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Wed Apr 9 17:58:59 2008 Subject: [Haskell-cafe] Control.Parallel.Strategies In-Reply-To: References: <3d96ac180804091409j5fc59b33i414a5676b95fa0a6@mail.gmail.com> <3d96ac180804091425n152b84c9scdba015f62d79a05@mail.gmail.com> Message-ID: <3d96ac180804091503l7a413eey4d28ae54f8a285d8@mail.gmail.com> On Wed, Apr 9, 2008 at 10:58 PM, Justin Bailey wrote: > On Wed, Apr 9, 2008 at 2:25 PM, Sebastian Sylvan > wrote: > > Nope! > > > > This is GHC 6.8.2 btw, downloaded the binary from the web site, so it's > > nothing strange. > > On my hyper-threaded CPU, your original code works fine. With -N2, I > see 100% CPU. With N1, only 50%. I am also using GHC 6.8.2. > > Justin > Hmm, that's curious. I compile with "ghc --make -threaded partest.hs -o par.exe", and then run it with "par.exe +RTS -N2 -RTS". Am I making some silly configuration error? Are you running this on windows? -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080409/5db023fa/attachment.htm From jgbailey at gmail.com Wed Apr 9 18:10:35 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Wed Apr 9 18:06:09 2008 Subject: [Haskell-cafe] Control.Parallel.Strategies In-Reply-To: <3d96ac180804091503l7a413eey4d28ae54f8a285d8@mail.gmail.com> References: <3d96ac180804091409j5fc59b33i414a5676b95fa0a6@mail.gmail.com> <3d96ac180804091425n152b84c9scdba015f62d79a05@mail.gmail.com> <3d96ac180804091503l7a413eey4d28ae54f8a285d8@mail.gmail.com> Message-ID: On Wed, Apr 9, 2008 at 3:03 PM, Sebastian Sylvan wrote: > Hmm, that's curious. I compile with "ghc --make -threaded partest.hs -o > par.exe", and then run it with "par.exe +RTS -N2 -RTS". Am I making some > silly configuration error? > Are you running this on windows? Yep, that's the command line I used and I am running XP. Justin From pete-expires-20080608 at kazmier.com Wed Apr 9 20:52:26 2008 From: pete-expires-20080608 at kazmier.com (Pete Kazmier) Date: Wed Apr 9 20:48:14 2008 Subject: [Haskell-cafe] Re: Lock-Free Data Structures using STMs in Haskell References: <871w5fgmsc.fsf@coco.kazmier.com> <47FCE522.80508@serpentine.com> Message-ID: <87r6defs51.fsf@coco.kazmier.com> Bryan O'Sullivan writes: > Pete Kazmier wrote: > >> data ArrayBlockingQueueSTM e = ArrayBlockingQueueSTM { >> [...] >> sa :: Array Int (TVar e) >> } >> >> It's unclear to me why the Array's elements must be wrapped in TVars. > > To allow them to be modified. You can't otherwise modify the elements > of an array without going into the ST monad. Thanks! I forgot about the whole immutable thing :-) Haven't used arrays yet while learning Haskell! From jackmarathon at gmail.com Wed Apr 9 22:05:05 2008 From: jackmarathon at gmail.com (Jackm139) Date: Wed Apr 9 22:00:37 2008 Subject: [Haskell-cafe] Pattern match failure Message-ID: <16600643.post@talk.nabble.com> I'm trying to write a function to recognize a context free grammar, but I keep getting pattern match failure errors. This is what I have: data Grammar c = Brule c c c | Rule c c gez = [(Brule 'S' 'p' 'D'),(Brule 'D' 't' 'E'),(Rule 'E' 'j')] recog :: String -> String -> [Grammar Char] -> Bool recog a b list = case list of [Brule x y z] -> if a == [x] then recog [z] b list else recog a b list [Rule x y] -> True how can I solve this pattern matching error? -- View this message in context: http://www.nabble.com/Pattern-match-failure-tp16600643p16600643.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From lrpalmer at gmail.com Wed Apr 9 22:19:08 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Wed Apr 9 22:14:40 2008 Subject: [Haskell-cafe] Pattern match failure In-Reply-To: <16600643.post@talk.nabble.com> References: <16600643.post@talk.nabble.com> Message-ID: <7ca3f0160804091919y28554c24sf11492983036ac12@mail.gmail.com> On Thu, Apr 10, 2008 at 2:05 AM, Jackm139 wrote: > I'm trying to write a function to recognize a context free grammar, but I > keep getting pattern match failure errors. This is what I have: > > data Grammar c = Brule c c c | Rule c c > > gez = [(Brule 'S' 'p' 'D'),(Brule 'D' 't' 'E'),(Rule 'E' 'j')] > > recog :: String -> String -> [Grammar Char] -> Bool > recog a b list = case list of > [Brule x y z] -> if a == [x] then recog [z] b list else recog a b list > [Rule x y] -> True I am stumped as to what this function is trying to do. But your pattern matches are not total; in particular you only handle lists of a single element. I suggest either: recog a b list = case list of (Brule x y z : rules) -> ... (involving 'rules') (Rule x y : rules) -> ... (involving 'rules') [] -> ... (case for the empty list) Or: recog a b (rule:rules) = case rule of Brule x y z -> ... Rule x y -> ... recog a b [] = ... But the point is that you have to say how to handle lists of more thn one element. Luke From daniel.is.fischer at web.de Wed Apr 9 22:31:17 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Apr 9 22:25:10 2008 Subject: [Haskell-cafe] Pattern match failure In-Reply-To: <16600643.post@talk.nabble.com> References: <16600643.post@talk.nabble.com> Message-ID: <200804100431.17906.daniel.is.fischer@web.de> Am Donnerstag, 10. April 2008 04:05 schrieb Jackm139: > I'm trying to write a function to recognize a context free grammar, but I > keep getting pattern match failure errors. This is what I have: > > data Grammar c = Brule c c c | Rule c c > > gez = [(Brule 'S' 'p' 'D'),(Brule 'D' 't' 'E'),(Rule 'E' 'j')] > > recog :: String -> String -> [Grammar Char] -> Bool > recog a b list = case list of > [Brule x y z] -> if a == [x] then recog [z] b list else recog a b list > [Rule x y] -> True > > > how can I solve this pattern matching error? By including cases for 1. empty lists 2. lists with more than one element. You probably want something like recog a b list = case list of (Brule x y z:rest) -> whatever (Rule x y:rest) -> something_else [] -> True Besides, the "else recog a b list" is a nice infinite loop. From chak at cse.unsw.edu.au Wed Apr 9 22:47:15 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Apr 9 22:45:02 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: <007901c89a25$ebc876f0$e9217ad5@cr3lt> References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> <007901c89a25$ebc876f0$e9217ad5@cr3lt> Message-ID: Claus Reinke: >> type family Id a >> type instance Id Int = Int >> >> foo :: Id a -> Id a >> foo = id n >> foo' :: Id a -> Id a >> foo' = foo > > type function notation is slightly misleading, as it presents > qualified polymorphic types in a form usually reserved for > unqualified polymorphic types. > > rewriting foo's type helped me to see the ambiguity that > others have pointed out: > > foo :: r ~ Id a => r -> r > > there's nowhere to get the 'a' from. so unless 'Id' itself is > fully polymorphic in 'a' (Id a = a, Id a = Int, ..), 'foo' can't > really be used. for each type variable, there needs to be > at least one position where it is not used as a type family > parameter. Yes. It is generally so that the introduction of indexed types (ie, all of GADTs, data type families, or synonym families) means that a type with a parameter is not necessarily parametric. > it might be useful to issue an ambiguity warning for such types? The problem is that testing for ambiguity is, in general, difficult. Whether a context is ambiguous depends for example on the currently visible class instances. As a result, a signature that is ambiguous in a module M, may be fine in a module N that imports M. However, I think what should be easier is to improve the error messages given when a function with an ambiguous signature is used. For example, if the error message in the definition of foo' would have included a hint saying that the definition is illegal because its right hand side contains the use of a function with an ambiguous signature, then Ganesh may have had an easier time seeing what's happening. > ps. i find these examples and discussions helpful, if often initially > puzzling - they help to clear up weak spots in the practice > of type family use, understanding, and implementation, > thereby improving all while making families more familiar!-) Absolutely! Manuel From chak at cse.unsw.edu.au Wed Apr 9 23:20:55 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Apr 9 23:16:37 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> <47FC75E3.4050902@gmail.com> Message-ID: <45C322C6-E01C-4867-9D2F-3FEA89C196C7@cse.unsw.edu.au> Lennart Augustsson: > On Wed, Apr 9, 2008 at 8:53 AM, Martin Sulzmann > wrote: > > Lennart, you said > > (It's also pretty easy to fix the problem.) > > What do you mean? Easy to fix the type checker, or easy to fix the > program by inserting annotations > to guide the type checker? > > Martin > > I'm referring to the situation where the type inferred by the type > checker is illegal for me to put into the program. > In our example we can fix this in two ways, by making foo' illegal > even when it has no signature, or making foo' legal even when it has > a signature. > > To make it illegal: If foo' has no type signature, infer a type for > foo', insert this type as a signature and type check again. If this > fails, foo' is illegal. That would be possible, but it means we have to do this for all bindings in a program (also all lets bindings etc). > To make it legal: If foo' with a type signature doesn't type check, > try to infer a type without a signature. If this succeeds then > check that the type that was inferred is alpha-convertible to the > original signature. If it is, accept foo'; the signature doesn't > add any information. This harder, if not impossible. What does it mean for two signatures to be "alpha-convertible"? I assume, you intend that given type S a = Int the five signatures forall a. S a forall b. S b forall a b. S (a, b) Int S Int are all the "alpha-convertible". Now, given type family F a b type instance F Int c = Int what about forall a. F a Int forall a. F Int Int forall a. F Int a forall a b. (a ~ Int) => F a b So, I guess, you don't really mean alpha-convertible in its original syntactic sense. We should accept the definition if the inferred and the given signature are in some sense "equivalent". For this "equivalence" to be robust, I am sure we need to define it as follows, where <= is standard type subsumption: t1 "equivalent" t2 iff t1 <= t2 and t2 <= t1 However, the fact that we cannot decide type subsumption for ambiguous types is exactly what led us to the original problem. So, nothing has been won. Summary ~~~~~~~ Trying to make those definitions that are currently only legal *without* a signature also legal when the inferred signature is added (foo' in Ganesh's example) doesn't seem workable. However, to generally reject the same definitions, even if they are presented without a signature, seems workable. It does require the compiler to compute type annotations, and then, check that it can still accept the annotated program. This makes the process of type checking together with annotating the checked program idempotent, which is nice. Manuel From chak at cse.unsw.edu.au Thu Apr 10 00:32:28 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Apr 10 00:28:04 2008 Subject: [Haskell-cafe] Re: type families and type signatures In-Reply-To: References: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> Message-ID: <57B43512-1E56-44E2-8410-1DD101941B17@cse.unsw.edu.au> apfelmus: > Manuel M T Chakravarty wrote: >> apfelmus: >>> Manuel M T Chakravarty wrote: >>>> Let's alpha-rename the signatures and use explicit foralls for >>>> clarity: >>>> foo :: forall a. Id a -> Id a >>>> foo' :: forall b. Id b -> Id b >>>> GHC will try to match (Id a) against (Id b). As Id is a type >>>> synonym family, it would *not* be valid to derive (a ~ b) from >>>> this. After all, Id could have the same result for different >>>> argument types. (That's not the case for your one instance, but >>>> maybe in another module, there are additional instances for Id, >>>> where that is the case.) >>> >>> While in general (Id a ~ Id b) -/-> (a ~ b) , parametricity >>> makes it "true" in the case of foo . For instance, let Id a ~ >>> Int . Then, the signature specializes to foo :: Int -> Int . But >>> due to parametricity, foo does not care at all what a is and >>> will be the very same function for every a with Id a ~ Int . In >>> other words, it's as if the type variable a is not in scope in >>> the definition of foo . >> Be careful, Id is a type-indexed type family and *not* a parametric >> type. Parametricity does not apply. For more details about the >> situation with GADTs alone, see >> Foundations for Structured Programming with GADTs. Patricia Johann >> and Neil Ghani. Proceedings, Principles of Programming Languages >> 2008 (POPL'08). > > Yes and no. In the GADT case, a function like > > bar :: forall a . GADT a -> String > > is clearly not "parametric" in a, in the sense that pattern matching > on the GADT can specialize a which means that we have some form of > "pattern matching" on the type a . The resulting String may depend > on the type a . So, by "parametricity", I mean "type arguments may > not be inspected". [..] > However, I have this feeling that > > bar :: forall a . Id a -> String > > with a type family Id *is* parametric in the sense that no matter > what a is, the result always has to be the same. Intuitively, > that's because we may not "pattern match on the branch" of a > definition like > > type instance Id String = .. > type instance Id Int = .. > .. > > So, in the special case of foo and foo' , solving Id b ~ Id a > by guessing a ~ b is safe since foo is parametric in a . We don't know that. We could have type instance Id [a] = GADT a Just looking at the signature, we don't know. Manuel From chak at cse.unsw.edu.au Thu Apr 10 00:52:10 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Apr 10 00:47:53 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> Message-ID: Lennart Augustsson: > Let's look at this example from a higher level. > > Haskell is a language which allows you to write type signatures for > functions, and even encourages you to do it. > Sometimes you even have to do it. Any language feature that stops > me from writing a type signature is in my opinion broken. > TFs as implemented in currently implemented ghc stops me from > writing type signatures. They are thus, in my opinion, broken. The problem of ambiguity is not at all restricted to TFs. In fact, you need neither TFs nor FDs to get the exact same behaviour. You don't even need MPTCs: > {-# LANGUAGE FlexibleContexts #-} > module Ambiguity where > > class C a > > bar :: C (a, b) => b -> b > bar = id > > bar' :: C (a, b) => b -> b > bar' = bar > This gives us > /Users/chak/Code/haskell/Ambiguity.hs:10:7: > Could not deduce (C (a, b)) from the context (C (a1, b)) > arising from a use of `bar' > at /Users/chak/Code/haskell/Ambiguity.hs:10:7-9 > Possible fix: > add (C (a, b)) to the context of the type signature for `bar'' > or add an instance declaration for (C (a, b)) > In the expression: bar > In the definition of `bar'': bar' = bar So, we have this problem as soon as we have flexible contexts and/or MPTCs, independent of TFs and FDs. Manuel From ajb at spamcop.net Thu Apr 10 01:50:02 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Thu Apr 10 01:45:34 2008 Subject: [Haskell-cafe] instance Monad m => Functor m In-Reply-To: <47FC8BB3.5040103@jellybean.co.uk> References: <93A90667-13CD-4E88-B39B-BD878D24C0F5@math.su.se> <47FC8BB3.5040103@jellybean.co.uk> Message-ID: <20080410015002.wi81geof4g00c8wo@webmail.spamcop.net> G'day all. Quoting Jules Bean : > Other solutions, such as class Functor m => Monad m are frequently discussed. > > I see no H' ticket for it, though. Then add it. :-) You'll probably want to make it depend on Ticket #101, because making class hierarchies more granular generally depends on flexible instances. Cheers, Andrew Bromage From lennart at augustsson.net Thu Apr 10 02:58:44 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Apr 10 02:54:16 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: <45C322C6-E01C-4867-9D2F-3FEA89C196C7@cse.unsw.edu.au> References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> <47FC75E3.4050902@gmail.com> <45C322C6-E01C-4867-9D2F-3FEA89C196C7@cse.unsw.edu.au> Message-ID: On Thu, Apr 10, 2008 at 4:20 AM, Manuel M T Chakravarty < chak@cse.unsw.edu.au> wrote: > the five signatures > > forall a. S a > forall b. S b > forall a b. S (a, b) > Int > S Int > By alpha-convertible I mean the usual thing from lambda calculus, they are identical modulo the names of bound variables. So only the first two are alpha-convertible to each other. If you involve any kind of reduction the equivalence test is no longer trivial. All I'm asking for really, is to be able to paste in the type that was inferred as the signature, without the compiler complaining. -- Lennart -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080410/1bc04223/attachment.htm From lennart at augustsson.net Thu Apr 10 03:03:18 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Apr 10 02:58:50 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> Message-ID: I didn't say TF was the only broken feature in GHC. But I want to see the broken ones removed, instead of new ones added. :) In the current GHC there are even definitions that are perfecty usable, that cannot be given the type signature that that was inferred. At work we have the warning for missing signatures enabled, and we turn warnings into errors. We have to disbale this for certain definitions, because you cannot give them a signature. I find that broken. -- Lennart On Thu, Apr 10, 2008 at 5:52 AM, Manuel M T Chakravarty < chak@cse.unsw.edu.au> wrote: > Lennart Augustsson: > > > Let's look at this example from a higher level. > > > > Haskell is a language which allows you to write type signatures for > > functions, and even encourages you to do it. > > Sometimes you even have to do it. Any language feature that stops me > > from writing a type signature is in my opinion broken. > > TFs as implemented in currently implemented ghc stops me from writing > > type signatures. They are thus, in my opinion, broken. > > > > The problem of ambiguity is not at all restricted to TFs. In fact, you > need neither TFs nor FDs to get the exact same behaviour. You don't even > need MPTCs: > > {-# LANGUAGE FlexibleContexts #-} > > module Ambiguity where > > > > class C a > > > > bar :: C (a, b) => b -> b > > bar = id > > > > bar' :: C (a, b) => b -> b > > bar' = bar > > > > > > This gives us > > /Users/chak/Code/haskell/Ambiguity.hs:10:7: > > Could not deduce (C (a, b)) from the context (C (a1, b)) > > arising from a use of `bar' > > at /Users/chak/Code/haskell/Ambiguity.hs:10:7-9 > > Possible fix: > > add (C (a, b)) to the context of the type signature for `bar'' > > or add an instance declaration for (C (a, b)) > > In the expression: bar > > In the definition of `bar'': bar' = bar > > > > > So, we have this problem as soon as we have flexible contexts and/or > MPTCs, independent of TFs and FDs. > > Manuel > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080410/cc430357/attachment.htm From lennart at augustsson.net Thu Apr 10 03:21:02 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Apr 10 03:16:34 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: <45C322C6-E01C-4867-9D2F-3FEA89C196C7@cse.unsw.edu.au> References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> <47FC75E3.4050902@gmail.com> <45C322C6-E01C-4867-9D2F-3FEA89C196C7@cse.unsw.edu.au> Message-ID: On Thu, Apr 10, 2008 at 4:20 AM, Manuel M T Chakravarty < chak@cse.unsw.edu.au> wrote: > Lennart Augustsson: > > > On Wed, Apr 9, 2008 at 8:53 AM, Martin Sulzmann < > > martin.sulzmann@gmail.com> wrote: > > > > Lennart, you said > > > > (It's also pretty easy to fix the problem.) > > > > What do you mean? Easy to fix the type checker, or easy to fix the > > program by inserting annotations > > to guide the type checker? > > > > Martin > > > > I'm referring to the situation where the type inferred by the type > > checker is illegal for me to put into the program. > > In our example we can fix this in two ways, by making foo' illegal even > > when it has no signature, or making foo' legal even when it has a signature. > > > > To make it illegal: If foo' has no type signature, infer a type for > > foo', insert this type as a signature and type check again. If this fails, > > foo' is illegal. > > > > That would be possible, but it means we have to do this for all bindings > in a program (also all lets bindings etc). > Of course, but I'd rather the compiler did it than I. It's not that hard, btw. If the whole module type checks, insert all signatures and type check again. Making it legal might be cheaper, though. -- Lennart -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080410/51f687ff/attachment.htm From claus.reinke at talk21.com Thu Apr 10 05:27:38 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Apr 10 05:23:21 2008 Subject: [Haskell-cafe] type families and type signatures References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk><41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au><47FC6045.1040800@gmail.com><47FC75E3.4050902@gmail.com> <45C322C6-E01C-4867-9D2F-3FEA89C196C7@cse.unsw.edu.au> Message-ID: <004d01c89aed$219049d0$b4118351@cr3lt> >> To make it legal: If foo' with a type signature doesn't type check, >> try to infer a type without a signature. If this succeeds then >> check that the type that was inferred is alpha-convertible to the >> original signature. If it is, accept foo'; the signature doesn't >> add any information. > > This harder, if not impossible. What does it mean for two signatures > to be "alpha-convertible"? > > ..[type synonym expansion vs type synonym family reduction] > > So, I guess, you don't really mean alpha-convertible in its original > syntactic sense. We should accept the definition if the inferred and > the given signature are in some sense "equivalent". For this > "equivalence" to be robust, I am sure we need to define it as follows, > where <= is standard type subsumption: > > t1 "equivalent" t2 iff t1 <= t2 and t2 <= t1 i would like to express my doubts about this assumption (which relates directly to the earlier discussion about subsumption). no matter what subsumption or what semantic equivalence we are talking about, we expect it to *include* syntactic identity (reflexivity of the relations): forall t: t <= t forall t: t ~ t moving some equational theory into the "syntactic" equivalence does not imply that syntactic has to be the full semantic equivalence - as the example of alpha- vs beta+alpha- convertibility in lambda calculus demonstrates, it is convenient to be able to ignore some representational issues when talking about "identical" terms in the greater theory. it would help to do the same here, and distinguish between a syntactic and a semantic equivalence of types, where the latter includes and extends the former: syntactic: alpha-conversion, permutation of contexts, probably type synonym expansion (because they are treated as syntactic macros, outside the theory) semantic: type family reduction, .. i'm tempted to the conclusion that the inability of the current system to check its inferred signatures means that reflexivity (of type subsumption/equivalence) is violated: if two types are the same, they should be equivalent and subsume each other. i can't see how the theory can work without this? > However, the fact that we cannot decide type subsumption > for ambiguous types is exactly what led us to the original > problem. So, nothing has been won. imho, the trick is to separate syntactic and semantic equivalence, even if we include some "modulo theory" in the former. both <= and ~ need to include this syntactic equivalence. but syntactic equivalence should remain straightforward to check - nothing should be included in it that isn't easily checkable. claus ps i hope it is obvious that i'd like infered signatures to be checkable, not non-checkable signatures to be rejected?-) From voigt at tcs.inf.tu-dresden.de Thu Apr 10 05:35:32 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Thu Apr 10 05:31:04 2008 Subject: [Haskell-cafe] PhD or PostDoc opening in Dresden, Germany Message-ID: <47FDDF64.5020105@tcs.inf.tu-dresden.de> There is a research position on offer in the project described at: http://wwwtcs.inf.tu-dresden.de/~voigt/project/ The official job advertisement (in German) can be found at: http://www.verw.tu-dresden.de/StellAus/einzelstelle.asp?id=783 The most important details are: - full-time faculty position - payment according to German public sector scale E 13 TV-L Ost (gross monthly salary expected to start around 2680 Euro) - no teaching duties - initial appointment for up to 30 months - no knowledge of German required (but English is) Please contact me directly with any further questions. Please also forward to potentially interested students. The closing date for applications is 15th May 2008. Best wishes, Janis Voigtlaender -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From vigalchin at gmail.com Thu Apr 10 10:12:45 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Apr 10 10:08:16 2008 Subject: [Haskell-cafe] Haskell library install question Message-ID: <5ae4f2ba0804100712p55dceb99y5054cb57fc440747@mail.gmail.com> Hello, I have configured, built and installed a library. When I "runhaskell Setup.hs install", I noticed the message Registering unix-2.2.0.0... In what sense is it being registered? Can I query this registry information? Thanks, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080410/19752193/attachment.htm From bulat.ziganshin at gmail.com Thu Apr 10 10:18:07 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Apr 10 10:18:31 2008 Subject: [Haskell-cafe] Haskell library install question In-Reply-To: <5ae4f2ba0804100712p55dceb99y5054cb57fc440747@mail.gmail.com> References: <5ae4f2ba0804100712p55dceb99y5054cb57fc440747@mail.gmail.com> Message-ID: <981736824.20080410181807@gmail.com> Hello Vasili, Thursday, April 10, 2008, 6:12:45 PM, you wrote: > Registering unix-2.2.0.0... > In what sense is it being registered? Can I query this registry information? ghc-pkg -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From adam.smyczek at gmail.com Thu Apr 10 10:50:16 2008 From: adam.smyczek at gmail.com (Adam Smyczek) Date: Thu Apr 10 10:46:09 2008 Subject: [Haskell-cafe] Fighting the monad stack, MonadIO Message-ID: <55F5F9E8-6DDC-46B5-B1FC-F3F9FA542DE9@gmail.com> For a small webapi binding I try to implement a session like monad by building a stack including BrowserAction from Network.Browser module as following: newtype RBAction a = RBAction { exec :: ErrorT String (StateT RBState BrowserAction) a } deriving (Functor, Monad, MonadState RBState) I would like the RBAction to implement MonadIO as well, but fight with the liftIO function for hours now, without success. Any idea how the implementation of liftIO could look like? Thanks for help, Adam From cetin.sert at gmail.com Thu Apr 10 12:27:12 2008 From: cetin.sert at gmail.com (Cetin Sert) Date: Thu Apr 10 12:22:46 2008 Subject: [Haskell-cafe] ghc Message-ID: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> Hi, Is GHC required to be installed on the target OS I compile Haskell binaries for in order for these binaries to run? I need a quick answer on that! By the way there is no computer in the 4 or so networks I have online access to on which ghc is not installed, which might be a sign people like haskell here in Heidelberg/Mannheim, Germany. Best Regards, Cetin Sert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080410/807e223e/attachment-0001.htm From sebastian.sylvan at gmail.com Thu Apr 10 12:35:44 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Thu Apr 10 12:31:24 2008 Subject: [Haskell-cafe] Control.Parallel.Strategies In-Reply-To: References: <3d96ac180804091409j5fc59b33i414a5676b95fa0a6@mail.gmail.com> <3d96ac180804091425n152b84c9scdba015f62d79a05@mail.gmail.com> <3d96ac180804091503l7a413eey4d28ae54f8a285d8@mail.gmail.com> Message-ID: <3d96ac180804100935g6410c297lef269efb7221c215@mail.gmail.com> On Wed, Apr 9, 2008 at 11:10 PM, Justin Bailey wrote: > On Wed, Apr 9, 2008 at 3:03 PM, Sebastian Sylvan > wrote: > > Hmm, that's curious. I compile with "ghc --make -threaded partest.hs -o > > par.exe", and then run it with "par.exe +RTS -N2 -RTS". Am I making some > > silly configuration error? > > Are you running this on windows? > > Yep, that's the command line I used and I am running XP. > > Justin > That is indeed weird. The only difference seems to be that you have hyperthreading, whereas I have dual cores. But as I mentioned, manual parallelism works (using forkIO)... -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080410/087327b9/attachment.htm From vigalchin at gmail.com Thu Apr 10 13:01:53 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Apr 10 12:57:31 2008 Subject: [Haskell-cafe] Haskell library install question In-Reply-To: <981736824.20080410181807@gmail.com> References: <5ae4f2ba0804100712p55dceb99y5054cb57fc440747@mail.gmail.com> <981736824.20080410181807@gmail.com> Message-ID: <5ae4f2ba0804101001j4678a770g63024db33b320a95@mail.gmail.com> Thanks, Bulat. On Thu, Apr 10, 2008 at 9:18 AM, Bulat Ziganshin wrote: > Hello Vasili, > > Thursday, April 10, 2008, 6:12:45 PM, you wrote: > > Registering unix-2.2.0.0... > > In what sense is it being registered? Can I query this registry > information? > > ghc-pkg > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080410/af6189ef/attachment.htm From ryani.spam at gmail.com Thu Apr 10 13:09:01 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Apr 10 13:04:34 2008 Subject: [Haskell-cafe] Fighting the monad stack, MonadIO In-Reply-To: <55F5F9E8-6DDC-46B5-B1FC-F3F9FA542DE9@gmail.com> References: <55F5F9E8-6DDC-46B5-B1FC-F3F9FA542DE9@gmail.com> Message-ID: <2f9b2d30804101009p4a8b0f50r93dd8ed0ed96bd1d@mail.gmail.com> Assuming you have "ioAction :: IO x -> BrowserAction x" (from http://homepages.paradise.net.nz/warrickg/haskell/http/#browser) you can do: > instance MonadIO BrowserAction where liftIO = ioAction Then you can derive MonadIO with GHC's newtype deriving. Alternatively, you can implement it directly on your type: > instance MonadIO RBAction where > liftIO = RBAction . lift . lift . ioAction This just inserts the proper number of "lift"s to bring the BrowserAction through your monad transformer stack, and then wraps it with your newtype constructor. On Thu, Apr 10, 2008 at 7:50 AM, Adam Smyczek wrote: > For a small webapi binding I try to implement a session like monad > by building a stack including BrowserAction from Network.Browser > module as following: > > newtype RBAction a = RBAction > { exec :: ErrorT String (StateT RBState BrowserAction) a } > deriving (Functor, Monad, MonadState RBState) > > I would like the RBAction to implement MonadIO as well, > but fight with the liftIO function for hours now, without success. > Any idea how the implementation of liftIO could look like? > > Thanks for help, > Adam > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From matt at asklater.com Thu Apr 10 13:20:49 2008 From: matt at asklater.com (Matt Amos) Date: Thu Apr 10 13:17:10 2008 Subject: [Haskell-cafe] Longest increasing subsequence Message-ID: <200804101820.49647.matt@asklater.com> I'm trying to break out of my imperative mind-set by learning Haskell in small snippets. After a few successes I've hit a bit of a roadblock with one of the classic dynamic programming problems, the longest increasing subsequence: http://en.wikipedia.org/wiki/Longest_increasing_subsequence The most efficient algorithm relies on destructive updates, so a simple translation doesn't seem possible. I've been trying to think of a way of removing the need for destructive updates while keeping the efficiency, but so far without much luck. Ideally, I'd like to avoid threading the whole thing with a state monad, since then it would just be an imperative algorithm in disguise. Any suggestions would be very gratefully appreciated. Cheers, Matt From haberg at math.su.se Thu Apr 10 13:28:02 2008 From: haberg at math.su.se (Hans Aberg) Date: Thu Apr 10 13:23:39 2008 Subject: [Haskell-cafe] instance Monad m => Functor m In-Reply-To: References: <93A90667-13CD-4E88-B39B-BD878D24C0F5@math.su.se> <47FC8BB3.5040103@jellybean.co.uk> <0A14144B-88B1-4BC2-B448-25ED6BEF9611@math.su.se> Message-ID: <1B189A5B-38BE-4D86-A300-F54FB92B9024@math.su.se> On 9 Apr 2008, at 17:49, Henning Thielemann wrote: > Additionally I see the problem, that we put more interpretation > into standard symbols by convention. Programming is not only about > the most general formulation of an algorithm but also about error > detection. E.g. you cannot compare complex numbers in a natural > way, that is > x < (y :: Complex Rational) > is probably a programming error. However, some people might be > happy if (<) is defined by lexicgraphic ordering. This way complex > numbers can be used as keys in a Data.Map. But then accidental uses > of (<) could no longer be detected. (Thus I voted for a different > class for keys to be used in Data.Map, Data.Set et.al.) If one just needs to compare equal and unequal elements, then a hash- map is faster than a balanced tree map, and a total order is not needed. So those that want to use complex numbers as keys perhaps have not considered that possibility. And if one considers a total order (<) for all data types, then if that includes functions, then it may happen that two equal functions f, g satisfy f < g. So it would not have the expected semantic properties. Hans From aslatter at gmail.com Thu Apr 10 13:44:32 2008 From: aslatter at gmail.com (Antoine Latter) Date: Thu Apr 10 13:40:09 2008 Subject: [Haskell-cafe] Fighting the monad stack, MonadIO In-Reply-To: <55F5F9E8-6DDC-46B5-B1FC-F3F9FA542DE9@gmail.com> References: <55F5F9E8-6DDC-46B5-B1FC-F3F9FA542DE9@gmail.com> Message-ID: <694519c50804101044t583c16das1c7fd42fcc206c45@mail.gmail.com> On Thu, Apr 10, 2008 at 9:50 AM, Adam Smyczek wrote: > For a small webapi binding I try to implement a session like monad > by building a stack including BrowserAction from Network.Browser > module as following: > > newtype RBAction a = RBAction > { exec :: ErrorT String (StateT RBState BrowserAction) a } > deriving (Functor, Monad, MonadState RBState) > > I would like the RBAction to implement MonadIO as well, > but fight with the liftIO function for hours now, without success. > Any idea how the implementation of liftIO could look like? > Adam, The following worked for me: +++++ {-# LANGUAGE GeneralizedNewtypeDeriving #-} import Control.Monad.Trans import Control.Monad.State import Control.Monad.Error type BrowserAction = IO -- or something else which is in MondaIO data RBState = RBState newtype RBAction a = RBAction { exec :: ErrorT String (StateT RBState BrowserAction) a } deriving (Functor, Monad, MonadState RBState) instance MonadIO RBAction where liftIO = RBAction . liftIO +++++ Because everything inside the newtype wrapper already supports MondIO, you just need to call the version of liftIO underneath the newtype wrapper. Is that clear at all? -Antoine From aslatter at gmail.com Thu Apr 10 13:47:57 2008 From: aslatter at gmail.com (Antoine Latter) Date: Thu Apr 10 13:43:31 2008 Subject: [Haskell-cafe] Fighting the monad stack, MonadIO In-Reply-To: <694519c50804101044t583c16das1c7fd42fcc206c45@mail.gmail.com> References: <55F5F9E8-6DDC-46B5-B1FC-F3F9FA542DE9@gmail.com> <694519c50804101044t583c16das1c7fd42fcc206c45@mail.gmail.com> Message-ID: <694519c50804101047x6caf09b7h17aa21c2bd4cb28f@mail.gmail.com> On Thu, Apr 10, 2008 at 12:44 PM, Antoine Latter wrote: > {-# LANGUAGE GeneralizedNewtypeDeriving #-} > > import Control.Monad.Trans > import Control.Monad.State > import Control.Monad.Error > > type BrowserAction = IO -- or something else which is in MondaIO > data RBState = RBState > > > newtype RBAction a = RBAction > { exec :: ErrorT String (StateT RBState BrowserAction) a } > deriving (Functor, Monad, MonadState RBState, MonadIO) D'oh! Deriving MonadIO for the newtype should work, so long as BrowserAction is in the MonadIO class. -Antoine From judah.jacobson at gmail.com Thu Apr 10 14:02:26 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Thu Apr 10 13:57:58 2008 Subject: [Haskell-cafe] Fighting the monad stack, MonadIO In-Reply-To: <55F5F9E8-6DDC-46B5-B1FC-F3F9FA542DE9@gmail.com> References: <55F5F9E8-6DDC-46B5-B1FC-F3F9FA542DE9@gmail.com> Message-ID: <6d74b0d20804101102l4b7af03dp925c8812227b7936@mail.gmail.com> On Thu, Apr 10, 2008 at 7:50 AM, Adam Smyczek wrote: > For a small webapi binding I try to implement a session like monad > by building a stack including BrowserAction from Network.Browser > module as following: > > newtype RBAction a = RBAction > { exec :: ErrorT String (StateT RBState BrowserAction) a } > deriving (Functor, Monad, MonadState RBState) > > I would like the RBAction to implement MonadIO as well, > but fight with the liftIO function for hours now, without success. > Any idea how the implementation of liftIO could look like? In order to make a stack of monads an instance of MonadIO, you need to be able to run IO actions in the innermost monad (BrowserAction). Ideally, that monad itself would be an instance of MonadIO; maybe the authors of HTTP didn't do so because it would add a dependency on the mtl package (which defines the MonadIO class). Luckily, though, Network.Browser provides ioAction :: IO a -> BrowserAction a which is exactly what you need to write the MonadIO instances yourself. -- Solution #1 -- > instance MonadIO BrowserAction where > liftIO = ioAction Then you can add MonadIO to the deriving clause for RBAction. -- Solution #2 -- > instance MonadIO RBAction where > liftIO = RBAction . lift . lift . ioAction This pulls IO actions manually through the stack of transformers. It might be better because if the HTTP package ever provided its own instance of MonadIO BrowserAction, that would conflict with #1. Hope that helps, -Judah From philip.weaver at gmail.com Thu Apr 10 14:15:38 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Thu Apr 10 14:11:10 2008 Subject: [Haskell-cafe] ghc In-Reply-To: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> References: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> Message-ID: 2008/4/10 Cetin Sert : > Hi, > > Is GHC required to be installed on the target OS I compile Haskell binaries > for in order for these binaries to run? I need a quick answer on that! > If I parse your question correctly, the answer is no, you do not need GHC installed to run the binaries, only to compile them. > By the way there is no computer in the 4 or so networks I have online access > to on which ghc is not installed, which might be a sign people like haskell > here in Heidelberg/Mannheim, Germany. > > Best Regards, > Cetin Sert > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From byorgey at gmail.com Thu Apr 10 14:20:40 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Thu Apr 10 14:16:12 2008 Subject: [Haskell-cafe] ghc In-Reply-To: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> References: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> Message-ID: <22fcbd520804101120r4782ec34y58e9ca5fde21ff0@mail.gmail.com> > Is GHC required to be installed on the target OS I compile Haskell > binaries for in order for these binaries to run? I need a quick answer on > that! Nope! As long as they're compiled for the right architecture, GHC-produced binaries should run anywhere, whether GHC is there or not. This is true for any compiler that produces native binaries (as opposed to certain languages which require a virtual machine...) > By the way there is no computer in the 4 or so networks I have online > access to on which ghc is not installed, which might be a sign people like haskell here in Heidelberg/Mannheim, Germany. > Cool! =) It's probably also a sign of the great work various people have done packaging GHC for various package systems. -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080410/291a679e/attachment.htm From allbery at ece.cmu.edu Thu Apr 10 14:41:10 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Apr 10 14:36:45 2008 Subject: [Haskell-cafe] ghc In-Reply-To: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> References: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> Message-ID: On Apr 10, 2008, at 12:27 , Cetin Sert wrote: > Is GHC required to be installed on the target OS I compile Haskell > binaries for in order for these binaries to run? I need a quick > answer on that! ghc doesn't currently create shared objects, so no. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From adam.smyczek at gmail.com Thu Apr 10 14:53:06 2008 From: adam.smyczek at gmail.com (Adam Smyczek) Date: Thu Apr 10 14:48:51 2008 Subject: [Haskell-cafe] Fighting the monad stack, MonadIO In-Reply-To: <6d74b0d20804101102l4b7af03dp925c8812227b7936@mail.gmail.com> References: <55F5F9E8-6DDC-46B5-B1FC-F3F9FA542DE9@gmail.com> <6d74b0d20804101102l4b7af03dp925c8812227b7936@mail.gmail.com> Message-ID: Thanks a lot for all explanations! It looks like 'ioAction' is the key to the solution and if the Browser module did not provide/expose this function, no IO actions could be run inside the BrowserAction monad? If yes, is this a general concept/pattern how to hide functionality of a underlying monad, in this case hide IO entirely? Adam On Apr 10, 2008, at 11:02 AM, Judah Jacobson wrote: > On Thu, Apr 10, 2008 at 7:50 AM, Adam Smyczek > wrote: >> For a small webapi binding I try to implement a session like monad >> by building a stack including BrowserAction from Network.Browser >> module as following: >> >> newtype RBAction a = RBAction >> { exec :: ErrorT String (StateT RBState BrowserAction) a } >> deriving (Functor, Monad, MonadState RBState) >> >> I would like the RBAction to implement MonadIO as well, >> but fight with the liftIO function for hours now, without success. >> Any idea how the implementation of liftIO could look like? > > In order to make a stack of monads an instance of MonadIO, you need to > be able to run IO actions in the innermost monad (BrowserAction). > Ideally, that monad itself would be an instance of MonadIO; maybe the > authors of HTTP didn't do so because it would add a dependency on the > mtl package (which defines the MonadIO class). > > Luckily, though, Network.Browser provides > ioAction :: IO a -> BrowserAction a > which is exactly what you need to write the MonadIO instances > yourself. > > > -- Solution #1 -- >> instance MonadIO BrowserAction where >> liftIO = ioAction > > Then you can add MonadIO to the deriving clause for RBAction. > > -- Solution #2 -- >> instance MonadIO RBAction where >> liftIO = RBAction . lift . lift . ioAction > > This pulls IO actions manually through the stack of transformers. It > might be better because if the HTTP package ever provided its own > instance of MonadIO BrowserAction, that would conflict with #1. > > Hope that helps, > -Judah From phercek at gmail.com Thu Apr 10 15:22:41 2008 From: phercek at gmail.com (Peter Hercek) Date: Thu Apr 10 15:19:08 2008 Subject: [Haskell-cafe] Re: ghc In-Reply-To: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> References: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> Message-ID: Cetin Sert wrote: > Is GHC required to be installed on the target OS I compile Haskell > binaries for in order for these binaries to run? I need a quick answer > on that! No. Well possibly yes if you use GHC api (e.g. for compiling a haskel code from your haskell application) but for common applications it is not required. Peter. From vigalchin at gmail.com Thu Apr 10 15:25:38 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Apr 10 15:21:11 2008 Subject: [Haskell-cafe] library version problem Message-ID: <5ae4f2ba0804101225g5c8a87e4u883acd5dd71e0f82@mail.gmail.com> Hello, I doing work using Linux. The wrong version (for me) of the unix package seems to be visible. I see possibilities to use ghc-pkg to suppress the unix package that I don't want(2.3.0.0) but that seems dangerious. Details are below . What should I do? Regards, vasili When I do: > ghci :m System.Posix I am getting the wrong version of the Unix package. I know this to be true because I did ghc-pkg latest unix and got unix-2.3.0.0 I want unix.2.2.0.0 because this version has changes that I made to the unix package. libHSunix-2.2.0.0.a is installed under /usr/local/lib/unix-2.2.0.0/ghc-6.8.2 I did a "nm -a libHSunix-2.2.0.0.a" and found symbols that I added. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080410/7d8ea2ce/attachment.htm From ketil at malde.org Thu Apr 10 15:27:37 2008 From: ketil at malde.org (Ketil Malde) Date: Thu Apr 10 15:23:02 2008 Subject: [Haskell-cafe] ghc In-Reply-To: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> (Cetin Sert's message of "Thu\, 10 Apr 2008 18\:27\:12 +0200") References: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> Message-ID: <87ej9d1pee.fsf@nmd9999.imr.no> "Cetin Sert" writes: > Is GHC required to be installed on the target OS I compile Haskell binaries for > in order for these binaries to run? I need a quick answer on that! Quick answer: No. GHC produces normal, standalone binaries. You may have problems with dynamic libraries, use ldd to check, or compile with -optl-static. -k -- If I haven't seen further, it is by standing in the footprints of giants From lrpalmer at gmail.com Thu Apr 10 15:42:35 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Apr 10 15:38:07 2008 Subject: [Haskell-cafe] Fighting the monad stack, MonadIO In-Reply-To: <55F5F9E8-6DDC-46B5-B1FC-F3F9FA542DE9@gmail.com> References: <55F5F9E8-6DDC-46B5-B1FC-F3F9FA542DE9@gmail.com> Message-ID: <7ca3f0160804101242l144bd37bu62632860ba18b99d@mail.gmail.com> On Thu, Apr 10, 2008 at 2:50 PM, Adam Smyczek wrote: > For a small webapi binding I try to implement a session like monad > by building a stack including BrowserAction from Network.Browser > module as following: > > newtype RBAction a = RBAction > { exec :: ErrorT String (StateT RBState BrowserAction) a } > deriving (Functor, Monad, MonadState RBState) > > I would like the RBAction to implement MonadIO as well, > but fight with the liftIO function for hours now, without success. > Any idea how the implementation of liftIO could look like? I suspect BrowserAction does not implement MonadIO (lest you could just put MonadIO in the deriving clause). So, that depends on how BrowserAction is implemented. What package is Network.Browser in? Luke From rendel at daimi.au.dk Thu Apr 10 15:49:00 2008 From: rendel at daimi.au.dk (Tillmann Rendel) Date: Thu Apr 10 15:44:49 2008 Subject: [Haskell-cafe] Fighting the monad stack, MonadIO In-Reply-To: <55F5F9E8-6DDC-46B5-B1FC-F3F9FA542DE9@gmail.com> References: <55F5F9E8-6DDC-46B5-B1FC-F3F9FA542DE9@gmail.com> Message-ID: <47FE6F2C.4070605@daimi.au.dk> Adam Smyczek wrote: > For a small webapi binding I try to implement a session like monad > by building a stack including BrowserAction from Network.Browser > module as following: > > newtype RBAction a = RBAction > { exec :: ErrorT String (StateT RBState BrowserAction) a } > deriving (Functor, Monad, MonadState RBState) > > I would like the RBAction to implement MonadIO as well, > but fight with the liftIO function for hours now, without success. > Any idea how the implementation of liftIO could look like? I would add instance MonadIO BrowserAction where liftIO = ioAction to hook Network.Browser into the monad transformer framework. I don't know why this instance is missing from Network.Browser. Maybe to avoid a dependency on the mtl? Anyway, with this instance, MonadIO can simply be derived for RBAction: newtype RBAction a = ... deriving (MonadIO, ...) Tillmann From adam.smyczek at gmail.com Thu Apr 10 15:51:47 2008 From: adam.smyczek at gmail.com (Adam Smyczek) Date: Thu Apr 10 15:47:22 2008 Subject: [Haskell-cafe] Fighting the monad stack, MonadIO In-Reply-To: <7ca3f0160804101242l144bd37bu62632860ba18b99d@mail.gmail.com> References: <55F5F9E8-6DDC-46B5-B1FC-F3F9FA542DE9@gmail.com> <7ca3f0160804101242l144bd37bu62632860ba18b99d@mail.gmail.com> Message-ID: On Apr 10, 2008, at 12:42 PM, Luke Palmer wrote: > On Thu, Apr 10, 2008 at 2:50 PM, Adam Smyczek > wrote: >> For a small webapi binding I try to implement a session like monad >> by building a stack including BrowserAction from Network.Browser >> module as following: >> >> newtype RBAction a = RBAction >> { exec :: ErrorT String (StateT RBState BrowserAction) a } >> deriving (Functor, Monad, MonadState RBState) >> >> I would like the RBAction to implement MonadIO as well, >> but fight with the liftIO function for hours now, without success. >> Any idea how the implementation of liftIO could look like? > > I suspect BrowserAction does not implement MonadIO (lest you could > just put MonadIO in the deriving clause). So, that depends on how > BrowserAction is implemented. What package is Network.Browser in? It's correct, BrowserAction does not implement MonadIO. This are the small things that confuse beginners like me :) Package http: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP-3001.0.4 > Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080410/0193d9cd/attachment.htm From valgarv at gmx.net Thu Apr 10 17:05:17 2008 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Thu Apr 10 17:00:51 2008 Subject: [Haskell-cafe] Longest increasing subsequence In-Reply-To: <200804101820.49647.matt@asklater.com> References: <200804101820.49647.matt@asklater.com> Message-ID: <200804110005.17716.valgarv@gmx.net> The article mentioned in this thread addresses a similar problem: http://lambda-the-ultimate.org/classic/message8282.html The main idea is to start by expressing the straightforward, inefficient solution ,in this case something like: liss = maximumBy length . filter ascending . concat . map inits . tails (with ascending :: (Ord a) => [a] -> Bool defined appropriately) Then apply a series of manipulations to it (each justified by a theorem) in order to arrive at the functional version of your favorite algorithm =) Some known names for (instances/applications of) this technique are map/fold fusion, deforestation and MapReduce. All the cool kids go bananas over it ;) -- Ariel J. Birnbaum From robdockins at fastmail.fm Thu Apr 10 17:17:15 2008 From: robdockins at fastmail.fm (Robert Dockins) Date: Thu Apr 10 17:02:17 2008 Subject: [Haskell-cafe] Longest increasing subsequence In-Reply-To: <200804101820.49647.matt@asklater.com> References: <200804101820.49647.matt@asklater.com> Message-ID: <200804101717.15991.robdockins@fastmail.fm> On Thursday 10 April 2008 01:20:49 pm Matt Amos wrote: > I'm trying to break out of my imperative mind-set by learning Haskell > in small snippets. After a few successes I've hit a bit of a > roadblock with one of the classic dynamic programming problems, the > longest increasing subsequence: > > http://en.wikipedia.org/wiki/Longest_increasing_subsequence > > The most efficient algorithm relies on destructive updates, so a > simple translation doesn't seem possible. I've been trying to think of > a way of removing the need for destructive updates while keeping the > efficiency, but so far without much luck. Ideally, I'd like to avoid > threading the whole thing with a state monad, since then it would > just be an imperative algorithm in disguise. > > Any suggestions would be very gratefully appreciated. Memorization is a nice way to implement dynamic programming algorithms in Haskell. Basically, you arrange it so that the underlying runtime does the destructive updates for you. http://www.haskell.org/haskellwiki/Memoization > Cheers, > > Matt From agl at imperialviolet.org Thu Apr 10 17:27:25 2008 From: agl at imperialviolet.org (Adam Langley) Date: Thu Apr 10 17:22:58 2008 Subject: [Haskell-cafe] ghc In-Reply-To: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> References: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> Message-ID: <396556a20804101427q7fdfb519h986eeff7e2627d0f@mail.gmail.com> 2008/4/10 Cetin Sert : > Is GHC required to be installed on the target OS I compile Haskell binaries > for in order for these binaries to run? I need a quick answer on that! Short answer: no. GHC can produce binaries which don't have any runtime deps on GHC libs. One thing that you might need on the target host is GMP, however that's pretty common. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From valgarv at gmx.net Thu Apr 10 17:36:08 2008 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Thu Apr 10 17:31:42 2008 Subject: [Haskell-cafe] Pattern match failure In-Reply-To: <16600643.post@talk.nabble.com> References: <16600643.post@talk.nabble.com> Message-ID: <200804110036.08578.valgarv@gmx.net> I think you were having a similar problem in an earlier thread. Others have given answers, but I'll try to drive the point home further. In a pattern match like this: f a = case a of [Rule x y] -> ... the pattern is *NOT* matched against each element of the list, but against the list as a whole. Say we have an expression like: let f [x] = True l = [1,2,3] in f l In the third line we attempt to match the list [1,2,3] against the pattern [x]. This cannot possibly work -- [x] can only match a list with a single element! I hope it's more clear now -- and that I answered the right question at all! There's more detail below if you're interested. {-# nitty-gritty on #-} In more detail, recall that [x] is nothing but syntactic sugar for x:[]. That is, the (:) constructor applied to x and []. [1,2,3] in turn stands for 1:2:3:[]. Pattern matching then proceeds: Match 1:2:3:[] against x:[] (:) matched -> match 1 against x; 2:3:[] against [] Match 1 against x x is a variable, bind it to 1 Match 2:3:[] against [] Match failed! {-# nitty-gritty off #-} Have fun =) Jealous 'cause I never had any homework in Haskell, -- Ariel J. Birnbaum From carette at mcmaster.ca Thu Apr 10 17:48:57 2008 From: carette at mcmaster.ca (Jacques Carette) Date: Thu Apr 10 17:43:03 2008 Subject: [Haskell-cafe] Longest increasing subsequence In-Reply-To: <200804101820.49647.matt@asklater.com> References: <200804101820.49647.matt@asklater.com> Message-ID: <47FE8B49.2030201@mcmaster.ca> You can translate the following algorithm (written in Maple 11), which can be made purely functional. [For the cognoscenti: attributes are implemented in-place in Maple, but that is really just an instance of the Decorator pattern which can be just as easily implemented with a functional Map]. Note that all the assignments below are really just let bindings. Jacques longestIncreasingSequence := proc(L::list) local n,i,j,G; uses GraphTheory; n := nops(L); G := Digraph(n , {seq(seq(`if`(L[i] Arrivals(G,v)=[], Vertices(G)); [attributes(max(seq(len(v), v in sources)))]; end proc: From ndmitchell at gmail.com Thu Apr 10 17:50:04 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Apr 10 17:45:46 2008 Subject: [Haskell-cafe] ghc In-Reply-To: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> References: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> Message-ID: <404396ef0804101450y3f5e9028g762df8b575cf7e1a@mail.gmail.com> Hi > Is GHC required to be installed on the target OS I compile Haskell binaries > for in order for these binaries to run? I need a quick answer on that! No. You can compile binaries on one machine and move them to a similar machine without recompilation. If you want to move binaries to a different type of machine, you would need to cross compile, which is a lot more work Thanks Neil From marco-oweber at gmx.de Thu Apr 10 18:50:20 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu Apr 10 18:45:56 2008 Subject: [Haskell-cafe] ghc In-Reply-To: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> References: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> Message-ID: <20080410225020.GD28116@gmx.de> On Thu, Apr 10, 2008 at 06:27:12PM +0200, Cetin Sert wrote: > Hi, > > Is GHC required to be installed on the target OS I compile Haskell binaries > for in order for these binaries to run? I need a quick answer on that! Because you need a quick answer I will give you an incomplete one: No, of course not. Depends on architecture though. You need some runtime dependencies (libraries such readline ).. using ghc-pkg describe you can find them (or readelf should list them as well) You need ghc if your applicattions use the ghc library. Running x86 on x86_64 won't work (although you can bootstrap ghc itself using C-files only, But I've never tried this.. There is -f-viaC as well. ) Marc From Braden.Shepherdson at gmail.com Thu Apr 10 17:51:59 2008 From: Braden.Shepherdson at gmail.com (Braden Shepherdson) Date: Thu Apr 10 19:20:37 2008 Subject: [Haskell-cafe] Re: ghc In-Reply-To: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> References: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> Message-ID: Cetin Sert wrote: > Hi, > > Is GHC required to be installed on the target OS I compile Haskell > binaries for in order for these binaries to run? I need a quick answer > on that! > > By the way there is no computer in the 4 or so networks I have online > access to on which ghc is not installed, which might be a sign people > like haskell here in Heidelberg/Mannheim, Germany. > > Best Regards, > Cetin Sert > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe No, GHC is not required. Compiling on the same OS and architecture will produce an executable that can be sent standalone to users. If it uses any external libraries (GTK, for example) then these libraries will need to be installed as well. Generally it is not necessary. Braden Shepherdson shepheb From jake.mcarthur at gmail.com Thu Apr 10 19:34:03 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Thu Apr 10 19:29:36 2008 Subject: [Haskell-cafe] ghc In-Reply-To: <22fcbd520804101120r4782ec34y58e9ca5fde21ff0@mail.gmail.com> References: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> <22fcbd520804101120r4782ec34y58e9ca5fde21ff0@mail.gmail.com> Message-ID: <7DE2B205-A52F-4E13-B3D2-E7BDE0ABC687@gmail.com> On Apr 10, 2008, at 1:20 PM, Brent Yorgey wrote: > This is true for any compiler that produces native binaries (as > opposed to certain languages which require a virtual machine...) Unless, of course, it results in a dynamically linked binary, which I'm pretty sure GHC doesn't support at all anyway (unless that has changed?). ? Jake From ajb at spamcop.net Thu Apr 10 20:11:50 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Thu Apr 10 20:07:21 2008 Subject: [Haskell-cafe] Longest increasing subsequence In-Reply-To: <200804101820.49647.matt@asklater.com> References: <200804101820.49647.matt@asklater.com> Message-ID: <20080410201150.2kxugbxo4gckckc4@webmail.spamcop.net> G'day all. Quoting Matt Amos : > http://en.wikipedia.org/wiki/Longest_increasing_subsequence > > The most efficient algorithm relies on destructive updates, so a > simple translation doesn't seem possible. Given that it's based on binary search, you might like to try using a binary search tree. You may or may not have discovered that the quadratic algorithm has a more-or-less direct translation into Haskell using lazy arrays. Did you have a go at implementing that first? Cheers, Andrew Bromage From haskell at list.mightyreason.com Thu Apr 10 20:18:38 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Thu Apr 10 20:14:24 2008 Subject: [Haskell-cafe] Re: Longest increasing subsequence In-Reply-To: <200804101820.49647.matt@asklater.com> References: <200804101820.49647.matt@asklater.com> Message-ID: It is late, but I was not sleepy enough, so here is my first translation of the algorithm to a functional approach... {- Quote wikipedia: http://en.wikipedia.org/wiki/Longest_increasing_subsequence L = 0 M[0] = 0 for i = 1, 2, ... n: binary search for the largest j ? L such that X[M[j]] < X[i] (or set j = 0 if no such value exists) P[i] = M[j] if j == L or X[i] < X[M[j+1]]: M[j+1] = i L = max(L, j+1) -} {- X[i] defined for i = 1,2,3? So X[0] is not defined. Now, rethink '0' as Nothing, and 1?j?L since X[M[0]] is also undefined. Not that after the binary search that one the three conditions holds: X[i] ? X[M[1]] "The same or a new minimum value" P[i] is created and set to Nothing If X[i] < X[M[1]] then M[1] is changed to i X[M[j]] < X[i] ? X[M[j+1]] for some j References: <1ff5dedc0804100927w747a6833kc4ba0fe6b6a1e708@mail.gmail.com> <22fcbd520804101120r4782ec34y58e9ca5fde21ff0@mail.gmail.com> <7DE2B205-A52F-4E13-B3D2-E7BDE0ABC687@gmail.com> Message-ID: <1ff5dedc0804101722g5227c97ybd7f6ca7011a0cbd@mail.gmail.com> moving a binary compiled on a 32-bit machine running Linux to a 64-bit one, would that necessitate recompilation on the target machine or cross-compilation or can 64-bit Linux run 32-bit binaries? 2008/4/11 Jake Mcarthur : > On Apr 10, 2008, at 1:20 PM, Brent Yorgey wrote: > > This is true for any compiler that produces native binaries (as opposed > > to certain languages which require a virtual machine...) > > > > Unless, of course, it results in a dynamically linked binary, which I'm > pretty sure GHC doesn't support at all anyway (unless that has changed?). > > ? Jake -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080411/6ad7a856/attachment.htm From valgarv at gmx.net Thu Apr 10 20:25:24 2008 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Thu Apr 10 20:20:58 2008 Subject: [Haskell-cafe] Longest increasing subsequence In-Reply-To: <200804110005.17716.valgarv@gmx.net> References: <200804101820.49647.matt@asklater.com> <200804110005.17716.valgarv@gmx.net> Message-ID: <200804110325.25075.valgarv@gmx.net> > liss = maximumBy length . filter ascending . concat . map inits . tails Of course my solution is braindamaged since I skipped this bit of the definition: [quote]Note that subsequence we are searching for is not necessarily contiguous[/quote]. Like the article says, without this detail the problem is quite trivial =P Replace concat . map inits . tails with foldr (\x xss -> xss ++ map (x:) xss) [[]] for a correct (yet even more inefficient) solution. I'd blame the mistake on the late hour, but it was even later when I noticed... *shame* -- Ariel J. Birnbaum From derek.a.elkins at gmail.com Thu Apr 10 20:32:29 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Thu Apr 10 20:28:05 2008 Subject: [Haskell-cafe] Fighting the monad stack, MonadIO In-Reply-To: References: <55F5F9E8-6DDC-46B5-B1FC-F3F9FA542DE9@gmail.com> <6d74b0d20804101102l4b7af03dp925c8812227b7936@mail.gmail.com> Message-ID: <1207873949.23782.5.camel@derek-laptop> On Thu, 2008-04-10 at 11:53 -0700, Adam Smyczek wrote: > Thanks a lot for all explanations! > > It looks like 'ioAction' is the key to the solution > and if the Browser module did not provide/expose > this function, no IO actions could be run inside > the BrowserAction monad? > > If yes, is this a general concept/pattern > how to hide functionality of a underlying monad, > in this case hide IO entirely? Yes, only there is nothing particular to monads. This would be just utilizing a standard abstract data type. From ryani.spam at gmail.com Thu Apr 10 21:06:18 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Apr 10 21:01:50 2008 Subject: [Haskell-cafe] Fighting the monad stack, MonadIO In-Reply-To: References: <55F5F9E8-6DDC-46B5-B1FC-F3F9FA542DE9@gmail.com> <6d74b0d20804101102l4b7af03dp925c8812227b7936@mail.gmail.com> Message-ID: <2f9b2d30804101806v42b777a9lb8d4dead062b5006@mail.gmail.com> On 4/10/08, Adam Smyczek wrote: > If yes, is this a general concept/pattern > how to hide functionality of a underlying monad, > in this case hide IO entirely? Yes, that's correct, although with IO you can't hide it entirely; eventually you need a way to actually run the computation, and if that's built on IO there's no way to do that without at least a way to get -back- to the IO Monad. On the other hand, you can use this to encapsulate "sandboxed" computations: > module Console (Console, execConsole, consoleGetLine, consolePutLine) > where > newtype Console a = MkConsole { execConsole :: IO a } > deriving (Monad, Functor) > consoleGetLine :: Console String > consoleGetLine = MkConsole getLine > consolePutLine :: String -> Console () > consolePutLine = MkConsole . putStrLn MkConsole is a private constructor not exported from this module, so the only way to construct one is via the operations we provide and the monad/functor operations. So we can prove that these operations never do any network access, or file I/O, or weird pointer access. Of course, with unsafeCoerce# and/or unsafePerformIO, client code can break either/both of these claims: > runConsole :: Console a -> a > runConsole = unsafePerformIO . execConsole > instance MonadIO Console where > liftIO = unsafeCoerce# > -- works because newtype is guaranteed not to change > -- the runtime representation -- ryan From jgoerzen at complete.org Thu Apr 10 21:34:41 2008 From: jgoerzen at complete.org (John Goerzen) Date: Thu Apr 10 22:03:49 2008 Subject: [Haskell-cafe] I/O system brokenness with named pipes Message-ID: So I have a need to write data to a POSIX named pipe (aka FIFO). Long story involving a command that doesn't have an option to read data from stdin, but can from a named pipe. I have created the named pipe from Haskell no problem. But I can't use writeFile to write data to it. Worse, it returns: *** Exception: /tmp/bakroller.zD0xHj/fifo: openFile: does not exist (No such device or address) which is completely false, as it *does* exist, and I can cat to it as expected. The call should block until everything is read on the remote end. I thought maybe writeFile is being weird, so I tried: openFile "/tmp/bakroller.zD0xHj/fifo" WriteMode Same thing. There is no logical reason I can see for this behavior. In fact, something must be going to *extra* effort to avoid writing to a named pipe, and I can't work out why. Named pipes are a standard, useful part of a system and shouldn't be ignored like this. Interestingly, readFile works fine on a named pipe. What's going on here? Am I going to have to resort to the System.Posix interface just to be able to write to a named pipe? -- John From vigalchin at gmail.com Thu Apr 10 22:36:13 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Apr 10 22:31:44 2008 Subject: [Haskell-cafe] library version problem In-Reply-To: References: <5ae4f2ba0804101225g5c8a87e4u883acd5dd71e0f82@mail.gmail.com> Message-ID: <5ae4f2ba0804101936qbce2ee9oe76a4045e8dfdf9c@mail.gmail.com> Hi Philip, Before I got your email, I deregistered unix-2.3.0.0 which made my unix-2.2.0.0 namespace changes visible. However, deregistering seems to made other things worse, e.g. runhaskell Setup.hs configure gives an error message "unknown parameter package: unix-2.3.0.0". Sigh .. how do I get back to where i was in order to do a "hide"? Kind regards, Vasili On Thu, Apr 10, 2008 at 8:22 PM, Philip Weaver wrote: > 2008/4/10 Galchin, Vasili : > > Hello, > > > > I doing work using Linux. The wrong version (for me) of the unix > > package seems to be visible. I see possibilities to use ghc-pkg to > suppress > > the unix package that I don't want(2.3.0.0) but that seems dangerious. > > Details are below . What should I do? > > If you don't want to use it, then it's safe to hide it: > > ghc-pkg hide unix-2.3.0.0 > > You can always unhide it later. > > You can also tell ghc to use a specific version of a package: > > ghc -package unix-2.2.0.0 > > Of course, you'll need to make sure unix-2.2.0.0 is registered with > ghc-pkg. > > > > > Regards, vasili > > > > > > > > When I do: > > > > > ghci > > :m System.Posix > > > > I am getting the wrong version of the Unix package. I know this to be > true > > because I did > > ghc-pkg latest unix > > > > and got unix-2.3.0.0 > > > > I want unix.2.2.0.0 because this version has changes that I made to the > unix > > package. libHSunix-2.2.0.0.a is installed under > > /usr/local/lib/unix-2.2.0.0/ghc-6.8.2 I did a "nm -a > libHSunix-2.2.0.0.a" > > and found symbols that I added. > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080410/9818752c/attachment.htm From vigalchin at gmail.com Thu Apr 10 22:38:26 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Apr 10 22:33:56 2008 Subject: [Haskell-cafe] library version problem In-Reply-To: <5ae4f2ba0804101936qbce2ee9oe76a4045e8dfdf9c@mail.gmail.com> References: <5ae4f2ba0804101225g5c8a87e4u883acd5dd71e0f82@mail.gmail.com> <5ae4f2ba0804101936qbce2ee9oe76a4045e8dfdf9c@mail.gmail.com> Message-ID: <5ae4f2ba0804101938n5e4a3105q44e901aa1aae2f1b@mail.gmail.com> Hello, Is there better documentation for ghc-pkg than just "help"?? Vasili On Thu, Apr 10, 2008 at 9:36 PM, Galchin, Vasili wrote: > Hi Philip, > > Before I got your email, I deregistered unix-2.3.0.0 which made my > unix-2.2.0.0 namespace changes visible. However, deregistering seems to made > other things worse, e.g. runhaskell Setup.hs configure gives an error > message "unknown parameter package: unix-2.3.0.0". Sigh .. how do I get back > to where i was in order to do a "hide"? > > Kind regards, Vasili > > > On Thu, Apr 10, 2008 at 8:22 PM, Philip Weaver > wrote: > > > 2008/4/10 Galchin, Vasili : > > > Hello, > > > > > > I doing work using Linux. The wrong version (for me) of the > > unix > > > package seems to be visible. I see possibilities to use ghc-pkg to > > suppress > > > the unix package that I don't want(2.3.0.0) but that seems dangerious. > > > Details are below . What should I do? > > > > If you don't want to use it, then it's safe to hide it: > > > > ghc-pkg hide unix-2.3.0.0 > > > > You can always unhide it later. > > > > You can also tell ghc to use a specific version of a package: > > > > ghc -package unix-2.2.0.0 > > > > Of course, you'll need to make sure unix-2.2.0.0 is registered with > > ghc-pkg. > > > > > > > > Regards, vasili > > > > > > > > > > > > When I do: > > > > > > > ghci > > > :m System.Posix > > > > > > I am getting the wrong version of the Unix package. I know this to be > > true > > > because I did > > > ghc-pkg latest unix > > > > > > and got unix-2.3.0.0 > > > > > > I want unix.2.2.0.0 because this version has changes that I made to > > the unix > > > package. libHSunix-2.2.0.0.a is installed under > > > /usr/local/lib/unix-2.2.0.0/ghc-6.8.2 I did a "nm -a > > libHSunix-2.2.0.0.a" > > > and found symbols that I added. > > > > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > Haskell-Cafe@haskell.org > > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080410/837ff039/attachment.htm From vigalchin at gmail.com Thu Apr 10 22:39:39 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Apr 10 22:35:09 2008 Subject: [Haskell-cafe] library version problem In-Reply-To: <5ae4f2ba0804101938n5e4a3105q44e901aa1aae2f1b@mail.gmail.com> References: <5ae4f2ba0804101225g5c8a87e4u883acd5dd71e0f82@mail.gmail.com> <5ae4f2ba0804101936qbce2ee9oe76a4045e8dfdf9c@mail.gmail.com> <5ae4f2ba0804101938n5e4a3105q44e901aa1aae2f1b@mail.gmail.com> Message-ID: <5ae4f2ba0804101939s4902c5ebt2b2ea3523c756715@mail.gmail.com> e.g. with "register" what is filename .. a path? Is this path to the .a (archive) file on Unix systems? On Thu, Apr 10, 2008 at 9:38 PM, Galchin, Vasili wrote: > Hello, > > Is there better documentation for ghc-pkg than just "help"?? > > Vasili > > > On Thu, Apr 10, 2008 at 9:36 PM, Galchin, Vasili > wrote: > > > Hi Philip, > > > > Before I got your email, I deregistered unix-2.3.0.0 which made my > > unix-2.2.0.0 namespace changes visible. However, deregistering seems to made > > other things worse, e.g. runhaskell Setup.hs configure gives an error > > message "unknown parameter package: unix-2.3.0.0". Sigh .. how do I get back > > to where i was in order to do a "hide"? > > > > Kind regards, Vasili > > > > > > On Thu, Apr 10, 2008 at 8:22 PM, Philip Weaver > > wrote: > > > > > 2008/4/10 Galchin, Vasili : > > > > Hello, > > > > > > > > I doing work using Linux. The wrong version (for me) of the > > > unix > > > > package seems to be visible. I see possibilities to use ghc-pkg to > > > suppress > > > > the unix package that I don't want(2.3.0.0) but that seems > > > dangerious. > > > > Details are below . What should I do? > > > > > > If you don't want to use it, then it's safe to hide it: > > > > > > ghc-pkg hide unix-2.3.0.0 > > > > > > You can always unhide it later. > > > > > > You can also tell ghc to use a specific version of a package: > > > > > > ghc -package unix-2.2.0.0 > > > > > > Of course, you'll need to make sure unix-2.2.0.0 is registered with > > > ghc-pkg. > > > > > > > > > > > Regards, vasili > > > > > > > > > > > > > > > > When I do: > > > > > > > > > ghci > > > > :m System.Posix > > > > > > > > I am getting the wrong version of the Unix package. I know this to > > > be true > > > > because I did > > > > ghc-pkg latest unix > > > > > > > > and got unix-2.3.0.0 > > > > > > > > I want unix.2.2.0.0 because this version has changes that I made to > > > the unix > > > > package. libHSunix-2.2.0.0.a is installed under > > > > /usr/local/lib/unix-2.2.0.0/ghc-6.8.2 I did a "nm -a > > > libHSunix-2.2.0.0.a" > > > > and found symbols that I added. > > > > > > > > _______________________________________________ > > > > Haskell-Cafe mailing list > > > > Haskell-Cafe@haskell.org > > > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080410/9cb3a0cc/attachment.htm From dm.maillists at gmail.com Thu Apr 10 23:18:51 2008 From: dm.maillists at gmail.com (Daniel McAllansmith) Date: Thu Apr 10 23:14:38 2008 Subject: [Haskell-cafe] http: Network.Browser leaks TCP connections In-Reply-To: <200804090824.41940.dm.maillists@gmail.com> References: <200804082300.52246.dm.maillists@gmail.com> <4249453d0804081036g58eff9acta02d4f421a70a4e7@mail.gmail.com> <200804090824.41940.dm.maillists@gmail.com> Message-ID: <200804111518.52378.dm.maillists@gmail.com> I've looked into this further and I believe the leaked connections are due to Network.Browser, this is a separate issue from that identified by Paul Brown. The BrowserState in Network.Browser has a connection pool of up to five connections. When a sixth is opened the oldest connection is closed. This looks to be the only time that a connection is closed. BrowserState's internals are not exported so there is no way for a user to close them. The net effect for HXT is that every time readDocument is called, using native http, a single TCP connection is leaked. I've attached a patch against the darcs version of http that cures my test programs leak. Cheers Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: BrowserState_connection_leak.patch Type: text/x-diff Size: 4162 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080411/6c839dcc/BrowserState_connection_leak.bin From chak at cse.unsw.edu.au Fri Apr 11 00:22:48 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Fri Apr 11 00:18:23 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> <47FC75E3.4050902@gmail.com> <45C322C6-E01C-4867-9D2F-3FEA89C196C7@cse.unsw.edu.au> Message-ID: <8535B153-0B87-4AFA-A30F-424DF2595907@cse.unsw.edu.au> Lennart Augustsson: > > On Thu, Apr 10, 2008 at 4:20 AM, Manuel M T Chakravarty > wrote: > the five signatures > > forall a. S a > forall b. S b > forall a b. S (a, b) > Int > S Int > > By alpha-convertible I mean the usual thing from lambda calculus, > they are identical modulo the names of bound variables. > So only the first two are alpha-convertible to each other. > > If you involve any kind of reduction the equivalence test is no > longer trivial. > > All I'm asking for really, is to be able to paste in the type that > was inferred as the signature, without the compiler complaining. I think a trivial, purely syntactic test, such as the one proposed, would generate at least as much puzzlement as the current situation does. It would mean, you could not have String in your signature if the inferred signature has [Char]. I don't think that this is a solution at all. Manuel From chak at cse.unsw.edu.au Fri Apr 11 00:24:26 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Fri Apr 11 00:19:59 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> Message-ID: Lennart Augustsson: > In the current GHC there are even definitions that are perfecty > usable, that cannot be given the type signature that that was > inferred. That's bad, I agree. > At work we have the warning for missing signatures enabled, and we > turn warnings into errors. We have to disbale this for certain > definitions, because you cannot give them a signature. I find that > broken. Definitely. Can you give an example? Manuel > On Thu, Apr 10, 2008 at 5:52 AM, Manuel M T Chakravarty > wrote: > Lennart Augustsson: > > Let's look at this example from a higher level. > > Haskell is a language which allows you to write type signatures for > functions, and even encourages you to do it. > Sometimes you even have to do it. Any language feature that stops > me from writing a type signature is in my opinion broken. > TFs as implemented in currently implemented ghc stops me from > writing type signatures. They are thus, in my opinion, broken. > > The problem of ambiguity is not at all restricted to TFs. In fact, > you need neither TFs nor FDs to get the exact same behaviour. You > don't even need MPTCs: > > {-# LANGUAGE FlexibleContexts #-} > module Ambiguity where > > class C a > > bar :: C (a, b) => b -> b > bar = id > > bar' :: C (a, b) => b -> b > bar' = bar > > > > This gives us > > /Users/chak/Code/haskell/Ambiguity.hs:10:7: > Could not deduce (C (a, b)) from the context (C (a1, b)) > arising from a use of `bar' > at /Users/chak/Code/haskell/Ambiguity.hs:10:7-9 > Possible fix: > add (C (a, b)) to the context of the type signature for `bar'' > or add an instance declaration for (C (a, b)) > In the expression: bar > In the definition of `bar'': bar' = bar > > > So, we have this problem as soon as we have flexible contexts and/or > MPTCs, independent of TFs and FDs. > > Manuel > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From chak at cse.unsw.edu.au Fri Apr 11 00:26:12 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Fri Apr 11 00:21:45 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> <47FC75E3.4050902@gmail.com> <45C322C6-E01C-4867-9D2F-3FEA89C196C7@cse.unsw.edu.au> Message-ID: <80CEF079-F851-4EA7-BCAA-4D95F0E43E44@cse.unsw.edu.au> Lennart Augustsson: > On Thu, Apr 10, 2008 at 4:20 AM, Manuel M T Chakravarty > wrote: > Lennart Augustsson: > > On Wed, Apr 9, 2008 at 8:53 AM, Martin Sulzmann > wrote: > > Lennart, you said > > (It's also pretty easy to fix the problem.) > > What do you mean? Easy to fix the type checker, or easy to fix the > program by inserting annotations > to guide the type checker? > > Martin > > I'm referring to the situation where the type inferred by the type > checker is illegal for me to put into the program. > In our example we can fix this in two ways, by making foo' illegal > even when it has no signature, or making foo' legal even when it has > a signature. > > To make it illegal: If foo' has no type signature, infer a type for > foo', insert this type as a signature and type check again. If this > fails, foo' is illegal. > > That would be possible, but it means we have to do this for all > bindings in a program (also all lets bindings etc). > > Of course, but I'd rather the compiler did it than I. It's not that > hard, btw. If the whole module type checks, insert all signatures > and type check again. Sure. I did not argue against this. I think it would be a reasonable way forward. Manuel From vigalchin at gmail.com Fri Apr 11 00:59:05 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri Apr 11 00:54:39 2008 Subject: [Haskell-cafe] library version problem In-Reply-To: <5ae4f2ba0804101939s4902c5ebt2b2ea3523c756715@mail.gmail.com> References: <5ae4f2ba0804101225g5c8a87e4u883acd5dd71e0f82@mail.gmail.com> <5ae4f2ba0804101936qbce2ee9oe76a4045e8dfdf9c@mail.gmail.com> <5ae4f2ba0804101938n5e4a3105q44e901aa1aae2f1b@mail.gmail.com> <5ae4f2ba0804101939s4902c5ebt2b2ea3523c756715@mail.gmail.com> Message-ID: <5ae4f2ba0804102159u40d58ee6r58656a2c5fc4c9de@mail.gmail.com> I am reading currently .. http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html#installed-pkg-info 1) Is ghc-pkg intended to be run by most Haskell developers or should ghc-pkg be run by "higher level" tools like Cabal?? 2) my package database appears to be somewhat comprised after I unregistered unix-2.3.0.0. I can no longer build the unix package via "runhaskell". ?? Kind regards, Vasili On Thu, Apr 10, 2008 at 9:39 PM, Galchin, Vasili wrote: > e.g. with "register" what is filename .. a path? Is this path to the .a > (archive) file on Unix systems? > > On Thu, Apr 10, 2008 at 9:38 PM, Galchin, Vasili > wrote: > > > Hello, > > > > Is there better documentation for ghc-pkg than just "help"?? > > > > Vasili > > > > > > On Thu, Apr 10, 2008 at 9:36 PM, Galchin, Vasili > > wrote: > > > > > Hi Philip, > > > > > > Before I got your email, I deregistered unix-2.3.0.0 which made my > > > unix-2.2.0.0 namespace changes visible. However, deregistering seems to made > > > other things worse, e.g. runhaskell Setup.hs configure gives an error > > > message "unknown parameter package: unix-2.3.0.0". Sigh .. how do I get back > > > to where i was in order to do a "hide"? > > > > > > Kind regards, Vasili > > > > > > > > > On Thu, Apr 10, 2008 at 8:22 PM, Philip Weaver < > > > philip.weaver@gmail.com> wrote: > > > > > > > 2008/4/10 Galchin, Vasili : > > > > > Hello, > > > > > > > > > > I doing work using Linux. The wrong version (for me) of > > > > the unix > > > > > package seems to be visible. I see possibilities to use ghc-pkg to > > > > suppress > > > > > the unix package that I don't want(2.3.0.0) but that seems > > > > dangerious. > > > > > Details are below . What should I do? > > > > > > > > If you don't want to use it, then it's safe to hide it: > > > > > > > > ghc-pkg hide unix-2.3.0.0 > > > > > > > > You can always unhide it later. > > > > > > > > You can also tell ghc to use a specific version of a package: > > > > > > > > ghc -package unix-2.2.0.0 > > > > > > > > Of course, you'll need to make sure unix-2.2.0.0 is registered with > > > > ghc-pkg. > > > > > > > > > > > > > > Regards, vasili > > > > > > > > > > > > > > > > > > > > When I do: > > > > > > > > > > > ghci > > > > > :m System.Posix > > > > > > > > > > I am getting the wrong version of the Unix package. I know this to > > > > be true > > > > > because I did > > > > > ghc-pkg latest unix > > > > > > > > > > and got unix-2.3.0.0 > > > > > > > > > > I want unix.2.2.0.0 because this version has changes that I made > > > > to the unix > > > > > package. libHSunix-2.2.0.0.a is installed under > > > > > /usr/local/lib/unix-2.2.0.0/ghc-6.8.2 I did a "nm -a > > > > libHSunix-2.2.0.0.a" > > > > > and found symbols that I added. > > > > > > > > > > _______________________________________________ > > > > > Haskell-Cafe mailing list > > > > > Haskell-Cafe@haskell.org > > > > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080410/c75d36db/attachment.htm From ketil at malde.org Fri Apr 11 03:11:47 2008 From: ketil at malde.org (Ketil Malde) Date: Fri Apr 11 03:07:08 2008 Subject: [Haskell-cafe] library version problem In-Reply-To: <5ae4f2ba0804101225g5c8a87e4u883acd5dd71e0f82@mail.gmail.com> (Vasili Galchin's message of "Thu\, 10 Apr 2008 14\:25\:38 -0500") References: <5ae4f2ba0804101225g5c8a87e4u883acd5dd71e0f82@mail.gmail.com> Message-ID: <878wzk27d8.fsf@nmd9999.imr.no> "Galchin, Vasili" writes: >> ghci > :m System.Posix > > I am getting the wrong version of the Unix package. I know this to be true > because I did > ghc-pkg latest unix > > and got unix-2.3.0.0 > > I want unix.2.2.0.0 because this version has changes that I made Naturally, you'll get 2.3.0.0, since it has the highest version number! Either rename your modified version to 2.4 (or similar), specify the exact version in your *application's* cabal file, or use "ghc-pkg hide" to hide version 2.3.0.0 from view. -k -- If I haven't seen further, it is by standing in the footprints of giants From martin.sulzmann at gmail.com Fri Apr 11 04:32:29 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Fri Apr 11 04:28:04 2008 Subject: [Haskell-cafe] type families and type signatures In-Reply-To: References: <8C984B4799C04D4B8F80F746537145E116F4F67B@elon12p32001.csfp.co.uk> <41C4B3AC-8350-4DB6-BF56-7502B3244077@cse.unsw.edu.au> <47FC6045.1040800@gmail.com> <47FC75E3.4050902@gmail.com> Message-ID: <47FF221D.5080405@gmail.com> Lennart Augustsson wrote: > On Wed, Apr 9, 2008 at 8:53 AM, Martin Sulzmann > > wrote: > > > Lennart, you said > > (It's also pretty easy to fix the problem.) > > > What do you mean? Easy to fix the type checker, or easy to fix the > program by inserting annotations > to guide the type checker? > > Martin > > > I'm referring to the situation where the type inferred by the type > checker is illegal for me to put into the program. > In our example we can fix this in two ways, by making foo' illegal > even when it has no signature, or making foo' legal even when it has a > signature. > > To make it illegal: If foo' has no type signature, infer a type for > foo', insert this type as a signature and type check again. If this > fails, foo' is illegal. > > To make it legal: If foo' with a type signature doesn't type check, > try to infer a type without a signature. If this succeeds then check > that the type that was inferred is alpha-convertible to the original > signature. If it is, accept foo'; the signature doesn't add any > information. > > Either of these two option would be much preferable to the current > (broken) situation where the inferred signature is illegal. I understand now what you meant. See my earlier reply to Claus' email. Regarding your request to take into account alpha-convertibility when checking signatures. We know that in GHC the check (forall a, b. Foo a b => a) <= (forall a, c. Foo a c => a) (**) fails cause when testing the constraint/formula derived from the above subsumption check forall a, b. Foo a b implies exists c. Foo a c GHC simply drops the exists c bit and clearly Foo a b does NOT imply Foo a c We need to choose c to be equal to b. I call this process "matching" but it's of course a form of alpha-conversion. (We convince GHC to accept such signatures but encoding System F style type application via redundant type proxy arguments) The point I want to make is that in Chameleon I've implemented a subsumption check which takes into account matching. Therefore, (**) is checkable in Chameleon. BUT matching can be fairly expensive, exponential in the worst case, for example consider cases such as Foo x_i x_i+1 So maybe there's good reason why GHC's subsumption check doesn't take into account matching. The slightly odd thing is that GHC uses a "pessimistic" subsumption check (no matching) in combination with an "optimistic" ambiguity check (see my earlier message on this topic). I'd say it's better to be pessimistic/pessimistic and optimistic/optimistic, maybe this could be a compiler switch? Martin From apfelmus at quantentunnel.de Fri Apr 11 05:22:18 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Fri Apr 11 05:18:04 2008 Subject: [Haskell-cafe] Re: type families and type signatures In-Reply-To: References: <38046D50-6BDD-4CFF-81A3-2126A445953A@cse.unsw.edu.au> Message-ID: Tom Schrijvers wrote: > apfelmus wrote: >> However, I have this feeling that >> >> bar :: forall a . Id a -> String >> >> with a type family Id *is* parametric in the sense that no matter >> what a is, the result always has to be the same. Intuitively, that's >> because we may not "pattern match on the branch" of a definition like >> >> type instance Id String = .. >> type instance Id Int = .. >> .. > > But in a degenerate case there could be just this one instance: > > type instance Id x = GADT x > > which then reduces this example to the GADT case of which you said that > is was "clearly parametric". Manuel M T Chakravarty wrote: > type instance Id [a] = GADT a Oh right, just setting the instance to a GADT makes it non-parametric. Still, it's not the type family that is the problem, but "parametricity" is not the right word for that. What I want to say is that although the type signature bar :: forall a . Id a ~ b => b -> String looks ambiguous, it is not. A trivial example of "seeming" ambiguity would be (foo :: forall a . Int) . Here, parametricity tells us that this is not ambiguous. The proper formulation is probably: a value f :: forall a . t is /unambiguous/ iff any choices a1, a2 for a that yield the same static type necessarily also yield the same dynamic value t[a1/a] = t[a2/a] -- types are equal => f @ a1 = f @ a2 -- values are equal In the case of bar , this would mean that anything not injective like type instance Id Int = Int type instance Id Char = Int would not change the dynamic semantics of bar at all, i.e. (bar @ Int :: Int -> String) = (bar @ Char :: Int -> String). I believe that this is indeed the case for bar and for type synonym families in general. (Not so for type classes, of course.) Regards apfelmus From dons at galois.com Fri Apr 11 05:43:15 2008 From: dons at galois.com (Don Stewart) Date: Fri Apr 11 05:38:47 2008 Subject: [Haskell-cafe] Control.Parallel.Strategies In-Reply-To: <3d96ac180804091503l7a413eey4d28ae54f8a285d8@mail.gmail.com> References: <3d96ac180804091409j5fc59b33i414a5676b95fa0a6@mail.gmail.com> <3d96ac180804091425n152b84c9scdba015f62d79a05@mail.gmail.com> <3d96ac180804091503l7a413eey4d28ae54f8a285d8@mail.gmail.com> Message-ID: <20080411094315.GB15362@scytale.galois.com> sebastian.sylvan: > On Wed, Apr 9, 2008 at 10:58 PM, Justin Bailey <[1]jgbailey@gmail.com> > wrote: > > On Wed, Apr 9, 2008 at 2:25 PM, Sebastian Sylvan > <[2]sebastian.sylvan@gmail.com> wrote: > > Nope! > > > > This is GHC 6.8.2 btw, downloaded the binary from the web site, so > it's > > nothing strange. > > On my hyper-threaded CPU, your original code works fine. With -N2, I > see 100% CPU. With N1, only 50%. I am also using GHC [3]6.8.2. > Justin > > Hmm, that's curious. I compile with "ghc --make -threaded partest.hs -o > par.exe", and then run it with "par.exe +RTS -N2 -RTS". Am I making some > silly configuration error? > Are you running this on windows? > I think its always worth using -O or -O2 too, for what its worth. -- Don From dons at galois.com Fri Apr 11 06:33:53 2008 From: dons at galois.com (Don Stewart) Date: Fri Apr 11 06:29:39 2008 Subject: [Haskell-cafe] I/O system brokenness with named pipes In-Reply-To: References: Message-ID: <20080411103353.GE15362@scytale.galois.com> jgoerzen: > So I have a need to write data to a POSIX named pipe (aka FIFO). Long > story involving a command that doesn't have an option to read data > from stdin, but can from a named pipe. > > I have created the named pipe from Haskell no problem. > > But I can't use writeFile to write data to it. Worse, it returns: > > *** Exception: /tmp/bakroller.zD0xHj/fifo: openFile: does not exist > (No such device or address) > > which is completely false, as it *does* exist, and I can cat to it as > expected. The call should block until everything is read on the > remote end. > > I thought maybe writeFile is being weird, so I tried: > > openFile "/tmp/bakroller.zD0xHj/fifo" WriteMode Hmm, I can get this to work, but only if I have another process waiting on the pipe already: $ mkfifo /tmp/pipe $ tail -f /tmp/pipe $ ghc -e 'writeFile "/tmp/pipe" "test"' testtesttesttest^C However, if I don't have 'tail' waiting on the pipe, it fails. > There is no logical reason I can see for this behavior. In fact, > something must be going to *extra* effort to avoid writing to a named > pipe, and I can't work out why. Named pipes are a standard, useful > part of a system and shouldn't be ignored like this. > > Interestingly, readFile works fine on a named pipe. > > What's going on here? Am I going to have to resort to the > System.Posix interface just to be able to write to a named pipe? Something fishy. -- Don From duncan.coutts at worc.ox.ac.uk Fri Apr 11 06:39:54 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 11 06:35:25 2008 Subject: [Haskell-cafe] I/O system brokenness with named pipes In-Reply-To: References: Message-ID: <1207910394.9923.3.camel@dell.linuxdev.us.dell.com> On Thu, 2008-04-10 at 20:34 -0500, John Goerzen wrote: > I have created the named pipe from Haskell no problem. > > But I can't use writeFile to write data to it. Worse, it returns: > > *** Exception: /tmp/bakroller.zD0xHj/fifo: openFile: does not exist > (No such device or address) > What's going on here? Am I going to have to resort to the > System.Posix interface just to be able to write to a named pipe? Named pipes have broken semantics for non-blocking IO, see google or the man pages on named pipes. GHC's standard Handle IO always sets file descriptor to non-blocking mode. That's the problem. That's why cat works, because it uses blocking IO. You would indeed need to use System.Posix to get a FD in blocking mode. Then you have to worry a bit about blocking other Haskell thread when you block on writing to the pipe. Duncan From ketil at malde.org Fri Apr 11 06:54:08 2008 From: ketil at malde.org (Ketil Malde) Date: Fri Apr 11 06:49:29 2008 Subject: [Haskell-cafe] library version problem In-Reply-To: <878wzk27d8.fsf@nmd9999.imr.no> (Ketil Malde's message of "Fri\, 11 Apr 2008 09\:11\:47 +0200") References: <5ae4f2ba0804101225g5c8a87e4u883acd5dd71e0f82@mail.gmail.com> <878wzk27d8.fsf@nmd9999.imr.no> Message-ID: <87iqyozmpb.fsf@nmd9999.imr.no> Ketil Malde writes: > Either rename your modified version to 2.4 (or similar), specify the > exact version in your *application's* cabal file, ..or you could compile your application specifying the package explicitly, using "-package unix-2.2.0.0" (and all the other packages, normally supplied by Cabal or ghc --make). > or use "ghc-pkg hide" to hide version 2.3.0.0 from view. -k -- If I haven't seen further, it is by standing in the footprints of giants From sebastian.sylvan at gmail.com Fri Apr 11 07:27:32 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Fri Apr 11 07:23:05 2008 Subject: [Haskell-cafe] Control.Parallel.Strategies In-Reply-To: <20080411094315.GB15362@scytale.galois.com> References: <3d96ac180804091409j5fc59b33i414a5676b95fa0a6@mail.gmail.com> <3d96ac180804091425n152b84c9scdba015f62d79a05@mail.gmail.com> <3d96ac180804091503l7a413eey4d28ae54f8a285d8@mail.gmail.com> <20080411094315.GB15362@scytale.galois.com> Message-ID: <3d96ac180804110427v1918de17j4c23b690e10a1623@mail.gmail.com> On Fri, Apr 11, 2008 at 10:43 AM, Don Stewart wrote: > sebastian.sylvan: > > On Wed, Apr 9, 2008 at 10:58 PM, Justin Bailey <[1]jgbailey@gmail.com > > > > wrote: > > > > On Wed, Apr 9, 2008 at 2:25 PM, Sebastian Sylvan > > <[2]sebastian.sylvan@gmail.com> wrote: > > > Nope! > > > > > > This is GHC 6.8.2 btw, downloaded the binary from the web site, > so > > it's > > > nothing strange. > > > > On my hyper-threaded CPU, your original code works fine. With -N2, > I > > see 100% CPU. With N1, only 50%. I am also using GHC [3]6.8.2. > > Justin > > > > Hmm, that's curious. I compile with "ghc --make -threaded partest.hs > -o > > par.exe", and then run it with "par.exe +RTS -N2 -RTS". Am I making > some > > silly configuration error? > > Are you running this on windows? > > > > I think its always worth using -O or -O2 too, for what its worth. > Yes I've tried both, neither helped. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080411/3bd34ae2/attachment-0001.htm From himself at leiffrenzel.de Fri Apr 11 07:36:21 2008 From: himself at leiffrenzel.de (Leif Frenzel) Date: Fri Apr 11 07:31:51 2008 Subject: [Haskell-cafe] library version problem In-Reply-To: <5ae4f2ba0804101938n5e4a3105q44e901aa1aae2f1b@mail.gmail.com> References: <5ae4f2ba0804101225g5c8a87e4u883acd5dd71e0f82@mail.gmail.com> <5ae4f2ba0804101936qbce2ee9oe76a4045e8dfdf9c@mail.gmail.com> <5ae4f2ba0804101938n5e4a3105q44e901aa1aae2f1b@mail.gmail.com> Message-ID: <40412.193.47.77.5.1207913781.squirrel@d2875.servadmin.com> Hi Vasili, there is: http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html HTH, Ciao, Leif On Fri, April 11, 2008 4:38 am, Galchin, Vasili wrote: > Hello, > > Is there better documentation for ghc-pkg than just "help"?? > > Vasili > > On Thu, Apr 10, 2008 at 9:36 PM, Galchin, Vasili > wrote: > >> Hi Philip, >> >> Before I got your email, I deregistered unix-2.3.0.0 which made my >> unix-2.2.0.0 namespace changes visible. However, deregistering seems to >> made >> other things worse, e.g. runhaskell Setup.hs configure gives an error >> message "unknown parameter package: unix-2.3.0.0". Sigh .. how do I get >> back >> to where i was in order to do a "hide"? >> >> Kind regards, Vasili >> >> >> On Thu, Apr 10, 2008 at 8:22 PM, Philip Weaver >> wrote: >> >> > 2008/4/10 Galchin, Vasili : >> > > Hello, >> > > >> > > I doing work using Linux. The wrong version (for me) of the >> > unix >> > > package seems to be visible. I see possibilities to use ghc-pkg to >> > suppress >> > > the unix package that I don't want(2.3.0.0) but that seems >> dangerious. >> > > Details are below . What should I do? >> > >> > If you don't want to use it, then it's safe to hide it: >> > >> > ghc-pkg hide unix-2.3.0.0 >> > >> > You can always unhide it later. >> > >> > You can also tell ghc to use a specific version of a package: >> > >> > ghc -package unix-2.2.0.0 >> > >> > Of course, you'll need to make sure unix-2.2.0.0 is registered with >> > ghc-pkg. >> > >> > > >> > > Regards, vasili >> > > >> > > >> > > >> > > When I do: >> > > >> > > > ghci >> > > :m System.Posix >> > > >> > > I am getting the wrong version of the Unix package. I know this to >> be >> > true >> > > because I did >> > > ghc-pkg latest unix >> > > >> > > and got unix-2.3.0.0 >> > > >> > > I want unix.2.2.0.0 because this version has changes that I made to >> > the unix >> > > package. libHSunix-2.2.0.0.a is installed under >> > > /usr/local/lib/unix-2.2.0.0/ghc-6.8.2 I did a "nm -a >> > libHSunix-2.2.0.0.a" >> > > and found symbols that I added. >> > > >> > > _______________________________________________ >> > > 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 > -- Leif Frenzel http://leiffrenzel.de http://cohatoe.blogspot.com From allbery at ece.cmu.edu Fri Apr 11 07:41:37 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Apr 11 07:37:09 2008 Subject: [Haskell-cafe] I/O system brokenness with named pipes In-Reply-To: References: Message-ID: On Apr 10, 2008, at 21:34 , John Goerzen wrote: > So I have a need to write data to a POSIX named pipe (aka FIFO). Long > story involving a command that doesn't have an option to read data > from stdin, but can from a named pipe. > > I have created the named pipe from Haskell no problem. > > But I can't use writeFile to write data to it. Worse, it returns: > > *** Exception: /tmp/bakroller.zD0xHj/fifo: openFile: does not exist > (No such device or address) The "does not exist" is misleading: ENXIO ("No such device or address"), unless it's being abused by the runtime, indicates something's wrong at the kernel level when trying to associate the FIFO. Using FIFOs properly is actually rather tricky and fidgety. Can you provide the actual code you're using? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From jgoerzen at complete.org Fri Apr 11 08:12:59 2008 From: jgoerzen at complete.org (John Goerzen) Date: Fri Apr 11 08:08:32 2008 Subject: [Haskell-cafe] I/O system brokenness with named pipes In-Reply-To: <1207910394.9923.3.camel@dell.linuxdev.us.dell.com> References: <1207910394.9923.3.camel@dell.linuxdev.us.dell.com> Message-ID: <200804110712.59895.jgoerzen@complete.org> On Friday 11 April 2008 05:39:54 am Duncan Coutts wrote: > On Thu, 2008-04-10 at 20:34 -0500, John Goerzen wrote: > > I have created the named pipe from Haskell no problem. > > > > But I can't use writeFile to write data to it. Worse, it returns: > > > > *** Exception: /tmp/bakroller.zD0xHj/fifo: openFile: does not exist > > (No such device or address) > > > > What's going on here? Am I going to have to resort to the > > System.Posix interface just to be able to write to a named pipe? > > Named pipes have broken semantics for non-blocking IO, see google or the > man pages on named pipes. GHC's standard Handle IO always sets file > descriptor to non-blocking mode. That's the problem. That's why cat > works, because it uses blocking IO. OK, I have referred to fifo(7) regarding this point. It seems I may need a loop trying over and over to open the FIFO in write mode. It also appears that ReadWriteMode appearing to work is Linux-specific, and this behavior is left undefined in POSIX. Does openFd do a non-blocking open? (Brief testing suggests it does) I'm somewhat confused about its semantics, especially since it does not appear to correspond directly to open(2). O_CREAT, for instance, is missing. > You would indeed need to use System.Posix to get a FD in blocking mode. > Then you have to worry a bit about blocking other Haskell thread when > you block on writing to the pipe. Fortunately, in this particular case, I'm using forking instead of threading so this won't be a problem. Thanks for the help. -- John From allbery at ece.cmu.edu Fri Apr 11 08:53:12 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Apr 11 08:48:43 2008 Subject: [Haskell-cafe] I/O system brokenness with named pipes In-Reply-To: <20080411103353.GE15362@scytale.galois.com> References: <20080411103353.GE15362@scytale.galois.com> Message-ID: On Apr 11, 2008, at 6:33 , Don Stewart wrote: >> >> But I can't use writeFile to write data to it. Worse, it returns: >> >> *** Exception: /tmp/bakroller.zD0xHj/fifo: openFile: does not exist >> (No such device or address) >> > Hmm, I can get this to work, but only if I have another process > waiting > on the pipe already: Yep; that's one of the tricky parts of FIFOs. If you don't have the read side *always* open, it behaves very nonintuitively. (But with the read side always open, you will never receive an EOF.) This has nothing to do with Haskell; it's just the way FIFOs work. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Fri Apr 11 09:02:07 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Apr 11 08:57:37 2008 Subject: [Haskell-cafe] I/O system brokenness with named pipes In-Reply-To: <200804110712.59895.jgoerzen@complete.org> References: <1207910394.9923.3.camel@dell.linuxdev.us.dell.com> <200804110712.59895.jgoerzen@complete.org> Message-ID: <3F6A8321-5E6A-4FD9-97BA-B6BFABC136BE@ece.cmu.edu> On Apr 11, 2008, at 8:12 , John Goerzen wrote: > OK, I have referred to fifo(7) regarding this point. It seems I > may need a > loop trying over and over to open the FIFO in write mode. It also > appears > that ReadWriteMode appearing to work is Linux-specific, and this > behavior is > left undefined in POSIX. Undefined in POSIX, normal for Unix (and Linux originally promised only POSIX semantics but was rejiggered some years back to behave like Unix in this regard, because Unix programs rely on these semantics and therefore failed on Linux). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From jgoerzen at complete.org Fri Apr 11 09:08:13 2008 From: jgoerzen at complete.org (John Goerzen) Date: Fri Apr 11 09:03:45 2008 Subject: [Haskell-cafe] I/O system brokenness with named pipes In-Reply-To: <3F6A8321-5E6A-4FD9-97BA-B6BFABC136BE@ece.cmu.edu> References: <200804110712.59895.jgoerzen@complete.org> <3F6A8321-5E6A-4FD9-97BA-B6BFABC136BE@ece.cmu.edu> Message-ID: <200804110808.13843.jgoerzen@complete.org> On Fri April 11 2008 8:02:07 am Brandon S. Allbery KF8NH wrote: > On Apr 11, 2008, at 8:12 , John Goerzen wrote: > > OK, I have referred to fifo(7) regarding this point. It seems I > > may need a > > loop trying over and over to open the FIFO in write mode. It also > > appears > > that ReadWriteMode appearing to work is Linux-specific, and this > > behavior is > > left undefined in POSIX. > > Undefined in POSIX, normal for Unix (and Linux originally promised > only POSIX semantics but was rejiggered some years back to behave > like Unix in this regard, because Unix programs rely on these > semantics and therefore failed on Linux). Hrm, can you define what OSs you mean when you say "Unix"? From jgoerzen at complete.org Fri Apr 11 09:15:37 2008 From: jgoerzen at complete.org (John Goerzen) Date: Fri Apr 11 09:11:07 2008 Subject: [Haskell-cafe] I/O system brokenness with named pipes In-Reply-To: References: <20080411103353.GE15362@scytale.galois.com> Message-ID: <200804110815.38285.jgoerzen@complete.org> On Fri April 11 2008 7:53:12 am Brandon S. Allbery KF8NH wrote: > On Apr 11, 2008, at 6:33 , Don Stewart wrote: > >> But I can't use writeFile to write data to it. Worse, it returns: > >> > >> *** Exception: /tmp/bakroller.zD0xHj/fifo: openFile: does not exist > >> (No such device or address) > > > > Hmm, I can get this to work, but only if I have another process > > waiting > > on the pipe already: > > Yep; that's one of the tricky parts of FIFOs. If you don't have the > read side *always* open, it behaves very nonintuitively. (But with > the read side always open, you will never receive an EOF.) > > This has nothing to do with Haskell; it's just the way FIFOs work. I wonder if we could document this behavior. I rarely use non-blocking I/O from C, and Haskell hides the fact that it's doing this, so the behavior is non-intuitive. Actually, better yet, I wonder if we could *fix* this behavior. Most programs can take a FIFO as arguments in a standard way, and it seems to me that this violates the principle of least surprise. Unfortunately, since we're talking about open here, we can't use select() or poll(). But I wonder if we couldn't use stat() to determine if something is a named pipe, and if so, enter a loop where we try to open it periodically? -- John From allbery at ece.cmu.edu Fri Apr 11 09:16:55 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Apr 11 09:12:28 2008 Subject: [Haskell-cafe] I/O system brokenness with named pipes In-Reply-To: <200804110808.13843.jgoerzen@complete.org> References: <200804110712.59895.jgoerzen@complete.org> <3F6A8321-5E6A-4FD9-97BA-B6BFABC136BE@ece.cmu.edu> <200804110808.13843.jgoerzen@complete.org> Message-ID: On Apr 11, 2008, at 9:08 , John Goerzen wrote: > On Fri April 11 2008 8:02:07 am Brandon S. Allbery KF8NH wrote: >> On Apr 11, 2008, at 8:12 , John Goerzen wrote: >>> OK, I have referred to fifo(7) regarding this point. It seems I >>> may need a >>> loop trying over and over to open the FIFO in write mode. It also >>> appears >>> that ReadWriteMode appearing to work is Linux-specific, and this >>> behavior is >>> left undefined in POSIX. >> >> Undefined in POSIX, normal for Unix (and Linux originally promised >> only POSIX semantics but was rejiggered some years back to behave >> like Unix in this regard, because Unix programs rely on these >> semantics and therefore failed on Linux). > > Hrm, can you define what OSs you mean when you say "Unix"? SunOS/Solaris, and in general the descendants of 4.xBSD and AT&T System III/V. Unless this is a different issue from the usual FIFO only-works-as-expected-if-both-ends-always-open problem. That is, unless the first opener opens read/write, neither a prospective writer nor a prospective reader will be capable of opening it at all; depending on OS you will get ENXIO or EPIPE or (in some rare implementations) EAGAIN. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From claus.reinke at talk21.com Fri Apr 11 09:36:44 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Apr 11 09:33:01 2008 Subject: [Haskell-cafe] Haskell IDE: Someone else interested in enhancingShim ? / How to contact author Benedikt Schmidt ? References: <20080408130526.GC8116@gmx.de> Message-ID: <00c501c89bd9$1a5bee20$c9298351@cr3lt> Hi Marc, when i first encountered Shim, i thought it was a nice idea, but with a lot less emphasis on the vim side than on the emacs side. also, iirc, Shim uses python's interprocess communication and i didn't want to ask vim users to install python to get haskell functionality. so i found that Shim didn't help me to simplify my own haskellmode plugins for vim [1]. perhaps all that has changed, and information just hasn't reached this list yet? but i like your suggestions, so i thought i'd comment as a non-Shim vim haskeller;-) > :GrepScope regex > Which greps the whole scope of all used packages by regex. > Very useful to find all functions taking/ returning some type etc i have something similar in my .ghci file [2], allowing things like ':grep Maybe :browse' or ':grep fold :browse'. it might be useful to have more direct access to it inside vim, but i'll wait for user interest on this one. > :ModulesExporting identifier > returns all modules exporting identifiers. Can be used to > add imports more automatically. already supported in my haskellmode plugins; used for |_?| browse Haddock entry for id under cursor |_.| qualify unqualified id under cursor |_i| add 'import ()' for id under cursor |_im| add 'import ' for id under cursor > Completion: > camelCaseMatching > Use pSL to get putStrLn i like this so much that i've implemented it, too (still testing/modifying, so it isn't online yet;-)! nice way to navigate/narrow down the huge menues of options one can otherwise get from completing short ids. there are some interesting issues, though: - i consider upper-case letters anchored at the start of patterns, so 'X' will ignore things like 'fromX' - apart from upper-case letters, i also use '.' for guidance, and as anchors, so that 'C.E.t' will get you directly to the 'Control.Exception.t' stuff, ignoring 'C[^.]E' stuff (depending on preferences, some might want '_' for guidance, too?) - i need to enable CamelCase matching only when there are no prefix matches, otherwise it will enlarge the completion options, offering unintended choices (and since those extra options will not have the same prefix, that prefix will disappear, eg if you actually mean 'pSomething', you try 'pS', and it will turn into 'p' -with a huge menu- because there are things like 'putStr', etc) - there are now more possible matches and more matching, so things get a bit slower.. - i'm having an odd issue that interferes with incrementally adding upper-case letters to narrow completion options CamelCase style; but hitting again works, so it might be a bug in my code? but quite useful when it works, so thanks for the suggestion!-) claus [1] http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/Vim [2] http://haskell.cs.yale.edu/haskellwiki/GHCi#Using_.ghci.2C_a_mini-tutorial (everyone, please add your own .ghci tips to that wiki page!-) From byorgey at gmail.com Fri Apr 11 10:33:04 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Fri Apr 11 10:29:13 2008 Subject: [Haskell-cafe] library version problem In-Reply-To: <878wzk27d8.fsf@nmd9999.imr.no> References: <5ae4f2ba0804101225g5c8a87e4u883acd5dd71e0f82@mail.gmail.com> <878wzk27d8.fsf@nmd9999.imr.no> Message-ID: <22fcbd520804110733q7abb092av1cc6b11fcc284d13@mail.gmail.com> On Fri, Apr 11, 2008 at 3:11 AM, Ketil Malde wrote: > "Galchin, Vasili" writes: > > >> ghci > > :m System.Posix > > > > I am getting the wrong version of the Unix package. I know this to be > true > > because I did > > ghc-pkg latest unix > > > > and got unix-2.3.0.0 > > > > I want unix.2.2.0.0 because this version has changes that I made > > Naturally, you'll get 2.3.0.0, since it has the highest version number! > > Either rename your modified version to 2.4 (or similar), specify the > exact version in your *application's* cabal file, or use > "ghc-pkg hide" to hide version 2.3.0.0 from view. > Actually, I'm pretty sure that Cabal does not take the visibility states of packages into account when selecting packages to fulfill dependencies, so ghc-pkg hide will not actually work. -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080411/a7c55cea/attachment.htm From cgibbard at gmail.com Fri Apr 11 11:53:42 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Fri Apr 11 11:49:14 2008 Subject: [Haskell-cafe] Control.Parallel.Strategies In-Reply-To: <3d96ac180804110427v1918de17j4c23b690e10a1623@mail.gmail.com> References: <3d96ac180804091409j5fc59b33i414a5676b95fa0a6@mail.gmail.com> <3d96ac180804091425n152b84c9scdba015f62d79a05@mail.gmail.com> <3d96ac180804091503l7a413eey4d28ae54f8a285d8@mail.gmail.com> <20080411094315.GB15362@scytale.galois.com> <3d96ac180804110427v1918de17j4c23b690e10a1623@mail.gmail.com> Message-ID: <89ca3d1f0804110853g1dec5393od0af23035e57ee17@mail.gmail.com> Out of interest, have you tried using parListChunk to break the work into larger pieces? It seems rather unlikely to help with this case as the parts are already pretty large, but perhaps it's worth a shot. From almeidaraf at gmail.com Fri Apr 11 13:35:28 2008 From: almeidaraf at gmail.com (Rafael C. de Almeida) Date: Fri Apr 11 13:31:13 2008 Subject: [Haskell-cafe] Monad proof Message-ID: <47FFA160.1080009@gmail.com> Hello, I was studying Monads and I was trying to think about new Monads I could define. So, a question poped into my mind: how is proof regarding the 3 Monad laws handled? I know that, aside from testing all the possible values (and there can be a lot of them), there's no general way to prove it. Nonetheless, I think that it would be insightful to see how people write those proofs for their monads -- specially for new user monads. Is there some article or some notes on proving that Monads are implemented correctly? []'s Rafael From rodrigogribeiro at gmail.com Fri Apr 11 13:39:08 2008 From: rodrigogribeiro at gmail.com (Rodrigo Geraldo) Date: Fri Apr 11 13:34:38 2008 Subject: [Haskell-cafe] Monad proof In-Reply-To: <47FFA160.1080009@gmail.com> References: <47FFA160.1080009@gmail.com> Message-ID: <21ba18fc0804111039l599adc5bh805620a05ff9eaab@mail.gmail.com> Did you see this? http://okmij.org/ftp/Computation/proving-monad-laws.txt []'s Rodrigo Geraldo Ribeiro. PhD student - UFMG On Fri, Apr 11, 2008 at 2:35 PM, Rafael C. de Almeida wrote: > Hello, > > I was studying Monads and I was trying to think about new Monads I could > define. So, a question poped into my mind: how is proof regarding the 3 > Monad laws handled? I know that, aside from testing all the possible values > (and there can be a lot of them), there's no general way to prove it. > Nonetheless, I think that it would be insightful to see how people write > those proofs for their monads -- specially for new user monads. Is there > some article or some notes on proving that Monads are implemented correctly? > > []'s > Rafael > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080411/82cd44ec/attachment.htm From haskell at list.mightyreason.com Fri Apr 11 15:33:33 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Fri Apr 11 15:29:19 2008 Subject: [Haskell-cafe] Re: Longest increasing subsequence In-Reply-To: References: <200804101820.49647.matt@asklater.com> Message-ID: My late night suggestions were nearly correct. I have actually written the code now. Once keeping track of indices, and a second time without them: > {-# LANGUAGE BangPatterns #-} > -- By Chris Kuklewicz, copyright 2008, BSD3 license > -- Longest increasing subsequence > -- (see http://en.wikipedia.org/wiki/Longest_increasing_subsequence) > import Data.List (foldl') > import Data.Map (Map) > import qualified Data.Map as M (empty,null,insert,findMin,findMax > ,splitLookup,deleteMin,delete) > > type DList a = [a] -> [a] > > lnds :: Ord a => [a] -> [a] > lnds = lnds_decode . lnds_fold > > lnds_fold :: Ord a => [a] -> Map a (DList a) > lnds_fold = foldl' process M.empty where > -- The Map keys, in sorted order, are the input values which > -- terminate the longest increasing chains of length 1,2,3,? > process mu x = > case M.splitLookup x mu of > (_,Just {},_) -> mu -- ignore x when it is already an end of a chain > > (map1,Nothing,map2) | M.null map2 -> > -- insert new maximum element x > if M.null mu > then M.insert x (x:) mu -- x is very first element > else let !xs = snd (M.findMax mu) > in M.insert x (xs . (x:)) mu > > | M.null map1 -> > -- replace minimum element with smaller x > M.insert x (x:) (M.deleteMin mu) > > | otherwise -> > -- replace previous element oldX with slightly smaller x > let !xs = snd (M.findMax map1) > !oldX = fst (M.findMin map2) -- slightly bigger key > !withoutOldX = M.delete oldX mu > in M.insert x (xs . (x:)) withoutOldX > > lnds_decode :: Ord a => Map a (DList a) -> [a] > lnds_decode mu | M.null mu = [] > | otherwise = snd (M.findMax mu) [] > > tests = [ ['b'..'m'] == (lnds $ ['m'..'s'] ++ ['b'..'g'] ++ ['a'..'c'] ++ ['h'..'k'] ++ ['h'..'m'] ++ ['d','c'..'a']) > , "" == lnds "" > , "a" == lnds "a" > , "a" == lnds "ba" > , "ab" == lnds "ab" > ] Comparing to wikipedia: The X[M[1]],X[M[2]],? sequence is strictly increasing. These are the ends of the current increasing chains of length 1,2,? and they are the keys to the Map in my code. The values of the map are the subsequences themselves, in DList form. Instead of pointing to the index of the previous element I just lookup '!xs' and append '(x:)' to that. Complexity: The strictness annotations ensure that the garbage collector can destroy any unreachable DList entries. The space usage is thus O(N) and may be O(1) for certain inputs (such as the best case of never-increasing input list). A strictly increasing input list is the worst case for space usage. The naive time complexity of 'process' for the i'th input value is O(log i). This can be double checked by looking at the time complexity of everything I import from Data.Map. Peak performance could be had by (1) adding the first element before the foldl' to avoid checking for this case in process (2a) accessing the internal map structure to optimize the splitLookup->delete->insert case into a single operation (2b) Using something like a zipper to access the to-be-deleted-and-replaced element of the map The (2a) and (2b) work because we know the changed key will go into the same 'slot' of the map as the old one. -- Chris From vigalchin at gmail.com Fri Apr 11 16:45:47 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri Apr 11 16:41:33 2008 Subject: [Haskell-cafe] library version problem In-Reply-To: <22fcbd520804110733q7abb092av1cc6b11fcc284d13@mail.gmail.com> References: <5ae4f2ba0804101225g5c8a87e4u883acd5dd71e0f82@mail.gmail.com> <878wzk27d8.fsf@nmd9999.imr.no> <22fcbd520804110733q7abb092av1cc6b11fcc284d13@mail.gmail.com> Message-ID: <5ae4f2ba0804111345g69bc7d30x131a4d4f11990bfa@mail.gmail.com> Right I am just trying to rebuild the unix package. No matter what version is present in the unix.cabal file, runhaskell Setup.hs configure produces an error concerning unix-2.3.0.0 Starting to get really frustrated over this. I just want to build a Unix package test case .. and now I can't even build the unix package itself. ghc-pkg seems to be at the center of this problem because the problem seems to have to deal with the package database. 1) On Linux(Ubuntu) where is the package database? 2) If ghc-pkg is indeed a Haskell program, how can I get the source to better understand the problem I am encountering on my own? On Fri, Apr 11, 2008 at 9:33 AM, Brent Yorgey wrote: > > On Fri, Apr 11, 2008 at 3:11 AM, Ketil Malde wrote: > > > "Galchin, Vasili" writes: > > > > >> ghci > > > :m System.Posix > > > > > > I am getting the wrong version of the Unix package. I know this to be > > true > > > because I did > > > ghc-pkg latest unix > > > > > > and got unix-2.3.0.0 > > > > > > I want unix.2.2.0.0 because this version has changes that I made > > > > Naturally, you'll get 2.3.0.0, since it has the highest version number! > > > > Either rename your modified version to 2.4 (or similar), specify the > > exact version in your *application's* cabal file, or use > > "ghc-pkg hide" to hide version 2.3.0.0 from view. > > > > Actually, I'm pretty sure that Cabal does not take the visibility states > of packages into account when selecting packages to fulfill dependencies, so > ghc-pkg hide will not actually work. > > -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080411/ecedbd27/attachment.htm From ryani.spam at gmail.com Fri Apr 11 20:40:22 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Fri Apr 11 20:35:52 2008 Subject: [Haskell-cafe] Monad proof In-Reply-To: <47FFA160.1080009@gmail.com> References: <47FFA160.1080009@gmail.com> Message-ID: <2f9b2d30804111740n487b04b8t9a714c504459291d@mail.gmail.com> I really like Chuan-Kai Lin's Unimo paper; in it he talks about defining a monad in terms of defining the behavior of its effects: http://web.cecs.pdx.edu/~cklin/papers/unimo-143.pdf Prompt is based on the same idea, with one small difference. While it's possible to write observation functions that break the monad laws with Unimo, it's actually impossible to do so with Prompt. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/MonadPrompt-1.0.0.1 This way you don't have to prove the Monad laws at all, you just write the code you want and some properties are guaranteed for you. -- ryan On 4/11/08, Rafael C. de Almeida wrote: > Hello, > > I was studying Monads and I was trying to think about new Monads I could > define. So, a question poped into my mind: how is proof regarding the 3 > Monad laws handled? I know that, aside from testing all the possible values > (and there can be a lot of them), there's no general way to prove it. > Nonetheless, I think that it would be insightful to see how people write > those proofs for their monads -- specially for new user monads. Is there > some article or some notes on proving that Monads are implemented correctly? > > []'s > Rafael > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From conal at conal.net Fri Apr 11 21:37:14 2008 From: conal at conal.net (Conal Elliott) Date: Fri Apr 11 21:32:41 2008 Subject: [Haskell-cafe] install trouble with SDL on win32+cygwin Message-ID: I'm trying to install the SDL package (on win32+cygwin), and configure isn't able to find my SDL.dll, though it's on my PATH. Any ideas? - Conal bash-3.2$ cabal install SDL 'SDL-0.5.3' is cached. [1 of 1] Compiling Main ( Setup.lhs, dist\setup/Main.o ) Linking dist\setup\setup.exe ... Configuring SDL-0.5.3... checking for sdl-config... no checking for sdl11-config... no configure: error: *** SDL not found! Get SDL from www.libsdl.org. If you already installed it, check it's in the path. If problem remains, please send a mail to the address that appears in ./configure --version indicating your platform, the version of configure script and the problem. cabal.exe: Error: some packages failed to install: SDL-0.5.3 failed during the configure step. The exception was: exit: ExitFailure 1 bash-3.2$ which SDL.dll /cygdrive/c/WINDOWS/system32/SDL.dll bash-3.2$ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080411/2d6972fd/attachment.htm From jake.mcarthur at gmail.com Fri Apr 11 22:18:39 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Fri Apr 11 22:14:31 2008 Subject: [Haskell-cafe] install trouble with SDL on win32+cygwin In-Reply-To: References: Message-ID: On Apr 11, 2008, at 8:37 PM, Conal Elliott wrote: > I'm trying to install the SDL package (on win32+cygwin), and > configure isn't able to find my SDL.dll, though it's on my PATH. > Any ideas? - Conal I think this has been a known (neglected?) issue for quite some time. That's why I am not using SDL right now. :( ? Jake From lrpalmer at gmail.com Fri Apr 11 23:55:03 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Fri Apr 11 23:50:28 2008 Subject: [Haskell-cafe] install trouble with SDL on win32+cygwin In-Reply-To: References: Message-ID: <7ca3f0160804112055y17083b6cx5b6ec563860db04d@mail.gmail.com> 2008/4/11 Conal Elliott : > I'm trying to install the SDL package (on win32+cygwin), and configure isn't > able to find my SDL.dll, though it's on my PATH. Any ideas? - Conal > > bash-3.2$ cabal install SDL > 'SDL-0.5.3' is cached. > [1 of 1] Compiling Main ( Setup.lhs, dist\setup/Main.o ) > Linking dist\setup\setup.exe ... > Configuring SDL-0.5.3... > checking for sdl-config... no I currently am not running cygwin, so I could be wrong, but the lack of sdl-config is a red flag. Have you installed sdl and sdl-devel (I think those are the package names) with the cygwin installer yet? Luke From vigalchin at gmail.com Fri Apr 11 23:55:55 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri Apr 11 23:51:21 2008 Subject: [Haskell-cafe] more on my ghc package issues Message-ID: <5ae4f2ba0804112055h755ce4daj2b160335bced1aee@mail.gmail.com> Hello, I "unregistered" unix-2.3.0.0. Now I cannot rebuild the Unix package. Please see the below log: vigalchin@ubuntu:~$ ghc-pkg latest unix unix-2.2.0.0 vigalchin@ubuntu:~$ ghc-pkg describe unix name: unix version: 2.2.0.0 license: BSD3 copyright: maintainer: libraries@haskell.org stability: homepage: package-url: description: This package gives you access to the set of operating system services standardised by POSIX 1003.1b (or the IEEE Portable Operating System Interface for Computing Environments - IEEE Std. 1003.1). . The package is not supported under Windows (except under Cygwin). category: author: exposed: True exposed-modules: System.Posix System.Posix.DynamicLinker.Module System.Posix.DynamicLinker.Prim System.Posix.Directory System.Posix.DynamicLinker System.Posix.Env System.Posix.Error System.Posix.Files System.Posix.IO System.Posix.Process System.Posix.Process.Internals System.Posix.Resource System.Posix.Temp System.Posix.Terminal System.Posix.Time System.Posix.Unistd System.Posix.User System.Posix.Signals System.Posix.Signals.Exts System.Posix.Semaphore System.Posix.SharedMem System.Posix.MQueue hidden-modules: import-dirs: /usr/local/lib/unix-2.2.0.0/ghc-6.8.2 library-dirs: /usr/local/lib/unix-2.2.0.0/ghc-6.8.2 hs-libraries: HSunix-2.2.0.0 extra-libraries: util dl extra-ghci-libraries: include-dirs: /usr/local/lib/unix-2.2.0.0/ghc-6.8.2/include includes: HsUnix.h execvpe.h depends: base-3.0.1.0 directory-1.0.0.0 hugs-options: cc-options: ld-options: framework-dirs: frameworks: haddock-interfaces: /usr/local/share/doc/unix-2.2.0.0/html/unix.haddock haddock-html: /usr/local/share/doc/unix-2.2.0.0/html vigalchin@ubuntu:~$ vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs configure unknown package: unix-2.3.0.0 In my .cabal file, I have specified the version as 2.2.0.0, 2.3.0.0 and 2.4.0.0 all with the same results: "unknown package: unix-2.3.0.0" Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080411/49569d52/attachment.htm From dan.doel at gmail.com Sat Apr 12 01:06:45 2008 From: dan.doel at gmail.com (Dan Doel) Date: Sat Apr 12 01:02:15 2008 Subject: [Haskell-cafe] Type families and GADTs in 6.9 Message-ID: <200804120106.45717.dan.doel@gmail.com> Hello, I've been playing around with type families off and on in 6.8, but, what with the implementation therein being reportedly incomplete, it's hard to know what I'm getting right and wrong, or what should work but doesn't and so on. So, I finally decided to take the plunge and install 6.9 (which, perhaps, isn't yet safe in that regard either, but, such is life :)). But, when I loaded up one of my programs, I got a type error. The subject is inductively defined tuples: ------------------------------------- {-# LANGUAGE GADTs, TypeFamilies, EmptyDataDecls, TypeOperators #-} data Zero data Succ n data Nat n where Zero :: Nat Zero Succ :: Nat n -> Nat (Succ n) data FZ data FS a data Fin fn n where FZ :: Fin FZ (Succ n) FS :: Fin fn n -> Fin (FS fn) (Succ n) f0 = FZ f1 = FS f0 f2 = FS f1 -- ... etc. data Nil data t ::: ts type family Length ts :: * type instance Length Nil = Zero type instance Length (t ::: ts) = Succ (Length ts) type family Lookup ts fn :: * type instance Lookup (t ::: ts) FZ = t type instance Lookup (t ::: ts) (FS fn) = Lookup ts fn infixr 4 ::: data Tuple ts where ZT :: Tuple Nil (:::) :: t -> !(Tuple ts) -> Tuple (t ::: ts) {- This type signature gets complained about in 6.8, but it seems like a sensible one: proj :: (Length ts ~ n) => Fin fn n -> Tuple ts -> Lookup ts fn Indexing the tuple by its length is also an option (which works). In any case, the code doesn't even work with the lenient 6.8 signature: -} proj :: Fin fn n -> Tuple ts -> Lookup ts fn proj FZ (v ::: vs) = v proj (FS fn) (v ::: vs) = proj fn vs ------------------------------------- The overall goal being Haskell-alike tuples with a single projection function that works for all of them, without having to use template haskell for instance (fst = proj f0, snd = proj f1, etc.). However, proj results in a type error: Occurs check: cannot construct the infinite type: t = Lookup (t ::: ts) fn In the pattern: v ::: vs In the definition of `proj': proj FZ (v ::: vs) = v Oddly (to me), if I reverse the clauses, the compiler doesn't complain about the FS case, still complaining about FZ. Now, my thought process here is that the pattern match against FZ (the value) requires fn to be FZ (the type), which should tell the compiler to solve "t ~ Lookup (t ::: ts) FZ" which is, of course, the first instance above. Am I doing something wrong, or have I bumped into as-yet-unimplemented functionality? Thanks for your time and help. -- Dan From j_prince2109 at hotmail.com Sat Apr 12 02:04:09 2008 From: j_prince2109 at hotmail.com (Jodi-Ann Prince) Date: Sat Apr 12 01:59:35 2008 Subject: [Haskell-cafe] do construct in wxhaskell Message-ID: hi, im working ona project, and im having problem loading some code in wxhaskell: onOpen :: Frame a -> TextCtrl b -> MenuItem c -> StatusField -> IO () onOpen f sw mclose status = do mbfname <- fileOpenDialog f False True "Open image" fileTypes "" "" case (mbfname) of (Nothing) -> return () (Just (fname)) -> do fileContent <- readFile fname set sw [text := fileContent] set mclose [enabled := True] set status [text := fname] return () i keep getting the error : "the last statement in a 'do' construct must be an expression." ive tried rearranging it many times, but i still get the same error. any help would be greatly appreciated. _________________________________________________________________ Connect to the next generation of MSN Messenger? http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080412/09659f79/attachment.htm From donn at avvanta.com Sat Apr 12 02:56:19 2008 From: donn at avvanta.com (Donn Cave) Date: Sat Apr 12 02:51:47 2008 Subject: [Haskell-cafe] I/O system brokenness with named pipes In-Reply-To: <200804110815.38285.jgoerzen@complete.org> References: <20080411103353.GE15362@scytale.galois.com> <200804110815.38285.jgoerzen@complete.org> Message-ID: <0EAFCC1E-AD81-4156-9CB2-12B952F5BD7A@avvanta.com> On Apr 11, 2008, at 6:15 AM, John Goerzen wrote: > I wonder if we could document this behavior. I rarely use non- > blocking I/O > from C, and Haskell hides the fact that it's doing this, so the > behavior is > non-intuitive. I have run into this problem, with Network.Socket (socket). If I remember right, ktrace showed me what was happening. This isn't my favorite thing about Haskell. Is there even a means provided to set it back to blocking? I couldn't find one, had to write my own FFI. It is not news to me that there is an issue with the Haskell thread implementation here, but since any non-native library I/O will similarly be blocking, we have to be able to live with this anyway. > Actually, better yet, I wonder if we could *fix* this behavior. Most > programs can take a FIFO as arguments in a standard way, and it > seems to me > that this violates the principle of least surprise. > > Unfortunately, since we're talking about open here, we can't use > select() or > poll(). But I wonder if we couldn't use stat() to determine if > something is > a named pipe, and if so, enter a loop where we try to open it > periodically? I am having a little trouble following this. Somewhere in the thread, the subject of ReadWrite pipe behavior came up, apparently for whatever reason you get non-blocking I/O this way too. But as long as you don't do that, then all you need for normal named pipe I/O is to set the file descriptor back to blocking ... right? Is the loop to work around the Haskell non-blocking, or the ReadWrite non-blocking? Donn Cave, donn@avvanta.com From abhay.parvate at gmail.com Sat Apr 12 03:24:53 2008 From: abhay.parvate at gmail.com (Abhay Parvate) Date: Sat Apr 12 03:20:21 2008 Subject: [Haskell-cafe] do construct in wxhaskell In-Reply-To: References: Message-ID: <3c4d5adf0804120024q6f05db38x3b83569f70fbcf76@mail.gmail.com> The indentation is not right; all the statements after the 'do' keyword need to start exactly at the same column. In particular, the 'f' in fileContent and 's' in set should be one below the other. And the 'return ()' also seems to be displaced; perhaps you want that also exactly below the last 'set' if it's the part of the last case. Hope it helps Abhay 2008/4/12 Jodi-Ann Prince : > hi, im working ona project, and im having problem loading some code in > wxhaskell: > > > onOpen :: Frame a -> TextCtrl b -> MenuItem c -> StatusField -> IO () > onOpen f sw mclose status = do mbfname <- fileOpenDialog f False True > "Open image" fileTypes "" "" > case (mbfname) of > (Nothing) -> return () > (Just (fname)) -> do > fileContent <- readFile fname > > set sw [text := fileContent] > > set mclose [enabled := True] > > set status [text := fname] > return () > > i keep getting the error : "the last statement in a 'do' construct must be > an expression." > ive tried rearranging it many times, but i still get the same error. any > help would be greatly appreciated. > > ------------------------------ > Connect to the next generation of MSN Messenger Get it now! > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080412/c3becc15/attachment-0001.htm From haskell at list.mightyreason.com Sat Apr 12 05:37:52 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Sat Apr 12 05:33:34 2008 Subject: [Haskell-cafe] Re: Type families and GADTs in 6.9 In-Reply-To: <200804120106.45717.dan.doel@gmail.com> References: <200804120106.45717.dan.doel@gmail.com> Message-ID: The length calculation looked complicated. So I reformulated it as a comparison using HasIndex. But ghc-6.8.2 was not inferring the recursive constraint on proj, so I split proj into proj_unsafe without the constraint and proj with the constraint checked only once. I also renamed ZT to Nil to be more consistent. > -- works in ghc 6.8.2 > {-# LANGUAGE GADTs, TypeFamilies, EmptyDataDecls, TypeOperators #-} > > data FZ > data FS a > > data Fin fn where > FZ :: Fin FZ > FS :: Fin fn -> Fin (FS fn) > > f0 = FZ > f1 = FS f0 > f2 = FS f1 > -- ... etc. > > data Nil > data t ::: ts > > infixr 4 ::: > > data Tuple ts where > Nil :: Tuple Nil > (:::) :: t -> !(Tuple ts) -> Tuple (t ::: ts) > > data HTrue > > type family Lookup ts fn :: * > type instance Lookup (t ::: ts) FZ = t > type instance Lookup (t ::: ts) (FS fn) = Lookup ts fn > > type family HasIndex ts fn :: * > type instance HasIndex (t ::: ts) FZ = HTrue > type instance HasIndex (t ::: ts) (FS fn) = HasIndex ts fn > > {-# INLINE proj #-} > proj :: (HasIndex tsT fnT ~ HTrue) => Fin fnT -> Tuple tsT -> Lookup tsT fnT > proj = proj_unsafe where > proj_unsafe :: Fin fnT -> Tuple tsT -> Lookup tsT fnT > proj_unsafe (FS fn) (_v ::: vs) = proj_unsafe fn vs > proj_unsafe FZ (v ::: _vs) = v > proj_unsafe _ Nil = error "Cannot proj Nil in proj_unsafe" > > fst' :: (HasIndex ts FZ ~ HTrue) => Tuple ts -> Lookup ts FZ > fst' = proj f0 > > snd' :: (HasIndex ts (FS FZ) ~ HTrue) => Tuple ts -> Lookup ts (FS FZ) > snd' = proj f1 > > pair :: Tuple (Char ::: (() ::: Nil)) > pair = 'a' ::: () ::: Nil > > q1 :: Char > q1 = fst' pair > > q2 :: () > q2 = snd' pair > > {- This won't compile > > q2 :: () > q2 = snd' ('a' ::: Nil) > -} From dan.doel at gmail.com Sat Apr 12 06:21:47 2008 From: dan.doel at gmail.com (Dan Doel) Date: Sat Apr 12 06:17:15 2008 Subject: [Haskell-cafe] Re: Type families and GADTs in 6.9 In-Reply-To: References: <200804120106.45717.dan.doel@gmail.com> Message-ID: <200804120621.47917.dan.doel@gmail.com> On Saturday 12 April 2008, ChrisK wrote: > The length calculation looked complicated. So I reformulated it as a > comparison using HasIndex. But ghc-6.8.2 was not inferring the recursive > constraint on proj, so I split proj into proj_unsafe without the constraint > and proj with the constraint checked only once. I also renamed ZT to Nil > to be more consistent. Ah, well, in fact, you can also structure things this way: ------------------------------ data Tuple ts n where Nil :: Tuple Nil Zero (:::) :: t -> Tuple ts n -> Tuple (t ::: ts) (Succ n) proj :: Fin fn n -> Tuple ts n -> Lookup ts fn -- proj is the same as my original mail ------------------------------ That ensures that a tuple of size n is indexed by the finite set of size n. The two are a natural fit for one another, since there are as many elements in the tuple as there are in the finite set. This actually works on 6.8.2 (modulo having to tell GHCi what result type it ought to get in some cases, since it thinks there is no Show instance for Lookup (Int ::: Nil) FZ :)), and gives type errors if you try to do, say 'proj f2 ('a' ::: 'b' ::: Nil)': f2 :: Fin (FS (FS FZ)) (Succ (Succ (Succ n))) tuple :: Tuple (Char ::: Char ::: Nil) (Succ (Succ Zero)) => Succ (Succ (Succ n)) ~ Succ (Succ Zero) -- no can do My main confusion was that none of this works in 6.9, seemingly because the pattern match against FZ in proj fails to refine the type variable fn to FZ, which is necessary to solve the equation 't ~ Lookup (t ::: ts) fn', so instead it tells me I'm asking for an infinite type. However, the type checker not figuring out that Succ n ~ Length (t ::: ts) implies that n ~ Length ts in the recursive call is, I think, the problem I was having with the original alternate signature. I suppose it's less trivial than HasIndex, but you say it didn't like that either. It'd be interesting to know if that sort of thing will be possible in 6.10, or if it's unreasonable to expect that to work. Cheers. -- Dan From thomas at cs.ru.nl Sat Apr 12 08:39:34 2008 From: thomas at cs.ru.nl (Thomas van Noort) Date: Sat Apr 12 08:35:01 2008 Subject: [Haskell-cafe] ANNOUNCE: Generic Haskell 1.80 (Emerald) Message-ID: <49768.82.157.212.81.1208003974.squirrel@squirrel.science.ru.nl> Generic Haskell version 1.80 (Emerald) ====================================== We are happy to announce the fifth release of Generic Haskell, an extension of Haskell that facilitates generic programming. Generic Haskell includes the following features: * type-indexed values -- generic functions that can be instantiated on all Haskell data types. * type-indexed types -- types which are indexed over the type constructors underlying Haskell datatypes. The Generic Haskell compiler takes Generic Haskell source and produces Haskell code. Changes since 1.62 (Diamond) ---------------------------- * Generic views for generic types [1] are now supported. * The implementation of type-indexed types is improved. Download -------- The Generic Haskell compiler is available in source and binary distributions. Binaries for Linux, Windows, and MacOSX are available. These are available from: http://www.generic-haskell.org/compiler.html The documentation is also available separately from that page. For more general information, point your browser to: http://www.generic-haskell.org Why Generic Haskell? -------------------- Software development often consists of designing datatypes, around which functionality is added. Some functionality is datatype specific, whereas other functionality is defined on almost all datatypes in such a way that it depends only on the structure of the datatype. A function that works on many datatypes in this way is called a generic function. Examples of generic functionality include editing, pretty-printing or storing a value in a database, and comparing two values for equality. Since datatypes often change and new datatypes are introduced, we have developed Generic Haskell, an extension of the functional programming language Haskell that supports generic definitions, to save the programmer from (re)writing instances of generic functions. The original design of Generic Haskell is based on work by Ralf Hinze. Pleasant programming, The Generic Haskell Team at Utrecht University info@generic-haskell.org [1] Thomas van Noort. Generic views for generic types. Master's thesis, Utrecht University, 2008. From pablo at babel.ls.fi.upm.es Sat Apr 12 09:34:28 2008 From: pablo at babel.ls.fi.upm.es (Pablo Nogueira) Date: Sat Apr 12 09:29:54 2008 Subject: [Haskell-cafe] ANNOUNCE: Generic Haskell 1.80 (Emerald) In-Reply-To: <49768.82.157.212.81.1208003974.squirrel@squirrel.science.ru.nl> References: <49768.82.157.212.81.1208003974.squirrel@squirrel.science.ru.nl> Message-ID: On 12/04/2008, Thomas van Noort wrote: > Generic Haskell includes the following features: > > * type-indexed values -- generic functions that can be > instantiated on all Haskell data types. ^^^ I have perused the manual and wonder if parametric types with class constraints are now supported or are not considered Haskell types. I'm thinking of types such as data Ord a => BinTree a = Leaf | Node a (BinTree a) (BinTree a) data Functor f => GRose f a = GLeaf | GNode a (f(GTree f a)) From miguelimo38 at yandex.ru Sat Apr 12 09:54:45 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Sat Apr 12 09:50:24 2008 Subject: [Haskell-cafe] ANNOUNCE: Generic Haskell 1.80 (Emerald) In-Reply-To: <49768.82.157.212.81.1208003974.squirrel@squirrel.science.ru.nl> References: <49768.82.157.212.81.1208003974.squirrel@squirrel.science.ru.nl> Message-ID: <15B3D62E-20A5-48DE-8BC2-E9101AD35BCB@yandex.ru> > Generic Haskell includes the following features: > > * type-indexed values -- generic functions that can be > instantiated on all Haskell data types. How come I haven't ever heard about such a thing?! From noteed at gmail.com Sat Apr 12 10:09:22 2008 From: noteed at gmail.com (minh thu) Date: Sat Apr 12 10:04:47 2008 Subject: [Haskell-cafe] help understanding pj-lester-book Message-ID: <40a414c20804120709j19b5f6c4n40c6f35ae122cdf@mail.gmail.com> Hi! I don't understand something in there : pj-lester-book : Implementing functional languages: a tutorial by Simon Peyton Jones and David Lester, available at http://research.microsoft.com/~simonpj/Papers/pj-lester-book/ eval/apply : Making a Fast Curry: Push/Enter vs. Eval/Apply for Higher-order Languages by Simon Marlow and Simon Peyton Jones, available at http://www.haskell.org/~simonmar/papers/ The introduction in eval/apply states the arity of a function and the number of arguments in a call can match or differs (and it should be dealt with). In pj-lester-book (bottom of page 46 and top of page 47), it is stated that if the program has been type-cheched, the underflow check is unnecessary. When continuing to the G-machine then to the TIM-machine chapters, I haven't found discussion of an arity-mismatch. What am I missing ? Thanks a lot, Thu From bulat.ziganshin at gmail.com Sat Apr 12 10:10:04 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Apr 12 10:05:41 2008 Subject: [Haskell-cafe] ANNOUNCE: Generic Haskell 1.80 (Emerald) In-Reply-To: <15B3D62E-20A5-48DE-8BC2-E9101AD35BCB@yandex.ru> References: <49768.82.157.212.81.1208003974.squirrel@squirrel.science.ru.nl> <15B3D62E-20A5-48DE-8BC2-E9101AD35BCB@yandex.ru> Message-ID: <378826474.20080412181004@gmail.com> Hello Miguel, Saturday, April 12, 2008, 5:54:45 PM, you wrote: > How come I haven't ever heard about such a thing?! it's an overview of generic haskell programming systems: http://dfa.imn.htwk-leipzig.de/~waldmann/draft/meta-haskell/second.pdf ask here about final version of this paper -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Sat Apr 12 10:12:46 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Apr 12 10:08:56 2008 Subject: [Haskell-cafe] ANNOUNCE: Generic Haskell 1.80 (Emerald) In-Reply-To: <378826474.20080412181004@gmail.com> References: <49768.82.157.212.81.1208003974.squirrel@squirrel.science.ru.nl> <15B3D62E-20A5-48DE-8BC2-E9101AD35BCB@yandex.ru> <378826474.20080412181004@gmail.com> Message-ID: <432181714.20080412181246@gmail.com> Hello Bulat, Saturday, April 12, 2008, 6:10:04 PM, you wrote: > it's an overview of generic haskell programming systems: found longer paper myself: Comparing Approaches to Generic Programming in Haskell http://www.cs.uu.nl/~johanj/publications/ComparingGP.pdf -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From byorgey at gmail.com Sat Apr 12 10:17:26 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Sat Apr 12 10:12:50 2008 Subject: [Haskell-cafe] library version problem In-Reply-To: <5ae4f2ba0804111345g69bc7d30x131a4d4f11990bfa@mail.gmail.com> References: <5ae4f2ba0804101225g5c8a87e4u883acd5dd71e0f82@mail.gmail.com> <878wzk27d8.fsf@nmd9999.imr.no> <22fcbd520804110733q7abb092av1cc6b11fcc284d13@mail.gmail.com> <5ae4f2ba0804111345g69bc7d30x131a4d4f11990bfa@mail.gmail.com> Message-ID: <22fcbd520804120717l13fb6d94yad2183373c19e06@mail.gmail.com> On Fri, Apr 11, 2008 at 4:45 PM, Galchin, Vasili wrote: > Right I am just trying to rebuild the unix package. No matter what version > is present in the unix.cabal file, > > runhaskell Setup.hs configure > > produces an error concerning unix-2.3.0.0 > Have you tried doing a 'runhaskell Setup.hs clean' first? You should also try unregistering the unix-2.3 package (ghc-pkg unregister unix-2.3.0.0). > > Starting to get really frustrated over this. I just want to build a Unix > package test case .. and now I can't even build the unix package itself. > > ghc-pkg seems to be at the center of this problem because the problem > seems to have to deal with the package database. > > 1) On Linux(Ubuntu) where is the package database? > The global package database should be somewhere like /usr/lib/ghc-6.6.1/package.conf on my system it is in /usr/local/lib/ghc-6.8.2/package.conf. The local (user) package database is in something like ~/.ghc/i386-linux-version/package.conf. > 2) If ghc-pkg is indeed a Haskell program, how can I get the source to > better understand the problem I am encountering on my own? > It is part of the ghc source, in utils/ghc-pkg. -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080412/6930d726/attachment.htm From byorgey at gmail.com Sat Apr 12 10:20:54 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Sat Apr 12 10:16:17 2008 Subject: [Haskell-cafe] more on my ghc package issues In-Reply-To: <5ae4f2ba0804112055h755ce4daj2b160335bced1aee@mail.gmail.com> References: <5ae4f2ba0804112055h755ce4daj2b160335bced1aee@mail.gmail.com> Message-ID: <22fcbd520804120720j2de9266i3bb27695cd8c8e05@mail.gmail.com> ] > > vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs configure > unknown package: unix-2.3.0.0 > I suggested this in my other message, before I saw this one, but just to be sure: does it help to do 'runhaskell Setup.hs clean' before doing the configure step? -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080412/825d174b/attachment.htm From thomas at cs.ru.nl Sat Apr 12 11:12:21 2008 From: thomas at cs.ru.nl (Thomas van Noort) Date: Sat Apr 12 11:22:56 2008 Subject: [Haskell-cafe] ANNOUNCE: Generic Haskell 1.80 (Emerald) In-Reply-To: References: <49768.82.157.212.81.1208003974.squirrel@squirrel.science.ru.nl> Message-ID: <50032.82.157.212.81.1208013141.squirrel@squirrel.science.ru.nl> That's a good question. Unfortunately, only Haskell98 types are currently supported by the Generic Haskell compiler. But at first sight, implementing support for parametric types with class constraints is not too hard. Class constraints of a parametric type need to be propagated to its generated structure type. Regards, Thomas > On 12/04/2008, Thomas van Noort wrote: > >> Generic Haskell includes the following features: >> >> * type-indexed values -- generic functions that can be >> instantiated on all Haskell data types. > ^^^ > > I have perused the manual and wonder if parametric types with class > constraints are now supported or are not considered Haskell types. I'm > thinking of types such as > > data Ord a => BinTree a = Leaf | Node a (BinTree a) (BinTree a) > data Functor f => GRose f a = GLeaf | GNode a (f(GTree f a)) > From vigalchin at gmail.com Sat Apr 12 12:27:16 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat Apr 12 12:22:39 2008 Subject: [Haskell-cafe] more on my ghc package issues In-Reply-To: <22fcbd520804120720j2de9266i3bb27695cd8c8e05@mail.gmail.com> References: <5ae4f2ba0804112055h755ce4daj2b160335bced1aee@mail.gmail.com> <22fcbd520804120720j2de9266i3bb27695cd8c8e05@mail.gmail.com> Message-ID: <5ae4f2ba0804120927y3b453b56v77c732f32308b426@mail.gmail.com> vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs cleanup unknown package: unix-2.3.0.0 no it doesn't. Vasili On Sat, Apr 12, 2008 at 9:20 AM, Brent Yorgey wrote: > ] > > > > vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs > > configure > > unknown package: unix-2.3.0.0 > > > > I suggested this in my other message, before I saw this one, but just to > be sure: does it help to do 'runhaskell Setup.hs clean' before doing the > configure step? > > -Brent > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080412/77f03800/attachment.htm From allbery at ece.cmu.edu Sat Apr 12 12:30:10 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Apr 12 12:25:37 2008 Subject: [Haskell-cafe] more on my ghc package issues In-Reply-To: <5ae4f2ba0804120927y3b453b56v77c732f32308b426@mail.gmail.com> References: <5ae4f2ba0804112055h755ce4daj2b160335bced1aee@mail.gmail.com> <22fcbd520804120720j2de9266i3bb27695cd8c8e05@mail.gmail.com> <5ae4f2ba0804120927y3b453b56v77c732f32308b426@mail.gmail.com> Message-ID: <83B4374E-6A2D-4818-B6ED-7E8A67F93B83@ece.cmu.edu> On Apr 12, 2008, at 12:27 , Galchin, Vasili wrote: > vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs > cleanup > unknown package: unix-2.3.0.0 > > no it doesn't. I suspect the Cabal stuff has a dependency on the unix package (at least on POSIXish systems, probably via the filepath stuff) and by deregistering unix-2.3.0.0 which Cabal was built against you broke it. Probably you need to do a full reinstall of GHC to recover at this point. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From vigalchin at gmail.com Sat Apr 12 12:36:06 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat Apr 12 12:31:30 2008 Subject: [Haskell-cafe] more on my ghc package issues In-Reply-To: <83B4374E-6A2D-4818-B6ED-7E8A67F93B83@ece.cmu.edu> References: <5ae4f2ba0804112055h755ce4daj2b160335bced1aee@mail.gmail.com> <22fcbd520804120720j2de9266i3bb27695cd8c8e05@mail.gmail.com> <5ae4f2ba0804120927y3b453b56v77c732f32308b426@mail.gmail.com> <83B4374E-6A2D-4818-B6ED-7E8A67F93B83@ece.cmu.edu> Message-ID: <5ae4f2ba0804120936n94fb40aj192ad9b6c6e1ea67@mail.gmail.com> I was afraid of the install. Hopefully with the Ubuntu package manager it will be fairly painless. Thanks, Vasili On Sat, Apr 12, 2008 at 11:30 AM, Brandon S. Allbery KF8NH < allbery@ece.cmu.edu> wrote: > > On Apr 12, 2008, at 12:27 , Galchin, Vasili wrote: > > > vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs cleanup > > unknown package: unix-2.3.0.0 > > > > no it doesn't. > > > > I suspect the Cabal stuff has a dependency on the unix package (at least > on POSIXish systems, probably via the filepath stuff) and by deregistering > unix-2.3.0.0 which Cabal was built against you broke it. Probably you need > to do a full reinstall of GHC to recover at this point. > > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080412/6503edc1/attachment.htm From pablo at babel.ls.fi.upm.es Sat Apr 12 13:14:19 2008 From: pablo at babel.ls.fi.upm.es (Pablo Nogueira) Date: Sat Apr 12 13:09:49 2008 Subject: [Haskell-cafe] ANNOUNCE: Generic Haskell 1.80 (Emerald) In-Reply-To: <50032.82.157.212.81.1208013141.squirrel@squirrel.science.ru.nl> References: <49768.82.157.212.81.1208003974.squirrel@squirrel.science.ru.nl> <50032.82.157.212.81.1208013141.squirrel@squirrel.science.ru.nl> Message-ID: On 12/04/2008, Thomas van Noort wrote: > That's a good question. Unfortunately, only Haskell98 types are currently > supported by the Generic Haskell compiler. I thought constrained types were Haskell 98, but now I'm in doubt... > But at first sight, implementing support for parametric types with class > constraints is not too hard. Class constraints of a parametric type need > to be propagated to its generated structure type. Certainly, but there are a few difficulties for higher-kinded types. An arguable solution: http://portal.acm.org/citation.cfm?id=1159868 The reason I mention this is because Scrap your Boilerplate supports them whereas GH does not, and I'm not aware this has been taken into account when comparing these two approaches in the work cited by Bulat on this thread. From thomas at cs.ru.nl Sat Apr 12 13:33:32 2008 From: thomas at cs.ru.nl (Thomas van Noort) Date: Sat Apr 12 13:44:02 2008 Subject: [Haskell-cafe] ANNOUNCE: Generic Haskell 1.80 (Emerald) In-Reply-To: References: <49768.82.157.212.81.1208003974.squirrel@squirrel.science.ru.nl> <50032.82.157.212.81.1208013141.squirrel@squirrel.science.ru.nl> Message-ID: <50652.82.157.212.81.1208021612.squirrel@squirrel.science.ru.nl> > On 12/04/2008, Thomas van Noort wrote: > >> That's a good question. Unfortunately, only Haskell98 types are >> currently >> supported by the Generic Haskell compiler. > > I thought constrained types were Haskell 98, but now I'm in doubt... I'm not 100% sure either, but according to the Haskell98 language report, constrained types are not part of Haskell98, http://haskell.org/onlinereport/basic.html , but are described as GHC language features, http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type-extensions.html > >> But at first sight, implementing support for parametric types with >> class >> constraints is not too hard. Class constraints of a parametric type >> need >> to be propagated to its generated structure type. > > Certainly, but there are a few difficulties for higher-kinded types. > An arguable solution: http://portal.acm.org/citation.cfm?id=1159868 > > The reason I mention this is because Scrap your Boilerplate supports > them whereas GH does not, and I'm not aware this has been taken into > account when comparing these two approaches in the work cited by Bulat > on this thread. > This has certainly been taken into account when comparing approaches to generic programming. I quote from page 18/19 from the work you and Bulat cited: == Full reflexivity. A generic programming language is fully reflexive if a generic function can be used on any type that is definable in the language. Generic Haskell is fully reflexive with respect to the types that are definable in Haskell 98, except for constraints in data-type definitions. So a data type of the form data Eq a => Set a = NilSet | ConsSet a (Set a) is not dealt with correctly. However, constrained data types are a corner case in Haskell and can easily be simulated using other means. Furthermore, Nogueira [69] shows how to make Generic Haskell work for data types with constraints. == Thus, full reflexivity of an approach is taken into account. This suggests constrained types are part of Haskell98. So, I'm a bit confused at the moment as well. Regards, Thomas From allbery at ece.cmu.edu Sat Apr 12 13:51:31 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Apr 12 13:47:01 2008 Subject: [Haskell-cafe] ANNOUNCE: Generic Haskell 1.80 (Emerald) In-Reply-To: <50652.82.157.212.81.1208021612.squirrel@squirrel.science.ru.nl> References: <49768.82.157.212.81.1208003974.squirrel@squirrel.science.ru.nl> <50032.82.157.212.81.1208013141.squirrel@squirrel.science.ru.nl> <50652.82.157.212.81.1208021612.squirrel@squirrel.science.ru.nl> Message-ID: <33890D00-EB03-465A-B4AF-09A24783667E@ece.cmu.edu> On Apr 12, 2008, at 13:33 , Thomas van Noort wrote: >> On 12/04/2008, Thomas van Noort wrote: >> >>> That's a good question. Unfortunately, only Haskell98 types are >>> currently >>> supported by the Generic Haskell compiler. >> >> I thought constrained types were Haskell 98, but now I'm in doubt... > > language. Generic Haskell is fully reflexive with respect to the types > that are definable in Haskell 98, except for constraints in data-type > definitions. So a data type of the form > > data Eq a => Set a = NilSet | ConsSet a (Set a) > > is not dealt with correctly. However, constrained data types are a > corner > case in Haskell and can easily be simulated using other means. I was under the impression "corner case" here means that H98 lets you write it but doesn't handle it very sanely (a GHC-specific extension being needed to achieve that). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From conal at conal.net Sat Apr 12 22:48:50 2008 From: conal at conal.net (Conal Elliott) Date: Sat Apr 12 22:44:13 2008 Subject: [Haskell-cafe] install trouble with SDL on win32+cygwin In-Reply-To: <7ca3f0160804112055y17083b6cx5b6ec563860db04d@mail.gmail.com> References: <7ca3f0160804112055y17083b6cx5b6ec563860db04d@mail.gmail.com> Message-ID: Now I have sdl-config, but still not able to build. Does *anyone* have the SDL package running on Windows? If not, is GLFW the recommended cross-platform GL toolkit? Thanks, - Conal On Fri, Apr 11, 2008 at 8:55 PM, Luke Palmer wrote: > 2008/4/11 Conal Elliott : > > I'm trying to install the SDL package (on win32+cygwin), and configure > isn't > > able to find my SDL.dll, though it's on my PATH. Any ideas? - Conal > > > > bash-3.2$ cabal install SDL > > 'SDL-0.5.3' is cached. > > [1 of 1] Compiling Main ( Setup.lhs, dist\setup/Main.o ) > > Linking dist\setup\setup.exe ... > > Configuring SDL-0.5.3... > > checking for sdl-config... no > > I currently am not running cygwin, so I could be wrong, but the lack > of sdl-config is a red flag. Have you installed sdl and sdl-devel (I > think those are the package names) with the cygwin installer yet? > > Luke > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080412/986f51d5/attachment.htm From jake.mcarthur at gmail.com Sat Apr 12 23:43:05 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Sat Apr 12 23:38:34 2008 Subject: [Haskell-cafe] install trouble with SDL on win32+cygwin In-Reply-To: References: <7ca3f0160804112055y17083b6cx5b6ec563860db04d@mail.gmail.com> Message-ID: <6EEFCD94-465D-404D-9786-551658AF8516@gmail.com> On Apr 12, 2008, at 9:48 PM, Conal Elliott wrote: > If not, is GLFW the recommended cross-platform GL toolkit? Don't forget there is GLUT as well. ? Jake From bjpop at csse.unimelb.edu.au Sat Apr 12 23:52:39 2008 From: bjpop at csse.unimelb.edu.au (Bernie Pope) Date: Sat Apr 12 23:41:25 2008 Subject: [Haskell-cafe] help understanding pj-lester-book In-Reply-To: <40a414c20804120709j19b5f6c4n40c6f35ae122cdf@mail.gmail.com> References: <40a414c20804120709j19b5f6c4n40c6f35ae122cdf@mail.gmail.com> Message-ID: On 13/04/2008, at 12:09 AM, minh thu wrote: > Hi! > > I don't understand something in there : > > pj-lester-book : > Implementing functional languages: a tutorial > by Simon Peyton Jones and David Lester, > available at http://research.microsoft.com/~simonpj/Papers/pj- > lester-book/ > > eval/apply : > Making a Fast Curry: Push/Enter vs. Eval/Apply for Higher-order > Languages > by Simon Marlow and Simon Peyton Jones, > available at http://www.haskell.org/~simonmar/papers/ > > The introduction in eval/apply states the arity of a function and the > number of arguments in a call can match or differs (and it should be > dealt with). > > In pj-lester-book (bottom of page 46 and top of page 47), it is stated > that if the program has been type-cheched, the underflow check is > unnecessary. > When continuing to the G-machine then to the TIM-machine chapters, I > haven't found discussion of an arity-mismatch. > > What am I missing ? Hi Minh, If I understand the pj-lester book properly, what they are saying is: if you have an expression which is a function application, and type checking has determined that the result of the expression is _not a function_, then you can be sure that the outermost redex in the expression has enough arguments. If it is not a function then it cannot be a partial application. Thus you don't have to do the underflow check for that redex. You either have a saturated application or an over saturated application, but either way there is guaranteed to be enough arguments. Unfortunately, instead of saying "not a function", they say "a number, or say, a list". If you are writing a compiler, and you are about to generate code for a function application, and the type checker tells you the result is not a function, then you can omit generating the code for the underflow test - which is a performance gain. I believe the eval/apply paper is referring to the general case of a function application, where you don't always know that the result is not a function. For example, suppose you are generating code for the "map" function. In the body of "map" you have: case list of Nil -> Nil Cons x xs -> Cons (f x) (map f xs) In the application (f x), you can't statically determine if it is saturated or not, because it depends on the arity of the function subsituted for "f", which is of course unknown. (You could turn it into a known by doing an arity-based specialisation of the program, but that is a fairly heavyweight option, which would require multiple versions of functions like map.) Cheers, Bernie. From vigalchin at gmail.com Sun Apr 13 00:33:19 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sun Apr 13 00:28:41 2008 Subject: [Haskell-cafe] more on my ghc package issues In-Reply-To: <83B4374E-6A2D-4818-B6ED-7E8A67F93B83@ece.cmu.edu> References: <5ae4f2ba0804112055h755ce4daj2b160335bced1aee@mail.gmail.com> <22fcbd520804120720j2de9266i3bb27695cd8c8e05@mail.gmail.com> <5ae4f2ba0804120927y3b453b56v77c732f32308b426@mail.gmail.com> <83B4374E-6A2D-4818-B6ED-7E8A67F93B83@ece.cmu.edu> Message-ID: <5ae4f2ba0804122133m64651017i7ed6f047ce61756d@mail.gmail.com> 1) I did an Ubuntu purge followed by an install. Afterwards I rebuilt ghc 6.8.2. The same d*mn "unknown package: unix-2.3.0.0" message when I try to build unix and bytestring via runhaskell Setup.hs configure. 2) This strongly looks like the package database manager, i.e. ghc-pkg. Source please so I can understand where this d*amn "unknown package: unix-2.3.0.0" message is coming from and why? 3) Serious rant mode on ... I am a computer industry veteran(decades) who is trying to convince, coggle, etc. younger colleagues about the usefulness of FPLs for correctness, etc, and then => "unknown package ....". V. On Sat, Apr 12, 2008 at 11:30 AM, Brandon S. Allbery KF8NH < allbery@ece.cmu.edu> wrote: > > On Apr 12, 2008, at 12:27 , Galchin, Vasili wrote: > > > vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs cleanup > > unknown package: unix-2.3.0.0 > > > > no it doesn't. > > > > I suspect the Cabal stuff has a dependency on the unix package (at least > on POSIXish systems, probably via the filepath stuff) and by deregistering > unix-2.3.0.0 which Cabal was built against you broke it. Probably you need > to do a full reinstall of GHC to recover at this point. > > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080412/8732beb0/attachment.htm From duncan.coutts at worc.ox.ac.uk Sun Apr 13 05:54:35 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 13 05:50:00 2008 Subject: [Haskell-cafe] more on my ghc package issues In-Reply-To: <5ae4f2ba0804122133m64651017i7ed6f047ce61756d@mail.gmail.com> References: <5ae4f2ba0804112055h755ce4daj2b160335bced1aee@mail.gmail.com> <22fcbd520804120720j2de9266i3bb27695cd8c8e05@mail.gmail.com> <5ae4f2ba0804120927y3b453b56v77c732f32308b426@mail.gmail.com> <83B4374E-6A2D-4818-B6ED-7E8A67F93B83@ece.cmu.edu> <5ae4f2ba0804122133m64651017i7ed6f047ce61756d@mail.gmail.com> Message-ID: <1208080475.9923.63.camel@dell.linuxdev.us.dell.com> On Sat, 2008-04-12 at 23:33 -0500, Galchin, Vasili wrote: > 2) This strongly looks like the package database manager, i.e. > ghc-pkg. Source please so I can understand where this d*amn "unknown > package: unix-2.3.0.0" message is coming from and why? Yes, ghc/ghc-pkg is giving this message because you're trying to use a package that depends on a package that you unregistered. In your case, you unregistered unix-2.3.0.0 but process-1.0.0.0 depended on that. Cabal depends on process-1.0.0.0 which means you now cannot runghc Setup.hs scripts because they all import Cabal. Look at the output of ghc-pkg list. It marks in {} the packages that are broken due to missing dependencies. Remember you also have two package databases, the per-user one and the global one. The per-user one is stored under ~/.ghc You can see the exact path in the ghc-pkg list output. The packages from the user db mask those from the global db, so if you have messed up the per-user one then you will still get problems even if you reset the global one to default. If you're just trying to get back to a known state then you can delete the per-user ghc package db. ghc-pkg will re-create it next time you register a package as a user. > 3) Serious rant mode on ... I am a computer industry veteran(decades) > who is trying to convince, coggle, etc. younger colleagues about the > usefulness of FPLs for correctness, etc, and then => "unknown > package ....". The error messages from ghc-pkg are not very helpful and it does not prevent you from removing packages which other packages still depend on. The best advice at the moment is, don't un-register packages, at least not without considering what other packages still depend on them. There's no easy way of doing a reverse dependency lookup I think yet via ghc-pkg. You can see direct dependencies, eg $ ghc-pkg field containers depends depends: base-3.0.1.0 array-0.1.0.0 As it happens, the latest version of Cabal gives a much better error message in the case that you try to configure a package that depends on a broken package. It says exactly which package is broken due to which missing dependency. In this case we'd get a message like: The following installed packages are broken because other packages they depend on are missing. These broken packages must be rebuilt before they can be used. package process-1.0.0.0 is broken due to missing package unix-2.3.0.0 It would be nice if ghc/ghci/runghc could give a similarly helpful error message. Duncan From johan.tibell at gmail.com Sun Apr 13 07:59:45 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun Apr 13 07:55:08 2008 Subject: [Haskell-cafe] RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) Message-ID: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> Good day hackers, The Python community have been successful in standardizing an interface between web server and applications or frameworks resulting in users having more control over their web stack by being able to pick frameworks independently from web servers, and vice versa. I propose we try to do the same for Haskell. I've written half a draft for a Haskell version of Python's PEP 333 [1]. If you're interested in taking part in this effort please read through the Python spec first (as it is way more complete and you can understand this proposal better by reading it, I've skipped some important issues in my first draft) and then go read the Haskell spec [2]. I'm particularly interesting in feedback regarding: * Doing in this way won't work as it violates HTTP/CGI spec part X, Y and Z (the Python spec takes lots of things from the CGI spec including naming and semantics). * My server/framework could never provide/be run under this interface. * This interface has bad performance by design. * Using a different set of data types would work better. The spec needs to be extended to cover all the corners of HTTP. Some parts need to be motivated better. It is easier for me to motivate things if people would tell me what parts are badly motivated. Note: I'm open to a complete rewrite if needed. I'm not wedded to the current design and/or wording. In fact parts of the wording is borrowed from the Python spec. The parts with bad grammar are all mine. 1. http://www.python.org/dev/peps/pep-0333/ 2. http://www.haskell.org/haskellwiki/WebApplicationInterface -- Johan From manlio_perillo at libero.it Sun Apr 13 10:21:42 2008 From: manlio_perillo at libero.it (Manlio Perillo) Date: Sun Apr 13 10:17:13 2008 Subject: [Haskell-cafe] RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> Message-ID: <480216F6.2000208@libero.it> Johan Tibell ha scritto: > Good day hackers, > > The Python community have been successful in standardizing an > interface between web server and applications or frameworks resulting > in users having more control over their web stack by being able to > pick frameworks independently from web servers, and vice versa. I > propose we try to do the same for Haskell. I've written half a draft > for a Haskell version of Python's PEP 333 [1]. If you're interested in > taking part in this effort please read through the Python spec first > (as it is way more complete and you can understand this proposal > better by reading it, I've skipped some important issues in my first > draft) and then go read the Haskell spec [2]. I'm very interested, thanks for the effort. > I'm particularly > interesting in feedback regarding: > > * Doing in this way won't work as it violates HTTP/CGI spec part X, Y > and Z (the Python spec takes lots of things from the CGI spec > including naming and semantics). > * My server/framework could never provide/be run under this interface. > * This interface has bad performance by design. > * Using a different set of data types would work better. > I'm not yet an Haskell expert, however one of the great feature of WSGI is that the environ is a Python dictionary. This means that the user can add new keys/values in it. I'm using this feature, in my WSGI implementation for Nginx (and in a mini framework I'm writing) to store user configuration in the environment, and to cache the result of the parsing of request headers. I'm not sure if this make sense in Haskell. > The spec needs to be extended to cover all the corners of HTTP. Some > parts need to be motivated better. It is easier for me to motivate > things if people would tell me what parts are badly motivated. > > Note: I'm open to a complete rewrite if needed. I'm not wedded to the > current design and/or wording. In fact parts of the wording is > borrowed from the Python spec. The parts with bad grammar are all > mine. > > 1. http://www.python.org/dev/peps/pep-0333/ > 2. http://www.haskell.org/haskellwiki/WebApplicationInterface > > -- Johan Manlio Perillo From allbery at ece.cmu.edu Sun Apr 13 10:33:05 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Apr 13 10:28:28 2008 Subject: [Haskell-cafe] RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: <480216F6.2000208@libero.it> References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> <480216F6.2000208@libero.it> Message-ID: <3349B31E-706C-41C3-A0F0-318B23B8DF8E@ece.cmu.edu> On Apr 13, 2008, at 10:21 , Manlio Perillo wrote: > I'm not yet an Haskell expert, however one of the great feature of > WSGI is that the environ is a Python dictionary. > This means that the user can add new keys/values in it. > > > I'm using this feature, in my WSGI implementation for Nginx (and in > a mini framework I'm writing) to store user configuration in the > environment, and to cache the result of the parsing of request > headers. > > I'm not sure if this make sense in Haskell. Er, that's just a StateT and possibly a ReaderT. I suspect a specific monad stack wrapping IO will end up being part of the interface anyway. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From bit at mutantlemon.com Sun Apr 13 15:11:55 2008 From: bit at mutantlemon.com (Bit Connor) Date: Sun Apr 13 15:07:18 2008 Subject: [Haskell-cafe] install trouble with SDL on win32+cygwin In-Reply-To: References: <7ca3f0160804112055y17083b6cx5b6ec563860db04d@mail.gmail.com> Message-ID: <6205bd290804131211m773f41f7ka26ee4b9ac2efcc6@mail.gmail.com> SDL works great on Windows, and you don't even need cygwin. Only ghc is required. There are instructions in the WIN32 file. http://darcs.haskell.org/~lemmih/hsSDL/hssdl/WIN32 2008/4/12 Conal Elliott : > Now I have sdl-config, but still not able to build. > > Does *anyone* have the SDL package running on Windows? > > If not, is GLFW the recommended cross-platform GL toolkit? > > Thanks, - Conal > > > > On Fri, Apr 11, 2008 at 8:55 PM, Luke Palmer wrote: > > 2008/4/11 Conal Elliott : > > > > > I'm trying to install the SDL package (on win32+cygwin), and configure > isn't > > > able to find my SDL.dll, though it's on my PATH. Any ideas? - Conal > > > > > > bash-3.2$ cabal install SDL > > > 'SDL-0.5.3' is cached. > > > [1 of 1] Compiling Main ( Setup.lhs, dist\setup/Main.o ) > > > Linking dist\setup\setup.exe ... > > > Configuring SDL-0.5.3... > > > checking for sdl-config... no > > > > I currently am not running cygwin, so I could be wrong, but the lack > > of sdl-config is a red flag. Have you installed sdl and sdl-devel (I > > think those are the package names) with the cygwin installer yet? > > > > Luke > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From conal at conal.net Sun Apr 13 15:56:47 2008 From: conal at conal.net (Conal Elliott) Date: Sun Apr 13 15:52:08 2008 Subject: [Haskell-cafe] install trouble with SDL on win32+cygwin In-Reply-To: <6205bd290804131211m773f41f7ka26ee4b9ac2efcc6@mail.gmail.com> References: <7ca3f0160804112055y17083b6cx5b6ec563860db04d@mail.gmail.com> <6205bd290804131211m773f41f7ka26ee4b9ac2efcc6@mail.gmail.com> Message-ID: Thanks very much for the pointer, Bit. I had to add "\SDL" to the end of this def: Include-Dirs: C:\SDL-1.2.12\include and I didn't need to change the Extra-Libraries line. I'm using cygwin, which may make a difference here. Next, I 'cabal install'ed SDL-ttf and discovered that I need the SDL_ttf lib, which I got, but I don't know where to unpack it so that the (Haskell) SDL-ttf will find it. Suggestions? - Conal On Sun, Apr 13, 2008 at 12:11 PM, Bit Connor wrote: > SDL works great on Windows, and you don't even need cygwin. Only ghc > is required. There are instructions in the WIN32 file. > > http://darcs.haskell.org/~lemmih/hsSDL/hssdl/WIN32 > > 2008/4/12 Conal Elliott : > > Now I have sdl-config, but still not able to build. > > > > Does *anyone* have the SDL package running on Windows? > > > > If not, is GLFW the recommended cross-platform GL toolkit? > > > > Thanks, - Conal > > > > > > > > On Fri, Apr 11, 2008 at 8:55 PM, Luke Palmer wrote: > > > 2008/4/11 Conal Elliott : > > > > > > > I'm trying to install the SDL package (on win32+cygwin), and > configure > > isn't > > > > able to find my SDL.dll, though it's on my PATH. Any ideas? - > Conal > > > > > > > > bash-3.2$ cabal install SDL > > > > 'SDL-0.5.3' is cached. > > > > [1 of 1] Compiling Main ( Setup.lhs, dist\setup/Main.o > ) > > > > Linking dist\setup\setup.exe ... > > > > Configuring SDL-0.5.3... > > > > checking for sdl-config... no > > > > > > I currently am not running cygwin, so I could be wrong, but the lack > > > of sdl-config is a red flag. Have you installed sdl and sdl-devel (I > > > think those are the package names) with the cygwin installer yet? > > > > > > Luke > > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080413/5ec51005/attachment.htm From agl at imperialviolet.org Sun Apr 13 19:06:43 2008 From: agl at imperialviolet.org (Adam Langley) Date: Sun Apr 13 19:02:05 2008 Subject: [Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> Message-ID: <396556a20804131606h35c0cd75p2076fd20bdd67582@mail.gmail.com> On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell wrote: > * Using a different set of data types would work better. Give that this is Haskell, I'd suggest more types ;) HTTP headers aren't just strings and, at the risk of tooting my own horn, I'll point to the Headers structure in [1]. Likewise, URLs have lots of structure that should just be handled in one place [2] [1] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;f=/Network/MiniHTTP/Marshal.hs [2] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;f=/Network/MiniHTTP/URL.hs AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From dm.maillists at gmail.com Sun Apr 13 21:08:56 2008 From: dm.maillists at gmail.com (Daniel McAllansmith) Date: Sun Apr 13 21:04:33 2008 Subject: [Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: <396556a20804131606h35c0cd75p2076fd20bdd67582@mail.gmail.com> References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> <396556a20804131606h35c0cd75p2076fd20bdd67582@mail.gmail.com> Message-ID: <200804141308.56697.dm.maillists@gmail.com> On Mon, 14 Apr 2008 11:06:43 Adam Langley wrote: > On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell wrote: > > * Using a different set of data types would work better. > > Give that this is Haskell, I'd suggest more types ;) > > HTTP headers aren't just strings and, at the risk of tooting my own > horn, I'll point to the Headers structure in [1]. And it could go further. The use of a given header is often valid only in certain requests or responses. Perhaps sprinkling some phantom types or type classes around could represent that. Daniel From s.clover at gmail.com Sun Apr 13 22:43:33 2008 From: s.clover at gmail.com (Sterling Clover) Date: Sun Apr 13 22:38:56 2008 Subject: [Haskell-cafe] Re: [web-devel] RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> Message-ID: <368E0883-A910-4FFD-937F-A6A1D7F88E42@gmail.com> In a sense, the CGIT interface provided by Network.CGI already is a sort of halfway implementation of what we're discussing, no? I'd be interested in approaching this from the other way -- specifying exactly what CGIT doesn't provide and therefore what folks want to see. As far as I can tell, the main issue with CGIT is that it doesn't handle streaming/resource issues very well. The main innovation I see provided here is the enumerator interface, which is a very nice and flexible approach to I/O and provides a way to handle comet cleanly to boot. Since the application type as proposed is Env -> IO (Code, Headers, ResponseEnumerator), what we're really getting is almost an equiv. (modulo enumerators) of unwrapping CGIT IO CGIResponse with a run function. So what we lose is the ability for all our nicely named record accessors and functions to be shared across frameworks -- i.e. the flexibility a monad transformer *does* provide. So my question is if we can somehow preserve that with an appropriate typeclass. I'd ideally like to see this engineered in two parts -- a "cgit-like" typeclass interface that allows access to the environment but is agnostic as to response type, so that comet-style and other apps that take special advantage of enumerators can be built on top of it as well as apps that simply perform lazy writes; and the lower-level enumerator interface. This ideally would let the higher-level interface be built over any stack at all (i.e. STM-based as well, or even a pure stack), while the lower level interface that calls it is some glue of the given constant type in the IO monad. This would be of great help to hvac. There's also the fact that this could be designed ground-up with greater bytestring use, but that doesn't seem immense to me. Outside of this, I'm not quite sure what else CGIT lacks. I'm with Chris Smith's arguments as to the headers question, and it seems to me that dicts are best done using MVar-style primitives. I'm a bit at sea as to why the queryString is here just represented as a bytestring -- is it seriously an issue that some apps may want to use it other than in the standard parsed way? Is the idea here that lib functions would fill in and be shared among frameworks? On the other hand, seperating GET and POST vars is a good idea, and its a shame that CGIT doesn't allow this. The openness here seems in part based on the desire to keep different forms of file upload handling available. However, the work that oleg did with regards to CGI also seems promising -- i.e., rather than using an enumerator, simply taking advantage of laziness to unpack the input stream into a lazy dictionary. Regards, S. On Apr 13, 2008, at 7:59 AM, Johan Tibell wrote: > Good day hackers, > > The Python community have been successful in standardizing an > interface between web server and applications or frameworks resulting > in users having more control over their web stack by being able to > pick frameworks independently from web servers, and vice versa. I > propose we try to do the same for Haskell. I've written half a draft > for a Haskell version of Python's PEP 333 [1]. If you're interested in > taking part in this effort please read through the Python spec first > (as it is way more complete and you can understand this proposal > better by reading it, I've skipped some important issues in my first > draft) and then go read the Haskell spec [2]. I'm particularly > interesting in feedback regarding: > > * Doing in this way won't work as it violates HTTP/CGI spec part X, Y > and Z (the Python spec takes lots of things from the CGI spec > including naming and semantics). > * My server/framework could never provide/be run under this interface. > * This interface has bad performance by design. > * Using a different set of data types would work better. > > The spec needs to be extended to cover all the corners of HTTP. Some > parts need to be motivated better. It is easier for me to motivate > things if people would tell me what parts are badly motivated. > > Note: I'm open to a complete rewrite if needed. I'm not wedded to the > current design and/or wording. In fact parts of the wording is > borrowed from the Python spec. The parts with bad grammar are all > mine. > > 1. http://www.python.org/dev/peps/pep-0333/ > 2. http://www.haskell.org/haskellwiki/WebApplicationInterface > > -- Johan > _______________________________________________ > web-devel mailing list > web-devel@haskell.org > http://www.haskell.org/mailman/listinfo/web-devel From john at repetae.net Sun Apr 13 22:55:12 2008 From: john at repetae.net (John Meacham) Date: Sun Apr 13 22:50:31 2008 Subject: [Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> Message-ID: <20080414025512.GJ25982@sliver.repetae.net> Haskell works fine with both the FastCGI and SCGI protocols (There are libraries floating around for both), I have found them much nicer than any mod_* web server plugin in general. John -- John Meacham - ?repetae.net?john? From agl at imperialviolet.org Sun Apr 13 23:27:35 2008 From: agl at imperialviolet.org (Adam Langley) Date: Sun Apr 13 23:22:58 2008 Subject: [Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> <396556a20804131606h35c0cd75p2076fd20bdd67582@mail.gmail.com> Message-ID: <396556a20804132027p6d00e5bdw89518241a39a6ee3@mail.gmail.com> On Sun, Apr 13, 2008 at 6:32 PM, Chris Smith wrote: > Does old code that handled these headers stop working, just because it > was looking in the "other" section, but now needs to check a field > dedicated to that header? Yes, but it would be very sad if we couldn't do common header parsing because of this. I'd suggest that all the headers given in RFC 2616 be parsed and nothing else. That leaves the question of how we would handle the addition of any extra ones in the future. Firstly, packages could depend on a given version of this interface and we declare that the set of handled headers doesn't change within a major version. Better would be some static assertion that the interface doesn't handle some set of headers. Maybe there's a type trick to do this, but I can't think of one, so we might have to settle for a non static: checkUnparsedHeaders :: [String] -> IO () Which can be put in 'main' (or equivalent) and can call error if there's a mismatch. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From mj at mjclement.com Sun Apr 13 23:31:54 2008 From: mj at mjclement.com (Michaeljohn Clement) Date: Sun Apr 13 23:27:14 2008 Subject: [Haskell-cafe] RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> Message-ID: <4802D02A.9070203@mjclement.com> I am very interested in this work. One thing missing is support for all HTTP methods, not just those in RFC 2616. As-is, something like WebDAV cannot be implemented. That probably means requestMethod should be a (Byte)String. What about something like sendfile(2) available on some platforms? To allow the server to make use of such optimizations, how about an optional alternative to the enumerator? Perhaps the app can optionally pass a path or an open fd back to the server in place of an enumerator, which allows servers to do any kind of buffering optimizations, etc, that they may know about, as well as using any platform-specific optimizations like sendfile. -- Michaeljohn Clement From mj at mjclement.com Sun Apr 13 23:50:48 2008 From: mj at mjclement.com (Michaeljohn Clement) Date: Sun Apr 13 23:46:08 2008 Subject: [Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: <396556a20804131606h35c0cd75p2076fd20bdd67582@mail.gmail.com> References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> <396556a20804131606h35c0cd75p2076fd20bdd67582@mail.gmail.com> Message-ID: <4802D498.7000303@mjclement.com> Adam Langley wrote: > On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell wrote: >> * Using a different set of data types would work better. > > Give that this is Haskell, I'd suggest more types ;) > > HTTP headers aren't just strings and, at the risk of tooting my own > horn, I'll point to the Headers structure in [1]. That is one of the things I don't like about Network.HTTP, which also enumerates header fields. It is inconvenient to have to look up the names in the data type, when the standard field names are already known, and it makes using non-RFC2616 headers less convenient. Automatic parsing of header fields also makes unusual usage inconvenient, (for example the Range header support in [1] is a profile of RFC2616.) I think those kinds of features belong in frameworks; they will be more of an annoyance than a help to anyone that is writing to the WSGI layer. > Likewise, URLs have > lots of structure that should just be handled in one place [2] Yes, I think should be parsed to the level of granularity specified by RFC 2616 (i.e. scheme, host, port, path, query string) and anything more (like parsing query strings) should be handled by frameworks. > > [1] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;f=/Network/MiniHTTP/Marshal.hs > [2] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;f=/Network/MiniHTTP/URL.hs > > > AGL > -- Michaeljohn Clement From dm.maillists at gmail.com Mon Apr 14 01:17:24 2008 From: dm.maillists at gmail.com (Daniel McAllansmith) Date: Mon Apr 14 01:13:12 2008 Subject: [Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> <396556a20804131606h35c0cd75p2076fd20bdd67582@mail.gmail.com> Message-ID: <200804141717.24442.dm.maillists@gmail.com> On Mon, 14 Apr 2008 13:32:07 Chris Smith wrote: > On Sun, 13 Apr 2008 16:06:43 -0700, Adam Langley wrote: > > On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell > > > > wrote: > >> * Using a different set of data types would work better. > > > > Give that this is Haskell, I'd suggest more types ;) > > > > HTTP headers aren't just strings and, at the risk of tooting my own > > horn, I'll point to the Headers structure in [1]. > > Wait, I'm not sure I agree here. How are headers not just strings? Headers, at least their values, aren't strings. The specification says so. I think headers should be represented by something more specific than a string. > By > assuming that, are we guaranteeing that anything using this interface > cannot respond gracefully to a client that writes malformed headers? Having explicit types for headers doesn't preclude trying to handle messages with malformed headers. Soldiering on in the face of malformed messages as a general strategy is pretty dubious in my opinion. In the specific cases where you've determined it is necessary you want to be able to register a work-around parser for that section of the message, and be able to tell that it has been used. A decent framework can supply a catalogue of commonly required work-arounds. > > Another perspective: there is unnecessary variation there in how > interfaces are represented. If I'm looking for a header, and I know its > name as a string, how do I look for it? Well, apparently it's either a > named field (if it's known to the interface) or in the "other" section > (if not). So I write a gigantic case analysis? But then suppose the > interface is updated later to include some headers that popped up > unofficially but then are standardized in a future RFC. (This is not too > odd; lots of REST web services invent new headers every day, many of > which do things that make sense outside of the particular application.) > Does old code that handled these headers stop working, just because it > was looking in the "other" section, but now needs to check a field > dedicated to that header? I don't like the idea of having a fixed enumeration of methods or headers. You need to be able to define new methods and headers at will, and ideally have the usage of headers constrained to valid contexts. This suggests to me type classes that establish a 'can occur in' relationship between request/response, method and a given general/request/response/entity header. By importing new method or header data type, appropriate type class instances and registering an appropriate message parser extension you can mix and match which headers and methods you support. GET and HEAD are the only ones that MUST be supported after all. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080414/a485fb4d/attachment.htm From chak at cse.unsw.edu.au Mon Apr 14 02:00:51 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Apr 14 01:56:12 2008 Subject: [Haskell-cafe] Type families and GADTs in 6.9 In-Reply-To: <200804120106.45717.dan.doel@gmail.com> References: <200804120106.45717.dan.doel@gmail.com> Message-ID: <2B5F471E-AC3E-4805-8F1A-4E6E40CADEBF@cse.unsw.edu.au> Dan, > I've been playing around with type families off and on in 6.8, but, > what with > the implementation therein being reportedly incomplete, it's hard to > know > what I'm getting right and wrong, or what should work but doesn't > and so on. > So, I finally decided to take the plunge and install 6.9 (which, > perhaps, > isn't yet safe in that regard either, but, such is life :)). But, > when I > loaded up one of my programs, I got a type error. The subject is > inductively > defined tuples: [..] > However, proj results in a > type error: > > Occurs check: cannot construct the infinite type: > t = Lookup (t ::: ts) fn > In the pattern: v ::: vs > In the definition of `proj': proj FZ (v ::: vs) = v Sorry, but looks like a bug in 6.9 to me. Could you add it to the GHC bug tracker? Thanks, Manuel From dekudekuplex at yahoo.com Mon Apr 14 03:22:24 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Mon Apr 14 03:17:44 2008 Subject: Embedding newlines into a string? [Was: Re: [Haskell-cafe] Separate a string into a list of strings] In-Reply-To: <8b108f950606121634q12b0862dvbbe88e866385e394@mail.gmail.com> Message-ID: <759981.50282.qm@web30205.mail.mud.yahoo.com> A friend and I were working on a Haskell version of Towers of Hanoi yesterday, and I tried writing out the program today, but got stuck on outputting newlines as part of the string; viz: hanoi :: Int -> String hanoi n = hanoi_helper 'a' 'b' 'c' n hanoi_helper :: Char -> Char -> Char -> Int -> String hanoi_helper source using dest n | n == 1 = putStrLn "Move " ++ show source ++ " to " ++ show dest ++ "." ++ show '\n' | otherwise = hanoi_helper source dest using (n-1) ++ hanoi_helper source using dest 1 ++ hanoi_helper using source dest (n-1) The problem is that the newlines ('\n') get embedded as escaped newlines into the output string, instead of as newlines. E.g., Hugs> :load hanoi.hs Main> hanoi 2 "Move 'a' to 'b'.'\\n'Move 'a' to 'c'.'\\n'Move 'b' to 'c'.'\\n'" Instead, what I want is the following: Hugs> :load hanoi.hs Main> hanoi 2 "Move 'a' to 'b'. Move 'a' to 'c'. Move 'b' to 'c'. " However, when I try to use putStrLn to avoid this problem, as follows: | n == 1 = putStrLn "Move " ++ show source ++ " to " ++ show dest ++ "." ++ show '\n' the compiler generates the following error: ERROR file:hanoi.hs:6 - Type error in application *** Expression : putStrLn "Move " ++ show source ++ " to " ++ show dest ++ "." ++ show '\n' *** Term : putStrLn "Move " *** Type : IO () *** Does not match : [Char] Simply changing the type signature does not solve this problem. I searched through the past messages on this list, and came up with the message below, but simply quoting the newlines as '\n' doesn't seem to help. Does anybody know a way to embed a newline into a string as output of type String of a function so that the newline characters are not escaped? Benjamin L. Russell --- Jared Updike wrote: > Funny. I have a module called Useful.hs with some of > these same sorts > of functions. (coming from Python where I used > .split(',') and > .replace('\r', '') and such a lot): > > ------------------ > module Useful where > > import List ( intersperse, tails ) > import Numeric ( readHex ) > > hex2num :: (Num a) => String -> a > hex2num s = let (result, _):_ = readHex s in result > > toEnv s = map tuple (split ';' s) > > tuple :: String -> (String, String) > tuple line = case split '=' line of > a:b:_ -> (a,b) > a:_ -> (a,"") > _ -> ("","") -- not good, probably won't > happen for my typical usage... > > split :: Char -> String -> [String] > split _ "" = [] > split c s = let (l, s') = break (== c) s > in l : case s' of > [] -> [] > (_:s'') -> split c s'' > > beginsWith [] [] = True > beginsWith _ [] = True > beginsWith [] _ = False > beginsWith (a:aa) (b:bb) > | a == b = aa `beginsWith` bb > | otherwise = False > > dropping [] [] = [] > dropping [] _ = [] > dropping x [] = x > dropping s@(a:aa) (b:bb) | a == b = dropping aa > bb > | otherwise = s > > -- replace all occurrences of 'this' with 'that' in > the string 'str' > -- like Python replace > replace _ _ [] = [] > replace this that str > | str `beginsWith` this = let after = (str > `dropping` this) > in that ++ replace > this that after > | otherwise = > let x:xs = str > in x : replace this that xs > > eat s = replace s "" > > -- sometimes newlines get out of hand on the end of > form POST submissions, > -- so trim all the end newlines and add a single > newline > fixEndingNewlines = reverse . ('\n':) . dropWhile > (=='\n') . reverse . > filter (/= '\r') > > endsWith a b = beginsWith (reverse a) (reverse b) > > a `contains` b = any (`beginsWith` b) $ tails a > ------------------ > > Jared. > > On 6/12/06, Neil Mitchell > wrote: > > Hi, > > > > I tend to use the module TextUtil (or Util.Text) > from Yhc for these > > kind of string manipulations: > > > > > http://www-users.cs.york.ac.uk/~malcolm/cgi-bin/darcsweb.cgi?r=yhc;a=headblob;f=/src/compiler98/Util/Text.hs > > > > separate = splitList "," > > > > I am currently thinking about making this module > into a standalone > > library with some other useful functions, if > people have any opinions > > on this then please let me know. > > > > Thanks > > > > Neil > > > > > > On 6/12/06, Sara Kenedy > wrote: > > > Hi all, > > > > > > I want to write a function to separate a string > into a list of strings > > > separated by commas. > > > > > > Example: > > > separate :: String -> [String] > > > > > > separate "Haskell, Haskell, and Haskell" = > ["Haskell", "Haskell", "and Haskell"] > > > > > > If anyone has some ideas, please share with me. > Thanks. > > > > > > S. > > > _______________________________________________ > > > 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 > > > > > -- > http://www.updike.org/~jared/ > reverse ")-:" > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ndmitchell at gmail.com Mon Apr 14 03:30:33 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Apr 14 03:25:51 2008 Subject: Embedding newlines into a string? [Was: Re: [Haskell-cafe] Separate a string into a list of strings] In-Reply-To: <759981.50282.qm@web30205.mail.mud.yahoo.com> References: <8b108f950606121634q12b0862dvbbe88e866385e394@mail.gmail.com> <759981.50282.qm@web30205.mail.mud.yahoo.com> Message-ID: <404396ef0804140030h45319e56w946d4c655c49e1a3@mail.gmail.com> Hi On Mon, Apr 14, 2008 at 8:22 AM, Benjamin L. Russell wrote: > A friend and I were working on a Haskell version of > Towers of Hanoi yesterday, and I tried writing out the > program today, but got stuck on outputting newlines as > part of the string; viz: > | n == 1 = putStrLn ("Move " ++ show source ++ " to > " ++ show dest ++ "." ++ show '\n') show '\n' = "\\n" "\n" == "\n" Therefore: > | n == 1 = putStrLn ("Move " ++ show source ++ " to > " ++ show dest ++ "." ++ "\n") Note that you need the brackets, an in general don't call show on a String or a Char. Thanks Neil From rendel at daimi.au.dk Mon Apr 14 03:41:39 2008 From: rendel at daimi.au.dk (Tillmann Rendel) Date: Mon Apr 14 03:37:11 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <759981.50282.qm@web30205.mail.mud.yahoo.com> References: <759981.50282.qm@web30205.mail.mud.yahoo.com> Message-ID: <48030AB3.9040904@daimi.au.dk> Benjamin L. Russell wrote: > but got stuck on outputting newlines as part of the string; quoting is done by the show function in Haskell, so you have to take care to avoid calling show. your code calls show at two positions: (1) when you insert the newline into the string (2) when you output the string with respect to (1): you use (show '\n') to create a newline-only string, which produces a machine-readable (!) textual representation of '\n'. try the difference between > '\n' and > show '\n' to see what I mean. instead of using (show '\n'), you should simply use "\n" to encode the string of length 1 containing a newline character. with respect to (2): the type of your top-level expression is String, which is automatically print'ed by the interpreter. but print x = putStrLn (show x), so there is another call to show at this point. to avoid this call, write an IO action yourself. try the difference between putStrLn (hanoi ...) and print (hanoi ...) to see what I mean. Last, but not least, I would like to point out a different aproach to multiline output which is often used by Haskell programmers: The worker functions in this aproach produces a list of strings, which is joined together with newlines by the unlines function. In your case: hanoi_helper :: ... -> [String] | ... = ["Move " ++ ...] | otherwise = hanoi_helper ... ++ hanoi_helper ... hanoi n = hanoi_helper 'a' 'b' 'c' n and in the interpreter one of these: > hanoi 2 -- outputs a list > mapM_ putStrLn (hanoi 2) -- outputs each move in a new line > putStrLn (unlines (hanoi 2)) -- same as previous line Tillmann From dekudekuplex at yahoo.com Mon Apr 14 04:42:42 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Mon Apr 14 04:38:01 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <48030AB3.9040904@daimi.au.dk> Message-ID: <445663.82046.qm@web30203.mail.mud.yahoo.com> Ok; much better. Here's my new type signature and definition: hanoi.hs: hanoi :: Int -> IO () hanoi n = mapM_ putStrLn (hanoi_helper 'a' 'b' 'c' n) hanoi_helper :: Char -> Char -> Char -> Int -> [String] hanoi_helper source using dest n | n == 1 = ["Move " ++ show source ++ " to " ++ show dest ++ "."] | otherwise = hanoi_helper source dest using (n-1) ++ hanoi_helper source using dest 1 ++ hanoi_helper using source dest (n-1) Then in WinHugs (Version Sep 2006): Hugs> :load hanoi.hs Main> hanoi 2 Move 'a' to 'b'. Move 'a' to 'c'. Move 'b' to 'c'. Great! One minor question: I tried out both of your following suggestions: > > mapM_ putStrLn (hanoi 2) -- outputs each move > in a new line > > putStrLn (unlines (hanoi 2)) -- same as > previous line and discovered that putStrLn with unlines (the lower option) in fact generates one extra blank line at the end. Just curious as to why.... Benjamin L. Russell --- Tillmann Rendel wrote: > Benjamin L. Russell wrote: > > but got stuck on outputting newlines as part of > the string; > > quoting is done by the show function in Haskell, so > you have to take > care to avoid calling show. your code calls show at > two positions: > (1) when you insert the newline into the string > (2) when you output the string > > with respect to (1): > > you use (show '\n') to create a newline-only string, > which produces a > machine-readable (!) textual representation of '\n'. > try the difference > between > > > '\n' > > and > > > show '\n' > > to see what I mean. instead of using (show '\n'), > you should simply use > "\n" to encode the string of length 1 containing a > newline character. > > with respect to (2): > > the type of your top-level expression is String, > which is automatically > print'ed by the interpreter. but print x = putStrLn > (show x), so there > is another call to show at this point. to avoid this > call, write an IO > action yourself. try the difference between > > putStrLn (hanoi ...) > > and > > print (hanoi ...) > > to see what I mean. > > Last, but not least, I would like to point out a > different aproach to > multiline output which is often used by Haskell > programmers: The worker > functions in this aproach produces a list of > strings, which is joined > together with newlines by the unlines function. In > your case: > > hanoi_helper :: ... -> [String] > | ... = ["Move " ++ ...] > | otherwise = hanoi_helper ... ++ hanoi_helper > ... > > hanoi n = hanoi_helper 'a' 'b' 'c' n > > and in the interpreter one of these: > > > hanoi 2 -- outputs a list > > mapM_ putStrLn (hanoi 2) -- outputs each move > in a new line > > putStrLn (unlines (hanoi 2)) -- same as > previous line > > Tillmann > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From pablo at babel.ls.fi.upm.es Mon Apr 14 04:49:14 2008 From: pablo at babel.ls.fi.upm.es (Pablo Nogueira) Date: Mon Apr 14 04:44:34 2008 Subject: [Haskell-cafe] ANNOUNCE: Generic Haskell 1.80 (Emerald) In-Reply-To: <50652.82.157.212.81.1208021612.squirrel@squirrel.science.ru.nl> References: <49768.82.157.212.81.1208003974.squirrel@squirrel.science.ru.nl> <50032.82.157.212.81.1208013141.squirrel@squirrel.science.ru.nl> <50652.82.157.212.81.1208021612.squirrel@squirrel.science.ru.nl> Message-ID: > This has certainly been taken into account when comparing approaches to > generic programming. I quote from page 18/19 from the work you and Bulat Indeed I was not aware of it. Missed that. Thanks for pointing it out! > Thus, full reflexivity of an approach is taken into account. This suggests > constrained types are part of Haskell98. So, I'm a bit confused at the > moment as well. After reading the Haskell 98 report more carefully I think constrained types are part of Haskell98. The syntax for algebraic datatype declarations given is: > data cx => T u1 ... uk = K1 t11 ... t1k1 | ...| Kn tn1 ... tnkn Certainly, they are implemented in a peculiar way, with constraints associated with value constructors and not the type, perhaps to keep the class and kinds orthogonal (eg, the BinTree type has * -> * kind instead of Ord -> * kind). At any rate, this has been discussed before in other threads. Thanks Thomas for your help P. From ndmitchell at gmail.com Mon Apr 14 05:00:04 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Apr 14 04:55:23 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <445663.82046.qm@web30203.mail.mud.yahoo.com> References: <48030AB3.9040904@daimi.au.dk> <445663.82046.qm@web30203.mail.mud.yahoo.com> Message-ID: <404396ef0804140200j3a36efcbh66bf6f259cb8d5d5@mail.gmail.com> Hi > > > mapM_ putStrLn (hanoi 2) -- outputs each move > > in a new line > > > putStrLn (unlines (hanoi 2)) -- same as > > previous line putStr (unlines (hanoi 2)) is what you want. Unlines puts a trailing new line at the end of every line, including the final one. putStrLn puts an additional trailing new line, so you get 2 at the end. mapM_ putStrLn == putStr . unlines Thanks Neil From rendel at daimi.au.dk Mon Apr 14 05:12:26 2008 From: rendel at daimi.au.dk (Tillmann Rendel) Date: Mon Apr 14 05:07:40 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <404396ef0804140200j3a36efcbh66bf6f259cb8d5d5@mail.gmail.com> References: <48030AB3.9040904@daimi.au.dk> <445663.82046.qm@web30203.mail.mud.yahoo.com> <404396ef0804140200j3a36efcbh66bf6f259cb8d5d5@mail.gmail.com> Message-ID: <48031FFA.8000103@daimi.au.dk> Neil Mitchell wrote: > Unlines puts a trailing new line at the end of every > line, including the final one. putStrLn puts an additional trailing > new line, so you get 2 at the end. Thanks for that clarification. > mapM_ putStrLn == putStr . unlines I'm wondering which (==) you mean here ;) Tillmann From thomas at cs.ru.nl Mon Apr 14 04:59:36 2008 From: thomas at cs.ru.nl (Thomas van Noort) Date: Mon Apr 14 05:12:49 2008 Subject: [Haskell-cafe] ANNOUNCE: Generic Haskell 1.80 (Emerald) In-Reply-To: References: <49768.82.157.212.81.1208003974.squirrel@squirrel.science.ru.nl> <50032.82.157.212.81.1208013141.squirrel@squirrel.science.ru.nl> <50652.82.157.212.81.1208021612.squirrel@squirrel.science.ru.nl> Message-ID: <48031CF8.6040209@cs.ru.nl> Pablo Nogueira wrote: >> This has certainly been taken into account when comparing approaches to >> generic programming. I quote from page 18/19 from the work you and Bulat > > Indeed I was not aware of it. Missed that. Thanks for pointing it out! > >> Thus, full reflexivity of an approach is taken into account. This suggests >> constrained types are part of Haskell98. So, I'm a bit confused at the >> moment as well. > > After reading the Haskell 98 report more carefully I think constrained > types are part of Haskell98. The syntax for algebraic datatype > declarations given is: > > > data cx => T u1 ... uk = K1 t11 ... t1k1 | ...| Kn tn1 ... tnkn > > Certainly, they are implemented in a peculiar way, with constraints > associated with value constructors and not the type, perhaps to keep > the class and kinds orthogonal (eg, the BinTree type has * -> * kind > instead of Ord -> * kind). You are completely right, constraints are optional for data and newtype declarations in Haskell98: http://www.haskell.org/onlinereport/syntax-iso.html#sect9.5 In addition, GHC supports liberalised type synonyms which allows you to define constraints: http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type-extensions.html#type-synonyms Seems like the mystery is solved now.. > > At any rate, this has been discussed before in other threads. > Thanks Thomas for your help > P. You're welcome, Thomas From ndmitchell at gmail.com Mon Apr 14 05:23:20 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Apr 14 05:18:39 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <48031FFA.8000103@daimi.au.dk> References: <48030AB3.9040904@daimi.au.dk> <445663.82046.qm@web30203.mail.mud.yahoo.com> <404396ef0804140200j3a36efcbh66bf6f259cb8d5d5@mail.gmail.com> <48031FFA.8000103@daimi.au.dk> Message-ID: <404396ef0804140223o7ac4c1a6p22ce21bacc1dcc9@mail.gmail.com> Hi > > mapM_ putStrLn == putStr . unlines > > > > I'm wondering which (==) you mean here ;) Expression equality, defined by: instance (Arbitrary a, Eq b) => Eq (a -> b) where f == g = forall x :: a, f x == g x Using QuickCheck to generate the values, and an Eq over IO (), which can be defined using the IO test modelling thing at last years Haskell Workshop. There are answers to all these things, even if Haskell can't express all of them quite like this :) Thanks Neil From rendel at daimi.au.dk Mon Apr 14 05:27:11 2008 From: rendel at daimi.au.dk (Tillmann Rendel) Date: Mon Apr 14 05:22:24 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <445663.82046.qm@web30203.mail.mud.yahoo.com> References: <445663.82046.qm@web30203.mail.mud.yahoo.com> Message-ID: <4803236F.2070800@daimi.au.dk> Benjamin L. Russell wrote: > Ok; much better. Here's my new type signature and > definition: > > hanoi :: Int -> IO () > hanoi_helper :: Char -> Char -> Char -> Int -> [String] If you want, you can separate the algorithm and the output processing even more by providing three functions of these types: hanoi :: Int -> [(Char, Char)] hanoi_helper :: Char -> Char -> Char -> Int -> [(Char, Char)] hanoi_shower :: [(Char, Char)] -> String and at the interpreter level: > putStr (hanoi_shower (hanoi 2)) added value: you can easily use the output of hanoi for automated processing (e.g. testing, controlling a robot, producing an animation, counting the number of steps). You can go one step further if you consider that towers don't have to be named by single characters, but can be named by everything: hanoi :: a -> a -> a -> Int -> [(a, a)] hanoi_helper :: a -> a -> a -> Int -> [(a, a)] hanoi_shower :: Show a => [(a, a)] -> String now you can use > putStr (hanoi_shower (hanoi 'a' 'b' 'c' 2)) to get the same result as above, but you are also allowed to write > putStr (hanoi_shower (hanoi 1 2 3 2)) if you want to use numeric tower names. Tillmann From lemming at henning-thielemann.de Mon Apr 14 05:36:47 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Apr 14 05:30:46 2008 Subject: [Haskell-cafe] retrospective on 'seq' -> 'unsafeSeq' ? Message-ID: When reading the section "10.3 Controlling Evaluation Order" in "History of Haskell" I thought that the example that justified the 'seq' to be unrestricted polymorphic was mainly a debugging problem. I wondered if the better solution would have been to provide an 'unsafeSeq' which has no type restriction but must be absent from production code just like 'trace'. With 'unsafeSeq' one could nicely play around until time and space behaviour is as wanted and then one can replace all 'unsafeSeq's by 'seq' while adding type constraints accordingly. (Analogously there could be an unsafeShow that allows showing offending values in an 'error' without adding a Show constraint to the type signature.) From ndmitchell at gmail.com Mon Apr 14 06:07:17 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Apr 14 06:02:40 2008 Subject: [Haskell-cafe] retrospective on 'seq' -> 'unsafeSeq' ? In-Reply-To: References: Message-ID: <404396ef0804140307g757887bcr8429d3b8d9cf7545@mail.gmail.com> Hi > unrestricted polymorphic was mainly a debugging problem. I wondered if the > better solution would have been to provide an 'unsafeSeq' which has no type > restriction but must be absent from production code just like 'trace'. That would be very neat! > type constraints accordingly. (Analogously there could be an unsafeShow that > allows showing offending values in an 'error' without adding a Show > constraint to the type signature.) Ideally, unsafeShow could also show types as they are underneath, not as a pretty-printing Show might show them. I have often wanted to overload Show to print things in a readable way, but to have a showRaw which shows things as they are, for debugging purposes. I have even written such code for Yhc: http://www.cs.york.ac.uk/fp/yhc/snapshot/docs/Yhc-Core-ShowRaw.html I think unsafeShow is a fantastic idea - and would be much more useful to me than unsafeSeq - plus is a non-breaking change. I think Hugs already has 90% of the code to support this, and GHCi's debugger I think has a fair chunk of it, so it could be added given not too much work. Thanks Neil From simonpj at microsoft.com Mon Apr 14 06:19:29 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Apr 14 06:14:49 2008 Subject: [Haskell-cafe] retrospective on 'seq' -> 'unsafeSeq' ? In-Reply-To: <404396ef0804140307g757887bcr8429d3b8d9cf7545@mail.gmail.com> References: <404396ef0804140307g757887bcr8429d3b8d9cf7545@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE4D7A6E9@EA-EXMSG-C334.europe.corp.microsoft.com> | > type constraints accordingly. (Analogously there could be an unsafeShow that | > allows showing offending values in an 'error' without adding a Show | > constraint to the type signature.) | | Ideally, unsafeShow could also show types as they are underneath, not | as a pretty-printing Show might show them. I have often wanted to | overload Show to print things in a readable way, but to have a showRaw | which shows things as they are, for debugging purposes. I have even | written such code for Yhc: | http://www.cs.york.ac.uk/fp/yhc/snapshot/docs/Yhc-Core-ShowRaw.html | | I think unsafeShow is a fantastic idea - and would be much more useful | to me than unsafeSeq - plus is a non-breaking change. I think Hugs | already has 90% of the code to support this, and GHCi's debugger I | think has a fair chunk of it, so it could be added given not too much | work. Yes, as you say, the debugger has most of the machinery. I just don't know what it'd take to make it a callable function. Pepe? Someone might want to make a feature-request ticket for this, with as much background and/or suggested design as poss. Simon From mnislaih at gmail.com Mon Apr 14 07:22:42 2008 From: mnislaih at gmail.com (pepe) Date: Mon Apr 14 07:18:09 2008 Subject: [Haskell-cafe] retrospective on 'seq' -> 'unsafeSeq' ? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE4D7A6E9@EA-EXMSG-C334.europe.corp.microsoft.com> References: <404396ef0804140307g757887bcr8429d3b8d9cf7545@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE4D7A6E9@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On 14/04/2008, at 12:19, Simon Peyton-Jones wrote: > | > type constraints accordingly. (Analogously there could be an > unsafeShow that > | > allows showing offending values in an 'error' without adding a > Show > | > constraint to the type signature.) > | > | Ideally, unsafeShow could also show types as they are underneath, > not > | as a pretty-printing Show might show them. I have often wanted to > | overload Show to print things in a readable way, but to have a > showRaw > | which shows things as they are, for debugging purposes. I have even > | written such code for Yhc: > | http://www.cs.york.ac.uk/fp/yhc/snapshot/docs/Yhc-Core-ShowRaw.html > | > | I think unsafeShow is a fantastic idea - and would be much more > useful > | to me than unsafeSeq - plus is a non-breaking change. I think Hugs > | already has 90% of the code to support this, and GHCi's debugger I > | think has a fair chunk of it, so it could be added given not too > much > | work. > > Yes, as you say, the debugger has most of the machinery. I just > don't know what it'd take to make it a callable function. Pepe? > > Someone might want to make a feature-request ticket for this, with > as much background and/or suggested design as poss. unsafeShow sounds quite useful, especially to avoid adding a Show constraint in function signatures only for debugging (of course a decent refactoring tool for Haskell would help with this too, so I hope the HaRe SoC project proposal gets accepted and done!). :print has the code for doing this, but it needs the type information collected by the compiler. In GHC API speak, it needs the HscEnv from the Session object. If we can expose the Session created for GHCi (how? exporting it from GHC.Main? in a thread-local object? FFI trickery?), then this would need nearly zero work, albeit it would print things only when working in GHCi of course. But you can still compile all your modules to object code and call main from GHCi, so I don't think this is a big restriction considering unsafeShow is only for debugging purposes. Another question is where in the package hierarchy would this function live. Since the code it would use is in the ghc package, it would introduce a dependency on it. And I am fairly sure that there is no package in the standard ghc distribution which depends on the ghc package. Ian, can it be made to live in ghc-prim without creating a dependency on the ghc package? Alternatively, with some effort one can create a type-agnostic version of unsafeShow, which would print things in a more raw format, but probably sufficient anyway. I don't think it would work with unboxed values in general, although it can be made to work with the standard types. Actually, Bernie Pope wrote some code for this [1, see GHC Heap Printing library] some time ago, although with the new primitives and changes made for :print in GHC 6.8, this would be way easier nowadays. No need to use StablePtrs, no need to turn on profiling, and above all, no C needed :) And as a bonus this would work out of GHCi too. If there is a clean way to access the Session object, the first option means less implementation work, less code to maintain in GHC, and better functionality. What does the GHC team think? [1] - http://www.cs.mu.oz.au/~bjpop/code.html From dekudekuplex at yahoo.com Mon Apr 14 07:51:38 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Mon Apr 14 07:46:56 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <4803236F.2070800@daimi.au.dk> Message-ID: <385428.92143.qm@web30206.mail.mud.yahoo.com> Wow, that's very general. So you want to divide hanoi into a main function, a helper function, and a display function. I tried it out, and got this far so far: hanoi :: a -> a -> a -> Int -> [(a, a)] hanoi a b c n = hanoi_helper a b c n hanoi_helper :: a -> a -> a -> Int -> [(a, a)] hanoi_helper source using dest n | n == 1 = [(source, dest)] | otherwise = hanoi_helper source dest using (n-1) ++ hanoi_helper source using dest 1 ++ hanoi_helper using source dest (n-1) hanoi_shower :: Show a => [(a, a)] -> String hanoi_shower [(a, b)] = "Move " ++ show a ++ " to " ++ show b ++ "." However, when I tried to run the code in WinHugs, this is what I got: Hugs> :load hanoi_general.hs Main> putStr (hanoi_shower (hanoi 'a' 'b' 'c' 2)) Program error: pattern match failure: hanoi_shower [('a','b'),('a','c')] ++ ([] ++ hanoi_helper 'b' 'a' 'c' (2 - 1)) There seems to be a bug in hanoi_shower. I'm still trying to debug hanoi_shower, but I need to stop for today and continue on this tomorrow. Thanks for your help so far! Perhaps I can get this general version fully working tomorrow. Benjamin L. Russell --- Tillmann Rendel wrote: > Benjamin L. Russell wrote: > > Ok; much better. Here's my new type signature and > > definition: > > > > hanoi :: Int -> IO () > > hanoi_helper :: Char -> Char -> Char -> Int -> > [String] > > If you want, you can separate the algorithm and the > output processing > even more by providing three functions of these > types: > > hanoi :: Int -> [(Char, Char)] > hanoi_helper :: Char -> Char -> Char -> Int -> > [(Char, Char)] > hanoi_shower :: [(Char, Char)] -> String > > and at the interpreter level: > > > putStr (hanoi_shower (hanoi 2)) > > added value: you can easily use the output of hanoi > for automated > processing (e.g. testing, controlling a robot, > producing an animation, > counting the number of steps). > > You can go one step further if you consider that > towers don't have to be > named by single characters, but can be named by > everything: > > hanoi :: a -> a -> a -> Int -> [(a, a)] > hanoi_helper :: a -> a -> a -> Int -> [(a, a)] > hanoi_shower :: Show a => [(a, a)] -> String > > now you can use > > > putStr (hanoi_shower (hanoi 'a' 'b' 'c' 2)) > > to get the same result as above, but you are also > allowed to write > > > putStr (hanoi_shower (hanoi 1 2 3 2)) > > if you want to use numeric tower names. > > Tillmann > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From daniel.yokomizo at gmail.com Mon Apr 14 07:54:07 2008 From: daniel.yokomizo at gmail.com (Daniel Yokomizo) Date: Mon Apr 14 07:49:27 2008 Subject: [Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: <396556a20804132027p6d00e5bdw89518241a39a6ee3@mail.gmail.com> References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> <396556a20804131606h35c0cd75p2076fd20bdd67582@mail.gmail.com> <396556a20804132027p6d00e5bdw89518241a39a6ee3@mail.gmail.com> Message-ID: On Mon, Apr 14, 2008 at 3:27 AM, Adam Langley wrote: > On Sun, Apr 13, 2008 at 6:32 PM, Chris Smith wrote: > > Does old code that handled these headers stop working, just because it > > was looking in the "other" section, but now needs to check a field > > dedicated to that header? > > Yes, but it would be very sad if we couldn't do common header parsing > because of this. > > I'd suggest that all the headers given in RFC 2616 be parsed and > nothing else. Both request and response accept any entity headers and 7.1 (of RFC 2616) says that a valid entity header is an extension header, which can be any kind of header. > That leaves the question of how we would handle the > addition of any extra ones in the future. Firstly, packages could > depend on a given version of this interface and we declare that the > set of handled headers doesn't change within a major version. > > Better would be some static assertion that the interface doesn't > handle some set of headers. Maybe there's a type trick to do this, but > I can't think of one, so we might have to settle for a non static: > > checkUnparsedHeaders :: [String] -> IO () > > Which can be put in 'main' (or equivalent) and can call error if > there's a mismatch. Most of the times a Header makes sense in some scenarios and doesn't in others, so a package level checking is too coarse grained. IMHO it would be better to create a two layered approach. The bottom layer handles the request as a bunch of strings, just checks for structural correctness (i.e. break the headers by line and such) without checking if the headers are correct. The top layer provides a bunch of parser combinators to validate, parse and sanitize the request so a library can create its own contract: newtype Contract e a = Contract (HttpRequest -> e a) contract :: Contract Maybe MyRequest contract = do pragma <- parseHeader "Pragma" (\header -> ...) ... return $ MyRequest pragma ... main = do request <- readHttpRequest sanitized <- enforce contract request ... Such approach would be more flexible and extensible. Later other packages could provide specialized combinators for other RFCs. HTTP is regularly extended, in RFCs and by private parties experimenting before writing an RFC, it would be bad if the primary Haskell library for HTTP didn't support this behavior. Also it's important to notice that the HTTP spec defines things to be mostly orthogonal, so most of the headers stand on their own and can be used in combination with many methods and other headers, every once in a while someone finds a combination that makes sense and wasn't thought of before. > AGL > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org Best regards, Daniel Yokomizo. From abhay.parvate at gmail.com Mon Apr 14 08:07:29 2008 From: abhay.parvate at gmail.com (Abhay Parvate) Date: Mon Apr 14 08:02:48 2008 Subject: [Haskell-cafe] semi-closed handles Message-ID: <3c4d5adf0804140507k1bb786dehc6220f66af2f94ba@mail.gmail.com> Hello, In describing the Handle type, the GHC documentation says (in the System.IO documentation): GHC note: a Handle will be automatically closed when the garbage collector detects that it has become unreferenced by the program. However, relying on this behaviour is not generally recommended: the garbage collector is unpredictable. If possible, use explicit an explicit hClose to close Handles when they are no longer required. GHC does not currently attempt to free up file descriptors when they have run out, it is your responsibility to ensure that this doesn't happen. But one cannot call hClose on Handles on which something like hGetContents has been called; it just terminates the character list at the point till which it has already read. Further the manual says that hGetContents puts the handle in the semi-closed state, and further, A semi-closed handle becomes closed: - if hClose is applied to it; - if an I/O error occurs when reading an item from the handle; - or once the entire contents of the handle has been read. So do I safely assume here, according to the third point above, that it's fine if I do not call hClose explicitly as far as I am consuming all the contents returned by hGetContents? Thanks, Abhay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080414/ddeeaaa2/attachment.htm From abhay.parvate at gmail.com Mon Apr 14 08:21:32 2008 From: abhay.parvate at gmail.com (Abhay Parvate) Date: Mon Apr 14 08:16:50 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <270397.96776.qm@web30207.mail.mud.yahoo.com> References: <3c4d5adf0804140200g30fc716al3ff69e681c4b0eb5@mail.gmail.com> <270397.96776.qm@web30207.mail.mud.yahoo.com> Message-ID: <3c4d5adf0804140521t5d1c3c40n4f8ccc3aaa4e2fa6@mail.gmail.com> Yes, they are. That's what perhaps Neil Mitchell means by mapM_ putStrLn == putStr . unlines And whether the trailing newline is to be called the last blank line depends upon the convention; The string that is output in both the cases contains a single newline character. Are you calling that a blank line at end? And I actually meant to reply to haskell-cafe as well; omitted haskell-cafe by mistake. Anyway, you got the same answer from two people! This time I am including haskell-cafe in the recipients. Regards, Abhay On Mon, Apr 14, 2008 at 4:05 PM, Benjamin L. Russell wrote: > Abhay Parvate, > > Thank you; that answered my question. > > Then, the following two lines of code should be > equivalent: > > In hanoi.hs: > hanoi n = mapM_ putStrLn (hanoi_helper 'a' 'b' 'c' n) > > In hanoi_unlines.hs: > hanoi n = putStr (unlines(hanoi_helper 'a' 'b' 'c' n)) > > I tested them both out on WinHugs (Version Sep 2006); > they both generated one blank line at the end. > > Benjamin L. Russell > > --- Abhay Parvate wrote: > > > unlines puts newline after each string; putStrLn > > puts newline after the > > given string. As a result, the output contains two > > newlines in the end. You > > can use putStr instead, since the resultant string > > from 'unlines' will have > > a newline at the end. > > > > On Mon, Apr 14, 2008 at 2:12 PM, Benjamin L. Russell > > > > wrote: > > > > > Ok; much better. Here's my new type signature and > > > definition: > > > > > > hanoi.hs: > > > hanoi :: Int -> IO () > > > hanoi n = mapM_ putStrLn (hanoi_helper 'a' 'b' 'c' > > n) > > > > > > hanoi_helper :: Char -> Char -> Char -> Int -> > > > [String] > > > hanoi_helper source using dest n > > > | n == 1 = ["Move " ++ show source ++ " to " ++ > > > show dest ++ "."] > > > | otherwise = hanoi_helper source dest using > > (n-1) > > > > > > ++ hanoi_helper source using dest > > 1 > > > ++ hanoi_helper using > > source > > > dest (n-1) > > > > > > Then in WinHugs (Version Sep 2006): > > > > > > Hugs> :load hanoi.hs > > > Main> hanoi 2 > > > Move 'a' to 'b'. > > > Move 'a' to 'c'. > > > Move 'b' to 'c'. > > > > > > Great! > > > > > > One minor question: I tried out both of your > > > following suggestions: > > > > > > > > mapM_ putStrLn (hanoi 2) -- outputs each > > move > > > > in a new line > > > > > putStrLn (unlines (hanoi 2)) -- same as > > > > previous line > > > > > > and discovered that putStrLn with unlines (the > > lower > > > option) in fact generates one extra blank line at > > the > > > end. Just curious as to why.... > > > > > > Benjamin L. Russell > > > > > > --- Tillmann Rendel wrote: > > > > > > > Benjamin L. Russell wrote: > > > > > but got stuck on outputting newlines as part > > of > > > > the string; > > > > > > > > quoting is done by the show function in Haskell, > > so > > > > you have to take > > > > care to avoid calling show. your code calls show > > at > > > > two positions: > > > > (1) when you insert the newline into the string > > > > (2) when you output the string > > > > > > > > with respect to (1): > > > > > > > > you use (show '\n') to create a newline-only > > string, > > > > which produces a > > > > machine-readable (!) textual representation of > > '\n'. > > > > try the difference > > > > between > > > > > > > > > '\n' > > > > > > > > and > > > > > > > > > show '\n' > > > > > > > > to see what I mean. instead of using (show > > '\n'), > > > > you should simply use > > > > "\n" to encode the string of length 1 containing > > a > > > > newline character. > > > > > > > > with respect to (2): > > > > > > > > the type of your top-level expression is String, > > > > which is automatically > > > > print'ed by the interpreter. but print x = > > putStrLn > > > > (show x), so there > > > > is another call to show at this point. to avoid > > this > > > > call, write an IO > > > > action yourself. try the difference between > > > > > > > > putStrLn (hanoi ...) > > > > > > > > and > > > > > > > > print (hanoi ...) > > > > > > > > to see what I mean. > > > > > > > > Last, but not least, I would like to point out a > > > > different aproach to > > > > multiline output which is often used by Haskell > > > > programmers: The worker > > > > functions in this aproach produces a list of > > > > strings, which is joined > > > > together with newlines by the unlines function. > > In > > > > your case: > > > > > > > > hanoi_helper :: ... -> [String] > > > > | ... = ["Move " ++ ...] > > > > | otherwise = hanoi_helper ... ++ > > hanoi_helper > > > > ... > > > > > > > > hanoi n = hanoi_helper 'a' 'b' 'c' n > > > > > > > > and in the interpreter one of these: > > > > > > > > > hanoi 2 -- outputs a list > > > > > mapM_ putStrLn (hanoi 2) -- outputs each > > move > > > > in a new line > > > > > putStrLn (unlines (hanoi 2)) -- same as > > > > previous line > > > > > > > > Tillmann > > > > _______________________________________________ > > > > 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 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080414/c048cb8b/attachment.htm From allbery at ece.cmu.edu Mon Apr 14 10:22:50 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Apr 14 10:18:11 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <385428.92143.qm@web30206.mail.mud.yahoo.com> References: <385428.92143.qm@web30206.mail.mud.yahoo.com> Message-ID: <7549FA40-104F-497D-ADAB-7478DCBC7722@ece.cmu.edu> On Apr 14, 2008, at 7:51 , Benjamin L. Russell wrote: > hanoi_shower :: Show a => [(a, a)] -> String > hanoi_shower [(a, b)] = "Move " ++ show a ++ " to " ++ show b ++ "." You've just specified via pattern match that hanoi_shower always gets a 1-element list. Is that really what you intended? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From rendel at daimi.au.dk Mon Apr 14 10:36:06 2008 From: rendel at daimi.au.dk (Tillmann Rendel) Date: Mon Apr 14 10:31:19 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <385428.92143.qm@web30206.mail.mud.yahoo.com> References: <385428.92143.qm@web30206.mail.mud.yahoo.com> Message-ID: <48036BD6.5040308@daimi.au.dk> Benjamin L. Russell wrote: > Wow, that's very general. So you want to divide hanoi > into a main function, a helper function, and a display > function. > > I tried it out, and got this far so far: > > [...] > > hanoi_shower :: Show a => [(a, a)] -> String > hanoi_shower [(a, b)] = "Move " ++ show a ++ " to " ++ > show b ++ "." That's exactly what I was thinking about, but your hanoi_shower only handles list of exactly one action, but you have to handle longer lists, too. This could be done with explicit recursion hanoi_shower [] = ... hanoi_shower ((a, b) : moves) = ... or (preferably) with map hanoi_shower moves = unlines (map show_move moves) where show_move (a, b) = ... Note the use of unlines again. I decided to use where to introduce a local binding to avoid cluttering the top-level scope with function names. Tillmann From ndmitchell at gmail.com Mon Apr 14 10:41:17 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Apr 14 10:36:34 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <48036BD6.5040308@daimi.au.dk> References: <385428.92143.qm@web30206.mail.mud.yahoo.com> <48036BD6.5040308@daimi.au.dk> Message-ID: <404396ef0804140741k3094f3b2w82d35cfa2531dce2@mail.gmail.com> Hi > hanoi_shower [] = ... > hanoi_shower ((a, b) : moves) = ... > > or (preferably) with map > > hanoi_shower moves = unlines (map show_move moves) where > show_move (a, b) = ... A nice list comprehension works wonders in these situations: hanoi_shower moves = unlines ["Move " ++ show a ++ " to " ++ show b ++ "." | (a,b) <- moves] I would personally remove the "." from the end, as its a list of commands, not sentences - but that is personal choice. I'd also use unwords, as its slightly shorter: hanoi_shower moves = unlines [unwords ["Move", show a, "to", show b] | (a,b) <- moves] Thanks Neil From agl at imperialviolet.org Mon Apr 14 12:14:02 2008 From: agl at imperialviolet.org (Adam Langley) Date: Mon Apr 14 12:09:23 2008 Subject: [Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> <396556a20804131606h35c0cd75p2076fd20bdd67582@mail.gmail.com> <396556a20804132027p6d00e5bdw89518241a39a6ee3@mail.gmail.com> Message-ID: <396556a20804140914o7e71f8cam73421444bc775a23@mail.gmail.com> On Mon, Apr 14, 2008 at 4:54 AM, Daniel Yokomizo wrote: > Both request and response accept any entity headers and 7.1 (of RFC > 2616) says that a valid entity header is an extension header, which > can be any kind of header. Is wasn't suggesting that other headers be dropped, just that they remain as strings. > IMHO it would be better to create a two layered approach. The bottom > layer handles the request as a bunch of strings, just checks for > structural correctness (i.e. break the headers by line and such) > without checking if the headers are correct. The top layer provides a > bunch of parser combinators to validate, parse and sanitize the > request so a library can create its own contract: Ok, I think I'm convinced by this argument. I'd hope that a standard set of header parsers be defined, and that an application which only cares about 2616 headers can do call a single function to parse them all, but I no longer advocate that the base interface use parsed forms of headers. Also, parsing URLs seems to be pretty uncontroversial (maybe parsing key, value pairs from the path, maybe not) AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From adam.smyczek at gmail.com Mon Apr 14 13:07:31 2008 From: adam.smyczek at gmail.com (Adam Smyczek) Date: Mon Apr 14 13:02:54 2008 Subject: [Haskell-cafe] HTTP and file upload Message-ID: Is form based file upload supported in HTTP module (HTTP-3001.0.4)? Adam From byorgey at gmail.com Mon Apr 14 13:28:09 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Mon Apr 14 13:23:31 2008 Subject: [Haskell-cafe] semi-closed handles In-Reply-To: <3c4d5adf0804140507k1bb786dehc6220f66af2f94ba@mail.gmail.com> References: <3c4d5adf0804140507k1bb786dehc6220f66af2f94ba@mail.gmail.com> Message-ID: <22fcbd520804141028n495e4ef6vab0219d0cbb70ace@mail.gmail.com> 2008/4/14 Abhay Parvate : > Hello, > > In describing the Handle type, the GHC documentation says (in the > System.IO documentation): > > GHC note: a Handle will be automatically closed when the garbage collector > detects that it has become unreferenced by the program. However, relying on > this behaviour is not generally recommended: the garbage collector is > unpredictable. If possible, use explicit an explicit hClose to close Handles > when they are no longer required. GHC does not currently attempt to free up > file descriptors when they have run out, it is your responsibility to ensure > that this doesn't happen. > > But one cannot call hClose on Handles on which something like hGetContents > has been called; it just terminates the character list at the point till > which it has already read. Further the manual says that hGetContents puts > the handle in the semi-closed state, and further, > > A semi-closed handle becomes closed: > > - if hClose is applied to it; > - if an I/O error occurs when reading an item from the handle; > - or once the entire contents of the handle has been read. > > So do I safely assume here, according to the third point above, that it's > fine if I do not call hClose explicitly as far as I am consuming all the > contents returned by hGetContents? > Yes, not only is it fine, it's recommended! Calling hClose explicitly on a handle after calling hGetContents is a sure way to introduce bugs. -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080414/fddc1e50/attachment.htm From byorgey at gmail.com Mon Apr 14 13:37:17 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Mon Apr 14 13:32:35 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <385428.92143.qm@web30206.mail.mud.yahoo.com> References: <4803236F.2070800@daimi.au.dk> <385428.92143.qm@web30206.mail.mud.yahoo.com> Message-ID: <22fcbd520804141037u288afe90k5208a8757d86a9e3@mail.gmail.com> > > hanoi :: a -> a -> a -> Int -> [(a, a)] > hanoi a b c n = hanoi_helper a b c n > Note that now hanoi is exactly the same function as hanoi_helper, so you may as well just get rid of hanoi_helper. =) -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080414/964f84b6/attachment.htm From mail at joachim-breitner.de Mon Apr 14 18:01:39 2008 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon Apr 14 17:57:13 2008 Subject: [Haskell-cafe] ANN: darcswatch, a way to track your contributions Message-ID: <1208210499.3708.16.camel@otto.ehbuehl.net> Hi Haskellers, today I scrached an itch that was icking for a while: When I submit patches to some project or person, I?m never sure that I won?t forget checking that the patch will actually be applied. But if I forget, and the maitainer forgets (or decides against), my patch would be lost. Therefore I wrote a little haskell program darcswatch, which has a bunch of patches to track, and a bunch of repositories to watch, and shows you what patches have to be applied where. You see it in action here: http://darcswatch.nomeata.de/ To use it conveniently, I have put this in my ~/.darcs/defaults: send sign send cc darcswatch@nomeata.de so all patches I send will be signed and copied to that address. For security reasons, only mails signed by allowed gpg keys are accepted and the webpage is updated. It is also updated every hour by a cronjob. As you can see the program is ready to track patches by several authors. If you want to try it out and help debug it, just drop me a (signed) note with your gpg key-id, also listing all repositories you want to be tracked. I would also appreciate any help with programming darcswatch. There is a darcs repository on http://darcs.nomeata.de/darcswatch/ (with DarcsWeb at http://darcs.nomeata.de/cgi-bin/darcsweb.cgi?r=darcswatch;a=summary). There is a lot to do yet, I quote the TODO list on http://darcs.nomeata.de/darcswatch/README : * Support for tagged repositories (fetching older inventories) * Cache the inventories and only update when needed, by issuing a HEAD request. * Add a download link to each pach * Add the diff to each patch, with some javascript hiding/unhiding. * Cabalize the program. * Detect inverted patches and treat specially (e.g. an unapplied patch where the user also submitted an inverted patch can be considered obsolete) * Nicer output (CSS magic!) * (Maybe) Add repositores per gpg signed command Haskell projects could also make use of darcswatch by tracking patches that were submitted to a bugtracker (e.g. for xmonad) or via the mailing list, to make sure no contribution is lost. I could also imagine that it might be a service that, if proven reliable, could be run on community.haskell.org or similar. As always, comments are appreciated. Enjoy, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080415/34cd16db/attachment.bin From harke at cs.pdx.edu Mon Apr 14 19:52:45 2008 From: harke at cs.pdx.edu (harke@cs.pdx.edu) Date: Mon Apr 14 20:17:18 2008 Subject: [Haskell-cafe] Monad proof In-Reply-To: <47FFA160.1080009@gmail.com> References: <47FFA160.1080009@gmail.com> Message-ID: <20080414235243.GA4104@catamorphism.cs.pdx.edu> Here's part of a pencil-and-paper proof of laws for a state monad. Before doing so, I've got a question of my own about the *other* laws: Is there a place where somebody has explicitly written the laws that "non-proper morphisms" of commonly used monads? Back to the original question... Beware. What I'm about to say doesn't quite work in Haskell, for two reasons. First, you can't make my definition into an instance of the class Monad without inserting type constructors into inconvenient places. Second, due to the way undefined works in Haskell, the state monad doesn't obey all the laws. Assume we don't have non-termination, and assume we don't care about overloading (>>=) and return (so we don't need to shoe-horn our monad into the monad type class). Preliminaries. From the Prelude we have: curry :: ((a,b) -> c) -> a -> b -> c uncurry :: (a -> b -> c) -> (a,b) -> c id :: a -> a We define the state monad to be a synonym for a function returning a pair: M a = s -> (a,s) Define morphisms return = curry id -- where id is specialized to type (a,s) -> (a,s) m >>= k = (uncurry k) . m get = \s -> (s,s) put s = \_ -> ((),s) Now check the laws. Of the basic 3, I'll only do associativity. The other 2 are easier. Take the two sides of the conjectured law and unfold the definition of >>= (and return), then use properties of uncurry (and curry) to massage them into the same form. If you can do so, the law holds. (I'm going to avoid unfolding the definition of (un)curry so I can stay at a higher level of abstraction, though the following might be shorter if I did unfold them.) LHS == (p >>= q) >>= r == uncurry r . (p >>= q) == uncurry r . (uncurry q . p) RHS = == p >>= (\x -> q x >>= r) == uncurry (\x -> q x >>= r) . p == uncurry (\x -> uncurry r . q x) . p == uncurry (\x s -> (uncurry r . q x) s) . p == uncurry (\x s -> uncurry r (q x s)) . p == (\xs -> uncurry r (q (fst xs) (snd xs))) . p == (\xs -> uncurry r (uncurry q xs)) . p == (\xs -> (uncurry r . uncurry q) xs) . p == (uncurry r . uncurry q) . p Now, one thing that's equally interesting (and perhaps not spoken of often enough) is the laws that the "non-proper morphisms" obey. In the case of state: put a >> get == put a >> return a where each side reduces to \_ -> (a,a) get >> get == get where each side reduces to \s -> ((),s) BTW, in a proof assistant like Coq, Isabelle or Agda these identities can be verified much more easily (though a badly done "proof script" may be unreadable.) On Fri, Apr 11, 2008 at 02:35:28PM -0300, Rafael C. de Almeida wrote: > Hello, > > I was studying Monads and I was trying to think about new Monads I could > define. So, a question poped into my mind: how is proof regarding the 3 > Monad laws handled? I know that, aside from testing all the possible values > (and there can be a lot of them), there's no general way to prove it. > Nonetheless, I think that it would be insightful to see how people write > those proofs for their monads -- specially for new user monads. Is there > some article or some notes on proving that Monads are implemented > correctly? > > []'s > Rafael -- Tom Harke Portland State University From derek.a.elkins at gmail.com Mon Apr 14 21:00:06 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Mon Apr 14 20:55:26 2008 Subject: [Haskell-cafe] Monad proof In-Reply-To: <20080414235243.GA4104@catamorphism.cs.pdx.edu> References: <47FFA160.1080009@gmail.com> <20080414235243.GA4104@catamorphism.cs.pdx.edu> Message-ID: <1208221206.5538.5.camel@derek-laptop> On Mon, 2008-04-14 at 16:52 -0700, harke@cs.pdx.edu wrote: > Here's part of a pencil-and-paper proof of laws for a state monad. > > Before doing so, I've got a question of my own about the *other* laws: > Is there a place where somebody has explicitly written the laws that > "non-proper morphisms" of commonly used monads? > > Back to the original question... > > Beware. What I'm about to say doesn't quite work in Haskell, for two > reasons. First, you can't make my definition into an instance of the > class Monad without inserting type constructors into inconvenient places. > Second, due to the way undefined works in Haskell, the state monad > doesn't obey all the laws. > > Assume we don't have non-termination, and assume we don't care about > overloading (>>=) and return (so we don't need to shoe-horn our monad > into the monad type class). > > Preliminaries. From the Prelude we have: > curry :: ((a,b) -> c) -> a -> b -> c > uncurry :: (a -> b -> c) -> (a,b) -> c > id :: a -> a > A shorter version. First, verify that curry and uncurry make an isomorphism. (They don't in Haskell because of seq, this is where we close our eyes and stick our fingers in our ears.) Then curry and uncurry define an adjunction: (,) a -| (->) a State is the monad of that adjunction. QED. From Patrick.Surry at portraitsoftware.com Mon Apr 14 22:39:53 2008 From: Patrick.Surry at portraitsoftware.com (Patrick Surry) Date: Mon Apr 14 22:35:12 2008 Subject: [Haskell-cafe] Help understanding sharing Message-ID: <93BECC602E286B499D5443ECB850D2FF0126B398@newman.usa.aitgroupad.com> I'm new to Haskell and trying to get a better understanding of sharing (and ultimately memoization). I've read SOE and various of the tutorials, as well as browsing around the wiki and old mailing lists. Most of the examples of memoization seem to revolve around Fibonacci, and are based either on the fact that a list defined within the function will get shared between calls, or on doing some 'unsafeIO' (which I haven't dug too deeply into.) I've read various discussions that explain why function calls are generally not automatically memoized (e.g. f x gets recalculated rather than looked up based on the prior result). The rationale for that (big space leak and no guarantee of improved performance) makes sense. (Though I did like one poster's suggestion of a compiler pragma that hints that a particular function should be memoized.) I've seen other discussions that suggest that lists are always shared while in scope (so the fibs trick works). But is that just a feature of the standard compilers, or is it somewhere mandated in the Hakell spec (I don't see anything obvious in the Haskell Report tho haven't read it cover to cover)? The wiki page http://www.haskell.org/haskellwiki/Performance/Strictness says laziness == non-strictness + sharing but again nowhere gives a set of rules that guarantees what will be shared and what won't. I was hoping I might find it here: http://www.haskell.org/haskellwiki/Sharing but no such luck. Or are there no guarantees and you just have to know how your particular compiler works?? Cheers, Patrick ________________________________________________________________________ DISCLAIMER: This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. If you received this email in error, please notify the sender and delete the message from your computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080414/75621663/attachment.htm From trebla at vex.net Mon Apr 14 23:24:36 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Mon Apr 14 23:19:53 2008 Subject: [Haskell-cafe] Help understanding sharing In-Reply-To: <93BECC602E286B499D5443ECB850D2FF0126B398@newman.usa.aitgroupad.com> References: <93BECC602E286B499D5443ECB850D2FF0126B398@newman.usa.aitgroupad.com> Message-ID: <48041FF4.4030908@vex.net> Patrick Surry wrote: > I've seen other discussions that suggest that lists are always shared > while in scope (so the fibs trick works). But is that just a feature of > the standard compilers, or is it somewhere mandated in the Hakell spec > (I don't see anything obvious in the Haskell Report tho haven't read it > cover to cover)? It is just a feature of most compilers. The Haskell Report does not specify sharing. For most compilers, a sufficient condition for sharing is aliasing, e.g., let y = f x in (y,y,y,y,y) you can be sure that most compilers share one copy of "f x" for those five mentions of "y". As another example, let x = 0:x in x you can be sure that most compilers create a tight cyclic graph for that. In contrast, most compilers may create redundantly new expressions for the following: (f x, f x, f x, f x, f x) -- given the definition: recurse f = f (recurse f) recurse (\x -> 0:x) From dekudekuplex at yahoo.com Mon Apr 14 23:45:05 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Mon Apr 14 23:40:21 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <404396ef0804140741k3094f3b2w82d35cfa2531dce2@mail.gmail.com> Message-ID: <604246.11489.qm@web30204.mail.mud.yahoo.com> Now it works; viz (in response to Brent Yorgey's suggestion, I have merged hanoi and hanoi_helper): hanoi_general_list_comprehension_unwords.hs (based on Neil Mitchell's suggestion, except for the trailing '.'): hanoi :: a -> a -> a -> Int -> [(a, a)] hanoi source using dest n | n == 1 = [(source, dest)] | otherwise = hanoi source dest using (n-1) ++ hanoi source using dest 1 ++ hanoi using source dest (n-1) hanoi_shower :: Show a => [(a, a)] -> String hanoi_shower moves = unlines [unwords ["Move", show a, "to", show b, "."] | (a, b) <- moves] Then, in WinHugs: Main> :load hanoi_general_list_comprehension_unwords.hs Main> putStr (hanoi_shower (hanoi 'a' 'b' 'c' 2)) Move 'a' to 'b' . Move 'a' to 'c' . Move 'b' to 'c' . Main> putStr (hanoi_shower (hanoi 1 2 3 2)) Move 1 to 2 . Move 1 to 3 . Move 2 to 3 . Notwithstanding Neil's advice on removing the trailing '.', which I appreciate, I would still prefer to retain it, because, in the interests of literate programming, I would like a sequence of English sentences as commands acceptable even to an English teacher. So, to be pedantic and remove the ' ' before the '.' at each line: hanoi_shower portion of hanoi_general_list_comprehension_unlines.hs (based on Neil Mitchell's suggestion): hanoi_shower :: Show a => [(a, a)] -> String hanoi_shower moves = unlines ["Move " ++ show a ++ " to "++ show b ++ "." | (a, b) <- moves] Then, in WinHugs: Main> :load hanoi_general_list_comprehension_unlines.hs Main> putStr (hanoi_shower (hanoi 'a' 'b' 'c' 2)) Move 'a' to 'b'. Move 'a' to 'c'. Move 'b' to 'c'. Main> putStr (hanoi_shower (hanoi 1 2 3 2)) Move 1 to 2. Move 1 to 3. Move 2 to 3. Splendid! Now, just for fun, let's see what other versions also work: hanoi_shower portion of hanoi_general_map_unlines.hs (based on Tillman Rendel's suggestion): hanoi_shower :: Show a => [(a, a)] -> String hanoi_shower moves = unlines (map move moves) where move (a, b) = "Move " ++ show a ++ " to "++ show b ++ "." Then, in WinHugs: Main> :load hanoi_general_map_unlines.hs Main> putStr (hanoi_shower (hanoi 'a' 'b' 'c' 2)) Move 'a' to 'b'. Move 'a' to 'c'. Move 'b' to 'c'. Main> putStr (hanoi_shower (hanoi 1 2 3 2)) Move 1 to 2. Move 1 to 3. Move 2 to 3. Wonderful! Thanks especially to Neil Mitchell and Tillman Rendel for their constructive suggestions. Nevertheless, I'm still working on the recursive version. So far, I've gotten this far: hanoi_shower portion of hanoi_general_recursive.hs (based on Tillman Rendel's suggestion): hanoi_shower :: Show a => [(a, a)] -> String hanoi_shower ((a, b) : moves) | null moves = "Move " ++ show a ++ " to "++ show b ++ "." | otherwise == "Move " ++ show a ++ " to "++ show b ++ "." ++ hanoi_shower moves However, in WinHugs, I get the following error: Hugs> :load hanoi_general_recursive.hs ERROR file:hanoi_general_recursive.hs:11 - Syntax error in declaration (unexpected `}', possibly due to bad layout) I haven't used recursion in Haskell much so far; I've only used it in Scheme, so I'm not used to it. I need to go to lunch now, so I'll work on this part later. Perhaps I can get it to work after lunch.... Benjamin L. Russell --- Neil Mitchell wrote: > Hi > > > hanoi_shower [] = ... > > hanoi_shower ((a, b) : moves) = ... > > > > or (preferably) with map > > > > hanoi_shower moves = unlines (map show_move > moves) where > > show_move (a, b) = ... > > A nice list comprehension works wonders in these > situations: > > hanoi_shower moves = unlines ["Move " ++ show a ++ " > to " ++ show b ++ > "." | (a,b) <- moves] > > I would personally remove the "." from the end, as > its a list of > commands, not sentences - but that is personal > choice. I'd also use > unwords, as its slightly shorter: > > hanoi_shower moves = unlines [unwords ["Move", show > a, "to", show b] | > (a,b) <- moves] > > Thanks > > Neil > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From bjpop at csse.unimelb.edu.au Mon Apr 14 23:51:53 2008 From: bjpop at csse.unimelb.edu.au (Bernie Pope) Date: Mon Apr 14 23:40:34 2008 Subject: [Haskell-cafe] retrospective on 'seq' -> 'unsafeSeq' ? In-Reply-To: References: <404396ef0804140307g757887bcr8429d3b8d9cf7545@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE4D7A6E9@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <8DA45EC3-210E-4FA1-8EBF-3B8CF27C06C8@csse.unimelb.edu.au> On 14/04/2008, at 9:22 PM, pepe wrote: > Alternatively, with some effort one can create a type-agnostic > version of unsafeShow, which would print things in a more raw > format, but probably sufficient anyway. I don't think it would work > with unboxed values in general, although it can be made to work > with the standard types. Actually, Bernie Pope wrote some code for > this [1, see GHC Heap Printing library] some time ago, although > with the new primitives and changes made for :print in GHC 6.8, > this would be way easier nowadays. No need to use StablePtrs, no > need to turn on profiling, and above all, no C needed :) > And as a bonus this would work out of GHCi too. Yes, an almost-universal printer would be possible now that we have data constructor names attached to info tables. I'd sort of planned to do that, and then got side-tracked. Of course, this won't be able to print functions in any helpful way, unless we attach source code information to functions as well (which may be worth doing anyway?). One thing to watch out for is cycles in data structures. You may not want to try to detect them, but at least you should be lazy in generating the printable representation of values. And then there is the question of whether to evaluate thunks during printing. Perhaps such a printer would also be useful for the GHCi debugger in cases where it can't infer the right types? Bernie. From cdsmith at twu.net Mon Apr 14 23:54:49 2008 From: cdsmith at twu.net (Chris Smith) Date: Mon Apr 14 23:50:19 2008 Subject: [Haskell-cafe] Strange message from GHC Message-ID: I'm running into this in some code I wrote. What does it mean? It says to look at -fspec-constr-count, but that flag doesn't seem to be in the GHC documentation. This isn't critical; the code still seems to work fine. It just makes the build uglier. Thanks. Message below. SpecConstr: too many specialisations for one function (see -fspec-constr- count): Function: main:Expr.simplifyTerm{v rqC} [lid] Specialisations: [([sc_s2wb{v} [lid], sc_s2wc{v} [lid], sc_s2wd{v} [lid], sc_s2we{v} [lid], sc_s2wf{v} [lid], sc_s2wg{v} [lid]], [main:Expr.Graph{v r51} [gid] sc_s2wg{v} [lid] sc_s2wf{v} [lid] sc_s2we{v} [lid] sc_s2wd{v} [lid], base:GHC.Base.:{(w) v 65} [gid] @ main:Expr.Gen{tc r53} (main:Expr.Edge{v r4Q} [gid] sc_s2wc{v} [lid]) sc_s2wb{v} [lid]]), ([sc_s2wh{v} [lid], sc_s2wi{v} [lid], sc_s2wj{v} [lid], sc_s2wk{v} [lid], sc_s2wl{v} [lid], sc_s2wm{v} [lid]], [main:Expr.Graph{v r51} [gid] sc_s2wm{v} [lid] sc_s2wl{v} [lid] sc_s2wk{v} [lid] sc_s2wj{v} [lid], base:GHC.Base.:{(w) v 65} [gid] @ main:Expr.Gen{tc r53} (main:Expr.Ghost{v r4P} [gid] sc_s2wi{v} [lid]) sc_s2wh{v} [lid]]), ([sc_s2wR{v} [lid], sc_s2wS{v} [lid], sc_s2wT{v} [lid]], [sc_s2wT{v} [lid], base:GHC.Base.:{(w) v 65} [gid] @ main:Expr.Gen{tc r53} (main:Expr.Vertex{v r4R} [gid] sc_s2wS{v} [lid]) sc_s2wR{v} [lid]]), ([sc_s2wU{v} [lid], sc_s2wV{v} [lid], sc_s2wW{v} [lid]], [sc_s2wW{v} [lid], base:GHC.Base.:{(w) v 65} [gid] @ main:Expr.Gen{tc r53} (main:Expr.Vertex{v r4R} [gid] (base:GHC.Base.I#{(w) v 6d} [gid] sc_s2wV{v} [lid])) sc_s2wU{v} [lid]])] From allbery at ece.cmu.edu Tue Apr 15 00:31:34 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Apr 15 00:26:53 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <604246.11489.qm@web30204.mail.mud.yahoo.com> References: <604246.11489.qm@web30204.mail.mud.yahoo.com> Message-ID: <8558B607-778D-4ABB-B12B-47358A42D3CF@ece.cmu.edu> On Apr 14, 2008, at 23:45 , Benjamin L. Russell wrote: > hanoi_shower :: Show a => [(a, a)] -> String > hanoi_shower ((a, b) : moves) > | null moves = "Move " ++ show a ++ " to "++ show b ++ "." > | otherwise == "Move " ++ show a ++ " to "++ show b ++ "." ++ > hanoi_shower moves `==' after the `otherwise'? (I think the error involving `}' is a side effect of the single ugliest part of Haskell syntax, which specifies the parser inserting `}' as necessary to try to get a parse.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From lrpalmer at gmail.com Tue Apr 15 00:45:19 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Apr 15 00:40:37 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <604246.11489.qm@web30204.mail.mud.yahoo.com> References: <404396ef0804140741k3094f3b2w82d35cfa2531dce2@mail.gmail.com> <604246.11489.qm@web30204.mail.mud.yahoo.com> Message-ID: <7ca3f0160804142145w2077d146uf6c28f11deba1240@mail.gmail.com> On Tue, Apr 15, 2008 at 3:45 AM, Benjamin L. Russell wrote: > hanoi_shower ((a, b) : moves) > | null moves = "Move " ++ show a ++ " to "++ show > b ++ "." > | otherwise == "Move " ++ show a ++ " to "++ show > b ++ "." ++ hanoi_shower moves More idiomatic pedantry: the way you will see most Haskellers write this style of function is by pattern matching rather than guards: hanoi_shower [] = "" hanoi_shower ((a,b):moves) = "Move " ++ show a ++ " to " ++ show b ++ ".\n" ++ hanoi_shower moves Luke From abhay.parvate at gmail.com Tue Apr 15 02:09:19 2008 From: abhay.parvate at gmail.com (Abhay Parvate) Date: Tue Apr 15 02:04:35 2008 Subject: [Haskell-cafe] semi-closed handles In-Reply-To: <22fcbd520804141028n495e4ef6vab0219d0cbb70ace@mail.gmail.com> References: <3c4d5adf0804140507k1bb786dehc6220f66af2f94ba@mail.gmail.com> <22fcbd520804141028n495e4ef6vab0219d0cbb70ace@mail.gmail.com> Message-ID: <3c4d5adf0804142309mc4fb184t1e957c8fe0e29d7c@mail.gmail.com> Thanks! I was worried about how/where would I place hClose! On Mon, Apr 14, 2008 at 10:58 PM, Brent Yorgey wrote: > > 2008/4/14 Abhay Parvate : > > Hello, > > > > In describing the Handle type, the GHC documentation says (in the > > System.IO documentation): > > > > GHC note: a Handle will be automatically closed when the garbage > > collector detects that it has become unreferenced by the program. However, > > relying on this behaviour is not generally recommended: the garbage > > collector is unpredictable. If possible, use explicit an explicit hClose to > > close Handles when they are no longer required. GHC does not currently > > attempt to free up file descriptors when they have run out, it is your > > responsibility to ensure that this doesn't happen. > > > > But one cannot call hClose on Handles on which something like > > hGetContents has been called; it just terminates the character list at the > > point till which it has already read. Further the manual says that > > hGetContents puts the handle in the semi-closed state, and further, > > > > A semi-closed handle becomes closed: > > > > - if hClose is applied to it; > > - if an I/O error occurs when reading an item from the handle; > > - or once the entire contents of the handle has been read. > > > > So do I safely assume here, according to the third point above, that > > it's fine if I do not call hClose explicitly as far as I am consuming all > > the contents returned by hGetContents? > > > > Yes, not only is it fine, it's recommended! Calling hClose explicitly on > a handle after calling hGetContents is a sure way to introduce bugs. > > -Brent > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080415/1202600a/attachment.htm From ketil at malde.org Tue Apr 15 02:48:32 2008 From: ketil at malde.org (Ketil Malde) Date: Tue Apr 15 02:43:38 2008 Subject: [Haskell-cafe] retrospective on 'seq' -> 'unsafeSeq' ? In-Reply-To: <8DA45EC3-210E-4FA1-8EBF-3B8CF27C06C8@csse.unimelb.edu.au> (Bernie Pope's message of "Tue\, 15 Apr 2008 13\:51\:53 +1000") References: <404396ef0804140307g757887bcr8429d3b8d9cf7545@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE4D7A6E9@EA-EXMSG-C334.europe.corp.microsoft.com> <8DA45EC3-210E-4FA1-8EBF-3B8CF27C06C8@csse.unimelb.edu.au> Message-ID: <871w57sjen.fsf@nmd9999.imr.no> Bernie Pope writes: > Of course, [unsafeShow] won't be able to print functions in any helpful way, > unless we attach source code information to > functions as well (which may be worth doing anyway?). It might not be able to print the function's definition, but perhaps its type? > One thing to watch out for is cycles in data structures. You may not > want to try to detect them, but at least you should > be lazy in generating the printable representation of values. For debugging output, I find I often limit output to avoid this. For instance, I defined this helper function for XML parser debugging: showSome :: [Tag] -> String showSome a@(_:_:_:_:_:_:_) = (init . show . take 5 $ a)++" ... ]" showSome a = show a with a typical error call: then error ("Couldn't find tag '"++show tag++"' in\n"++showSome list) Come to think of it, ghci's print-bind-result functionality could benefit from something like that... I also think it would be nice if unsafeShow could be available also in compiled code, not just ghci - e.g. sometimes you might want a mere user to run your application with debugging turned on. -k -- If I haven't seen further, it is by standing in the footprints of giants From rendel at daimi.au.dk Tue Apr 15 03:14:53 2008 From: rendel at daimi.au.dk (Tillmann Rendel) Date: Tue Apr 15 03:10:18 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <7ca3f0160804142145w2077d146uf6c28f11deba1240@mail.gmail.com> References: <404396ef0804140741k3094f3b2w82d35cfa2531dce2@mail.gmail.com> <604246.11489.qm@web30204.mail.mud.yahoo.com> <7ca3f0160804142145w2077d146uf6c28f11deba1240@mail.gmail.com> Message-ID: <480455ED.1040506@daimi.au.dk> Benjamin L. Russel wrote: > hanoi_shower ((a, b) : moves) > | null moves = ... > | otherwise == ... Luke Palmer wrote: > More idiomatic pedantry: the way you will see most Haskellers write > this style of function is by pattern matching rather than guards: > > hanoi_shower [] = ... > hanoi_shower ((a,b):moves) = ... These two versions are semantically different! Benjamin's versions works for lists of length 1 or more, Luke's version works for lists of length 0 or more. Luke's version looks like a typical Haskell solution, which would be expressed in lispy syntax like this: (define hanoi_shower (lambda (xs) (cond ((null xs) (...)) (true, (let ((a, (first (first xs))) (b, (rest (first xs))) (moves, (rest xs))) (...))))) The pattern matching in Haskell takes care of both the cond and the let, there's no need for guards or to actually call null or any selector functions. A nice exercise may be to implement the map function using primitive recursion. Tillmann From ryani.spam at gmail.com Tue Apr 15 03:37:20 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Apr 15 03:32:37 2008 Subject: [Haskell-cafe] semi-closed handles In-Reply-To: <3c4d5adf0804142309mc4fb184t1e957c8fe0e29d7c@mail.gmail.com> References: <3c4d5adf0804140507k1bb786dehc6220f66af2f94ba@mail.gmail.com> <22fcbd520804141028n495e4ef6vab0219d0cbb70ace@mail.gmail.com> <3c4d5adf0804142309mc4fb184t1e957c8fe0e29d7c@mail.gmail.com> Message-ID: <2f9b2d30804150037u552caeat94ba3ab7ed30b033@mail.gmail.com> I usually use something like this instead: hStrictGetContents :: Handle -> IO String hStrictGetContents h = do s <- hGetContents h length s `seq` hClose h return s This guarantees the following: 1) The whole file is read before hStrictGetContents exits (could be considered bad, but usually it's The Right Thing) 2) You guarantee that you don't leak file handles (good benefit!) A slightly better version: import qualified Data.ByteString.Char8 as B hStrictGetContents :: Handle -> IO String hStrictGetContents h = do bs <- B.hGetContents h hClose h -- not sure if this is required; ByteString documentation isn't clear. return $ B.unpack bs -- lazy unpack into String This saves a ton of memory for big reads; a String is ~12 bytes per character, this is only 1 byte per character + fixed overhead. Then, assuming the function consuming the String doesn't leak, you'll end up with a much smaller space requirement. -- ryan 2008/4/14 Abhay Parvate : > Thanks! I was worried about how/where would I place hClose! > > > > On Mon, Apr 14, 2008 at 10:58 PM, Brent Yorgey wrote: > > > > > > 2008/4/14 Abhay Parvate : > > > > > > > > > > > Hello, > > > > > > In describing the Handle type, the GHC documentation says (in the > System.IO documentation): > > > > > > > > > GHC note: a Handle will be automatically closed when the garbage > collector detects that it has become unreferenced by the program. However, > relying on this behaviour is not generally recommended: the garbage > collector is unpredictable. If possible, use explicit an explicit hClose to > close Handles when they are no longer required. GHC does not currently > attempt to free up file descriptors when they have run out, it is your > responsibility to ensure that this doesn't happen. > > > > > > But one cannot call hClose on Handles on which something like > hGetContents has been called; it just terminates the character list at the > point till which it has already read. Further the manual says that > hGetContents puts the handle in the semi-closed state, and further, > > > > > > > > > A semi-closed handle becomes closed: > > > > > > if hClose is applied to it; > > > if an I/O error occurs when reading an item from the handle; > > > or once the entire contents of the handle has been read. So do I safely > assume here, according to the third point above, that it's fine if I do not > call hClose explicitly as far as I am consuming all the contents returned by > hGetContents? > > > > > > > > > Yes, not only is it fine, it's recommended! Calling hClose explicitly on > a handle after calling hGetContents is a sure way to introduce bugs. > > > > -Brent > > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From ryani.spam at gmail.com Tue Apr 15 03:51:57 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Apr 15 03:47:13 2008 Subject: [Haskell-cafe] Help understanding sharing In-Reply-To: <48041FF4.4030908@vex.net> References: <93BECC602E286B499D5443ECB850D2FF0126B398@newman.usa.aitgroupad.com> <48041FF4.4030908@vex.net> Message-ID: <2f9b2d30804150051v5cd7d9u1834fb8b25f2261a@mail.gmail.com> To add to this; sharing is not always what you want; sometimes it's a time/space trade-off and sometimes it's actually strictly worse than not sharing. For example: > f :: Integer -> [Integer] > f x = take 10000000 [x..] > sum :: [Integer] -> Integer > sum = foldl' (+) 0 > expensiveZero :: Integer > expensiveZero = let (a,b) = (f 0, f 0) in sum a + sum (map negate b) If the applications of f are unshared, "expensive" runs in small constant memory. But, if the applications of f are shared, it will likely exhaust memory (if it doesn't, add another few zeroes to the "take" in f). Here's why. Assume that (+) evaluates its left argument first. Then "sum a" is going to consume the entire list stored in "a". If the applications of f are unshared, the garbage collector will reclaim the beginning of the list "a" while sum is evaluating! But if they are shared, it can't; b is the same list and is still live until the rhs of the (+) gets evaluated. So the entire list will end up in memory! Not only that, the program will likely take longer to run than the unshared version, because the garbage collector has so much more work to do maintaining the live data set. This is why most compilers use aliasing of names for sharing; it gives the programmer control of whether a computation will be shared or not. -- ryan On Mon, Apr 14, 2008 at 8:24 PM, Albert Y. C. Lai wrote: > Patrick Surry wrote: > > > I've seen other discussions that suggest that lists are always shared > while in scope (so the fibs trick works). But is that just a feature of the > standard compilers, or is it somewhere mandated in the Hakell spec (I don't > see anything obvious in the Haskell Report tho haven't read it cover to > cover)? > > > > It is just a feature of most compilers. The Haskell Report does not specify > sharing. > > For most compilers, a sufficient condition for sharing is aliasing, e.g., > > let y = f x in (y,y,y,y,y) > > you can be sure that most compilers share one copy of "f x" for those five > mentions of "y". > > As another example, > > let x = 0:x in x > > you can be sure that most compilers create a tight cyclic graph for that. > > In contrast, most compilers may create redundantly new expressions for the > following: > > (f x, f x, f x, f x, f x) > > -- given the definition: recurse f = f (recurse f) > recurse (\x -> 0:x) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From aneumann at inf.fu-berlin.de Tue Apr 15 04:38:54 2008 From: aneumann at inf.fu-berlin.de (Adrian Neumann) Date: Tue Apr 15 04:34:27 2008 Subject: [Haskell-cafe] HTTP and file upload In-Reply-To: References: Message-ID: Yes http://hpaste.org/6990 Am 14.04.2008 um 19:07 schrieb Adam Smyczek: > Is form based file upload supported in HTTP module (HTTP-3001.0.4)? > > Adam > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Signierter Teil der Nachricht Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080415/9331c329/PGP.bin From abhay.parvate at gmail.com Tue Apr 15 06:56:46 2008 From: abhay.parvate at gmail.com (Abhay Parvate) Date: Tue Apr 15 06:52:01 2008 Subject: [Haskell-cafe] semi-closed handles In-Reply-To: <2f9b2d30804150037u552caeat94ba3ab7ed30b033@mail.gmail.com> References: <3c4d5adf0804140507k1bb786dehc6220f66af2f94ba@mail.gmail.com> <22fcbd520804141028n495e4ef6vab0219d0cbb70ace@mail.gmail.com> <3c4d5adf0804142309mc4fb184t1e957c8fe0e29d7c@mail.gmail.com> <2f9b2d30804150037u552caeat94ba3ab7ed30b033@mail.gmail.com> Message-ID: <3c4d5adf0804150356v30d6a443i32a98601046060a1@mail.gmail.com> Thanks Ryan, this will definitely not leak handles. I had thought about making a strict version of hGetContents, though on a bit different lines. My question was that since the documentation says that the semi-closed handle becomes closed as soon as the entire contents have been read; can I conclude that as far as I consume the string, I am not leaking handles? I am still interested in using hGetContents, since these contents are going soon through hPutStr, which will consume it anyway. And hGetContents being lazy will not occupy memory of the order of size of the input file. That's why the question. Regards, Abhay On Tue, Apr 15, 2008 at 1:07 PM, Ryan Ingram wrote: > I usually use something like this instead: > > hStrictGetContents :: Handle -> IO String > hStrictGetContents h = do > s <- hGetContents h > length s `seq` hClose h > return s > > This guarantees the following: > 1) The whole file is read before hStrictGetContents exits (could be > considered bad, but usually it's The Right Thing) > 2) You guarantee that you don't leak file handles (good benefit!) > > A slightly better version: > > import qualified Data.ByteString.Char8 as B > > hStrictGetContents :: Handle -> IO String > hStrictGetContents h = do > bs <- B.hGetContents h > hClose h -- not sure if this is required; ByteString documentation > isn't clear. > return $ B.unpack bs -- lazy unpack into String > > This saves a ton of memory for big reads; a String is ~12 bytes per > character, this is only 1 byte per character + fixed overhead. Then, > assuming the function consuming the String doesn't leak, you'll end up > with a much smaller space requirement. > > -- ryan > > 2008/4/14 Abhay Parvate : > > Thanks! I was worried about how/where would I place hClose! > > > > > > > > On Mon, Apr 14, 2008 at 10:58 PM, Brent Yorgey > wrote: > > > > > > > > > 2008/4/14 Abhay Parvate : > > > > > > > > > > > > > > > > Hello, > > > > > > > > In describing the Handle type, the GHC documentation says (in the > > System.IO documentation): > > > > > > > > > > > > GHC note: a Handle will be automatically closed when the garbage > > collector detects that it has become unreferenced by the program. > However, > > relying on this behaviour is not generally recommended: the garbage > > collector is unpredictable. If possible, use explicit an explicit hClose > to > > close Handles when they are no longer required. GHC does not currently > > attempt to free up file descriptors when they have run out, it is your > > responsibility to ensure that this doesn't happen. > > > > > > > > But one cannot call hClose on Handles on which something like > > hGetContents has been called; it just terminates the character list at > the > > point till which it has already read. Further the manual says that > > hGetContents puts the handle in the semi-closed state, and further, > > > > > > > > > > > > A semi-closed handle becomes closed: > > > > > > > > if hClose is applied to it; > > > > if an I/O error occurs when reading an item from the handle; > > > > or once the entire contents of the handle has been read. So do I > safely > > assume here, according to the third point above, that it's fine if I do > not > > call hClose explicitly as far as I am consuming all the contents > returned by > > hGetContents? > > > > > > > > > > > > > Yes, not only is it fine, it's recommended! Calling hClose explicitly > on > > a handle after calling hGetContents is a sure way to introduce bugs. > > > > > > -Brent > > > > > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080415/45dcc150/attachment.htm From rodrigo.bonifacio at uol.com.br Tue Apr 15 09:52:42 2008 From: rodrigo.bonifacio at uol.com.br (rodrigo.bonifacio) Date: Tue Apr 15 09:48:13 2008 Subject: [Haskell-cafe] Installing HaXml Message-ID: Hi all, I've tried to install HaXml as explained in the documentation: > runhaskell Setup.hs configure However, I get as response: dyld: Library not loaded: GNUreadline.framework/Versions/A/GNUreadline Referenced from: /usr/local/bin/runhaskell Reason: image not found Trace/BPT trap Any idea about this problem? Some comments about my configuration: Mac/OS Darwin 8.11.1 GHC-6.6 Hugs - Version September 2006 Thanks in advance, Rodrigo. From Malcolm.Wallace at cs.york.ac.uk Tue Apr 15 10:02:11 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Apr 15 10:14:23 2008 Subject: [Haskell-cafe] Installing HaXml In-Reply-To: References: Message-ID: <20080415150211.38a7a34f.Malcolm.Wallace@cs.york.ac.uk> "rodrigo.bonifacio" wrote: > > runhaskell Setup.hs configure > > dyld: Library not loaded: GNUreadline.framework/Versions/A/GNUreadline > Referenced from: /usr/local/bin/runhaskell > Reason: image not found > Trace/BPT trap The problem is that 'runhaskell' invokes ghci (the interpreter), which requires readline, which you do not have on your Mac. Instead, you could compile Setup.hs with ghc, which will not require readline. ghc --make Setup ./Setup configure ./Setup build ./Setup install Regards, Malcolm From magnus at therning.org Tue Apr 15 11:01:05 2008 From: magnus at therning.org (Magnus Therning) Date: Tue Apr 15 10:56:20 2008 Subject: [Haskell-cafe] Module for parsing C (pre-processed header files only)? Message-ID: Is there such a beast out there? If this were a list on some OO language I'd ask for something that created an AST and then offered an API based around a visitor pattern. The pre-processor (platform specific most likely, but could be cpphs of course) would be run prior to the tool I'm considering writing. After that I only need access to declarations of C functions and definitions of types (structs, enums, other typedefs). I had a quick look at the code in c2hs yesterday, but found it a little hard to make heads or tails of it without some guidance, so I couldn't tell whether it would be suitable. Would it? Any help or pointers appreciated. /M -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080415/d4a79802/attachment.htm From lgreg.meredith at biosimilarity.com Tue Apr 15 11:21:19 2008 From: lgreg.meredith at biosimilarity.com (Greg Meredith) Date: Tue Apr 15 11:16:33 2008 Subject: [Haskell-cafe] NW Functional Programming Interest Group In-Reply-To: <5de3f5ca0802011155l771cc649wa0e671bbe3abe364@mail.gmail.com> References: <5de3f5ca0802011155l771cc649wa0e671bbe3abe364@mail.gmail.com> Message-ID: <5de3f5ca0804150821t342512bcv5fd3bb5f02f20bd7@mail.gmail.com> All, Apologies for multiple listings. It's that time again. Our growing cadre of functionally-minded north westerners is meeting at the The Seattle Public Library 1000 - 4th Ave. Seattle, WA 98104 from 18:30 - 20:00 on April 16th. This meeting's agenda is a little more fluid, but... - i would like to talk about a proposal i'm mulling over around a much more general account of the Curry-Howard isomorphism by way of iterated distributive laws for monads - we also need to get a couple more people on the hook to give a talk Hope to see you there. Monadically yours, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080415/1f29d827/attachment.htm From magnus at therning.org Tue Apr 15 11:29:41 2008 From: magnus at therning.org (Magnus Therning) Date: Tue Apr 15 11:24:56 2008 Subject: [Haskell-cafe] Module for parsing C (pre-processed header files only)? In-Reply-To: References: Message-ID: On Tue, Apr 15, 2008 at 4:12 PM, Brian Sniffen wrote: > 2008/4/15 Magnus Therning : > > Is there such a beast out there? > > Well, there's CIL (http://manju.cs.berkeley.edu/cil/), an OCaml > library attacking the same problem. It has a very positive > reputation. Interesting answer on a Haskell list ;) I've been toying with the idea of looking at OCaml though, so this might be just the opportunity I was waiting for... /M -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080415/b66940e1/attachment.htm From Christian.Maeder at dfki.de Tue Apr 15 11:32:00 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Apr 15 11:27:14 2008 Subject: [Haskell-cafe] Re: Installing HaXml In-Reply-To: References: Message-ID: <4804CA70.2080200@dfki.de> rodrigo.bonifacio wrote: > Hi all, > > I've tried to install HaXml as explained in the documentation: > >> runhaskell Setup.hs configure > > However, I get as response: > > dyld: Library not loaded: GNUreadline.framework/Versions/A/GNUreadline > Referenced from: /usr/local/bin/runhaskell > Reason: image not found > Trace/BPT trap > > Any idea about this problem? You should install the frameworks http://www.haskell.org/ghc/dist/mac_frameworks/mac_e.htm Cheers Christian From benjovi at gmx.net Tue Apr 15 12:02:41 2008 From: benjovi at gmx.net (benedikth) Date: Tue Apr 15 12:00:24 2008 Subject: [Haskell-cafe] Re: Module for parsing C (pre-processed header files only)? In-Reply-To: References: Message-ID: <4804D1A1.8070608@gmx.net> Magnus Therning schrieb: > Is there such a beast out there? > > If this were a list on some OO language I'd ask for something that > created an AST and then offered an API based around a visitor pattern. > > The pre-processor (platform specific most likely, but could be cpphs of > course) would be run prior to the tool I'm considering writing. After > that I only need access to declarations of C functions and definitions > of types (structs, enums, other typedefs). > > I had a quick look at the code in c2hs yesterday, but found it a little > hard to make heads or tails of it without some guidance, so I couldn't > tell whether it would be suitable. Would it? Hi Markus, the C parser in c2hs is able to parse preprocessed C and build an AST for you. As c2hs also needs to extract function declarations and type definitions, there is also code to do that. Actually I applied for soc project to prepare a more general library from c2hs' code base, which would also provide what you are asking for. Right now, you can download the source code and have a look at c2hs/c/tests/CCWrapper.hs on how to invoke to parser, at c2hs/c/CAST.hs for the syntax tree datatypes, c2hs/c/CTrav.hs for syntax tree traversal and in gen/GenBind.hs to see how c2hs uses this functionality. best regards, benedikt From haskell at list.mightyreason.com Tue Apr 15 12:49:22 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Tue Apr 15 12:44:44 2008 Subject: [Haskell-cafe] Re: semi-closed handles In-Reply-To: <2f9b2d30804150037u552caeat94ba3ab7ed30b033@mail.gmail.com> References: <3c4d5adf0804140507k1bb786dehc6220f66af2f94ba@mail.gmail.com> <22fcbd520804141028n495e4ef6vab0219d0cbb70ace@mail.gmail.com> <3c4d5adf0804142309mc4fb184t1e957c8fe0e29d7c@mail.gmail.com> <2f9b2d30804150037u552caeat94ba3ab7ed30b033@mail.gmail.com> Message-ID: Ryan Ingram wrote: > I usually use something like this instead: > > hStrictGetContents :: Handle -> IO String > hStrictGetContents h = do > s <- hGetContents h > length s `seq` hClose h > return s A small idiomatic nitpick: When I see (length s) gets computed and thrown away I wince at the wasted effort. I would prefer (finiteSpine s): finiteSpine = foldr (const id) () hStrictGetContents :: Handle -> IO String hStrictGetContents h = do s <- hGetContents h finiteSpine s `seq` hClose h return s "finiteSpine" finds the "end" of a finite list and will hang forever on an infinite list. One can even notice that the type of finiteSpine is Strategy [a]: import Control.Parallel.Strategies(Strategy) finiteSpine :: Strategy [a] finiteSpine = foldr (const id) () And in fact "finiteSpine = seqList r0", which returns () after applying the "do nothing" strategy "r0" to every element. -- Chris From jbuehler at spirentcom.com Tue Apr 15 15:15:16 2008 From: jbuehler at spirentcom.com (Joe Buehler) Date: Tue Apr 15 15:10:47 2008 Subject: [Haskell-cafe] Re: I/O system brokenness with named pipes In-Reply-To: References: Message-ID: John Goerzen wrote: > So I have a need to write data to a POSIX named pipe (aka FIFO). Long > story involving a command that doesn't have an option to read data > from stdin, but can from a named pipe. How about /dev/stdin? -- Joe Buehler From ryani.spam at gmail.com Tue Apr 15 16:19:15 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Apr 15 16:14:33 2008 Subject: [Haskell-cafe] Re: semi-closed handles In-Reply-To: References: <3c4d5adf0804140507k1bb786dehc6220f66af2f94ba@mail.gmail.com> <22fcbd520804141028n495e4ef6vab0219d0cbb70ace@mail.gmail.com> <3c4d5adf0804142309mc4fb184t1e957c8fe0e29d7c@mail.gmail.com> <2f9b2d30804150037u552caeat94ba3ab7ed30b033@mail.gmail.com> Message-ID: <2f9b2d30804151319v39342879h61cd6f2ce16fbb40@mail.gmail.com> On 4/15/08, ChrisK wrote: > A small idiomatic nitpick: When I see (length s) gets computed and thrown > away I wince at the wasted effort. I would prefer (finiteSpine s): On every piece of hardware I've seen, the actual calculation done by "length" is basically free. Compared to the cache misses you'll get from traversing the list, or especially the disk access from reading the file, it's vanishingly small. It's also directly from the prelude and it's usually pretty clear to a newbie what it's doing, as compared to "foldr (const id) () s" which is on the path to "functional languages make no sense" land. I consider myself moderately experienced, and assuming that it typechecks I know what it has to mean, but I can't just look at it and know what it does like I can with "length". If there was a standard "seqList" or "deepSeq", I'd use that instead. -- ryan From vigalchin at gmail.com Tue Apr 15 18:53:32 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Tue Apr 15 18:48:48 2008 Subject: [Haskell-cafe] monadic debugging Message-ID: <5ae4f2ba0804151553t7e95961fsc699df5a08b8abcd@mail.gmail.com> Hello, I have an Linux executable of my Haskell library and test case. I see there are several debuggers, e.g. Buddha, Hat, etc. Which debugger is currently preferred for monadic (imperative) code? Thanks. Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080415/ed1185eb/attachment.htm From bulat.ziganshin at gmail.com Tue Apr 15 19:04:13 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Apr 15 19:00:25 2008 Subject: [Haskell-cafe] monadic debugging In-Reply-To: <5ae4f2ba0804151553t7e95961fsc699df5a08b8abcd@mail.gmail.com> References: <5ae4f2ba0804151553t7e95961fsc699df5a08b8abcd@mail.gmail.com> Message-ID: <701705975.20080416030413@gmail.com> Hello Vasili, Wednesday, April 16, 2008, 2:53:32 AM, you wrote: > ???? I have an Linux executable of my Haskell library and test > case. I see there are several debuggers, e.g. Buddha, Hat, etc. > Which debugger is currently preferred for monadic (imperative) code? Thanks. i use print mainly :) btw, there is also built-in ghci debugger, i suspect that it's closest one to the usual debuggers and most useful one for imperative code (but i never tried anything, so don't trust me :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From conal at conal.net Tue Apr 15 19:18:53 2008 From: conal at conal.net (Conal Elliott) Date: Tue Apr 15 19:14:07 2008 Subject: [Haskell-cafe] GC'ing file handles and other resources Message-ID: Are Haskell folks satisfied with the practical necessity of imperatively & explicitly reclaiming resources such as file handles, fonts & brushes, video memory chunks, etc? Doesn't explicit freeing of these resources have the same modularity and correctness problems as explicit freeing of system memory (C/C++ programming)? I wrote a lovely purely functional graphics library that used video memory to lazily compute and cache infinite-resolution images, and I found that I don't know how to get my finalizers to run anytime soon after video memory chunks become inaccessible. Explicit freeing isn't an option, since the interface is functional, not imperative (IO). I guess I'm wondering a few things: * Are Haskell programmers generally content with imperative and bug-friendly interfaces involving explicit freeing/closing of resources? * Do people assume that these resources (or handling them frugally) aren't useful in purely functional interfaces? * Are there fundamental reasons why GC algorithms cannot usefully apply to resources like video memory, file descriptors, etc? * Are there resource management techniques that have the flexibility, efficiency, and accuracy of GC that I could be using for these other resources? Thanks, - Conal 2008/4/14 Abhay Parvate : > Hello, > > In describing the Handle type, the GHC documentation says (in the > System.IO documentation): > > GHC note: a Handle will be automatically closed when the garbage collector > detects that it has become unreferenced by the program. However, relying on > this behaviour is not generally recommended: the garbage collector is > unpredictable. If possible, use explicit an explicit hClose to close Handles > when they are no longer required. GHC does not currently attempt to free up > file descriptors when they have run out, it is your responsibility to ensure > that this doesn't happen. > > But one cannot call hClose on Handles on which something like hGetContents > has been called; it just terminates the character list at the point till > which it has already read. Further the manual says that hGetContents puts > the handle in the semi-closed state, and further, > > A semi-closed handle becomes closed: > > - if hClose is applied to it; > - if an I/O error occurs when reading an item from the handle; > - or once the entire contents of the handle has been read. > > So do I safely assume here, according to the third point above, that it's > fine if I do not call hClose explicitly as far as I am consuming all the > contents returned by hGetContents? > > Thanks, > Abhay > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080415/f72f7295/attachment.htm From tatd2 at kent.ac.uk Tue Apr 15 20:16:00 2008 From: tatd2 at kent.ac.uk (Thomas Davie) Date: Tue Apr 15 20:11:45 2008 Subject: [Haskell-cafe] monadic debugging In-Reply-To: <701705975.20080416030413@gmail.com> References: <5ae4f2ba0804151553t7e95961fsc699df5a08b8abcd@mail.gmail.com> <701705975.20080416030413@gmail.com> Message-ID: On 16 Apr 2008, at 00:04, Bulat Ziganshin wrote: > Hello Vasili, > > Wednesday, April 16, 2008, 2:53:32 AM, you wrote: > >> I have an Linux executable of my Haskell library and test >> case. I see there are several debuggers, e.g. Buddha, Hat, etc. >> Which debugger is currently preferred for monadic (imperative) >> code? Thanks. > > i use print mainly :) btw, there is also built-in ghci debugger, i > suspect that it's closest one to the usual debuggers and most useful > one for imperative code (but i never tried anything, so don't trust > me :) Having worked lots on Hat, and studied all (I hope or I've got a hole in my research) of the debuggers out there, I'd have to say that debugging monadic code is still very much an unsolved problem. Putting print statements in is probably your best option. You may want to try hat-delta, or buddha's functional mapping mode -- both of them should be capable of reducing sequences of monadic operations to a single operation and a function map. Tom Davie From dbueno at gmail.com Tue Apr 15 20:59:56 2008 From: dbueno at gmail.com (Denis Bueno) Date: Tue Apr 15 20:55:12 2008 Subject: [Haskell-cafe] Wrong Answer Computing Graph Dominators Message-ID: <6dbd4d000804151759r2ca72957hae8cd60c91404e60@mail.gmail.com> I'm using the Data.Graph.Inductive.Query.Dominators library (http://haskell.org/ghc/docs/latest/html/libraries/fgl/Data-Graph-Inductive-Query-Dominators.html) with GHC 6.8.2. The library is a bit spare on comments, so I may or may not be using it correctly. My goal is to compute the set of nodes that dominate two different nodes of a DAG, with respect to one initial node. My approach is: import qualified Data.Graph.Inductive.Graph as Graph import qualified Data.Graph.Inductive.Query.Dominators as Dom uips = intersect domConfl domAssigned :: [Graph.Node] -- my goal domConfl = fromJust $ lookup conflNode domFromLastd -- dominators of first node domAssigned = fromJust $ lookup (negate conflNode) domFromLastd -- dominators of second node domFromLastd = Dom.dom conflGraph lastd -- source node I compute the dominators individually and my answer is their intersection. When I call the dom function, my assumption is that I need to pass it the source node, and it tells me, for any node x to which there is a path from the source, the list of nodes for which *any path* from source to x must touch, i.e., the list of dominators of x. The DAG in question is attached as a postscript file, which is generated by `dot -Tps` using the output of the Graphviz module directly from the graph object. The nodes for which I'm computing dominators are labeled -2 and 2 (that is, conflNode = 2). The problem is that I think the answer is wrong. In particular I think the set of dominators for -2 is {20, -2}, and the set for 2 is {20, 2}. Their intersection is {20}, which is what I expect. But what I am getting is: --> uips = [-9,20] --> domConfl = [2,-9,20] --> domAssigned = [-2,-9,-12,20] --> lastd = 20 But -9 is not a dominator for 2, since 20,-7,8,6,2 is a path from 20 to 2 that does not touch 9. -9 is also not a dominator for -2, since 20,-7,8,6,-2 is a path from 20 to -2 not touching 9. Am I missing something? I've simplified the code above slightly from the original code in order to ignore some irrelevancies. The original code is for computing a learned clause in a SAT solver. The code in the state that will reproduce the error above is available via a git clone: git clone http://fid.stygian.net/dpllsat Build via cabal, configuring with --disable-optimization in order to enable assertions, then run: ./dist/build/dsat/dsat ./tests/problems/uf20/uf20-0226.cnf The graph should be saved in conflict.dot and with `dot -Tps -o conflict.ps conflict.dot` you should be able to turn it into the ps file attached. The problematic code referenced above starts on line 759. -- Denis -------------- next part -------------- A non-text attachment was scrubbed... Name: bad-dominators.ps Type: application/postscript Size: 12697 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080415/746ed57b/bad-dominators-0001.ps From bjpop at csse.unimelb.edu.au Tue Apr 15 21:34:51 2008 From: bjpop at csse.unimelb.edu.au (Bernie Pope) Date: Tue Apr 15 21:23:28 2008 Subject: [Haskell-cafe] monadic debugging In-Reply-To: References: <5ae4f2ba0804151553t7e95961fsc699df5a08b8abcd@mail.gmail.com> <701705975.20080416030413@gmail.com> Message-ID: On 16/04/2008, at 10:16 AM, Thomas Davie wrote: > > On 16 Apr 2008, at 00:04, Bulat Ziganshin wrote: >> Hello Vasili, >> >> Wednesday, April 16, 2008, 2:53:32 AM, you wrote: >> >>> I have an Linux executable of my Haskell library and test >>> case. I see there are several debuggers, e.g. Buddha, Hat, etc. >>> Which debugger is currently preferred for monadic (imperative) >>> code? Thanks. >> >> i use print mainly :) btw, there is also built-in ghci debugger, i >> suspect that it's closest one to the usual debuggers and most useful >> one for imperative code (but i never tried anything, so don't >> trust me :) > > Having worked lots on Hat, and studied all (I hope or I've got a > hole in my research) of the debuggers out there, I'd have to say > that debugging monadic code is still very much an unsolved > problem. Putting print statements in is probably your best option. > > You may want to try hat-delta, or buddha's functional mapping mode > -- both of them should be capable of reducing sequences of monadic > operations to a single operation and a function map. I agree with Tom, that debugging monadic code is an open problem. From a practical level, I doubt buddha is going to be much help, because it has bit rotted, and is unsupported. Hat allows you to debug the program in different ways, and it gives you reduction traces, which can often be useful, so you may get some traction there. But I would try the ghci debugger first. Be warned: it forces you to be aware of lazy evaluation, which can be quite hard to understand, so you need a bit of practice with it. As for debugging monads, it depends on the complexity of the monad. If you are using standard monads (and that usually means transformers) then a lot of the plumbing will be invisible in the debugger, because breakpoints and stepping don't work in the libraries (you would have to copy the library code into your workspace, if you wanted to see the underlying monad code in action). I've successfully found bugs in code using the ghci debugger, where the code used a continuation transformer, over a state transformer, over an IO monad. It was easy enough to follow because I wasn't forced to see the plumbing underneath. In particular I wasn't forced to see the continuation, or the state, which really helps. Of, course, if I did want to see those things then I would have been in trouble. One question that has been in my head for a while now is that if you used the Unimo way to build monads, maybe they are easier to debug? The Unimo style is intentionally operational, and that may be a better fit to debugging, especially in the ghci debugger, which requires an operational way of thinking. Here's a link to the Unimo paper: http://web.cecs.pdx.edu/~cklin/ papers/unimo-143.pdf If you do make some progress with any of the debugging tools it would be very useful to hear how it went. We get very little feedback on successful debugging endeavours where tools were involved (maybe because the tools aren't helpful, it is hard to say). Cheers, Bernie. From jgoerzen at complete.org Tue Apr 15 23:15:29 2008 From: jgoerzen at complete.org (John Goerzen) Date: Tue Apr 15 23:11:08 2008 Subject: [Haskell-cafe] Hackage being too strict? Message-ID: When I went to make my upload of MissingH 1.0.1, Hackage rejected it, saying: Instead of 'ghc-options: -XPatternSignatures' use 'extensions: PatternSignatures' It hadn't rejected MissingH 1.0.0, even though it had the same thing. Now, my .cabal file has this: -- Hack because ghc-6.6 and the Cabal the comes with ghc-6.8.1 -- does not understand the PatternSignatures extension. -- The Cabal that comes with ghc-6.8.2 does understand it, so -- this hack can be dropped if we require Cabal-Version: >=1.2.3 If impl(ghc >= 6.8) GHC-Options: -XPatternSignatures which was contributed by Duncan Coutts. It seems arbitrary that Hackage would suddenly reject this valid usage. Thoughts? From gwern0 at gmail.com Tue Apr 15 23:53:03 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Tue Apr 15 23:48:57 2008 Subject: [Haskell-cafe] Hackage being too strict? In-Reply-To: References: Message-ID: <20080416035303.GA742245@localhost> On 2008.04.15 22:15:29 -0500, John Goerzen scribbled 0.7K characters: > When I went to make my upload of MissingH 1.0.1, Hackage rejected it, > saying: > > Instead of 'ghc-options: -XPatternSignatures' use 'extensions: PatternSignatures' > > It hadn't rejected MissingH 1.0.0, even though it had the same thing. > > Now, my .cabal file has this: > > -- Hack because ghc-6.6 and the Cabal the comes with ghc-6.8.1 > -- does not understand the PatternSignatures extension. > -- The Cabal that comes with ghc-6.8.2 does understand it, so > -- this hack can be dropped if we require Cabal-Version: >=1.2.3 > If impl(ghc >= 6.8) > GHC-Options: -XPatternSignatures > > which was contributed by Duncan Coutts. > > It seems arbitrary that Hackage would suddenly reject this valid > usage. > > Thoughts? Doesn't strike me as being any more arbitrary than demanding a Build-type: field. -- gwern submiss mega Audiotel meta SUBACS JSOTF NMIC EIP RAID CRA -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080415/d9bd506a/attachment.bin From jgoerzen at complete.org Tue Apr 15 23:57:19 2008 From: jgoerzen at complete.org (John Goerzen) Date: Tue Apr 15 23:52:40 2008 Subject: [Haskell-cafe] Hackage being too strict? In-Reply-To: <20080416035303.GA742245@localhost> References: <20080416035303.GA742245@localhost> Message-ID: <200804152257.19291.jgoerzen@complete.org> On Tuesday 15 April 2008 10:53:03 pm Gwern Branwen wrote: > On 2008.04.15 22:15:29 -0500, John Goerzen scribbled 0.7K characters: > > When I went to make my upload of MissingH 1.0.1, Hackage rejected it, > > saying: > > > > Instead of 'ghc-options: -XPatternSignatures' use 'extensions: > > PatternSignatures' > > > > It hadn't rejected MissingH 1.0.0, even though it had the same thing. > > > > Now, my .cabal file has this: > > > > -- Hack because ghc-6.6 and the Cabal the comes with ghc-6.8.1 > > -- does not understand the PatternSignatures extension. > > -- The Cabal that comes with ghc-6.8.2 does understand it, so > > -- this hack can be dropped if we require Cabal-Version: >=1.2.3 > > If impl(ghc >= 6.8) > > GHC-Options: -XPatternSignatures > > > > which was contributed by Duncan Coutts. > > > > It seems arbitrary that Hackage would suddenly reject this valid > > usage. > > > > Thoughts? > > Doesn't strike me as being any more arbitrary than demanding a Build-type: > field. Well, that's perhaps a problem too. It makes it difficult to produce a .cabal file that can both be parsed by GHC 6.6 and uploaded to Hackage. > > -- > gwern > submiss mega Audiotel meta SUBACS JSOTF NMIC EIP RAID CRA From jgoerzen at complete.org Wed Apr 16 00:02:01 2008 From: jgoerzen at complete.org (John Goerzen) Date: Wed Apr 16 00:03:30 2008 Subject: [Haskell-cafe] ANN: datapacker 1.0.0 Message-ID: Hi, I'm pleased to announce the first release of datapacker. datapacker is a tool to pack files into a minimum number of CDs, DVDs, or any other arbitrary bin. It groups file by size. It is designed to group files such that they fill fixed-size containers (called "bins") using the minimum number of containers. This is useful, for instance, if you want to archive a number of files to CD or DVD, and want to organize them such that you use the minimum possible number of CDs or DVDs. In many cases, datapacker executes almost instantaneously. Of particular note, the hardlink action can be used to effectively copy data into bins without having to actually copy the data at all. datapacker is a tool in the traditional Unix style; it can be used in pipes and call other tools. More information, including downloads and a full manual, can be found at: http://software.complete.org/datapacker datapacker is also available on Hackage. From dekudekuplex at yahoo.com Wed Apr 16 01:12:48 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Wed Apr 16 01:08:01 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <480455ED.1040506@daimi.au.dk> Message-ID: <338351.52842.qm@web30205.mail.mud.yahoo.com> Ok; I rewrote my recursive version of hanoi, preserving my semantics (i.e., working for lists of length 1 or more, rather than 0 or more, to start with) in a more Haskell-idiomatic manner; viz: hanoi_general_recursive.hs: hanoi :: a -> a -> a -> Int -> [(a, a)] hanoi source using dest n | n == 1 = [(source, dest)] | otherwise = hanoi source dest using (n-1) ++ hanoi source using dest 1 ++ hanoi using source dest (n-1) hanoi_shower :: Show a => [(a, a)] -> String hanoi_shower [(a, b)] = unlines ["Move " ++ show a ++ " to "++ show b ++ "."] hanoi_shower ((a, b):moves) = unlines ["Move " ++ show a ++ " to "++ show b ++ "."] ++ hanoi_shower moves (I wanted to start out with lists of length 1 as a base case before extending the base case to lists of length 0 because Luke Palmer had already solved it for 0, and I didn't want just to copy his solution--I can't learn anything if I just do that.) In WinHugs: Main> :load hanoi_general_recursive.hs Main> putStr (hanoi_shower (hanoi 'a' 'b' 'c' 2)) Move 'a' to 'b'. Move 'a' to 'c'. Move 'b' to 'c'. Main> putStr (hanoi_shower (hanoi 'a' 'b' 'c' 1)) Move 'a' to 'c'. Main> putStr (hanoi_shower (hanoi 1 2 3 2)) Move 1 to 2. Move 1 to 3. Move 2 to 3. Main> putStr (hanoi_shower (hanoi 1 2 3 1)) Move 1 to 3. Ok; it works now. Now that I have successfully created a recursive version that preserves my original semantics, it is time to extend the base case to handle lists of length 0. (Notice that I added a base case of n == 0 to hanoi itself as well, in addition to hanoi_shower; leaving this out in hanoi results in an error of "ERROR - C stack overflow" on an argument of n == 0 discs:) hanoi_general_recursive_base_0.hs: hanoi :: a -> a -> a -> Int -> [(a, a)] hanoi source using dest n | n == 0 = [] | n == 1 = [(source, dest)] | otherwise = hanoi source dest using (n-1) ++ hanoi source using dest 1 ++ hanoi using source dest (n-1) hanoi_shower :: Show a => [(a, a)] -> String hanoi_shower [] = "" hanoi_shower ((a, b):moves) = unlines ["Move " ++ show a ++ " to "++ show b ++ "."] ++ hanoi_shower moves Now, let's sit back and watch the fun in WinHugs: Main> :load hanoi_general_recursive_base_0.hs Main> putStr (hanoi_shower (hanoi 'a' 'b' 'c' 2)) Move 'a' to 'b'. Move 'a' to 'c'. Move 'b' to 'c'. Main> putStr (hanoi_shower (hanoi 'a' 'b' 'c' 0)) Main> putStr (hanoi_shower (hanoi 1 2 3 2)) Move 1 to 2. Move 1 to 3. Move 2 to 3. Main> putStr (hanoi_shower (hanoi 1 2 3 0)) Great! Just for reference, here's the code for the other versions for comparison: hanoi_general_list_comprehension_unwords.hs [Note: This version adds an extra space before the final '.' on each line.]: hanoi :: a -> a -> a -> Int -> [(a, a)] hanoi source using dest n | n == 1 = [(source, dest)] | otherwise = hanoi source dest using (n-1) ++ hanoi source using dest 1 ++ hanoi using source dest (n-1) hanoi_shower :: Show a => [(a, a)] -> String hanoi_shower moves = unlines [unwords ["Move", show a, "to", show b, "."] | (a, b) <- moves] -- hanoi_general_list_comprehension_unlines.hs: hanoi :: a -> a -> a -> Int -> [(a, a)] hanoi source using dest n | n == 1 = [(source, dest)] | otherwise = hanoi source dest using (n-1) ++ hanoi source using dest 1 ++ hanoi using source dest (n-1) hanoi_shower :: Show a => [(a, a)] -> String hanoi_shower moves = unlines ["Move " ++ show a ++ " to "++ show b ++ "." | (a, b) <- moves] -- hanoi_general_map_unlines.hs: hanoi :: a -> a -> a -> Int -> [(a, a)] hanoi source using dest n | n == 1 = [(source, dest)] | otherwise = hanoi source dest using (n-1) ++ hanoi source using dest 1 ++ hanoi using source dest (n-1) hanoi_shower :: Show a => [(a, a)] -> String hanoi_shower moves = unlines (map move moves) where move (a, b) = "Move " ++ show a ++ " to "++ show b ++ "." -- hanoi_general_recursive.hs [Note: This version only works for lists of length 1 or more.]: hanoi :: a -> a -> a -> Int -> [(a, a)] hanoi source using dest n | n == 1 = [(source, dest)] | otherwise = hanoi source dest using (n-1) ++ hanoi source using dest 1 ++ hanoi using source dest (n-1) hanoi_shower :: Show a => [(a, a)] -> String hanoi_shower [(a, b)] = unlines ["Move " ++ show a ++ " to "++ show b ++ "."] hanoi_shower ((a, b):moves) = unlines ["Move " ++ show a ++ " to "++ show b ++ "."] ++ hanoi_shower moves -- hanoi_general_recursive_base_0.hs [Note: This program is just the program contained in the file hanoi_general_recursive.hs, but extended to process lists of length 0 or more.]: hanoi :: a -> a -> a -> Int -> [(a, a)] hanoi source using dest n | n == 0 = [] | n == 1 = [(source, dest)] | otherwise = hanoi source dest using (n-1) ++ hanoi source using dest 1 ++ hanoi using source dest (n-1) hanoi_shower :: Show a => [(a, a)] -> String hanoi_shower [] = "" hanoi_shower ((a, b):moves) = unlines ["Move " ++ show a ++ " to "++ show b ++ "."] ++ hanoi_shower moves -- Thanks for all your help! Thanks especially to Tillmann Rendel, Neil Mitchell, and Luke Palmer for their sample code, to Brandon S. Allbery KF8NH for his acute questions, to Brent Yorgey for pointing out that hanoi_helper was superfluous, and to Abhay Parvate for his discussion of the meaning of Neil Mitchell's "mapM_ putStrLn == putStr . unlines" (I hope I didn't miss anybody). Next step: to figure out how to write hanoi in CPS. More on this later.... Benjamin L. Russell --- Tillmann Rendel wrote: > Benjamin L. Russel wrote: > > hanoi_shower ((a, b) : moves) > > | null moves = ... > > | otherwise == ... > > Luke Palmer wrote: > > More idiomatic pedantry: the way you will see > most Haskellers write > > this style of function is by pattern matching > rather than guards: > > > > hanoi_shower [] = ... > > hanoi_shower ((a,b):moves) = ... > > These two versions are semantically different! > Benjamin's versions works > for lists of length 1 or more, Luke's version works > for lists of length > 0 or more. > > Luke's version looks like a typical Haskell > solution, which would be > expressed in lispy syntax like this: > > (define hanoi_shower (lambda (xs) > (cond ((null xs) (...)) > (true, (let ((a, (first (first xs))) > (b, (rest (first xs))) > (moves, (rest xs))) > (...))))) > > The pattern matching in Haskell takes care of both > the cond and the let, > there's no need for guards or to actually call null > or any selector > functions. A nice exercise may be to implement the > map function using > primitive recursion. > > Tillmann > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From abhay.parvate at gmail.com Wed Apr 16 01:30:34 2008 From: abhay.parvate at gmail.com (Abhay Parvate) Date: Wed Apr 16 01:25:48 2008 Subject: [Haskell-cafe] GC'ing file handles and other resources In-Reply-To: References: Message-ID: <3c4d5adf0804152230x25abc55cg36480c52a2097b47@mail.gmail.com> Your mail gives me an idea, though I am not an iota familiar with compiler/garbage collector internals. Can we have some sort of internally maintained priority associated with allocated objects? The garbage collector should look at these objects first when it tries to free anything. The objects which hold other system resources apart from memory, such as file handles, video memory, and so on could be allocated as higher priority objects. Is such a thing possible? 2008/4/16 Conal Elliott : > Are Haskell folks satisfied with the practical necessity of imperatively & > explicitly reclaiming resources such as file handles, fonts & brushes, video > memory chunks, etc? Doesn't explicit freeing of these resources have the > same modularity and correctness problems as explicit freeing of system > memory (C/C++ programming)? > > I wrote a lovely purely functional graphics library that used video memory > to lazily compute and cache infinite-resolution images, and I found that I > don't know how to get my finalizers to run anytime soon after video memory > chunks become inaccessible. Explicit freeing isn't an option, since the > interface is functional, not imperative (IO). > > I guess I'm wondering a few things: > > * Are Haskell programmers generally content with imperative and > bug-friendly interfaces involving explicit freeing/closing of resources? > * Do people assume that these resources (or handling them frugally) aren't > useful in purely functional interfaces? > * Are there fundamental reasons why GC algorithms cannot usefully apply to > resources like video memory, file descriptors, etc? > * Are there resource management techniques that have the flexibility, > efficiency, and accuracy of GC that I could be using for these other > resources? > > Thanks, > - Conal > > 2008/4/14 Abhay Parvate : > > > Hello, > > > > In describing the Handle type, the GHC documentation says (in the > > System.IO documentation): > > > > GHC note: a Handle will be automatically closed when the garbage > > collector detects that it has become unreferenced by the program. However, > > relying on this behaviour is not generally recommended: the garbage > > collector is unpredictable. If possible, use explicit an explicit hClose to > > close Handles when they are no longer required. GHC does not currently > > attempt to free up file descriptors when they have run out, it is your > > responsibility to ensure that this doesn't happen. > > > > But one cannot call hClose on Handles on which something like > > hGetContents has been called; it just terminates the character list at the > > point till which it has already read. Further the manual says that > > hGetContents puts the handle in the semi-closed state, and further, > > > > A semi-closed handle becomes closed: > > > > - if hClose is applied to it; > > - if an I/O error occurs when reading an item from the handle; > > - or once the entire contents of the handle has been read. > > > > So do I safely assume here, according to the third point above, that > > it's fine if I do not call hClose explicitly as far as I am consuming all > > the contents returned by hGetContents? > > > > Thanks, > > Abhay > > > > _______________________________________________ > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080416/482ce8fb/attachment.htm From bulat.ziganshin at gmail.com Wed Apr 16 02:25:44 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Apr 16 02:22:01 2008 Subject: [Haskell-cafe] GC'ing file handles and other resources In-Reply-To: <3c4d5adf0804152230x25abc55cg36480c52a2097b47@mail.gmail.com> References: <3c4d5adf0804152230x25abc55cg36480c52a2097b47@mail.gmail.com> Message-ID: <96093350.20080416102544@gmail.com> Hello Abhay, Wednesday, April 16, 2008, 9:30:34 AM, you wrote: i think it will not work with current ghc GC - it scans entire memory/nursery when garbage collected so anyway you will need to wait until next GC event occurs > Your mail gives me an idea, though I am not an iota familiar with > compiler/garbage collector internals. Can we have some sort of > internally maintained priority associated with allocated objects? > The garbage collector should look at these objects first when it > tries to free anything. The objects which hold other system > resources apart from memory, such as file handles, video memory, and > so on could be allocated as higher priority objects. Is such a thing possible? > > 2008/4/16 Conal Elliott : > Are Haskell folks satisfied with the practical necessity of > imperatively & explicitly reclaiming resources such as file handles, > fonts & brushes, video memory chunks, etc?? Doesn't explicit freeing > of these resources have the same modularity and correctness problems > as explicit freeing of system memory (C/C++ programming)? > > I wrote a lovely purely functional graphics library that used video > memory to lazily compute and cache infinite-resolution images, and I > found that I don't know how to get my finalizers to run anytime soon > after video memory chunks become inaccessible.? Explicit freeing > isn't an option, since the interface is functional, not imperative (IO). > > I guess I'm wondering a few things: > * Are Haskell programmers generally content with imperative and > bug-friendly interfaces involving explicit freeing/closing of resources? > * Do people assume that these resources (or handling them frugally) > aren't useful in purely functional interfaces? > * Are there fundamental reasons why GC algorithms cannot usefully > apply to resources like video memory, file descriptors, etc? > * Are there resource management techniques that have the > flexibility, efficiency, and accuracy of GC that I could be using for these other resources? > > Thanks, > ? - Conal > 2008/4/14 Abhay Parvate : > Hello, > In describing the Handle type, the GHC documentation says (in the System.IO documentation): > GHC note: a Handle will be automatically closed when the garbage > collector detects that it has become unreferenced by the program. > However, relying on this behaviour is not generally recommended: > the garbage collector is unpredictable. If possible, use explicit > an explicit hClose to close Handles when they are no longer > required. GHC does not currently attempt to free up file > descriptors when they have run out, it is your responsibility to ensure that this doesn't happen. > But one cannot call hClose on Handles on which something like > hGetContents has been called; it just terminates the character list > at the point till which it has already read. Further the manual says > that hGetContents puts the handle in the semi-closed state, and further, > > A semi-closed handle becomes closed: > if hClose is applied to it; if an I/O error occurs when reading > an item from the handle; or once the entire contents of the handle has been read. > So do I safely assume here, according to the third point above, > that it's fine if I do not call hClose explicitly as far as I am > consuming all the contents returned by hGetContents? > Thanks, > Abhay > > _______________________________________________ > 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 > > -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From abhay.parvate at gmail.com Wed Apr 16 02:51:07 2008 From: abhay.parvate at gmail.com (Abhay Parvate) Date: Wed Apr 16 02:46:27 2008 Subject: [Haskell-cafe] GC'ing file handles and other resources In-Reply-To: <96093350.20080416102544@gmail.com> References: <3c4d5adf0804152230x25abc55cg36480c52a2097b47@mail.gmail.com> <96093350.20080416102544@gmail.com> Message-ID: <3c4d5adf0804152351g4c8c18e2i81860f9a92d355e6@mail.gmail.com> I am not saying that it should claim it as soon as it is unused; all I am saying that as soon as a priority object becomes unreferenced, it should be the first choice for collecting in the next collect. Further I was under the impression (I may be wrong) that it uses a generational GC and therefore scans allocated memory incrementally; not the whole at a time. Please correct me if I am wrong. Regards, Abhay On Wed, Apr 16, 2008 at 11:55 AM, Bulat Ziganshin wrote: > Hello Abhay, > > Wednesday, April 16, 2008, 9:30:34 AM, you wrote: > > i think it will not work with current ghc GC - it scans entire > memory/nursery when garbage collected so anyway you will need to wait > until next GC event occurs > > > Your mail gives me an idea, though I am not an iota familiar with > > compiler/garbage collector internals. Can we have some sort of > > internally maintained priority associated with allocated objects? > > The garbage collector should look at these objects first when it > > tries to free anything. The objects which hold other system > > resources apart from memory, such as file handles, video memory, and > > so on could be allocated as higher priority objects. Is such a thing > possible? > > > > 2008/4/16 Conal Elliott : > > Are Haskell folks satisfied with the practical necessity of > > imperatively & explicitly reclaiming resources such as file handles, > > fonts & brushes, video memory chunks, etc? Doesn't explicit freeing > > of these resources have the same modularity and correctness problems > > as explicit freeing of system memory (C/C++ programming)? > > > > I wrote a lovely purely functional graphics library that used video > > memory to lazily compute and cache infinite-resolution images, and I > > found that I don't know how to get my finalizers to run anytime soon > > after video memory chunks become inaccessible. Explicit freeing > > isn't an option, since the interface is functional, not imperative (IO). > > > > I guess I'm wondering a few things: > > > * Are Haskell programmers generally content with imperative and > > bug-friendly interfaces involving explicit freeing/closing of resources? > > * Do people assume that these resources (or handling them frugally) > > aren't useful in purely functional interfaces? > > * Are there fundamental reasons why GC algorithms cannot usefully > > apply to resources like video memory, file descriptors, etc? > > * Are there resource management techniques that have the > > flexibility, efficiency, and accuracy of GC that I could be using for > these other resources? > > > > Thanks, > > - Conal > > > 2008/4/14 Abhay Parvate : > > Hello, > > > In describing the Handle type, the GHC documentation says (in the > System.IO documentation): > > > GHC note: a Handle will be automatically closed when the garbage > > collector detects that it has become unreferenced by the program. > > However, relying on this behaviour is not generally recommended: > > the garbage collector is unpredictable. If possible, use explicit > > an explicit hClose to close Handles when they are no longer > > required. GHC does not currently attempt to free up file > > descriptors when they have run out, it is your responsibility to ensure > that this doesn't happen. > > > But one cannot call hClose on Handles on which something like > > hGetContents has been called; it just terminates the character list > > at the point till which it has already read. Further the manual says > > that hGetContents puts the handle in the semi-closed state, and further, > > > > A semi-closed handle becomes closed: > > if hClose is applied to it; if an I/O error occurs when reading > > an item from the handle; or once the entire contents of the handle has > been read. > > So do I safely assume here, according to the third point above, > > that it's fine if I do not call hClose explicitly as far as I am > > consuming all the contents returned by hGetContents? > > > Thanks, > > Abhay > > > > _______________________________________________ > > 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 > > > > > > > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080416/917d92a9/attachment.htm From bulat.ziganshin at gmail.com Wed Apr 16 03:07:11 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Apr 16 03:12:10 2008 Subject: [Haskell-cafe] GC'ing file handles and other resources In-Reply-To: <3c4d5adf0804152351g4c8c18e2i81860f9a92d355e6@mail.gmail.com> References: <3c4d5adf0804152230x25abc55cg36480c52a2097b47@mail.gmail.com> <96093350.20080416102544@gmail.com> <3c4d5adf0804152351g4c8c18e2i81860f9a92d355e6@mail.gmail.com> Message-ID: <476603809.20080416110711@gmail.com> Hello Abhay, Wednesday, April 16, 2008, 10:51:07 AM, you wrote: > I am not saying that it should claim it as soon as it is unused; > all I am saying that as soon as a priority object becomes > unreferenced, it should be the first choice for collecting in the next collect. on the GC, all unreferenced objects are collected. there is no difference which ones will be collected first - anyway program is stopped until whole GC will be finished > Further I was under the impression (I may be wrong) that it uses a > generational GC and therefore scans allocated memory incrementally; > not the whole at a time. Please correct me if I am wrong. yes, it uses generational GC. data are first allocated in small 256k block and when it is filled, GC for this small block occurs. data that are still alive then moved to the global heap. this minor GC doesn't scan global heap. if it will do this, each minor GC will become as slow as major ones "Generational garbage collection for Haskell" http://research.microsoft.com/~simonpj/Papers/gen-gc-for-haskell.ps.gz > > Regards, > Abhay > On Wed, Apr 16, 2008 at 11:55 AM, Bulat Ziganshin > wrote: > Hello Abhay, > > Wednesday, April 16, 2008, 9:30:34 AM, you wrote: > > i think it will not work with current ghc GC - it scans entire > memory/nursery when garbage collected so anyway you will need to wait > until next GC event occurs > >> Your mail gives me an idea, though I am not an iota familiar with >> compiler/garbage collector internals. Can we have some sort of >> internally maintained priority associated with allocated objects? >> The garbage collector should look at these objects first when it >> tries to free anything. The objects which hold other system >> resources apart from memory, such as file handles, video memory, and >> so on could be allocated as higher priority objects. Is such a thing possible? >> >> 2008/4/16 Conal Elliott : >> ?Are Haskell folks satisfied with the practical necessity of >> imperatively & explicitly reclaiming resources such as file handles, >> fonts & brushes, video memory chunks, etc?? Doesn't explicit freeing >> of these resources have the same modularity and correctness problems >> as explicit freeing of system memory (C/C++ programming)? >> >> I wrote a lovely purely functional graphics library that used video >> memory to lazily compute and cache infinite-resolution images, and I >> found that I don't know how to get my finalizers to run anytime soon >> after video memory chunks become inaccessible.? Explicit freeing >> isn't an option, since the interface is functional, not imperative (IO). >> >> I guess I'm wondering a few things: > >> * Are Haskell programmers generally content with imperative and >> bug-friendly interfaces involving explicit freeing/closing of resources? >> * Do people assume that these resources (or handling them frugally) >> aren't useful in purely functional interfaces? >> ?* Are there fundamental reasons why GC algorithms cannot usefully >> apply to resources like video memory, file descriptors, etc? >> * Are there resource management techniques that have the >> flexibility, efficiency, and accuracy of GC that I could be using for these other resources? >> >> Thanks, >> ? - Conal > >> 2008/4/14 Abhay Parvate : >> ?Hello, > >> In describing the Handle type, the GHC documentation says (in the System.IO documentation): > >> GHC note: a Handle will be automatically closed when the garbage >> collector detects that it has become unreferenced by the program. >> However, relying on this behaviour is not generally recommended: >> the garbage collector is unpredictable. ?If possible, use explicit >> an explicit hClose to close Handles when they are no longer >> required. ?GHC does not currently attempt to free up file >> descriptors when they have run out, it is your responsibility to ?ensure that this doesn't happen. > >> But one cannot call hClose on Handles on which something like >> hGetContents has been called; it just terminates the character list >> at the point till which it has already read. Further the manual says >> that hGetContents puts the handle in the semi-closed state, and further, >> >> A semi-closed handle becomes closed: >> ?if hClose is applied to it; ?if an I/O error occurs when reading >> an item from the handle; ?or once the entire contents of the handle has been read. >> So do I safely assume here, according to the third point above, >> that it's fine if I do not call hClose explicitly as far as I am >> consuming all the contents returned by hGetContents? > >> Thanks, >> Abhay >> >> _______________________________________________ >> ?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 >> > > >> > > > > -- > Best regards, > ?Bulat ? ? ? ? ? ? ? ? ? ? ? ? ? ?mailto:Bulat.Ziganshin@gmail.com > > > -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From abhay.parvate at gmail.com Wed Apr 16 03:43:08 2008 From: abhay.parvate at gmail.com (Abhay Parvate) Date: Wed Apr 16 03:38:23 2008 Subject: [Haskell-cafe] GC'ing file handles and other resources In-Reply-To: <476603809.20080416110711@gmail.com> References: <3c4d5adf0804152230x25abc55cg36480c52a2097b47@mail.gmail.com> <96093350.20080416102544@gmail.com> <3c4d5adf0804152351g4c8c18e2i81860f9a92d355e6@mail.gmail.com> <476603809.20080416110711@gmail.com> Message-ID: <3c4d5adf0804160043x5745d03cwe0dd16a32a84ca77@mail.gmail.com> Thanks, both for the summary and for the link. Will try to go through it. Regards, Abhay On Wed, Apr 16, 2008 at 12:37 PM, Bulat Ziganshin wrote: > Hello Abhay, > > Wednesday, April 16, 2008, 10:51:07 AM, you wrote: > > > I am not saying that it should claim it as soon as it is unused; > > all I am saying that as soon as a priority object becomes > > unreferenced, it should be the first choice for collecting in the next > collect. > > on the GC, all unreferenced objects are collected. there is no > difference which ones will be collected first - anyway program is > stopped until whole GC will be finished > > > Further I was under the impression (I may be wrong) that it uses a > > generational GC and therefore scans allocated memory incrementally; > > not the whole at a time. Please correct me if I am wrong. > > yes, it uses generational GC. data are first allocated in small 256k block > and when it is filled, GC for this small block occurs. data that are > still alive then moved to the global heap. this minor GC doesn't scan > global heap. if it will do this, each minor GC will become as slow as > major ones > > "Generational garbage collection for Haskell" > http://research.microsoft.com/~simonpj/Papers/gen-gc-for-haskell.ps.gz > > > > > Regards, > > Abhay > > > On Wed, Apr 16, 2008 at 11:55 AM, Bulat Ziganshin > > wrote: > > Hello Abhay, > > > > Wednesday, April 16, 2008, 9:30:34 AM, you wrote: > > > > i think it will not work with current ghc GC - it scans entire > > memory/nursery when garbage collected so anyway you will need to wait > > until next GC event occurs > > > > >> Your mail gives me an idea, though I am not an iota familiar with > >> compiler/garbage collector internals. Can we have some sort of > >> internally maintained priority associated with allocated objects? > >> The garbage collector should look at these objects first when it > >> tries to free anything. The objects which hold other system > >> resources apart from memory, such as file handles, video memory, and > >> so on could be allocated as higher priority objects. Is such a thing > possible? > >> > >> 2008/4/16 Conal Elliott : > >> Are Haskell folks satisfied with the practical necessity of > >> imperatively & explicitly reclaiming resources such as file handles, > >> fonts & brushes, video memory chunks, etc? Doesn't explicit freeing > >> of these resources have the same modularity and correctness problems > >> as explicit freeing of system memory (C/C++ programming)? > >> > >> I wrote a lovely purely functional graphics library that used video > >> memory to lazily compute and cache infinite-resolution images, and I > >> found that I don't know how to get my finalizers to run anytime soon > >> after video memory chunks become inaccessible. Explicit freeing > >> isn't an option, since the interface is functional, not imperative > (IO). > >> > >> I guess I'm wondering a few things: > > > >> * Are Haskell programmers generally content with imperative and > >> bug-friendly interfaces involving explicit freeing/closing of > resources? > >> * Do people assume that these resources (or handling them frugally) > >> aren't useful in purely functional interfaces? > >> * Are there fundamental reasons why GC algorithms cannot usefully > >> apply to resources like video memory, file descriptors, etc? > >> * Are there resource management techniques that have the > >> flexibility, efficiency, and accuracy of GC that I could be using for > these other resources? > >> > >> Thanks, > >> - Conal > > > >> 2008/4/14 Abhay Parvate : > >> Hello, > > > >> In describing the Handle type, the GHC documentation says (in the > System.IO documentation): > > > >> GHC note: a Handle will be automatically closed when the garbage > >> collector detects that it has become unreferenced by the program. > >> However, relying on this behaviour is not generally recommended: > >> the garbage collector is unpredictable. If possible, use explicit > >> an explicit hClose to close Handles when they are no longer > >> required. GHC does not currently attempt to free up file > >> descriptors when they have run out, it is your responsibility to > ensure that this doesn't happen. > > > >> But one cannot call hClose on Handles on which something like > >> hGetContents has been called; it just terminates the character list > >> at the point till which it has already read. Further the manual says > >> that hGetContents puts the handle in the semi-closed state, and > further, > >> > >> A semi-closed handle becomes closed: > >> if hClose is applied to it; if an I/O error occurs when reading > >> an item from the handle; or once the entire contents of the handle > has been read. > >> So do I safely assume here, according to the third point above, > >> that it's fine if I do not call hClose explicitly as far as I am > >> consuming all the contents returned by hGetContents? > > > >> Thanks, > >> Abhay > >> > >> _______________________________________________ > >> 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 > >> > > > > > >> > > > > > > > > -- > > Best regards, > > Bulat mailto:Bulat.Ziganshin@gmail.com > > > > > > > > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080416/aab4b95e/attachment.htm From phercek at gmail.com Wed Apr 16 03:49:57 2008 From: phercek at gmail.com (Peter Hercek) Date: Wed Apr 16 03:45:09 2008 Subject: [Haskell-cafe] Re: GC'ing file handles and other resources In-Reply-To: <3c4d5adf0804152351g4c8c18e2i81860f9a92d355e6@mail.gmail.com> References: <3c4d5adf0804152230x25abc55cg36480c52a2097b47@mail.gmail.com> <96093350.20080416102544@gmail.com> <3c4d5adf0804152351g4c8c18e2i81860f9a92d355e6@mail.gmail.com> Message-ID: Abhay Parvate wrote: > I am not saying that it should claim it as soon as it is unused; all I > am saying that as soon as a priority object becomes unreferenced, it > should be the first choice for collecting in the next collect. > Further I was under the impression (I may be wrong) that it uses a > generational GC and therefore scans allocated memory incrementally; not > the whole at a time. Please correct me if I am wrong. > It would be hard to separate memory collection from handle collection. But what could be done is start GC not only when memory consumption reaches some threshold but also when handle consumption reaches some (other) threshold. I'm curious whether it would work :-) Peter. From miguellordelo at gmail.com Wed Apr 16 03:58:03 2008 From: miguellordelo at gmail.com (Miguel Lordelo) Date: Wed Apr 16 03:53:21 2008 Subject: [Haskell-cafe] C++ interface with Haskell Message-ID: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> Hi all, Well...somehow I'm a beginner in Haskell. But actually my interest in Haskell will increase if it is possible to call a haskell function in C++. Something like GreenCard ( http://www.haskell.org/greencard/ ) simplifying the task of interfacing Haskell programs to external libraries (usually). But is there also a task to interface a foreign language with Haskell, but calling Haskell functions. Or c2hs which is an interface generator that simplifies the development of Haskell bindings to C libraries. I want to know this, because in my company some guys are doing some testing with Frotran and MatLab and I want to show them the power of haskell and the software which we are using is implemented in C++ (there is the reason to make Haskel -> C++). I read somewhere that the only way for C++ calling a haskell function is to create a binding between Haskell and C and from C to C++, but a easy "Hello World" example was not there. Unfortunatelly I couldn't found anything usefull, like an complete example, or how to compile the code from haskell to C to C++. Can sombody help me, please :P Chears, Miguel Lordelo. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080416/ea96e956/attachment.htm From ketil at malde.org Wed Apr 16 04:45:16 2008 From: ketil at malde.org (Ketil Malde) Date: Wed Apr 16 04:40:20 2008 Subject: [Haskell-cafe] compressed pointers? In-Reply-To: <87tzi2kxwz.fsf@nmd9999.imr.no> (Ketil Malde's message of "Wed\, 16 Apr 2008 10\:26\:52 +0200") References: <20080415120614.15389413.malcwallace@googlemail.com> <5ab17e790804151005y703c5d0dj50cf2f9b51cf1362@mail.gmail.com> <87y77eky3j.fsf@nmd9999.imr.no> <87tzi2kxwz.fsf@nmd9999.imr.no> Message-ID: <87od8akx2b.fsf_-_@nmd9999.imr.no> One of the downsides of a 64-bit environment is the increased size of pointers. This means that the cost of a String increases from something like 12 bytes per char to something like 24. I notice BEA uses something called "compressed pointers" to get the 64-bit (more registers, etc) benefits without paying the (cache-thrashing) cost. http://e-docs.bea.com/jrockit/releases/5026x/relnotes/relnotes.html#wp1079760 Something for GHC? -k -- If I haven't seen further, it is by standing in the footprints of giants From mnislaih at gmail.com Wed Apr 16 06:39:28 2008 From: mnislaih at gmail.com (pepe) Date: Wed Apr 16 06:34:48 2008 Subject: [Haskell-cafe] monadic debugging In-Reply-To: <5ae4f2ba0804151553t7e95961fsc699df5a08b8abcd@mail.gmail.com> References: <5ae4f2ba0804151553t7e95961fsc699df5a08b8abcd@mail.gmail.com> Message-ID: <8F1AF6DC-7182-48CB-AD15-151479B5E6C5@gmail.com> On 16/04/2008, at 0:53, Galchin, Vasili wrote: > Hello, > > I have an Linux executable of my Haskell library and test case. > I see there are several debuggers, e.g. Buddha, Hat, etc. Which > debugger is currently preferred for monadic (imperative) code? Thanks. > > Vasili For debugging IO code, I have used the GHCi debugger with great success in several occasions. Particularly, :steplocal is very useful in monadic code. Make sure you read at least the documentation in GHC docs, and the tutorial recently published in The Monad Reader. The latest version of the debugger in HEAD is extended to print the contents of IORefs automatically, which you may find useful too. Cheers, pepe From jmaessen at alum.mit.edu Wed Apr 16 08:17:10 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Wed Apr 16 08:12:32 2008 Subject: [Haskell-cafe] compressed pointers? In-Reply-To: <87od8akx2b.fsf_-_@nmd9999.imr.no> References: <20080415120614.15389413.malcwallace@googlemail.com> <5ab17e790804151005y703c5d0dj50cf2f9b51cf1362@mail.gmail.com> <87y77eky3j.fsf@nmd9999.imr.no> <87tzi2kxwz.fsf@nmd9999.imr.no> <87od8akx2b.fsf_-_@nmd9999.imr.no> Message-ID: <57723B93-E1CC-4EBC-ADC8-B92CCE809646@alum.mit.edu> On Apr 16, 2008, at 4:45 AM, Ketil Malde wrote: > I notice BEA uses something called "compressed pointers" to get the > 64-bit (more registers, etc) benefits without paying the > (cache-thrashing) cost. But only if you're not *actually* using a 64-bit address space. From their own documentation: The heap size will be limited to less than 4 GB; therefore, you can only use this option for applications that demand less than 4 GB of live data. The heap will be reduced to meet this size limitation if you specify a larger initial (-Xms) or maximum (-Xmx) heap size. (http://edocs.bea.com/jrockit/jrdocs/refman/optionXX.html#wp1021022) So this amounts to saying "we can use the 64-bit ISA but still use 32- bit pointers with all the restrictions that accompany them". You might be able to keep non-heap data around in excess of 4GB (eg it might be possible to mmap a file *and* have 4GB of heap data, and maybe even keep thread stacks off-heap as well). You can take advantage of pointer alignment to get address spaces of 8-32GB (by shifting 32-bit pointers before dereferencing them), but that requires taking back the pointer bits that GHC just stole for pointer tagging. -Jan From haberg at math.su.se Wed Apr 16 08:56:33 2008 From: haberg at math.su.se (Hans Aberg) Date: Wed Apr 16 08:51:51 2008 Subject: [Haskell-cafe] Funny State monad dependency Message-ID: When I load the State module in Hugs, then I can define the function f below, but I do not immediately see exactly what function "return" returns. Explanation welcome. For example: > f [2..4] [6..9] [6,7,8,9,6,7,8,9,6,7,8,9] That is, it just repeats the second argument as many times as the length of the second argument. Hans Aberg -------- import Control.Monad.State f :: Monad a => a b -> a c -> a c f x y = x >>= (return y) -------- From miguelimo38 at yandex.ru Wed Apr 16 09:04:49 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Wed Apr 16 09:00:13 2008 Subject: [Haskell-cafe] Funny State monad dependency In-Reply-To: References: Message-ID: <7588A9B1-71E7-4977-9C79-153E5D4EC3E7@yandex.ru> It has nothing to do with State; it actually works in List monad. "return y" is just another way of writing "[y]". You don't need to import Control.Monad.State for this to work; you only need Control.Monad (which is imported by the former). On 16 Apr 2008, at 16:56, Hans Aberg wrote: > When I load the State module in Hugs, then I can define the function > f below, but I do not immediately see exactly what function "return" > returns. Explanation welcome. > > For example: > > f [2..4] [6..9] > [6,7,8,9,6,7,8,9,6,7,8,9] > That is, it just repeats the second argument as many times as the > length of the second argument. > > Hans Aberg > > -------- > import Control.Monad.State > > f :: Monad a => a b -> a c -> a c > f x y = x >>= (return y) > -------- > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From miguelimo38 at yandex.ru Wed Apr 16 09:14:14 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Wed Apr 16 09:09:32 2008 Subject: [Haskell-cafe] Funny State monad dependency In-Reply-To: <7588A9B1-71E7-4977-9C79-153E5D4EC3E7@yandex.ru> References: <7588A9B1-71E7-4977-9C79-153E5D4EC3E7@yandex.ru> Message-ID: Before somebody noticed: I'm wrong. It's not List monad, but also a "(->) x" monad, also defined in Control.Monad. Therefore, "return y" is just "const y". Therefore, x >>= (return y) = x >>= (const y) = x >> y On 16 Apr 2008, at 17:04, Miguel Mitrofanov wrote: > It has nothing to do with State; it actually works in List monad. > "return y" is just another way of writing "[y]". > > You don't need to import Control.Monad.State for this to work; you > only need Control.Monad (which is imported by the former). > > On 16 Apr 2008, at 16:56, Hans Aberg wrote: >> When I load the State module in Hugs, then I can define the >> function f below, but I do not immediately see exactly what >> function "return" returns. Explanation welcome. >> >> For example: >> > f [2..4] [6..9] >> [6,7,8,9,6,7,8,9,6,7,8,9] >> That is, it just repeats the second argument as many times as the >> length of the second argument. >> >> Hans Aberg >> >> -------- >> import Control.Monad.State >> >> f :: Monad a => a b -> a c -> a c >> f x y = x >>= (return y) >> -------- >> >> _______________________________________________ >> 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 From zunino at di.unipi.it Wed Apr 16 09:22:47 2008 From: zunino at di.unipi.it (Roberto Zunino) Date: Wed Apr 16 09:14:09 2008 Subject: [Haskell-cafe] Funny State monad dependency In-Reply-To: <7588A9B1-71E7-4977-9C79-153E5D4EC3E7@yandex.ru> References: <7588A9B1-71E7-4977-9C79-153E5D4EC3E7@yandex.ru> Message-ID: <4805FDA7.4070404@di.unipi.it> Miguel Mitrofanov wrote: > It has nothing to do with State; it actually works in List monad. > "return y" is just another way of writing "[y]". Actually, it seems that in this case return is from the ((->) a) monad, i.e. return=const. f x y = x >>= return y = x >>= const y = (concat . map) (const y) x = concat (map (const y) x) Zun. From daniel.is.fischer at web.de Wed Apr 16 09:22:09 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Apr 16 09:15:42 2008 Subject: [Haskell-cafe] Funny State monad dependency In-Reply-To: References: Message-ID: <200804161522.09931.daniel.is.fischer@web.de> Am Mittwoch, 16. April 2008 14:56 schrieb Hans Aberg: > When I load the State module in Hugs, then I can define the function > f below, but I do not immediately see exactly what function "return" > returns. Explanation welcome. > > For example: > > f [2..4] [6..9] > > [6,7,8,9,6,7,8,9,6,7,8,9] > That is, it just repeats the second argument as many times as the > length of the second argument. > > Hans Aberg > > -------- > import Control.Monad.State > > f :: Monad a => a b -> a c -> a c > f x y = x >>= (return y) > -------- > The point is the instance Monad ((->) a) where return x = const x f >>= g = \x -> g (f x) x which is defined in Control.Monad.Instances (try in GHCI: Prelude> let f x y = x >>= (return y) Prelude> :t f f :: (Monad ((->) a), Monad m) => m a -> m b -> m b ). This is imported into Control.Monad.State and hence the instance is visible. By the type of (>>=), (return y) must have type (a -> m b), on the other hand, if y has type c, then (return y) has type (m' c) for some monad m'. Unifying m' c and a -> m b gives then m' === ((->) a) and c === m b. Now according to the instance, return y === const y, so f is the same as g x y = x >>= (const y). From haberg at math.su.se Wed Apr 16 09:41:24 2008 From: haberg at math.su.se (Hans Aberg) Date: Wed Apr 16 09:36:39 2008 Subject: [Haskell-cafe] Funny State monad dependency In-Reply-To: <200804161522.09931.daniel.is.fischer@web.de> References: <200804161522.09931.daniel.is.fischer@web.de> Message-ID: <91C12AA5-C873-4042-8DD4-5CD1ED1BF9F6@math.su.se> On 16 Apr 2008, at 15:22, Daniel Fischer wrote: > The point is the > > instance Monad ((->) a) where > return x = const x > f >>= g = \x -> g (f x) x > > which is defined in Control.Monad.Instances... Thank you. I suspected there was an instance somewhere, and I wanted to know where it is defined. > (try in GHCI: > Prelude> let f x y = x >>= (return y) > Prelude> :t f > f :: (Monad ((->) a), Monad m) => m a -> m b -> m b > ). It works in Hugs too. If I don't import Control.Monad.State, then f :: (Monad a, Monad ((->) b)) => a b -> a c -> a c > This is imported into Control.Monad.State and hence the instance is > visible. > > By the type of (>>=), (return y) must have type (a -> m b), on the > other hand, > if y has type c, then (return y) has type (m' c) for some monad m'. > Unifying > m' c and a -> m b gives then m' === ((->) a) and c === m b. > Now according to the instance, return y === const y, so f is the > same as > g x y = x >>= (const y). Good to know the details. Thanks. Hans From haberg at math.su.se Wed Apr 16 10:08:09 2008 From: haberg at math.su.se (Hans Aberg) Date: Wed Apr 16 10:03:25 2008 Subject: [Haskell-cafe] Funny State monad dependency In-Reply-To: References: <7588A9B1-71E7-4977-9C79-153E5D4EC3E7@yandex.ru> Message-ID: <06651BFA-E008-41C6-9D28-F253EFBFCEA9@math.su.se> On 16 Apr 2008, at 15:14, Miguel Mitrofanov wrote: > Before somebody noticed: I'm wrong. > > It's not List monad, but also a "(->) x" monad, also defined in > Control.Monad. > > Therefore, "return y" is just "const y". Therefore, > > x >>= (return y) = x >>= (const y) = x >> y Right. It is an interesting monad, but it may cause unexpected effect, in view of its implicit name. Hans From ivan.miljenovic at gmail.com Wed Apr 16 10:23:00 2008 From: ivan.miljenovic at gmail.com (Ivan Miljenovic) Date: Wed Apr 16 10:18:12 2008 Subject: [Haskell-cafe] Searching for possible PhD supervisors/projects Message-ID: Next year, I'm thinking of going overseas (I'm currently in Australia) to do a PhD. Preferably, I'd like to do something in the area of computational combinatorics using Haskell. Does anyone know of any particular unis/supervisors I should be looking at/talking to about this? -- Ivan Lazar Miljenovic From Tom.Schrijvers at cs.kuleuven.be Wed Apr 16 10:30:27 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Wed Apr 16 10:26:39 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies Message-ID: Hello, I'm looking for practical examples of non-full functional dependencies and would be grateful if anyone could show me some or point to applications using them. A non-full functional dependency is one involves only part of the parameters of a type class. E.g. class C a b c | a -> b has a non-full functional dependency a -> b which does not involve c. Thanks, Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From d.w.mead at gmail.com Wed Apr 16 10:40:44 2008 From: d.w.mead at gmail.com (Dan Mead) Date: Wed Apr 16 10:35:56 2008 Subject: [Haskell-cafe] C++ interface with Haskell In-Reply-To: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> References: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> Message-ID: <59ba068d0804160740m3529218dpbb9efaf61f0a32ce@mail.gmail.com> write the C wrapper that calls haskell, then link that to your C++ objects I think what you're really asking is how to call C from C++ -Dan 2008/4/16 Miguel Lordelo : > Hi all, > > Well...somehow I'm a beginner in Haskell. But actually my interest in > Haskell will increase if it is possible to call a haskell function in C++. > Something like GreenCard ( http://www.haskell.org/greencard/ ) simplifying > the task of interfacing Haskell programs to external libraries (usually). > But is there also a task to interface a foreign language with Haskell, but > calling Haskell functions. Or c2hs which is an interface generator that > simplifies the development of Haskell bindings to C libraries. > > I want to know this, because in my company some guys are doing some > testing with Frotran and MatLab and I want to show them the power of haskell > and the software which we are using is implemented in C++ (there is the > reason to make Haskel -> C++). > > I read somewhere that the only way for C++ calling a haskell function is > to create a binding between Haskell and C and from C to C++, but a easy > "Hello World" example was not there. > Unfortunatelly I couldn't found anything usefull, like an complete > example, or how to compile the code from haskell to C to C++. > > Can sombody help me, please :P > > Chears, > Miguel Lordelo. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080416/7af69145/attachment.htm From dons at galois.com Wed Apr 16 10:59:34 2008 From: dons at galois.com (Don Stewart) Date: Wed Apr 16 10:54:48 2008 Subject: [Haskell-cafe] compressed pointers? In-Reply-To: <87od8akx2b.fsf_-_@nmd9999.imr.no> References: <20080415120614.15389413.malcwallace@googlemail.com> <5ab17e790804151005y703c5d0dj50cf2f9b51cf1362@mail.gmail.com> <87y77eky3j.fsf@nmd9999.imr.no> <87tzi2kxwz.fsf@nmd9999.imr.no> <87od8akx2b.fsf_-_@nmd9999.imr.no> Message-ID: <20080416145934.GB12207@scytale.galois.com> ketil: > > One of the downsides of a 64-bit environment is the increased size of > pointers. This means that the cost of a String increases from > something like 12 bytes per char to something like 24. > > I notice BEA uses something called "compressed pointers" to get the > 64-bit (more registers, etc) benefits without paying the > (cache-thrashing) cost. > > http://e-docs.bea.com/jrockit/releases/5026x/relnotes/relnotes.html#wp1079760 > > Something for GHC? > One small upside (performance wise), is that the bottom 3 bits of the pointer are now used to encode the constructor on 64 bits, so 'case' gets a good percent cheaper. -- Don From dons at galois.com Wed Apr 16 11:01:59 2008 From: dons at galois.com (Don Stewart) Date: Wed Apr 16 10:57:11 2008 Subject: [Haskell-cafe] Module for parsing C (pre-processed header files only)? In-Reply-To: References: Message-ID: <20080416150159.GC12207@scytale.galois.com> magnus: > Is there such a beast out there? > > If this were a list on some OO language I'd ask for something that created > an AST and then offered an API based around a visitor pattern. > > The pre-processor (platform specific most likely, but could be cpphs of > course) would be run prior to the tool I'm considering writing. After > that I only need access to declarations of C functions and definitions of > types (structs, enums, other typedefs). > > I had a quick look at the code in c2hs yesterday, but found it a little > hard to make heads or tails of it without some guidance, so I couldn't > tell whether it would be suitable. Would it? > > Any help or pointers appreciated. I think the main option for parsing C now is the c2hs parser -- there's a summer of code project to wrap it up as a suitable C manipulation, printing and parsing library, so we should see a good standalone solution in a few months. -- Don From martin.sulzmann at gmail.com Wed Apr 16 11:06:07 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Wed Apr 16 11:01:20 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: References: Message-ID: <480615DF.6050807@gmail.com> We're also looking for (practical) examples of "multi-range" functional dependencies class C a b c | c -> a b Notice that there are multiple (two) parameters in the range of the FD. It's tempting to convert the above to class C a b c | c -> a, c -> b but this yields a weaker (in terms of type improvement) system. Thanks, Martin Tom Schrijvers wrote: > Hello, > > I'm looking for practical examples of non-full functional dependencies > and would be grateful if anyone could show me some or point to > applications using them. > > A non-full functional dependency is one involves only part of the > parameters of a type class. E.g. > > class C a b c | a -> b > > has a non-full functional dependency a -> b which does not involve c. > > Thanks, > > Tom > > -- > Tom Schrijvers > > Department of Computer Science > K.U. Leuven > Celestijnenlaan 200A > B-3001 Heverlee > Belgium > > tel: +32 16 327544 > e-mail: tom.schrijvers@cs.kuleuven.be > url: http://www.cs.kuleuven.be/~toms/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ross at soi.city.ac.uk Wed Apr 16 11:14:46 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Apr 16 11:09:59 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: References: Message-ID: <20080416151446.GA3787@soi.city.ac.uk> On Wed, Apr 16, 2008 at 04:30:27PM +0200, Tom Schrijvers wrote: > I'm looking for practical examples of non-full functional dependencies > and would be grateful if anyone could show me some or point to > applications using them. > > A non-full functional dependency is one involves only part of the > parameters of a type class. E.g. > > class C a b c | a -> b > > has a non-full functional dependency a -> b which does not involve c. hackageDB has a substantial sample of code these days, which is handy for questions like this. There are examples of non-full FDs in the following packages: ArrayRef-0.1.2 arrows-0.4 OpenAFP-1.0 parsec-3.0.0 StrategyLib-4.0.0.0 Yampa-0.9.2.1 However for most of these there are indirect dependencies. The only exceptions I can find are those in ArrayRef, parsec and StrategyLib. On Wed, Apr 16, 2008 at 05:06:07PM +0200, Martin Sulzmann wrote: > We're also looking for (practical) examples of "multi-range" functional > dependencies > > class C a b c | c -> a b Look in BerkeleyDB-0.3 CC-delcont-0.2 collections-0.3 HsJudy-0.2 yi-0.3 yi-gtk-0.2 yi-vty-0.2 From bulat.ziganshin at gmail.com Wed Apr 16 11:17:14 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Apr 16 11:15:33 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <480615DF.6050807@gmail.com> References: <480615DF.6050807@gmail.com> Message-ID: <546031584.20080416191714@gmail.com> Hello Martin, Wednesday, April 16, 2008, 7:06:07 PM, you wrote: i'm not 100% sure that you'll find there appropriate examples but i suggest you too look into http://haskell.org/haskellwiki/Library/Streams where i've used very sophisticated (for me) FDs > We're also looking for (practical) examples of "multi-range" functional > dependencies class C a b c | c ->> a b > Notice that there are multiple (two) parameters in the range of the FD. > It's tempting to convert the above to class C a b c | c ->> a, c -> b > but this yields a weaker (in terms of type improvement) system. > Thanks, > Martin > Tom Schrijvers wrote: >> Hello, >> >> I'm looking for practical examples of non-full functional dependencies >> and would be grateful if anyone could show me some or point to >> applications using them. >> >> A non-full functional dependency is one involves only part of the >> parameters of a type class. E.g. >> >> class C a b c | a -> b >> >> has a non-full functional dependency a -> b which does not involve c. >> >> Thanks, >> >> Tom >> >> -- >> Tom Schrijvers >> >> Department of Computer Science >> K.U. Leuven >> Celestijnenlaan 200A >> B-3001 Heverlee >> Belgium >> >> tel: +32 16 327544 >> e-mail: tom.schrijvers@cs.kuleuven.be >> url: http://www.cs.kuleuven.be/~toms/ >> _______________________________________________ >> 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 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jgoerzen at complete.org Wed Apr 16 11:16:26 2008 From: jgoerzen at complete.org (John Goerzen) Date: Wed Apr 16 12:03:32 2008 Subject: [Haskell-cafe] Re: I/O system brokenness with named pipes References: Message-ID: On 2008-04-15, Joe Buehler wrote: > John Goerzen wrote: > >> So I have a need to write data to a POSIX named pipe (aka FIFO). Long >> story involving a command that doesn't have an option to read data >> from stdin, but can from a named pipe. > > How about /dev/stdin? Only works on Linux. -- John From magnus at therning.org Wed Apr 16 12:42:22 2008 From: magnus at therning.org (Magnus Therning) Date: Wed Apr 16 12:37:40 2008 Subject: [Haskell-cafe] Module for parsing C (pre-processed header files only)? In-Reply-To: <20080416150159.GC12207@scytale.galois.com> References: <20080416150159.GC12207@scytale.galois.com> Message-ID: On Wed, Apr 16, 2008 at 4:01 PM, Don Stewart wrote: > magnus: > > Is there such a beast out there? > > > > If this were a list on some OO language I'd ask for something that > created > > an AST and then offered an API based around a visitor pattern. > > > > The pre-processor (platform specific most likely, but could be cpphs > of > > course) would be run prior to the tool I'm considering writing. > After > > that I only need access to declarations of C functions and > definitions of > > types (structs, enums, other typedefs). > > > > I had a quick look at the code in c2hs yesterday, but found it a > little > > hard to make heads or tails of it without some guidance, so I > couldn't > > tell whether it would be suitable. Would it? > > > > Any help or pointers appreciated. > > I think the main option for parsing C now is the c2hs parser -- there's > a summer of code project to wrap it up as a suitable C manipulation, > printing and parsing library, so we should see a good standalone > solution in a few months. Will it be delivered with good documentation? ;-) This is /very/ interesting for me and my job (what I'm talking about above is not for work though). I would love to see something that would allow me to spend more time using Haskell while being paid for it :-) /M -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080416/f310ace6/attachment.htm From dons at galois.com Wed Apr 16 12:44:54 2008 From: dons at galois.com (Don Stewart) Date: Wed Apr 16 12:40:09 2008 Subject: [Haskell-cafe] Module for parsing C (pre-processed header files only)? In-Reply-To: References: <20080416150159.GC12207@scytale.galois.com> Message-ID: <20080416164454.GA4395@scytale.galois.com> magnus: > On Wed, Apr 16, 2008 at 4:01 PM, Don Stewart <[1]dons@galois.com> wrote: > > magnus: > > Is there such a beast out there? > > > > If this were a list on some OO language I'd ask for something that > created > > an AST and then offered an API based around a visitor pattern. > > > > The pre-processor (platform specific most likely, but could be > cpphs of > > course) would be run prior to the tool I'm considering writing. > After > > that I only need access to declarations of C functions and > definitions of > > types (structs, enums, other typedefs). > > > > I had a quick look at the code in c2hs yesterday, but found it a > little > > hard to make heads or tails of it without some guidance, so I > couldn't > > tell whether it would be suitable. Would it? > > > > Any help or pointers appreciated. > > I think the main option for parsing C now is the c2hs parser -- there's > a summer of code project to wrap it up as a suitable C manipulation, > printing and parsing library, so we should see a good standalone > solution in a few months. > > Will it be delivered with good documentation? ;-) > > This is /very/ interesting for me and my job (what I'm talking about above > is not for work though). I would love to see something that would allow > me to spend more time using Haskell while being paid for it :-) > Exactly, its potentially a new leading project for Haskell, if we do a good job here. An exciting niche waiting to be exploited. -- Don From allbery at ece.cmu.edu Wed Apr 16 13:20:37 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Apr 16 13:15:49 2008 Subject: [Haskell-cafe] Re: I/O system brokenness with named pipes In-Reply-To: References: Message-ID: <545B47E3-5E6A-48F4-8986-2E8593FDA737@ece.cmu.edu> On Apr 16, 2008, at 11:16 , John Goerzen wrote: > On 2008-04-15, Joe Buehler wrote: >> John Goerzen wrote: >> >>> So I have a need to write data to a POSIX named pipe (aka FIFO). >>> Long >>> story involving a command that doesn't have an option to read data >>> from stdin, but can from a named pipe. >> >> How about /dev/stdin? > > Only works on Linux. Hm. I see it even on our ancient Solaris 8 boxes. And I'm quite sure the *BSDs support it as well. Just how ancient / weird is this "POSIX" platform of yours? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From miguelimo38 at yandex.ru Wed Apr 16 13:23:15 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Wed Apr 16 13:18:46 2008 Subject: [Haskell-cafe] Re: I/O system brokenness with named pipes In-Reply-To: References: Message-ID: You are insulting other Unixes. It works on Mac OS X, for example. On 16 Apr 2008, at 19:16, John Goerzen wrote: > On 2008-04-15, Joe Buehler wrote: >> John Goerzen wrote: >> >>> So I have a need to write data to a POSIX named pipe (aka FIFO). >>> Long >>> story involving a command that doesn't have an option to read data >>> from stdin, but can from a named pipe. >> >> How about /dev/stdin? > > Only works on Linux. > > -- John > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From allbery at ece.cmu.edu Wed Apr 16 13:25:25 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Apr 16 13:20:36 2008 Subject: [Haskell-cafe] Re: I/O system brokenness with named pipes In-Reply-To: References: Message-ID: <58BEEBBE-BA41-40E0-9E36-B35223984EA8@ece.cmu.edu> On Apr 16, 2008, at 13:23 , Miguel Mitrofanov wrote: > You are insulting other Unixes. It works on Mac OS X, for example. Not just that, but IIRC Linux was late to the party: Solaris got / dev/fd/ and /dev/stdin before Linux got /proc/$$/fd/ (which gets symlinked to /dev/fd/). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From dbueno at gmail.com Wed Apr 16 13:28:27 2008 From: dbueno at gmail.com (Denis Bueno) Date: Wed Apr 16 13:23:37 2008 Subject: [Haskell-cafe] ANN: datapacker 1.0.0 In-Reply-To: References: Message-ID: <6dbd4d000804161028l3a395d90vb2f3e2d86ea25c59@mail.gmail.com> On Wed, Apr 16, 2008 at 12:02 AM, John Goerzen wrote: > Hi, > > I'm pleased to announce the first release of datapacker. Your datapacker depends on MissingH 1.0.1 which, although on hackage, fails to build with GHC 6.8.2. (It may build with earlier versions, but I haven't tried.) It says: [41 of 48] Compiling System.IO.Binary ( src/System/IO/Binary.hs, dist/build/System/IO/Binary.o ) src/System/IO/Binary.hs:115:12: Illegal signature in pattern: ForeignPtr Word8 Use -XPatternSignatures to permit it src/System/IO/Binary.hs:266:8: Illegal signature in pattern: ForeignPtr CChar Use -XPatternSignatures to permit it Hackage confirms this build failure: http://hackage.haskell.org/packages/archive/MissingH/1.0.1/logs/failure/ghc-6.8 -- Denis From iavor.diatchki at gmail.com Wed Apr 16 13:29:59 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Apr 16 13:25:11 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <480615DF.6050807@gmail.com> References: <480615DF.6050807@gmail.com> Message-ID: <5ab17e790804161029q54ea6bb5yaeca44cf970359e0@mail.gmail.com> Hello, On Wed, Apr 16, 2008 at 8:06 AM, Martin Sulzmann wrote: > We're also looking for (practical) examples of "multi-range" functional > dependencies > > class C a b c | c -> a b > > Notice that there are multiple (two) parameters in the range of the FD. > > It's tempting to convert the above to > > class C a b c | c -> a, c -> b > > but this yields a weaker (in terms of type improvement) system. Could you elaborate on this? I think that a system that distinguishes these two would be very confusing. If you think of the FDs as logical statements about what is known of type variables, then the FDs on the two classes correspond to equivalent logical statements, so I am not sure why would we distinguish them for improvement purposes. Also, it seems fairly easy to convert between the two forms purely based on syntax, so if the one somehow results in better improvements, why would we ever use the other one? As for examples of interesting uses of functional dependencies, perhaps the literature on relational databases would provide some? -Iavor From donn at avvanta.com Wed Apr 16 13:50:20 2008 From: donn at avvanta.com (Donn Cave) Date: Wed Apr 16 13:45:35 2008 Subject: [Haskell-cafe] Re: I/O system brokenness with named pipes In-Reply-To: <58BEEBBE-BA41-40E0-9E36-B35223984EA8@ece.cmu.edu> References: <58BEEBBE-BA41-40E0-9E36-B35223984EA8@ece.cmu.edu> Message-ID: On Apr 16, 2008, at 10:25 AM, Brandon S. Allbery KF8NH wrote: > > On Apr 16, 2008, at 13:23 , Miguel Mitrofanov wrote: >> You are insulting other Unixes. It works on Mac OS X, for example. > > Not just that, but IIRC Linux was late to the party: Solaris got / > dev/fd/ and /dev/stdin before Linux got /proc/$$/fd/ (which gets > symlinked to /dev/fd/). Yeah, among people who don't know much about UNIX, Linux gets a lot of credit for things it borrowed. But /dev/stdin isn't a standard feature of UNIX, if you count AIX for example as a UNIX platform. And apparently you can compile Haskell programs on AIX - thanks to the original poster in this thread's work with GHC - so there you go. Donn From westondan at imageworks.com Wed Apr 16 14:05:24 2008 From: westondan at imageworks.com (Dan Weston) Date: Wed Apr 16 14:00:35 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <5ab17e790804161029q54ea6bb5yaeca44cf970359e0@mail.gmail.com> References: <480615DF.6050807@gmail.com> <5ab17e790804161029q54ea6bb5yaeca44cf970359e0@mail.gmail.com> Message-ID: <48063FE4.1010408@imageworks.com> Iavor Diatchki wrote: > Hello, > > On Wed, Apr 16, 2008 at 8:06 AM, Martin Sulzmann > wrote: >> We're also looking for (practical) examples of "multi-range" functional >> dependencies >> >> class C a b c | c -> a b >> >> Notice that there are multiple (two) parameters in the range of the FD. >> >> It's tempting to convert the above to >> >> class C a b c | c -> a, c -> b >> >> but this yields a weaker (in terms of type improvement) system. > > Could you elaborate on this? I think that a system that distinguishes > these two would be very confusing. If you think of the FDs as > logical statements about what is known of type variables, then the FDs > on the two classes correspond to equivalent logical statements, so I > am not sure why would we distinguish them for improvement purposes. > Also, it seems fairly easy to convert between the two forms purely > based on syntax, so if the one somehow results in better improvements, > why would we ever use the other one? The two are not isomorphic. The first one c -> a b contains an explicit order (class parameter order is significant), whereas the second does not (the FDs form a set). I think the isomorphic functional dependency in the first case would be the set of all FDs under permutation of class parameters, in this case: c -> a b, c -> b a > As for examples of interesting uses of functional dependencies, > perhaps the literature on relational databases would provide some? Elaborating on the relational connection, it seems at first blush that class C a b c | a -> b is not ideally normalized and might presumably be profitably broken up into class A a b | a -> b class A a b => B a b c From marco-oweber at gmx.de Wed Apr 16 14:08:08 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Wed Apr 16 14:03:21 2008 Subject: [Haskell-cafe] ANN: datapacker 1.0.0 In-Reply-To: <6dbd4d000804161028l3a395d90vb2f3e2d86ea25c59@mail.gmail.com> References: <6dbd4d000804161028l3a395d90vb2f3e2d86ea25c59@mail.gmail.com> Message-ID: <20080416180808.GA20782@gmx.de> > src/System/IO/Binary.hs:266:8: > Illegal signature in pattern: ForeignPtr CChar > Use -XPatternSignatures to permit it > > Hackage confirms this build failure: > http://hackage.haskell.org/packages/archive/MissingH/1.0.1/logs/failure/ghc-6.8 Should not be hard to fix :) just add it to the Cabal file as extension :) extensions: PatternSignatures Don't worry, be happy *g* Marc From jgoerzen at complete.org Wed Apr 16 14:10:52 2008 From: jgoerzen at complete.org (John Goerzen) Date: Wed Apr 16 14:06:06 2008 Subject: [Haskell-cafe] Re: I/O system brokenness with named pipes In-Reply-To: <545B47E3-5E6A-48F4-8986-2E8593FDA737@ece.cmu.edu> References: <545B47E3-5E6A-48F4-8986-2E8593FDA737@ece.cmu.edu> Message-ID: <200804161310.53042.jgoerzen@complete.org> On Wed April 16 2008 12:20:37 pm Brandon S. Allbery KF8NH wrote: > On Apr 16, 2008, at 11:16 , John Goerzen wrote: > > On 2008-04-15, Joe Buehler wrote: > >> John Goerzen wrote: > >>> So I have a need to write data to a POSIX named pipe (aka FIFO). > >>> Long > >>> story involving a command that doesn't have an option to read data > >>> from stdin, but can from a named pipe. > >> > >> How about /dev/stdin? > > > > Only works on Linux. > > Hm. I see it even on our ancient Solaris 8 boxes. And I'm quite > sure the *BSDs support it as well. Just how ancient / weird is this > "POSIX" platform of yours? OK, so I shouldn't have said "it only works on Linux", but as far as I can tell, it isn't standard (defined by POSIX). I don't presently have easy access to non-Linux machines, but I do want to be as portable as possible. -- John From jgoerzen at complete.org Wed Apr 16 14:14:49 2008 From: jgoerzen at complete.org (John Goerzen) Date: Wed Apr 16 14:10:02 2008 Subject: [Haskell-cafe] ANN: datapacker 1.0.0 In-Reply-To: <20080416180808.GA20782@gmx.de> References: <6dbd4d000804161028l3a395d90vb2f3e2d86ea25c59@mail.gmail.com> <20080416180808.GA20782@gmx.de> Message-ID: <200804161314.49660.jgoerzen@complete.org> On Wed April 16 2008 1:08:08 pm Marc Weber wrote: > > src/System/IO/Binary.hs:266:8: > > Illegal signature in pattern: ForeignPtr CChar > > Use -XPatternSignatures to permit it > > > > Hackage confirms this build failure: > > http://hackage.haskell.org/packages/archive/MissingH/1.0.1/logs/failure/ > >ghc-6.8 > > Should not be hard to fix :) just add it to the Cabal file as extension :) > extensions: > PatternSignatures > > Don't worry, be happy *g* Drat. my workaround to the hackage issue I described in another thread was faulty. I'm uploading a new version now. -- John From bertram.felgenhauer at googlemail.com Wed Apr 16 14:33:56 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Wed Apr 16 14:29:13 2008 Subject: [Haskell-cafe] Wrong Answer Computing Graph Dominators In-Reply-To: <6dbd4d000804151759r2ca72957hae8cd60c91404e60@mail.gmail.com> References: <6dbd4d000804151759r2ca72957hae8cd60c91404e60@mail.gmail.com> Message-ID: <20080416183356.GA4362@zombie.inf.tu-dresden.de> Denis Bueno wrote: > I'm using the Data.Graph.Inductive.Query.Dominators library > (http://haskell.org/ghc/docs/latest/html/libraries/fgl/Data-Graph-Inductive-Query-Dominators.html) > with GHC 6.8.2. > The library is a bit spare on comments, so I may or may not be using > it correctly. > [snip] > But what I am getting is: > --> uips = [-9,20] > --> domConfl = [2,-9,20] > --> domAssigned = [-2,-9,-12,20] > --> lastd = 20 > > But -9 is not a dominator for 2, since 20,-7,8,6,2 is a path from 20 > to 2 that does not touch 9. -9 is also not a dominator for -2, since > 20,-7,8,6,-2 is a path from 20 to -2 not touching 9. > > Am I missing something? No. Data.Graph.Inductive.Query.Dominators is just buggy. 1) domr is meant to find a fixed point of builddoms by iteratively applying builddoms, but in fact it calls builddoms at most twice. 2) the code doesn't handle nodes with no predecessors correctly. Here's a quick fix: diff -rN -u old-fgl/Data/Graph/Inductive/Query/Dominators.hs new-fgl/Data/Graph/Inductive/Query/Dominators.hs --- old-fgl/Data/Graph/Inductive/Query/Dominators.hs 2008-04-16 20:13:35.000000000 +0200 +++ new-fgl/Data/Graph/Inductive/Query/Dominators.hs 2008-04-16 20:13:35.000000000 +0200 @@ -18,13 +18,13 @@ builddoms :: DomSets -> [Node] -> DomSets builddoms ds [] = ds builddoms ds (v:vs) = builddoms ((fs++[(n,p,sort(n:idv))])++(tail rs)) vs - where idv = intersection (getdomv p ds) - (n,p,_) = head rs + where idv = intersection ((q \\ [n]):getdomv p ds) + (n,p,q) = head rs (fs,rs) = span (\(x,_,_)->x/=v) ds domr :: DomSets -> [Node] -> DomSets domr ds vs|xs == ds = ds - |otherwise = builddoms xs vs + |otherwise = domr xs vs where xs = (builddoms ds vs) {-| Bertram From vigalchin at gmail.com Wed Apr 16 14:40:17 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed Apr 16 14:35:57 2008 Subject: [Haskell-cafe] Hoogle Message-ID: <5ae4f2ba0804161140k25b17cfaue7378471c15eee32@mail.gmail.com> Hello, I tried d to use Hoogle to find openFd's signature and more importantly FileMode. I found FileMode which is a type synonym with CMode. I don't understand what are the "values" for FileMode (so I can call openFd). ?? Thanks, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080416/ad52d5bf/attachment.htm From aslatter at gmail.com Wed Apr 16 14:46:45 2008 From: aslatter at gmail.com (Antoine Latter) Date: Wed Apr 16 14:41:57 2008 Subject: [Haskell-cafe] Hoogle In-Reply-To: <5ae4f2ba0804161140k25b17cfaue7378471c15eee32@mail.gmail.com> References: <5ae4f2ba0804161140k25b17cfaue7378471c15eee32@mail.gmail.com> Message-ID: <694519c50804161146x4b9a14e8p834f5cfbd2920b59@mail.gmail.com> 2008/4/16 Galchin, Vasili : > Hello, > > I tried d to use Hoogle to find openFd's signature and more > importantly FileMode. I found FileMode which is a type synonym with CMode. > I don't understand what are the "values" for FileMode (so I can call > openFd). ?? Values of type FileMode are defined in System.Posix.Files See http://haskell.org/ghc/docs/latest/html/libraries/unix/System-Posix-Files.html#1 for the defintions. Does that help? -Antoine From ndmitchell at gmail.com Wed Apr 16 14:47:46 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Apr 16 14:42:57 2008 Subject: [Haskell-cafe] Hoogle In-Reply-To: <5ae4f2ba0804161140k25b17cfaue7378471c15eee32@mail.gmail.com> References: <5ae4f2ba0804161140k25b17cfaue7378471c15eee32@mail.gmail.com> Message-ID: <404396ef0804161147p56d6e11fh544e1553173c862c@mail.gmail.com> Hi > I tried d to use Hoogle to find openFd's signature and more > importantly FileMode. Hoogle does not search the Posix library, because in general people should steer clear of it - otherwise I won't be able to run your programs :-) - The next version of Hoogle will permit selecting to search the Posix library, if you so choose. > I found FileMode which is a type synonym with CMode. > I don't understand what are the "values" for FileMode (so I can call > openFd). ?? Clearly, the documentation is rather weak. It comes from the Posix "open" function, which is document all over the place, and you can see the code here: http://darcs.haskell.org/ghc-6.6/packages/unix/System/Posix/IO.hsc After figuring out what you want, I recommend submitting a patch for documentation. Additionally, if what you want can be done in a cross platform way, but lacks the appropriate abstraction layer, I would add a request for this to be fixed. Thanks Neil From allbery at ece.cmu.edu Wed Apr 16 15:27:52 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Apr 16 15:23:04 2008 Subject: [Haskell-cafe] ANN: datapacker 1.0.0 In-Reply-To: <20080416180808.GA20782@gmx.de> References: <6dbd4d000804161028l3a395d90vb2f3e2d86ea25c59@mail.gmail.com> <20080416180808.GA20782@gmx.de> Message-ID: <9EF76937-8C0B-430C-B436-A232B0F01544@ece.cmu.edu> On Apr 16, 2008, at 14:08 , Marc Weber wrote: >> src/System/IO/Binary.hs:266:8: >> Illegal signature in pattern: ForeignPtr CChar >> Use -XPatternSignatures to permit it >> >> Hackage confirms this build failure: >> http://hackage.haskell.org/packages/archive/MissingH/1.0.1/logs/ >> failure/ghc-6.8 > > Should not be hard to fix :) just add it to the Cabal file as > extension :) > extensions: > PatternSignatures You might want to see previous messages today, about how hackage is forcing MissingH to be either 6.6 or 6.8 compatible but not both. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From valgarv at gmx.net Wed Apr 16 15:57:04 2008 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Wed Apr 16 15:52:57 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <48036BD6.5040308@daimi.au.dk> References: <385428.92143.qm@web30206.mail.mud.yahoo.com> <48036BD6.5040308@daimi.au.dk> Message-ID: <200804162257.05243.valgarv@gmx.net> > That's exactly what I was thinking about, but your hanoi_shower only > handles list of exactly one action, but you have to handle longer lists, > too. This could be done with explicit recursion This seems to be a common pitfall for Haskell newcomers: mistaking a single-element list pattern (such as [x]) for a pattern that iterates over every element in the list. I can't seem to find a page with a list of common pitfalls and mistakes... is there such a thing? -- Ariel J. Birnbaum From graham.fawcett at gmail.com Wed Apr 16 16:15:23 2008 From: graham.fawcett at gmail.com (Graham Fawcett) Date: Wed Apr 16 16:10:40 2008 Subject: [Haskell-cafe] Shim: finding modules Message-ID: Hi folks, I'm a newbie, so please forgive any terminological mistakes. I've been using Shim in Emacs with great success, but there's one issue I've encountered, and I don't know if it's configuration problem or something fundamental. Consider a module 'App' and submodules 'App.Front' and 'App.Back'. When editing code in App that depends on the submodules, Shim works well at resolving the location of the submodules, and validates my code. But when editing App.Front, which depends on App.Back, Shim fails to validate -- my working directory is App.Front, and Shim doesn't seem able to find the location of App.Back. I'd like to be able to tell Shim that 'App' is the root of my project, and to locate modules from that root. Is this possible? On a related note, it seems that Shim is moribund (though others have forked it, mostly for Vim support?). Given its utility, I'm surprised by this. Do you have other support tools that serve a similar role? (I know of haskell-mode, but the GHC API integration seems to be the feature that sets Shim apart.) Thanks, Graham From vigalchin at gmail.com Wed Apr 16 16:54:45 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed Apr 16 16:50:08 2008 Subject: [Haskell-cafe] Hoogle In-Reply-To: <694519c50804161146x4b9a14e8p834f5cfbd2920b59@mail.gmail.com> References: <5ae4f2ba0804161140k25b17cfaue7378471c15eee32@mail.gmail.com> <694519c50804161146x4b9a14e8p834f5cfbd2920b59@mail.gmail.com> Message-ID: <5ae4f2ba0804161354l6ee9c080l1b26f94831523489@mail.gmail.com> hi Antoine, I already found this link. Thanks in any case. I want to O_CREATE a file, i.e. do a openFd creating a new file. O_CREATE should be the FileMode, but I don't see in the link below. Thanks, Vasili On Wed, Apr 16, 2008 at 1:46 PM, Antoine Latter wrote: > 2008/4/16 Galchin, Vasili : > > Hello, > > > > I tried d to use Hoogle to find openFd's signature and more > > importantly FileMode. I found FileMode which is a type synonym with > CMode. > > I don't understand what are the "values" for FileMode (so I can call > > openFd). ?? > > Values of type FileMode are defined in System.Posix.Files > > See > http://haskell.org/ghc/docs/latest/html/libraries/unix/System-Posix-Files.html#1 > for the defintions. > > Does that help? > > -Antoine > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080416/cc497cac/attachment.htm From ndmitchell at gmail.com Wed Apr 16 17:08:43 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Apr 16 17:03:53 2008 Subject: [Haskell-cafe] Hoogle In-Reply-To: <5ae4f2ba0804161354l6ee9c080l1b26f94831523489@mail.gmail.com> References: <5ae4f2ba0804161140k25b17cfaue7378471c15eee32@mail.gmail.com> <694519c50804161146x4b9a14e8p834f5cfbd2920b59@mail.gmail.com> <5ae4f2ba0804161354l6ee9c080l1b26f94831523489@mail.gmail.com> Message-ID: <404396ef0804161408v500c614fw2565c6126ddee984@mail.gmail.com> Hi Vasili, > I already found this link. Thanks in any case. I want to O_CREATE a file, > i.e. do a openFd creating a new file. O_CREATE should be the FileMode, but I > don't see in the link below. What do you want to do beyond writeFile/openFile/readFile? If you can, its better to use the standard IO openFile. Thanks Neil From jgoerzen at complete.org Wed Apr 16 17:30:57 2008 From: jgoerzen at complete.org (John Goerzen) Date: Wed Apr 16 17:26:09 2008 Subject: [Haskell-cafe] Hoogle In-Reply-To: <5ae4f2ba0804161354l6ee9c080l1b26f94831523489@mail.gmail.com> References: <5ae4f2ba0804161140k25b17cfaue7378471c15eee32@mail.gmail.com> <694519c50804161146x4b9a14e8p834f5cfbd2920b59@mail.gmail.com> <5ae4f2ba0804161354l6ee9c080l1b26f94831523489@mail.gmail.com> Message-ID: <200804161630.57911.jgoerzen@complete.org> On Wed April 16 2008 3:54:45 pm Galchin, Vasili wrote: > hi Antoine, > > I already found this link. Thanks in any case. I want to O_CREATE a > file, i.e. do a openFd creating a new file. O_CREATE should be the > FileMode, but I don't see in the link below. Indeed. It seems there is no way to pass O_CREAT to openFile. there is createFile, but that's really a different call. Sigh. From graham.fawcett at gmail.com Wed Apr 16 18:58:43 2008 From: graham.fawcett at gmail.com (Graham Fawcett) Date: Wed Apr 16 18:53:57 2008 Subject: [Haskell-cafe] Hoogle In-Reply-To: <200804161630.57911.jgoerzen@complete.org> References: <5ae4f2ba0804161140k25b17cfaue7378471c15eee32@mail.gmail.com> <694519c50804161146x4b9a14e8p834f5cfbd2920b59@mail.gmail.com> <5ae4f2ba0804161354l6ee9c080l1b26f94831523489@mail.gmail.com> <200804161630.57911.jgoerzen@complete.org> Message-ID: On Wed, Apr 16, 2008 at 5:30 PM, John Goerzen wrote: > On Wed April 16 2008 3:54:45 pm Galchin, Vasili wrote: > > hi Antoine, > > > > I already found this link. Thanks in any case. I want to O_CREATE a > > file, i.e. do a openFd creating a new file. O_CREATE should be the > > FileMode, but I don't see in the link below. > > Indeed. It seems there is no way to pass O_CREAT to openFile. there is > createFile, but that's really a different call. Sigh. In openFile, in GHC 6.8.2 at least, O_CREAT is passed for WriteMode and ReadWriteMode -- see output_flags in GHC/Handle.hs. Graham From ryani.spam at gmail.com Wed Apr 16 19:00:36 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Apr 16 18:55:47 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <48063FE4.1010408@imageworks.com> References: <480615DF.6050807@gmail.com> <5ab17e790804161029q54ea6bb5yaeca44cf970359e0@mail.gmail.com> <48063FE4.1010408@imageworks.com> Message-ID: <2f9b2d30804161600l52ee3844xe6746f88e7d9d8a4@mail.gmail.com> I'm still confused about this point: On 4/16/08, Dan Weston wrote: > > > class C a b c | c -> a b > > > > > > Notice that there are multiple (two) parameters in the range of the FD. > > > > > > It's tempting to convert the above to > > > > > > class C a b c | c -> a, c -> b > > > > > > but this yields a weaker (in terms of type improvement) system. In both cases the statement is that given a type x, the instance C x y z for some y,z and the constraint C x a b, we unambiguously have a ~ y, b ~ z (where ~ is type equality) How does the order in (c -> a b) matter? -- ryan From simonmarhaskell at gmail.com Wed Apr 16 19:02:59 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Apr 16 18:58:14 2008 Subject: [Haskell-cafe] Re: I/O system brokenness with named pipes In-Reply-To: <0EAFCC1E-AD81-4156-9CB2-12B952F5BD7A@avvanta.com> References: <20080411103353.GE15362@scytale.galois.com> <200804110815.38285.jgoerzen@complete.org> <0EAFCC1E-AD81-4156-9CB2-12B952F5BD7A@avvanta.com> Message-ID: <480685A3.5070008@gmail.com> Donn Cave wrote: > I have run into this problem, with Network.Socket (socket). If I > remember right, > ktrace showed me what was happening. This isn't my favorite thing about > Haskell. > Is there even a means provided to set it back to blocking? There isn't a way right now to open a file using a blocking FD, however the IO library does support using blocking FDs (the std handles are left in blocking mode to avoid causing problems with pipes). We could certainly add an interface to let you open files in blocking mode - just submit a feature request via GHC's Trac and we'll try to get around to it (or better still, send us a patch... the code is in GHC.Handle.fdToHandle). Cheers, Simon From allbery at ece.cmu.edu Wed Apr 16 19:16:56 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Apr 16 19:12:09 2008 Subject: [Haskell-cafe] Hoogle In-Reply-To: <200804161630.57911.jgoerzen@complete.org> References: <5ae4f2ba0804161140k25b17cfaue7378471c15eee32@mail.gmail.com> <694519c50804161146x4b9a14e8p834f5cfbd2920b59@mail.gmail.com> <5ae4f2ba0804161354l6ee9c080l1b26f94831523489@mail.gmail.com> <200804161630.57911.jgoerzen@complete.org> Message-ID: <08EB2755-AE6E-40E2-BBAA-CA40FA4CB35E@ece.cmu.edu> On Apr 16, 2008, at 17:30 , John Goerzen wrote: > On Wed April 16 2008 3:54:45 pm Galchin, Vasili wrote: >> I already found this link. Thanks in any case. I want to >> O_CREATE a >> file, i.e. do a openFd creating a new file. O_CREATE should be the >> FileMode, but I don't see in the link below. > > Indeed. It seems there is no way to pass O_CREAT to openFile. > there is > createFile, but that's really a different call. Sigh. Remember, Haskell is functional; treat the function to call as an argument? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From ronwalf at umd.edu Wed Apr 16 19:22:58 2008 From: ronwalf at umd.edu (Ron Alford) Date: Wed Apr 16 19:18:13 2008 Subject: [Haskell-cafe] Mutually recursive types? Message-ID: Here's the setup: I have a series of problems that use various logical connectives. The problem is that they're not all the same. So instead of creating one giant datatype (or duplicating much code), I'd like to assemble them like toy blocks. I've boiled down an example here: data LogicalConnective a = Not a | And [a] | Or [a] data BasicGoal a = Atomic String [Term] | Empty | Logical (LogicalConnective a) deriving (Show, Eq) data PreferenceGoal1 = Basic1 PreferenceGoal1 | Prefer1 PreferenceGoal1 This works OK, but PreferenceGoal1 is a dead end. I can't combine it with other connectives. So I try: data PreferenceGoal2 a = Basic2 (PreferenceGoal2 a) | Prefer2 (PreferenceGoal2 a) And this works fine, but seems impossible to explicitly type (ie, there is nothing to substitute for 'a' in a type declaration). Or am I wrong? Also, it could be that this is just an ugly way to represent things (it does require a huge number of constructors). Any suggestions? -Ron From jgoerzen at complete.org Wed Apr 16 19:29:59 2008 From: jgoerzen at complete.org (John Goerzen) Date: Wed Apr 16 19:25:15 2008 Subject: [Haskell-cafe] Hoogle In-Reply-To: <08EB2755-AE6E-40E2-BBAA-CA40FA4CB35E@ece.cmu.edu> References: <5ae4f2ba0804161140k25b17cfaue7378471c15eee32@mail.gmail.com> <200804161630.57911.jgoerzen@complete.org> <08EB2755-AE6E-40E2-BBAA-CA40FA4CB35E@ece.cmu.edu> Message-ID: <200804161829.59425.jgoerzen@complete.org> On Wednesday 16 April 2008 6:16:56 pm Brandon S. Allbery KF8NH wrote: > On Apr 16, 2008, at 17:30 , John Goerzen wrote: > > On Wed April 16 2008 3:54:45 pm Galchin, Vasili wrote: > >> I already found this link. Thanks in any case. I want to > >> O_CREATE a > >> file, i.e. do a openFd creating a new file. O_CREATE should be the > >> FileMode, but I don't see in the link below. > > > > Indeed. It seems there is no way to pass O_CREAT to openFile. > > there is > > createFile, but that's really a different call. Sigh. > > Remember, Haskell is functional; treat the function to call as an > argument? I don't have access to the GHC source just at the moment, but presumably that is an interface to creat() instead of open(). creat() is documented as: creat() is equivalent to open() with flags equal to O_CREAT|O_WRONLY|O_TRUNC. There could be reasons that you would want to pass, say, O_CREAT|O_RDWR| O_APPEND and omit O_TRUNC. There are also reasons that you might want to pass, say, O_WRONLY|O_APPEND with no O_CREAT. The fact that openFile implies O_CREAT sometimes is a serious misfeature IMHO. That means bug. -- John From westondan at imageworks.com Wed Apr 16 19:58:14 2008 From: westondan at imageworks.com (Dan Weston) Date: Wed Apr 16 19:53:24 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <2f9b2d30804161600l52ee3844xe6746f88e7d9d8a4@mail.gmail.com> References: <480615DF.6050807@gmail.com> <5ab17e790804161029q54ea6bb5yaeca44cf970359e0@mail.gmail.com> <48063FE4.1010408@imageworks.com> <2f9b2d30804161600l52ee3844xe6746f88e7d9d8a4@mail.gmail.com> Message-ID: <48069296.2080500@imageworks.com> I think I was the one confused. I guess I was (falsely) thinking that both C Int Char T C Char Int T could both be instances of class C a b c | c -> a, c -> b but only one could be an instance of C a b c | c -> a b. Sorry for adding noise to the discussion. Ryan Ingram wrote: > I'm still confused about this point: > > On 4/16/08, Dan Weston wrote: >>>> class C a b c | c -> a b >>>> >>>> Notice that there are multiple (two) parameters in the range of the FD. >>>> >>>> It's tempting to convert the above to >>>> >>>> class C a b c | c -> a, c -> b >>>> >>>> but this yields a weaker (in terms of type improvement) system. > > In both cases the statement is that given a type x, the instance C x y > z for some y,z and the constraint C x a b, we unambiguously have a ~ > y, b ~ z (where ~ is type equality) > > How does the order in (c -> a b) matter? > > -- ryan > > From graham.fawcett at gmail.com Wed Apr 16 20:09:13 2008 From: graham.fawcett at gmail.com (Graham Fawcett) Date: Wed Apr 16 20:04:26 2008 Subject: [Haskell-cafe] export question (GHC.Handle) Message-ID: I notice in the source for GHC.Handle that certain functions (e.g. fdToHandle_stat) are in the export list, but are not actually exported (at least, it seems you cannot import them). What mechanism causes these functions to be "hidden", and are they still accessible in some way? Graham From ok at cs.otago.ac.nz Wed Apr 16 20:57:54 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed Apr 16 20:53:30 2008 Subject: [Haskell-cafe] Re: I/O system brokenness with named pipes In-Reply-To: References: <58BEEBBE-BA41-40E0-9E36-B35223984EA8@ece.cmu.edu> Message-ID: <5A4AE41D-E77C-4609-9BBC-4A0A9E2B8235@cs.otago.ac.nz> One question is whether the program is statically or dynamically linked, and if the latter, whether it is possible (as it is in many Unices) to slide your own open(2) definition in between the program and the system library. If it is, it's possible to slide in something that fakes /dev/stdin. From isaacdupree at charter.net Wed Apr 16 21:16:38 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Apr 16 21:11:51 2008 Subject: [Haskell-cafe] C++ interface with Haskell In-Reply-To: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> References: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> Message-ID: <4806A4F6.4090404@charter.net> perhaps haskell: foreign export "foo_func" foo :: Int -> IO Int -- I forget the rest of the syntax here C++: extern "C" { int foo_func(int i); } int some_cplusplus_function() { int bat = 3; int blah = foo_func(bat); return blah; } Is that all you need to do? Miguel Lordelo wrote: > Hi all, > > Well...somehow I'm a beginner in Haskell. But actually my interest in > Haskell will increase if it is possible to call a haskell function in C++. > Something like GreenCard ( http://www.haskell.org/greencard/ ) simplifying > the task of interfacing Haskell programs to external libraries (usually). > But is there also a task to interface a foreign language with Haskell, but > calling Haskell functions. Or c2hs which is an interface generator that > simplifies the development of Haskell bindings to C libraries. > > I want to know this, because in my company some guys are doing some testing > with Frotran and MatLab and I want to show them the power of haskell and the > software which we are using is implemented in C++ (there is the reason to > make Haskel -> C++). > > I read somewhere that the only way for C++ calling a haskell function is to > create a binding between Haskell and C and from C to C++, but a easy "Hello > World" example was not there. > Unfortunatelly I couldn't found anything usefull, like an complete example, > or how to compile the code from haskell to C to C++. > > Can sombody help me, please :P > > Chears, > Miguel Lordelo. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ryani.spam at gmail.com Wed Apr 16 21:22:28 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Apr 16 21:17:38 2008 Subject: [Haskell-cafe] Mutually recursive types? In-Reply-To: References: Message-ID: <2f9b2d30804161822g172091fcw8446602b07c6e3a9@mail.gmail.com> You probably want to look at this: http://wadler.blogspot.com/2008/02/data-types-la-carte.html which refers to a paper about this exact problem. The main types you want are: newtype Fix a = In { out :: a (Fix a) } data (f :+: g) x = Inl (f x) | Inr (g x) Yes, you end up with a ton of constructors, but you can use typeclass machinery and "smart constructors" to help with this problem; see, for example, http://www.haskell.org/pipermail/haskell-cafe/2008-February/040098.html With (:<:) and inj as defined by that post, you can end up with something like: and :: (t :<: LogicalConnective) => [Fix t] -> Fix t and ps = In (inj (And ps)) empty :: (t :<: BasicGoal) => Fix t empty = In (inj Empty) type Problem1 = Fix (LogicalConnective :+: BasicGoal) test :: Problem1 test = and empty empty -- ryan On 4/16/08, Ron Alford wrote: > Here's the setup: > I have a series of problems that use various logical connectives. The > problem is that they're not all the same. So instead of creating one > giant datatype (or duplicating much code), I'd like to assemble them > like toy blocks. > > I've boiled down an example here: > > data LogicalConnective a = > Not a > | And [a] > | Or [a] > > data BasicGoal a = > Atomic String [Term] > | Empty > | Logical (LogicalConnective a) > deriving (Show, Eq) > > data PreferenceGoal1 = > Basic1 PreferenceGoal1 > | Prefer1 PreferenceGoal1 > > This works OK, but PreferenceGoal1 is a dead end. I can't combine it > with other connectives. So I try: > > data PreferenceGoal2 a = > Basic2 (PreferenceGoal2 a) > | Prefer2 (PreferenceGoal2 a) > > And this works fine, but seems impossible to explicitly type (ie, > there is nothing to substitute for 'a' in a type declaration). Or am > I wrong? > > Also, it could be that this is just an ugly way to represent things > (it does require a huge number of constructors). Any suggestions? > > -Ron > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ryani.spam at gmail.com Wed Apr 16 21:26:27 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Apr 16 21:21:37 2008 Subject: [Haskell-cafe] Mutually recursive types? In-Reply-To: <2f9b2d30804161822g172091fcw8446602b07c6e3a9@mail.gmail.com> References: <2f9b2d30804161822g172091fcw8446602b07c6e3a9@mail.gmail.com> Message-ID: <2f9b2d30804161826v17e9c472p5e131880d20fd535@mail.gmail.com> minor correction: test = and [empty, empty] On 4/16/08, Ryan Ingram wrote: > You probably want to look at this: > http://wadler.blogspot.com/2008/02/data-types-la-carte.html > which refers to a paper about this exact problem. > > The main types you want are: > newtype Fix a = In { out :: a (Fix a) } > data (f :+: g) x = Inl (f x) | Inr (g x) > > Yes, you end up with a ton of constructors, but you can use typeclass > machinery and "smart constructors" to help with this problem; see, for > example, http://www.haskell.org/pipermail/haskell-cafe/2008-February/040098.html > > With (:<:) and inj as defined by that post, you can end up with something like: > > and :: (t :<: LogicalConnective) => [Fix t] -> Fix t > and ps = In (inj (And ps)) > > empty :: (t :<: BasicGoal) => Fix t > empty = In (inj Empty) > > type Problem1 = Fix (LogicalConnective :+: BasicGoal) > > test :: Problem1 > test = and empty empty > > -- ryan > > On 4/16/08, Ron Alford wrote: > > Here's the setup: > > I have a series of problems that use various logical connectives. The > > problem is that they're not all the same. So instead of creating one > > giant datatype (or duplicating much code), I'd like to assemble them > > like toy blocks. > > > > I've boiled down an example here: > > > > data LogicalConnective a = > > Not a > > | And [a] > > | Or [a] > > > > data BasicGoal a = > > Atomic String [Term] > > | Empty > > | Logical (LogicalConnective a) > > deriving (Show, Eq) > > > > data PreferenceGoal1 = > > Basic1 PreferenceGoal1 > > | Prefer1 PreferenceGoal1 > > > > This works OK, but PreferenceGoal1 is a dead end. I can't combine it > > with other connectives. So I try: > > > > data PreferenceGoal2 a = > > Basic2 (PreferenceGoal2 a) > > | Prefer2 (PreferenceGoal2 a) > > > > And this works fine, but seems impossible to explicitly type (ie, > > there is nothing to substitute for 'a' in a type declaration). Or am > > I wrong? > > > > Also, it could be that this is just an ugly way to represent things > > (it does require a huge number of constructors). Any suggestions? > > > > -Ron > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > From dekudekuplex at yahoo.com Wed Apr 16 22:19:41 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Wed Apr 16 22:14:50 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <200804162257.05243.valgarv@gmx.net> Message-ID: <334026.85117.qm@web30201.mail.mud.yahoo.com> Ariel, Check out the following HaskellWiki pages: Common Misunderstandings - HaskellWiki http://www.haskell.org/haskellwiki/Common_Misunderstandings Things to avoid - HaskellWiki http://www.haskell.org/haskellwiki/Things_to_avoid Hope these help.... Benjamin L. Russell --- "Ariel J. Birnbaum" wrote: > > That's exactly what I was thinking about, but your > hanoi_shower only > > handles list of exactly one action, but you have > to handle longer lists, > > too. This could be done with explicit recursion > > This seems to be a common pitfall for Haskell > newcomers: mistaking > a single-element list pattern (such as [x]) for a > pattern that iterates > over every element in the list. > I can't seem to find a page with a list of common > pitfalls and mistakes... > is there such a thing? > > -- > Ariel J. Birnbaum > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dekudekuplex at yahoo.com Wed Apr 16 23:42:06 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Wed Apr 16 23:37:16 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <334026.85117.qm@web30201.mail.mud.yahoo.com> Message-ID: <216212.49076.qm@web30201.mail.mud.yahoo.com> Ariel, In response to your comment, since there was apparently no section devoted to pitfalls of iterating over lists, I have added the section "1.4 Iterating Over a List" in the following HaskellWiki page; viz: Common Misunderstandings - HaskellWiki http://www.haskell.org/haskellwiki/Common_Misunderstandings#Iterating_Over_a_List Hope this helps.... Benjamin L. Russell --- "Benjamin L. Russell" wrote: > Ariel, > > Check out the following HaskellWiki pages: > > Common Misunderstandings - HaskellWiki > http://www.haskell.org/haskellwiki/Common_Misunderstandings > > Things to avoid - HaskellWiki > http://www.haskell.org/haskellwiki/Things_to_avoid > > Hope these help.... > > Benjamin L. Russell > > --- "Ariel J. Birnbaum" wrote: > > > > That's exactly what I was thinking about, but > your > > hanoi_shower only > > > handles list of exactly one action, but you have > > to handle longer lists, > > > too. This could be done with explicit recursion > > > > This seems to be a common pitfall for Haskell > > newcomers: mistaking > > a single-element list pattern (such as [x]) for a > > pattern that iterates > > over every element in the list. > > I can't seem to find a page with a list of common > > pitfalls and mistakes... > > is there such a thing? > > > > -- > > Ariel J. Birnbaum > > _______________________________________________ > > 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 > From mpj at cs.pdx.edu Wed Apr 16 23:49:10 2008 From: mpj at cs.pdx.edu (Mark P Jones) Date: Wed Apr 16 23:44:30 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <480615DF.6050807@gmail.com> References: <480615DF.6050807@gmail.com> Message-ID: <4806C8B6.6040603@cs.pdx.edu> Martin Sulzmann wrote: > We're also looking for (practical) examples of "multi-range" functional > dependencies > > class C a b c | c -> a b > > Notice that there are multiple (two) parameters in the range of the FD. > > It's tempting to convert the above to > > class C a b c | c -> a, c -> b > > but this yields a weaker (in terms of type improvement) system. I agree with Iavor. In fact, the two sets of dependencies that you have given here are provably equivalent, so it would be decidedly odd to have a "type improvement" system that distinguishes between them. While you're looking for unusual examples of fundeps, you might also want to consider things like: class C a b c | a -> b, b -> c Note that this is subtly different from a -> b c because {a -> b, b -> c} |= {a -> b c} while the reverse does not hold. Instead of type classes, I'll give you some more down-to-earth examples of relations that satisfy these dependencies: {Paper, Conference, Year} {Professor, University, Country} {Person, FavoriteFood, FoodGroup} ... For further insight, you might want to take a look at the theory of relational databases to see how functional dependencies are used there. In that context, some sets of dependencies (such as {a -> b, b -> c}) can be interpreted as indicators of bad design. This, in turn, might give you some ideas about the kinds of dependencies you can expect to encounter in well-designed Haskell code. (Of course, you might still find examples in other Haskell code of dependencies that would make a database person wince :-) All the best, Mark From dry.green.tea at gmail.com Thu Apr 17 01:21:16 2008 From: dry.green.tea at gmail.com (Alexis Hazell) Date: Thu Apr 17 01:16:39 2008 Subject: [Haskell-cafe] Intro to functional dependencies in Haskell? Message-ID: <20080417052116.GO9745@mischief.78net> Hi all, i'm having some trouble 'getting' functional dependencies in the Haskell context (although my understanding of them in the context of relational database theory isn't that great either). Could someone please point me to an introduction / tutorial in this regard? Thanks! Alexis. From blancolioni at gmail.com Thu Apr 17 01:34:00 2008 From: blancolioni at gmail.com (Fraser Wilson) Date: Thu Apr 17 01:29:11 2008 Subject: [Haskell-cafe] export question (GHC.Handle) In-Reply-To: References: Message-ID: On Thu, Apr 17, 2008 at 2:09 AM, Graham Fawcett wrote: > I notice in the source for GHC.Handle that certain functions (e.g. > fdToHandle_stat) are in the export list, but are not actually exported > (at least, it seems you cannot import them). What mechanism causes > these functions to be "hidden", and are they still accessible in some > way? Good question. I often need to export a name to other modules within the hierarchy, but without making them visible outside it. I've "solved" this problem by giving them funky names and adding a comment, but is there a more structured way to do this? A quick google hasn't found one yet. cheers, Fraser. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080417/61e82d01/attachment.htm From martin.sulzmann at gmail.com Thu Apr 17 02:06:18 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Thu Apr 17 02:01:30 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <4806C8B6.6040603@cs.pdx.edu> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> Message-ID: <4806E8DA.9070503@gmail.com> Mark P Jones wrote: > Martin Sulzmann wrote: >> We're also looking for (practical) examples of "multi-range" >> functional dependencies >> >> class C a b c | c -> a b >> >> Notice that there are multiple (two) parameters in the range of the FD. >> >> It's tempting to convert the above to >> >> class C a b c | c -> a, c -> b >> >> but this yields a weaker (in terms of type improvement) system. > > I agree with Iavor. > > In fact, the two sets of dependencies that you have given here > are provably equivalent, so it would be decidedly odd to have > a "type improvement" system that distinguishes between them. > Consider class C a b c | a -> b, a -> c instance C a b b => C [a] [b] [b] Suppose we encounter the constraint C [x] y z What results can we expect from type improvement? 1) Single-range non-full FDs in GHC following the FD-CHR formulation: The first FD C a b c | a -> b in combination with the instance head C [a] [b] [b] will yield C [x] y z improved by y = [b1] for some b1 A similar reasoning yields C [x] y z improved by z = [b2] for some b2 So, overall we get C [x] y z improved by y= [b1] and z = [b2] Unfortunately, we couldn't establish that b1 and b2 are equal. Hence, we can *not* apply the instance. 2) Alternative design: We could now argue that the improvement implied by the FD is only applicable if we are in the "right" context. That is, C [x] y z doesn't yield any improvement because the context y is still underspecified (doesn't match the instance). In case of C [x] [y] z we get z = [y] (and C [x] z [y] yields z = [y]) 3) Multi-range FDs Consider class C a b c | a -> b c instance C a b b => C [a] [b] [b] This time it's straightforward. C [x] y z yields the improvement y = [b] and z = [b] which then allows us to apply the instance. 4) Summary. With multi-range FDs we can derive "more" improvement. C [x] y z yields y = [b] and z = [b] Based on the FD-CHR formulation, for the single-range FD case we get C [x] y z yields y = [b1] and z = [b2] which is clearly weaker. The alternative design is even weaker, from C [x] y z we can derive any improvement. So, I conclude that in the Haskell type improvement context there's clearly a difference among single-range and multi-range FDs. Of course, we could define multi-range FDs in terms of single-range FDs which then trivially solves the "equivalence" problem (but some user may be disappointed that their multi-range FDs yield weaker improvement). Thanks for your pointers below but I believe that FDs in the Haskell context can be quite different from FDs in the database context. - Martin > While you're looking for unusual examples of fundeps, you > might also want to consider things like: > > class C a b c | a -> b, b -> c > > Note that this is subtly different from a -> b c because > > {a -> b, b -> c} |= {a -> b c} > > while the reverse does not hold. Instead of type classes, > I'll give you some more down-to-earth examples of relations > that satisfy these dependencies: > > {Paper, Conference, Year} > {Professor, University, Country} > {Person, FavoriteFood, FoodGroup} > ... > > For further insight, you might want to take a look at the theory > of relational databases to see how functional dependencies are > used there. In that context, some sets of dependencies (such > as {a -> b, b -> c}) can be interpreted as indicators of bad > design. This, in turn, might give you some ideas about the kinds > of dependencies you can expect to encounter in well-designed > Haskell code. (Of course, you might still find examples in other > Haskell code of dependencies that would make a database person > wince :-) > From bulat.ziganshin at gmail.com Thu Apr 17 03:38:13 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Apr 17 03:37:59 2008 Subject: [Haskell-cafe] Intro to functional dependencies in Haskell? In-Reply-To: <20080417052116.GO9745@mischief.78net> References: <20080417052116.GO9745@mischief.78net> Message-ID: <93327320.20080417113813@gmail.com> Hello Alexis, Thursday, April 17, 2008, 9:21:16 AM, you wrote: > i'm having some trouble 'getting' functional dependencies in the Haskell ghc 6.8 manual contains good introduction into FDs -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ganesh.sittampalam at credit-suisse.com Thu Apr 17 04:01:22 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Apr 17 04:00:08 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <4806E8DA.9070503@gmail.com> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> Message-ID: <78A3C5650E28124399107F21A1FA41945B32FC@ELON17P32002A.csfb.cs-group.com> Martin Sulzmann wrote: > Mark P Jones wrote: > > In fact, the two sets of dependencies that you have given here are > > provably equivalent, so it would be decidedly odd to have a "type > > improvement" system that distinguishes between them. > Based on the FD-CHR formulation, for the single-range FD case we > get [...] which is clearly weaker. > [...] > So, I conclude that in the Haskell type improvement context > there's clearly a difference among single-range and multi-range FDs. This seems like a flaw in FD-CHR, rather than a fundamental difference between the dependencies. > Of course, we could define multi-range FDs in terms of single-range FDs > which then trivially solves the "equivalence" problem (but some user > may be disappointed that their multi-range FDs yield weaker improvement). Why not instead transform single-range FDs into multi-range ones where possible? Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From marco-oweber at gmx.de Thu Apr 17 04:05:47 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu Apr 17 04:00:58 2008 Subject: [Haskell-cafe] Intro to functional dependencies in Haskell? In-Reply-To: <20080417052116.GO9745@mischief.78net> References: <20080417052116.GO9745@mischief.78net> Message-ID: <20080417080547.GB20782@gmx.de> On Thu, Apr 17, 2008 at 03:21:16PM +1000, Alexis Hazell wrote: > Hi all, > > i'm having some trouble 'getting' functional dependencies in the Haskell > context (although my understanding of them in the context of relational > database theory isn't that great either). Could someone please point me > to an introduction / tutorial in this regard? I think you've already tried www.haskell.org -> wiki search ? http://haskell.org/haskellwiki/Functional_dependencies You can express this by specifying a functional dependency, or fundep for short: class Mult a b c | a b -> c where (*) :: a -> b -> c This tells Haskell that c is uniquely determined from a and b. So there you can't implement instances Mult Int Char Sting and Mult Int Char MyString of course, your programs will work withou t that | a b -> c as well, but you need to tell the compiler the result type of (*) fac1 fac2 wheeras using fundeps it knows the result type becaus there can only be one instance. (Which is what you want in this case when multiplying matrizes as well. HTH Marc Weber From mnislaih at gmail.com Thu Apr 17 04:26:48 2008 From: mnislaih at gmail.com (pepe) Date: Thu Apr 17 04:22:01 2008 Subject: [Haskell-cafe] Shim: finding modules In-Reply-To: References: Message-ID: <5E563A18-DAB1-473F-9830-8048898B8F8B@gmail.com> On 16/04/2008, at 22:15, Graham Fawcett wrote: > Hi folks, I'm a newbie, so please forgive any terminological mistakes. > > I've been using Shim in Emacs with great success, but there's one > issue I've encountered, and I don't know if it's configuration problem > or something fundamental. Consider a module 'App' and submodules > 'App.Front' and 'App.Back'. When editing code in App that depends on > the submodules, Shim works well at resolving the location of the > submodules, and validates my code. But when editing App.Front, which > depends on App.Back, Shim fails to validate -- my working directory is > App.Front, and Shim doesn't seem able to find the location of > App.Back. > > I'd like to be able to tell Shim that 'App' is the root of my project, > and to locate modules from that root. Is this possible? > Shim already does this. All it requires is that your project is a Cabal project. Shim will locate the Cabal descriptor and auto configure itself from there. Does that solve your problem ? Cheers pepe From Tom.Schrijvers at cs.kuleuven.be Thu Apr 17 05:36:47 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Thu Apr 17 05:33:19 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <20080416151446.GA3787@soi.city.ac.uk> References: <20080416151446.GA3787@soi.city.ac.uk> Message-ID: > hackageDB has a substantial sample of code these days, which is handy > for questions like this. Thanks, Ross. These examples are perfect! Cheers, Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From alfonso.acosta at gmail.com Thu Apr 17 07:26:26 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Thu Apr 17 07:21:36 2008 Subject: [Haskell-cafe] Intro to functional dependencies in Haskell? In-Reply-To: <20080417052116.GO9745@mischief.78net> References: <20080417052116.GO9745@mischief.78net> Message-ID: <6a7c66fc0804170426t1ec49f07t1cfb407a15c023c3@mail.gmail.com> Not so long ago, I had difficulties to understand functional dependecies. Due to the (sometimes well-grounded) prejudgement of considering research papers as an unfriendly and obscure source of information, I stupidly ruled out reading Mark P Jones original paper. Then I learned I was totally wrong, it is written in a friendly way, with lots of examples, allowing me to finally understand how functional dependencies work and what was the reason to introduce them: http://web.cecs.pdx.edu/~mpj/pubs/fundeps.html On Thu, Apr 17, 2008 at 7:21 AM, Alexis Hazell wrote: > Hi all, > > i'm having some trouble 'getting' functional dependencies in the Haskell > context (although my understanding of them in the context of relational > database theory isn't that great either). Could someone please point me > to an introduction / tutorial in this regard? > > Thanks! > > > Alexis. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From martin.sulzmann at gmail.com Thu Apr 17 07:37:45 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Thu Apr 17 07:32:59 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <78A3C5650E28124399107F21A1FA41945B32FC@ELON17P32002A.csfb.cs-group.com> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <78A3C5650E28124399107F21A1FA41945B32FC@ELON17P32002A.csfb.cs-group.com> Message-ID: <48073689.8090902@gmail.com> Sittampalam, Ganesh wrote: > Martin Sulzmann wrote: > >> Mark P Jones wrote: >> > > >>> In fact, the two sets of dependencies that you have given here are >>> provably equivalent, so it would be decidedly odd to have a "type >>> improvement" system that distinguishes between them. >>> > > >> Based on the FD-CHR formulation, for the single-range FD case we >> get [...] which is clearly weaker. >> [...] >> So, I conclude that in the Haskell type improvement context >> there's clearly a difference among single-range and multi-range FDs. >> > > This seems like a flaw in FD-CHR, rather than a fundamental difference > between the dependencies. > > >> Of course, we could define multi-range FDs in terms of single-range FDs >> which then trivially solves the "equivalence" problem (but some user >> may be disappointed that their multi-range FDs yield weaker improvement). >> > > Why not instead transform single-range FDs into multi-range ones where > possible? > > That's a perfectly reasonable assumption and would establish the logical property that a -> b /\ a -> c iff a -> b /\ c for FDs (by definition). But what about programmers who'd like that C [x] y z yields the improvement y = [b], z =[b] where class C a b c | a -> b c instance C a b b => C [a] [b] [b] It's hard to say who's right or wrong but there's a design space which needs to be explored further. Martin From jgoerzen at complete.org Thu Apr 17 07:45:40 2008 From: jgoerzen at complete.org (John Goerzen) Date: Thu Apr 17 07:40:55 2008 Subject: [Haskell-cafe] Hackage Haddock fails where local succeeds Message-ID: <200804170645.40935.jgoerzen@complete.org> Hi folks, Over at http://hackage.haskell.org/packages/archive/MissingH/1.0.1.2/logs/failure/ghc-6.8 the build has failed in the Hackage step with this output: src/Data/BinPacking.hs:78:32: parse error on input `-- ^ The sizes of bins' haddock: Failed to check module: Data.BinPacking That section of code looks like this: {- | The primary type for bin-packing functions. These functions take a list of size of bins. If every bin is the same size, you can pass @(repeat binSize)@ to pass an infinite list of bins if the same size. Any surplus bins will simply be ignored. -} type BinPacker = (Num size, Ord size, Show size, Show obj) => [size] -- ^ The sizes of bins -> [(size, obj)] -- ^ The sizes and objects -> Either (BinPackerError size obj) [[(size, obj)]] -- ^ Either error or results (the last line got artificially wrapped in my mail client) My local haddock, 0.8, parses this file fine. Is Hackage running and older version? Could it be upgraded? Or is there something else going on here? -- John From ross at soi.city.ac.uk Thu Apr 17 08:01:18 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Apr 17 07:56:28 2008 Subject: [Haskell-cafe] Hackage Haddock fails where local succeeds In-Reply-To: <200804170645.40935.jgoerzen@complete.org> References: <200804170645.40935.jgoerzen@complete.org> Message-ID: <20080417120118.GA6558@soi.city.ac.uk> On Thu, Apr 17, 2008 at 06:45:40AM -0500, John Goerzen wrote: > My local haddock, 0.8, parses this file fine. Is Hackage running and older > version? Could it be upgraded? Or is there something else going on here? No, it's running haddock 2.1.0, which understands all the GHC extensions, but is more picky about comments. From emax at cs.chalmers.se Thu Apr 17 08:18:36 2008 From: emax at cs.chalmers.se (Emil Axelsson) Date: Thu Apr 17 08:14:06 2008 Subject: [Haskell-cafe] Help with associated types Message-ID: <4807401C.7060006@cs.chalmers.se> Hello! I'm trying to rewrite some FD classes to use associated types instead. The Port class is for type structures whose leaves have the same type: class Port p where type Leaf p type Struct p toList :: p -> [Leaf p] fromList :: [Leaf p] -> p (Leaf p) gives the leaf type, and (Struct p) gives a canonical representation of the structure regardless of leaf type. Here we just instantiate two leaf types: instance Port Int where type Leaf Int = Int type Struct Int = () toList a = [a] fromList [a] = a instance Port Bool where type Leaf Bool = Bool type Struct Bool = () toList a = [a] fromList [a] = a There's also a function for mapping over ports: mapPort :: ( Port pa , Port pb , Struct pa ~ Struct pb ) => (Leaf pa -> Leaf pb) -> (pa -> pb) mapPort f = fromList . map f . toList The equality constraint makes sure that we're mapping between equal structures. When I try to run this, I get: *Main> mapPort even (5::Int) :1:8: No instance for (Integral (Leaf Int)) ... because as it stands, mapPort is not able to infer (pb = Bool) from (Struct pb = ()) and (Leaf pb = Bool). What's the easiest way to encode that pb can be inferred from (Struct pb) and (Leaf pb)? Thanks, / Emil PS. I used to have a class class SameStruct pa a pb b | pa -> a, pa b -> pb, pb -> b, pb a -> pa In the example above, we'd have pa=Int and b==Bool, so the second dependeny would infer pb=Bool. From ganesh.sittampalam at credit-suisse.com Thu Apr 17 08:20:44 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Apr 17 08:19:45 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <48073689.8090902@gmail.com> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <78A3C5650E28124399107F21A1FA41945B32FC@ELON17P32002A.csfb.cs-group.com> <48073689.8090902@gmail.com> Message-ID: <78A3C5650E28124399107F21A1FA41945B3302@ELON17P32002A.csfb.cs-group.com> > > Why not instead transform single-range FDs into multi-range ones where > > possible? > That's a perfectly reasonable assumption and would establish the logical property that > a -> b /\ a -> c iff a -> b /\ c > for FDs (by definition). > But what about programmers who'd like that > C [x] y z yields the improvement y = [b], z =[b] > where > class C a b c | a -> b c > instance C a b b => C [a] [b] [b] Isn't that precisely what you earlier said would happen with multi-range FDs? Either I'm missing some difference or we're talking at cross-purposes. My suggestion is that "class C a b c | a -> b c" and "class C a b c | a -> b, a -> c" be both treated as the former case, leading to both cases having the y=[b],z=[b] improvement as above. Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From martin.sulzmann at gmail.com Thu Apr 17 08:59:23 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Thu Apr 17 08:54:38 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <78A3C5650E28124399107F21A1FA41945B3302@ELON17P32002A.csfb.cs-group.com> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <78A3C5650E28124399107F21A1FA41945B32FC@ELON17P32002A.csfb.cs-group.com> <48073689.8090902@gmail.com> <78A3C5650E28124399107F21A1FA41945B3302@ELON17P32002A.csfb.cs-group.com> Message-ID: <480749AB.201@gmail.com> Sittampalam, Ganesh wrote: >>> Why not instead transform single-range FDs into multi-range ones where >>> possible? >>> > > >> That's a perfectly reasonable assumption and would establish the logical property that >> > > >> a -> b /\ a -> c iff a -> b /\ c >> > > >> for FDs (by definition). >> > > >> But what about programmers who'd like that >> > > >> C [x] y z yields the improvement y = [b], z =[b] >> > > >> where >> > > >> class C a b c | a -> b c >> instance C a b b => C [a] [b] [b] >> > > Isn't that precisely what you earlier said would happen with multi-range FDs? > Either I'm missing some difference or we're talking at cross-purposes. > > My suggestion is that > > "class C a b c | a -> b c" and "class C a b c | a -> b, a -> c" be both > treated as the former case, leading to both cases having the y=[b],z=[b] > improvement as above. > > Misunderstanding. I see what you mean. Yes, I agree let's consider a -> b, a -> c as equivalent to a -> b c (I argued the other direction in my earlier email). One subtle point (Tom and I just discussed). It could happen that the programmer writes class SuperCtxt => C a b c | a -> b but there could be an implicit dependency a -> c arising from the super class context SuperCtxt. Hence, you suddenly get a -> b c. The problem is to generate the proper improvement rules. Well, it's not hard to generate these rules we just need to make sure that the rules generated match the programmers intuition how functional dependencies behave. Martin From graham.fawcett at gmail.com Thu Apr 17 09:09:06 2008 From: graham.fawcett at gmail.com (Graham Fawcett) Date: Thu Apr 17 09:04:18 2008 Subject: [Haskell-cafe] Shim: finding modules In-Reply-To: <5E563A18-DAB1-473F-9830-8048898B8F8B@gmail.com> References: <5E563A18-DAB1-473F-9830-8048898B8F8B@gmail.com> Message-ID: On Thu, Apr 17, 2008 at 4:26 AM, pepe wrote: > > On 16/04/2008, at 22:15, Graham Fawcett wrote: > > I'd like to be able to tell Shim that 'App' is the root of my project, > > and to locate modules from that root. Is this possible? > > Shim already does this. All it requires is that your project is a Cabal > project. Shim will locate the Cabal descriptor and auto configure itself > from there. Does that solve your problem ? It does! Thanks very much. Graham From jgoerzen at complete.org Thu Apr 17 09:24:22 2008 From: jgoerzen at complete.org (John Goerzen) Date: Thu Apr 17 09:19:35 2008 Subject: [Haskell-cafe] Hackage Haddock fails where local succeeds In-Reply-To: <20080417120118.GA6558@soi.city.ac.uk> References: <200804170645.40935.jgoerzen@complete.org> <20080417120118.GA6558@soi.city.ac.uk> Message-ID: <200804170824.23144.jgoerzen@complete.org> On Thu April 17 2008 7:01:18 am Ross Paterson wrote: > On Thu, Apr 17, 2008 at 06:45:40AM -0500, John Goerzen wrote: > > My local haddock, 0.8, parses this file fine. Is Hackage running and > > older version? Could it be upgraded? Or is there something else going > > on here? > > No, it's running haddock 2.1.0, which understands all the GHC > extensions, but is more picky about comments. OK. I have been able to replicate this behavior with Haddock 2.0.0.0, which is the latest according to www.haskell.org/haddock. Where did 2.1.0 come from? Although I can replicate the behavior, I can't explain it. My reading of the Haddock docs leads me to believe I have done the correct thing. Is this a bug in Haddock or am I missing something? Is there some different syntax for a "type" declaration that defines an alias for a function? -- John From claus.reinke at talk21.com Thu Apr 17 09:57:57 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Apr 17 09:53:12 2008 Subject: [Haskell-cafe] looking for examples of non-fullFunctional Dependencies References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> Message-ID: <00b201c8a093$0c133080$62398351@cr3lt> > class C a b c | a -> b, a -> c > instance C a b b => C [a] [b] [b] > > Suppose we encounter the constraint C [x] y z interesting example. splitting improvement into two rules seems to lose the (b1=b2) constraint that spans both: [O] C [x] y z => y=[b1]. C [x] y z => z=[b2]. my first thought was that the improvement rules look too general as the instance only applies if (y=z), so i was tempted to add that constraint via guards or patterns: [A] C [x] y [b] => y=[b]. C [x] [b] z => z=[b]. but the FD states that knowing a is sufficient to know both b and c, so one could argue that (y=z), just like (y=[b]) and (z=[b]) should be a consequence rather than a condition for these improvements: [B] C [x] y z => y=z, y=[b]. C [x] y z => y=z, z=[b]. it is interesting to observe Hugs (20051031) vs GHCi (6.9.20080217) on this example and some slight variations (see below). it appears [1] that Hugs follows [B] while GHCi follows [A], and that [2,3] GHCi generally treats structural and unification constraints differently. i have no idea how GHCi comes up with the type (x, [Bool], [Char]) in [2]. btw, Ross started a survey of FD examples/requirements a while ago on the Haskell prime list - it would be nice to have any results of his and your's online (on the wiki perhaps?), especially as documentation regarding different interpretations of the same language extensions between Hugs and GHC (overlap resolution & FDs comes to mind as being fairly similar to this example): http://www.haskell.org/pipermail/haskell-prime/2006-April/001334.html http://www.haskell.org/pipermail/haskell-prime/2006-April/001440.html claus [1] class C a b c | a -> b, a -> c instance C a b b => C [a] [b] [b] Hugs: :t undefined::C [x] y z => (x,y,z) undefined :: C [a] [b] [b] => (a,[b],[b]) GHCi: :t undefined :: C [x] y z => (x,y,z) undefined :: C [x] y z => (x,y,z) :: (C [x] [b] [b1]) => (x, [b], [b1]) [2] class C a b c | a -> b, a -> c instance C a b b => C [a] [b] [b] instance C [a] [Bool] [Char] Hugs: ERROR file:.\C.hs:8 - Instances are not consistent with dependencies *** This instance : C [a] [Bool] [Char] *** Conflicts with : C [a] [b] [b] *** For class : C a b c *** Under dependency : a -> b GHCi: Ok, modules loaded: Main. :t undefined :: C [x] y z => (x,y,z) undefined :: C [x] y z => (x,y,z) :: (x, [Bool], [Char]) [3] class C a b c | a -> b, a -> c instance C a b b => C [a] [b] [b] instance C [a] Bool Char Hugs: ERROR file:.\C.hs:8 - Instances are not consistent with dependencies *** This instance : C [a] Bool Char *** Conflicts with : C [a] [b] [b] *** For class : C a b c *** Under dependency : a -> b GHCi: C:\Documents and Settings\cr3\Desktop\C.hs:7:0: Functional dependencies conflict between instance declarations: instance (C a b b) => C [a] [b] [b] -- Defined at C:\Documents and Settings\cr3\Desktop\C.hs:7:0-32 instance C [a] Bool Char -- Defined at C:\Documents and Settings\cr3\Desktop\C.hs:8:0-23 Failed, modules loaded: none. From bertram.felgenhauer at googlemail.com Thu Apr 17 10:38:04 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Thu Apr 17 10:33:17 2008 Subject: [Haskell-cafe] export question (GHC.Handle) In-Reply-To: References: Message-ID: <20080417143804.GA4366@zombie.inf.tu-dresden.de> Graham Fawcett wrote: > I notice in the source for GHC.Handle that certain functions (e.g. > fdToHandle_stat) are in the export list, but are not actually exported > (at least, it seems you cannot import them). What mechanism causes > these functions to be "hidden", and are they still accessible in some > way? which ghc version are you using, and which sources are you looking at? import GHC.Handle (fdToHandle_stat) works fine in ghc 6.8.2. In the base library shipped with ghc 6.6.1, it wasn't exported (or even defined). HTH, Bertram From marco-oweber at gmx.de Thu Apr 17 10:41:50 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu Apr 17 10:37:01 2008 Subject: [Haskell-cafe] Shim: finding modules In-Reply-To: References: Message-ID: <20080417144150.GB10560@gmx.de> > I'd like to be able to tell Shim that 'App' is the root of my project, > and to locate modules from that root. Is this possible? If adding the cabal file does'nt work contact me and we'll try to reslove this issue. Are you willing to test new versions/ extensions? Are you already using ghc-6.8 ? Must shim still work for ghc-6.6 ? > On a related note, it seems that Shim is moribund (though others have No it is not / won't in the near future Benedikt (author) has even takled to me on irc for 20min I'm the one who has asked and forked because of vim. But I don't plan to keep it forked. That time I didn't knew how to contribute and didn't got any feedback. That's why I've put another shim repository on my server. Maybe you also want to help? It would be cool to get shim integrated into the EclipseFP as well. But there is still a lot to do. Anyway it's nice to see that shim is beeing used. Marc Weber From bertram.felgenhauer at googlemail.com Thu Apr 17 10:46:59 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Thu Apr 17 10:42:11 2008 Subject: [Haskell-cafe] export question (GHC.Handle) In-Reply-To: References: Message-ID: <20080417144659.GB4366@zombie.inf.tu-dresden.de> Fraser Wilson wrote: > Good question. I often need to export a name to other modules within the > hierarchy, but without making them visible outside it. I've "solved" this > problem by giving them funky names and adding a comment, but is there a more > structured way to do this? A quick google hasn't found one yet. Assuming you're writing a cabal package, you could separate the interface from the actual implementation: ------------------------------------------------------------------------ module Hello ( hello ) where import Hello.Impl ------------------------------------------------------------------------ module Hello.Impl ( hello, hello_internal ) where hello, hello_internal :: String hello = "Hello, world!" hello_internal = "The secret word is 'puddleplum'." ------------------------------------------------------------------------ and then list Hello.Impl under extra-modules instead of exposed-modules in the cabal file, which will hide it from external users. Internal users can just use Hello.Impl directly. HTH, Bertram From graham.fawcett at gmail.com Thu Apr 17 10:51:22 2008 From: graham.fawcett at gmail.com (Graham Fawcett) Date: Thu Apr 17 10:46:31 2008 Subject: [Haskell-cafe] export question (GHC.Handle) In-Reply-To: <20080417143804.GA4366@zombie.inf.tu-dresden.de> References: <20080417143804.GA4366@zombie.inf.tu-dresden.de> Message-ID: On Thu, Apr 17, 2008 at 10:38 AM, Bertram Felgenhauer wrote: > > Graham Fawcett wrote: > > I notice in the source for GHC.Handle that certain functions (e.g. > > fdToHandle_stat) are in the export list, but are not actually exported > > (at least, it seems you cannot import them). What mechanism causes > > these functions to be "hidden", and are they still accessible in some > > way? > > which ghc version are you using, and which sources are you looking at? > > import GHC.Handle (fdToHandle_stat) > > works fine in ghc 6.8.2. In the base library shipped with ghc 6.6.1, > it wasn't exported (or even defined). Ah, I was looking at GHC 6.8.2 sources, but I may have been running 6.6.1. PEBKAC, sorry for the noise. Graham From graham.fawcett at gmail.com Thu Apr 17 10:57:08 2008 From: graham.fawcett at gmail.com (Graham Fawcett) Date: Thu Apr 17 10:52:28 2008 Subject: [Haskell-cafe] Shim: finding modules In-Reply-To: <20080417144150.GB10560@gmx.de> References: <20080417144150.GB10560@gmx.de> Message-ID: On Thu, Apr 17, 2008 at 10:41 AM, Marc Weber wrote: > > I'd like to be able to tell Shim that 'App' is the root of my project, > > and to locate modules from that root. Is this possible? > If adding the cabal file does'nt work contact me and we'll try to > reslove this issue. It did work, but thanks for the offer of help. > Are you willing to test new versions/ extensions? Are you already using ghc-6.8 ? Yes, and I don't need ghc-6 support. I'm not sure how much I can help, but I would be a willing tester (on Emacs, particularly). > Anyway it's nice to see that shim is beeing used. Equally glad that it's being supported! Thank you. Graham From dbueno at gmail.com Thu Apr 17 11:32:51 2008 From: dbueno at gmail.com (Denis Bueno) Date: Thu Apr 17 11:27:59 2008 Subject: [Haskell-cafe] Wrong Answer Computing Graph Dominators In-Reply-To: <20080416183356.GA4362@zombie.inf.tu-dresden.de> References: <6dbd4d000804151759r2ca72957hae8cd60c91404e60@mail.gmail.com> <20080416183356.GA4362@zombie.inf.tu-dresden.de> Message-ID: <6dbd4d000804170832h1391db15ob84e61d4e8960170@mail.gmail.com> On Wed, Apr 16, 2008 at 2:33 PM, Bertram Felgenhauer wrote: > No. Data.Graph.Inductive.Query.Dominators is just buggy. [...] > Here's a quick fix: Thanks! This fixes my problem. Have you submitted a bug and your patch to the appropriate tracker? If not, would someone point me to the appropriate one? Would in be the GHC trac, or is there a libraries-specific one? I'll be happy to submit your patch and credit you for it, if someone will point me in the right direction. -- Denis From claus.reinke at talk21.com Thu Apr 17 11:47:42 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Apr 17 11:42:57 2008 Subject: [Haskell-cafe] looking for examples ofnon-fullFunctional Dependencies References: <480615DF.6050807@gmail.com><4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <00b201c8a093$0c133080$62398351@cr3lt> Message-ID: <011501c8a0a2$61355390$62398351@cr3lt> a little more experimentation leaves me confused. consider [4] class C a b c | a -> b -- , a -> c instance C a b b => C [a] [b] [b] Hugs: :t undefined :: C [x] y z => (x,y,z) undefined :: C [a] [b] c => (a,[b],c) GHCi: :t undefined :: C [x] y z => (x,y,z) undefined :: C [x] y z => (x,y,z) :: (C [x] [b] z) => (x, [b], z) both systems improve 'y' to '[b]', but not to '[b] where z=[b]'. ok, the third parameter is not in range of an FD, so cannot be instantiated by improvement, and without that, 'y' cannot be instantiated as far as the FD would suggest. it is slightly surprising that 'y' get partially instantiated at this stage. however, if we try to help the process along by instantiating 'z' to '[b]' ourselves, we get: [5] Hugs: :t undefined :: C [x] y [b] => (x,y,[b]) undefined :: C [a] [b] [c] => (a,[b],[c]) GHCi: :t undefined :: C [x] y [b] => (x,y,[b]) undefined :: C [x] y [b] => (x,y,[b]) :: (C [x] [b1] [b]) => (x, [b1], [b]) i would have expected 'C a c c => (a,[c],[c])' here, as only instantiation of 'y' is required; so my intuition is still off, and neither [A] nor [B] seems to capture Hugs' interpretation. in particular, i don't see how to account for [5], even with a refined ruleset that accounts for [4]. suggestions?-) claus ----- Original Message ----- From: "Claus Reinke" To: "Martin Sulzmann" ; "Mark P Jones" Cc: "Tom Schrijvers" ; "Haskell-cafe Caf?" Sent: Thursday, April 17, 2008 2:57 PM Subject: Re: [Haskell-cafe] looking for examples ofnon-fullFunctional Dependencies >> class C a b c | a -> b, a -> c >> instance C a b b => C [a] [b] [b] >> >> Suppose we encounter the constraint C [x] y z > > interesting example. splitting improvement into two rules seems to lose the (b1=b2) constraint > that spans both: > > [O] > C [x] y z => y=[b1]. > C [x] y z => z=[b2]. > > my first thought was that the improvement rules look too general > as the instance only applies if (y=z), so i was tempted to add that > constraint via guards or patterns: > > [A] > C [x] y [b] => y=[b]. > C [x] [b] z => z=[b]. > > but the FD states that knowing a is sufficient to know both b and c, so one could argue that > (y=z), just like (y=[b]) and (z=[b]) should be a consequence rather than a condition for these > improvements: > > [B] > C [x] y z => y=z, y=[b]. > C [x] y z => y=z, z=[b]. > > it is interesting to observe Hugs (20051031) vs GHCi (6.9.20080217) > on this example and some slight variations (see below). it appears [1] that Hugs follows [B] while > GHCi follows [A], and that [2,3] GHCi generally treats structural and unification constraints > differently. i have no idea how GHCi comes up with the type (x, [Bool], [Char]) in [2]. > > btw, Ross started a survey of FD examples/requirements a while ago on the Haskell prime list - it > would be nice to have any results of his and your's online (on the wiki perhaps?), especially as > documentation regarding different interpretations of the same language extensions between Hugs and > GHC (overlap resolution & FDs comes to mind > as being fairly similar to this example): > > http://www.haskell.org/pipermail/haskell-prime/2006-April/001334.html > http://www.haskell.org/pipermail/haskell-prime/2006-April/001440.html > > claus > > [1] > class C a b c | a -> b, a -> c > instance C a b b => C [a] [b] [b] > > Hugs: :t undefined::C [x] y z => (x,y,z) > undefined :: C [a] [b] [b] => (a,[b],[b]) > > GHCi: > :t undefined :: C [x] y z => (x,y,z) > undefined :: C [x] y z => (x,y,z) :: (C [x] [b] [b1]) => (x, [b], [b1]) > > [2] > class C a b c | a -> b, a -> c > instance C a b b => C [a] [b] [b] > instance C [a] [Bool] [Char] > > Hugs: > ERROR file:.\C.hs:8 - Instances are not consistent with dependencies > *** This instance : C [a] [Bool] [Char] > *** Conflicts with : C [a] [b] [b] > *** For class : C a b c > *** Under dependency : a -> b > > GHCi: > Ok, modules loaded: Main. > :t undefined :: C [x] y z => (x,y,z) > undefined :: C [x] y z => (x,y,z) :: (x, [Bool], [Char]) > > [3] > class C a b c | a -> b, a -> c > instance C a b b => C [a] [b] [b] > instance C [a] Bool Char > > Hugs: > ERROR file:.\C.hs:8 - Instances are not consistent with dependencies > *** This instance : C [a] Bool Char > *** Conflicts with : C [a] [b] [b] > *** For class : C a b c > *** Under dependency : a -> b > > GHCi: > C:\Documents and Settings\cr3\Desktop\C.hs:7:0: > Functional dependencies conflict between instance declarations: > instance (C a b b) => C [a] [b] [b] > -- Defined at C:\Documents and Settings\cr3\Desktop\C.hs:7:0-32 > instance C [a] Bool Char > -- Defined at C:\Documents and Settings\cr3\Desktop\C.hs:8:0-23 > Failed, modules loaded: none. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From miguellordelo at gmail.com Thu Apr 17 12:41:20 2008 From: miguellordelo at gmail.com (Miguel Lordelo) Date: Thu Apr 17 12:36:33 2008 Subject: [Haskell-cafe] C++ interface with Haskell In-Reply-To: <4806A4F6.4090404@charter.net> References: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> <4806A4F6.4090404@charter.net> Message-ID: <7981f6330804170941r3e19a0d0v93ae0d0d05c33d12@mail.gmail.com> Well Isaac...I became now a little bit smarter then yesterday!!! I show you the example that I found and on which I?m working with. File: foo.hs module Foo where foreign export ccall foo :: Int -> IO Int foo :: Int -> IO Int foo n = return (length (f n)) f :: Int -> [Int] f 0 = [] f n = n:(f (n-1)) To get the C wrapper you insert the following command: ghc -ffi -fvia-C -C foo.hs After execution you will have these following additional files: foo.hc foo.hi foo_stub.c foo_stub.h foo_stub.o What I did next was to create a file named: myfoo_c.c, where I will call the foo function (implemented in Haskell). (you can see this example on http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html ) But the problem is to compile with gcc (must I put any flag or whatever set something) The gcc output is: myfoo_c.c:2:19: error: HsFFI.h: No such file or directory I downloaded this header file from: (I know that is not the correct way, but it was the only idea that occurs at the moment) http://www.koders.com/c/fidD0593B84C41CA71319BB079EFD0A2C80211C9337.aspx I compiled again and the following return error appears: myfoo_c.c:(.text+0x1c): undefined reference to `hs_init' myfoo_c.c:(.text+0x31): undefined reference to `foo' myfoo_c.c:(.text+0x50): undefined reference to `hs_exit' collect2: ld returned 1 exit status These functions are necessary to setup GHC runtime (see: http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html ) What I want to know is how to compile myfoo_c.c?! Is it with GCC or GHC?! Chears, Miguel Lordelo. On Wed, Apr 16, 2008 at 9:16 PM, Isaac Dupree wrote: > perhaps > > haskell: > foreign export "foo_func" foo :: Int -> IO Int > -- I forget the rest of the syntax here > > C++: > > extern "C" { > int foo_func(int i); > } > > int some_cplusplus_function() { > int bat = 3; > int blah = foo_func(bat); > return blah; > } > > > Is that all you need to do? > > > Miguel Lordelo wrote: > > > Hi all, > > > > Well...somehow I'm a beginner in Haskell. But actually my interest in > > Haskell will increase if it is possible to call a haskell function in > > C++. > > Something like GreenCard ( http://www.haskell.org/greencard/ ) > > simplifying > > the task of interfacing Haskell programs to external libraries > > (usually). > > But is there also a task to interface a foreign language with Haskell, > > but > > calling Haskell functions. Or c2hs which is an interface generator that > > simplifies the development of Haskell bindings to C libraries. > > > > I want to know this, because in my company some guys are doing some > > testing > > with Frotran and MatLab and I want to show them the power of haskell and > > the > > software which we are using is implemented in C++ (there is the reason > > to > > make Haskel -> C++). > > > > I read somewhere that the only way for C++ calling a haskell function is > > to > > create a binding between Haskell and C and from C to C++, but a easy > > "Hello > > World" example was not there. > > Unfortunatelly I couldn't found anything usefull, like an complete > > example, > > or how to compile the code from haskell to C to C++. > > > > Can sombody help me, please :P > > > > Chears, > > Miguel Lordelo. > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080417/d5612d97/attachment.htm From valgarv at gmx.net Thu Apr 17 12:57:15 2008 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Thu Apr 17 12:52:53 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <334026.85117.qm@web30201.mail.mud.yahoo.com> References: <334026.85117.qm@web30201.mail.mud.yahoo.com> Message-ID: <200804171957.15648.valgarv@gmx.net> > Common Misunderstandings - HaskellWiki > http://www.haskell.org/haskellwiki/Common_Misunderstandings I didn't find this one... maybe it should be in a more prominent place? > Things to avoid - HaskellWiki > http://www.haskell.org/haskellwiki/Things_to_avoid I thought of this but it has more discussions about style than pitfalls... it seems to me more oriented to people who know Haskell well and want to write better. Maybe a link from here to the above would be a good idea. Thanks for adding this case to the wiki =) -- Ariel J. Birnbaum From iavor.diatchki at gmail.com Thu Apr 17 13:09:08 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu Apr 17 13:04:24 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <4806E8DA.9070503@gmail.com> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> Message-ID: <5ab17e790804171009l6d974cf2va38cbd94dccf3303@mail.gmail.com> Hello, On Wed, Apr 16, 2008 at 11:06 PM, Martin Sulzmann wrote: > 3) Multi-range FDs > > Consider > > class C a b c | a -> b c > > instance C a b b => C [a] [b] [b] > > This time it's straightforward. > > C [x] y z yields the improvement y = [b] and z = [b] > which then allows us to apply the instance. I don't think that this improvement rule is justified (unless there are some assumptions that are added to the system that go beyond FD?). By the way, note that the above example does not have any instances for C, so lets first add a base case like this: instance C Char Bool Bool Now the instances for C are: { C Char Bool Bool, C [Char] [Bool] [Bool], ... }. Certainly, if you just consider these instances, then the improvement rule that you suggest is valid. However, suppose that we also add the instance: instance C [Int] Char Bool Note that this instance does not violate the FD: if we know the first argument, then we know exactly what are the other two arguments. In this context, it is not OK to improve C [x] y z as you suggest because 'x' may be instantiate to 'Int'. -Iavor From martin.sulzmann at gmail.com Thu Apr 17 13:26:41 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Thu Apr 17 13:21:57 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <5ab17e790804171009l6d974cf2va38cbd94dccf3303@mail.gmail.com> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <5ab17e790804171009l6d974cf2va38cbd94dccf3303@mail.gmail.com> Message-ID: <48078851.1050201@gmail.com> Iavor Diatchki wrote: > Hello, > > On Wed, Apr 16, 2008 at 11:06 PM, Martin Sulzmann > wrote: > >> 3) Multi-range FDs >> >> Consider >> >> class C a b c | a -> b c >> >> instance C a b b => C [a] [b] [b] >> >> This time it's straightforward. >> >> C [x] y z yields the improvement y = [b] and z = [b] >> which then allows us to apply the instance. >> > > I don't think that this improvement rule is justified (unless there > are some assumptions that are added to the system that go beyond FD?). > By the way, note that the above example does not have any instances > for C, so lets first add a base case like this: > > instance C Char Bool Bool > > Now the instances for C are: { C Char Bool Bool, C [Char] [Bool] > [Bool], ... }. Certainly, if you just consider these instances, then > the improvement rule that you suggest is valid. However, suppose that > we also add the instance: > > instance C [Int] Char Bool > > Note that this instance does not violate the FD: if we know the first > argument, then we know exactly what are the other two arguments. In > this context, it is not OK to improve C [x] y z as you suggest because > 'x' may be instantiate to 'Int' > There possible points of view here. Consider a -> b c as a short-hand for a -> b, a -> c. That's fine. But we may also want to go beyond (single-range) FDs. That's why I have in mind. Therefore, a -> b, a -> c is a short-hand for a -> b, c. (At least there's one supporter, Ganesh, assuming that Tom and I are neutral :) ) Suppose we encode the multi-range FD a -> b, c as defined in the FD-CHR paper. Then, class C a b c | a -> b c instance C a b b => C [a] [b] [b] instance C [Int] Char Bool leads to an instance improvement/instance improvement conflict, like in the single-range FD case class D a b | a -> b instance D a a => D [a] [a] instance D [Int] Char All of the above design choices make sense. There's no right or wrong. But it's wrong to simply ignore possible FD variants which go beyond single-range FDs. Martin From david.waern at gmail.com Thu Apr 17 13:37:39 2008 From: david.waern at gmail.com (David Waern) Date: Thu Apr 17 13:32:47 2008 Subject: Fwd: [Haskell-cafe] Hackage Haddock fails where local succeeds In-Reply-To: References: <200804170645.40935.jgoerzen@complete.org> <20080417120118.GA6558@soi.city.ac.uk> <200804170824.23144.jgoerzen@complete.org> Message-ID: 2008/4/17, John Goerzen : > On Thu April 17 2008 7:01:18 am Ross Paterson wrote: > > On Thu, Apr 17, 2008 at 06:45:40AM -0500, John Goerzen wrote: > > > My local haddock, 0.8, parses this file fine. Is Hackage running and > > > older version? Could it be upgraded? Or is there something else going > > > on here? > > > > No, it's running haddock 2.1.0, which understands all the GHC > > extensions, but is more picky about comments. > > > OK. I have been able to replicate this behavior with Haddock 2.0.0.0, which > is the latest according to www.haskell.org/haddock. Where did 2.1.0 come > from? > > Although I can replicate the behavior, I can't explain it. My reading of the > Haddock docs leads me to believe I have done the correct thing. Is this a > bug in Haddock or am I missing something? It's a bug. Comments on type synonyms were missed when Haddock support was added to the GHC parser. This might be fixed in future versions of GHC. David From mail at joachim-breitner.de Thu Apr 17 13:43:00 2008 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu Apr 17 13:38:21 2008 Subject: [Haskell-cafe] Announcing DarcsWatch Message-ID: <1208454180.3829.3.camel@otto.ehbuehl.net> Hi, (Hi again to those on haskell-cafe, but things have changed since the other announcement) A lot of haskell-related projects use the darcs version control system. Darcs has the nice feature that you can easily submit a patch by e-mail, usually sent to the project maintainer or a mailing list. What has bothered me in the past was that I had to manually check whether my patch was applied yet. So this week, I wrote DarcsWatch. DarcsWatch receives submitted patches and compares them to the repositories it knows about, whether the patch is missing there or not. You either send your patches to DarcsWeb directly when submitting them, using CC, or DarcsWatch is subscribed to the project mailing list itself, which is the case for the darcs-devel and xmonad lists. Other than that, not much is to do, and you?ll find a nice overview of your patches with diffs and download links. For an example, see: http://darcswatch.nomeata.de/user_mail@joachim-breitner.de.html If you want to use DarcsWatch for your contributions to other projects, or for your own projects, have a look the documentation at http://darcs.nomeata.de/darcswatch/documentation.html There are probably still bugs around, and the problem of marking patches as obsolete is not really solved yet, so if you have ideas about it, mail me or come to #darcs on freenode. Patches are always welcome, you can get the source from DarcsWatch?s repository, found at http://darcs.nomeata.de/darcswatch/ Enjoy, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080417/b36cea0e/attachment.bin From blancolioni at gmail.com Thu Apr 17 13:50:07 2008 From: blancolioni at gmail.com (Fraser Wilson) Date: Thu Apr 17 13:45:26 2008 Subject: [Haskell-cafe] export question (GHC.Handle) In-Reply-To: <20080417144659.GB4366@zombie.inf.tu-dresden.de> References: <20080417144659.GB4366@zombie.inf.tu-dresden.de> Message-ID: On Thu, Apr 17, 2008 at 4:46 PM, Bertram Felgenhauer < bertram.felgenhauer@googlemail.com> wrote: > > Assuming you're writing a cabal package, you could separate the interface > from the actual implementation: [..] > > HTH, Magic. Thanks a lot! cheers, Fraser. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080417/c1ad38bf/attachment-0001.htm From hthiel.char at zonnet.nl Thu Apr 17 13:54:42 2008 From: hthiel.char at zonnet.nl (Hans van Thiel) Date: Thu Apr 17 13:51:39 2008 Subject: [Haskell-cafe] Ann: Emping 0.5 in Hackage Message-ID: <1208454882.7075.28.camel@localhost.localdomain> Emping is a utility which derives the shortest rules from a table of rules. For example, in a list of 8000 different mushrooms, it finds 21 single predicates that determine the mushroom is poisonous, and 23 that it is edible. But it also finds all combinations of two, three and more predicates that determine this property. Each shorter rule is a generalization of an original one. So, if r1 covers {a,b,c} and r2 {a,b}, then r2 implies r1 (r1 entails r2). The shorter rules are partially ordered. Thanks to the functional graphs library, which comes with ghc, the reduced rules are now displayed as graphs which can be viewed with a Graphviz viewer. Also new in 0.5 is that the reduced rules, and the reduced rules in an equivalence class, are ordered by length. Lastly, the GUI has been improved. Testing has also shown some bugs and issues, most importantly when the data contains ambiguous rules. Ambiguities are rules with the same antecedent, but a different consequent. You can test for them, but if the user turns the checks off and run Emping without correcting the data, the program could hang, in a special case. See http://home.telfort.nl/sp969709/emp/empug.html for more info and a few screenshots. Thank you all, Hans van Thiel From Tom.Schrijvers at cs.kuleuven.be Thu Apr 17 14:11:44 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Thu Apr 17 14:07:58 2008 Subject: [Haskell-cafe] looking for examples ofnon-fullFunctional Dependencies In-Reply-To: <011501c8a0a2$61355390$62398351@cr3lt> References: <480615DF.6050807@gmail.com><4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <00b201c8a093$0c133080$62398351@cr3lt> <011501c8a0a2$61355390$62398351@cr3lt> Message-ID: > a little more experimentation leaves me confused. consider > > [4] > class C a b c | a -> b -- , a -> c > instance C a b b => C [a] [b] [b] > > Hugs: > :t undefined :: C [x] y z => (x,y,z) > undefined :: C [a] [b] c => (a,[b],c) > > GHCi: > :t undefined :: C [x] y z => (x,y,z) > undefined :: C [x] y z => (x,y,z) :: (C [x] [b] z) => (x, [b], z) > > both systems improve 'y' to '[b]', but not to '[b] where z=[b]'. > > ok, the third parameter is not in range of an FD, so cannot be > instantiated by improvement, and without that, 'y' cannot be > instantiated as far as the FD would suggest. it is slightly > surprising that 'y' get partially instantiated at this stage. My understanding of an FD a -> b is to improve, or in other words instantiate, b as much as possible based on information from a. With C [x] y z we know for sure that y must be [b] for some b. Improvement adds (propagates) this information we know for sure. With our limited information, we may not know what b is, but just knowing the list type constructor [] may already be useful. For instance, if we had a second type class constraint D y for which there is an instance instance D [a] where ... Then inferring that y = [b] will allow us to figure out that we can use the above instance for it. > however, if we try to help the process along by instantiating > 'z' to '[b]' ourselves, we get: > > [5] > Hugs: > :t undefined :: C [x] y [b] => (x,y,[b]) > undefined :: C [a] [b] [c] => (a,[b],[c]) > > GHCi: > :t undefined :: C [x] y [b] => (x,y,[b]) > undefined :: C [x] y [b] => (x,y,[b]) :: (C [x] [b1] [b]) => (x, [b1], > [b]) > > i would have expected 'C a c c => (a,[c],[c])' here, as > only instantiation of 'y' is required; so my intuition is still off, > and neither [A] nor [B] seems to capture Hugs' interpretation. You did not provide the FD a -> c (or even a -> b c). That means that you did not allow the type checker to improve c based on a. Nor did you provide the FD a c -> b. For that reason the type checker does not use any information from the third parameter to improve the second parameter. It does indeed feel somewhat strange, because there is no alternative for y (except if you allow overlapping instances and add e.g. an instance C [a] [b] [Int]). Cheers, Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From iavor.diatchki at gmail.com Thu Apr 17 14:13:54 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu Apr 17 14:09:05 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <48078851.1050201@gmail.com> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <5ab17e790804171009l6d974cf2va38cbd94dccf3303@mail.gmail.com> <48078851.1050201@gmail.com> Message-ID: <5ab17e790804171113i647ff98ftde208ca753f88f0d@mail.gmail.com> Hello, On Thu, Apr 17, 2008 at 10:26 AM, Martin Sulzmann wrote: > leads to an instance improvement/instance improvement conflict, > like in the single-range FD case > > class D a b | a -> b > > instance D a a => D [a] [a] > instance D [Int] Char Sorry to be picky but there is no violation of the FD here. Note that the class D has only a single ground instance and to violate an FD you need at least two. As in the previous example, we can add an instance like this: instance D Char Char This results in more ground instances: { D [Int] Char, D Char Char, D [Char] [Char], ... } but again, there is no violation of the FD. I think that a lot of the confusion in discussions such as this one (and we've had a few of those :-) stems from the fact that the term "functional dependency" seems to have become heavily overloaded. Often, the basic concept is mixed with (i) concepts related to checking that the basic concept holds (e.g., various restrictions on instances, etc), (ii) concepts related to how we might want to use the basic concept (e.g., what improvement rules to use). Of course, (i) and (ii) are very important, and there are a lot possible design choices. However, a number of the discussions I have seen go like this: 1) In general, it is hard to check if instances violate the stated functional dependencies. 2) So we have more restrictive rules, that are easier to check. 3) These more restrictive rules give us stronger guarantees, so we have more opportunity for improvement. While there is nothing inherently wrong with this, it is important to note that the extra improvement is not a result of the use of FDs but rather, from the extra restrictions that we placed on the instances. I think that this distinction is important because (i) it avoids mixing concepts, and (ii) points to new things that we may want to consider. For example, I think that there is an opportunity for improvement in situations where is class is not exported from a module. Then we know the full set of instances for the class, and we may be able to compute improvement rules. Hope this helps! -Iavor -Iavor From mail at joachim-breitner.de Thu Apr 17 14:14:17 2008 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu Apr 17 14:09:38 2008 Subject: [Haskell-cafe] Announcing DarcsWatch (with link) Message-ID: <1208456057.3829.5.camel@otto.ehbuehl.net> Hi, sorry for the spam, but what I forgot in the first mail: You can find DarcsWatch at: http://darcswatch.nomeata.de/ A lot of haskell-related projects use the darcs version control system. Darcs has the nice feature that you can easily submit a patch by e-mail, usually sent to the project maintainer or a mailing list. What has bothered me in the past was that I had to manually check whether my patch was applied yet. So this week, I wrote DarcsWatch. DarcsWatch receives submitted patches and compares them to the repositories it knows about, whether the patch is missing there or not. You either send your patches to DarcsWeb directly when submitting them, using CC, or DarcsWatch is subscribed to the project mailing list itself, which is the case for the darcs-devel and xmonad lists. Other than that, not much is to do, and you?ll find a nice overview of your patches with diffs and download links. For an example, see: http://darcswatch.nomeata.de/user_mail@joachim-breitner.de.html If you want to use DarcsWatch for your contributions to other projects, or for your own projects, have a look the documentation at http://darcs.nomeata.de/darcswatch/documentation.html There are probably still bugs around, and the problem of marking patches as obsolete is not really solved yet, so if you have ideas about it, mail me or come to #darcs on freenode. Patches are always welcome, you can get the source from DarcsWatch?s repository, found at http://darcs.nomeata.de/darcswatch/ Enjoy, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080417/1decc568/attachment.bin From martin.sulzmann at gmail.com Thu Apr 17 15:05:41 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Thu Apr 17 15:00:54 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <5ab17e790804171113i647ff98ftde208ca753f88f0d@mail.gmail.com> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <5ab17e790804171009l6d974cf2va38cbd94dccf3303@mail.gmail.com> <48078851.1050201@gmail.com> <5ab17e790804171113i647ff98ftde208ca753f88f0d@mail.gmail.com> Message-ID: <48079F85.5030408@gmail.com> Iavor Diatchki wrote: > Hello, > > On Thu, Apr 17, 2008 at 10:26 AM, Martin Sulzmann > wrote: > >> leads to an instance improvement/instance improvement conflict, >> like in the single-range FD case >> >> class D a b | a -> b >> >> instance D a a => D [a] [a] >> instance D [Int] Char >> > > Sorry to be picky but there is no violation of the FD here. Note that > the class D has only a single ground instance and to violate an FD you > need at least two. As in the previous example, we can add an instance > like this: > > instance D Char Char > > This results in more ground instances: { D [Int] Char, D Char Char, D > [Char] [Char], ... } but again, there is no violation of the FD. > > I think that a lot of the confusion in discussions such as this one > (and we've had a few of those :-) stems from the fact that the term > "functional dependency" seems to have become heavily overloaded. > Often, the basic concept is mixed with (i) concepts related to > checking that the basic concept holds (e.g., various restrictions on > instances, etc), (ii) concepts related to how we might want to use the > basic concept (e.g., what improvement rules to use). Of course, (i) > and (ii) are very important, and there are a lot possible design > choices. However, a number of the discussions I have seen go like > this: > 1) In general, it is hard to check if instances violate the stated > functional dependencies. > 2) So we have more restrictive rules, that are easier to check. > 3) These more restrictive rules give us stronger guarantees, so we > have more opportunity for improvement. > While there is nothing inherently wrong with this, it is important to > note that the extra improvement is not a result of the use of FDs but > rather, from the extra restrictions that we placed on the instances. > I think that this distinction is important because (i) it avoids > mixing concepts, and (ii) points to new things that we may want to > consider. For example, I think that there is an opportunity for > improvement in situations where is class is not exported from a > module. Then we know the full set of instances for the class, and we > may be able to compute improvement rules. > > Hope this helps! > -Iavor > > Can you pl specify the improvement rules for your interpretation of FDs. That would help! I'm simply following Mark Jones' style FDs. Mark's ESOP'00 paper has a consistency condition: If two instances match on the FD domain then the must also match on their range. The motivation for this condition is to avoid inconsistencies when deriving improvement rules from instances. For class D a b | a -> b instance D a a => D [a] [a] instance D [Int] Char we get D [a] b ==> b =[a] D [Int] b ==> b=Char In case of D [Int] b we therefore get b=Char *and* b =[a] which leads to a (unification) error. The consistency condition avoids such situations. The beauty of formalism FDs with CHRs (or type functions/families) is that the whole improvement process becomes explicit. Of course, it has to match the programmer's intuition. See the discussion regarding multi-range FDs. Martin From gour at mail.inet.hr Thu Apr 17 15:14:26 2008 From: gour at mail.inet.hr (Gour) Date: Thu Apr 17 15:09:51 2008 Subject: [Haskell-cafe] Re: Shim: finding modules References: <20080417144150.GB10560@gmx.de> Message-ID: <87lk3cxpil.fsf@gaura-nitai.no-ip.org> >>>>> "Graham" == Graham Fawcett writes: Graham> Equally glad that it's being supported! Thank you. Where one can found it? Few days ago I was told on #haskell that shim is dead :-/ Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080417/b9c96fc3/attachment.bin From dbueno at gmail.com Thu Apr 17 17:13:05 2008 From: dbueno at gmail.com (Denis Bueno) Date: Thu Apr 17 17:08:17 2008 Subject: [Haskell-cafe] Wrong Answer Computing Graph Dominators In-Reply-To: <6dbd4d000804170832h1391db15ob84e61d4e8960170@mail.gmail.com> References: <6dbd4d000804151759r2ca72957hae8cd60c91404e60@mail.gmail.com> <20080416183356.GA4362@zombie.inf.tu-dresden.de> <6dbd4d000804170832h1391db15ob84e61d4e8960170@mail.gmail.com> Message-ID: <6dbd4d000804171413h54c33f35sdb1c9554d4d4c9@mail.gmail.com> On Thu, Apr 17, 2008 at 11:32 AM, Denis Bueno wrote: > On Wed, Apr 16, 2008 at 2:33 PM, Bertram Felgenhauer > wrote: > > No. Data.Graph.Inductive.Query.Dominators is just buggy. I have one more problem. For the attached graph, the dominators of the -20 node are computed correctly (namely, [-20,-1,11,12]). But the list of dominators for 20 is present, when in fact 20 isn't reachable from 12. I think 20 should be absent from the return value of `dom graph 12'. (And hence a call to `lookup 20 (dom graph 12)' should return Nothing.) Instead it returns [-20,-1,-3,11,12,-14,17]. Is my reasoning correct? I'd try to fix the code, but, I don't understand how it works. -- Denis -------------- next part -------------- A non-text attachment was scrubbed... Name: bad-dominators2.ps Type: application/postscript Size: 12915 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080417/51544b32/bad-dominators2.ps From jsnow at cs.pdx.edu Thu Apr 17 16:45:05 2008 From: jsnow at cs.pdx.edu (Jim Snow) Date: Thu Apr 17 17:41:53 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) Message-ID: <4807B6D1.7090006@cs.pdx.edu> A new version of my raytracer is out. It now supports cones, cylinders, disks, boxes, and planes as base primitives (previously it only supported triangles and spheres), as well as transformations of arbitrary objects (rotate, scale, translate) and the CSG operations difference and intersection. Perlin noise and Blinn highlights have been added, as well. http://syn.cs.pdx.edu/~jsnow/glome/ Glome can parse NFF-format scene files (see http://tog.acm.org/resources/SPD/), but many features are only accessible via raw Haskell, since NFF doesn't support very many kinds of primitives. I included a TestScene.hs file that demonstrates how to create a scene with various kinds of geometry (including a crude attempt at a recursively-defined oak tree) in haskell. There isn't any documentation yet, but many of the primitives have constructors that resemble their equivalents in povray, so anyone familiar with povray's syntax should be able to figure out what's going on. -jim From lennart at augustsson.net Thu Apr 17 17:49:10 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Apr 17 17:44:18 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <4806E8DA.9070503@gmail.com> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> Message-ID: To reuse a favorite word, I think that any implementation that distinguishes 'a -> b, a -> c' from 'a -> b c' is broken. :) It does not implement FD, but something else. Maybe this something else is useful, but if one of the forms is strictly more powerful than the other then I don't see why you would ever want the less powerful one. -- Lennart On Thu, Apr 17, 2008 at 7:06 AM, Martin Sulzmann wrote: > Mark P Jones wrote: > > > Martin Sulzmann wrote: > > > > > We're also looking for (practical) examples of "multi-range" > > > functional dependencies > > > > > > class C a b c | c -> a b > > > > > > Notice that there are multiple (two) parameters in the range of the > > > FD. > > > > > > It's tempting to convert the above to > > > > > > class C a b c | c -> a, c -> b > > > > > > but this yields a weaker (in terms of type improvement) system. > > > > > > > I agree with Iavor. > > > > In fact, the two sets of dependencies that you have given here > > are provably equivalent, so it would be decidedly odd to have > > a "type improvement" system that distinguishes between them. > > > > > Consider > > class C a b c | a -> b, a -> c > > instance C a b b => C [a] [b] [b] > > Suppose we encounter the constraint > > C [x] y z > > What results can we expect from type improvement? > > 1) Single-range non-full FDs in GHC following the FD-CHR formulation: > > The first FD C a b c | a -> b in combination with > the instance head C [a] [b] [b] will yield > > C [x] y z improved by y = [b1] for some b1 > > A similar reasoning yields > > C [x] y z improved by z = [b2] for some b2 > > So, overall we get > > C [x] y z improved by y= [b1] and z = [b2] > > Unfortunately, we couldn't establish that b1 and b2 are equal. > Hence, we can *not* apply the instance. > > 2) Alternative design: > > We could now argue that the improvement implied by the FD > is only applicable if we are in the "right" context. > > That is, > C [x] y z doesn't yield any improvement because > the context y is still underspecified (doesn't match > the instance). > > In case of C [x] [y] z we get z = [y] > (and C [x] z [y] yields z = [y]) > > > 3) Multi-range FDs > > Consider > > class C a b c | a -> b c > > instance C a b b => C [a] [b] [b] > > This time it's straightforward. > > C [x] y z yields the improvement y = [b] and z = [b] > which then allows us to apply the instance. > > 4) Summary. > > With multi-range FDs we can derive "more" improvement. > > C [x] y z yields y = [b] and z = [b] > > Based on the FD-CHR formulation, for the single-range FD case we get > > C [x] y z yields y = [b1] and z = [b2] > > which is clearly weaker. > > The alternative design is even weaker, from C [x] y z we can derive > any improvement. > > So, I conclude that in the Haskell type improvement context > there's clearly a difference among single-range and multi-range FDs. > > Of course, we could define multi-range FDs in terms of single-range FDs > which then trivially solves the "equivalence" problem (but some user > may be disappointed that their multi-range FDs yield weaker improvement). > > Thanks for your pointers below but I believe that FDs in the Haskell > context > can be quite different from FDs in the database context. > > - Martin > > > While you're looking for unusual examples of fundeps, you > > might also want to consider things like: > > > > class C a b c | a -> b, b -> c > > > > Note that this is subtly different from a -> b c because > > > > {a -> b, b -> c} |= {a -> b c} > > > > while the reverse does not hold. Instead of type classes, > > I'll give you some more down-to-earth examples of relations > > that satisfy these dependencies: > > > > {Paper, Conference, Year} > > {Professor, University, Country} > > {Person, FavoriteFood, FoodGroup} > > ... > > > > For further insight, you might want to take a look at the theory > > of relational databases to see how functional dependencies are > > used there. In that context, some sets of dependencies (such > > as {a -> b, b -> c}) can be interpreted as indicators of bad > > design. This, in turn, might give you some ideas about the kinds > > of dependencies you can expect to encounter in well-designed > > Haskell code. (Of course, you might still find examples in other > > Haskell code of dependencies that would make a database person > > wince :-) > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080417/253a67a5/attachment.htm From westondan at imageworks.com Thu Apr 17 17:52:43 2008 From: westondan at imageworks.com (Dan Weston) Date: Thu Apr 17 17:47:50 2008 Subject: [Haskell-cafe] Wrong Answer Computing Graph Dominators In-Reply-To: <6dbd4d000804171413h54c33f35sdb1c9554d4d4c9@mail.gmail.com> References: <6dbd4d000804151759r2ca72957hae8cd60c91404e60@mail.gmail.com> <20080416183356.GA4362@zombie.inf.tu-dresden.de> <6dbd4d000804170832h1391db15ob84e61d4e8960170@mail.gmail.com> <6dbd4d000804171413h54c33f35sdb1c9554d4d4c9@mail.gmail.com> Message-ID: <4807C6AB.3050902@imageworks.com> Your reasoning differs from the usual understanding of a null product (1 or True), as compared to a null sum (0 or False): > the list of nodes for which > *any path* from source to x must touch, i.e., the list of dominators > of x. Here, "any path" means all paths, a logical conjunction: and [True, True] = True and [True ] = True and [ ] = True The empty case of all sources touching is True, so 12 is a valid dominator for 20 if there is no path from 12 to 20. Dan Denis Bueno wrote: > On Thu, Apr 17, 2008 at 11:32 AM, Denis Bueno wrote: >> On Wed, Apr 16, 2008 at 2:33 PM, Bertram Felgenhauer >> wrote: >> > No. Data.Graph.Inductive.Query.Dominators is just buggy. > > I have one more problem. For the attached graph, the dominators of > the -20 node are computed correctly (namely, [-20,-1,11,12]). But the > list of dominators for 20 is present, when in fact 20 isn't reachable > from 12. I think 20 should be absent from the return value of `dom > graph 12'. (And hence a call to `lookup 20 (dom graph 12)' should > return Nothing.) Instead it returns [-20,-1,-3,11,12,-14,17]. > > Is my reasoning correct? I'd try to fix the code, but, I don't > understand how it works. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From graham.fawcett at gmail.com Thu Apr 17 18:17:31 2008 From: graham.fawcett at gmail.com (Graham Fawcett) Date: Thu Apr 17 18:12:49 2008 Subject: [Haskell-cafe] Re: Shim: finding modules In-Reply-To: <87lk3cxpil.fsf@gaura-nitai.no-ip.org> References: <20080417144150.GB10560@gmx.de> <87lk3cxpil.fsf@gaura-nitai.no-ip.org> Message-ID: 2008/4/17 Gour : > >>>>> "Graham" == Graham Fawcett writes: > > Graham> Equally glad that it's being supported! Thank you. > > Where one can found it? > > Few days ago I was told on #haskell that shim is dead :-/ The original, I believe: http://mapcar.org/haskell/shim/ Mark Weber's fork is here (discussed April 8 on haskell-cafe): http://mawercer.de/~publicrepos/shim/ Graham From dbueno at gmail.com Thu Apr 17 18:36:10 2008 From: dbueno at gmail.com (Denis Bueno) Date: Thu Apr 17 18:31:17 2008 Subject: [Haskell-cafe] Wrong Answer Computing Graph Dominators In-Reply-To: <4807C6AB.3050902@imageworks.com> References: <6dbd4d000804151759r2ca72957hae8cd60c91404e60@mail.gmail.com> <20080416183356.GA4362@zombie.inf.tu-dresden.de> <6dbd4d000804170832h1391db15ob84e61d4e8960170@mail.gmail.com> <6dbd4d000804171413h54c33f35sdb1c9554d4d4c9@mail.gmail.com> <4807C6AB.3050902@imageworks.com> Message-ID: <6dbd4d000804171536n1fe95a23v11e4cd28810a80d7@mail.gmail.com> On Thu, Apr 17, 2008 at 5:52 PM, Dan Weston wrote: > Your reasoning differs from the usual understanding of a null product (1 or > True), as compared to a null sum (0 or False): > > > > the list of nodes for which > > *any path* from source to x must touch, i.e., the list of dominators > > of x. > > Here, "any path" means all paths, a logical conjunction: I'm not sure I agree this is the common definition of dominators, but supposing it is: the upshot is that to get what I expect, I should only ask for the dominators of nodes which I know are reachable from the source node, right? -- Denis From westondan at imageworks.com Thu Apr 17 19:11:33 2008 From: westondan at imageworks.com (Dan Weston) Date: Thu Apr 17 19:06:41 2008 Subject: [Haskell-cafe] Wrong Answer Computing Graph Dominators In-Reply-To: <6dbd4d000804171536n1fe95a23v11e4cd28810a80d7@mail.gmail.com> References: <6dbd4d000804151759r2ca72957hae8cd60c91404e60@mail.gmail.com> <20080416183356.GA4362@zombie.inf.tu-dresden.de> <6dbd4d000804170832h1391db15ob84e61d4e8960170@mail.gmail.com> <6dbd4d000804171413h54c33f35sdb1c9554d4d4c9@mail.gmail.com> <4807C6AB.3050902@imageworks.com> <6dbd4d000804171536n1fe95a23v11e4cd28810a80d7@mail.gmail.com> Message-ID: <4807D925.1010905@imageworks.com> > I'm not sure I agree this is the common definition of dominators Is one undefeated if one has never fought? > I should only ask for the dominators of nodes which I know are > reachable from the source node, right? Yes. Denis Bueno wrote: > On Thu, Apr 17, 2008 at 5:52 PM, Dan Weston wrote: >> Your reasoning differs from the usual understanding of a null product (1 or >> True), as compared to a null sum (0 or False): >> >> >> > the list of nodes for which >> > *any path* from source to x must touch, i.e., the list of dominators >> > of x. >> >> Here, "any path" means all paths, a logical conjunction: > > I'm not sure I agree this is the common definition of dominators, but > supposing it is: the upshot is that to get what I expect, I should > only ask for the dominators of nodes which I know are reachable from > the source node, right? > From claus.reinke at talk21.com Thu Apr 17 20:00:40 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Apr 17 19:55:52 2008 Subject: [Haskell-cafe] looking for examples of non-full FunctionalDependencies References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu><4806E8DA.9070503@gmail.com><5ab17e790804171009l6d974cf2va38cbd94dccf3303@mail.gmail.com><48078851.1050201@gmail.com> <5ab17e790804171113i647ff98ftde208ca753f88f0d@mail.gmail.com> Message-ID: <020d01c8a0e7$3edfe810$62398351@cr3lt> > Sorry to be picky but there is no violation of the FD here. Note that > the class D has only a single ground instance and to violate an FD you > need at least two. perhaps you are thinking of functional dependencies as being defined extensionally, over the extent of the type relations specified by multiparameter type classes? somewhat counterintuitively, this isn't quite the case (just as instance selection doesn't take contexts into account..). to get an FD conflict, it is sufficient to have two conflicting constraints, no need for any instances. consider module Fail(Fail) where class X a class X a => Fail a module Main where import Fail class C a b | a -> b instance Fail a => C [a] Bool since superclass X has no instances and is not exported from module Fail, class Fail, though exported, can have no instances. so the instance declaration given for C seems entirely useless, as far as the relation over types is concerned - there are no ground instances of C. nevertheless, it is taken into account when considering functional dependencies: Hugs: :t undefined :: C [a] b => (a,b) undefined :: C [a] Bool => (a,Bool) and so adding an instance for 'C [a] Char' would lead to an FD conflict. just checking, claus From john at repetae.net Thu Apr 17 20:25:20 2008 From: john at repetae.net (John Meacham) Date: Thu Apr 17 20:20:27 2008 Subject: [Haskell-cafe] compressed pointers? In-Reply-To: <87od8akx2b.fsf_-_@nmd9999.imr.no> References: <20080415120614.15389413.malcwallace@googlemail.com> <5ab17e790804151005y703c5d0dj50cf2f9b51cf1362@mail.gmail.com> <87y77eky3j.fsf@nmd9999.imr.no> <87tzi2kxwz.fsf@nmd9999.imr.no> <87od8akx2b.fsf_-_@nmd9999.imr.no> Message-ID: <20080418002520.GA17560@sliver.repetae.net> jhc packs data into pointers when possible. so for instance data Foo = Foo !Word16 !Word32 gets encoded as ------------------------------- | 16 bits | 32 bits | ... | 10| ------------------------------- This particularly helps strings, where the character can often be encoded in the space of the pointer itself. (even on 32 bit architecturs, as Char is only 24 bits in jhc) John -- John Meacham - ?repetae.net?john? From dekudekuplex at yahoo.com Thu Apr 17 22:58:16 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Thu Apr 17 22:53:23 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <200804171957.15648.valgarv@gmx.net> Message-ID: <818729.5162.qm@web30207.mail.mud.yahoo.com> Ariel, --- "Ariel J. Birnbaum" wrote: > > Common Misunderstandings - HaskellWiki > > > http://www.haskell.org/haskellwiki/Common_Misunderstandings > I didn't find this one... maybe it should be in a > more prominent place? > > > Things to avoid - HaskellWiki > > http://www.haskell.org/haskellwiki/Things_to_avoid > I thought of this but it has more discussions about > style than pitfalls... > it seems to me more oriented to people who know > Haskell well and want to > write better. > Maybe a link from here to the above would be a good > idea. Added: Things to avoid - HaskellWiki - 7 Related Links: http://www.haskell.org/haskellwiki/Things_to_avoid#Related_Links > Thanks for adding this case to the wiki =) My pleasure! Benjamin L. Russell From dekudekuplex at yahoo.com Thu Apr 17 23:32:47 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Thu Apr 17 23:27:56 2008 Subject: [Haskell-cafe] incompatibility issues in installing wxHaskell 0.10.3 with GHCi 6.8.2 on Windows XP Pro Message-ID: <423140.88277.qm@web30206.mail.mud.yahoo.com> Perhaps this is not the best mailing list for this issue, but since this problem involves a library for Haskell and is not a bug of GHC proper, I thought this would be a better place than the Glasgow-haskell-bugs mailing list.... I tried installing wxHaskell 0.10.3 with GHCi 6.8.2 already installed on Windows XP Professional Service Pack 2, but every time I run the wxhaskell-register.bat script to install the library, the following error message appears (I am installing on the Japanese version of Windows XP at work, so some of the error messages are in Japanese, which I shall translate accordingly below): ----- error message begins immediately after this line ----- 1 ?????t?@?C?????R?s?[?????????B ?R?}???h???\?????????????????B ?R?}???h???\?????????????????B - register packages Reading package info from "C:\\Documents and Settings\\Benjamin\\My Documents\\H askell\\Libraries\\wxHaskell\\wxhaskell-0.10.3\\bin\\wxcore.pkg" ... done. WARNING: unversioned dependencies are deprecated, and will NOT be accepted by GH C 6.10: base haskell98 ghc-pkg: C:\Documents doesn't exist or isn't a directory (use --force to overrid e) Reading package info from "C:\\Documents and Settings\\Benjamin\\My Documents\\H askell\\Libraries\\wxHaskell\\wxhaskell-0.10.3\\bin\\wx.pkg" ... done. ghc-pkg: dependency wxcore-0.10.3 doesn't exist (use --force to override) error: Unable to register the package using "ghc-pkg". Maybe you have an incompatible version of ghc installed? ???s?????????????L?[???????????????? . . . ----- error message ends immediately before this line ----- The first paragraph above means the following: " 1 file copied. Syntax error in command. Syntax error in command." The final line above means the following: "Press any key to continue...." However, there do not seem to be any errors in my unmodified wxhaskell-register.bat file, quoted below: ----- text of wxhaskell-register.bat file begins immediately after this line ----- @SET wxclibname=wxc-msw2.6.4-0.10.3 @SET generate=yes @ECHO OFF IF "%1"=="" GOTO noarg IF "%1"=="--help" GOTO help IF "%1"=="-?" GOTO help IF "%1"=="/?" GOTO help GOTO installarg :installarg SET installdir=%1 GOTO check :noarg COPY /B /Y setcd setcd.bat CD .. CD >> bin\setcd.bat CD bin CALL setcd.bat DEL setcd.bat SET installdir=%CURDIR% GOTO check :check IF "%generate%"=="yes" GOTO generate GOTO checkfile :generate IF NOT EXIST %installdir%\bin\wx-partial.pkg GOTO notfound COPY /Y %installdir%\bin\wx-partial.pkg %installdir%\bin\wx.pkg ECHO import-dirs:%installdir%\lib\imports >> %installdir%\bin\wx.pkg ECHO library-dirs:%installdir%\lib >> %installdir%\bin\wx.pkg COPY /Y %installdir%\bin\wxcore-partial.pkg %installdir%\bin\wxcore.pkg ECHO import-dirs:%installdir%\lib\imports >> %installdir%\bin\wxcore.pkg ECHO library-dirs:%installdir%\lib >> %installdir%\bin\wxcore.pkg GOTO checkfile :checkfile IF NOT EXIST "%installdir%\bin\wx.pkg" GOTO notfound :install ECHO - register packages SET wxhlibdir=%installdir%\lib ghc-pkg update "%installdir%\bin\wxcore.pkg" ghc-pkg update "%installdir%\bin\wx.pkg" IF ERRORLEVEL 1 GOTO regerror ECHO. IF "%OS%"=="Windows_NT" GOTO copyNT ECHO - copy %wxclibname%.dll to the windows system directory (%WINDIR%\system) COPY %installdir%\lib\%wxclibname%.dll %WINDIR%\system\%wxclibname%.dll GOTO checkcopy :copyNT ECHO - copy %wxclibname%.dll to the windows system directory (%WINDIR%\system32) COPY %installdir%\lib\%wxclibname%.dll %WINDIR%\system32\%wxclibname%.dll :checkcopy IF ERRORLEVEL 1 GOTO copyerror ECHO - done! GOTO end :regerror ECHO error: ECHO Unable to register the package using "ghc-pkg". ECHO Maybe you have an incompatible version of ghc installed? ECHO. goto end :copyerror ECHO error: ECHO Unable to copy dynamic link libraries to the system folder. ECHO This is not a real problem but you will have to add the wxHaskell ECHO library directory to your PATH environment variable. ECHO. ECHO The library directory is: %installdir%\lib ECHO. goto end :notfound ECHO error: ECHO Unable to find the wxHaskell packages (bin\wx.pkg) ECHO Maybe the installation directory is not properly specified? ECHO. GOTO help :help ECHO usage: ECHO wxhaskell-register [installdir] ECHO. ECHO (or just double click on the batch file from the explorer) ECHO. GOTO end :end PAUSE ----- text of wxhaskell-register.bat file ends immediately before this line ----- Any ideas? Has anybody else encountered this bug? Benjamin L. Russell From dekudekuplex at yahoo.com Fri Apr 18 00:45:57 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Fri Apr 18 00:41:04 2008 Subject: [Haskell-cafe] incompatibility issues in installing wxHaskell 0.10.3 with GHCi 6.8.2 on Windows XP Pro In-Reply-To: <423140.88277.qm@web30206.mail.mud.yahoo.com> Message-ID: <52339.39854.qm@web30205.mail.mud.yahoo.com> I just solved the problem by myself: It was a problem with paths including spaces. Originally, I had installed wxhaskell-register.bat in the following directory: C:\Documents and Settings\Benjamin\My Documents\Haskell\Libraries\wxHaskell\wxhaskell-0.10.3\bin However, the directory "Documents and Settings" includes two spaces, and "My Documents" includes a space as well. Therefore, I moved the wxhaskell-0.10.3 directory to the C:\ top-level directory, thus creating a path without spaces; viz: C:\wxhaskell-0.10.3\bin Running wxhaskell-register.bat there caused it to run successfully (some of the returned messages are in Japanese, which I shall translate accordingly below): ----- installation messages begin immediately after this line ----- 1 個のファイルをコピーしました。 1 個のファイルをコピーしました。 1 個のファイルをコピーしました。 - register packages Reading package info from "C:\\wxhaskell-0.10.3\\bin\\wxcore.pkg" ... done. WARNING: unversioned dependencies are deprecated, and will NOT be accepted by GH C 6.10: base haskell98 Saving old package config file... done. Writing new package config file... done. Reading package info from "C:\\wxhaskell-0.10.3\\bin\\wx.pkg" ... done. Saving old package config file... done. Writing new package config file... done. - copy wxc-msw2.6.4-0.10.3.dll to the windows system directory (C:\WINDOWS\syste m32) 1 個のファイルをコピーしました。 - done! 続行するには何かキーを押してください . . . ----- installation messages end immediately before this line ----- The first three messages above mean the following: "1 file copied. 1 file copied. 1 file copied." The last two messages above mean the following: "1 file copied. Press any key to continue...." ( I wish that the error messages had been more helpful, though; "Documents and Settings" is a standard location for many settings in Windows XP, and the previous error message "Maybe you have an incompatible version of ghc installed?" had not been very informative. Also, there are no instructions on the "wxHaskell - Download" page (http://wxhaskell.sourceforge.net/download.html) to run the installation batch file in a directory with no spaces in the path. It seems designed by someone who never steps outside the world of Linux/UNIX/*NIX (nothing against UNIX here; I use Mac OS X, which is a UNIX-based OS, at home myself, but if they are going to provide an automated Windows installer, they should at least explain how to use it from the standpoint of a user used to working in that environment....). ) Benjamin L. Russell --- "Benjamin L. Russell" wrote: > Perhaps this is not the best mailing list for this > issue, but since this problem involves a library for > Haskell and is not a bug of GHC proper, I thought > this > would be a better place than the > Glasgow-haskell-bugs > mailing list.... > > I tried installing wxHaskell 0.10.3 with GHCi 6.8.2 > already installed on Windows XP Professional Service > Pack 2, but every time I run the > wxhaskell-register.bat script to install the > library, > the following error message appears (I am installing > on the Japanese version of Windows XP at work, so > some > of the error messages are in Japanese, which I shall > translate accordingly below): > > ----- error message begins immediately after this > line > ----- > 1 ?????t?@?C?????R?s?[?????????B > ?R?}???h???\?????????????????B > ?R?}???h???\?????????????????B > - register packages > Reading package info from "C:\\Documents and > Settings\\Benjamin\\My Documents\\H > askell\\Libraries\\wxHaskell\\wxhaskell-0.10.3\\bin\\wxcore.pkg" > ... done. > WARNING: unversioned dependencies are deprecated, > and > will NOT be accepted by GH > C 6.10: base haskell98 > ghc-pkg: C:\Documents doesn't exist or isn't a > directory (use --force to overrid > e) > Reading package info from "C:\\Documents and > Settings\\Benjamin\\My Documents\\H > askell\\Libraries\\wxHaskell\\wxhaskell-0.10.3\\bin\\wx.pkg" > ... done. > ghc-pkg: dependency wxcore-0.10.3 doesn't exist (use > --force to override) > error: > Unable to register the package using "ghc-pkg". > Maybe you have an incompatible version of ghc > installed? > > ???s?????????????L?[???????????????? . . . > ----- error message ends immediately before this > line > ----- > > The first paragraph above means the following: > > " 1 file copied. > Syntax error in command. > Syntax error in command." > > The final line above means the following: > > "Press any key to continue...." > > However, there do not seem to be any errors in my > unmodified wxhaskell-register.bat file, quoted > below: > > ----- text of wxhaskell-register.bat file begins > immediately after this line ----- > @SET wxclibname=wxc-msw2.6.4-0.10.3 > @SET generate=yes > @ECHO OFF > > IF "%1"=="" GOTO noarg > IF "%1"=="--help" GOTO help > IF "%1"=="-?" GOTO help > IF "%1"=="/?" GOTO help > GOTO installarg > > :installarg > SET installdir=%1 > GOTO check > > :noarg > COPY /B /Y setcd setcd.bat > CD .. > CD >> bin\setcd.bat > CD bin > CALL setcd.bat > DEL setcd.bat > SET installdir=%CURDIR% > GOTO check > > :check > IF "%generate%"=="yes" GOTO generate > GOTO checkfile > > :generate > IF NOT EXIST %installdir%\bin\wx-partial.pkg GOTO > notfound > COPY /Y %installdir%\bin\wx-partial.pkg > %installdir%\bin\wx.pkg > ECHO import-dirs:%installdir%\lib\imports >> > %installdir%\bin\wx.pkg > ECHO library-dirs:%installdir%\lib >> > %installdir%\bin\wx.pkg > COPY /Y %installdir%\bin\wxcore-partial.pkg > %installdir%\bin\wxcore.pkg > ECHO import-dirs:%installdir%\lib\imports >> > %installdir%\bin\wxcore.pkg > ECHO library-dirs:%installdir%\lib >> > %installdir%\bin\wxcore.pkg > GOTO checkfile > > :checkfile > IF NOT EXIST "%installdir%\bin\wx.pkg" GOTO notfound > > :install > ECHO - register packages > SET wxhlibdir=%installdir%\lib > ghc-pkg update "%installdir%\bin\wxcore.pkg" > ghc-pkg update "%installdir%\bin\wx.pkg" > > IF ERRORLEVEL 1 GOTO regerror > > ECHO. > IF "%OS%"=="Windows_NT" GOTO copyNT > ECHO - copy %wxclibname%.dll to the windows system > directory (%WINDIR%\system) > COPY %installdir%\lib\%wxclibname%.dll > %WINDIR%\system\%wxclibname%.dll > GOTO checkcopy > > :copyNT > ECHO - copy %wxclibname%.dll to the windows system > directory (%WINDIR%\system32) > COPY %installdir%\lib\%wxclibname%.dll > %WINDIR%\system32\%wxclibname%.dll > > :checkcopy > IF ERRORLEVEL 1 GOTO copyerror > > ECHO - done! > GOTO end > > :regerror > ECHO error: > ECHO Unable to register the package using > "ghc-pkg". > > ECHO Maybe you have an incompatible version of ghc > installed? > ECHO. > goto end > > :copyerror > ECHO error: > ECHO Unable to copy dynamic link libraries to the > system folder. > ECHO This is not a real problem but you will have > to > add the wxHaskell > ECHO library directory to your PATH environment > variable. > ECHO. > ECHO The library directory is: %installdir%\lib > ECHO. > goto end > > :notfound > ECHO error: > ECHO Unable to find the wxHaskell packages > (bin\wx.pkg) > ECHO Maybe the installation directory is not > properly specified? > ECHO. > GOTO help > > :help > ECHO usage: > ECHO wxhaskell-register [installdir] > ECHO. > ECHO (or just double click on the batch file from > the > explorer) > ECHO. > GOTO end > > :end > PAUSE > ----- text of wxhaskell-register.bat file ends > immediately before this line ----- > > Any ideas? Has anybody else encountered this bug? > > Benjamin L. Russell > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > === message truncated === From a.biurvOir4 at asuhan.com Fri Apr 18 01:04:42 2008 From: a.biurvOir4 at asuhan.com (Kim-Ee Yeoh) Date: Fri Apr 18 00:59:49 2008 Subject: [Haskell-cafe] Wrong Answer Computing Graph Dominators In-Reply-To: <4807C6AB.3050902@imageworks.com> References: <6dbd4d000804151759r2ca72957hae8cd60c91404e60@mail.gmail.com> <20080416183356.GA4362@zombie.inf.tu-dresden.de> <6dbd4d000804170832h1391db15ob84e61d4e8960170@mail.gmail.com> <6dbd4d000804171413h54c33f35sdb1c9554d4d4c9@mail.gmail.com> <4807C6AB.3050902@imageworks.com> Message-ID: <16760156.post@talk.nabble.com> Dan Weston wrote: > > Here, "any path" means all paths, a logical conjunction: > > and [True, True] = True > and [True ] = True > and [ ] = True > Hate to nitpick, but what appears to be some kind of a limit in the opposite direction is a curious way of arguing that: and [] = True. Surely one can also write and [False, False] = False and [False ] = False and [ ] = False ??? -- Kim-Ee -- View this message in context: http://www.nabble.com/Wrong-Answer-Computing-Graph-Dominators-tp16714477p16760156.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From haskell at brecknell.org Fri Apr 18 01:40:38 2008 From: haskell at brecknell.org (Matthew Brecknell) Date: Fri Apr 18 01:35:44 2008 Subject: [Haskell-cafe] Wrong Answer Computing Graph Dominators In-Reply-To: <16760156.post@talk.nabble.com> References: <6dbd4d000804151759r2ca72957hae8cd60c91404e60@mail.gmail.com> <20080416183356.GA4362@zombie.inf.tu-dresden.de> <6dbd4d000804170832h1391db15ob84e61d4e8960170@mail.gmail.com> <6dbd4d000804171413h54c33f35sdb1c9554d4d4c9@mail.gmail.com> <4807C6AB.3050902@imageworks.com> <16760156.post@talk.nabble.com> Message-ID: <1208497238.30072.1248551899@webmail.messagingengine.com> Dan Weston wrote: > Here, "any path" means all paths, a logical conjunction: > > and [True, True] = True > and [True ] = True > and [ ] = True Kim-Ee Yeoh wrote: > Hate to nitpick, but what appears to be some kind of a > limit in the opposite direction is a curious way of arguing > that: and [] = True. > > Surely one can also write > > and [False, False] = False > and [False ] = False > and [ ] = False ??? No. I think what Dan meant was that for all non-null xs :: [Bool], it is clearly true that: and (True:xs) == and xs -- (1) It therefore makes sense to define (1) to hold also for empty lists, and since it is also true that: and (True:[]) == True We obtain: and [] == True Since we can't make any similar claim about the conjuctions of lists beginning with False, there is no reasonable argument to the contrary. From ketil at malde.org Fri Apr 18 02:44:53 2008 From: ketil at malde.org (Ketil Malde) Date: Fri Apr 18 02:39:51 2008 Subject: [Haskell-cafe] compressed pointers? In-Reply-To: <20080416145934.GB12207@scytale.galois.com> (Don Stewart's message of "Wed\, 16 Apr 2008 07\:59\:34 -0700") References: <20080415120614.15389413.malcwallace@googlemail.com> <5ab17e790804151005y703c5d0dj50cf2f9b51cf1362@mail.gmail.com> <87y77eky3j.fsf@nmd9999.imr.no> <87tzi2kxwz.fsf@nmd9999.imr.no> <87od8akx2b.fsf_-_@nmd9999.imr.no> <20080416145934.GB12207@scytale.galois.com> Message-ID: <87bq47ek62.fsf@nmd9999.imr.no> Don Stewart writes: > One small upside (performance wise), is that the bottom 3 bits of the > pointer are now used to encode the constructor on 64 bits, so 'case' gets a > good percent cheaper. Well - my experience (which is from before this optimization was added, I think) is that 64bit Haskell is slower than 32bit Haskell. Anyway, I think this is an orthogonal issue - by limiting your program to 4GB RAM, 4-byte alignment could give you two bits for pointer tagging and 32 bit pointers. If you still do 8-byte alignment, there's no difference. In extremis, you could imagine several different models based on heap size, with optimal choices for pointer size, alignment and tag bits. If you shift the pointer, you could address up to 16G from 32 bits (by using 8-byte alignment and one tag bit). This probably becomes too complicated, but I thought it was interesting that the Java people are making use of 32bit pointers on a 64bit system, and are seeing a good performance benefit from it. -k -- If I haven't seen further, it is by standing in the footprints of giants From valgarv at gmx.net Fri Apr 18 03:00:24 2008 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Fri Apr 18 02:55:33 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <818729.5162.qm@web30207.mail.mud.yahoo.com> References: <818729.5162.qm@web30207.mail.mud.yahoo.com> Message-ID: <200804181000.24928.valgarv@gmx.net> > Things to avoid - HaskellWiki - 7 Related Links: > http://www.haskell.org/haskellwiki/Things_to_avoid#Related_Links The link was broken (it had an extra chunk of '- Haskell Wiki' ;) ) so I fixed it. For that matter, the "Common Hugs Messages" link is broken too but I can't seem to find the page it should point to. -- Ariel J. Birnbaum From dekudekuplex at yahoo.com Fri Apr 18 03:54:56 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Fri Apr 18 03:50:03 2008 Subject: [Haskell-cafe] Re: Embedding newlines into a string? In-Reply-To: <200804181000.24928.valgarv@gmx.net> Message-ID: <753431.92487.qm@web30208.mail.mud.yahoo.com> Ariel, --- "Ariel J. Birnbaum" wrote: > > Things to avoid - HaskellWiki - 7 Related Links: > > > http://www.haskell.org/haskellwiki/Things_to_avoid#Related_Links > The link was broken (it had an extra chunk of '- > Haskell Wiki' ;) ) > so I fixed it. Thank you; sorry about the broken link. > For that matter, the "Common Hugs > Messages" link is > broken too but I can't seem to find the page it > should point to. I just fixed it. It was supposed to be an external link to the following Web page: Some common Hugs error messages http://www.cs.kent.ac.uk/people/staff/sjt/craft2e/errors/allErrors.html I discovered that link originally under the following subsection of HaskellWiki: Learning Haskell - 2 Material - 2.9 Reference http://www.haskell.org/haskellwiki/Learning_Haskell#Reference This time, I have checked my updated link to verify that it works. ;-) Benjamin L. Russell From martin.sulzmann at gmail.com Fri Apr 18 04:26:55 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Fri Apr 18 04:22:11 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> Message-ID: <48085B4F.3000007@gmail.com> Lennart Augustsson wrote: > To reuse a favorite word, I think that any implementation that > distinguishes 'a -> b, a -> c' from 'a -> b c' is broken. :) > It does not implement FD, but something else. Maybe this something > else is useful, but if one of the forms is strictly more powerful than > the other then I don't see why you would ever want the less powerful one. > Do you have any good examples, besides the contrived one class D a b c | a -> b c instance D a b b => D [a] [b] [b] where we want to have the more powerful form of multi-range FDs? Fixing the problem who mention is easy. After all, we know how to derive improvement for multi-range FDs. But it seems harder to find agreement whether multi-range FDs are short-hands for single-range FDs, or certain single-range FDs, eg a -> b and a -> c, are shorthands for more powerful multi-range FDs a -> b c. I clearly prefer the latter, ie have a more powerful form of FDs. Martin From duncan.coutts at worc.ox.ac.uk Fri Apr 18 05:43:24 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 18 05:38:31 2008 Subject: [Haskell-cafe] Hackage being too strict? In-Reply-To: References: Message-ID: <1208511804.5960.14.camel@dell.linuxdev.us.dell.com> On Tue, 2008-04-15 at 22:15 -0500, John Goerzen wrote: > When I went to make my upload of MissingH 1.0.1, Hackage rejected it, > saying: > > Instead of 'ghc-options: -XPatternSignatures' use 'extensions: PatternSignatures' > > It hadn't rejected MissingH 1.0.0, even though it had the same thing. I added loads of extra checks recently. > Now, my .cabal file has this: > > -- Hack because ghc-6.6 and the Cabal the comes with ghc-6.8.1 > -- does not understand the PatternSignatures extension. > -- The Cabal that comes with ghc-6.8.2 does understand it, so > -- this hack can be dropped if we require Cabal-Version: >=1.2.3 > If impl(ghc >= 6.8) > GHC-Options: -XPatternSignatures > > which was contributed by Duncan Coutts. :-) > It seems arbitrary that Hackage would suddenly reject this valid > usage. Yes it is valid though I hope you can see the general intention of the suggestion. If it were not for the compatibility problem it would be preferable to use: iIf impl(ghc >= 6.8) extensions: PatternSignatures or just unconditionally if that makes sense: extensions: PatternSignatures because it encourages packages to declare what the need in a way that is not compiler-specific (which was one of the aims of Cabal in the first place). > Thoughts? Mmm. So the problem is that previously the .cabal parser was pretty unhelpful when it came to forwards compatibility. For example for the Extension enumeration type it was just using the Read instance which meant that it would fail with a parse error for any new extensions. That's the real source of the problem, that the parser allows no forwards compatibility so when new extensions are added, older Cabal versions will fail with a parse error. I have now fixed that by eliminating the use of Read in the .cabal parser and basically adding an Other/Unknown constructor to several of the enumeration types, including Extension. So as of Cabal-1.4 it will be possible to add new extensions in later Cabal versions that are not in Cabal-1.4 without Cabal-1.4 falling over with a parse error. Indeed, if the compiler knows about the extension then it will actually work. The only restriction is that unknown extensions cannot be used in packages uploaded to hackage, which is pretty reasonable I think. If an extension is going to be used in widely distributed packages then that extension should be registered in Language.Haskell.Extension. It's trivial to add and update hackage to recognise it. So that obviously does not solve the problem that Cabal-1.2 and older are not very good with forwards compat in the parser. The solution is probably just to downgrade that check to a warning rather than outright rejection (or possibly limit the check to extensions that existed in older Cabal versions). We can make it stricter again in the future when Cabal-1.4+ is much more widely deployed. Sound ok? Duncan From duncan.coutts at worc.ox.ac.uk Fri Apr 18 05:53:54 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 18 05:49:03 2008 Subject: [Haskell-cafe] GC'ing file handles and other resources In-Reply-To: <3c4d5adf0804152230x25abc55cg36480c52a2097b47@mail.gmail.com> References: <3c4d5adf0804152230x25abc55cg36480c52a2097b47@mail.gmail.com> Message-ID: <1208512434.5960.23.camel@dell.linuxdev.us.dell.com> On Wed, 2008-04-16 at 11:00 +0530, Abhay Parvate wrote: > Your mail gives me an idea, though I am not an iota familiar with > compiler/garbage collector internals. Can we have some sort of > internally maintained priority associated with allocated objects? The > garbage collector should look at these objects first when it tries to > free anything. The objects which hold other system resources apart > from memory, such as file handles, video memory, and so on could be > allocated as higher priority objects. Is such a thing possible? The way I have imagined this when I've faced Conal's problem in the past (again to do with graphics libs and large foreign allocated bitmaps) is to assign an optional heap memory equivalent cost to ForeignPtrs. Basically the idea is to take the foreign memory allocations into account when considering heap pressure. At the moment a ForeignPtr only counts for about 10 words of heap pressure when of course it can represent hundreds of kilobytes. So by assigning a cost we can take that into account with the normal decisions about when to do a minor and major GC. We should be able to treat a ForeignPtr to foreign allocated memory in just the same way as a ForeignPtr to heap allocated memory in terms of timing/frequency of GC behaviour. Of course it doesn't help with all resources since not all are equivalent to memory, eg the arbitrary limits some OSs impose on the number of open file handles. Duncan From bulat.ziganshin at gmail.com Fri Apr 18 05:59:51 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Apr 18 06:05:05 2008 Subject: [Haskell-cafe] Hackage being too strict? In-Reply-To: <1208511804.5960.14.camel@dell.linuxdev.us.dell.com> References: <1208511804.5960.14.camel@dell.linuxdev.us.dell.com> Message-ID: <128380937.20080418135951@gmail.com> Hello Duncan, Friday, April 18, 2008, 1:43:24 PM, you wrote: > older Cabal versions). We can make it stricter again in the future when > Cabal-1.4+ is much more widely deployed. the problem, imho, is that such tools as Cabal, GHC, Hackage should be built with forward and backward compatibility in mind. otherwise, Haskell will still remain mostly a hacker tool -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Fri Apr 18 06:18:14 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 18 06:13:20 2008 Subject: [Haskell-cafe] Hackage being too strict? In-Reply-To: <128380937.20080418135951@gmail.com> References: <1208511804.5960.14.camel@dell.linuxdev.us.dell.com> <128380937.20080418135951@gmail.com> Message-ID: <1208513894.5960.30.camel@dell.linuxdev.us.dell.com> On Fri, 2008-04-18 at 13:59 +0400, Bulat Ziganshin wrote: > Hello Duncan, > > Friday, April 18, 2008, 1:43:24 PM, you wrote: > > > older Cabal versions). We can make it stricter again in the future when > > Cabal-1.4+ is much more widely deployed. > > the problem, imho, is that such tools as Cabal, GHC, Hackage should be > built with forward and backward compatibility in mind. otherwise, > Haskell will still remain mostly a hacker tool Yes! Yes you're absolutely right, that's why I've been fixing it :-) Duncan From bulat.ziganshin at gmail.com Fri Apr 18 07:46:37 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Apr 18 07:44:14 2008 Subject: [Haskell-cafe] compressed pointers? In-Reply-To: <87bq47ek62.fsf@nmd9999.imr.no> References: <20080415120614.15389413.malcwallace@googlemail.com> <5ab17e790804151005y703c5d0dj50cf2f9b51cf1362@mail.gmail.com> <87y77eky3j.fsf@nmd9999.imr.no> <87tzi2kxwz.fsf@nmd9999.imr.no> <87od8akx2b.fsf_-_@nmd9999.imr.no> <20080416145934.GB12207@scytale.galois.com> <87bq47ek62.fsf@nmd9999.imr.no> Message-ID: <1376368623.20080418154637@gmail.com> Hello Ketil, Friday, April 18, 2008, 10:44:53 AM, you wrote: > This probably becomes too complicated, but I thought it was > interesting that the Java people are making use of 32bit pointers on a > 64bit system, and are seeing a good performance benefit from it. afaik, C compilers support this model too, so it shouldn't too hard to compile GHC in such mode. it's a bit like small/large memory models of those 16-bit x86 systems :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From haskell at list.mightyreason.com Fri Apr 18 07:52:07 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Fri Apr 18 07:47:32 2008 Subject: [Haskell-cafe] Re: Wrong Answer Computing Graph Dominators In-Reply-To: <1208497238.30072.1248551899@webmail.messagingengine.com> References: <6dbd4d000804151759r2ca72957hae8cd60c91404e60@mail.gmail.com> <20080416183356.GA4362@zombie.inf.tu-dresden.de> <6dbd4d000804170832h1391db15ob84e61d4e8960170@mail.gmail.com> <6dbd4d000804171413h54c33f35sdb1c9554d4d4c9@mail.gmail.com> <4807C6AB.3050902@imageworks.com> <16760156.post@talk.nabble.com> <1208497238.30072.1248551899@webmail.messagingengine.com> Message-ID: More algebraically, including 'or' for symmtry: and xs = foldr (&&) True xs or xs = foldr (||) False xs The True and False are the (monoid) identities with respect to && and || : True && x == x x && True == x False || x == x x || False == x And so an empty list, if defined at all, should be the identity: and [] = True or [] = False In english: "and returns false" when "is any element of the list false?" is yes "or returns true" when "is any element of the list true?" is yes Matthew Brecknell wrote: > Dan Weston wrote: >> Here, "any path" means all paths, a logical conjunction: >> >> and [True, True] = True >> and [True ] = True >> and [ ] = True > > Kim-Ee Yeoh wrote: >> Hate to nitpick, but what appears to be some kind of a >> limit in the opposite direction is a curious way of arguing >> that: and [] = True. >> >> Surely one can also write >> >> and [False, False] = False >> and [False ] = False >> and [ ] = False ??? > > No. I think what Dan meant was that for all non-null > xs :: [Bool], it is clearly true that: > > and (True:xs) == and xs -- (1) > > It therefore makes sense to define (1) to hold also > for empty lists, and since it is also true that: > > and (True:[]) == True > > We obtain: > > and [] == True > > Since we can't make any similar claim about the > conjuctions of lists beginning with False, there > is no reasonable argument to the contrary. From john at repetae.net Fri Apr 18 08:13:51 2008 From: john at repetae.net (John Meacham) Date: Fri Apr 18 08:08:56 2008 Subject: [Haskell-cafe] Hackage being too strict? In-Reply-To: <1208511804.5960.14.camel@dell.linuxdev.us.dell.com> References: <1208511804.5960.14.camel@dell.linuxdev.us.dell.com> Message-ID: <20080418121351.GJ17560@sliver.repetae.net> On Fri, Apr 18, 2008 at 10:43:24AM +0100, Duncan Coutts wrote: > I have now fixed that by eliminating the use of Read in the .cabal > parser and basically adding an Other/Unknown constructor to several of > the enumeration types, including Extension. So as of Cabal-1.4 it will > be possible to add new extensions in later Cabal versions that are not > in Cabal-1.4 without Cabal-1.4 falling over with a parse error. Indeed, > if the compiler knows about the extension then it will actually work. > The only restriction is that unknown extensions cannot be used in > packages uploaded to hackage, which is pretty reasonable I think. If an > extension is going to be used in widely distributed packages then that > extension should be registered in Language.Haskell.Extension. It's > trivial to add and update hackage to recognise it. And then have everyone have to upgrade their cabal? It should just be > newtype Extension = Extension String it would simplify a lot of code, be more forwards and backwards proof, and remove oddness like do 'Other "PatternGuards"' and 'PatternGuards' mean the same thing? In order to be both backwards and forwards compatable, everyone writing haskell code that links against cabal and cares about extensions will have to have special code treating both the same, and in fact, conditionally compile part of it, since 'PatternGuards' might not even be valid in some old version of cabal. (replace PatternGuards with some other soon to be standardized extension) Normalized data types are a good thing. A centralized registry of things hackage recognizes is fine, but it shouldn't be cluttering up the source code. John -- John Meacham - ?repetae.net?john? From jgoerzen at complete.org Fri Apr 18 09:05:12 2008 From: jgoerzen at complete.org (John Goerzen) Date: Fri Apr 18 09:00:18 2008 Subject: [Haskell-cafe] Hackage being too strict? In-Reply-To: <1208511804.5960.14.camel@dell.linuxdev.us.dell.com> References: <1208511804.5960.14.camel@dell.linuxdev.us.dell.com> Message-ID: <200804180805.12793.jgoerzen@complete.org> On Fri April 18 2008 4:43:24 am Duncan Coutts wrote: > > It seems arbitrary that Hackage would suddenly reject this valid > > usage. > > Yes it is valid though I hope you can see the general intention of the > suggestion. If it were not for the compatibility problem it would be > preferable to use: Sure, I do. It's a good point. But I think there are a couple of issues here: 1) Hackage is rejecting things that Cabal accepts without trouble 2) The behavior of Hackage is unpredictable in what it will accept and what it will reject 3) The behavior of Hackage changes rapidly It's been quite frustrating lately as many of my packages that used to upload fine still build fine but get rejected at upload time. I think that Hackage is the wrong place for these checks. This stuff should go in Cabal, and ./setup configure should print a big DEPRECATION WARNING for a major release before the stuff gets yanked. > I have now fixed that by eliminating the use of Read in the .cabal > parser and basically adding an Other/Unknown constructor to several of > the enumeration types, including Extension. So as of Cabal-1.4 it will > be possible to add new extensions in later Cabal versions that are not > in Cabal-1.4 without Cabal-1.4 falling over with a parse error. Indeed, That's great news. > if the compiler knows about the extension then it will actually work. > The only restriction is that unknown extensions cannot be used in > packages uploaded to hackage, which is pretty reasonable I think. If an > extension is going to be used in widely distributed packages then that > extension should be registered in Language.Haskell.Extension. It's > trivial to add and update hackage to recognise it. That makes sense. > So that obviously does not solve the problem that Cabal-1.2 and older > are not very good with forwards compat in the parser. The solution is > probably just to downgrade that check to a warning rather than outright > rejection (or possibly limit the check to extensions that existed in > older Cabal versions). We can make it stricter again in the future when > Cabal-1.4+ is much more widely deployed. > > Sound ok? Yes, that makes a lot of sense, too. Can cabal-put be tweaked to make sure to output that warning by default? -- John From alfonso.acosta at gmail.com Fri Apr 18 09:33:19 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Fri Apr 18 09:28:48 2008 Subject: [Haskell-cafe] C++ interface with Haskell In-Reply-To: <7981f6330804170941r3e19a0d0v93ae0d0d05c33d12@mail.gmail.com> References: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> <4806A4F6.4090404@charter.net> <7981f6330804170941r3e19a0d0v93ae0d0d05c33d12@mail.gmail.com> Message-ID: <6a7c66fc0804180633l1bfe91ccrcbc7148ba8ae91cf@mail.gmail.com> Although you could use gcc to link the code I wouldn't recommend it (mainly for the problems you are currently having) SImply call GHC to compile both the C and Haskell code. It will take care of finding the headers and supplying the necessary linker arguments. ghc -ffi -c foo.hs myfoo_c.c BTW, you don't need to compile viaC 2008/4/17 Miguel Lordelo : > Well Isaac...I became now a little bit smarter then yesterday!!! > > I show you the example that I found and on which I?m working with. > > File: foo.hs > module Foo where > > foreign export ccall foo :: Int -> IO Int > > foo :: Int -> IO Int > foo n = return (length (f n)) > > f :: Int -> [Int] > f 0 = [] > f n = n:(f (n-1)) > > To get the C wrapper you insert the following command: > ghc -ffi -fvia-C -C foo.hs > > After execution you will have these following additional files: > > foo.hc > foo.hi > foo_stub.c > foo_stub.h > foo_stub.o > > What I did next was to create a file named: myfoo_c.c, where I will call the > foo function (implemented in Haskell). > (you can see this example on > http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html ) > But the problem is to compile with gcc (must I put any flag or whatever set > something) > > The gcc output is: > myfoo_c.c:2:19: error: HsFFI.h: No such file or directory > > I downloaded this header file from: (I know that is not the correct way, but > it was the only idea that occurs at the moment) > http://www.koders.com/c/fidD0593B84C41CA71319BB079EFD0A2C80211C9337.aspx > > I compiled again and the following return error appears: > myfoo_c.c:(.text+0x1c): undefined reference to `hs_init' > myfoo_c.c:(.text+0x31): undefined reference to `foo' > myfoo_c.c:(.text+0x50): undefined reference to `hs_exit' > collect2: ld returned 1 exit status > > These functions are necessary to setup GHC runtime (see: > http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html ) > > What I want to know is how to compile myfoo_c.c?! Is it with GCC or GHC?! > > Chears, > Miguel Lordelo. > > > > > On Wed, Apr 16, 2008 at 9:16 PM, Isaac Dupree > wrote: > > > perhaps > > > > haskell: > > foreign export "foo_func" foo :: Int -> IO Int > > -- I forget the rest of the syntax here > > > > C++: > > > > extern "C" { > > int foo_func(int i); > > } > > > > int some_cplusplus_function() { > > int bat = 3; > > int blah = foo_func(bat); > > return blah; > > } > > > > > > Is that all you need to do? > > > > > > Miguel Lordelo wrote: > > > > > > > > > > > > > > Hi all, > > > > > > Well...somehow I'm a beginner in Haskell. But actually my interest in > > > Haskell will increase if it is possible to call a haskell function in > C++. > > > Something like GreenCard ( http://www.haskell.org/greencard/ ) > simplifying > > > the task of interfacing Haskell programs to external libraries > (usually). > > > But is there also a task to interface a foreign language with Haskell, > but > > > calling Haskell functions. Or c2hs which is an interface generator that > > > simplifies the development of Haskell bindings to C libraries. > > > > > > I want to know this, because in my company some guys are doing some > testing > > > with Frotran and MatLab and I want to show them the power of haskell and > the > > > software which we are using is implemented in C++ (there is the reason > to > > > make Haskel -> C++). > > > > > > I read somewhere that the only way for C++ calling a haskell function is > to > > > create a binding between Haskell and C and from C to C++, but a easy > "Hello > > > World" example was not there. > > > Unfortunatelly I couldn't found anything usefull, like an complete > example, > > > or how to compile the code from haskell to C to C++. > > > > > > Can sombody help me, please :P > > > > > > Chears, > > > Miguel Lordelo. > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > _______________________________________________ > > > 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 > > From magr at cs.tu-berlin.de Fri Apr 18 09:35:04 2008 From: magr at cs.tu-berlin.de (Martin Grabmueller) Date: Fri Apr 18 09:32:23 2008 Subject: [Haskell-cafe] ANNOUNCE: cpuid 0.2 - Binding for the cpuid machine instruction Message-ID: <4808A388.2010202@cs.tu-berlin.de> Hello fellow Haskellers, I have just uploaded my new package cpuid to Hackage. Description: This module provides the function 'cpuid' for accessing information about the currently running IA-32 processor. Both a function for calling the 'cpuid' instruction directly, and some convenience functions for common uses are provided. This package is only portable to IA-32 machines. Home page: http://uebb.cs.tu-berlin.de/~magr/projects/cpuid/doc/ Hackage page: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cpuid-0.2 I'm looking forward to comments, improvements and bug fixes. I hope it's useful to you! Happy Haskell Hacking, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080418/2e02ec8a/signature.bin From miguellordelo at gmail.com Fri Apr 18 11:06:07 2008 From: miguellordelo at gmail.com (Miguel Lordelo) Date: Fri Apr 18 11:01:19 2008 Subject: [Haskell-cafe] C++ interface with Haskell In-Reply-To: <6a7c66fc0804180633l1bfe91ccrcbc7148ba8ae91cf@mail.gmail.com> References: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> <4806A4F6.4090404@charter.net> <7981f6330804170941r3e19a0d0v93ae0d0d05c33d12@mail.gmail.com> <6a7c66fc0804180633l1bfe91ccrcbc7148ba8ae91cf@mail.gmail.com> Message-ID: <7981f6330804180806u114e1f48kc4deb4ba86781e6b@mail.gmail.com> Thanks, I found on one site how to compile after creating the stub files with GHC: First step: *ghc -c -ffi haskell_file.hs* Second step - here it is important to know and write where are the ghc libraries: *gcc -I /usr/local/lib/ghc-5.04.3/include -c C_file.c * After that it is important to link my creted C_file with the stub file and compile it: *ghc -no-hs-main -o C_file C_file.o haskell_file.o haskell_file_stub.o* The final result is C_file execution file...just enter C_file and the program is running correctly. This information: how to compile and to link C with Haskell and to call a Haskell funtion from C was quite difficult. But here is my result of googling throw the internet and to find something usefull. Next challange: link C++ with C and creating a usefull documentation and put it online! Ciao, Miguel Lordelo. On Fri, Apr 18, 2008 at 3:33 PM, Alfonso Acosta wrote: > Although you could use gcc to link the code I wouldn't recommend it > (mainly for the problems you are currently having) > > SImply call GHC to compile both the C and Haskell code. It will take > care of finding the headers and supplying the necessary linker > arguments. > > ghc -ffi -c foo.hs myfoo_c.c > > BTW, you don't need to compile viaC > > 2008/4/17 Miguel Lordelo : > > Well Isaac...I became now a little bit smarter then yesterday!!! > > > > I show you the example that I found and on which I?m working with. > > > > File: foo.hs > > module Foo where > > > > foreign export ccall foo :: Int -> IO Int > > > > foo :: Int -> IO Int > > foo n = return (length (f n)) > > > > f :: Int -> [Int] > > f 0 = [] > > f n = n:(f (n-1)) > > > > To get the C wrapper you insert the following command: > > ghc -ffi -fvia-C -C foo.hs > > > > After execution you will have these following additional files: > > > > foo.hc > > foo.hi > > foo_stub.c > > foo_stub.h > > foo_stub.o > > > > What I did next was to create a file named: myfoo_c.c, where I will call > the > > foo function (implemented in Haskell). > > (you can see this example on > > http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html ) > > But the problem is to compile with gcc (must I put any flag or whatever > set > > something) > > > > The gcc output is: > > myfoo_c.c:2:19: error: HsFFI.h: No such file or directory > > > > I downloaded this header file from: (I know that is not the correct way, > but > > it was the only idea that occurs at the moment) > > http://www.koders.com/c/fidD0593B84C41CA71319BB079EFD0A2C80211C9337.aspx > > > > I compiled again and the following return error appears: > > myfoo_c.c:(.text+0x1c): undefined reference to `hs_init' > > myfoo_c.c:(.text+0x31): undefined reference to `foo' > > myfoo_c.c:(.text+0x50): undefined reference to `hs_exit' > > collect2: ld returned 1 exit status > > > > These functions are necessary to setup GHC runtime (see: > > http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html ) > > > > What I want to know is how to compile myfoo_c.c?! Is it with GCC or > GHC?! > > > > Chears, > > Miguel Lordelo. > > > > > > > > > > On Wed, Apr 16, 2008 at 9:16 PM, Isaac Dupree > > wrote: > > > > > perhaps > > > > > > haskell: > > > foreign export "foo_func" foo :: Int -> IO Int > > > -- I forget the rest of the syntax here > > > > > > C++: > > > > > > extern "C" { > > > int foo_func(int i); > > > } > > > > > > int some_cplusplus_function() { > > > int bat = 3; > > > int blah = foo_func(bat); > > > return blah; > > > } > > > > > > > > > Is that all you need to do? > > > > > > > > > Miguel Lordelo wrote: > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > Well...somehow I'm a beginner in Haskell. But actually my interest > in > > > > Haskell will increase if it is possible to call a haskell function > in > > C++. > > > > Something like GreenCard ( http://www.haskell.org/greencard/ ) > > simplifying > > > > the task of interfacing Haskell programs to external libraries > > (usually). > > > > But is there also a task to interface a foreign language with > Haskell, > > but > > > > calling Haskell functions. Or c2hs which is an interface generator > that > > > > simplifies the development of Haskell bindings to C libraries. > > > > > > > > I want to know this, because in my company some guys are doing some > > testing > > > > with Frotran and MatLab and I want to show them the power of haskell > and > > the > > > > software which we are using is implemented in C++ (there is the > reason > > to > > > > make Haskel -> C++). > > > > > > > > I read somewhere that the only way for C++ calling a haskell > function is > > to > > > > create a binding between Haskell and C and from C to C++, but a easy > > "Hello > > > > World" example was not there. > > > > Unfortunatelly I couldn't found anything usefull, like an complete > > example, > > > > or how to compile the code from haskell to C to C++. > > > > > > > > Can sombody help me, please :P > > > > > > > > Chears, > > > > Miguel Lordelo. > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080418/791cdf22/attachment.htm From bulat.ziganshin at gmail.com Fri Apr 18 11:17:18 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Apr 18 11:14:16 2008 Subject: [Haskell-cafe] C++ interface with Haskell In-Reply-To: <7981f6330804180806u114e1f48kc4deb4ba86781e6b@mail.gmail.com> References: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> <4806A4F6.4090404@charter.net> <7981f6330804170941r3e19a0d0v93ae0d0d05c33d12@mail.gmail.com> <6a7c66fc0804180633l1bfe91ccrcbc7148ba8ae91cf@mail.gmail.com> <7981f6330804180806u114e1f48kc4deb4ba86781e6b@mail.gmail.com> Message-ID: <1158453900.20080418191718@gmail.com> Hello Miguel, Friday, April 18, 2008, 7:06:07 PM, you wrote: you may look into my freearc.org project overall, nothing complex as far as you got it :) i use ghc -c c_file.cpp ghc --make main.hs c_file.o in order to call from C++ to Haskell or vice versa you should define function in C++ as having extern "C" linkage. i recommend you to declare function in header file which is able to compile either in C++ mode (used in first step) or C mode (used in second step, when compiling main.hs): #ifdef __cplusplus extern "C" { #endif void myfunc(void); #ifdef __cplusplus } #endif then you use either "foreign import" haskell statement to use C++ func from haskell or "foreign export" for other way. i also recommend you to use main procedure written in haskell and run from this procedure your main C function - this is the simplest way to initialize Haskell runtime system. that's all > Thanks, > I found on one site how to compile after creating the stub files with GHC: > First step: > ghc -c -ffi haskell_file.hs > Second step - here it is important to know and write where are the ghc libraries: > gcc -I /usr/local/lib/ghc-5.04.3/include -c C_file.c > After that it is important to link my creted C_file with the stub file and compile it: > ghc -no-hs-main -o C_file C_file.o haskell_file.o haskell_file_stub.o > > The final result is C_file execution file...just enter C_file and the program is running correctly. > This information: how to compile and to link C with Haskell and to > call a Haskell funtion from C was quite difficult. > But here is my result of googling throw the internet and to find something usefull. > Next challange: link C++ with C and creating a usefull documentation and put it online! > Ciao, > Miguel Lordelo. > > On Fri, Apr 18, 2008 at 3:33 PM, Alfonso Acosta wrote: > Although you could use gcc to link the code I wouldn't recommend it > (mainly for the problems you are currently having) > > SImply call GHC to compile both the C and Haskell code. It will take > care of finding the headers and supplying the necessary linker > arguments. > > ghc -ffi -c ? foo.hs myfoo_c.c > > BTW, you don't need to compile viaC > > 2008/4/17 Miguel Lordelo : > >> Well Isaac...I became now a little bit smarter then yesterday!!! >> >> I show you the example that I found and on which I?m working with. >> >> File: foo.hs >> module Foo where >> >> foreign export ccall foo :: Int -> IO Int >> >> foo :: Int -> IO Int >> foo n = return (length (f n)) >> >> f :: Int -> [Int] >> f 0 = [] >> f n = n:(f (n-1)) >> >> To get the C wrapper you insert the following command: >> ghc -ffi -fvia-C -C foo.hs >> >> ?After execution you will have these following additional files: >> >> foo.hc >> foo.hi >> foo_stub.c >> foo_stub.h >> foo_stub.o >> >> What I did next was to create a file named: myfoo_c.c, where I will call the >> foo function (implemented in Haskell). >> ?(you can see this example on >> http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html ) >> But the problem is to compile with gcc (must I put any flag or whatever set >> something) >> >> The gcc output is: >> myfoo_c.c:2:19: error: HsFFI.h: No such file or directory >> >> I downloaded this header file from: (I know that is not the correct way, but >> it was the only idea that occurs at the moment) >> http://www.koders.com/c/fidD0593B84C41CA71319BB079EFD0A2C80211C9337.aspx >> >> I compiled again and the following return error appears: >> myfoo_c.c:(.text+0x1c): undefined reference to `hs_init' >> myfoo_c.c:(.text+0x31): undefined reference to `foo' >> myfoo_c.c:(.text+0x50): undefined reference to `hs_exit' >> ?collect2: ld returned 1 exit status >> >> These functions are necessary to setup GHC runtime (see: >> http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html ) >> >> What I want to know is how to compile myfoo_c.c?! Is it with GCC or GHC?! >> >> Chears, >> Miguel Lordelo. >> >> >> >> >> On Wed, Apr 16, 2008 at 9:16 PM, Isaac Dupree >> wrote: >> >> > perhaps >> > >> > haskell: >> > foreign export "foo_func" foo :: Int -> IO Int >> > -- I forget the rest of the syntax here >> > >> > C++: >> > >> > extern "C" { >> > int foo_func(int i); >> > } >> > >> > int some_cplusplus_function() { >> > ?int bat = 3; >> > ?int blah = foo_func(bat); >> > ?return blah; >> > } >> > >> > >> > Is that all you need to do? >> > >> > >> > Miguel Lordelo wrote: >> > >> > > >> > > >> > > >> > > Hi all, >> > > >> > > Well...somehow I'm a beginner in Haskell. But actually my interest in >> > > Haskell will increase if it is possible to call a haskell function in >> C++. >> > > Something like GreenCard ( http://www.haskell.org/greencard/ ) >> simplifying >> > > the task of interfacing Haskell programs to external libraries >> (usually). >> > > But is there also a task to interface a foreign language with Haskell, >> but >> > > calling Haskell functions. Or c2hs which is an interface generator that >> > > simplifies the development of Haskell bindings to C libraries. >> > > >> > > I want to know this, because in my company some guys are doing some >> testing >> > > with Frotran and MatLab and I want to show them the power of haskell and >> the >> > > software which we are using is implemented in C++ (there is the reason >> to >> > > make Haskel -> C++). >> > > >> > > I read somewhere that the only way for C++ calling a haskell function is >> to >> > > create a binding between Haskell and C and from C to C++, but a easy >> "Hello >> > > World" example was not there. >> > > Unfortunatelly I couldn't found anything usefull, like an complete >> example, >> > > or how to compile the code from haskell to C to C++. >> > > >> > > Can sombody help me, please :P >> > > >> > > Chears, >> > > Miguel Lordelo. >> > > >> > > >> > > >> > > ------------------------------------------------------------------------ >> > > >> > > >> > > _______________________________________________ >> > > 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 >> >> > > -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Fri Apr 18 11:19:11 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 18 11:14:25 2008 Subject: [Haskell-cafe] Hackage being too strict? In-Reply-To: <200804180805.12793.jgoerzen@complete.org> References: <1208511804.5960.14.camel@dell.linuxdev.us.dell.com> <200804180805.12793.jgoerzen@complete.org> Message-ID: <20080418151911.B6895E4001@webmail219.herald.ox.ac.uk> In message <200804180805.12793.jgoerzen@complete.org> John Goerzen writes: > On Fri April 18 2008 4:43:24 am Duncan Coutts wrote: > > > It seems arbitrary that Hackage would suddenly reject this valid > > > usage. > > > > Yes it is valid though I hope you can see the general intention of the > > suggestion. If it were not for the compatibility problem it would be > > preferable to use: > > Sure, I do. It's a good point. > > But I think there are a couple of issues here: > > 1) Hackage is rejecting things that Cabal accepts without trouble This is by design. There are dubious things you can do locally that are not really acceptable in publicly distributed packages. As a simple example you can't put 'AllRightsReserved' packages on the public hackage. Hackage upload is an excellent point to apply stricter QA for distributed packages than what you'd use locally for quick hacks. Remember that Cabal is aimed as a haskell build system as well as a haskell package distribution system. So it does not make sense in every context to apply the strictest levels of checking. For example in the longer term I'd like to see 'cabal build Foo.hs' as an upgraded 'ghc --make Foo.hs' ie just the ordinary build stuff - but with parallel build and understanding preprocessors and without having to supply a .cabal file. So the Cabal checking code has a few levels of severity and depending on the context we make those fatal errors, warnings or ignore them completely. The strictest levels of checks are reserved for distributing packages. It's easy to adjust the levels for individual checks. > 2) The behavior of Hackage is unpredictable in what it will accept and what > it will reject Actually with the latest Cabal it's quite predictable. 'cabal sdist' now reports exactly the same errors and warnings as hackage upload. You see the difference at the moment because you're using an older version of Cabal compared to the one on hackage. There is also a new 'cabal check' command for running these additional QA checks (which we hope to extend with more expensive checks along the lines of autotools's 'make distcheck' feature). > 3) The behavior of Hackage changes rapidly They will remain synchronised because Hackage just uses the Cabal library to do its checks. It changed very rapidly recently because we added this checking infrastructure and added dozens of new checks based on looking at the dubious things people have put in existing .cabal files in hackage packages. > It's been quite frustrating lately as many of my packages that used to upload > fine still build fine but get rejected at upload time. If there are any that you think are rejecting legitimate packages then do complain (as in this thread). They're not set in stone. Probably better to complain to cabal-devel or the libraries list, or file bug repots so we spot them. I do realise there is the danger of going too far and having pointless finicky rules. We rely on feedback on this. > I think that Hackage is the wrong place for these checks. I disagree. I think it's absolutely the best place for these checks. Of course they need to be in the client too, that's coming soon with Cabal-1.4 (or now if you use the development version of Cabal). As an ex-linux-distro maintainer I think this is absolutely the right thing to do - to automate and distribute QA as much as possible. Maintaining and improving the quality of the hackage collection is really important. > This stuff should go in Cabal, and ./setup configure should print a big > DEPRECATION WARNING for a major release before the stuff gets yanked. Yes, that's what will happen when you use the new Cabal (the same version that hackage is using). Though it will not print all warnings on configure because we think that'd probably be too annoying for people working on quick hacks. But it does run the full set of checks with the 'check' and 'sdist' commands. > > So that obviously does not solve the problem that Cabal-1.2 and older > > are not very good with forwards compat in the parser. The solution is > > probably just to downgrade that check to a warning rather than outright > > rejection (or possibly limit the check to extensions that existed in > > older Cabal versions). We can make it stricter again in the future when > > Cabal-1.4+ is much more widely deployed. > > > > Sound ok? > > Yes, that makes a lot of sense, too. Can cabal-put be tweaked to make sure > to output that warning by default? There's a bug open on that and Ross and Bjorn are working on getting the cgi upload script to reporte errors/warnings to http clients that only accept text not html output (ie cabal upload). Does that help explain what's going on and what we're up to with this checking stuff? I should also note that there will be a Cabal-1.4 and cabal-install release in the near future but you can grab the pre-releases or the darcs versions now and try things out and report any problems. The first pre-release was announced to the libraries list a bit over a week ago. I'll probably announce the next pre-release on this list so we get wider testing. Duncan From isaacdupree at charter.net Fri Apr 18 11:27:56 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Apr 18 11:23:08 2008 Subject: [Haskell-cafe] C++ interface with Haskell In-Reply-To: <6a7c66fc0804180633l1bfe91ccrcbc7148ba8ae91cf@mail.gmail.com> References: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> <4806A4F6.4090404@charter.net> <7981f6330804170941r3e19a0d0v93ae0d0d05c33d12@mail.gmail.com> <6a7c66fc0804180633l1bfe91ccrcbc7148ba8ae91cf@mail.gmail.com> Message-ID: <4808BDFC.7060100@charter.net> if you'd normally be linking using g++, you'll need (IIRC) -lstdc++ added to linking-ghc's command line Alfonso Acosta wrote: > Although you could use gcc to link the code I wouldn't recommend it > (mainly for the problems you are currently having) > > SImply call GHC to compile both the C and Haskell code. It will take > care of finding the headers and supplying the necessary linker > arguments. > > ghc -ffi -c foo.hs myfoo_c.c > > BTW, you don't need to compile viaC > > 2008/4/17 Miguel Lordelo : >> Well Isaac...I became now a little bit smarter then yesterday!!! >> >> I show you the example that I found and on which I?m working with. >> >> File: foo.hs >> module Foo where >> >> foreign export ccall foo :: Int -> IO Int >> >> foo :: Int -> IO Int >> foo n = return (length (f n)) >> >> f :: Int -> [Int] >> f 0 = [] >> f n = n:(f (n-1)) >> >> To get the C wrapper you insert the following command: >> ghc -ffi -fvia-C -C foo.hs >> >> After execution you will have these following additional files: >> >> foo.hc >> foo.hi >> foo_stub.c >> foo_stub.h >> foo_stub.o >> >> What I did next was to create a file named: myfoo_c.c, where I will call the >> foo function (implemented in Haskell). >> (you can see this example on >> http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html ) >> But the problem is to compile with gcc (must I put any flag or whatever set >> something) >> >> The gcc output is: >> myfoo_c.c:2:19: error: HsFFI.h: No such file or directory >> >> I downloaded this header file from: (I know that is not the correct way, but >> it was the only idea that occurs at the moment) >> http://www.koders.com/c/fidD0593B84C41CA71319BB079EFD0A2C80211C9337.aspx >> >> I compiled again and the following return error appears: >> myfoo_c.c:(.text+0x1c): undefined reference to `hs_init' >> myfoo_c.c:(.text+0x31): undefined reference to `foo' >> myfoo_c.c:(.text+0x50): undefined reference to `hs_exit' >> collect2: ld returned 1 exit status >> >> These functions are necessary to setup GHC runtime (see: >> http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html ) >> >> What I want to know is how to compile myfoo_c.c?! Is it with GCC or GHC?! >> >> Chears, >> Miguel Lordelo. >> >> >> >> >> On Wed, Apr 16, 2008 at 9:16 PM, Isaac Dupree >> wrote: >> >>> perhaps >>> >>> haskell: >>> foreign export "foo_func" foo :: Int -> IO Int >>> -- I forget the rest of the syntax here >>> >>> C++: >>> >>> extern "C" { >>> int foo_func(int i); >>> } >>> >>> int some_cplusplus_function() { >>> int bat = 3; >>> int blah = foo_func(bat); >>> return blah; >>> } >>> >>> >>> Is that all you need to do? >>> >>> >>> Miguel Lordelo wrote: >>> >>>> >>>> >>>> Hi all, >>>> >>>> Well...somehow I'm a beginner in Haskell. But actually my interest in >>>> Haskell will increase if it is possible to call a haskell function in >> C++. >>>> Something like GreenCard ( http://www.haskell.org/greencard/ ) >> simplifying >>>> the task of interfacing Haskell programs to external libraries >> (usually). >>>> But is there also a task to interface a foreign language with Haskell, >> but >>>> calling Haskell functions. Or c2hs which is an interface generator that >>>> simplifies the development of Haskell bindings to C libraries. >>>> >>>> I want to know this, because in my company some guys are doing some >> testing >>>> with Frotran and MatLab and I want to show them the power of haskell and >> the >>>> software which we are using is implemented in C++ (there is the reason >> to >>>> make Haskel -> C++). >>>> >>>> I read somewhere that the only way for C++ calling a haskell function is >> to >>>> create a binding between Haskell and C and from C to C++, but a easy >> "Hello >>>> World" example was not there. >>>> Unfortunatelly I couldn't found anything usefull, like an complete >> example, >>>> or how to compile the code from haskell to C to C++. >>>> >>>> Can sombody help me, please :P >>>> >>>> Chears, >>>> Miguel Lordelo. >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> > From duncan.coutts at worc.ox.ac.uk Fri Apr 18 11:29:07 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 18 11:24:14 2008 Subject: [Haskell-cafe] Hackage being too strict? In-Reply-To: <20080418121351.GJ17560@sliver.repetae.net> References: <1208511804.5960.14.camel@dell.linuxdev.us.dell.com> <20080418121351.GJ17560@sliver.repetae.net> Message-ID: <20080418152907.EAC0DE4001@webmail219.herald.ox.ac.uk> In message <20080418121351.GJ17560@sliver.repetae.net> haskell-cafe@haskell.org writes: > On Fri, Apr 18, 2008 at 10:43:24AM +0100, Duncan Coutts wrote: > > I have now fixed that by eliminating the use of Read in the .cabal > > parser and basically adding an Other/Unknown constructor to several of > > the enumeration types, including Extension. So as of Cabal-1.4 it will > > be possible to add new extensions in later Cabal versions that are not > > in Cabal-1.4 without Cabal-1.4 falling over with a parse error. Indeed, > > if the compiler knows about the extension then it will actually work. > > The only restriction is that unknown extensions cannot be used in > > packages uploaded to hackage, which is pretty reasonable I think. If an > > extension is going to be used in widely distributed packages then that > > extension should be registered in Language.Haskell.Extension. It's > > trivial to add and update hackage to recognise it. > > And then have everyone have to upgrade their cabal? No, that's the nice thing about the changes I've made already. It already works (in Cabal-1.4) to use the PArr extension that ghc-6.8.2 supports but is not finalised yet and is therefore not listed in Language.Haskell.Extension. So only the list that the hackage server itself knows about has to be updated so that it can > It should just be > > > newtype Extension = Extension String Perhaps but the main point I think this that Cabal/Hackage needs to know both what the global list of known extensions and what extensions are supported by particular versions of compilers. It's obviously legitimate for compilers to add new extensions that are not globally registered (and that works now in Cabal-1.4) but I don't think it's legitimate to have such packages be uploaded to hackage. If they're going to be publicly distributed then the extensions they use should be known too. Then there's the simple matter of reporting to users that they've mis-spelled an extension. We need enough information about known extensions to be able to do that. > it would simplify a lot of code, be more forwards and backwards proof, > and remove oddness like do 'Other "PatternGuards"' and 'PatternGuards' > mean the same thing? > > In order to be both backwards and forwards compatable, everyone writing > haskell code that links against cabal and cares about extensions will > have to have special code treating both the same, and in fact, > conditionally compile part of it, since 'PatternGuards' might not even > be valid in some old version of cabal. > > (replace PatternGuards with some other soon to be standardized > extension) > > Normalized data types are a good thing. A centralized registry of things > hackage recognizes is fine, but it shouldn't be cluttering up the source > code. Yeah maybe. I don't really care about the representation so long as we can all agree about what users/packagers/hackage/compilers want from extensions. Duncan From droundy at darcs.net Fri Apr 18 11:37:06 2008 From: droundy at darcs.net (David Roundy) Date: Fri Apr 18 11:32:11 2008 Subject: [Haskell-cafe] announcing franchise 0.0 Message-ID: <20080418153703.GN8763@darcs.net> I'm pleased to announce the existence (not release, properly) of franchise, a new configuration/build system for Haskell programs and packages. Franchise ========= Franchise is a configuration and build system for Haskell projects. The configure system employed in franchise is designed to be easily forward and backward compatible, meaning that you shouldn't need to change your Setup.hs file in order to compile with a new version of ghc, and if you *do* need to make a change in your Setup.hs file, it shouldn't force users who have an older version of franchise and/or ghc to upgrade either their compiler or their copy of franchise. The latter goal is really only going to be realized if and when a stable version of franchise is released... as it is currently is something of a pre-alpha state (but useable, for instance, for compiling darcs). One goal of franchise is to not require developers to provide redundant information. For instance, you've already listed all the modules you use, and ghc already knows which modules are present in which packages, so there's in general no need for you to list the packages that you require, much less their versions. This enhances both forwards and backwards compatibility, and just plain makes your life easier. If a particular module is provided by more than one package, you may need to disambiguate, but that's not the common case. Perhaps also worth mentioning is that franchise supports parallel builds similar to make -j. Currently the number of simultaneous builds is fixed at four. Franchise does not, however, compute an optimized parallel build order, with the result that on the darcs repository a franchise build is a few percent slower than make -j4. Franchise is currently ghc-specific and won't run on Windows, but patches to extend either of these limitations would be welcome. It also currently won't work when any flags contain space characters (e.g. with --prefix="/home/user/My stuff"), but the fix for lack of space support is the same as the fix for Windows support, so far as I can tell. The package name "franchise" stands for "Fun, relaxing and calming Haskell into Saturday evening." It is also something of an antonym of "cabal," since "franchise" means the right to vote. Which also fits in with the concept of allowing the code to decide on its own dependencies. Franchise is made up of some pretty ugly code, with a small amount of pretty beautiful code. But it was all code that was fun and relaxing to write. It you want to have argumentative, stressful conversations, please don't do so on the subject of fun, relaxing and calming code. Note: franchise is almost entirely undocumented. It does only export a couple of dozen functions, but still might be hard to learn to use. This is because writing documentation is not as fun, relaxing or calming as writing Haskell. Also, franchise is not yet at the stage where it's likely to be useful to you without any features added, unless you've got a very simple project, in which case you should be able to pretty easily copy and modify an existing franchise Setup.hs file. To get franchise, run darcs get http://darcs.net/repos/franchise (note that this will require darcs 2.0.0) To build and install franchise, simply execute runghc Setup.hs install --user --prefix=$HOME if you don't want to actually install it, just run runghc Setup.hs build I think that's all (and obviously, in no particular order). I hope you enjoy franchise, or if you don't enjoy franchise, I hope you don't tell me about it. David Roundy P.S. A franchise build file for darcs is included below. This is a work-in-progress. It doesn't build the documentation, doesn't allow the user to configure on the command-line which packages they want to use (e.g. bytestring/curl/libwww) and doesn't build the Workaround.hs module which codes replacements for missing or broken library functions. But it *is* able to build darcs, and if these features are added, it will be able to replace darcs' configure and build system without loss of features or compatibility. #!/usr/bin/runhaskell import Distribution.Franchise configure = do findPackagesFor "src/darcs.lhs" addEnv "GHC_FLAGS" "-DPACKAGE_VERSION=\"2.0.0\"" addEnv "GHC_FLAGS" "-O2 -Wall -Werror" addEnv "CFLAGS" "-DPACKAGE_VERSION=\"2.0.0\"" -- look for libz checkLib "z" "zlib.h" "gzopen(\"temp\",\"w\")" -- look for libwww do systemOut "libwww-config" ["--cflags"] >>= addEnv "CFLAGS" systemOut "libwww-config" ["--libs"] >>= addEnv "LDFLAGS" addEnv "GHC_FLAGS" "-DHAVE_LIBWWW" putStrLn "Found libwww" `catch` \_ -> putStrLn "Libwww isn't present!" -- look for libcurl do systemOut "curl-config" ["--cflags"] >>= addEnv "GHC_FLAGS" systemOut "curl-config" ["--cflags"] >>= addEnv "CFLAGS" systemOut "curl-config" ["--libs"] >>= addEnv "LDFLAGS" addEnv "GHC_FLAGS" "-DHAVE_CURL" putStrLn "Found libcurl" `catch` \_ -> putStrLn "Libcurl isn't present!" -- look for libcurses do checkLib "curses" "term.h" "tgetnum(\"hello world\")" checkLib "curses" "curses.h" "" addEnv "GHC_FLAGS" "-DHAVE_CURSES" `catch` \_ -> putStrLn "Couldn't find libcurses." -- look for http packages do requireModule "Network.HTTP ()" addEnv "GHC_FLAGS" "-DHAVE_HTTP" `catch` \_ -> putStrLn "Couldn't find http package." findPackagesFor "src/darcs.lhs" main = build configure $ executable "darcs" "src/darcs.lhs" ["src/c_compat.c", "src/maybe_relink.c", "src/atomic_create.c", "src/fpstring.c", "src/umask.c", "src/hslibwww.c", "src/Crypt/sha2.c", "src/hscurl.c"] -- David Roundy Department of Physics Oregon State University From emax at cs.chalmers.se Fri Apr 18 12:08:31 2008 From: emax at cs.chalmers.se (Emil Axelsson) Date: Fri Apr 18 12:03:57 2008 Subject: [Haskell-cafe] Help with associated types In-Reply-To: <4807401C.7060006@cs.chalmers.se> References: <4807401C.7060006@cs.chalmers.se> Message-ID: <4808C77F.3080408@cs.chalmers.se> After some thinking I think I can put my question much simpler: If I have a class with some dependencies, say a -> ..., b c -> ... Is it possible to encode this using associated types without having all of a, b and c as class parameters? It seems to me that it's not possible. And if so, I'll simply drop this idea (was hoping that ATs would allow me to have fewer class parameters). Thanks, / Emil From bulat.ziganshin at gmail.com Fri Apr 18 12:40:01 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Apr 18 12:37:01 2008 Subject: [Haskell-cafe] C++ interface with Haskell In-Reply-To: <4808BDFC.7060100@charter.net> References: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> <4806A4F6.4090404@charter.net> <7981f6330804170941r3e19a0d0v93ae0d0d05c33d12@mail.gmail.com> <6a7c66fc0804180633l1bfe91ccrcbc7148ba8ae91cf@mail.gmail.com> <4808BDFC.7060100@charter.net> Message-ID: <1875521233.20080418204001@gmail.com> Hello Isaac, Friday, April 18, 2008, 7:27:56 PM, you wrote: absolutely true! it's required if you use new/delete and other things supported by c++ RTS > if you'd normally be linking using g++, you'll need (IIRC) -lstdc++ > added to linking-ghc's command line > Alfonso Acosta wrote: >> Although you could use gcc to link the code I wouldn't recommend it >> (mainly for the problems you are currently having) >> >> SImply call GHC to compile both the C and Haskell code. It will take >> care of finding the headers and supplying the necessary linker >> arguments. >> >> ghc -ffi -c foo.hs myfoo_c.c >> >> BTW, you don't need to compile viaC >> >> 2008/4/17 Miguel Lordelo : >>> Well Isaac...I became now a little bit smarter then yesterday!!! >>> >>> I show you the example that I found and on which I?m working with. >>> >>> File: foo.hs >>> module Foo where >>> >>> foreign export ccall foo :: Int -> IO Int >>> >>> foo :: Int -> IO Int >>> foo n = return (length (f n)) >>> >>> f :: Int -> [Int] >>> f 0 = [] >>> f n = n:(f (n-1)) >>> >>> To get the C wrapper you insert the following command: >>> ghc -ffi -fvia-C -C foo.hs >>> >>> After execution you will have these following additional files: >>> >>> foo.hc >>> foo.hi >>> foo_stub.c >>> foo_stub.h >>> foo_stub.o >>> >>> What I did next was to create a file named: myfoo_c.c, where I will call the >>> foo function (implemented in Haskell). >>> (you can see this example on >>> http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html ) >>> But the problem is to compile with gcc (must I put any flag or whatever set >>> something) >>> >>> The gcc output is: >>> myfoo_c.c:2:19: error: HsFFI.h: No such file or directory >>> >>> I downloaded this header file from: (I know that is not the correct way, but >>> it was the only idea that occurs at the moment) >>> http://www.koders.com/c/fidD0593B84C41CA71319BB079EFD0A2C80211C9337.aspx >>> >>> I compiled again and the following return error appears: >>> myfoo_c.c:(.text+0x1c): undefined reference to `hs_init' >>> myfoo_c.c:(.text+0x31): undefined reference to `foo' >>> myfoo_c.c:(.text+0x50): undefined reference to `hs_exit' >>> collect2: ld returned 1 exit status >>> >>> These functions are necessary to setup GHC runtime (see: >>> http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html ) >>> >>> What I want to know is how to compile myfoo_c.c?! Is it with GCC or GHC?! >>> >>> Chears, >>> Miguel Lordelo. >>> >>> >>> >>> >>> On Wed, Apr 16, 2008 at 9:16 PM, Isaac Dupree >>> wrote: >>> >>>> perhaps >>>> >>>> haskell: >>>> foreign export "foo_func" foo :: Int -> IO Int >>>> -- I forget the rest of the syntax here >>>> >>>> C++: >>>> >>>> extern "C" { >>>> int foo_func(int i); >>>> } >>>> >>>> int some_cplusplus_function() { >>>> int bat = 3; >>>> int blah = foo_func(bat); >>>> return blah; >>>> } >>>> >>>> >>>> Is that all you need to do? >>>> >>>> >>>> Miguel Lordelo wrote: >>>> >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> Well...somehow I'm a beginner in Haskell. But actually my interest in >>>>> Haskell will increase if it is possible to call a haskell function in >>> C++. >>>>> Something like GreenCard ( http://www.haskell.org/greencard/ ) >>> simplifying >>>>> the task of interfacing Haskell programs to external libraries >>> (usually). >>>>> But is there also a task to interface a foreign language with Haskell, >>> but >>>>> calling Haskell functions. Or c2hs which is an interface generator that >>>>> simplifies the development of Haskell bindings to C libraries. >>>>> >>>>> I want to know this, because in my company some guys are doing some >>> testing >>>>> with Frotran and MatLab and I want to show them the power of haskell and >>> the >>>>> software which we are using is implemented in C++ (there is the reason >>> to >>>>> make Haskel -> C++). >>>>> >>>>> I read somewhere that the only way for C++ calling a haskell function is >>> to >>>>> create a binding between Haskell and C and from C to C++, but a easy >>> "Hello >>>>> World" example was not there. >>>>> Unfortunatelly I couldn't found anything usefull, like an complete >>> example, >>>>> or how to compile the code from haskell to C to C++. >>>>> >>>>> Can sombody help me, please :P >>>>> >>>>> Chears, >>>>> Miguel Lordelo. >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From iavor.diatchki at gmail.com Fri Apr 18 13:28:13 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri Apr 18 13:23:24 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <48079F85.5030408@gmail.com> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <5ab17e790804171009l6d974cf2va38cbd94dccf3303@mail.gmail.com> <48078851.1050201@gmail.com> <5ab17e790804171113i647ff98ftde208ca753f88f0d@mail.gmail.com> <48079F85.5030408@gmail.com> Message-ID: <5ab17e790804181028i20a6961au8ca528871170b460@mail.gmail.com> Hello, On Thu, Apr 17, 2008 at 12:05 PM, Martin Sulzmann wrote: > Can you pl specify the improvement rules for your interpretation of FDs. > That would help! Each functional dependency on a class adds one extra axiom to the system (aka CHR rule, improvement rule). For the example in question we have: class D a b | a -> b where ... the extra axiom is: forall a b c. (D a b, D a c) => (b = c) This is the definition of "functional dependency"---it specifies that the relation 'D' is functional. An improvement rule follows from a functional dependency if it can be derived from this rule. For example, if we have an instance (i.e., another axiom): instance D Char Bool Then we can derive the following theorem: (D Char a) => (a = Bool) I think that in the CHR paper this was called "instance" improvement. Note that this is not an extra axiom but rather a theorem---adding it to the system as an axiom does not make the system any more expressive. Now consider what happens when we have a qualified instance: instance D a a => D [a] [a] We can combine this with the FD axiom to get: (D a a, D [a] b) => b = [a] This is all that follows from the functional dependency. Of course, in the presence of other instances, we could obtain more improvement rules. As for the "consistency rule", it is intended to ensure that instances are consistent with the FD axiom. As we saw from the previous examples, it is a bit conservative in that it rejects some instances that do not violate the functional dependency. Now, we could choose to exploit this fact to compute stronger improvement rules---nothing wrong with that. However, this goes beyond FDs. -Iavor > > I'm simply following Mark Jones' style FDs. > > Mark's ESOP'00 paper has a consistency condition: > If two instances match on the FD domain then the must also match on their > range. > The motivation for this condition is to avoid inconsistencies when > deriving improvement rules from instances. > > For > > > class D a b | a -> b > > instance D a a => D [a] [a] > instance D [Int] Char > > > we get > > D [a] b ==> b =[a] > D [Int] b ==> b=Char > > In case of > > D [Int] b we therefore get b=Char *and* b =[a] which leads to a > (unification) error. > The consistency condition avoids such situations. > > > The beauty of formalism FDs with CHRs (or type functions/families) is that > the whole improvement process becomes explicit. Of course, it has to match > the programmer's intuition. See the discussion regarding multi-range FDs. > > Martin > > From lennart at augustsson.net Fri Apr 18 13:36:31 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Fri Apr 18 13:31:40 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <48085B4F.3000007@gmail.com> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <48085B4F.3000007@gmail.com> Message-ID: I've never thought of one being shorthand for the other, really. Since they are logically equivalent (in my interpretation) I don't really care which one we regard as more primitive. On Fri, Apr 18, 2008 at 9:26 AM, Martin Sulzmann wrote: > Lennart Augustsson wrote: > > > To reuse a favorite word, I think that any implementation that > > distinguishes 'a -> b, a -> c' from 'a -> b c' is broken. :) > > It does not implement FD, but something else. Maybe this something else > > is useful, but if one of the forms is strictly more powerful than the other > > then I don't see why you would ever want the less powerful one. > > > > Do you have any good examples, besides the contrived one > > class D a b c | a -> b c > > instance D a b b => D [a] [b] [b] > > where we want to have the more powerful form of multi-range FDs? > > Fixing the problem who mention is easy. After all, we know how to derive > improvement for multi-range FDs. But it seems harder to find agreement > whether > multi-range FDs are short-hands for single-range FDs, or > certain single-range FDs, eg a -> b and a -> c, are shorthands for more > powerful > multi-range FDs a -> b c. > I clearly prefer the latter, ie have a more powerful form of FDs. > > Martin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080418/2967c06f/attachment.htm From duncan.coutts at worc.ox.ac.uk Fri Apr 18 13:41:25 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 18 13:36:32 2008 Subject: [Haskell-cafe] announcing franchise 0.0 In-Reply-To: <20080418153703.GN8763@darcs.net> Message-ID: <20080418174125.F3562E4001@webmail219.herald.ox.ac.uk> In message <20080418153703.GN8763@darcs.net> haskell-cafe@haskell.org, darcs-devel@darcs.net writes: > One goal of franchise is to not require developers to provide redundant > information. For instance, you've already listed all the modules you use, > and ghc already knows which modules are present in which packages, so > there's in general no need for you to list the packages that you require, > much less their versions. Yeah, this is an important point. Part of the original idea of Cabal was to help distribution by properly tracking dependencies. It's not too bad for that use case but it's really a pain in comparison to ghc --make or hmake which just do the right thing given the environment. Part of our plan for Cabal 2.x is to do proper module dependency chasing so that it will work without a .cabal file in simple cases and be usable for the ghc --make or hmake use cases (but with support for preprocessors and parallel build). It should be possible to just start hacking and derive a skeleton .cabal file afterwards if you decide you want to distribute a package. Duncan From martin.sulzmann at gmail.com Fri Apr 18 14:04:30 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Fri Apr 18 13:59:43 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <5ab17e790804181028i20a6961au8ca528871170b460@mail.gmail.com> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <5ab17e790804171009l6d974cf2va38cbd94dccf3303@mail.gmail.com> <48078851.1050201@gmail.com> <5ab17e790804171113i647ff98ftde208ca753f88f0d@mail.gmail.com> <48079F85.5030408@gmail.com> <5ab17e790804181028i20a6961au8ca528871170b460@mail.gmail.com> Message-ID: <4808E2AE.2080703@gmail.com> Thanks Iavor! Things become now clear. Let's consider our running example class D a b | a -> b instance D a b => D [a] [b] which we can write in CHR notation D a b, D a c ==> b=c (FD) D [a] [b] <=> D a b (Inst) These rules overlap. Let's consider the critical pair D [a] [b], D [a] c The following two derivations are possible D [a] [b], D [a] c -->FD D [a] [b], c = [b] -->Inst D a b, c = [b] D [a] [b], D [a] c -->Inst D a b, D [a] c The two final stores differ which means that the CHR system is non-confluent. Hence, the proof theory is (potentially) incomplete. What does this mean? Logically true statement may not be derivable using our CHR/typeclass-FD solver. Iavor suggests to add the rule D [a] c, D a b ==> c = [b] (Imp1) Makes perfect sense! This rule is indeed a theorem and makes the system confluent. But that's not what the FD-CHR paper does. The FD-CHR paper generates the "stronger" rule D [a] c ==> c = [b] (Imp2) This rule is NOT a theorem (ie logical consequence from the FD and Inst rule). But this rule also makes the system confluent. Why does the FD-CHR paper suggest this rule. Some reasons: - the (Imp2) matches the GHC and I believe also Hugs implementation - the (Imp2) is "easier" to implement, we only need to look for a single constraint when firing the rule - (Arguable) The (Imp2) matches better the programmer's intuition. We only consider the instance head when generating improvement but ignore the instance context. - (Historical note: The rule suggested by Iavor were discussed when writing the FD-CHR paper but somehow we never pursued this alternative design space. I have to dig out some old notes, maybe there some other reasons, infinite completion, why this design space wasn't pursued). To summarize, I see now where the confusion lies. The FD-CHR studies a "stronger" form of FDs where the CHR improvement rules generated guarantee confluence but the rules are not necessarily logical consequence. Therefore, the previously discussed property a -> b and a -> c iff a -> b c does of course NOT hold. That is, the combination of improvement rules derived from a -> b and a -> c is NOT equivalent to the improvement rules derived from a -> b c. Logically, the equivalence obviously holds. Martin Iavor Diatchki wrote: > Hello, > > On Thu, Apr 17, 2008 at 12:05 PM, Martin Sulzmann > wrote: > >> Can you pl specify the improvement rules for your interpretation of FDs. >> That would help! >> > > Each functional dependency on a class adds one extra axiom to the > system (aka CHR rule, improvement rule). For the example in question > we have: > > class D a b | a -> b where ... > > the extra axiom is: > > forall a b c. (D a b, D a c) => (b = c) > > This is the definition of "functional dependency"---it specifies that > the relation 'D' is functional. An improvement rule follows from a > functional dependency if it can be derived from this rule. For > example, if we have an instance (i.e., another axiom): > > instance D Char Bool > > Then we can derive the following theorem: > > (D Char a) => (a = Bool) > > I think that in the CHR paper this was called "instance" improvement. > Note that this is not an extra axiom but rather a theorem---adding it > to the system as an axiom does not make the system any more > expressive. Now consider what happens when we have a qualified > instance: > > instance D a a => D [a] [a] > > We can combine this with the FD axiom to get: > > (D a a, D [a] b) => b = [a] > > This is all that follows from the functional dependency. Of course, > in the presence of other instances, we could obtain more improvement > rules. > > As for the "consistency rule", it is intended to ensure that instances > are consistent with the FD axiom. As we saw from the previous > examples, it is a bit conservative in that it rejects some instances > that do not violate the functional dependency. Now, we could choose > to exploit this fact to compute stronger improvement rules---nothing > wrong with that. However, this goes beyond FDs. > > -Iavor > > > > > > > > > >> I'm simply following Mark Jones' style FDs. >> >> Mark's ESOP'00 paper has a consistency condition: >> If two instances match on the FD domain then the must also match on their >> range. >> The motivation for this condition is to avoid inconsistencies when >> deriving improvement rules from instances. >> >> For >> > > > >> class D a b | a -> b >> >> instance D a a => D [a] [a] >> instance D [Int] Char >> >> >> we get >> >> D [a] b ==> b =[a] >> D [Int] b ==> b=Char >> >> In case of >> >> D [Int] b we therefore get b=Char *and* b =[a] which leads to a >> (unification) error. >> The consistency condition avoids such situations. >> >> >> The beauty of formalism FDs with CHRs (or type functions/families) is that >> the whole improvement process becomes explicit. Of course, it has to match >> the programmer's intuition. See the discussion regarding multi-range FDs. >> >> Martin >> >> >> From martin.sulzmann at gmail.com Fri Apr 18 14:05:52 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Fri Apr 18 14:01:01 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <48085B4F.3000007@gmail.com> Message-ID: <4808E300.1040808@gmail.com> Lennart Augustsson wrote: > I've never thought of one being shorthand for the other, really. > Since they are logically equivalent (in my interpretation) I don't > really care which one we regard as more primitive. True. See my response to Iavor's recent email. Martin From bos at serpentine.com Fri Apr 18 14:13:24 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Apr 18 14:08:30 2008 Subject: [Haskell-cafe] [ANN] cabal-rpm 0.4 Message-ID: <4808E4C4.2070200@serpentine.com> I've just uploaded version 0.4 of cabal-rpm to Hackage. This is a program that generates an RPM package from a Cabal package. RPM is the package format used by several major Linux distributions. New in this version are support for GHC 6.8.2 and the Cabal 1.2 release series. Download: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cabal-rpm-0.4 Source: darcs get http://darcs.serpentine.com/cabal-rpm References: <4807B6D1.7090006@cs.pdx.edu> Message-ID: <20080418184327.GB3462@scytale.galois.com> jsnow: > A new version of my raytracer is out. It now supports cones, cylinders, > disks, boxes, and planes as base primitives (previously it only > supported triangles and spheres), as well as transformations of > arbitrary objects (rotate, scale, translate) and the CSG operations > difference and intersection. Perlin noise and Blinn highlights have > been added, as well. > > http://syn.cs.pdx.edu/~jsnow/glome/ > > Glome can parse NFF-format scene files (see > http://tog.acm.org/resources/SPD/), but many features are only > accessible via raw Haskell, since NFF doesn't support very many kinds of > primitives. I included a TestScene.hs file that demonstrates how to > create a scene with various kinds of geometry (including a crude attempt > at a recursively-defined oak tree) in haskell. There isn't any > documentation yet, but many of the primitives have constructors that > resemble their equivalents in povray, so anyone familiar with povray's > syntax should be able to figure out what's going on. Very impressive. Did you consider cabalising the Haskell code, so it can be easily distributed from hackage.haskell.org? I note on the website you say: "no threading (shared-memory concurrency is not supported by ocaml, in haskell it's buggy)" Could you elaborate on this? Shared memory concurrency is a sweet spot in Haskell, and heavily utilised, so I think we'd all like to know more details.. -- Don From qdunkan at gmail.com Fri Apr 18 15:08:10 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Fri Apr 18 15:03:22 2008 Subject: [Haskell-cafe] C++ interface with Haskell In-Reply-To: <1875521233.20080418204001@gmail.com> References: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> <4806A4F6.4090404@charter.net> <7981f6330804170941r3e19a0d0v93ae0d0d05c33d12@mail.gmail.com> <6a7c66fc0804180633l1bfe91ccrcbc7148ba8ae91cf@mail.gmail.com> <4808BDFC.7060100@charter.net> <1875521233.20080418204001@gmail.com> Message-ID: <2518b95d0804181208j3c369e85nc012557c777f6e2e@mail.gmail.com> To threadjack a little bit, I've been interfacing haskell with c++. It gets awkward when the c++ structures use STL types like string and vector. Of course those are too complex for haskell to marshal to. What I've been doing is defining an XMarshal variant of the X c++ class, that uses plain c arrays. Then I marshal to that, and construct the c++ object properly from XMarshal in the c->c++ wrapper layer. On a few occasions, when the c++ class is really big and only has one STL member, I make a partially constructed c++ object, pass the array separately, and then construct the proper c++ class from the broken haskell generated one. Possibly dangerous as all get-out because I'm dealing with "unconstructed" c++ objects, but it seems to work. Passing back to haskell is easier since I can use "&*vec.begin()", which according to the internet should be safe because STL guarantees that vector contents are contiguous. I'm only saved by the fact that I don't have that many different kinds of classes to pass. This would be much more drudgery if I had more. Does anyone have a better solution or convention for marshalling c++ objects? I've also noticed warnings from g++ about hsc2hs's use of the OFFSETOF macro on c++ classes, but some googling of g++ mailing lists implied that it's harmless if you don't have virtual bases, and what sane person does, so I suppress it now :) From sebastian.sylvan at gmail.com Fri Apr 18 15:13:01 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Fri Apr 18 15:08:06 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <20080418184327.GB3462@scytale.galois.com> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> Message-ID: <3d96ac180804181213h40f468a7n146440b6cedb398e@mail.gmail.com> On Fri, Apr 18, 2008 at 7:43 PM, Don Stewart wrote: > jsnow: > > A new version of my raytracer is out. It now supports cones, cylinders, > > disks, boxes, and planes as base primitives (previously it only > > supported triangles and spheres), as well as transformations of > > arbitrary objects (rotate, scale, translate) and the CSG operations > > difference and intersection. Perlin noise and Blinn highlights have > > been added, as well. > > > > http://syn.cs.pdx.edu/~jsnow/glome/ > > > > Glome can parse NFF-format scene files (see > > http://tog.acm.org/resources/SPD/), but many features are only > > accessible via raw Haskell, since NFF doesn't support very many kinds of > > primitives. I included a TestScene.hs file that demonstrates how to > > create a scene with various kinds of geometry (including a crude attempt > > at a recursively-defined oak tree) in haskell. There isn't any > > documentation yet, but many of the primitives have constructors that > > resemble their equivalents in povray, so anyone familiar with povray's > > syntax should be able to figure out what's going on. > > Very impressive. Did you consider cabalising the Haskell code, so it > can be easily distributed from hackage.haskell.org? > > I note on the website you say: > > "no threading (shared-memory concurrency is not supported by ocaml, > in haskell it's buggy)" > > Could you elaborate on this? Shared memory concurrency is a sweet spot > in Haskell, and heavily utilised, so I think we'd all like to know more > details.. > Not sure what you need shared memory concurrency for in this case as it seems to be a straightforward parallelism problem (i.e. the different threads would be different pixels, there is no sharing needed). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080418/beaad1f2/attachment.htm From westondan at imageworks.com Fri Apr 18 15:24:59 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri Apr 18 15:20:05 2008 Subject: [Haskell-cafe] Wrong Answer Computing Graph Dominators In-Reply-To: <1208497238.30072.1248551899@webmail.messagingengine.com> References: <6dbd4d000804151759r2ca72957hae8cd60c91404e60@mail.gmail.com> <20080416183356.GA4362@zombie.inf.tu-dresden.de> <6dbd4d000804170832h1391db15ob84e61d4e8960170@mail.gmail.com> <6dbd4d000804171413h54c33f35sdb1c9554d4d4c9@mail.gmail.com> <4807C6AB.3050902@imageworks.com> <16760156.post@talk.nabble.com> <1208497238.30072.1248551899@webmail.messagingengine.com> Message-ID: <4808F58B.8050703@imageworks.com> Matthew Brecknell wrote: > Dan Weston wrote: >> Here, "any path" means all paths, a logical conjunction: >> >> and [True, True] = True >> and [True ] = True >> and [ ] = True > > Kim-Ee Yeoh wrote: >> Hate to nitpick, but what appears to be some kind of a >> limit in the opposite direction is a curious way of arguing >> that: and [] = True. >> >> Surely one can also write >> >> and [False, False] = False >> and [False ] = False >> and [ ] = False ??? > > No. I think what Dan meant was that for all non-null > xs :: [Bool], it is clearly true that: > > and (True:xs) == and xs -- (1) > > It therefore makes sense to define (1) to hold also > for empty lists, and since it is also true that: > > and (True:[]) == True > > We obtain: > > and [] == True > > Since we can't make any similar claim about the > conjuctions of lists beginning with False, there > is no reasonable argument to the contrary. Also, (and I know none of this is original, but it's worth repeating...) It is not just the definition of "and" at stake here. Logical propositions that extend painlessly to [] if (and [] == True) become inconsistent for [] if (and [] == False) and would have to be checked in program calculation. For instance, in propositional logic, you can prove (using Composition, Distribution[2], Material Implication) that for nonnull ys = [y0,y1,..,yn], implying everthing implies each thing: x -> (y0 && y1 && ... yn) <--> (x -> y0) && (x -> y1) && ... && (x -> yn) Writing this in Haskell and using the fact that x -> y means (not x || y), this says that not x || and ys == and (map (not x ||) ys) or in pointfree notation: f . and == and . map f where f = (not x ||) This should look familiar to origamists everywhere. "and" can be defined in terms of foldr iff (and [] == True) [Try it!]. Why is this important? If and is defined with foldr, then the above can be proven for all well-typed f, and for f = (not x ||) in particular, even if ys is null. The law is painlessly extended to cover the null case automatically (and is therefore consistent): LHS: not x || (and []) == not x || True == True RHS: and (map (not x ||) []) == and [] == True Therefore True |- True, an instance of x |- x If (and [] == False), then the law becomes inconsistent: LHS: not x || (and []) == not x || False == not x RHS: and (map (not x ||) []) == and [] == False Since not x == False, then x == True Therefore, True |- x ==> -| x (everything is derivable) so we would have to exclude the null case for this law (and many others). Uck! Better stick with (and [] == True) Naturally, similar reasoning justifies (or [] == False). From lennart at augustsson.net Fri Apr 18 15:58:49 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Fri Apr 18 15:53:55 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <48085B4F.3000007@gmail.com> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <48085B4F.3000007@gmail.com> Message-ID: BTW, here's a non-contrived example. It's pretty easy to come up with examples when you try to use type classes instead of a proper module system. Here we have expressions parametrized over how identifiers and literals are represented. First a simple instance, and then one where all the types are parametrized over the string representation. These are the plug-and-play type of things I'd like to be able to do. class IsExpr expr id lit | expr -> id lit where eId :: id -> expr eLit :: lit -> expr eApply :: expr -> expr -> expr data SimpleExpr = SId Char | SLit Int | SApply SimpleExpr SimpleExpr instance IsExpr SimpleExpr Char Int where eId = SId eLit = SLit eApply = SApply data FancyExpr str = FId (Id str) | FLit (Lit str) | FApply (FancyExpr str) (FancyExpr str) data Id str = Id str data Lit str = LString str | LInt Int instance IsExpr (FancyExpr str) (Id str) (Lit str) where eId = FId eLit = FLit eApply = FApply On Fri, Apr 18, 2008 at 9:26 AM, Martin Sulzmann wrote: > Lennart Augustsson wrote: > > > To reuse a favorite word, I think that any implementation that > > distinguishes 'a -> b, a -> c' from 'a -> b c' is broken. :) > > It does not implement FD, but something else. Maybe this something else > > is useful, but if one of the forms is strictly more powerful than the other > > then I don't see why you would ever want the less powerful one. > > > > Do you have any good examples, besides the contrived one > > class D a b c | a -> b c > > instance D a b b => D [a] [b] [b] > > where we want to have the more powerful form of multi-range FDs? > > Fixing the problem who mention is easy. After all, we know how to derive > improvement for multi-range FDs. But it seems harder to find agreement > whether > multi-range FDs are short-hands for single-range FDs, or > certain single-range FDs, eg a -> b and a -> c, are shorthands for more > powerful > multi-range FDs a -> b c. > I clearly prefer the latter, ie have a more powerful form of FDs. > > Martin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080418/972eff5b/attachment.htm From dons at galois.com Fri Apr 18 16:08:11 2008 From: dons at galois.com (Don Stewart) Date: Fri Apr 18 16:03:23 2008 Subject: [Haskell-cafe] C++ interface with Haskell In-Reply-To: <2518b95d0804181208j3c369e85nc012557c777f6e2e@mail.gmail.com> References: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> <4806A4F6.4090404@charter.net> <7981f6330804170941r3e19a0d0v93ae0d0d05c33d12@mail.gmail.com> <6a7c66fc0804180633l1bfe91ccrcbc7148ba8ae91cf@mail.gmail.com> <4808BDFC.7060100@charter.net> <1875521233.20080418204001@gmail.com> <2518b95d0804181208j3c369e85nc012557c777f6e2e@mail.gmail.com> Message-ID: <20080418200811.GE3462@scytale.galois.com> qdunkan: > To threadjack a little bit, I've been interfacing haskell with c++. > It gets awkward when the c++ structures use STL types like string and > vector. Of course those are too complex for haskell to marshal to. > > What I've been doing is defining an XMarshal variant of the X c++ > class, that uses plain c arrays. Then I marshal to that, and > construct the c++ object properly from XMarshal in the c->c++ wrapper > layer. On a few occasions, when the c++ class is really big and only > has one STL member, I make a partially constructed c++ object, pass > the array separately, and then construct the proper c++ class from the > broken haskell generated one. Possibly dangerous as all get-out > because I'm dealing with "unconstructed" c++ objects, but it seems to > work. > > Passing back to haskell is easier since I can use "&*vec.begin()", > which according to the internet should be safe because STL guarantees > that vector contents are contiguous. > > I'm only saved by the fact that I don't have that many different kinds > of classes to pass. This would be much more drudgery if I had more. > Does anyone have a better solution or convention for marshalling c++ > objects? > > > I've also noticed warnings from g++ about hsc2hs's use of the OFFSETOF > macro on c++ classes, but some googling of g++ mailing lists implied > that it's harmless if you don't have virtual bases, and what sane > person does, so I suppress it now :) Would someone like to summarise the current approaches to combining Haskell & C++ on the Haskell wiki, even if just in bullet points? -- Don From jsnow at cs.pdx.edu Fri Apr 18 16:10:23 2008 From: jsnow at cs.pdx.edu (Jim Snow) Date: Fri Apr 18 16:07:07 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <20080418184327.GB3462@scytale.galois.com> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> Message-ID: <4809002F.8010302@cs.pdx.edu> Don Stewart wrote: > jsnow: > >> A new version of my raytracer is out. ... >> > > Very impressive. Did you consider cabalising the Haskell code, so it > can be easily distributed from hackage.haskell.org? > > I note on the website you say: > > "no threading (shared-memory concurrency is not supported by ocaml, > in haskell it's buggy)" > > Could you elaborate on this? Shared memory concurrency is a sweet spot > in Haskell, and heavily utilised, so I think we'd all like to know more > details.. > > -- Don > The concurrency bug has to do with excessive memory use, and was discussed earlier here on the mailing list (search for Glome). http://hackage.haskell.org/trac/ghc/ticket/2185 The other problem I had with concurrency is that I was getting about a 50% speedup instead of the 99% or so that I'd expect on two cores. I figured I'm probably doing something wrong. I don't have any objection to using cabal, I just haven't gone to the trouble to figure it out yet. Maybe in the next release. Sebastian Sylvan wrote: > Not sure what you need shared memory concurrency for in this case as > it seems to be a straightforward parallelism problem (i.e. the > different threads would be different pixels, there is no sharing needed). The scene is shared between threads. (Complex scenes can be quite large.) I'm assuming this is handled as a read-only shared memory region or something similar, as one might expect, and is not actually copied. -jim From bulat.ziganshin at gmail.com Fri Apr 18 16:19:19 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Apr 18 16:16:19 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <4809002F.8010302@cs.pdx.edu> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> Message-ID: <4310375315.20080419001919@gmail.com> Hello Jim, Saturday, April 19, 2008, 12:10:23 AM, you wrote: > The other problem I had with concurrency is that I was getting about a > 50% speedup instead of the 99% or so that I'd expect on two cores. I 2 cores doesn't guarantee 2x speedup. some programs are limited by memory access speed and you still have just one memory :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From adam.smyczek at gmail.com Fri Apr 18 16:22:00 2008 From: adam.smyczek at gmail.com (Adam Smyczek) Date: Fri Apr 18 16:17:10 2008 Subject: [Haskell-cafe] HTTP and file upload In-Reply-To: References: Message-ID: <26E57BA9-053F-49F6-A5DA-CE2D54D236DB@gmail.com> Thanks for the snippet. Sorry, but my question was somehow mis-formulated. I was looking for a client-side implementation how to upload a file to any server using Haskell (mainly using the Browser module from HTTP package). Going through the Browser.hs source code a little, I and came up with the following implementation and your hpaste helped me to test it. The following code is just a small wrapper around the Browser module that adds support for multipart/form-data content type. It's more or less a prototype but works fine for me. Looking forward to suggestions how to improve it. Be gentle, it's beginner code :) Adam ------------------------------------------------------------------------ ----- -- | -- Wrapper around Network.Browser module with -- support for multipart/form-data content type -- ------------------------------------------------------------------------ ----- module ReviewBoard.Browser ( formToRequest, FormVar(..), Form(..) ) where import qualified Network.Browser as HB import Network.HTTP import Network.URI import Data.Char import Control.Monad.Writer import System.Random -- | Form to request for typed form variables -- formToRequest :: Form -> HB.BrowserAction Request formToRequest (Form m u vs) -- Use multipart/form-data content type when -- the form contains at least one FileUpload variable | or (map isFileUpload vs) = do bnd <- HB.ioAction mkBoundary (_, enc) <- HB.ioAction $ runWriterT $ multipartUrlEncodeVars bnd vs let body = concat enc return Request { rqMethod=POST , rqHeaders= [ Header HdrContentType $ "multipart/form-data; boundary=" ++ bnd, Header HdrContentLength (show . length $ body) ] , rqBody= body , rqURI=u } -- Otherwise fall back to Network.Browser | otherwise = return $ HB.formToRequest (HB.Form m u $ map toHVar vs) where -- Convert typed variables to Network.Browser variables toHVar (TextField n v) = (n, v) toHVar (FileUpload n f) = (n, f) toHVar (Checkbox n v) = (n, map toLower $ show v) -- Is file upload isFileUpload (FileUpload _ _) = True isFileUpload _ = False -- Create random boundary string mkBoundary = do rand <- randomRIO (100000000000 :: Integer, 999999999999) return $ "--------------------" ++ show rand -- | Encode variables, add boundary header and footer -- multipartUrlEncodeVars :: String -> [FormVar] -> RqsWriter () multipartUrlEncodeVars bnd vs = do mapM (\v -> tell ["--", bnd, "\r\n"] >> encodeVar v) vs tell ["--", bnd, "--", "\r\n"] -- | Encode variable based on type -- encodeVar :: FormVar -> RqsWriter () encodeVar (TextField n v) = defaultEncVar n v encodeVar (Checkbox n True) = defaultEncVar n "true" encodeVar (Checkbox n False) = defaultEncVar n "false" encodeVar (FileUpload n f) = do fc <- liftIO $ readFile f tell [ "Content-Disposition: form-data; name=\"", n, "\"; filename=\"", f, "\"\r\n" , "Content-Type: text/plain\r\n" -- TODO: add support for different types , "\r\n" , fc , "\r\n"] -- | Default encode method for name/value as string -- defaultEncVar :: String -> String -> RqsWriter () defaultEncVar n v = tell [ "Content-Disposition: form-data; name=\"", n, "\"\r\n" , "\r\n" , v , "\r\n"] -- ------------------------------------------------------------------------ --- -- Types -- | Request writer -- type RqsWriter a = WriterT [String] IO a -- | Typed form vars -- data FormVar = TextField String String | FileUpload String FilePath | Checkbox String Bool deriving Show -- | And the typed form -- data Form = Form RequestMethod URI [FormVar] On Apr 15, 2008, at 1:38 AM, Adrian Neumann wrote: > Yes > > http://hpaste.org/6990 > > Am 14.04.2008 um 19:07 schrieb Adam Smyczek: >> Is form based file upload supported in HTTP module (HTTP-3001.0.4)? >> >> Adam >> >> >> _______________________________________________ >> 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 From droundy at darcs.net Fri Apr 18 16:32:29 2008 From: droundy at darcs.net (David Roundy) Date: Fri Apr 18 16:27:36 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <4310375315.20080419001919@gmail.com> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> <4310375315.20080419001919@gmail.com> Message-ID: <20080418203222.GQ8763@darcs.net> On Sat, Apr 19, 2008 at 12:19:19AM +0400, Bulat Ziganshin wrote: > Saturday, April 19, 2008, 12:10:23 AM, you wrote: > > The other problem I had with concurrency is that I was getting about a > > 50% speedup instead of the 99% or so that I'd expect on two cores. I > > 2 cores doesn't guarantee 2x speedup. some programs are limited by > memory access speed and you still have just one memory :) In fact, this is relatively easily tested (albeit crudely): just run two copies of your single-threaded program at the same time. If they take longer than when run one at a time, you can guess that you're memory-limited, and you won't get such good performance from threading your code. But this is only a crude hint, since memory performance is strongly dependent on cache behavior, and running one threaded job may either do better or worse than two single-threaded jobs. If you've got two separate CPUs with two separate caches, the simultaneous single-threaded jobs should beat the threaded job (meaning take less than twice as long), since each job should have full access to one cache. If you've got two cores sharing a single cache, the behavior may be the opposite: the threaded job uses less total memory than the two single-threaded jobs, so more of the data may stay in cache. For reference, on a friend's dual quad-core Intel system (i.e. 8 cores total), if he runs 8 simultaneous (identical) memory-intensive job he only gets about five times the throughput of a job, meaning that each core is running at something like 60% of it's CPU capacity due to memory contention. It's possible that your system is comparably limited, although I'd be suprised, somehow it seems unlikely that your ray tracer is stressing the cache all that much. -- David Roundy Department of Physics Oregon State University From jsnow at cs.pdx.edu Fri Apr 18 17:09:28 2008 From: jsnow at cs.pdx.edu (Jim Snow) Date: Fri Apr 18 17:06:11 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <20080418203222.GQ8763@darcs.net> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> <4310375315.20080419001919@gmail.com> <20080418203222.GQ8763@darcs.net> Message-ID: <48090E08.1020109@cs.pdx.edu> David Roundy wrote: > On Sat, Apr 19, 2008 at 12:19:19AM +0400, Bulat Ziganshin wrote: > >> Saturday, April 19, 2008, 12:10:23 AM, you wrote: >> >>> The other problem I had with concurrency is that I was getting about a >>> 50% speedup instead of the 99% or so that I'd expect on two cores. I >>> >> 2 cores doesn't guarantee 2x speedup. some programs are limited by >> memory access speed and you still have just one memory :) >> > > In fact, this is relatively easily tested (albeit crudely): just run two > copies of your single-threaded program at the same time. If they take > longer than when run one at a time, you can guess that you're > memory-limited, and you won't get such good performance from threading your > code. But this is only a crude hint, since memory performance is strongly > dependent on cache behavior, and running one threaded job may either do > better or worse than two single-threaded jobs. If you've got two separate CPUs > with two separate caches, the simultaneous single-threaded jobs should beat the > threaded job (meaning take less than twice as long), since each job should > have full access to one cache. If you've got two cores sharing a single > cache, the behavior may be the opposite: the threaded job uses less total > memory than the two single-threaded jobs, so more of the data may stay in > cache. > > For reference, on a friend's dual quad-core Intel system (i.e. 8 cores > total), if he runs 8 simultaneous (identical) memory-intensive job he only > gets about five times the throughput of a job, meaning that each core is > running at something like 60% of it's CPU capacity due to memory > contention. It's possible that your system is comparably limited, although > I'd be suprised, somehow it seems unlikely that your ray tracer is > stressing the cache all that much. > On a particular scene with one instance of the single-threaded renderer running, it takes about 19 seconds to render an image. With two instances running, they each take about 23 seconds. This is on an Athlon-64 3800+ dual core, with 512kB of L2 cache per core. So, it seems my memory really is slowing things down noticeably. -jim From sebastian.sylvan at gmail.com Fri Apr 18 17:11:55 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Fri Apr 18 17:06:59 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <4809002F.8010302@cs.pdx.edu> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> Message-ID: <3d96ac180804181411g1bcb0dc0t63dbb98b0f13086d@mail.gmail.com> On Fri, Apr 18, 2008 at 9:10 PM, Jim Snow wrote: > The scene is shared between threads. (Complex scenes can be quite large.) > I'm assuming this is handled as a read-only shared memory region or > something similar, as one might expect, and is not actually copied. > Ah, when people say "shared memory concurrency", they usually mean shared *mutable* memory concurrency, which this isn't. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080418/24978ff8/attachment.htm From johan.tibell at gmail.com Fri Apr 18 17:19:04 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri Apr 18 17:20:47 2008 Subject: [Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> Message-ID: <90889fe70804181419t2036319bhbf9800d44db8d551@mail.gmail.com> First, apologies for not responding earlier. I spent my week at a conference in Austria. Second, thanks for all the feedback! I thought I go through some of my thoughts on the issues raised. Just to try to reiterate the goals of this effort: * To provide a common, no frills interface between web servers and applications or frameworks to increase choice for application developers. * To make that interface easy enough to implement so current web servers and frameworks will implement it. This is crucial for it being adopted. * Avoid design decisions that would limit the number of frameworks that can use the interface. One example of a limiting decisions would be one that limits the maximal possible performance by using e.g. inefficient data types. I'll try to start with what seems to be the easier issues. sendfile(2) support =================== I would like see this supported in the interface. I didn't include it in the first draft as I didn't have a good idea of where to put it. One idea would be to add the following field to the Environment record: sendfile :: Maybe (FD -> IO ()) Possibly with additional parameters as needed. The reason that sendfile needs to be included in the environment instead of just a binding to the C function is that the Socket used for the connection is hidden from the application side and its use is abstracted by the input and output enumerators. The other suggested solution (to return either an Enumerator or a file descriptor) might work better. I just wanted to communicate that I think it should be included. Extension HTTP methods ====================== I did have extension methods in mind when I wrote the draft but didn't include it. I see two possible options. 1. Change the HTTP method enumeration to: data Method = Get | ... | ExtensionMethod ByteString 2. Treat all methods as bytestrings: type Method = ByteString This treatment touches on the discussion on typing further down in this email. I still haven't thought enough about the consequences (if indeed there are any of any importance) of the two approaches. The Enumerator type =================== To recap, I proposed the following type for the Enumerator abstraction: type Enumerator = forall a. (a -> ByteString -> IO (Either a a)) -> a -> IO a The IO monad is a must both in the return type of the Enumerator function and in the iteratee function (i.e. the first parameter of the enumartor). IO in the return type of the enumerator is a must since the server must perform I/O (i.e. reading from the client socket) to provide the input and the application might need to perform I/O to create the response. The appearance of the IO monad in the iteratee functions is an optimization. It makes it possible for the server or application to act immediately when a chunk of data is received. This saves memory when large files are being sent as they can be written to disk/network immediately instead of being cached in memory. There are some different design (and possibly performance trade-offs) that could be made. The current enumerator type can be viewed as an unrolled State monad suggesting that it would be possible to change the type to: type Enumerator = forall t. MonadTrans t => (ByteString -> t IO (Either a a)) -> t IO a which is a more general type allowing for an arbitrary monad stack. Some arguments against doing this: * The unrolled state version is analogous to a left fold (and can indeed be seen as one) and should thus be familiar to all Haskell programmers. * A, possibly unfounded, worry I have is that it might be hard to optimize way the extra abstraction layer putting a performance tax on all applications, whether they use the extra flexibility or not. It would be great if any of the Takusen authors (or Oleg since he wrote the enumerator paper) could comment on this. Note: I haven't thought this one through. It was suggested to me on #haskell and I thought I should at least bring it up. Extra environment variables =========================== I've intended all along to include a field for remaining, optional extra pieces of information taken from e.g. the web server, the shell, etc. I haven't come up with an good name for this field by the idea is to add another field to the Environment: data Environment = Environment { ... , extraEnvironment :: [(ByteString, ByteString)] } Typing and data types ===================== Most discussions seem to, perhaps unsurprisingly, have centered around the use of data types and typing in general. Let me start by giving an assumptions I've used when writing this draft: Existing frameworks already have internal representations of the request URL, headers, etc. Changing these would be costly. Even if this was done I don't think it is possible to pick any one type that all frameworks could use to represent an HTTP requests or even parts of a request. Different frameworks need different types. Let me as an example use the Last-Modified header field. Assume we used named record fields for all headers: data Headers = Headers { ... , lastModified :: Maybe ??? } There is no type we could use for ??? that would be useful for all frameworks. There are several possible DateTime types possible with different design trade-offs. On the other hand, all frameworks likely already have a function to convert raw bytes to whatever internal representation used in that particular framework. Trying to provide more structured types that bytestrings appears to have two drawbacks: 1. It adds boiler plate type conversion code. No benefit is gained by the extra typing. Defining more types in the WAI interface adds complexity to the interface. 2. It adds an unnecessary performance penalty. My suggestions is this: We use a minimal number of types in the interface and leave it up to higher levels to add these. Summary ======= I suggest that the overall design principle should be this: Give a data type (e.g. Environment) with a minimal amount of structure corresponding to the one given in the HTTP RFC plus some extra optional environment provided by the web server and the environment (e.g. shell) in which it is run. I suggest we leave the raw bytestrings in the interface as interpreting them is best done by the framework. This also lends itself to an efficient implementation as the bytestrings in the environment could just be substrings (an O(1) operation) of the raw input read from the socket. Let me make a slight reservation here and say that I might want to split the URL into two parts (e.g. SCRIPT_NAME and PATH_INFO, like in CGI and WSGI). The reason for doing this is that it makes it much easier to nest applications by having each layer consuming one part of the URL and leave the rest to the nested application. For example, consider the task of writing an URL dispatcher that picks different applications depending on the URL prefix: storeApp, adminApp, urlMap :: Application urlMap = mkUrlMap [("/admin", adminApp) ,("/store", storeApp) ] serve :: Application -> IO () -- Provided by the web server. main = serve urlMap When a request for /store/items/1 reaches the URL mapper application it consumes the initial prefix (and puts it in scriptName) and leaves the remaining URL part in pathInfo. adminApp or storeApp can then use what's left in pathInfo to do further dispatching (to a handler function for example). Phew, this turned into a longer email than I thought. If I forgot to respond to any points raised please don't be afraid to raise them again. From droundy at darcs.net Fri Apr 18 17:34:06 2008 From: droundy at darcs.net (David Roundy) Date: Fri Apr 18 17:29:10 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <48090E08.1020109@cs.pdx.edu> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> <4310375315.20080419001919@gmail.com> <20080418203222.GQ8763@darcs.net> <48090E08.1020109@cs.pdx.edu> Message-ID: <20080418213405.GT8763@darcs.net> On Fri, Apr 18, 2008 at 02:09:28PM -0700, Jim Snow wrote: > On a particular scene with one instance of the single-threaded renderer > running, it takes about 19 seconds to render an image. With two > instances running, they each take about 23 seconds. This is on an > Athlon-64 3800+ dual core, with 512kB of L2 cache per core. So, it > seems my memory really is slowing things down noticeably. This doesn't mean there's no hope, it just means that you'll need to be extra-clever if you're to get a speedup that is close to optimal. The key to overcoming memory bandwidth issues is to think about cache use and figure out how to improve it. For instance, O(N^3) matrix multiplication can be done in close to O(N^2) time provided it's memory-limited, by blocking memory accesses so that you access less memory at once. In the case of ray-tracing I've little idea where or how you could improve memory access patterns, but this is what you should be thinking about (if you want to optimize this code). Of course, improving overall scaling is best (e.g. avoiding using lists if you need random access). Next I'd ask if there are more efficent or compact data structures that you could be using. If your program uses less memory, a greater fraction of that memory will fit into cache. Switching to stricter data structures and turning on -funbox-strict-fields (or whatever it's called) may help localize your memory access. Even better if you could manage to use unboxed arrays, so that your memory accesses really would be localized (assuming that you actually do have localize memory-access patterns). Of course, also ask yourself how much memory your program is using in total. If it's not much more than 512kB, for instance, we may have misdiagnosed your problem. -- David Roundy Department of Physics Oregon State University From bos at serpentine.com Fri Apr 18 17:36:32 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Apr 18 17:31:37 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <4809002F.8010302@cs.pdx.edu> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> Message-ID: <48091460.20604@serpentine.com> Jim Snow wrote: > The concurrency bug has to do with excessive memory use, and was > discussed earlier here on the mailing list (search for Glome). > http://hackage.haskell.org/trac/ghc/ticket/2185 Interesting. I looked at your test case. I can reproduce your problem when I build with the threaded runtime and run with a single core, but not if I use +RTS -N2. Did you overlook the possibility that you may not have told GHC how many cores to use? Also, your code is sprinkled with many more strictness annotations than it needs. References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> <4310375315.20080419001919@gmail.com> <20080418203222.GQ8763@darcs.net> <48090E08.1020109@cs.pdx.edu> <20080418213405.GT8763@darcs.net> Message-ID: <48092AB9.30405@cs.pdx.edu> David Roundy wrote: > On Fri, Apr 18, 2008 at 02:09:28PM -0700, Jim Snow wrote: > >> On a particular scene with one instance of the single-threaded renderer >> running, it takes about 19 seconds to render an image. With two >> instances running, they each take about 23 seconds. This is on an >> Athlon-64 3800+ dual core, with 512kB of L2 cache per core. So, it >> seems my memory really is slowing things down noticeably. >> > > This doesn't mean there's no hope, it just means that you'll need to be > extra-clever if you're to get a speedup that is close to optimal. The key > to overcoming memory bandwidth issues is to think about cache use and > figure out how to improve it. For instance, O(N^3) matrix multiplication > can be done in close to O(N^2) time provided it's memory-limited, by > blocking memory accesses so that you access less memory at once. > > In the case of ray-tracing I've little idea where or how you could improve > memory access patterns, but this is what you should be thinking about (if > you want to optimize this code). Of course, improving overall scaling is > best (e.g. avoiding using lists if you need random access). Next I'd ask > if there are more efficent or compact data structures that you could be > using. If your program uses less memory, a greater fraction of that memory > will fit into cache. Switching to stricter data structures and turning on > -funbox-strict-fields (or whatever it's called) may help localize your > memory access. Even better if you could manage to use unboxed arrays, so > that your memory accesses really would be localized (assuming that you > actually do have localize memory-access patterns). > > Of course, also ask yourself how much memory your program is using in > total. If it's not much more than 512kB, for instance, we may have > misdiagnosed your problem. > Interestingly, switching between "Float" and "Double" doesn't make any noticeable difference in speed (though I see more rendering artifacts with Float). Transformation matrices are memory hogs, at 24 floats each (a 4x4 matrix and its inverse with the bottom rows omitted (they're always 0 0 0 1)). This may be one reason why many real-time ray tracers just stick with triangles; a triangle can be transformed by transforming its verticies, and then you can throw the matrix away. There are a lot of tricks for making ray tracers more memory-coherent. You can trace packets of rays instead of single rays against whatever acceleration structure you may be using. Kd-tree nodes can be compacted to fit in a single cacheline if you arrange the tree in memory in a particular way that allows you to omit some of the pointers. (I use BIH trees, but the same ideas probably apply.) A lot of these sorts of tricks make the resulting code more complex and/or uglier. Useful references: "What Every Programmer Needs to Know About Memory" http://lwn.net/Articles/250967/ Siggraph presentation on optimizing ray tracers (warning: ppt) http://www.openrt.de/Siggraph05/UpdatedCourseNotes/Stoll_Realtime.ppt Bryan O'Sullivan wrote: > Jim Snow wrote: > > >> > The concurrency bug has to do with excessive memory use, and was >> > discussed earlier here on the mailing list (search for Glome). >> > http://hackage.haskell.org/trac/ghc/ticket/2185 >> > > Interesting. I looked at your test case. I can reproduce your problem > when I build with the threaded runtime and run with a single core, but > not if I use +RTS -N2. Did you overlook the possibility that you may > not have told GHC how many cores to use? > > I just tested it again. Memory usage behaves differently depending on how many cores I tell it to run on, but it always used the least memory when I compiled without threading support. With -N1 memory usage grows faster than -N2, but memory is smaller and doesn't grow larger with each re-render (except by a very small amount) if I don't use parmap. > Also, your code is sprinkled with many more strictness annotations than > it needs. > > That doesn't surprise me. I haven't really figured out why somethings are faster strict or not strict, or where it doesn't matter or the annotations are redundant. -jim From dons at galois.com Fri Apr 18 19:25:53 2008 From: dons at galois.com (Don Stewart) Date: Fri Apr 18 19:21:20 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <48092AB9.30405@cs.pdx.edu> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> <4310375315.20080419001919@gmail.com> <20080418203222.GQ8763@darcs.net> <48090E08.1020109@cs.pdx.edu> <20080418213405.GT8763@darcs.net> <48092AB9.30405@cs.pdx.edu> Message-ID: <20080418232553.GR3462@scytale.galois.com> jsnow: > David Roundy wrote: > >On Fri, Apr 18, 2008 at 02:09:28PM -0700, Jim Snow wrote: > > > >>On a particular scene with one instance of the single-threaded renderer > >>running, it takes about 19 seconds to render an image. With two > >>instances running, they each take about 23 seconds. This is on an > >>Athlon-64 3800+ dual core, with 512kB of L2 cache per core. So, it > >>seems my memory really is slowing things down noticeably. > >> > > > >This doesn't mean there's no hope, it just means that you'll need to be > >extra-clever if you're to get a speedup that is close to optimal. The key > >to overcoming memory bandwidth issues is to think about cache use and > >figure out how to improve it. For instance, O(N^3) matrix multiplication > >can be done in close to O(N^2) time provided it's memory-limited, by > >blocking memory accesses so that you access less memory at once. > > > >In the case of ray-tracing I've little idea where or how you could improve > >memory access patterns, but this is what you should be thinking about (if > >you want to optimize this code). Of course, improving overall scaling is > >best (e.g. avoiding using lists if you need random access). Next I'd ask > >if there are more efficent or compact data structures that you could be > >using. If your program uses less memory, a greater fraction of that > >memory > >will fit into cache. Switching to stricter data structures and turning on > >-funbox-strict-fields (or whatever it's called) may help localize your > >memory access. Even better if you could manage to use unboxed arrays, so > >that your memory accesses really would be localized (assuming that you > >actually do have localize memory-access patterns). > > > >Of course, also ask yourself how much memory your program is using in > >total. If it's not much more than 512kB, for instance, we may have > >misdiagnosed your problem. > > > Interestingly, switching between "Float" and "Double" doesn't make any > noticeable difference in speed (though I see more rendering artifacts > with Float). Transformation matrices are memory hogs, at 24 floats each > (a 4x4 matrix and its inverse with the bottom rows omitted (they're > always 0 0 0 1)). This may be one reason why many real-time ray tracers > just stick with triangles; a triangle can be transformed by transforming > its verticies, and then you can throw the matrix away. The only differences I'd expect to see here would be with -fvia-C -fexcess-precision -O2 -optc-O2 which might trigger some SSE stuff from the C compiler From ryani.spam at gmail.com Sat Apr 19 00:29:14 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sat Apr 19 00:24:17 2008 Subject: [Haskell-cafe] I hate Haskell's typeclasses Message-ID: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> WARNING: RANT AHEAD. Hopefully this fires off some productive discussion on how to fix these problems! Don't get me wrong: I think the idea of typeclasses is great. Their implementation in Haskell comes so close to being awesome and then falls short, and that's almost worse than not being awesome in the first place! Some examples of things I think you should be able to do, that just Do Not Work. Examples like these are trivial in many other languages, and they shouldn't be that hard here, either! 1) You can't make sensible default implementations. For example, it'd be nice to make all my Monads be Applicatives and Functors without resorting to Template Haskell or infinite boilerplate. Why can't I just write this? instance Monad m => Applicative m where pure = return (<*>) = ap Sure, I get that there might be ambiguity of which instance to choose. But why not warn me about that ambiguity, or let me choose somehow on a case-by-case basis when it happens? 2) You can't add sensible superclasses. I was playing with QuickCheck and wanted to write "equal with regards to testing". So I wrote up a class for it: class TestableEq a where (~=) :: a -> a -> Property instance Eq a => TestableEq a where -- should be a superclass of Eq instead! a ~= b = a == b instance (Arbitrary a, TestableEq b) => TestableEq (a -> b) where f ~= g = forAll arbitrary (\a -> f a ~= g a) But this doesn't work without overlapping & undecidable instances! Sure, there is an alternative: I could manually declare instances of TestableEq for EVERY SINGLE TYPE that is an instance of Eq. I am sure nobody here would actually suggest that I do so. And sure, these extensions are both safe here, because the intent is that you won't declare instances of TestableEq for things that are already instances of Eq, and you won't do something stupid like "instance TestableEq a => Eq a". But why do I need to jump through these hoops for a perfectly safe & commonly desired operation? 3) There's no reflection or ability to choose an implementation based on other constraints. In QuickCheck, (a -> b) is an instance of Arbitrary for appropriate a, b. But you can't use this instance in forAll or for testing functions without being an instance of Show. Now, this is probably a design mistake, but it's the right choice with the current typeclass system (see (2)). But it'd be a million times better to have something like the following: class Arbitrary a => MkArbitrary a where mkArbitrary :: Gen (a, String) case instance MkArbitrary a where Show a => mkArbitrary = do x <- arbitrary return (x, show x) otherwise => mkArbitrary = do st <- getGenState x <- arbitrary return (x, "evalGen arbitrary " ++ show st) With this, QuickCheck could print reproducible test cases painlessly without adding the requirement that everything is an instance of Show! Now, you could say that mkArbitrary should be a member function of Arbitrary, but then you clutter up your instance definitions with tons of "mkArbitrary = defaultMkArbitrary" for types that have a Show instance. 4) Every concrete type should be an instance of Typeable without having to do anything, and Typeable should give you typecase & reflection: genericShow :: Typeable a => a -> String genericShow x = typecase x of String -> x (Show t => t) -> show x -- any instance of Show _ -> "" -- ryan P.S. I'd actually love to work on any or all of these problems, but I can't get GHC to compile! See http://hpaste.org/5878 From jonathanccast at fastmail.fm Sat Apr 19 01:01:13 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Sat Apr 19 00:56:22 2008 Subject: [Haskell-cafe] I hate Haskell's typeclasses In-Reply-To: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> References: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> Message-ID: <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> On 18 Apr 2008, at 9:29 PM, Ryan Ingram wrote: > WARNING: RANT AHEAD. WARNING: RESPONSE IN THE SPIRIT OF THE ORIGINAL AHEAD. > Hopefully this fires off some productive > discussion on how to fix these problems! {-# GHC_OPTIONS -foverlapping-instances -fundecidable-instances #-} :) What you want to work is precisely what this allows. > Don't get me wrong: I think the idea of typeclasses is great. Their > implementation in Haskell comes so close to being awesome and then > falls short, and that's almost worse than not being awesome in the > first place! We've noticed. The literature on extending Haskell type classes is, um, enormous. > > Some examples of things I think you should be able to do, that just Do > Not Work. Examples like these are trivial in many other languages, I call. Name a language that is a) Completely statically typed (no type errors at runtime), b) Has an ad-hoc overloading mechanism powerful enough to encode Num and Monad, and c) Is substantially better than Haskell + extensions for your examples. The examples aren't all that long; comparison code snippets shouldn't be all that long either. > and they shouldn't be that hard here, either! > > 1) You can't make sensible default implementations. For example, it'd > be nice to make all my Monads be Applicatives and Functors without > resorting to Template Haskell or infinite boilerplate. Why can't I > just write this? > > instance Monad m => Applicative m where > pure = return > (<*>) = ap > > Sure, I get that there might be ambiguity of which instance to choose. > But why not warn me about that ambiguity, or let me choose somehow on > a case-by-case basis when it happens? You can already choose on a case-by-case basis. In this specific case, you can only think of one super-instance, but I can think of another: instance Arrow a => Applicative (a alpha) where pure = arr . const a <*> b = (a &&& b) >>> arr ($) I think Conal Elliot's recent work of FRP can be extended to show that Fudgets-style stream processors can be made instances of Applicative by both these methods, with different instances. So as soon as both are present, you have to choose the instance you want every time. Having something like this spring up and bite you because of a change in some library you pulled off of Haddock does not make for maintainable code. More generally, specifying what you want is really not hard. Do you really have gazillions of monads in your code you have to repeat this implementation for? > 2) You can't add sensible superclasses. I was playing with QuickCheck > and wanted to write "equal with regards to testing". So I wrote up a > class for it: > > class TestableEq a where > (~=) :: a -> a -> Property > > instance Eq a => TestableEq a where > -- should be a superclass of Eq instead! > a ~= b = a == b Again, this is one (*) line per type. How many types do you declare? > instance (Arbitrary a, TestableEq b) => TestableEq (a -> b) where > f ~= g = forAll arbitrary (\a -> f a ~= g a) > > But this doesn't work without overlapping & undecidable instances! > > Sure, there is an alternative: I could manually declare instances of > TestableEq for EVERY SINGLE TYPE that is an instance of Eq. I am sure > nobody here would actually suggest that I do so. Bzzzt. Wrong. Thanks for playing! > And sure, these extensions are both safe here, because the intent What? By that reasoning, perl is `safe'. Haskell is not perl. > is > that you won't declare instances of TestableEq for things that are > already instances of Eq, and you won't do something stupid like > "instance TestableEq a => Eq a". > > But why do I need to jump through these hoops for a perfectly safe & > commonly desired operation? It's called a proof obligation. Haskell is not here to stop you from jumping through hoops. In fact, it is here precisely to force you to jump through hoops. That's why it's called a bondage and discipline language. > 3) There's no reflection or ability to choose an implementation based > on other constraints. > > In QuickCheck, (a -> b) is an instance of Arbitrary for appropriate a, > b. But you can't use this instance in forAll or for testing functions > without being an instance of Show. Now, this is probably a design > mistake, but it's the right choice with the current typeclass system > (see (2)). But it'd be a million times better to have something like > the following: > > class Arbitrary a => MkArbitrary a where > mkArbitrary :: Gen (a, String) > > case instance MkArbitrary a where > Show a => > mkArbitrary = do > x <- arbitrary > return (x, show x) > otherwise => > mkArbitrary = do > st <- getGenState > x <- arbitrary > return (x, "evalGen arbitrary " ++ show st) So we compile in a table of every instance and every datatype, add a Typeable constraint to forAll (since parametricity just got shot to heck), and scan through that table on every test. Millions of times better. And slower. And more likely to develop odd changes and hard- to-debug errors. > With this, QuickCheck could print reproducible test cases painlessly > without adding the requirement that everything is an instance of Show! QuickCheck makes testing so easy, I think the Arbitrary (a -> b) instance is almost unnecessary; (btw., functions /are/ instances of Show). You can easily write a showable ADT encoding the functions you want to test. > Now, you could say that mkArbitrary should be a member function of > Arbitrary, but then you clutter up your instance definitions with tons > of "mkArbitrary = defaultMkArbitrary" for types that have a Show > instance. Thousands and thousands of pounds! You have too many types. Look for ways to re-factor, and move your duplication into functors. > 4) Every concrete type should be an instance of Typeable without > having to do anything, Sure. And seq should go back to being a class method. (See earlier about parametricity being shot to heck). I have an excellent design which will preserve the language's semantics (which are fine the way they are, thank you), while being convenient for programmers, which this margin is too small to contain.[1] > and Typeable should give you typecase & > Type case is easy: genericShow :: Typeable a => a -> String genericShow x = fromJust $ do s <- cast x :: Maybe String return s `mplus` do n <- cast x :: Maybe Int return (show n) `mplus` do return "" > reflection: > genericShow :: Typeable a => a -> String > genericShow x = typecase x of > String -> x > (Show t => t) -> show x -- any instance of Show > _ -> "" Reflection is harder, because of the need for the lookup table with every instance of every class I mentioned earlier. (And you get to figure out how to encode polymorphic instances, too! Good luck[2]). jcc [1, 2] These are the non-sarcastic bits. From duncan.coutts at worc.ox.ac.uk Sat Apr 19 03:10:32 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Apr 19 03:05:33 2008 Subject: [Haskell-cafe] HTTP and file upload In-Reply-To: <26E57BA9-053F-49F6-A5DA-CE2D54D236DB@gmail.com> References: <26E57BA9-053F-49F6-A5DA-CE2D54D236DB@gmail.com> Message-ID: <1208589032.5960.35.camel@dell.linuxdev.us.dell.com> On Fri, 2008-04-18 at 13:22 -0700, Adam Smyczek wrote: > The following code is just a small wrapper around the Browser module > that adds support for multipart/form-data content type. It's more or > less a prototype but works fine for me. Looking forward to suggestions > how to improve it. Be gentle, it's beginner code :) You may like to compare it with the code that 'cabal upload' uses for uploading tarballs to hackage: http://darcs.haskell.org/cabal-install/Hackage/Upload.hs I don't claim our code is perfect, you may have some suggestions for us! :-) Duncan From david.maciver at gmail.com Sat Apr 19 08:02:12 2008 From: david.maciver at gmail.com (David MacIver) Date: Sat Apr 19 07:57:15 2008 Subject: [Haskell-cafe] I hate Haskell's typeclasses In-Reply-To: <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> References: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> Message-ID: Independently of the rant... On Sat, Apr 19, 2008 at 6:01 AM, Jonathan Cast wrote: > > But why do I need to jump through these hoops for a perfectly safe & > > commonly desired operation? > > > > It's called a proof obligation. Haskell is not here to stop you from > jumping through hoops. In fact, it is here precisely to force you to jump > through hoops. That's why it's called a bondage and discipline language. Surely it's there to lovingly assist you through the hoops? You can't just force people not to do the wrong thing and expect to get a good statically typed language out of it - you have to make it easier for them to do the right thing. From niklas.broberg at gmail.com Sat Apr 19 08:57:23 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sat Apr 19 08:52:31 2008 Subject: [Haskell-cafe] Help with associated types In-Reply-To: <4807401C.7060006@cs.chalmers.se> References: <4807401C.7060006@cs.chalmers.se> Message-ID: Hi Emil, On 4/17/08, Emil Axelsson wrote: > Hello! > > I'm trying to rewrite some FD classes to use associated types instead. The > Port class is for type structures whose leaves have the same type: > > class Port p > where > type Leaf p > type Struct p > toList :: p -> [Leaf p] > fromList :: [Leaf p] -> p > > (Leaf p) gives the leaf type, and (Struct p) gives a canonical > representation of the structure regardless of leaf type. Here we just > instantiate two leaf types: > > instance Port Int > where > type Leaf Int = Int > type Struct Int = () > toList a = [a] > fromList [a] = a > > instance Port Bool > where > type Leaf Bool = Bool > type Struct Bool = () > toList a = [a] > fromList [a] = a > > There's also a function for mapping over ports: > > mapPort :: > ( Port pa > , Port pb > , Struct pa ~ Struct pb > ) => > (Leaf pa -> Leaf pb) -> (pa -> pb) > > mapPort f = fromList . map f . toList > > The equality constraint makes sure that we're mapping between equal > structures. When I try to run this, I get: > > *Main> mapPort even (5::Int) > > :1:8: > No instance for (Integral (Leaf Int)) > ... > the problem here is that Leaf p doesn't determine p, e.g. there can be many different types p for which Leaf p = Int. It has nothing to do with the Struct type. > What's the easiest way to encode that pb can be inferred from (Struct pb) > and (Leaf pb)? If you want the dependency Leaf p -> p then Leaf needs to be injective, i.e. you need to use an accociated datatype rather than just a type. Here's a sketch that shows this: class Port p where data Leaf p -- note the use of data here type Struct p toList :: p -> [Leaf p] fromList :: [Leaf p] -> p instance Port Int where newtype Leaf Int = IntLeaf Int type Struct Int = () toList a = [IntLeaf a] fromList [IntLeaf a] = a instance Port Bool where newtype Leaf Bool = BoolLeaf Bool type Struct Bool = () toList a = [BoolLeaf a] fromList [BoolLeaf a] = a mapPort :: ( Port pa , Port pb , Struct pa ~ Struct pb ) => (Leaf pa -> Leaf pb) -> (pa -> pb) mapPort f = fromList . map f . toList The problem now is of course that the arguments to f will now be a lot more complex, since the Leaf type is more complex. So to call this you would have to say *Port> let f (IntLeaf n) = BoolLeaf (even n) in mapPort f 1 False Not very pretty, but that's the way it goes if you want that dependency. So in the general case, > If I have a class with some dependencies, say > > a -> ..., b c -> ... > > Is it possible to encode this using associated types without having all of a, b > and c as class parameters? Yes it can be done, if you use associated *datatypes* instead of associated types. But as you can see, it introduces extra overhead. Cheers, /Niklas From isaacdupree at charter.net Sat Apr 19 09:45:22 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat Apr 19 09:40:28 2008 Subject: [Haskell-cafe] C++ interface with Haskell In-Reply-To: <2518b95d0804181208j3c369e85nc012557c777f6e2e@mail.gmail.com> References: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> <4806A4F6.4090404@charter.net> <7981f6330804170941r3e19a0d0v93ae0d0d05c33d12@mail.gmail.com> <6a7c66fc0804180633l1bfe91ccrcbc7148ba8ae91cf@mail.gmail.com> <4808BDFC.7060100@charter.net> <1875521233.20080418204001@gmail.com> <2518b95d0804181208j3c369e85nc012557c777f6e2e@mail.gmail.com> Message-ID: <4809F772.2050606@charter.net> Evan Laforge wrote: > To threadjack a little bit, I've been interfacing haskell with c++. > It gets awkward when the c++ structures use STL types like string and > vector. Of course those are too complex for haskell to marshal to. > > What I've been doing is defining an XMarshal variant of the X c++ > class, that uses plain c arrays. Then I marshal to that, and > construct the c++ object properly from XMarshal in the c->c++ wrapper > layer. On a few occasions, when the c++ class is really big and only > has one STL member, I make a partially constructed c++ object, pass > the array separately, and then construct the proper c++ class from the > broken haskell generated one. Possibly dangerous as all get-out > because I'm dealing with "unconstructed" c++ objects, but it seems to > work. you mean, you hack around with the internal representation of those structures? Well, if you want to avoid double-copying, C++ can't access Haskell sequences, and Haskell can't access C++ sequences, I guess I don't see an alternative. > Passing back to haskell is easier since I can use "&*vec.begin()", > which according to the internet should be safe because STL guarantees > that vector contents are contiguous. safe until either: the vector's contents change, if Haskell is assuming it's immutable, or more seriously, if the vector's length is changed, the pointers are invalidated and it might crash (due to reallocating for a bigger continuous memory chunk) > I'm only saved by the fact that I don't have that many different kinds > of classes to pass. This would be much more drudgery if I had more. > Does anyone have a better solution or convention for marshalling c++ > objects? not "better", but, you could wrap the methods of the class and call back into C++ (through C wrappers) to do anything with the class, if it suited your purposes better and wasn't too slow > I've also noticed warnings from g++ about hsc2hs's use of the OFFSETOF > macro on c++ classes, but some googling of g++ mailing lists implied > that it's harmless if you don't have virtual bases, and what sane > person does, so I suppress it now :) > From andrewcoppin at btinternet.com Sat Apr 19 10:56:10 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Apr 19 10:50:59 2008 Subject: [Haskell-cafe] Parallel weirdness Message-ID: <480A080A.4080205@btinternet.com> OK, so just for fun, I decided to try implementing a parallel merge sort using the seq and par combinators. My plan was to generate some psuedo-random data and time how long it takes to sort it. To try to account for lazy evaluation, what the program actually does is this: 1. Write the input data to disk without any sorting. (This ought to force it to be fully evaluated.) 2. Sort and save the data to disk 8 times. (So I can average the runtimes.) This is done with two data sets - one with 1 million items, and another with 2 million rows. Each data set is run through both the purely sequential algorithm and a simple parallel one. (Split the list in half, merge-sort each half in parallel, and then merge them.) The results of this little benchmark utterly defy comprehension. Allow me to enumerate: Weird thing #1: The first time you sort the data, it takes a few seconds. The other 7 times, it takes a split second - roughly 100x faster. Wuh? Weird thing #2: The parallel version runs *faster* than the sequential one in all cases - even with SMP disabled! (We're only talking a few percent faster, but still.) Weird thing #3: Adding the "-threaded" compiler option makes *everything* run a few percent faster. Even with only 1 OS thread. Weird thing #4: Adding "-N2" makes *everything* slow down a few percent. In particular, Task Manager shows only one CPU core in use. Adding more than 2 OS threads makes everything slow down even further - but that's hardly surprising. Can anybody explain any of this behaviour? I have no idea what I'm benchmarking, but it certainly doesn't appear to be the performance of a parallel merge sort! From dbueno at gmail.com Sat Apr 19 11:01:51 2008 From: dbueno at gmail.com (Denis Bueno) Date: Sat Apr 19 10:56:53 2008 Subject: [Haskell-cafe] Parallel weirdness In-Reply-To: <480A080A.4080205@btinternet.com> References: <480A080A.4080205@btinternet.com> Message-ID: <6dbd4d000804190801j382c55e0w70241be5463dbcb0@mail.gmail.com> On Sat, Apr 19, 2008 at 10:56 AM, Andrew Coppin wrote: > Can anybody explain any of this behaviour? I have no idea what I'm > benchmarking, but it certainly doesn't appear to be the performance of a > parallel merge sort! It would be much easier to draw sound conclusions if you would post your code. -- Denis From andrewcoppin at btinternet.com Sat Apr 19 11:03:35 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Apr 19 10:58:23 2008 Subject: [Haskell-cafe] Parallel weirdness [code] In-Reply-To: <6dbd4d000804190801j382c55e0w70241be5463dbcb0@mail.gmail.com> References: <480A080A.4080205@btinternet.com> <6dbd4d000804190801j382c55e0w70241be5463dbcb0@mail.gmail.com> Message-ID: <480A09C7.7080304@btinternet.com> Denis Bueno wrote: > It would be much easier to draw sound conclusions if you would post your code. > Erm... good point. See attachments. -------------- next part -------------- module Sort where import Control.Parallel import Control.Parallel.Strategies split0 [] = [] split0 (x:xs) = x : split1 xs split1 [] = [] split1 (x:xs) = split0 xs merge xs [] = xs merge [] ys = ys merge (x:xs) (y:ys) | x < y = x : merge xs (y:ys) | otherwise = y : merge (x:xs) ys msort [] = [] msort [x] = [x] msort xs = let xs0 = msort (split0 xs) xs1 = msort (split1 xs) in merge xs0 xs1 msortP [] = [] msortP [x] = [x] msortP xs = let xs0 = msort (split0 xs) xs1 = msort (split1 xs) in seqList rwhnf xs0 `par` seqList rwhnf xs1 `seq` merge xs0 xs1 list = [5,4,6,3,7,2,8,1,9,0] -------------- next part -------------- module Time where import System.CPUTime time :: IO () -> IO Integer time fn = do t0 <- getCPUTime fn t1 <- getCPUTime return (t1 - t0) ps_ms = 1000000000 :: Integer ps_s = ps_ms * 1000 :: Integer -------------- next part -------------- module Main where import Data.Word import System.IO import GHC.Conc (numCapabilities) import Sort import Time type Test = (String,[Word32]) random = iterate (\x -> 1664525 * x + 1013904223) 7 :: [Word32] test1m = ("1M",take 1000000 random) test2m = ("2M",take 2000000 random) type Algo = (String, [Word32] -> [Word32]) algo_seq_msort = ("MergeSortSeq", msort) algo_par_msort = ("MergeSortPar", msortP) dump :: [Word32] -> String dump = unlines . map show run_tests :: Algo -> Test -> IO () run_tests (name,fn) (title,xs) = do echo "\n" let f1 = name ++ "--" ++ title ++ "--In.txt" echo $ "Writing '" ++ f1 ++ "'..."; hFlush stdout nullT <- time (writeFile f1 (dump xs)) echo $ " Took " ++ show (nullT `div` ps_ms) ++ " ms.\n" mapM_ (\n -> do let f2 = name ++ "--" ++ title ++ "--Out" ++ show n ++ ".txt" echo $ "Writing '" ++ f2 ++ "'..."; hFlush stdout sortT <- time (writeFile f2 (dump (fn xs))) echo $ " Took " ++ show (sortT `div` ps_ms) ++ " ms.\n" ) [1..8] echo msg = do hPutStr stdout msg hPutStr stderr msg main = do echo $ "CPU threads = " ++ show numCapabilities ++ ".\n" mapM_ (\test -> mapM_ (\algo -> run_tests algo test) [algo_seq_msort, algo_par_msort] ) [test1m, test2m] From dry.green.tea at gmail.com Sat Apr 19 11:05:18 2008 From: dry.green.tea at gmail.com (Alexis Hazell) Date: Sat Apr 19 11:00:28 2008 Subject: [Haskell-cafe] Re. intro to FDs - thanks! Message-ID: <20080419150518.GH4999@mischief.78net> Thanks to all who helped me with my query about functional dependencies - much appreciated. And special thanks to Bulat for reminding me that the GHC user guide is more than just a user guide. :-) Alexis. From bulat.ziganshin at gmail.com Sat Apr 19 11:10:37 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Apr 19 11:08:05 2008 Subject: [Haskell-cafe] Parallel weirdness In-Reply-To: <480A080A.4080205@btinternet.com> References: <480A080A.4080205@btinternet.com> Message-ID: <1741635235.20080419191037@gmail.com> Hello Andrew, Saturday, April 19, 2008, 6:56:10 PM, you wrote: > OK, so just for fun, I decided to try implementing a parallel merge sort coincedence - now i'm writing a parallel compression algorithm, very much like parallel bzip2, but using ghc, of course > Weird thing #1: The first time you sort the data, it takes a few > seconds. The other 7 times, it takes a split second - roughly 100x > faster. Wuh? this looks like disk caching effects. if data are read from disj on first run and from disk cache on the next runs, this only means that your algorithm works faster than reading its data from disk > Weird thing #2: The parallel version runs *faster* than the sequential > one in all cases - even with SMP disabled! (We're only talking a few > percent faster, but still.) > Weird thing #3: Adding the "-threaded" compiler option makes > *everything* run a few percent faster. Even with only 1 OS thread. there are plenty of reasons: first, -threaded make i/o overlapped with calculations. second, parallel version may exhibit better cpu cache behavior - such as processing all data in cache before sending it back to memory > Weird thing #4: Adding "-N2" makes *everything* slow down a few percent. > In particular, Task Manager shows only one CPU core in use. it's easy - your algorithm isn't really parallel, and you just forced ghc to move it from one core to another. it's overhead of moving data around :) > Can anybody explain any of this behaviour? I have no idea what I'm > benchmarking, but it certainly doesn't appear to be the performance of a > parallel merge sort! there are many subtle effects making optimization much more interesting than using simple schemas ;) it's why i like it so much :)) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From mgross21 at verizon.net Sat Apr 19 11:53:03 2008 From: mgross21 at verizon.net (Murray Gross) Date: Sat Apr 19 11:35:06 2008 Subject: [Haskell-cafe] Parallel weirdness In-Reply-To: <480A080A.4080205@btinternet.com> References: <480A080A.4080205@btinternet.com> Message-ID: I can't offer definite answers to your questions, but I can suggest a few issues you should consider: 1. Merge sort doesn't parallelize all that well--when the blocks are small, the parallelization overhead is large in comparison with the productive work that is to be done, and when the blocks get large, the amount of parallelization possible is not great. Quicksort and quickersort, of course, suffer from the same issue. The end result is that your timings will be heavily dependent on your hardware, software, and the properties of the particular data set you use for testing. 2. You need to account for I/O buffering (not only by your OP system in RAM, but by your disk controller)--after the first set of I/O operations, your data may be in buffers, so subsequent uses may retrieve data from buffers rather than from the disk itself. Similarly, you also have to take into account paging and cache issues, which could make the first run much slower than immediate subsequent runs. 3. A better benchmark would be provided by a counting sort, which does parallelize well (O(n * (n/k), where k is the number of processors, and n is the number of elements to be sorted). A major advantage of using a counting sort for benchmarking is that it runs slowly enough to make it relatively easy to compare sequential and parallel timings. 4. Depending on your system defaults, there may also be memory allocation issues that need to be taken into account (which could also easily cause the first run to be considerably slower than subsequent runs made immediately after the first). Murray Gross Brooklyn College On Sat, 19 Apr 2008, Andrew Coppin wrote: > OK, so just for fun, I decided to try implementing a parallel merge sort > using the seq and par combinators. My plan was to generate some psuedo-random > data and time how long it takes to sort it. To try to account for lazy > evaluation, what the program actually does is this: > > 1. Write the input data to disk without any sorting. (This ought to force it > to be fully evaluated.) > 2. Sort and save the data to disk 8 times. (So I can average the runtimes.) > > This is done with two data sets - one with 1 million items, and another with > 2 million rows. Each data set is run through both the purely sequential > algorithm and a simple parallel one. (Split the list in half, merge-sort each > half in parallel, and then merge them.) > > The results of this little benchmark utterly defy comprehension. Allow me to > enumerate: > > Weird thing #1: The first time you sort the data, it takes a few seconds. The > other 7 times, it takes a split second - roughly 100x faster. Wuh? > > Weird thing #2: The parallel version runs *faster* than the sequential one in > all cases - even with SMP disabled! (We're only talking a few percent faster, > but still.) > > Weird thing #3: Adding the "-threaded" compiler option makes *everything* run > a few percent faster. Even with only 1 OS thread. > > Weird thing #4: Adding "-N2" makes *everything* slow down a few percent. In > particular, Task Manager shows only one CPU core in use. > > Adding more than 2 OS threads makes everything slow down even further - but > that's hardly surprising. > > Can anybody explain any of this behaviour? I have no idea what I'm > benchmarking, but it certainly doesn't appear to be the performance of a > parallel merge sort! > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From andrewcoppin at btinternet.com Sat Apr 19 11:50:30 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Apr 19 11:45:27 2008 Subject: [Haskell-cafe] Parallel weirdness In-Reply-To: <1741635235.20080419191037@gmail.com> References: <480A080A.4080205@btinternet.com> <1741635235.20080419191037@gmail.com> Message-ID: <480A14C6.8070800@btinternet.com> Bulat Ziganshin wrote: > >> Weird thing #1: The first time you sort the data, it takes a few >> seconds. The other 7 times, it takes a split second - roughly 100x >> faster. Wuh? >> > > this looks like disk caching effects. if data are read from disj on > first run and from disk cache on the next runs, this only means that > your algorithm works faster than reading its data from disk > Negative. No data is ever *read* from disk, only *written* to disk. (And each test writes to a different file.) The data to be sorted is generated using a trivial LCG PRNG. > there are plenty of reasons: first, -threaded make i/o overlapped > with calculations. Not with -N1. > second, parallel version may exhibit better cpu > cache behavior - such as processing all data in cache before sending > it back to memory > Again, with -N1, it is *still* only using 1 CPU core. >> Weird thing #4: Adding "-N2" makes *everything* slow down a few percent. >> In particular, Task Manager shows only one CPU core in use. >> > > it's easy - your algorithm isn't really parallel. > Fails to explain why the parallel version is faster than the sequential one (even with no parallelism), or why the sequential algorithm should slow down with more threads. (Surely the extra threads just sit idle?) > there are many subtle effects making optimization much more interesting > than using simple schemas ;) it's why i like it so much :)) > Well, based on the results I've seen so far, it seems that parallelism is a complete waste of time because it doesn't gain you anything. And that doesn't make a lot of sense... From jake.mcarthur at gmail.com Sat Apr 19 11:55:17 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Sat Apr 19 11:50:31 2008 Subject: [Haskell-cafe] Parallel weirdness In-Reply-To: <480A080A.4080205@btinternet.com> References: <480A080A.4080205@btinternet.com> Message-ID: <9D01C1B4-4DCC-426E-8934-F76ECD5348AD@gmail.com> On Apr 19, 2008, at 9:56 AM, Andrew Coppin wrote: > Weird thing #3: Adding the "-threaded" compiler option makes > *everything* run a few percent faster. Even with only 1 OS thread. I had a similar thing happen to me once. (http://geekrant.wordpress.com/2007/11/29/holy-shmoly-ghc-does-some-magic-all-by-itself/ ) It bothered me at the time, but as Simon Marlow said in the comments: > I wouldn?t believe these figures too much. I couldn?t repeat the > same effects here, but since this is such a tiny fragment of code, > small effects are magnified, and differences can sometimes appear > and disappear depending the day of the week. - Jake McArthur From bulat.ziganshin at gmail.com Sat Apr 19 12:04:48 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Apr 19 12:01:47 2008 Subject: [Haskell-cafe] Parallel weirdness In-Reply-To: <480A14C6.8070800@btinternet.com> References: <480A080A.4080205@btinternet.com> <1741635235.20080419191037@gmail.com> <480A14C6.8070800@btinternet.com> Message-ID: <759903091.20080419200448@gmail.com> Hello Andrew, Saturday, April 19, 2008, 7:50:30 PM, you wrote: >> this looks like disk caching effects. if data are read from disj on >> first run and from disk cache on the next runs, this only means that >> your algorithm works faster than reading its data from disk >> > Negative. No data is ever *read* from disk, only *written* to disk. (And > each test writes to a different file.) > The data to be sorted is generated using a trivial LCG PRNG. if you don't generate new data for each sorting run, this means that data generation is much slower than sorting. don't forget about ghc laziness :) >> there are plenty of reasons: first, -threaded make i/o overlapped >> with calculations. > Not with -N1. are you sure? :) afaik, -threaded RTS uses dedicated i/o thread despite of -N setting (which controls only amount of threads running *user* code) >> second, parallel version may exhibit better cpu >> cache behavior - such as processing all data in cache before sending >> it back to memory >> > Again, with -N1, it is *still* only using 1 CPU core. parallel version is different from sequential one and it process data in another order. for example, imagine tar+gzip algorithm which runs sequentially and write intermediate results to the disk. the same algorithm, being multithreaded, will compress data on the fly and don't store intermediate data to the HDD despite using only one core. the same effect applies to cpu cache usage >>> Weird thing #4: Adding "-N2" makes *everything* slow down a few percent. >>> In particular, Task Manager shows only one CPU core in use. >>> >> >> it's easy - your algorithm isn't really parallel. >> > Fails to explain why the parallel version is faster than the sequential > one (even with no parallelism), or why the sequential algorithm should > slow down with more threads. (Surely the extra threads just sit idle?) there are management overheads. with multiple worker threads you have many OS threads which fights for the right to execute single Haskell thread :)) >> there are many subtle effects making optimization much more interesting >> than using simple schemas ;) it's why i like it so much :)) >> > Well, based on the results I've seen so far, it seems that parallelism > is a complete waste of time because it doesn't gain you anything. And > that doesn't make a lot of sense... i made world fastest compression program using multithreading, so the problem is definitely on other side ;) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jake.mcarthur at gmail.com Sat Apr 19 12:17:16 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Sat Apr 19 12:12:23 2008 Subject: [Haskell-cafe] Parallel weirdness In-Reply-To: <480A080A.4080205@btinternet.com> References: <480A080A.4080205@btinternet.com> Message-ID: Okay, here are my thoughts: On Apr 19, 2008, at 9:56 AM, Andrew Coppin wrote: > Weird thing #1: The first time you sort the data, it takes a few > seconds. The other 7 times, it takes a split second - roughly 100x > faster. Wuh? This looks like standard memoization to me. I know, I know, GHC doesn't automagically memoize? it still has some behaviors I personally would label as a sort of primitive memoization, and this is one of them. I learned about this by losing an argument. ;) > Weird thing #2: The parallel version runs *faster* than the > sequential one in all cases - even with SMP disabled! (We're only > talking a few percent faster, but still.) > Weird thing #3: Adding the "-threaded" compiler option makes > *everything* run a few percent faster. Even with only 1 OS thread. I think these are not noteworthy. Weird things happen in benchmarks (which is why I have learned not to trust them). > Weird thing #4: Adding "-N2" makes *everything* slow down a few > percent. In particular, Task Manager shows only one CPU core in use. Then your algorithm must not truly be parallel. That is the only explanation I can think of. - Jake McArthur From allbery at ece.cmu.edu Sat Apr 19 12:24:03 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Apr 19 12:19:07 2008 Subject: [Haskell-cafe] Parallel weirdness In-Reply-To: <480A14C6.8070800@btinternet.com> References: <480A080A.4080205@btinternet.com> <1741635235.20080419191037@gmail.com> <480A14C6.8070800@btinternet.com> Message-ID: <88B17875-0A33-4192-A7D6-443C4C735D51@ece.cmu.edu> On Apr 19, 2008, at 11:50 , Andrew Coppin wrote: > Bulat Ziganshin wrote: >> there are plenty of reasons: first, -threaded make i/o overlapped >> with calculations. > > Not with -N1. Depending on how it's implemented (I not being a ghc guru), possibly even with -N1 as long as it's using the thread-capable runtime. (Note that "make -j2" is known to be optimal on single-processor machines, specifically because I/O tends to overlap with CPU.) >> second, parallel version may exhibit better cpu >> cache behavior - such as processing all data in cache before sending >> it back to memory > > Again, with -N1, it is *still* only using 1 CPU core. And again, this may well be an effect of using the thread-*capable* runtime. You can't generally multiplex memory accesses in SMP, so you may well want to delay and batch operations to/from main memory as much as possible to reduce lock contention for memory access. > Well, based on the results I've seen so far, it seems that > parallelism is a complete waste of time because it doesn't gain you > anything. And that doesn't make a lot of sense... Easy parallelism is still an unsolved problem; naive parallelism generally is no better than sequential and often worse, because naive parallelism generally fails to account for lock / resource contention. (Note that resource locking will be done by the threaded runtime even with only one thread, so you will see some slowdowns especially in I/O-related code.) Haskell can only help you so much with this; you need to design your algorithms to parallel properly. In addition, laziness can result in naive parallelism being a no-op because the only thing parallelized is some operation that trivially returns a lazy thunk that is later forced in the main thread. Careful strictness analysis is necessary in non-strict languages to make sure you are actually parallelizing what you want to. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From bulat.ziganshin at gmail.com Sat Apr 19 12:28:22 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Apr 19 12:25:22 2008 Subject: [Haskell-cafe] Parallel weirdness In-Reply-To: <88B17875-0A33-4192-A7D6-443C4C735D51@ece.cmu.edu> References: <480A080A.4080205@btinternet.com> <1741635235.20080419191037@gmail.com> <480A14C6.8070800@btinternet.com> <88B17875-0A33-4192-A7D6-443C4C735D51@ece.cmu.edu> Message-ID: <166105844.20080419202822@gmail.com> Hello Brandon, Saturday, April 19, 2008, 8:24:03 PM, you wrote: > contention. (Note that resource locking will be done by the threaded > runtime even with only one thread, so you will see some slowdowns > especially in I/O-related code.) yes, i forget about this. Simon wrote once that locking decrease performance by a few percents compared to single-threaded runtime -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From qdunkan at gmail.com Sat Apr 19 12:30:43 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Sat Apr 19 12:25:44 2008 Subject: [Haskell-cafe] C++ interface with Haskell In-Reply-To: <4809F772.2050606@charter.net> References: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> <4806A4F6.4090404@charter.net> <7981f6330804170941r3e19a0d0v93ae0d0d05c33d12@mail.gmail.com> <6a7c66fc0804180633l1bfe91ccrcbc7148ba8ae91cf@mail.gmail.com> <4808BDFC.7060100@charter.net> <1875521233.20080418204001@gmail.com> <2518b95d0804181208j3c369e85nc012557c777f6e2e@mail.gmail.com> <4809F772.2050606@charter.net> Message-ID: <2518b95d0804190930g47dec4e8s2fa58d03cafa9647@mail.gmail.com> > you mean, you hack around with the internal representation of those > structures? Well, if you want to avoid double-copying, C++ can't access > Haskell sequences, and Haskell can't access C++ sequences, I guess I don't > see an alternative. I don't really mind double copying, but having to declare c variants (i.e. no stl) of all the c++ structures and then copy from one to the other is a little tedious. I was hoping there was some clever trick to make that easier... > > Passing back to haskell is easier since I can use "&*vec.begin()", > > which according to the internet should be safe because STL guarantees > > that vector contents are contiguous. > > > > safe until either: > the vector's contents change, if Haskell is assuming it's immutable, Well, naturally I peekArray before letting c++ have it back. > > I'm only saved by the fact that I don't have that many different kinds > > of classes to pass. This would be much more drudgery if I had more. > > Does anyone have a better solution or convention for marshalling c++ > > objects? > > > > not "better", but, you could wrap the methods of the class and call back > into C++ (through C wrappers) to do anything with the class, if it suited > your purposes better and wasn't too slow Yeah, I was thinking of that, but it seemed like even more of a hassle. However, a more practical variant might be to write a haskell interface to marshal to vectors and strings, probably involving some void pointer sketchiness since naturally template types can't be expressed in a C function signature, and then poke those into the struct when I pass it. That would only work for vectors stored by pointer of course. From allbery at ece.cmu.edu Sat Apr 19 12:31:44 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Apr 19 12:26:48 2008 Subject: [Haskell-cafe] Parallel weirdness In-Reply-To: References: <480A080A.4080205@btinternet.com> Message-ID: <9942B6CF-AF6D-4AB7-977A-24ACDB844B28@ece.cmu.edu> On Apr 19, 2008, at 11:53 , Murray Gross wrote: > 2. You need to account for I/O buffering (not only by your OP > system in RAM, but by your disk controller)--after the first set of > I/O operations, your data may be in buffers, so subsequent uses may > retrieve data from buffers rather than from the disk itself. > Similarly, you also have to take into account paging and cache > issues, which could make the first run much slower than immediate > subsequent runs. Note also that, unless you use SCSI or very high-end SATA drives, they ignore requests to disable buffering. (References on request, you can probably find them by poking around http://www.pdl.cmu.edu/. Short summary: consumer drives are optimized for benchmarks, not for data safety. This is why early 32-bit Windows releases often lost data on shutdown until the shutdown was modified to sleep for 10-15 seconds.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From isaacdupree at charter.net Sat Apr 19 13:27:44 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat Apr 19 13:22:48 2008 Subject: [Haskell-cafe] C++ interface with Haskell In-Reply-To: <2518b95d0804190930g47dec4e8s2fa58d03cafa9647@mail.gmail.com> References: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> <4806A4F6.4090404@charter.net> <7981f6330804170941r3e19a0d0v93ae0d0d05c33d12@mail.gmail.com> <6a7c66fc0804180633l1bfe91ccrcbc7148ba8ae91cf@mail.gmail.com> <4808BDFC.7060100@charter.net> <1875521233.20080418204001@gmail.com> <2518b95d0804181208j3c369e85nc012557c777f6e2e@mail.gmail.com> <4809F772.2050606@charter.net> <2518b95d0804190930g47dec4e8s2fa58d03cafa9647@mail.gmail.com> Message-ID: <480A2B90.3050509@charter.net> you could write a C++ function to marshal a Sequence (or any Container IIRC, maybe Forward Container) to a vector (or whatever you wanted -- there are choices), and then okay let's see if I remember C++ well enough This design has extra copying. but anyway template std::vector container_to_vector(Container const& c) { return std::vector(c.begin(), c.end()); } and template Container vector_to_sequence(std::vector const& c) { return Container(c.begin(), c.end()); } extern "C" { /* the temporary returned variable doesn't last long enough here */ (char*, int)/*I know C++ doesn't have this syntax of tuples*/ string_to_array(std::string const& s) { return (&*container_to_vector(s).begin()) } } In other words I suspect that it's possible with a minimum of boilerplate per type, (possibly including the use of macros), but I'm not sure exactly what you need to do, and I got tired of being a C++-fu expert a few years ago From a.biurvOir4 at asuhan.com Sat Apr 19 14:11:31 2008 From: a.biurvOir4 at asuhan.com (Kim-Ee Yeoh) Date: Sat Apr 19 14:06:33 2008 Subject: [Haskell-cafe] Wrong Answer Computing Graph Dominators In-Reply-To: <4808F58B.8050703@imageworks.com> References: <6dbd4d000804151759r2ca72957hae8cd60c91404e60@mail.gmail.com> <20080416183356.GA4362@zombie.inf.tu-dresden.de> <6dbd4d000804170832h1391db15ob84e61d4e8960170@mail.gmail.com> <6dbd4d000804171413h54c33f35sdb1c9554d4d4c9@mail.gmail.com> <4807C6AB.3050902@imageworks.com> <16760156.post@talk.nabble.com> <1208497238.30072.1248551899@webmail.messagingengine.com> <4808F58B.8050703@imageworks.com> Message-ID: <16786100.post@talk.nabble.com> Dan Weston wrote: > > f . and == and . map f > where f = (not x ||) > > If and is defined with foldr, then the above can be proven for all > well-typed f, and for f = (not x ||) in particular, even if ys is null. > The law is painlessly extended to cover the null case automatically (and > is therefore consistent): > > LHS: not x || (and []) == not x || True == True > RHS: and (map (not x ||) []) == and [] == True > Therefore True |- True, an instance of x |- x > > If (and [] == False), then the law becomes inconsistent: > -- snipped -- Yes, the natural way of defining and [] is, well, natural in more than one sense of the word. I initially had a hard time grasping what you meant with the 3 equations that started this discussion. I was sure you meant something other than what I thought, but I couldn't work it out. I'm glad Matt Brecknell came to the rescue. Before I would've merely relied on a monoidal identity argument like the one Chris had presented. Appealing to uniformity (a la parametric polymorphism) definitely looks sexier. All the cool kids seem to be doing it. -- View this message in context: http://www.nabble.com/Wrong-Answer-Computing-Graph-Dominators-tp16714477p16786100.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From anton at appsolutions.com Sat Apr 19 14:55:30 2008 From: anton at appsolutions.com (Anton van Straaten) Date: Sat Apr 19 14:44:52 2008 Subject: [Haskell-cafe] I hate Haskell's typeclasses In-Reply-To: References: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> Message-ID: <480A4022.3050809@appsolutions.com> David MacIver wrote: > Independently of the rant... > > On Sat, Apr 19, 2008 at 6:01 AM, Jonathan Cast > wrote: >>> But why do I need to jump through these hoops for a perfectly safe & >>> commonly desired operation? >>> >> It's called a proof obligation. Haskell is not here to stop you from >> jumping through hoops. In fact, it is here precisely to force you to jump >> through hoops. That's why it's called a bondage and discipline language. > > Surely it's there to lovingly assist you through the hoops? From what I've read, B&D relationships can be quite loving, despite appearances. And Haskell has safewords you can use if the pain gets too intense, like unsafePerformIO. Just be sure to get the capitalization right, or Mistress Haskell will punish you again with a "not in scope" message. At which point it's customary to fix the error, and reinvoke the compiler while saying "Thank you ma'am, may I have another?" From vigalchin at gmail.com Sat Apr 19 15:50:46 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat Apr 19 15:45:48 2008 Subject: [Haskell-cafe] "publishing" a Haskell package Message-ID: <5ae4f2ba0804191250o278ee544i7ea4affaaf1cbce5@mail.gmail.com> Hello, In the past someone sent me a URL on how to formally "publish" Haskell work for public review and consumption. Does anyone have his link? Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080419/c83edf06/attachment.htm From dons at galois.com Sat Apr 19 15:54:20 2008 From: dons at galois.com (Don Stewart) Date: Sat Apr 19 15:49:23 2008 Subject: [Haskell-cafe] "publishing" a Haskell package In-Reply-To: <5ae4f2ba0804191250o278ee544i7ea4affaaf1cbce5@mail.gmail.com> References: <5ae4f2ba0804191250o278ee544i7ea4affaaf1cbce5@mail.gmail.com> Message-ID: <20080419195420.GA30241@scytale.galois.com> vigalchin: > Hello, > > In the past someone sent me a URL on how to formally "publish" > Haskell work for public review and consumption. Does anyone have his link? > > Regards, Vasili As usual, all answers can be found on haskell.org, http://haskell.org/haskellwiki/How_to_write_a_Haskell_program From andrewcoppin at btinternet.com Sat Apr 19 16:09:40 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Apr 19 16:04:29 2008 Subject: [Haskell-cafe] Parallel weirdness In-Reply-To: <166105844.20080419202822@gmail.com> References: <480A080A.4080205@btinternet.com> <1741635235.20080419191037@gmail.com> <480A14C6.8070800@btinternet.com> <88B17875-0A33-4192-A7D6-443C4C735D51@ece.cmu.edu> <166105844.20080419202822@gmail.com> Message-ID: <480A5184.3030709@btinternet.com> Bulat Ziganshin wrote: > Hello Brandon, > > Saturday, April 19, 2008, 8:24:03 PM, you wrote: > > >> contention. (Note that resource locking will be done by the threaded >> runtime even with only one thread, so you will see some slowdowns >> especially in I/O-related code.) >> > > yes, i forget about this. Simon wrote once that locking decrease > performance by a few percents compared to single-threaded runtime > ...which is why I'm so damned surprised that the threaded RTS is *faster* than the monoprocessor RTS [which presumably lacks such locking overhead]. From andrewcoppin at btinternet.com Sat Apr 19 16:16:20 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Apr 19 16:11:07 2008 Subject: [Haskell-cafe] Parallel weirdness In-Reply-To: <759903091.20080419200448@gmail.com> References: <480A080A.4080205@btinternet.com> <1741635235.20080419191037@gmail.com> <480A14C6.8070800@btinternet.com> <759903091.20080419200448@gmail.com> Message-ID: <480A5314.6090207@btinternet.com> Bulat Ziganshin wrote: > Hello Andrew, > > Saturday, April 19, 2008, 7:50:30 PM, you wrote: > > >> The data to be sorted is generated using a trivial LCG PRNG. >> > > if you don't generate new data for each sorting run, this means that > data generation is much slower than sorting. don't forget about ghc > laziness :) > ...which is why the unsorted data is written to disk *before* I attempt to sort it. This is to ensure it's fully evaluated, and give me some idea how long it takes to write to disk. The [first] sorting stage is about 10x slower than the initial writing stage - and yet, subsequent sorting is 10x faster than the initial unsorted write. >> Not with -N1. >> > > are you sure? :) afaik, -threaded RTS uses dedicated i/o thread > despite of -N setting (which controls only amount of threads running > *user* code) > Interesting. Without consulting a GHC RTS expert, I guess there's no way to know. Certainly I doubt my program is I/O-bounded. It only writes about 11 MB of data to a text file. I would think converting Word32 -> String is the slow part. >> Again, with -N1, it is *still* only using 1 CPU core. >> > > parallel version is different from sequential one and it process data > in another order. Yeah, perhaps it improves RAM usage or something... >> Fails to explain why the parallel version is faster than the sequential >> one (even with no parallelism), or why the sequential algorithm should >> slow down with more threads. (Surely the extra threads just sit idle?) >> > > there are management overheads. with multiple worker threads you have > many OS threads which fights for the right to execute single Haskell > thread :)) > As I understand it, sparked work is placed into a FIFO queue, and a set of worker threads poll this queue, remove the first item and begin executing. There is no "fighting"; once a work item has been picked by a thread, it runs to completion. Now, if there are more OS threads than physical CPU cores, they will fight it out at the OS level who runs first... ;-) From dons at galois.com Sat Apr 19 16:41:49 2008 From: dons at galois.com (Don Stewart) Date: Sat Apr 19 16:36:54 2008 Subject: [Haskell-cafe] Strange message from GHC In-Reply-To: References: Message-ID: <20080419204149.GB30241@scytale.galois.com> Cool message -- forward it to Simon PJ to get more info. cdsmith: > I'm running into this in some code I wrote. What does it mean? It says > to look at -fspec-constr-count, but that flag doesn't seem to be in the > GHC documentation. It's fairly new -- you can get explosions in the number of specialisations with Specconstr sometimes, and iirc this tunes that value. > This isn't critical; the code still seems to work fine. It just makes > the build uglier. > > Thanks. Message below. > > > SpecConstr: too many specialisations for one function (see -fspec-constr- > count): > Function: main:Expr.simplifyTerm{v rqC} [lid] > Specialisations: [([sc_s2wb{v} [lid], sc_s2wc{v} [lid], > sc_s2wd{v} [lid], sc_s2we{v} [lid], sc_s2wf{v} > [lid], > sc_s2wg{v} [lid]], > [main:Expr.Graph{v r51} [gid] > sc_s2wg{v} [lid] > sc_s2wf{v} [lid] > sc_s2we{v} [lid] > sc_s2wd{v} [lid], > base:GHC.Base.:{(w) v 65} [gid] > @ main:Expr.Gen{tc r53} > (main:Expr.Edge{v r4Q} [gid] sc_s2wc{v} [lid]) > sc_s2wb{v} [lid]]), > ([sc_s2wh{v} [lid], sc_s2wi{v} [lid], sc_s2wj{v} > [lid], > sc_s2wk{v} [lid], sc_s2wl{v} [lid], sc_s2wm{v} > [lid]], > [main:Expr.Graph{v r51} [gid] > sc_s2wm{v} [lid] > sc_s2wl{v} [lid] > sc_s2wk{v} [lid] > sc_s2wj{v} [lid], > base:GHC.Base.:{(w) v 65} [gid] > @ main:Expr.Gen{tc r53} > (main:Expr.Ghost{v r4P} [gid] sc_s2wi{v} [lid]) > sc_s2wh{v} [lid]]), > ([sc_s2wR{v} [lid], sc_s2wS{v} [lid], sc_s2wT{v} > [lid]], > [sc_s2wT{v} [lid], > base:GHC.Base.:{(w) v 65} [gid] > @ main:Expr.Gen{tc r53} > (main:Expr.Vertex{v r4R} [gid] sc_s2wS{v} [lid]) > sc_s2wR{v} [lid]]), > ([sc_s2wU{v} [lid], sc_s2wV{v} [lid], sc_s2wW{v} > [lid]], > [sc_s2wW{v} [lid], > base:GHC.Base.:{(w) v 65} [gid] > @ main:Expr.Gen{tc r53} > (main:Expr.Vertex{v r4R} [gid] > (base:GHC.Base.I#{(w) v 6d} [gid] sc_s2wV{v} > [lid])) > sc_s2wU{v} [lid]])] > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From andrewcoppin at btinternet.com Sat Apr 19 16:52:21 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Apr 19 16:47:08 2008 Subject: [Haskell-cafe] Parallel weirdness [update] In-Reply-To: <480A080A.4080205@btinternet.com> References: <480A080A.4080205@btinternet.com> Message-ID: <480A5B85.2020004@btinternet.com> Andrew Coppin wrote: > The results of this little benchmark utterly defy comprehension. Allow > me to enumerate: > > Weird thing #1: The first time you sort the data, it takes a few > seconds. The other 7 times, it takes a split second - roughly 100x > faster. Wuh? The test data was a CAF. I changed it to a regular function, and this behaviour vanished. Now *all* runs of a given test take approximately the same amount of time (to within a few ms anyway). > Weird thing #2: The parallel version runs *faster* than the sequential > one in all cases - even with SMP disabled! (We're only talking a few > percent faster, but still.) Now the parallel version is only faster with 1 worker thread. With more (even just 2) it becomes *slower* than the sequential version. Interestingly, it *does* now seem to be using more than 50% CPU. So it seems to actually be doing more work, just less efficiently. My first guess would be that it's creating data in a different order and thus stressing the GC more or something. Or maybe it's just that the algorithm sparks millions of really *tiny* items, which waste a lot of time. (It's a very simple implementation, so I was somewhat expecting this.) I'll try tuning further... > Weird thing #3: Adding the "-threaded" compiler option makes > *everything* run a few percent faster. Even with only 1 OS thread. Still true. > Weird thing #4: Adding "-N2" makes *everything* slow down a few > percent. In particular, Task Manager shows only one CPU core in use. Adding -N2 does still slow everything down, but not by very much. (Except the truely parallel stuff - that shows quite a big slowdown.) Task Manager does now show about 60% CPU usage instead of 50%. (I have exactly 2 physical cores.) From jsnow at cs.pdx.edu Sat Apr 19 17:09:02 2008 From: jsnow at cs.pdx.edu (Jim Snow) Date: Sat Apr 19 18:06:12 2008 Subject: [Haskell-cafe] announce: Glome-hs-0.4.1 (Haskell raytracer, now with cabal support) In-Reply-To: <20080418184327.GB3462@scytale.galois.com> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> Message-ID: <480A5F6E.70701@cs.pdx.edu> Don Stewart wrote: > jsnow: > >> A new version of my raytracer is out... >> > > Very impressive. Did you consider cabalising the Haskell code, so it > can be easily distributed from hackage.haskell.org? > > ... > > -- Don > A new version is up on hackage now: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/glome-hs In addition to the cabal conversion, it has a few bug fixes, performance improvements, and various code cleanups relative to version 0.3. If anyone has any problems with it, let me know. -jim From niklas.broberg at gmail.com Sat Apr 19 20:31:09 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sat Apr 19 20:26:09 2008 Subject: [Haskell-cafe] Ann: Win32-notify 0.1 Message-ID: Hi all, I wanted to use hinotify, which gives notifications on file system changes, but found (quite naturally) that it wouldn't run on my windows machine (since it's a binding to the linux kernel). So I started writing a library that would give similar functionality on Windows. This is the first release of that, more a proof-of-concept than anything useful at this stage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Win32-notify-0.1 Still, feel free to test it, and I would love feedback on everything from desired API to suggestions on how to implement the low-level bindings more efficiently. Cheers, /Niklas From wchogg at gmail.com Sat Apr 19 20:37:50 2008 From: wchogg at gmail.com (Creighton Hogg) Date: Sat Apr 19 20:32:51 2008 Subject: [Haskell-cafe] Problems with "Bananas" Message-ID: <814617240804191737m1d35f250rf7f507e412ec1220@mail.gmail.com> Hi, This isn't about Haskell per se, but I was reading the old Meijer et al. paper "Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire" & I think there's a notational pun that's really confusing me. On page 12 we have the CataEval equation (|phi|) . in = phi . (|phi|)_L Now, the subscript L & the following example of cons lists implies that L is a functor in this equation, yet the line immediately after this equation says that "(CataEval) states how to evaluate an application of (|phi|) to an arbitrary element of L...." so then that makes it sound like the L here is the fixed point of some functor F, not the functor itself. I'm sure I'm just being dumb, but this is really bugging me. Thanks, Creighton Hogg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080419/9c165a78/attachment.htm From ross at soi.city.ac.uk Sat Apr 19 21:00:59 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Apr 19 20:56:07 2008 Subject: [Haskell-cafe] Problems with "Bananas" In-Reply-To: <814617240804191737m1d35f250rf7f507e412ec1220@mail.gmail.com> References: <814617240804191737m1d35f250rf7f507e412ec1220@mail.gmail.com> Message-ID: <20080420010059.GA4634@soi.city.ac.uk> On Sat, Apr 19, 2008 at 07:37:50PM -0500, Creighton Hogg wrote: > This isn't about Haskell per se, but I was reading the old Meijer et al. paper > "Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire" & I > think there's a notational pun that's really confusing me. > On page 12 we have the CataEval equation > (|phi|) . in = phi . (|phi|)_L > Now, the subscript L & the following example of cons lists implies that L is a > functor in this equation, yet the line immediately after this equation says > that "(CataEval) states how to evaluate an application of (|phi|) to an > arbitrary element of L...." so then that makes it sound like the L here is the > fixed point of some functor F, not the functor itself. Yes, the explanatory text should say mu L instead of L. From conal at conal.net Sat Apr 19 22:33:58 2008 From: conal at conal.net (Conal Elliott) Date: Sat Apr 19 22:28:59 2008 Subject: [Haskell-cafe] Ann: Win32-notify 0.1 In-Reply-To: References: Message-ID: Hi Niklas, I'd love to see this functionality available cross-platform. Are there plans for a unified library with a single API? Cheers, - Conal On Sat, Apr 19, 2008 at 5:31 PM, Niklas Broberg wrote: > Hi all, > > I wanted to use hinotify, which gives notifications on file system > changes, but found (quite naturally) that it wouldn't run on my > windows machine (since it's a binding to the linux kernel). So I > started writing a library that would give similar functionality on > Windows. This is the first release of that, more a proof-of-concept > than anything useful at this stage: > > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Win32-notify-0.1 > > Still, feel free to test it, and I would love feedback on everything > from desired API to suggestions on how to implement the low-level > bindings more efficiently. > > Cheers, > > /Niklas > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080419/bfccbb21/attachment.htm From jonathanccast at fastmail.fm Sat Apr 19 23:46:29 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Sat Apr 19 23:41:35 2008 Subject: [Haskell-cafe] I hate Haskell's typeclasses In-Reply-To: References: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> Message-ID: <164F2F50-F66B-44AF-9CF2-E628142BFB35@fastmail.fm> On 19 Apr 2008, at 5:02 AM, David MacIver wrote: > Independently of the rant... > > On Sat, Apr 19, 2008 at 6:01 AM, Jonathan Cast > wrote: >>> But why do I need to jump through these hoops for a perfectly safe & >>> commonly desired operation? >>> >> >> It's called a proof obligation. Haskell is not here to stop you >> from >> jumping through hoops. In fact, it is here precisely to force you >> to jump >> through hoops. That's why it's called a bondage and discipline >> language. > > Surely it's there to lovingly assist you through the hoops? You can't > just force people not to do the wrong thing and expect to get a good > statically typed language out of it - you have to make it easier for > them to do the right thing. I think going through the hoop is paramount in Haskell. That's why Haskell is pure, for example, even though it (still) requires awkward code on occasion. Haskell is certainly designed to make getting through the hoops as easy as possible, but never by providing a general way around them. (unsafePerformIO notwithstanding). jcc From fmartini at gmail.com Sun Apr 20 05:13:17 2008 From: fmartini at gmail.com (Felix Martini) Date: Sun Apr 20 05:08:17 2008 Subject: [Haskell-cafe] Ann: Win32-notify 0.1 In-Reply-To: References: Message-ID: <6c0416190804200213q6702d380u745719523f24eb2d@mail.gmail.com> Conal Elliott: > I'd love to see this functionality available cross-platform. Are there > plans for a unified library with a single API? +1 It would be nice if the two inotify packages and this one could be combined. And if someone would add a kqueue backend for the BSD's and OSX then most platforms would be supported. From niklas.broberg at gmail.com Sun Apr 20 05:14:20 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Apr 20 05:09:26 2008 Subject: [Haskell-cafe] Ann: Win32-notify 0.1 In-Reply-To: References: Message-ID: > I'd love to see this functionality available cross-platform. Are there > plans for a unified library with a single API? Yep, that's the plan (not too far) down the line, me and Lennart (who wrote the hinotify bindings) have already discussed it to some extent. I think the work order will be - get a decent API for Win32-notify up. - create a cross-platform single-API package on top of Win32-notify and hinotify. - go back to Win32-notify and make the implementation less naive. So API suggestions would be most welcome! Cheers, /Niklas From david.maciver at gmail.com Sun Apr 20 06:05:38 2008 From: david.maciver at gmail.com (David MacIver) Date: Sun Apr 20 06:00:38 2008 Subject: [Haskell-cafe] I hate Haskell's typeclasses In-Reply-To: <164F2F50-F66B-44AF-9CF2-E628142BFB35@fastmail.fm> References: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> <164F2F50-F66B-44AF-9CF2-E628142BFB35@fastmail.fm> Message-ID: On Sun, Apr 20, 2008 at 4:46 AM, Jonathan Cast wrote: > > On 19 Apr 2008, at 5:02 AM, David MacIver wrote: > > > Independently of the rant... > > > > On Sat, Apr 19, 2008 at 6:01 AM, Jonathan Cast > > wrote: > > > > > > > > > But why do I need to jump through these hoops for a perfectly safe & > > > > commonly desired operation? > > > > > > > > > > > > > > It's called a proof obligation. Haskell is not here to stop you from > > > jumping through hoops. In fact, it is here precisely to force you to > jump > > > through hoops. That's why it's called a bondage and discipline > language. > > > > > > > Surely it's there to lovingly assist you through the hoops? You can't > > just force people not to do the wrong thing and expect to get a good > > statically typed language out of it - you have to make it easier for > > them to do the right thing. > > > > I think going through the hoop is paramount in Haskell. That's why Haskell > is pure, for example, even though it (still) requires awkward code on > occasion. Haskell is certainly designed to make getting through the hoops > as easy as possible, but never by providing a general way around them. > (unsafePerformIO notwithstanding). Sure. I'm just saying, it's more of a "Jump through this hoop and you shall have moist, delicious cake. And by the way, here's a leg up" set up. There are rewards for the hoop jumping, and assistance on the way there (which is more than can be said for a lot of languages which make you jump through hoops) :-) I think I might be stretching the analogy slightly. From bulat.ziganshin at gmail.com Sun Apr 20 07:51:49 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Apr 20 07:49:47 2008 Subject: [Haskell-cafe] C++ interface with Haskell In-Reply-To: <20080418200811.GE3462@scytale.galois.com> References: <7981f6330804160058s161f8bd1w10cd1cdbc6a5f08d@mail.gmail.com> <4806A4F6.4090404@charter.net> <7981f6330804170941r3e19a0d0v93ae0d0d05c33d12@mail.gmail.com> <6a7c66fc0804180633l1bfe91ccrcbc7148ba8ae91cf@mail.gmail.com> <4808BDFC.7060100@charter.net> <1875521233.20080418204001@gmail.com> <2518b95d0804181208j3c369e85nc012557c777f6e2e@mail.gmail.com> <20080418200811.GE3462@scytale.galois.com> Message-ID: <1909079884.20080420155149@gmail.com> Hello Don, Saturday, April 19, 2008, 12:08:11 AM, you wrote: > Would someone like to summarise the current approaches > to combining Haskell & C++ on the Haskell wiki, even if just in bullet > points? started at http://haskell.org/haskellwiki/IO_inside#Interfacing_with_foreign_evil -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jonathanccast at fastmail.fm Sun Apr 20 11:07:42 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Sun Apr 20 11:02:46 2008 Subject: [Haskell-cafe] I hate Haskell's typeclasses In-Reply-To: References: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> <164F2F50-F66B-44AF-9CF2-E628142BFB35@fastmail.fm> Message-ID: <1BE63616-8508-4363-9C3F-844A77FC4189@fastmail.fm> On 20 Apr 2008, at 3:05 AM, David MacIver wrote: > On Sun, Apr 20, 2008 at 4:46 AM, Jonathan Cast > wrote: >> >> On 19 Apr 2008, at 5:02 AM, David MacIver wrote: >> >>> Independently of the rant... >>> >>> On Sat, Apr 19, 2008 at 6:01 AM, Jonathan Cast >>> wrote: >>> >>>> >>>>> But why do I need to jump through these hoops for a perfectly >>>>> safe & >>>>> commonly desired operation? >>>>> >>>>> >>>> >>>> It's called a proof obligation. Haskell is not here to stop >>>> you from >>>> jumping through hoops. In fact, it is here precisely to force >>>> you to >> jump >>>> through hoops. That's why it's called a bondage and discipline >> language. >>>> >>> >>> Surely it's there to lovingly assist you through the hoops? You >>> can't >>> just force people not to do the wrong thing and expect to get a good >>> statically typed language out of it - you have to make it easier for >>> them to do the right thing. >>> >> >> I think going through the hoop is paramount in Haskell. That's >> why Haskell >> is pure, for example, even though it (still) requires awkward code on >> occasion. Haskell is certainly designed to make getting through >> the hoops >> as easy as possible, but never by providing a general way around >> them. >> (unsafePerformIO notwithstanding). > > Sure. I'm just saying, it's more of a "Jump through this hoop and you > shall have moist, delicious cake. And by the way, here's a leg up" set > up. There are rewards for the hoop jumping, and assistance on the way > there (which is more than can be said for a lot of languages which > make you jump through hoops) :-) Absolutely. But I think the original rant strayed into the realm of wanting the cake and the leg up /without/ the hoop. > > I think I might be stretching the analogy slightly. There is nothing the least bit wrong with that. jcc From andrewcoppin at btinternet.com Sun Apr 20 11:17:23 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun Apr 20 11:12:11 2008 Subject: [Haskell-cafe] I hate Haskell's typeclasses In-Reply-To: References: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> <164F2F50-F66B-44AF-9CF2-E628142BFB35@fastmail.fm> Message-ID: <480B5E83.9060903@btinternet.com> David MacIver wrote: > Sure. I'm just saying, it's more of a "Jump through this hoop and you > shall have moist, delicious cake. And by the way, here's a leg up" set > up. There are rewards for the hoop jumping, and assistance on the way > there (which is more than can be said for a lot of languages which > make you jump through hoops) :-) > > I think I might be stretching the analogy slightly. > THE CAKE IS A LIE!! (Sorry, couldn't resist... I'll try not to do that again.) From bos at serpentine.com Sun Apr 20 12:22:21 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sun Apr 20 12:17:22 2008 Subject: [Haskell-cafe] Ann: Win32-notify 0.1 In-Reply-To: References: Message-ID: <480B6DBD.9030609@serpentine.com> Niklas Broberg wrote: > So API suggestions would be most welcome! Your challenge will lie in finding an API that can be implemented efficiently on all concerned platforms. I don't know what the characteristics of the Windows or OS X notification APIs are, but if you use inotify on Linux, and you immediately issue a read every time select tells you there's something to be read, you'll easily consume 70% of a CPU when the filesystem gets busy. With a little guile, you can reduce that overhead by two orders of magnitude, to a fraction of a percent. It's not all that easy to do this well, but using inotify naively is so crippling that you must do it. Any higher-level API must account for factors like this. References: <480B6DBD.9030609@serpentine.com> Message-ID: On Sun, Apr 20, 2008 at 5:22 PM, Bryan O'Sullivan wrote: > Niklas Broberg wrote: > > > So API suggestions would be most welcome! > > Your challenge will lie in finding an API that can be implemented > efficiently on all concerned platforms. I don't know what the > characteristics of the Windows or OS X notification APIs are, but if you > use inotify on Linux, and you immediately issue a read every time select > tells you there's something to be read, you'll easily consume 70% of a > CPU when the filesystem gets busy. > > With a little guile, you can reduce that overhead by two orders of > magnitude, to a fraction of a percent. It's not all that easy to do > this well, but using inotify naively is so crippling that you must do > it. Any higher-level API must account for factors like this. Factor has a file system notification API that wraps windows, linux and mac ones. It might be worth taking a look at that to see what it does. From andrewcoppin at btinternet.com Sun Apr 20 15:41:52 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun Apr 20 15:36:37 2008 Subject: [Haskell-cafe] Parallel weirdness [new insights] In-Reply-To: <480A5314.6090207@btinternet.com> References: <480A080A.4080205@btinternet.com> <1741635235.20080419191037@gmail.com> <480A14C6.8070800@btinternet.com> <759903091.20080419200448@gmail.com> <480A5314.6090207@btinternet.com> Message-ID: <480B9C80.4080905@btinternet.com> OK, well I now have so much data sitting in from of me I don't even know *what* I'm seeing any more. I have made several significant discoveries though... Consider the following: msort [] = [] msort [x] = [x] msort xs = let xs0 = msort (split0 xs) xs1 = msort (split1 xs) in merge xs0 xs1 This takes roughly 14 seconds to sort a list of one million Word32 values. If I now change the final line to read in listSeq rwhnf xs0 `seq` listSeq rwhnf xs1 `seq` merge xs0 xs1 it now takes 8 seconds to do the same job. Notice that this is still completely sequential execution. It's just executing in a different order. (And, at first glance, doing slightly more work.) Of all the benchmarks I've performed, I have yet to find anything that goes faster than this. If I make it so that xs0 is computed in parallel with xs1 instead of in series, then it goes at roughly the same speed (but with more variation) if the number of real threads is 1. If you add more real threads, execution slows down. (Go figure!) I was expecting running parallel at just the top few levels and then switching to pure sequential for the lower levels to give the best performance. But the numbers I have seem to say that more parallel = slower, with 100% sequential giving me the fastest time of all. The next insight happens when you look at the GC statistics. Both the unmarked and the explicitly sequential program are giving me roughly 55% GC time and 45% user time. (!!) Obviously this is a Very Bad Thing. I discovered that simply by adding -H200m to the command line, I can make both programs speed up by about 20% or so. (They then drop down to roughly 25% GC time. Adding more RAM doesn't seem to make any difference.) I had assumed that the explicitly sequential program was faster because it was somehow demanding less GC time, but that doesn't appear to be the case - both GC time and user time are lower for the explicitly sequential version. And adding more heap space doesn't make the (large) speed difference go away. Is the strictness of the seq operator making GHC come up with different a Core implementation for this function or something? I have no idea. With the extra heap space, the speed difference between the sequential and parallel programs becomes smaller. The sequential version *is* still faster, however. I have no explanation for why that might be. Adding more heap also seems to make the runtimes more variable. (I run each test 8 times. One test, the fastest run was 7 seconds and the slowest was 11 seconds. That's quite a variation. The sequential algorithm only varies by a few milliseconds each time.) In short, it seems my little sorting algorithm test is *actually* just stressing out the GC engine, and I'm "really" benchmarking different GC settings. :-( Questions: 1. Does running the GC force all threads to stop? I know some GC designs do this, but I have no idea how the one GHC implements works. 2. Is the GC still single-threaded? (GHC 6.8.2 here.) 3. Is there any way for a running Haskell program to find out how much heap space is currently allocated / used / free? I know you can find out how much wall time and CPU time you've used, but I couldn't find anything for RAM usage. From allbery at ece.cmu.edu Sun Apr 20 15:51:16 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Apr 20 15:46:14 2008 Subject: [Haskell-cafe] Parallel weirdness [new insights] In-Reply-To: <480B9C80.4080905@btinternet.com> References: <480A080A.4080205@btinternet.com> <1741635235.20080419191037@gmail.com> <480A14C6.8070800@btinternet.com> <759903091.20080419200448@gmail.com> <480A5314.6090207@btinternet.com> <480B9C80.4080905@btinternet.com> Message-ID: On Apr 20, 2008, at 15:41 , Andrew Coppin wrote: > 1. Does running the GC force all threads to stop? I know some GC > designs do this, but I have no idea how the one GHC implements works. > > 2. Is the GC still single-threaded? (GHC 6.8.2 here.) Full GC is single-threaded and stops the entire program, yes. IIRC GHC's runtime tries to do incremental GC to minimize the need for a full GC. > 3. Is there any way for a running Haskell program to find out how > much heap space is currently allocated / used / free? I know you > can find out how much wall time and CPU time you've used, but I > couldn't find anything for RAM usage. You're looking for "heap profiling" in the GHC manual. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Sun Apr 20 15:54:02 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Apr 20 15:49:01 2008 Subject: [Haskell-cafe] Parallel weirdness [new insights] In-Reply-To: References: <480A080A.4080205@btinternet.com> <1741635235.20080419191037@gmail.com> <480A14C6.8070800@btinternet.com> <759903091.20080419200448@gmail.com> <480A5314.6090207@btinternet.com> <480B9C80.4080905@btinternet.com> Message-ID: <47B02233-EE23-473B-B9B8-24A7012FA503@ece.cmu.edu> On Apr 20, 2008, at 15:51 , Brandon S. Allbery KF8NH wrote: > On Apr 20, 2008, at 15:41 , Andrew Coppin wrote: >> 3. Is there any way for a running Haskell program to find out how >> much heap space is currently allocated / used / free? I know you >> can find out how much wall time and CPU time you've used, but I >> couldn't find anything for RAM usage. > > You're looking for "heap profiling" in the GHC manual. Wait, no, I misread. I don't know if or how a running program could introspect its own heap usage. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From bulat.ziganshin at gmail.com Sun Apr 20 15:54:28 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Apr 20 15:54:50 2008 Subject: [Haskell-cafe] Parallel weirdness [new insights] In-Reply-To: <480B9C80.4080905@btinternet.com> References: <480A080A.4080205@btinternet.com> <1741635235.20080419191037@gmail.com> <480A14C6.8070800@btinternet.com> <759903091.20080419200448@gmail.com> <480A5314.6090207@btinternet.com> <480B9C80.4080905@btinternet.com> Message-ID: <1469821949.20080420235428@gmail.com> Hello Andrew, Sunday, April 20, 2008, 11:41:52 PM, you wrote: yes, GC behavior has significant impact on any new language (i mean java, c#, f# and so on) > 1. Does running the GC force all threads to stop? I know some GC designs > do this, but I have no idea how the one GHC implements works. yes > 2. Is the GC still single-threaded? (GHC 6.8.2 here.) yes. multi-threaded GC is planned gor next ghc version, afair > 3. Is there any way for a running Haskell program to find out how much > heap space is currently allocated / used / free? i think it's possible by asking internal RTS vars. SM once suggested to add to GHC library that provides official way to ask this info but no volunteer was happen :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From andrewcoppin at btinternet.com Sun Apr 20 16:05:28 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun Apr 20 16:00:14 2008 Subject: [Haskell-cafe] Parallel weirdness [new insights] In-Reply-To: References: <480A080A.4080205@btinternet.com> <1741635235.20080419191037@gmail.com> <480A14C6.8070800@btinternet.com> <759903091.20080419200448@gmail.com> <480A5314.6090207@btinternet.com> <480B9C80.4080905@btinternet.com> Message-ID: <480BA208.9050703@btinternet.com> Brandon S. Allbery KF8NH wrote: > > On Apr 20, 2008, at 15:41 , Andrew Coppin wrote: > >> 1. Does running the GC force all threads to stop? I know some GC >> designs do this, but I have no idea how the one GHC implements works. >> >> 2. Is the GC still single-threaded? (GHC 6.8.2 here.) > > Full GC is single-threaded and stops the entire program, yes. IIRC > GHC's runtime tries to do incremental GC to minimize the need for a > full GC. My brain is telling me I've read something somewhere that had in-depth information about GHC's GC implementation - but I can't remember where I saw it... (Maybe the developer wiki? I'll go look there anyway, they might have some interesting goodies.) Anyway, the sequential version of the program clearly indicates that the thing is doing *a lot* of GC. If the GC sometimes stops the entire program, that could sure limit parallelism real fast... I suppose the only way to know for sure is to turn the heap size up absurdly high so that GC is *never* required, and see what that does. FWIW, I do see higher CPU usage figures with a larger heap... From andrewcoppin at btinternet.com Sun Apr 20 16:08:59 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun Apr 20 16:03:44 2008 Subject: [Haskell-cafe] Parallel weirdness [new insights] In-Reply-To: <1469821949.20080420235428@gmail.com> References: <480A080A.4080205@btinternet.com> <1741635235.20080419191037@gmail.com> <480A14C6.8070800@btinternet.com> <759903091.20080419200448@gmail.com> <480A5314.6090207@btinternet.com> <480B9C80.4080905@btinternet.com> <1469821949.20080420235428@gmail.com> Message-ID: <480BA2DB.3040801@btinternet.com> Bulat Ziganshin wrote: >> 3. Is there any way for a running Haskell program to find out how much >> heap space is currently allocated / used / free? >> > > i think it's possible by asking internal RTS vars. SM once suggested > to add to GHC library that provides official way to ask this info but > no volunteer was happen :) > The RTS can spit out aggregate data just with a CLI switch (and it doesn't appear to affect runtime noticably). You don't even need to compile with profiling enabled. This seems to indicate that the data is easy to collect, there's just no path for accessing it yet. I'm no GHC developer, but from the outside it "appears" to be a fairly simple problem. If I knew anything about the RTS, I'd volunteer myself. But I suspect this is one of those jobs that requires knowledge of C... :-( From bulat.ziganshin at gmail.com Sun Apr 20 16:09:51 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Apr 20 16:08:01 2008 Subject: [Haskell-cafe] Parallel weirdness [new insights] In-Reply-To: <480BA208.9050703@btinternet.com> References: <480A080A.4080205@btinternet.com> <1741635235.20080419191037@gmail.com> <480A14C6.8070800@btinternet.com> <759903091.20080419200448@gmail.com> <480A5314.6090207@btinternet.com> <480B9C80.4080905@btinternet.com> <480BA208.9050703@btinternet.com> Message-ID: <1095434322.20080421000951@gmail.com> Hello Andrew, Monday, April 21, 2008, 12:05:28 AM, you wrote: > My brain is telling me I've read something somewhere that had in-depth > information about GHC's GC implementation - but I can't remember where I > saw it... (Maybe the developer wiki? I'll go look there anyway, they > might have some interesting goodies.) look at the end of Arrays wiki page and further references. in particular, play with -A too -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From midfield at gmail.com Sun Apr 20 17:02:27 2008 From: midfield at gmail.com (Ben) Date: Sun Apr 20 16:57:27 2008 Subject: [Haskell-cafe] letting go of file handles and Data.Binary Message-ID: <9157df230804201402r40da4d1eoe94f678d95fb33a6@mail.gmail.com> hi all -- using binary 0.4.1 on ghc 6.8.2, vista 64 sp1. consider the following program: import System.Directory import Data.Binary main = do let dat = [1..10]::[Int] fname = "foo.dat" encodeFile fname dat dat2 <- decodeFile fname print (dat == dat2) removeFile fname this throws a permission denied exception, presumably because the file is still open when the removeFile is called. i've grovelled the source of Data.Bytestring.Lazy and all but i can't seem to understand the "right" way to make this work. note that i've forced the evaluation of dat2 and presumably therefore the filehandle is at least half-closed. any suggestions? take care, Ben From bos at serpentine.com Sun Apr 20 17:04:31 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sun Apr 20 16:59:32 2008 Subject: [Haskell-cafe] Parallel weirdness [new insights] In-Reply-To: <1469821949.20080420235428@gmail.com> References: <480A080A.4080205@btinternet.com> <1741635235.20080419191037@gmail.com> <480A14C6.8070800@btinternet.com> <759903091.20080419200448@gmail.com> <480A5314.6090207@btinternet.com> <480B9C80.4080905@btinternet.com> <1469821949.20080420235428@gmail.com> Message-ID: <480BAFDF.7090508@serpentine.com> Bulat Ziganshin wrote: > yes. multi-threaded GC is planned gor next ghc version, afair To be clear, it'll be a parallel GC, not a concurrent one. The former still stops all threads, but runs the collector on multiple cores at once. The latter performs collection while mutator threads are still running, and is a lot trickier to implement. (For a fine knee-slapping time, try reading a Java GC tuning guide.) References: <9157df230804201402r40da4d1eoe94f678d95fb33a6@mail.gmail.com> Message-ID: <480BB29E.7020002@serpentine.com> Ben wrote: > this throws a permission denied exception, presumably because the file > is still open when the removeFile is called. Yes. The file handle opened by encodeFile won't be closed until its finalizer is run. There is no guarantee that the finalizer will be run immediately. In fact, you can usually rely on the finalizer *not* running immediately, because the GC has to kick in, notice that the handle is dead, and hand it to the finalizer thread. It's actually possible that your finalizer could not run at all. > i've grovelled the > source of Data.Bytestring.Lazy and all but i can't seem to understand > the "right" way to make this work. Don't use encodeFile at all. Instead, write your own: import Data.Binary (Binary, encode) import Control.Exception (bracket) import qualified Data.ByteString.Lazy as L import System.IO (IOMode(..), hClose, openFile) encodeFile :: Binary a => FilePath -> a -> IO () encodeFile path = bracket (openFile path WriteMode) hClose . flip L.hPut . encode From duncan.coutts at worc.ox.ac.uk Sun Apr 20 17:19:05 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 17:14:03 2008 Subject: [Haskell-cafe] letting go of file handles and Data.Binary In-Reply-To: <9157df230804201402r40da4d1eoe94f678d95fb33a6@mail.gmail.com> References: <9157df230804201402r40da4d1eoe94f678d95fb33a6@mail.gmail.com> Message-ID: <1208726345.5960.112.camel@dell.linuxdev.us.dell.com> On Sun, 2008-04-20 at 14:02 -0700, Ben wrote: > hi all -- > > using binary 0.4.1 on ghc 6.8.2, vista 64 sp1. consider the following program: > > import System.Directory > import Data.Binary > > main = do > let dat = [1..10]::[Int] > fname = "foo.dat" > encodeFile fname dat > dat2 <- decodeFile fname > print (dat == dat2) > removeFile fname > > this throws a permission denied exception, presumably because the file > is still open when the removeFile is called. i've grovelled the > source of Data.Bytestring.Lazy and all but i can't seem to understand > the "right" way to make this work. note that i've forced the > evaluation of dat2 and presumably therefore the filehandle is at least > half-closed. > > any suggestions? There was a bug in bytestring-0.9.0.1 where the file handle was not closed when Data.Bytestring.Lazy.hGetContents reached the end of the file. The fix is certainly in version 0.9.0.4. So the above program should work there. If it still does not then the culprit is probably that your binary deserialiser is not consuming the whole input. Remember if you have access to a Handle you can always hClose it explicitly. Duncan From bos at serpentine.com Sun Apr 20 17:24:02 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sun Apr 20 17:19:03 2008 Subject: [Haskell-cafe] letting go of file handles and Data.Binary In-Reply-To: <480BB29E.7020002@serpentine.com> References: <9157df230804201402r40da4d1eoe94f678d95fb33a6@mail.gmail.com> <480BB29E.7020002@serpentine.com> Message-ID: <480BB472.40708@serpentine.com> Doh! For all that I wrote about encodeFile, substitute decodeFile. You'll need to write something to force the value that you're decoding. Something like this ought to do the trick. import Data.Binary (Binary, decode) import Control.Exception (bracket) import qualified Data.ByteString.Lazy as L import System.IO (IOMode(..), hClose, openFile) strictDecodeFile :: Binary a => FilePath -> (a -> b) -> IO () strictDecodeFile path force = bracket (openFile path ReadMode) hClose $ \h -> do c <- L.hGetContents h force (decode c) `seq` return () References: <9157df230804201402r40da4d1eoe94f678d95fb33a6@mail.gmail.com> <480BB29E.7020002@serpentine.com> <480BB472.40708@serpentine.com> Message-ID: <1208727297.5960.128.camel@dell.linuxdev.us.dell.com> On Sun, 2008-04-20 at 14:24 -0700, Bryan O'Sullivan wrote: > Doh! For all that I wrote about encodeFile, substitute decodeFile. Indeed the version of encodeFile you wrote should be exactly identical to the original because the lazy bytestring writeFile already uses bracket like that: writeFile :: FilePath -> ByteString -> IO () writeFile f txt = bracket (openBinaryFile f WriteMode) hClose (\hdl -> hPut hdl txt) > strictDecodeFile :: Binary a => FilePath -> (a -> b) -> IO () > strictDecodeFile path force = > bracket (openFile path ReadMode) hClose $ \h -> do > c <- L.hGetContents h > force (decode c) `seq` return () Yes, the problem with Ben's program was that decodeFile is lazily reading the file and lazily decoding. If the decoding consumes all the input then it should be possible to avoid rewriting decodeFile and use: dat2 <- decodeFile fname evaluate dat2 removeFile fname It's not immediately clear to me if we can make the decodeFile behave like your version. I'd have to go think about whether running the Get monad can lazily return values or if it always consumes all the input it'll ever need. Duncan From fegaras at uta.edu Sun Apr 20 17:42:42 2008 From: fegaras at uta.edu (Fegaras, Leonidas) Date: Sun Apr 20 17:37:45 2008 Subject: [Haskell-cafe] ANN: HXQ: An XQuery Compiler/Interpreter for Haskell Message-ID: <358486CF38F8EA409E72DAB944FBC606097F15@MAILFS2.uta.edu> Dear Haskell cafe members, I would like to announce the release of an XQuery compiler/interpreter for Haskell, called HXQ. You can get more info and download it at: http://lambda.uta.edu/HXQ/ HXQ is a fast and space-efficient translator from XQuery (the standard query language for XML) to embedded Haskell code. The translation is based on Haskell templates. HXQ takes full advantage of Haskell's lazy evaluation to keep in memory only those parts of XML data needed at each point of evaluation, thus performing stream-based evaluation for forward queries (queries that do not contain backward steps). This results to an implementation that is as fast and space-efficient as any stream-based implementation based on SAX filters or finite state machines. Furthermore, the coding is far simpler and extensible since its based on XML trees, rather than SAX events. For example, a complex XQuery against the DBLP bibliography (420MB XML) runs in 39 seconds on my laptop (using 18MB of max heap space in ghc). To contrast this, Qexo, which compiles XQueries to Java bytecode, took 1 minute 17 seconds (using no less than 1400MB of heap space). Also XQilla, which is written in C++, took 1 minute and 10 secs (using 1150MB heap). Current Status: HXQ supports most essential XQuery features, although some system functions are missing (but are easy to add). HXQ has little support for backward step axes, such as /.. (parent). Some, but not all, parent axis steps are removed using optimization rules; all others cause a compilation error. Finally, HXQ does not comply to the XQuery semantics that requires duplicate elimination and sorting by document order for every XPath step, which is very expensive and unnecessary in most cases. Please email me any suggestions for improvements or extensions you'd like to see. My plan is to use it as a base for various XQuery projects, such as adding SQL connectivity, as well as native storage and indexing. Best, Leonidas Fegaras U. of Texas at Arlington http://lambda.uta.edu/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080420/1a9ec556/attachment.htm From dons at galois.com Sun Apr 20 18:09:33 2008 From: dons at galois.com (Don Stewart) Date: Sun Apr 20 18:04:31 2008 Subject: [Haskell-cafe] Announce: bytestring 0.9.1.0 Message-ID: <20080420220933.GA29143@scytale.galois.com> Hey all, I'm pleased to announce a new major release of bytestring, the efficient string library for Haskell, suitable for high-performance scenarios. This release is primarily an (incremental) performance improvement release, though with some notable significant improvements, along with long term test coverage and quality control changes. Highlights: * a long term performance bug with Ord instances, involving very small strings, and Data.Map has been squashed. * everything's a little faster -- shootout problems showed a 1-5% speedup just by switching to the new library. Thanks goes to the Hac4 Haskell Hackathon organisers, in Gothenburg, Sweden, where the majority of this work to create this release took place. Key changes: * Data.Map short key performance greatly improved: - 'words Map' running time: 6.310s bytestring 0.9.0.1 1.071s bytestring 0.9.1.0 * Uses cheaper unsafeDupablePerformIO for allocation. - tail recursive tight loops (fixes obscure stack overflow) * Generally faster: - Shootout sum-file: 1.218s to 1.190s - Shooout fasta: 9.210s to 8.811s * 4-5x faster small substring search (breakSubstring/findSubstring/isInfixOf). * Extensive QuickCheck coverage reporting and improvements: - http://code.haskell.org/~dons/tests/bytestring/hpc_index.html Get the code: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring Note that if you upgrade to the new bytestring release, older packages built against previous releases will still require the old bytestring package. For best results, rebuild any bytestring-depending packages against the new library only. Cheers, Don From gwern0 at gmail.com Sun Apr 20 18:48:28 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Apr 20 18:54:19 2008 Subject: [Haskell-cafe] Announce: bytestring 0.9.1.0 In-Reply-To: <20080420220933.GA29143@scytale.galois.com> References: <20080420220933.GA29143@scytale.galois.com> Message-ID: <20080420224828.GA7794@localhost> On 2008.04.20 15:09:33 -0700, Don Stewart scribbled 1.7K characters: > > Hey all, > > I'm pleased to announce a new major release of bytestring, the efficient > string library for Haskell, suitable for high-performance scenarios. > > This release is primarily an (incremental) performance improvement > release, though with some notable significant improvements, along with > long term test coverage and quality control changes. > > Highlights: > > * a long term performance bug with Ord instances, involving very > small strings, and Data.Map has been squashed. > > * everything's a little faster -- shootout problems showed a 1-5% > speedup just by switching to the new library. > > Thanks goes to the Hac4 Haskell Hackathon organisers, in Gothenburg, > Sweden, where the majority of this work to create this release took place. > > Key changes: > > * Data.Map short key performance greatly improved: > - 'words Map' running time: > 6.310s bytestring 0.9.0.1 > 1.071s bytestring 0.9.1.0 > > * Uses cheaper unsafeDupablePerformIO for allocation. > - tail recursive tight loops (fixes obscure stack overflow) > > * Generally faster: > - Shootout sum-file: 1.218s to 1.190s > - Shooout fasta: 9.210s to 8.811s > > * 4-5x faster small substring search (breakSubstring/findSubstring/isInfixOf). > > * Extensive QuickCheck coverage reporting and improvements: > - http://code.haskell.org/~dons/tests/bytestring/hpc_index.html > > Get the code: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring > > Note that if you upgrade to the new bytestring release, older packages > built against previous releases will still require the old bytestring > package. For best results, rebuild any bytestring-depending packages > against the new library only. > > Cheers, > Don That's all good news; will this release of ByteString be used for GHC 6.8.3? I'm a little tired of linking everything against 0.9.0.1 just so I can use Yi (since GHC/the-GHC-API links against it). :) -- gwern NSDM USP Edens SAS kibo quarter NSES Gamma MP5k threat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080420/6928d11e/attachment.bin From midfield at gmail.com Sun Apr 20 19:35:15 2008 From: midfield at gmail.com (Ben) Date: Sun Apr 20 19:30:12 2008 Subject: [Haskell-cafe] letting go of file handles and Data.Binary In-Reply-To: <1208727297.5960.128.camel@dell.linuxdev.us.dell.com> References: <9157df230804201402r40da4d1eoe94f678d95fb33a6@mail.gmail.com> <480BB29E.7020002@serpentine.com> <480BB472.40708@serpentine.com> <1208727297.5960.128.camel@dell.linuxdev.us.dell.com> Message-ID: <9157df230804201635t28ac1668l43f680b268678cc5@mail.gmail.com> FWIW, installed bytestring-0.9.1.0, ran ghc-pkg hide bytestring-0.9.0.1, recompiled and reinstalled binary-0.4.1. then i played around with all that you suggested, and came to the conclusion that i don't understand seq! import Control.Exception (bracket) import System.Directory import System.IO import Data.Binary import Data.ByteString.Lazy as B strictDecodeFile :: Binary a => FilePath -> (a -> b) -> IO () strictDecodeFile path force = bracket (openFile path ReadMode) hClose $ \h -> do c <- B.hGetContents h force (decode c) `seq` return () strictDecodeFile' :: Binary a => FilePath -> (a -> IO b) -> IO () strictDecodeFile' path force = bracket (openFile path ReadMode) hClose $ \h -> do c <- B.hGetContents h force (decode c) return () main = do let dat = [1..10]::[Int] fname = "foo.dat" encodeFile fname dat h <- openFile fname ReadMode c <- B.hGetContents h let dat2 = decode c print (dat == dat2) hClose h removeFile fname encodeFile fname dat strictDecodeFile fname (\x -> do print "strict 1" print (x == dat)) removeFile fname encodeFile fname dat strictDecodeFile' fname (\x -> do print "strict 2" print (x == dat)) removeFile fname encodeFile fname dat dat4 <- decodeFile fname print (dat == dat4) removeFile fname running main outputs True "strict 2" True True *** Exception: foo.dat: removeFile: permission denied (Permission denied) e.g. the handle version works, Bryan's original strictDecodeFile appears to not run "force", the modified strictDecodeFile' does run "force" (i didn't use seq, just an additional line in the monad), and the encodeFile / decodeFile / removeFile appears to still not work with the latest bytestring. what's the difference between the seq and non-seq versions? for now i can use strictDecodeFile' but at least something should be said in the docs about decodeFile et al holding handles. (i understand this is not the fault of binary per se as much as haskell's non-strict semantics, but a reminder for noobs like me would be helpful.) and finally something like strictDecodeFile' might be useful in the library? thanks for the help, ben On Sun, Apr 20, 2008 at 2:34 PM, Duncan Coutts wrote: > > On Sun, 2008-04-20 at 14:24 -0700, Bryan O'Sullivan wrote: > > Doh! For all that I wrote about encodeFile, substitute decodeFile. > > > Indeed the version of encodeFile you wrote should be exactly identical > to the original because the lazy bytestring writeFile already uses > bracket like that: > > writeFile :: FilePath -> ByteString -> IO () > writeFile f txt = bracket (openBinaryFile f WriteMode) hClose > (\hdl -> hPut hdl txt) > > > > strictDecodeFile :: Binary a => FilePath -> (a -> b) -> IO () > > strictDecodeFile path force = > > bracket (openFile path ReadMode) hClose $ \h -> do > > c <- L.hGetContents h > > force (decode c) `seq` return () > > Yes, the problem with Ben's program was that decodeFile is lazily > reading the file and lazily decoding. If the decoding consumes all the > input then it should be possible to avoid rewriting decodeFile and use: > > dat2 <- decodeFile fname > evaluate dat2 > removeFile fname > > It's not immediately clear to me if we can make the decodeFile behave > like your version. I'd have to go think about whether running the Get > monad can lazily return values or if it always consumes all the input > it'll ever need. > > Duncan > > From mad.one at gmail.com Sun Apr 20 20:05:10 2008 From: mad.one at gmail.com (Austin Seipp) Date: Sun Apr 20 20:00:12 2008 Subject: [Haskell-cafe] Announce: bytestring 0.9.1.0 In-Reply-To: <20080420224828.GA7794@localhost> References: <20080420220933.GA29143@scytale.galois.com> <20080420224828.GA7794@localhost> Message-ID: <1208735474-sup-9554@continuum> > That's all good news; will this release of ByteString be used for GHC 6.8.3? > I'm a little tired of linking everything against 0.9.0.1 just so I can use Yi > (since GHC/the-GHC-API links against it). :) Indeed; this is the biggest issue I have with bytestring right now as it's interfered with my work with hs-plugins/GHC-api, especially considering I think the new cabal and ghc 6.8.3 should fix or at least warn about the library-version-mismatch issues (from what I've heard.) The only probable fix I can think of (other than doing compile-time hackery on both the C and haskell side to make symbol names differ across releases, which is fairly infeasible i'd think and would regardless kill portability since template-haskell is the only viable option on the haskell note,) is to factor out the usage of bytestring in the GHC-API, or just stick the source code to bytestring into the GHC source tree so it's not built as a package (so you wouldn't see it in, e.g. 'ghc-pkg describe ghc', although I would think the names would still show up in the symbol table, regardless.) But whatever route you choose, I'm not sure of the ramifications in general and it seems to be a tough cookie to solve properly, so we don't end up breaking things as we try and fix them. Don probably has better ideas. -- "It was in the days of the rains that their prayers went up, not from the fingering of knotted prayer cords or the spinning of prayer wheels, but from the great pray-machine in the monastery of Ratri, goddess of the Night." Roger Zelazny From dons at galois.com Sun Apr 20 20:07:48 2008 From: dons at galois.com (Don Stewart) Date: Sun Apr 20 20:02:51 2008 Subject: [Haskell-cafe] Announce: bytestring 0.9.1.0 In-Reply-To: <1208735474-sup-9554@continuum> References: <20080420220933.GA29143@scytale.galois.com> <20080420224828.GA7794@localhost> <1208735474-sup-9554@continuum> Message-ID: <20080421000748.GA9187@scytale.galois.com> mad.one: > > That's all good news; will this release of ByteString be used for GHC 6.8.3? > > I'm a little tired of linking everything against 0.9.0.1 just so I can use Yi > > (since GHC/the-GHC-API links against it). :) > > Indeed; this is the biggest issue I have with bytestring right now as > it's interfered with my work with hs-plugins/GHC-api, especially > considering I think the new cabal and ghc 6.8.3 should fix or at least > warn about the library-version-mismatch issues (from what I've heard.) > > The only probable fix I can think of (other than doing compile-time > hackery on both the C and haskell side to make symbol names differ > across releases, which is fairly infeasible i'd think and would regardless kill > portability since template-haskell is the only viable option on the > haskell note,) is to factor out the usage of bytestring in the GHC-API, or > just stick the source code to bytestring into the GHC source tree so > it's not built as a package (so you wouldn't see it in, e.g. 'ghc-pkg > describe ghc', although I would think the names would still show up in > the symbol table, regardless.) > > But whatever route you choose, I'm not sure of the ramifications in > general and it seems to be a tough cookie to solve properly, so we don't > end up breaking things as we try and fix them. Don probably has better > ideas. The use of bytestring inside GHC is limited only to a little bit in the GHCi modules -- and could easily be replaced, I suspect. Doing so would remove one dependency from GHC's core, as well as making it easier to upgrade bytestring versions. Ian, have you looked at this? -- Don From duncan.coutts at worc.ox.ac.uk Sun Apr 20 20:27:20 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 20:28:24 2008 Subject: [Haskell-cafe] Announce: bytestring 0.9.1.0 In-Reply-To: <1208735474-sup-9554@continuum> References: <20080420220933.GA29143@scytale.galois.com> <20080420224828.GA7794@localhost> <1208735474-sup-9554@continuum> Message-ID: <1208737640.5960.153.camel@dell.linuxdev.us.dell.com> On Sun, 2008-04-20 at 19:05 -0500, Austin Seipp wrote: > > That's all good news; will this release of ByteString be used for GHC 6.8.3? > > I'm a little tired of linking everything against 0.9.0.1 just so I can use Yi > > (since GHC/the-GHC-API links against it). :) > > Indeed; this is the biggest issue I have with bytestring right now as > it's interfered with my work with hs-plugins/GHC-api, especially > considering I think the new cabal and ghc 6.8.3 should fix or at least > warn about the library-version-mismatch issues (from what I've heard.) Cabal-1.4 does warn at configure time if a build is going to use inconsistent versions of dependent libraries. Trying to come up with an installation plan that avoids the problem is a good deal harder and in general isn't possible without having to rebuild lots of unrelated packages. > The only probable fix I can think of (other than doing compile-time > hackery on both the C and haskell side to make symbol names differ > across releases, All haskell code does work this way, ghc puts the package name and version into the symbol name so it is possible to link several versions of a package into one program. The particular problem for bytestring is the C code that it uses. So while Data.ByteString.foo get's mapped to a symbol name something like "bytestring_0_9_1_0_DatazByteStringzfoo" the embedded C code gets no such mangling so fps_reverse from bytestring-0.9.0.1 clashes with fps_reverse from bytestring-0.9.0.4. Actually the gnu ld linker doesn't mind about the duplicate symbols and just picks ones of them. The ghci linker is a bit more paranoid and rejects the duplicates. I guess we could try and adjust the names of the C symbols to include the package name and version. Duncan From daniel.is.fischer at web.de Sun Apr 20 20:34:32 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sun Apr 20 20:29:57 2008 Subject: [Haskell-cafe] letting go of file handles and Data.Binary In-Reply-To: <9157df230804201635t28ac1668l43f680b268678cc5@mail.gmail.com> References: <9157df230804201402r40da4d1eoe94f678d95fb33a6@mail.gmail.com> <1208727297.5960.128.camel@dell.linuxdev.us.dell.com> <9157df230804201635t28ac1668l43f680b268678cc5@mail.gmail.com> Message-ID: <200804210234.32129.daniel.is.fischer@web.de> Am Montag, 21. April 2008 01:35 schrieb Ben: > FWIW, installed bytestring-0.9.1.0, ran ghc-pkg hide > bytestring-0.9.0.1, recompiled and reinstalled binary-0.4.1. then i > played around with all that you suggested, and came to the conclusion > that i don't understand seq! > > import Control.Exception (bracket) > import System.Directory > import System.IO > import Data.Binary > import Data.ByteString.Lazy as B > > strictDecodeFile :: Binary a => FilePath -> (a -> b) -> IO () > strictDecodeFile path force = > bracket (openFile path ReadMode) hClose $ \h -> do > c <- B.hGetContents h > force (decode c) `seq` return () This means that force (decode c) is reduced to head normal form, not fully evaluated. So if the result type of force were e.g. Either String Int, it would be evaluated just far enough to determine if force (decode c) is bottom, Left something or Right somethingelse; Left undefined and Right undefined won't cause an exception. In the case below, force (decode c) is an IO action, it will be evaluated as far as necessary to see it's (IO whatever) and not bottom, for that it need not be run, therefore you don't see "strict 1" printed out. > > strictDecodeFile' :: Binary a => FilePath -> (a -> IO b) -> IO () > strictDecodeFile' path force = > bracket (openFile path ReadMode) hClose $ \h -> do > c <- B.hGetContents h > force (decode c) > return () Here you say you want the IO action force (decode c) to be run, so it is run and "strict 2" is printed out. Hope that helps. From midfield at gmail.com Sun Apr 20 20:36:23 2008 From: midfield at gmail.com (Ben) Date: Sun Apr 20 20:31:21 2008 Subject: [Haskell-cafe] letting go of file handles and Data.Binary In-Reply-To: <9157df230804201635t28ac1668l43f680b268678cc5@mail.gmail.com> References: <9157df230804201402r40da4d1eoe94f678d95fb33a6@mail.gmail.com> <480BB29E.7020002@serpentine.com> <480BB472.40708@serpentine.com> <1208727297.5960.128.camel@dell.linuxdev.us.dell.com> <9157df230804201635t28ac1668l43f680b268678cc5@mail.gmail.com> Message-ID: <9157df230804201736l99577e4qa311b5abe3e8d2f9@mail.gmail.com> one more piece of email pollution: import Control.Exception (bracket) import System.IO import Data.Binary import qualified Data.ByteString.Lazy as B strictDecodeFile :: Binary a => FilePath -> IO a strictDecodeFile path = bracket (openBinaryFile path ReadMode) hClose $ \h -> do c <- B.hGetContents h return $! decode c seems to work like Data.Binary.decodeFile but explicitly closes the handle. take care, ben On Sun, Apr 20, 2008 at 4:35 PM, Ben wrote: > FWIW, installed bytestring-0.9.1.0, ran ghc-pkg hide > bytestring-0.9.0.1, recompiled and reinstalled binary-0.4.1. then i > played around with all that you suggested, and came to the conclusion > that i don't understand seq! > > import Control.Exception (bracket) > import System.Directory > import System.IO > import Data.Binary > import Data.ByteString.Lazy as B > > > strictDecodeFile :: Binary a => FilePath -> (a -> b) -> IO () > strictDecodeFile path force = > bracket (openFile path ReadMode) hClose $ \h -> do > c <- B.hGetContents h > force (decode c) `seq` return () > > strictDecodeFile' :: Binary a => FilePath -> (a -> IO b) -> IO () > > strictDecodeFile' path force = > bracket (openFile path ReadMode) hClose $ \h -> do > c <- B.hGetContents h > force (decode c) > return () > > > main = do > let dat = [1..10]::[Int] > fname = "foo.dat" > encodeFile fname dat > h <- openFile fname ReadMode > c <- B.hGetContents h > let dat2 = decode c > print (dat == dat2) > hClose h > removeFile fname > > encodeFile fname dat > strictDecodeFile fname (\x -> do print "strict 1" > print (x == dat)) > removeFile fname > > encodeFile fname dat > strictDecodeFile' fname (\x -> do print "strict 2" > print (x == dat)) > removeFile fname > > encodeFile fname dat > dat4 <- decodeFile fname > print (dat == dat4) > removeFile fname > > running main outputs > > True > "strict 2" > True > True > *** Exception: foo.dat: removeFile: permission denied (Permission denied) > > e.g. the handle version works, Bryan's original strictDecodeFile > appears to not run "force", the modified strictDecodeFile' does run > "force" (i didn't use seq, just an additional line in the monad), and > the encodeFile / decodeFile / removeFile appears to still not work > with the latest bytestring. what's the difference between the seq and > non-seq versions? > > for now i can use strictDecodeFile' but at least something should be > said in the docs about decodeFile et al holding handles. (i > understand this is not the fault of binary per se as much as haskell's > non-strict semantics, but a reminder for noobs like me would be > helpful.) and finally something like strictDecodeFile' might be > useful in the library? > > thanks for the help, ben > > > > On Sun, Apr 20, 2008 at 2:34 PM, Duncan Coutts > wrote: > > > > On Sun, 2008-04-20 at 14:24 -0700, Bryan O'Sullivan wrote: > > > Doh! For all that I wrote about encodeFile, substitute decodeFile. > > > > > > Indeed the version of encodeFile you wrote should be exactly identical > > to the original because the lazy bytestring writeFile already uses > > bracket like that: > > > > writeFile :: FilePath -> ByteString -> IO () > > writeFile f txt = bracket (openBinaryFile f WriteMode) hClose > > (\hdl -> hPut hdl txt) > > > > > > > strictDecodeFile :: Binary a => FilePath -> (a -> b) -> IO () > > > strictDecodeFile path force = > > > bracket (openFile path ReadMode) hClose $ \h -> do > > > c <- L.hGetContents h > > > force (decode c) `seq` return () > > > > Yes, the problem with Ben's program was that decodeFile is lazily > > reading the file and lazily decoding. If the decoding consumes all the > > input then it should be possible to avoid rewriting decodeFile and use: > > > > dat2 <- decodeFile fname > > evaluate dat2 > > removeFile fname > > > > It's not immediately clear to me if we can make the decodeFile behave > > like your version. I'd have to go think about whether running the Get > > monad can lazily return values or if it always consumes all the input > > it'll ever need. > > > > Duncan > > > > > From daniel.is.fischer at web.de Sun Apr 20 20:57:36 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sun Apr 20 20:50:49 2008 Subject: [Haskell-cafe] letting go of file handles and Data.Binary In-Reply-To: <200804210234.32129.daniel.is.fischer@web.de> References: <9157df230804201402r40da4d1eoe94f678d95fb33a6@mail.gmail.com> <9157df230804201635t28ac1668l43f680b268678cc5@mail.gmail.com> <200804210234.32129.daniel.is.fischer@web.de> Message-ID: <200804210257.36315.daniel.is.fischer@web.de> Am Montag, 21. April 2008 02:34 schrieb Daniel Fischer: > > This means that force (decode c) is reduced to head normal form, not fully > evaluated. Ooops, _weak_ head normal form, of course. From bos at serpentine.com Sun Apr 20 21:52:31 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sun Apr 20 21:47:32 2008 Subject: [Haskell-cafe] letting go of file handles and Data.Binary In-Reply-To: <9157df230804201635t28ac1668l43f680b268678cc5@mail.gmail.com> References: <9157df230804201402r40da4d1eoe94f678d95fb33a6@mail.gmail.com> <480BB29E.7020002@serpentine.com> <480BB472.40708@serpentine.com> <1208727297.5960.128.camel@dell.linuxdev.us.dell.com> <9157df230804201635t28ac1668l43f680b268678cc5@mail.gmail.com> Message-ID: <480BF35F.3070803@serpentine.com> Ben wrote: > i played around with all that you suggested, and came to the conclusion > that i don't understand seq! That's certainly possible, but you also got the type of your first forcing function wrong :-) > strictDecodeFile :: Binary a => FilePath -> (a -> b) -> IO () > encodeFile fname dat > strictDecodeFile fname (\x -> do print "strict 1" > print (x == dat)) > removeFile fname You provided a function that returns an IO action. Note that strictDecodeFile ensures that the result of force is evaluated to WHNF, but it doesn't know what the *type* of the result is. If you return an IO action, there's no way it can be run, because the caller can't even tell that you returned an IO action: it just knows that you returned something of an unknown type "b". If the IO action can't be run, the comparison inside can't be performed, and so nothing useful actually happens. Instead, just provide a pure function to force the decoding: something as simple as (==dat) will do. Evaluating this to WHNF will reduce it to the constructor True or False. In order to produce a constructor, enough of the decoded data should be demanded to suit your needs. Developing a good enough mental model of how laziness works is a very useful way to spend some time. References: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> Message-ID: <2f9b2d30804210050h58aac9e4xf2de56331d244ba@mail.gmail.com> On Fri, Apr 18, 2008 at 10:01 PM, Jonathan Cast wrote: > {-# GHC_OPTIONS -foverlapping-instances -fundecidable-instances #-} :) > What you want to work is precisely what this allows. Of course, I bring that point up. And overlapping instances has the problem that it doesn't really do what you want; you always eventually end up with this problem: oops :: Eq a => a -> a -> Property oops x y = x ~= y Overlapping instances for EqTestable a arising from a use of `~=' Matching instances: instance [overlap ok] (Eq a) => EqTestable a instance [overlap ok] (Show a, Arbitrary a, EqTestable b) => EqTestable (a -> b) (The choice depends on the instantiation of `a' To pick the first instance above, use -fallow-incoherent-instances when compiling the other instance declarations) In the expression: x ~= y In the definition of `oops': oops x y = x ~= y > I call. Name a language that is > > a) Completely statically typed (no type errors at runtime), > b) Has an ad-hoc overloading mechanism powerful enough to encode Num and > Monad, and > c) Is substantially better than Haskell + extensions for your examples. No fair! I'm on haskell-cafe for a reason: every language sucks, Haskell just sucks less :) But I can give a couple of thoughts that almost meet your criteria: 1) Ruby. Totally misses (a) but absolutely nails (b) and (c). 2) C++: Fine on (a) as long as you don't write stupid stuff. Template meta-programming involves pattern-matching on types and I believe is strong enough for (b). But it's really verbose; from an elegance point of view it probably misses (c). 3) Scala? I don't know enough about it to say for sure but what I have seen looks promising. > On 18 Apr 2008, at 9:29 PM, Ryan Ingram wrote: > > 1) You can't make sensible default implementations. For example, it'd > > be nice to make all my Monads be Applicatives and Functors without > > resorting to Template Haskell or infinite boilerplate. Why can't I > > just write this? > > > > instance Monad m => Applicative m where > > pure = return > > (<*>) = ap > > > > Sure, I get that there might be ambiguity of which instance to choose. > > But why not warn me about that ambiguity, or let me choose somehow on > > a case-by-case basis when it happens? > > > > You can already choose on a case-by-case basis. That's true, but if the authors of Applicative could, I am sure they would have chosen to make it (and Functor) a superclass of Monad with the proper default implementation; after all (1) Applicative is damn useful, and (2) it's the common case. > More generally, specifying what you want is really not hard. Do you really > have gazillions of monads in your code you have to repeat this > implementation for? Yes, actually. First, I like writing monads. See http://hackage.haskell.org/cgi-bin/hackage-scripts/package/MonadPrompt-1.0.0.1 And second, just today I had to write instance Applicative STM where pure = return (<*>) = ap It felt like it was driving home the point. > > 2) You can't add sensible superclasses. I was playing with QuickCheck > > and wanted to write "equal with regards to testing". So I wrote up a > > class for it: > > > > class TestableEq a where > > (~=) :: a -> a -> Property > > > > instance Eq a => TestableEq a where > > -- should be a superclass of Eq instead! > > a ~= b = a == b > > > > Again, this is one (*) line per type. How many types do you declare? I don't declare too many myself, except on days when I'm trying to embed system F in Haskell via GADTs, but I use a lot of them; and many of them the authors have conveniently already made instances of useful typeclasses. Then I try to add some new functionality and run into a lot of friction because now every library I use needs an implementation which matches. Have you ever tried to write a monad transformer that is compatible with the MTL? O(n^2) instances is not a fun place to be, especially when most of the definitions are just variations on "lift". Disclaimer: this is actually a hard problem; I don't expect the compiler to be able to solve it, but it's frustrating nonetheless. The things I bring up here are easy in comparison. > > Sure, there is an alternative: I could manually declare instances of > > TestableEq for EVERY SINGLE TYPE that is an instance of Eq. I am sure > > nobody here would actually suggest that I do so. > Bzzzt. Wrong. Thanks for playing! Ha ha, you got me there :) > > But why do I need to jump through these hoops for a perfectly safe & > > commonly desired operation? > > It's called a proof obligation. My argument is that there shouldn't even be a proof obligation here; the language is just not expressive enough to allow me to write the code that I want; something that is actually completely decidable & non-overlapping. > > 3) There's no reflection or ability to choose an implementation based > > on other constraints. > > > > In QuickCheck, (a -> b) is an instance of Arbitrary for appropriate a, > > b. But you can't use this instance in forAll or for testing functions > > without being an instance of Show. Now, this is probably a design > > mistake, but it's the right choice with the current typeclass system > > (see (2)). But it'd be a million times better to have something like > > the following: > > > > class Arbitrary a => MkArbitrary a where > > mkArbitrary :: Gen (a, String) > > > > case instance MkArbitrary a where > > Show a => > > mkArbitrary = do > > x <- arbitrary > > return (x, show x) > > otherwise => > > mkArbitrary = do > > st <- getGenState > > x <- arbitrary > > return (x, "evalGen arbitrary " ++ show st) > > > > So we compile in a table of every instance and every datatype, add a > Typeable constraint to forAll (since parametricity just got shot to heck), > and scan through that table on every test. Millions of times better. And > slower. It's had a lot of research; I want the best of all worlds. For a start: http://www.google.com/search?q=optimizing+dynamic+dispatch You could get close without going to full dynamic dispatch, though; consider the following "core": -- This part is all in haskell now data ShowDict a = ShowDict { show :: a -> String } show_String :: ShowDict String show_Int :: ShowDict Int show_List :: ShowDict a -> ShowDict [a] -- foo :: Show a => [a] -> String -- foo x = show x ++ "!" foo :: ShowDict a -> [a] -> String foo sd x = show (show_List sd) x ++ "!" -- This part isn't in haskell, and the syntax sucks, but the idea is there. type MaybeShow a = Maybe (ShowDict a) -- bar :: MaybeInstance Show a => [a] -> String -- bar xs -- | Show a = foo xs -- | otherwise = show (length xs) bar :: MaybeShow a -> [a] -> String bar (Just sd) xs = foo sd xs bar Nothing xs = show (show_Int) (length xs) With this I could write instance (MaybeInstance Show a, Arbitrary a) => MkArbitrary a where mkArbitrary xs | Show a = do x <- arbitrary return (x, show x) | otherwise = do st <- getGenState x <- arbitrary return (x, "evalGen arbitrary " ++ show st) Now, every concrete type would be an instance of MaybeInstance , and "dynamic" dispatch and (I think) closed typeclasses would be a free benefit. > And more likely to develop odd changes and hard-to-debug errors. Or so you claim :) > QuickCheck makes testing so easy, I think the Arbitrary (a -> b) instance > is almost unnecessary; (btw., functions /are/ instances of Show). Now it's my turn to call: Prelude Test.QuickCheck> show ((\x -> x) :: Int -> Int) :1:0: No instance for (Show (Int -> Int)) Although, I do see a useless instance in the standard prelude at http://www.haskell.org/haskell-report/standard-prelude.html I actually would love to have (unsafeShow :: a -> String) which made a "best effort" attempt (subject to the compiler's debugging level) to evaluate an object and tell you what it contains, including source code for functions if possible. > You can easily write a showable ADT encoding the functions you want to test. That's fair (and actually pretty interesting). But definitely less elegant than -- assuming Arbitrary (Behavior Int) prop_fmap_at :: (Int -> Int) -> Property prop_fmap_at f = fmap f . at ~= at . fmap f (see Conal's recent FRP paper for the formulation of this property) > > 4) Every concrete type should be an instance of Typeable without > > having to do anything, > > Sure. And seq should go back to being a class method. (See earlier about > parametricity being shot to heck). I have an excellent design which will > preserve the language's semantics (which are fine the way they are, thank > you), while being convenient for programmers, which this margin is too small > to contain.[1] At least we agree on something. But please don't keep your design to yourself, share! > Reflection is harder, because of the need for the lookup table with every > instance of every class I mentioned earlier. (And you get to figure out how > to encode polymorphic instances, too! Good luck[2]). See dynamic dispatch, above. Although polymorphic instances do seem tricky. But you could probably get away with treating each typeclass as a member of the "typerep" object for each type with some amount of lookup; doesn't one of the existing compilers implement typeclasses in this way already? -- ryan From igloo at earth.li Mon Apr 21 06:18:59 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Apr 21 06:13:57 2008 Subject: [Haskell-cafe] Announce: bytestring 0.9.1.0 In-Reply-To: <20080421000748.GA9187@scytale.galois.com> References: <20080420220933.GA29143@scytale.galois.com> <20080420224828.GA7794@localhost> <1208735474-sup-9554@continuum> <20080421000748.GA9187@scytale.galois.com> Message-ID: <20080421101859.GA19000@matrix.chaos.earth.li> On Sun, Apr 20, 2008 at 05:07:48PM -0700, Donald Bruce Stewart wrote: > > The use of bytestring inside GHC is limited only to a little bit in the > GHCi modules -- and could easily be replaced, I suspect. Doing so would > remove one dependency from GHC's core, as well as making it easier to > upgrade bytestring versions. Ian, have you looked at this? I'd certainly be happy for bytestring to be removed from the bootlibs. When I last looked this was pretty easy to do. The only reason it's still in bootlibs at the moment is that you and/or Duncan were talking about rewriting some of the IO library on top of it, but if that happens in the future then we can always put it back into bootlibs again. Thanks Ian From igloo at earth.li Mon Apr 21 06:27:59 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Apr 21 06:22:55 2008 Subject: [Haskell-cafe] Announce: bytestring 0.9.1.0 In-Reply-To: <1208737640.5960.153.camel@dell.linuxdev.us.dell.com> References: <20080420220933.GA29143@scytale.galois.com> <20080420224828.GA7794@localhost> <1208735474-sup-9554@continuum> <1208737640.5960.153.camel@dell.linuxdev.us.dell.com> Message-ID: <20080421102759.GB19000@matrix.chaos.earth.li> On Mon, Apr 21, 2008 at 01:27:20AM +0100, Duncan Coutts wrote: > > I guess we could try and adjust the names of the > C symbols to include the package name and version. Or just rewrite the C bits in Haskell? There isn't much of it, and it doesn't look like there is a good reason that C should be able to do it more efficiently than Haskell impls. Thanks Ian From martin.sulzmann at gmail.com Mon Apr 21 06:44:09 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Mon Apr 21 06:39:07 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <4808E2AE.2080703@gmail.com> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <5ab17e790804171009l6d974cf2va38cbd94dccf3303@mail.gmail.com> <48078851.1050201@gmail.com> <5ab17e790804171113i647ff98ftde208ca753f88f0d@mail.gmail.com> <48079F85.5030408@gmail.com> <5ab17e790804181028i20a6961au8ca528871170b460@mail.gmail.com> <4808E2AE.2080703@gmail.com> Message-ID: <480C6FF9.3020607@gmail.com> I now recall the reason for NOT using D a b, D [a] c ==> c = [b] The reason is that the above rule creates a new critical pair with instance D a b => D [a] [b] To resolve the critical pair we need yet another rule D a b, D [[a]] c ==> c =[[b]] You can already see where this leads to. In general, we need an infinite rules of the form D a b, D [a]^k c ==> c = [b]^k where [a]^k stands for the k nested list [ ... [a] ... ] The FD-CHR approach therefore proposes to use D [a] c ==> c = [b] which is a "stronger" rule (that is, is not a logical consequence). Martin Martin Sulzmann wrote: > Thanks Iavor! Things become now clear. > > Let's consider our running example > > class D a b | a -> b > instance D a b => D [a] [b] > > which we can write in CHR notation > > D a b, D a c ==> b=c (FD) > > D [a] [b] <=> D a b (Inst) > > These rules overlap. > > Let's consider the critical pair > > D [a] [b], D [a] c > > The following two derivations are possible > > D [a] [b], D [a] c > -->FD D [a] [b], c = [b] > -->Inst D a b, c = [b] > > > D [a] [b], D [a] c > -->Inst D a b, D [a] c > > The two final stores differ which means that the > CHR system is non-confluent. Hence, the > proof theory is (potentially) incomplete. > What does this mean? > Logically true statement may not be derivable > using our CHR/typeclass-FD solver. > > Iavor suggests to add the rule > > D [a] c, D a b ==> c = [b] (Imp1) > > Makes perfect sense! > > This rule is indeed a theorem and makes the system confluent. > > But that's not what the FD-CHR paper does. > > The FD-CHR paper generates the "stronger" rule > > D [a] c ==> c = [b] (Imp2) > > This rule is NOT a theorem (ie logical consequence from the > FD and Inst rule). > But this rule also makes the system confluent. > > Why does the FD-CHR paper suggest this rule. > Some reasons: > > - the (Imp2) matches the GHC and I believe also Hugs implementation > - the (Imp2) is "easier" to implement, we only need to look for > a single constraint when firing the rule > - (Arguable) The (Imp2) matches better the programmer's intuition. > We only consider the instance head when generating improvement > but ignore the instance context. > - (Historical note: The rule suggested by Iavor were discussed > when writing the FD-CHR paper but somehow we never > pursued this alternative design space. > I have to dig out some old notes, maybe there some other reasons, > infinite completion, why this design space wasn't pursued). > > To summarize, I see now where the confusion lies. > The FD-CHR studies a "stronger" form of FDs where the CHR > improvement rules generated guarantee confluence but the > rules are not necessarily logical consequence. > Therefore, the previously discussed property > > a -> b and a -> c iff a -> b c > > does of course NOT hold. That is, > the combination of improvement rules derived from a -> b and a -> c > is NOT equivalent to the improvement rules derived from a -> b c. > Logically, the equivalence obviously holds. > > Martin > > > Iavor Diatchki wrote: >> Hello, >> >> On Thu, Apr 17, 2008 at 12:05 PM, Martin Sulzmann >> wrote: >> >>> Can you pl specify the improvement rules for your interpretation of >>> FDs. >>> That would help! >>> >> >> Each functional dependency on a class adds one extra axiom to the >> system (aka CHR rule, improvement rule). For the example in question >> we have: >> >> class D a b | a -> b where ... >> >> the extra axiom is: >> >> forall a b c. (D a b, D a c) => (b = c) >> >> This is the definition of "functional dependency"---it specifies that >> the relation 'D' is functional. An improvement rule follows from a >> functional dependency if it can be derived from this rule. For >> example, if we have an instance (i.e., another axiom): >> >> instance D Char Bool >> >> Then we can derive the following theorem: >> >> (D Char a) => (a = Bool) >> >> I think that in the CHR paper this was called "instance" improvement. >> Note that this is not an extra axiom but rather a theorem---adding it >> to the system as an axiom does not make the system any more >> expressive. Now consider what happens when we have a qualified >> instance: >> >> instance D a a => D [a] [a] >> >> We can combine this with the FD axiom to get: >> >> (D a a, D [a] b) => b = [a] >> >> This is all that follows from the functional dependency. Of course, >> in the presence of other instances, we could obtain more improvement >> rules. >> >> As for the "consistency rule", it is intended to ensure that instances >> are consistent with the FD axiom. As we saw from the previous >> examples, it is a bit conservative in that it rejects some instances >> that do not violate the functional dependency. Now, we could choose >> to exploit this fact to compute stronger improvement rules---nothing >> wrong with that. However, this goes beyond FDs. >> >> -Iavor >> >> >> >> >> >> >> >> >> >>> I'm simply following Mark Jones' style FDs. >>> >>> Mark's ESOP'00 paper has a consistency condition: >>> If two instances match on the FD domain then the must also match on >>> their >>> range. >>> The motivation for this condition is to avoid inconsistencies when >>> deriving improvement rules from instances. >>> >>> For >>> >> >> >> >>> class D a b | a -> b >>> >>> instance D a a => D [a] [a] >>> instance D [Int] Char >>> >>> >>> we get >>> >>> D [a] b ==> b =[a] >>> D [Int] b ==> b=Char >>> >>> In case of >>> >>> D [Int] b we therefore get b=Char *and* b =[a] which leads to a >>> (unification) error. >>> The consistency condition avoids such situations. >>> >>> >>> The beauty of formalism FDs with CHRs (or type functions/families) >>> is that >>> the whole improvement process becomes explicit. Of course, it has >>> to match >>> the programmer's intuition. See the discussion regarding >>> multi-range FDs. >>> >>> Martin >>> >>> >>> > From hthiel.char at zonnet.nl Mon Apr 21 07:38:49 2008 From: hthiel.char at zonnet.nl (Hans van Thiel) Date: Mon Apr 21 07:35:38 2008 Subject: [Haskell-cafe] Hackage being too strict? In-Reply-To: <20080418151911.B6895E4001@webmail219.herald.ox.ac.uk> References: <1208511804.5960.14.camel@dell.linuxdev.us.dell.com> <200804180805.12793.jgoerzen@complete.org> <20080418151911.B6895E4001@webmail219.herald.ox.ac.uk> Message-ID: <1208777929.3503.59.camel@localhost.localdomain> On Fri, 2008-04-18 at 16:19 +0100, Duncan Coutts wrote: > If there are any that you think are rejecting legitimate packages then do > complain (as in this thread). I was sloppy in my upload of Emping 0.5 in not checking the libraries dependencies sufficiently and not doing a build (my apologies about that). So then I did do a local build, and even corrected a warning about a type conversion to Double that GHC 6.8.2 (my version on FC 8) with -Wall -Werror seems to have missed. So the local build went well, but the Hackage build still appears to fail. Message: ** setup configure Configuring Emping-0.5.1... cabal-setup: At least the following dependencies are missing: gtk -any I'll have to leave it at that, since my local Cabal version does configure and build, and I obviously can't use Hackage as a development tool, uploading new versions until I get it right. Or, on second thought, does the above message just mean there's no gtk on Hackage? Some general questions, suggestions: To improve the usability of Hackage, wouldn't it be better to hold new uploads in limbo until they pass all the checks, instead of publishing them anyway? The current a priori check, which said there were no fatal errors, while the a posteriori check failed, is misleading. Wouldn't it be better to warn potential uploaders that this first check is not complete? I'd also like the warning about the -O2 optimization flag to go away...I'd guess this is a leftover from an earlier time in GHC. More importantly, if Cabal is sort of an rpm for Haskell programs, shouldn't the uploader use version numbers of the libraries in the Cabal file? For example, I believe in my case at least gtk2hs 0.9.12 is needed, while Ubuntu seems to have only 0.9.11 (until a few months ago, at least). So, if an uploader knows such dependencies, how to express them? Thanks in advance, Hans van Thiel From emax at cs.chalmers.se Mon Apr 21 08:12:25 2008 From: emax at cs.chalmers.se (Emil Axelsson) Date: Mon Apr 21 08:07:39 2008 Subject: [Haskell-cafe] Help with associated types In-Reply-To: References: <4807401C.7060006@cs.chalmers.se> Message-ID: <480C84A9.8020404@cs.chalmers.se> Thanks for the explanation! I didn't realize associate data types were different in that respect, but it makes sense to me now. I think associated data types seem too heavy-weight for my application. And anyway, just thinking about this made me simplify my previous solution to a three-parameter class, which makes things a lot nicer. / Emil On 2008-04-19 14:57, Niklas Broberg wrote: > Hi Emil, > > On 4/17/08, Emil Axelsson wrote: >> Hello! >> >> I'm trying to rewrite some FD classes to use associated types instead. The >> Port class is for type structures whose leaves have the same type: >> >> class Port p >> where >> type Leaf p >> type Struct p >> toList :: p -> [Leaf p] >> fromList :: [Leaf p] -> p >> >> (Leaf p) gives the leaf type, and (Struct p) gives a canonical >> representation of the structure regardless of leaf type. Here we just >> instantiate two leaf types: >> >> instance Port Int >> where >> type Leaf Int = Int >> type Struct Int = () >> toList a = [a] >> fromList [a] = a >> >> instance Port Bool >> where >> type Leaf Bool = Bool >> type Struct Bool = () >> toList a = [a] >> fromList [a] = a >> >> There's also a function for mapping over ports: >> >> mapPort :: >> ( Port pa >> , Port pb >> , Struct pa ~ Struct pb >> ) => >> (Leaf pa -> Leaf pb) -> (pa -> pb) >> >> mapPort f = fromList . map f . toList >> >> The equality constraint makes sure that we're mapping between equal >> structures. When I try to run this, I get: >> >> *Main> mapPort even (5::Int) >> >> :1:8: >> No instance for (Integral (Leaf Int)) >> ... >> > > the problem here is that Leaf p doesn't determine p, e.g. there can be > many different types p for which Leaf p = Int. It has nothing to do > with the Struct type. > >> What's the easiest way to encode that pb can be inferred from (Struct pb) >> and (Leaf pb)? > > If you want the dependency Leaf p -> p then Leaf needs to be > injective, i.e. you need to use an accociated datatype rather than > just a type. Here's a sketch that shows this: > > class Port p > where > data Leaf p -- note the use of data here > type Struct p > toList :: p -> [Leaf p] > fromList :: [Leaf p] -> p > > instance Port Int > where > newtype Leaf Int = IntLeaf Int > type Struct Int = () > toList a = [IntLeaf a] > fromList [IntLeaf a] = a > > instance Port Bool > where > newtype Leaf Bool = BoolLeaf Bool > type Struct Bool = () > toList a = [BoolLeaf a] > fromList [BoolLeaf a] = a > > mapPort :: > ( Port pa > , Port pb > , Struct pa ~ Struct pb > ) => > (Leaf pa -> Leaf pb) -> (pa -> pb) > > mapPort f = fromList . map f . toList > > The problem now is of course that the arguments to f will now be a lot > more complex, since the Leaf type is more complex. So to call this you > would have to say > > *Port> let f (IntLeaf n) = BoolLeaf (even n) in mapPort f 1 > False > > Not very pretty, but that's the way it goes if you want that > dependency. So in the general case, > >> If I have a class with some dependencies, say >> >> a -> ..., b c -> ... >> >> Is it possible to encode this using associated types without having all of a, b >> and c as class parameters? > > Yes it can be done, if you use associated *datatypes* instead of > associated types. But as you can see, it introduces extra overhead. > > Cheers, > > /Niklas From dougal at dougalstanton.net Mon Apr 21 11:22:49 2008 From: dougal at dougalstanton.net (Dougal Stanton) Date: Mon Apr 21 11:17:47 2008 Subject: [Haskell-cafe] Functional board games Message-ID: <2d3641330804210822r434fd4a9id188f33368fbe545@mail.gmail.com> I'm having a go at making a functional board game (the back-end logic for one, at least) and as with all good projects it raises lots of questions. But I'll keep it to one this time. Does anyone know of functional-style implementations of chess/draughts/go/anything else that might give me ideas? I am writing a game of Thud (yes, from the Terry Pratchett book...) but I don't hold much hope of their being a functional-style Thud game already in existence! Cheers, D. -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net From jefferson.r.heard at gmail.com Mon Apr 21 11:39:30 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Mon Apr 21 11:34:25 2008 Subject: [Haskell-cafe] Functional board games In-Reply-To: <2d3641330804210822r434fd4a9id188f33368fbe545@mail.gmail.com> References: <2d3641330804210822r434fd4a9id188f33368fbe545@mail.gmail.com> Message-ID: <4165d3a70804210839g1656a4ady63c91d9d907d2b4@mail.gmail.com> Ralph Glass has a Xiang Qi board: http://xiangqiboard.blogspot.com/ On Mon, Apr 21, 2008 at 11:22 AM, Dougal Stanton wrote: > I'm having a go at making a functional board game (the back-end logic > for one, at least) and as with all good projects it raises lots of > questions. But I'll keep it to one this time. > > Does anyone know of functional-style implementations of > chess/draughts/go/anything else that might give me ideas? I am writing > a game of Thud (yes, from the Terry Pratchett book...) but I don't > hold much hope of their being a functional-style Thud game already in > existence! > > Cheers, > > D. > > -- > Dougal Stanton > dougal@dougalstanton.net // http://www.dougalstanton.net > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080421/6237d01a/attachment.htm From bulat.ziganshin at gmail.com Mon Apr 21 11:42:00 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Apr 21 11:49:50 2008 Subject: [Haskell-cafe] Functional board games In-Reply-To: <2d3641330804210822r434fd4a9id188f33368fbe545@mail.gmail.com> References: <2d3641330804210822r434fd4a9id188f33368fbe545@mail.gmail.com> Message-ID: <1698882639.20080421194200@gmail.com> Hello Dougal, Monday, April 21, 2008, 7:22:49 PM, you wrote: > Does anyone know of functional-style implementations of > chess/draughts/go/anything else that might give me ideas? I am writing once we have seen 100-line chess published in this list -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Mon Apr 21 12:01:25 2008 From: dons at galois.com (Don Stewart) Date: Mon Apr 21 11:56:39 2008 Subject: [Haskell-cafe] Functional board games In-Reply-To: <1698882639.20080421194200@gmail.com> References: <2d3641330804210822r434fd4a9id188f33368fbe545@mail.gmail.com> <1698882639.20080421194200@gmail.com> Message-ID: <20080421160125.GA30140@scytale.galois.com> bulat.ziganshin: > Hello Dougal, > > Monday, April 21, 2008, 7:22:49 PM, you wrote: > > > Does anyone know of functional-style implementations of > > chess/draughts/go/anything else that might give me ideas? I am writing > > once we have seen 100-line chess published in this list > There's more than a dozen games here, http://haskell.org/haskellwiki/Applications_and_libraries/Games including hsChess. From ryani.spam at gmail.com Mon Apr 21 12:08:17 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Apr 21 12:03:14 2008 Subject: [Haskell-cafe] Functional board games In-Reply-To: <2d3641330804210822r434fd4a9id188f33368fbe545@mail.gmail.com> References: <2d3641330804210822r434fd4a9id188f33368fbe545@mail.gmail.com> Message-ID: <2f9b2d30804210908h35f04edi34db7d9601ccbab5@mail.gmail.com> Bertrand Felgenhauer[1] wrote a peg solitaire game[2] using Prompt[3] to interact with the user. Here's the core game loop: -- move a peg into a certain direction data Move = Move Pos Dir -- solitaire interface data Request a where RMove :: Board -> [Move] -> Request Move -- select a move from given list RDone :: Board -> Int -> Request () -- game over -- implement the game logic game :: Prompt Request () game = game' start -- find possible moves, end game if there are none, otherwise ... game' :: Board -> Prompt Request () game' b = do let options = filter (validMove b) allMoves if null options then prompt $ RDone b (length (pegs b)) else game'' b options -- ... prompt for a move and execute it game'' b options = do Move (x, y) d <- prompt $ RMove b options let (dx, dy) = delta d game' (Board (board b // [((x, y), Empty), ((x + dx, y + dy), Empty), ((x + 2*dx, y + 2*dy), Peg)])) -- ryan [1] http://www.haskell.org/pipermail/haskell-cafe/2008-January/038301.html [2] http://int-e.home.tlink.de/haskell/solitaire.tar.gz [3] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/MonadPrompt-1.0.0.1 On Mon, Apr 21, 2008 at 8:22 AM, Dougal Stanton wrote: > I'm having a go at making a functional board game (the back-end logic > for one, at least) and as with all good projects it raises lots of > questions. But I'll keep it to one this time. > > Does anyone know of functional-style implementations of > chess/draughts/go/anything else that might give me ideas? I am writing > a game of Thud (yes, from the Terry Pratchett book...) but I don't > hold much hope of their being a functional-style Thud game already in > existence! > > Cheers, > > D. > > -- > Dougal Stanton > dougal@dougalstanton.net // http://www.dougalstanton.net > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dougal at dougalstanton.net Mon Apr 21 13:54:09 2008 From: dougal at dougalstanton.net (Dougal Stanton) Date: Mon Apr 21 13:49:05 2008 Subject: [Haskell-cafe] Functional board games In-Reply-To: <2f9b2d30804210908h35f04edi34db7d9601ccbab5@mail.gmail.com> References: <2d3641330804210822r434fd4a9id188f33368fbe545@mail.gmail.com> <2f9b2d30804210908h35f04edi34db7d9601ccbab5@mail.gmail.com> Message-ID: <2d3641330804211054h41b2225fj6914cef448deb@mail.gmail.com> On Mon, Apr 21, 2008 at 5:08 PM, Ryan Ingram wrote: > Bertrand Felgenhauer[1] wrote a peg solitaire game[2] using Prompt[3] > to interact with the user. Thanks to everyone for the suggestions, particularly the Games page on the Haskell wiki which didn't appear in all my googling atttempts. Also, I had been hoping to have a go with Prompt after I saw it first time round but couldn't remember what it was called! So thanks to Ryan for bringing it up again. Cheers, D. -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net From dons at galois.com Mon Apr 21 14:11:19 2008 From: dons at galois.com (Don Stewart) Date: Mon Apr 21 14:06:20 2008 Subject: [Haskell-cafe] ANNOUNCE: Galois web libraries for Haskell released Message-ID: <20080421181119.GB8601@scytale.galois.com> Galois, Inc. is pleased to announce the open source release of a suite of web programming libraries for Haskell! The following libraries are available, providing support for a wide range of Haskell web programming scenarios: * json JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. This library provides a validating parser and pretty printer for converting between Haskell values and JSON. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/json * xml A simple, lightweight XML parser/generator. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml * utf8-string A UTF8 layer for IO and Strings. The utf8-string package provides operations for encoding UTF8 strings to Word8 lists and back, and for reading and writing UTF8 without truncation. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utf8-string * selenium Haskell bindings to communicate with a Selenium Remote Control server. This package makes it possible to use Haskell to write test scripts that exercise web applications through a web browser. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/selenium * curl libcurl is a client-side URL transfer library, supporting FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS and FILE. libcurl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, cookies, user+password authentication (Basic, Digest, NTLM, Negotiate, Kerberos4), file transfer resume, http proxy tunneling and more! This package provides a Haskell binding to libcurl. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/curl * sqlite Haskell binding to sqlite3 , a light, fast database. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sqlite * feed Interfacing with RSS (v 0.9x, 2.x, 1.0) and Atom feeds http://hackage.haskell.org/cgi-bin/hackage-scripts/package/feed * mime Haskell support for working with MIME types. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mime Together these fill in a big chunk of the web programming stack for Haskell. Get the code! You can find all the cabalised packages on hackage.haskell.org. About: Galois researches, designs and develops high assurance technologies for security-critical systems, networks and applications. We use Haskell as a primary development tool for producing robust components for a diverse range of clients. Web-based technologies are increasingly important in this area, and we believe Haskell has a key role to play in the production of reliable, secure web software. The culture of correctness Haskell encourages is ideally suited to web programming, where issues of security, authentication, privacy and protection of resources abound. In particular, Haskell's type system makes possible strong static guarantees about access to resources, critical to building reliable web applications. We hope that the release of this suite of libraries to the community will push further the adoption of Haskell in the domain of web programming. This release brought to you by: Iavor Diatchki Trevor Elliott Sigbjorn Finne Andy Gill Eric Mertens Isaac Potoczny-Jones Don Stewart Aaron Tomb From qdunkan at gmail.com Mon Apr 21 14:12:52 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Mon Apr 21 14:07:47 2008 Subject: [Haskell-cafe] functional update Message-ID: <2518b95d0804211112k1eae26d2j6fa0a5befd4c772@mail.gmail.com> Here's some haskell to update a particular field in a data structure (the below run in a StateT / ErrorT context): > set_track_width :: (UiStateMonad m) => > Block.ViewId -> Int -> Block.Width -> m () > set_track_width view_id tracknum width = do > view <- get_view view_id > track_views <- modify_at (Block.view_tracks view) tracknum $ \tview -> > tview { Block.track_view_width = width } > update_view view_id (view { Block.view_tracks = track_views }) Plus some utilities: > modify_at xs i f = case post of > [] -> throw $ "can't replace index " ++ show i > ++ " of list with length " ++ show (length xs) > (elt:rest) -> return (pre ++ f elt : rest) > where (pre, post) = splitAt i xs > update_view view_id view = modify $ \st -> st > { state_views = Map.adjust (const view) view_id (state_views st) } A similar imperative update would look something like this: > state.get_view(view_id).tracks[tracknum].width = width Has there been any work on improving update syntax in haskell? Possibly some improvement could be made with a typeclass or two and a few custom operators, to unify some of the disparate syntax. Maybe more improvement could be made with some TH hackery. A better record update syntax I'm sure could improve things even more. Or maybe there's a way to structure existing code to improve the above? Does anyone know of work that's been done on analysing functional update syntax issues, and coming up with something concise and clear? Other functional languages that do this better? It seems like an obvious candidate for improvement. Probably not an easy one though. There are various overlapping issues: monadic binds not mixing easily with non-monadic functions, different data structures (maps, lists, ...) having different update functions, record update syntax being super wordy, and probably some other things I'm not thinking of. As an aside, on the record system side, I would love to see one of the proposed record systems implemented in GHC, whether it be trex or the "lighter weight" version proposed by one of the Simons. Does anyone know what the main hangup is? Unresolved issues in the proposal? No consensus? Backward incompatibility? Not enough interested GHC devs? All I can say is that as a heavy user of (.) I wouldn't mind replacing them all with (#) or (@) or whatever if I got a nicer record syntax. It wouldn't be hard to write a search/replace for (.). From jgoerzen at complete.org Mon Apr 21 14:18:25 2008 From: jgoerzen at complete.org (John Goerzen) Date: Mon Apr 21 14:13:21 2008 Subject: [Haskell-cafe] Laziness and Either Message-ID: <200804211318.25854.jgoerzen@complete.org> Back when I was working on the logic for the bin-packing solver that I added to MissingH (for use with datapacker), I had a design decision to make: do I raise runtime errors with the input using error, or do I use an Either type to return errors? Initially, for simplicity, I just used error. But when I did a simple refactoring to use Either, it occurred to me that this switch likely had a negative impact on laziness. In this particular algorithm, we cannot tell for sure that we have no errors until we have consumed all items of the input list. This is unlike, say, a safe version of "head" where you can tell whether you have an error just by whether you have an empty list or not. In the case of using "error", we can happily process the data assuming everything will be fine, and raise an error if and when it is encountered. By using Either, however, any pattern match on the Left/Right result is going to force the entire input to be evaluated so that we can know whether or not it had any error. Is this analysis sensible? If so, are there better solutions? BTW, here are links to the code I'm talking about: http://git.complete.org/datapacker?a=blob;f=Scan.hs;h=d4e8ac8d6e883f342096a4618bb4fa9539162b79;hb=18e774ba27bd4857fd13fcbdd62083dc8c11ff56 line 32-43 -- version that uses error http://git.complete.org/datapacker?a=blob;f=Scan.hs;h=acd53739f5d871a3ce7ae66346050ef82c2a1254;hb=0d4e3ee6c4e5c780009ad5c09dfd79cc0df8ae90 line 32-46 -- version that uses Either http://git.complete.org/datapacker?a=commitdiff;h=0d4e3ee6c4e5c780009ad5c09dfd79cc0df8ae90 -- diff between them -- John From allbery at ece.cmu.edu Mon Apr 21 14:21:21 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Apr 21 14:16:25 2008 Subject: [Haskell-cafe] I hate Haskell's typeclasses In-Reply-To: <2f9b2d30804210050h58aac9e4xf2de56331d244ba@mail.gmail.com> References: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> <2f9b2d30804210050h58aac9e4xf2de56331d244ba@mail.gmail.com> Message-ID: <6B171C9B-BDCA-4CFF-ABBC-DFA2D4FCB157@ece.cmu.edu> On Apr 21, 2008, at 3:50 , Ryan Ingram wrote: >> is almost unnecessary; (btw., functions /are/ instances of Show). > > Now it's my turn to call: > > Prelude Test.QuickCheck> show ((\x -> x) :: Int -> Int) > :1:0: > No instance for (Show (Int -> Int)) import Data.Function. (but it is indeed a useless instance) A slightly less useless instance (more or less the one lambdabot uses) is at http://www.cmu.edu.edu/~allbery/FuncShow.hs; note that it only works for monomorphic functions (more specifically, for functions whose parameters are Typeable). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From mfn-haskell-cafe at cs.york.ac.uk Mon Apr 21 14:20:23 2008 From: mfn-haskell-cafe at cs.york.ac.uk (Matthew Naylor) Date: Mon Apr 21 14:18:40 2008 Subject: [Haskell-cafe] Functional board games In-Reply-To: <2d3641330804210822r434fd4a9id188f33368fbe545@mail.gmail.com> References: <2d3641330804210822r434fd4a9id188f33368fbe545@mail.gmail.com> Message-ID: <20080421182023.GA18334@turin.staff.cs.york.ac.uk> Hi Dougal, > Does anyone know of functional-style implementations of > chess/draughts/go/anything else that might give me ideas? there's the Mate-in-N solver in the nofib suite: ftp://www.cs.york.ac.uk/pub/haskell/nofib.tar.gz It takes quite a simple approach, representing the board as two lists (white and black) of piece/square pairs, where a square is just a pair of ints. Matt. From allbery at ece.cmu.edu Mon Apr 21 14:30:13 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Apr 21 14:25:10 2008 Subject: [Haskell-cafe] Hackage being too strict? In-Reply-To: <1208777929.3503.59.camel@localhost.localdomain> References: <1208511804.5960.14.camel@dell.linuxdev.us.dell.com> <200804180805.12793.jgoerzen@complete.org> <20080418151911.B6895E4001@webmail219.herald.ox.ac.uk> <1208777929.3503.59.camel@localhost.localdomain> Message-ID: <91905083-D679-4A33-87F9-6AC255FE4426@ece.cmu.edu> On Apr 21, 2008, at 7:38 , Hans van Thiel wrote: > On Fri, 2008-04-18 at 16:19 +0100, Duncan Coutts wrote: >> If there are any that you think are rejecting legitimate packages >> then do >> complain (as in this thread). > Configuring Emping-0.5.1... > cabal-setup: At least the following dependencies are missing: > gtk -any cabal-install doesn't handle the case of ghc packages that aren't named the same as hackage packages? (gtk is part of the gtk2hs hackage) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From donn at avvanta.com Mon Apr 21 14:40:45 2008 From: donn at avvanta.com (Donn Cave) Date: Mon Apr 21 14:35:42 2008 Subject: [Haskell-cafe] Laziness and Either In-Reply-To: <200804211318.25854.jgoerzen@complete.org> References: <200804211318.25854.jgoerzen@complete.org> Message-ID: On Apr 21, 2008, at 11:18 AM, John Goerzen wrote: > In the case of using "error", we can happily process the data assuming > everything will be fine, and raise an error if and when it is > encountered. > By using Either, however, any pattern match on the Left/Right > result is > going to force the entire input to be evaluated so that we can know > whether > or not it had any error. > > Is this analysis sensible? If so, are there better solutions? In another thread back on March 12 ("Exception handling when using STUARrray") I read `Since the decision between Left and Right requires all parts to be evaluated, it's Either that might too strict for your application. What about a writer monad, where exceptions, or better say warnings, are written to the writer stream?' I don't believe I ever got around to evaluating that recommendation (lazy evaluation strategy, indeed.) I think I would use "error". Donn Cave, donn@u.washington.edu From allbery at ece.cmu.edu Mon Apr 21 14:47:50 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Apr 21 14:42:46 2008 Subject: [Haskell-cafe] I hate Haskell's typeclasses In-Reply-To: <6B171C9B-BDCA-4CFF-ABBC-DFA2D4FCB157@ece.cmu.edu> References: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> <2f9b2d30804210050h58aac9e4xf2de56331d244ba@mail.gmail.com> <6B171C9B-BDCA-4CFF-ABBC-DFA2D4FCB157@ece.cmu.edu> Message-ID: <6F05238E-F562-4E1A-8EAD-B81AFE16070C@ece.cmu.edu> On Apr 21, 2008, at 14:21 , Brandon S. Allbery KF8NH wrote: > http://www.cmu.edu.edu/~allbery/FuncShow.hs; note that it only > works for monomorphic functions (more Note to self: be more careful when you just woke up. http:// www.ece.cmu.edu/~allbery/FuncShow.hs -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From andrewcoppin at btinternet.com Mon Apr 21 14:54:24 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon Apr 21 14:49:05 2008 Subject: [Haskell-cafe] Glome.hs-0.3 and other things In-Reply-To: <48092AB9.30405@cs.pdx.edu> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> <4310375315.20080419001919@gmail.com> <20080418203222.GQ8763@darcs.net> <48090E08.1020109@cs.pdx.edu> <20080418213405.GT8763@darcs.net> <48092AB9.30405@cs.pdx.edu> Message-ID: <480CE2E0.8000600@btinternet.com> Jim Snow wrote: > Useful references: "What Every Programmer Needs to Know About Memory" > http://lwn.net/Articles/250967/ Thank you for monopolising my entire afternoon. This is probably the single most interesting thing I've read in ages! :-D Thinking about it, maybe this explains my sorting benchmark - sorting Word32 values probably involves more shifting data from place to place than actual computation, so it's probably limited by the bandwidth of the FSB than the CPU's ability to perform number chrunking. Running it in multiple threads is probably just thrashing the L2 cache rather than actually helping... After studying all this material, I do find myself feeling slightly concerned. The article shows how in C / C++ / assembly you can arrange your data and order your computations to make maximum use of the various caches and avoid certain bottlenecks in the system. And the *vast* performance difference it can yield. But what happens if you happen to be writing your program in Smalltalk or Java or... Haskell. Up here, you're so far from the hardware that it would seem that you have *no hope* of using the CPU caches effectively. Think about it - data scattered all over the heap in an essentially random pattern, getting moved around periodically by the GC. [Oh, the GC! That sounds like it must nail the hell out of the cache. And even if it doesn't, it more or less negates its usefulness because all the "hot" data is now at a different address.] Just think about trying to process a Haskell list - all those multiple levels of pointer indirection! The CPU has no hope of prefetching that stuff... Damn, it seems as if there's simply no way of ever making Haskell fast. :-( I suppose the idea is that Haskell is supposed to help you work at a higher level of abstraction, so you can concentrate on building better *algorithms* which require less work in the first place. Surely using an algorithm in a suitably superior complexity class could more than make up for the performance loss from lack of cache coherence. But people who work in C and C++ know how to build efficient algorithms too, so... hmm, we seem to be in trouble here. From daveroundy at gmail.com Mon Apr 21 15:15:49 2008 From: daveroundy at gmail.com (David Roundy) Date: Mon Apr 21 15:10:50 2008 Subject: [Haskell-cafe] Glome.hs-0.3 and other things In-Reply-To: <480CE2E0.8000600@btinternet.com> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> <4310375315.20080419001919@gmail.com> <20080418203222.GQ8763@darcs.net> <48090E08.1020109@cs.pdx.edu> <20080418213405.GT8763@darcs.net> <48092AB9.30405@cs.pdx.edu> <480CE2E0.8000600@btinternet.com> Message-ID: <117f2cc80804211215p6018e523xc4125f3740958668@mail.gmail.com> On Mon, Apr 21, 2008 at 11:54 AM, Andrew Coppin wrote: > I suppose the idea is that Haskell is supposed to help you work at a higher > level of abstraction, so you can concentrate on building better *algorithms* > which require less work in the first place. Surely using an algorithm in a > suitably superior complexity class could more than make up for the > performance loss from lack of cache coherence. But people who work in C and > C++ know how to build efficient algorithms too, so... hmm, we seem to be in > trouble here. I don't think things are so glum. There are certainly things we can do to control where data is located (e.g. using unboxed arrays and keeping track of strictness, and strict data types combined with -funboxstrictidontrecalltheexactpragma). In truth, C++ programs also tend to have severe issues with memory use. Garbage collection is horrible on the cache, but it's also done relatively infrequently (at least, full GCs are). Writing seriously fast Haskell code is indeed challenging, but it's a fun challenge. And writing bug-free code is also a fun challenge, and one at which we have a huge advantage over most other languages. And in Haskell we less are forced to choose between a horribly ugly implementation and a horribly inefficient implementation. David From duncan.coutts at worc.ox.ac.uk Mon Apr 21 15:43:55 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Apr 21 15:39:00 2008 Subject: [Haskell-cafe] Hackage being too strict? In-Reply-To: <91905083-D679-4A33-87F9-6AC255FE4426@ece.cmu.edu> References: <1208511804.5960.14.camel@dell.linuxdev.us.dell.com> <200804180805.12793.jgoerzen@complete.org> <20080418151911.B6895E4001@webmail219.herald.ox.ac.uk> <1208777929.3503.59.camel@localhost.localdomain> <91905083-D679-4A33-87F9-6AC255FE4426@ece.cmu.edu> Message-ID: <1208807035.27748.18.camel@localhost> On Mon, 2008-04-21 at 14:30 -0400, Brandon S. Allbery KF8NH wrote: > On Apr 21, 2008, at 7:38 , Hans van Thiel wrote: > > > On Fri, 2008-04-18 at 16:19 +0100, Duncan Coutts wrote: > >> If there are any that you think are rejecting legitimate packages > >> then do > >> complain (as in this thread). > > Configuring Emping-0.5.1... > > cabal-setup: At least the following dependencies are missing: > > gtk -any > > cabal-install doesn't handle the case of ghc packages that aren't > named the same as hackage packages? (gtk is part of the gtk2hs hackage) Or rather, Cabal defines the package name to be the same as the ghc package. So gtk2hs is not a hackage package at all and it's not on hackage. When we do get it cabalised it'll be 9 (semi-)independent cabal packages. Duncan From lemming at henning-thielemann.de Mon Apr 21 15:52:34 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Apr 21 15:46:07 2008 Subject: [Haskell-cafe] Laziness and Either In-Reply-To: References: <200804211318.25854.jgoerzen@complete.org> Message-ID: On Mon, 21 Apr 2008, Donn Cave wrote: > On Apr 21, 2008, at 11:18 AM, John Goerzen wrote: > >> In the case of using "error", we can happily process the data assuming >> everything will be fine, and raise an error if and when it is encountered. >> By using Either, however, any pattern match on the Left/Right result is >> going to force the entire input to be evaluated so that we can know whether >> or not it had any error. >> >> Is this analysis sensible? If so, are there better solutions? > > In another thread back on March 12 ("Exception handling when using > STUARrray") > I read `Since the decision between Left and Right requires all parts to be > evaluated, it's Either that might too strict for your application. What about > a writer monad, where exceptions, or better say warnings, are written to the > writer stream?' > > I don't believe I ever got around to evaluating that recommendation (lazy > evaluation strategy, indeed.) I think I would use "error". Was this advise from me? I would advise the Writer monad again. 'error' should be used only for programming errors, not for unexpected data or situations from the outside world. http://www.haskell.org/haskellwiki/Exception http://www.haskell.org/haskellwiki/Error From duncan.coutts at worc.ox.ac.uk Mon Apr 21 15:59:00 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Apr 21 15:54:05 2008 Subject: [Haskell-cafe] Hackage being too strict? In-Reply-To: <1208777929.3503.59.camel@localhost.localdomain> References: <1208511804.5960.14.camel@dell.linuxdev.us.dell.com> <200804180805.12793.jgoerzen@complete.org> <20080418151911.B6895E4001@webmail219.herald.ox.ac.uk> <1208777929.3503.59.camel@localhost.localdomain> Message-ID: <1208807940.27748.34.camel@localhost> On Mon, 2008-04-21 at 13:38 +0200, Hans van Thiel wrote: > Configuring Emping-0.5.1... > cabal-setup: At least the following dependencies are missing: > gtk -any > > I'll have to leave it at that, since my local Cabal version does configure and build, > and I obviously can't use Hackage as a development tool, uploading new versions until > I get it right. Or, on second thought, does the above message just mean there's no > gtk on Hackage? That's right. > Some general questions, suggestions: > > To improve the usability of Hackage, wouldn't it be better to hold new uploads in limbo > until they pass all the checks, instead of publishing them anyway? Yes. Or the way we've been thinking about it is to define various subsets of hackage of packages that pass various automatic and manual tests. Of course at the moment the package build is not sufficiently accurate to determine if a package builds eg the gtk issue you found. The plan there is to use the cabal-install client to gather build reports. > The current a priori check, which said there were no fatal errors, while the > a posteriori check failed, is misleading. Wouldn't it be better to warn potential > uploaders that this first check is not complete? I'm not sure I see what you're getting at. We can't do a full build check synchronously at upload time. > I'd also like the warning about the -O2 optimization flag to go > away...I'd guess this is a leftover from an earlier time in GHC. It's not a leftover, it was added recently. The intention is that user gets to set the optimisation level (cabal configure -O or -O2 or -O0). It's not really great when packages override that choice. From experience packaging haskell libraries for gentoo we found that most packages that do set -O2 do so out of habit without any particular justification and it significantly increases compile times and memory use. It's not banned though as there are some cases where it's perfectly justified. > More importantly, if Cabal is sort of an rpm for Haskell programs, shouldn't > the uploader use version numbers of the libraries in the Cabal file? For example, > I believe in my case at least gtk2hs 0.9.12 is needed, while Ubuntu seems to have > only 0.9.11 (until a few months ago, at least). So, if an uploader knows such > dependencies, how to express them? build-depends: gtk >= 0.9.12 && < 0.10 Duncan From malcolm.wallace at cs.york.ac.uk Mon Apr 21 16:05:48 2008 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Apr 21 16:00:43 2008 Subject: [Haskell-cafe] Laziness and Either In-Reply-To: <200804211318.25854.jgoerzen@complete.org> References: <200804211318.25854.jgoerzen@complete.org> Message-ID: > But when I did a simple > refactoring to use Either, it occurred to me that this switch likely > had a > negative impact on laziness. Yes, probably. > Is this analysis sensible? If so, are there better solutions? I notice that your Maybe-based code is written in a monadic style. If you also use Applicative Functors with an appropriately lazy instance for Maybe, you may be able to be both lazy (where needed) and strict (where needed) just by mixing and matching do-notation with apply- notation. The technique is explored in this paper about partial parsing: http://www-users.cs.york.ac.uk/~malcolm/partialparse.html Regards, Malcolm From andrewcoppin at btinternet.com Mon Apr 21 16:15:12 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon Apr 21 16:09:53 2008 Subject: [Haskell-cafe] Glome.hs-0.3 and other things In-Reply-To: <117f2cc80804211215p6018e523xc4125f3740958668@mail.gmail.com> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> <4310375315.20080419001919@gmail.com> <20080418203222.GQ8763@darcs.net> <48090E08.1020109@cs.pdx.edu> <20080418213405.GT8763@darcs.net> <48092AB9.30405@cs.pdx.edu> <480CE2E0.8000600@btinternet.com> <117f2cc80804211215p6018e523xc4125f3740958668@mail.gmail.com> Message-ID: <480CF5D0.3030007@btinternet.com> David Roundy wrote: > On Mon, Apr 21, 2008 at 11:54 AM, Andrew Coppin > wrote: > >> I suppose the idea is that Haskell is supposed to help you work at a higher >> level of abstraction, so you can concentrate on building better *algorithms* >> which require less work in the first place. Surely using an algorithm in a >> suitably superior complexity class could more than make up for the >> performance loss from lack of cache coherence. But people who work in C and >> C++ know how to build efficient algorithms too, so... hmm, we seem to be in >> trouble here. >> > > I don't think things are so glum. There are certainly things we can > do to control where data is located (e.g. using unboxed arrays and > keeping track of strictness, and strict data types combined with > -funboxstrictidontrecalltheexactpragma). In truth, C++ programs also > tend to have severe issues with memory use. Garbage collection is > horrible on the cache, but it's also done relatively infrequently (at > least, full GCs are). > > Writing seriously fast Haskell code is indeed challenging, but it's a > fun challenge. And writing bug-free code is also a fun challenge, and > one at which we have a huge advantage over most other languages. And > in Haskell we less are forced to choose between a horribly ugly > implementation and a horribly inefficient implementation. > Well now, if you're interesting in bug-free code, Haskell looks to me like pretty much the supreme ultimate language. Can you spell "safe"? I think we've got it pretty much nailed on that score. About the most dangerous thing a typical Haskell program can do is "head []" or looping forever. I do worry about performance, however. [I tend to write compute-bounded programs.] Sure, you can use arrays, but for whatever reason the API isn't nearly as nice as lists. (E.g., there is no zip function for arrays.) ByteString shows that arrays can be made fast - but ByteString is only for bytes. It strikes me that an idiomatic Haskell program - which does things like "length . filter p" and such - is going to utterly confound cache prefetch logic with endless layers of indirection. The basic execution model of Haskell is graph reduction. As I understand it [it's been a while since I read about this], GHC uses the spineless tagless G-machine. This fundamentally uses pointers to functions for every aspect of its implementation - graph reduction, deadlock detection, GC, concurrency, etc. Every step of traversing a structure on the heap potentially involves forcing a thunk, so at every step you're dereferencing function pointers. It must utterly confound the instruction and data caches - 0% coherence! Using [unboxed] arrays makes the situation a little more bearable for the data cache, but the poor instruction cache still has to handle control flow that jumps somewhere every few dozen instructions... From stefanor at cox.net Mon Apr 21 16:21:57 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Mon Apr 21 16:16:56 2008 Subject: [Haskell-cafe] Glome.hs-0.3 and other things In-Reply-To: <480CE2E0.8000600@btinternet.com> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> <4310375315.20080419001919@gmail.com> <20080418203222.GQ8763@darcs.net> <48090E08.1020109@cs.pdx.edu> <20080418213405.GT8763@darcs.net> <48092AB9.30405@cs.pdx.edu> <480CE2E0.8000600@btinternet.com> Message-ID: <20080421202156.GA3357@localhost.localdomain> On Mon, Apr 21, 2008 at 07:54:24PM +0100, Andrew Coppin wrote: > Jim Snow wrote: >> Useful references: "What Every Programmer Needs to Know About Memory" >> http://lwn.net/Articles/250967/ > After studying all this material, I do find myself feeling slightly > concerned. The article shows how in C / C++ / assembly you can arrange your > data and order your computations to make maximum use of the various caches > and avoid certain bottlenecks in the system. And the *vast* performance > difference it can yield. But what happens if you happen to be writing your > program in Smalltalk or Java or... Haskell. Up here, you're so far from the > hardware that it would seem that you have *no hope* of using the CPU caches > effectively. Think about it - data scattered all over the heap in an > essentially random pattern, getting moved around periodically by the GC. > [Oh, the GC! That sounds like it must nail the hell out of the cache. And > even if it doesn't, it more or less negates its usefulness because all the > "hot" data is now at a different address.] Just think about trying to > process a Haskell list - all those multiple levels of pointer indirection! > The CPU has no hope of prefetching that stuff... Damn, it seems as if > there's simply no way of ever making Haskell fast. :-( You're assuming the hardware is constant. "Modern" CPUs were designed back when everyone was using C++; this is changing now, and I for one am still optimistic that CPU designs will follow suit. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080421/ad58d16d/attachment-0001.bin From jgoerzen at complete.org Mon Apr 21 16:22:02 2008 From: jgoerzen at complete.org (John Goerzen) Date: Mon Apr 21 16:17:04 2008 Subject: [Haskell-cafe] Hoogle In-Reply-To: <08EB2755-AE6E-40E2-BBAA-CA40FA4CB35E@ece.cmu.edu> References: <5ae4f2ba0804161140k25b17cfaue7378471c15eee32@mail.gmail.com> <200804161630.57911.jgoerzen@complete.org> <08EB2755-AE6E-40E2-BBAA-CA40FA4CB35E@ece.cmu.edu> Message-ID: <200804211522.02760.jgoerzen@complete.org> On Wed April 16 2008 6:16:56 pm Brandon S. Allbery KF8NH wrote: > On Apr 16, 2008, at 17:30 , John Goerzen wrote: > > On Wed April 16 2008 3:54:45 pm Galchin, Vasili wrote: > >> I already found this link. Thanks in any case. I want to > >> O_CREATE a > >> file, i.e. do a openFd creating a new file. O_CREATE should be the > >> FileMode, but I don't see in the link below. > > > > Indeed. It seems there is no way to pass O_CREAT to openFile. > > there is > > createFile, but that's really a different call. Sigh. > > Remember, Haskell is functional; treat the function to call as an > argument? That misses the point; the two are different calls in C and full functionality is not exposed via the Haskell API. -- John From magnus at therning.org Mon Apr 21 16:26:04 2008 From: magnus at therning.org (Magnus Therning) Date: Mon Apr 21 16:21:24 2008 Subject: [Haskell-cafe] Laziness and Either In-Reply-To: <200804211318.25854.jgoerzen@complete.org> References: <200804211318.25854.jgoerzen@complete.org> Message-ID: <480CF85C.6040808@therning.org> John Goerzen wrote: > Back when I was working on the logic for the bin-packing solver that I added > to MissingH (for use with datapacker), I had a design decision to make: do I > raise runtime errors with the input using error, or do I use an Either type > to return errors? > > Initially, for simplicity, I just used error. But when I did a simple > refactoring to use Either, it occurred to me that this switch likely had a > negative impact on laziness. > > In this particular algorithm, we cannot tell for sure that we have no errors > until we have consumed all items of the input list. This is unlike, say, a > safe version of "head" where you can tell whether you have an error just by > whether you have an empty list or not. > > In the case of using "error", we can happily process the data assuming > everything will be fine, and raise an error if and when it is encountered. > By using Either, however, any pattern match on the Left/Right result is > going to force the entire input to be evaluated so that we can know whether > or not it had any error. > > Is this analysis sensible? If so, are there better solutions? This reminds me of a problem I had in dataenc[1], when trying to decode large files I ran out of memory. It was simple to track that down to my decision to use Maybe for the return type. Originally I only had one function for decoding: decode :: String -> Maybe [Word8] decode = sequence . decode' In order to allow lazy decoding I ended up exporting decode' as well: decode' :: String -> [Maybe Word8] Unfortunately that pushes handling of decoding errors to the layer above. Not ideal maybe, but it was the easiest solution. Duncan mentioned that iconv took a similar route to provide laziness[2]. I'm curious to see whether Malcom's paper can offer some further insight. /M [1]: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dataenc [2]: http://www.haskell.org/pipermail/haskell-cafe/2007-December/036282.html -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?gmail?com http://therning.org/magnus What if I don't want to obey the laws? Do they throw me in jail with the other bad monads? -- Daveman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080421/f8059966/signature.bin From jgoerzen at complete.org Mon Apr 21 16:42:39 2008 From: jgoerzen at complete.org (John Goerzen) Date: Mon Apr 21 16:37:33 2008 Subject: [Haskell-cafe] Laziness and Either In-Reply-To: <480CF85C.6040808@therning.org> References: <200804211318.25854.jgoerzen@complete.org> <480CF85C.6040808@therning.org> Message-ID: <200804211542.39334.jgoerzen@complete.org> On Mon April 21 2008 3:26:04 pm Magnus Therning wrote: > In order to allow lazy decoding I ended up exporting decode' as well: > > decode' :: String -> [Maybe Word8] I take it that in a situation like this, you'd have either: [] -- success with empty result a list full of Just x -- success with valid results a list with 0 or more Just x, followed by one Nothing -- an error Makes sense to me. What impact does this have on performance? Also, I wonder if there is some call for tools in Data.Either to support this type of usage? For example: type EitherList a b = [Either a b] then some functions such as, say, mapEither or foldEither that act like try/catch: a special function to use for an exception, and otherwise they "unwrap" the Right side passing it along to others. -- John From bertram.felgenhauer at googlemail.com Mon Apr 21 17:21:00 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Mon Apr 21 17:15:58 2008 Subject: [Haskell-cafe] Wrong Answer Computing Graph Dominators In-Reply-To: <6dbd4d000804170832h1391db15ob84e61d4e8960170@mail.gmail.com> References: <6dbd4d000804151759r2ca72957hae8cd60c91404e60@mail.gmail.com> <20080416183356.GA4362@zombie.inf.tu-dresden.de> <6dbd4d000804170832h1391db15ob84e61d4e8960170@mail.gmail.com> Message-ID: <20080421212100.GB4360@zombie.inf.tu-dresden.de> Denis Bueno wrote: > On Wed, Apr 16, 2008 at 2:33 PM, Bertram Felgenhauer > wrote: > > No. Data.Graph.Inductive.Query.Dominators is just buggy. > [...] > > Here's a quick fix: > > Thanks! This fixes my problem. > > Have you submitted a bug and your patch to the appropriate tracker? > If not, would someone point me to the appropriate one? Would in be > the GHC trac, or is there a libraries-specific one? The library is shipped with ghc, and the darcs repository lists libraries@haskell.org as the maintainer, so GHC's trac seems to be the right place. I've created a ticket for this now, See http://hackage.haskell.org/trac/ghc/ticket/2227 Note that I opted for reimplementing the whole module instead of just fixing the bug. regards, Bertram From dbueno at gmail.com Mon Apr 21 17:42:55 2008 From: dbueno at gmail.com (Denis Bueno) Date: Mon Apr 21 17:37:50 2008 Subject: [Haskell-cafe] Wrong Answer Computing Graph Dominators In-Reply-To: <20080421212100.GB4360@zombie.inf.tu-dresden.de> References: <6dbd4d000804151759r2ca72957hae8cd60c91404e60@mail.gmail.com> <20080416183356.GA4362@zombie.inf.tu-dresden.de> <6dbd4d000804170832h1391db15ob84e61d4e8960170@mail.gmail.com> <20080421212100.GB4360@zombie.inf.tu-dresden.de> Message-ID: <6dbd4d000804211442v7660bed0ycb65445b24049388@mail.gmail.com> On Mon, Apr 21, 2008 at 5:21 PM, Bertram Felgenhauer wrote: > Denis Bueno wrote: > > On Wed, Apr 16, 2008 at 2:33 PM, Bertram Felgenhauer > > wrote: > > > No. Data.Graph.Inductive.Query.Dominators is just buggy. > > [...] > > > Here's a quick fix: > > > > Thanks! This fixes my problem. > > > > Have you submitted a bug and your patch to the appropriate tracker? > > If not, would someone point me to the appropriate one? Would in be > > the GHC trac, or is there a libraries-specific one? > > The library is shipped with ghc, and the darcs repository lists > libraries@haskell.org as the maintainer, so GHC's trac seems to be the > right place. > > I've created a ticket for this now, See > http://hackage.haskell.org/trac/ghc/ticket/2227 > > Note that I opted for reimplementing the whole module instead of > just fixing the bug. /me grovels before int-e. My code went from 310s to 28s (as measured by the profiler, which represents a much longer wall time) after merely switching to your dominators implementation. Thank you for taking the time to reimplement the module. In particular, in the original dominators code the `intersection' function was the time-hog, followed by `builddoms': COST CENTRE MODULE %time %alloc intersection DPLLSat 73.6 18.5 builddoms DPLLSat 11.1 46.4 With your new module I now have the bottleneck I expected from my code, and the dominators code nowhere approaches that bottleneck. -- Denis From hferreiro at udc.es Mon Apr 21 18:12:47 2008 From: hferreiro at udc.es (Henrique Ferreiro =?ISO-8859-1?Q?Garc=EDa?=) Date: Mon Apr 21 18:07:49 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: Galois web libraries for Haskell released Message-ID: <1208815967.25538.11.camel@macbook> > * feed > Interfacing with RSS (v 0.9x, 2.x, 1.0) and Atom feeds Great! I had planned to make a feed reader using gtk2hs and this was exactly what I was waiting for. I have just seen that it is released as BSD3. Anyone knows if is there any problem in making use of it to develop a GPLv3 application? -- Henrique Ferreiro Garc?a From dons at galois.com Mon Apr 21 18:29:21 2008 From: dons at galois.com (Don Stewart) Date: Mon Apr 21 18:24:17 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: Galois web libraries for Haskell released In-Reply-To: <1208815967.25538.11.camel@macbook> References: <1208815967.25538.11.camel@macbook> Message-ID: <20080421222921.GI8601@scytale.galois.com> hferreiro: > > * feed > > Interfacing with RSS (v 0.9x, 2.x, 1.0) and Atom feeds > > Great! I had planned to make a feed reader using gtk2hs and this was > exactly what I was waiting for. > > I have just seen that it is released as BSD3. Anyone knows if is there > any problem in making use of it to develop a GPLv3 application? They're simply BSD licensed, as most Haskell libraries are, meaning you can freely mix the code with GPLd works. -- Don From ryani.spam at gmail.com Mon Apr 21 19:43:42 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Apr 21 19:38:38 2008 Subject: [Haskell-cafe] functional update In-Reply-To: <2518b95d0804211112k1eae26d2j6fa0a5befd4c772@mail.gmail.com> References: <2518b95d0804211112k1eae26d2j6fa0a5befd4c772@mail.gmail.com> Message-ID: <2f9b2d30804211643p29a8c685g92233f8a69bef03c@mail.gmail.com> I recommend this blog entry: http://twan.home.fmf.nl/blog/haskell/overloading-functional-references.details along with a few additional combinators for imperative update: data FRef s a = FRef { frGet :: s -> a , frSet :: a -> s -> s } (=:) :: MonadState s m => FRef s a -> a -> m () ref =: a = modify $ frSet ref a fetch :: MonadState s m => FRef s a -> m a fetch ref = get >>= frGet ref Then (given the right fixity declarations which I don't remember off the top of my head) you can write code like this: attack :: Int -> Game () attack dmg = do h <- fetch (player.life) player.life =: h - dmg which works, given MonadState GameState Game, player :: FRef GameState Player, and life :: FRef Player Int. Note that (.) here is not (.) from the prelude; it's from the Ref class defined on that page. -- ryan On 4/21/08, Evan Laforge wrote: > Here's some haskell to update a particular field in a data structure > (the below run in a StateT / ErrorT context): > > > set_track_width :: (UiStateMonad m) => > > Block.ViewId -> Int -> Block.Width -> m () > > set_track_width view_id tracknum width = do > > view <- get_view view_id > > track_views <- modify_at (Block.view_tracks view) tracknum $ \tview -> > > tview { Block.track_view_width = width } > > update_view view_id (view { Block.view_tracks = track_views }) > > Plus some utilities: > > > modify_at xs i f = case post of > > [] -> throw $ "can't replace index " ++ show i > > ++ " of list with length " ++ show (length xs) > > (elt:rest) -> return (pre ++ f elt : rest) > > where (pre, post) = splitAt i xs > > > update_view view_id view = modify $ \st -> st > > { state_views = Map.adjust (const view) view_id (state_views st) } > > A similar imperative update would look something like this: > > > state.get_view(view_id).tracks[tracknum].width = width > > Has there been any work on improving update syntax in haskell? > Possibly some improvement could be made with a typeclass or two and a > few custom operators, to unify some of the disparate syntax. Maybe > more improvement could be made with some TH hackery. A better record > update syntax I'm sure could improve things even more. Or maybe > there's a way to structure existing code to improve the above? > > Does anyone know of work that's been done on analysing functional > update syntax issues, and coming up with something concise and clear? > Other functional languages that do this better? It seems like an > obvious candidate for improvement. Probably not an easy one though. > There are various overlapping issues: monadic binds not mixing easily > with non-monadic functions, different data structures (maps, lists, > ...) having different update functions, record update syntax being > super wordy, and probably some other things I'm not thinking of. > > > As an aside, on the record system side, I would love to see one of the > proposed record systems implemented in GHC, whether it be trex or the > "lighter weight" version proposed by one of the Simons. Does anyone > know what the main hangup is? Unresolved issues in the proposal? No > consensus? Backward incompatibility? Not enough interested GHC devs? > All I can say is that as a heavy user of (.) I wouldn't mind > replacing them all with (#) or (@) or whatever if I got a nicer record > syntax. It wouldn't be hard to write a search/replace for (.). > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From scook0 at gmail.com Mon Apr 21 22:50:56 2008 From: scook0 at gmail.com (Stuart Cook) Date: Mon Apr 21 22:45:51 2008 Subject: [Haskell-cafe] functional update In-Reply-To: <2518b95d0804211112k1eae26d2j6fa0a5befd4c772@mail.gmail.com> References: <2518b95d0804211112k1eae26d2j6fa0a5befd4c772@mail.gmail.com> Message-ID: <49b351060804211950o788acfdeyd0c75d65ba2d16ef@mail.gmail.com> On Tue, Apr 22, 2008 at 4:12 AM, Evan Laforge wrote: > Has there been any work on improving update syntax in haskell? > Possibly some improvement could be made with a typeclass or two and a > few custom operators, to unify some of the disparate syntax. Maybe > more improvement could be made with some TH hackery. A better record > update syntax I'm sure could improve things even more. Or maybe > there's a way to structure existing code to improve the above? Here are two little TH functions I find useful: -- \f x -> x { field = f (field x) } alter :: Name -> Q Exp alter field = do f <- newName "f" x <- newName "x" lamE [varP f, varP x] $ recUpdE (varE x) [return (field, AppE (VarE f) (AppE (VarE field) (VarE x)))] -- \a x -> x { field = a } set :: Name -> Q Exp set field = do a <- newName "a" x <- newName "x" lamE [varP a, varP x] $ recUpdE (varE x) [return (field, VarE a)] They're not as flexible as FRefs (though they could be helpful in manually defining FRefs), but they still solve some of my frustrations with record update syntax. Usage: $(set 'fieldname) value record -- sets the value of the "fieldname" field to "value" $(alter 'fieldname) f record -- produces a new record where "fieldname" has been transformed by f Stuart From jonathanccast at fastmail.fm Tue Apr 22 01:58:05 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Tue Apr 22 01:53:07 2008 Subject: [Haskell-cafe] I hate Haskell's typeclasses In-Reply-To: <2f9b2d30804210050h58aac9e4xf2de56331d244ba@mail.gmail.com> References: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> <2f9b2d30804210050h58aac9e4xf2de56331d244ba@mail.gmail.com> Message-ID: <17C32BFB-7B07-418A-A56C-0FBF9D4C6A0C@fastmail.fm> On 21 Apr 2008, at 12:50 AM, Ryan Ingram wrote: > On Fri, Apr 18, 2008 at 10:01 PM, Jonathan Cast > wrote: >> {-# GHC_OPTIONS -foverlapping-instances -fundecidable-instances >> #-} :) >> What you want to work is precisely what this allows. > > Of course, I bring that point up. And overlapping instances has the > problem that it doesn't really do what you want; you always eventually > end up with this problem: > > oops :: Eq a => a -> a -> Property > oops x y = x ~= y > > Overlapping instances for EqTestable a > arising from a use of `~=' > Matching instances: > instance [overlap ok] (Eq a) => EqTestable a > instance [overlap ok] (Show a, Arbitrary a, EqTestable b) => > EqTestable (a -> b) > (The choice depends on the instantiation of `a' > To pick the first instance above, use -fallow-incoherent- > instances > when compiling the other instance declarations) > In the expression: x ~= y > In the definition of `oops': oops x y = x ~= y OK, right. But I think what this shows is that sometimes you need to name and manipulate instances (instances are designed to be anonymous and transparent, which made sense when the alternative was thought to be the anonymous and transparent overloading of traditional languages, but has started to slip as time goes on). I think the traditional solution here is newtype; I think that using type signatures to try to choose an instance, in cases like this, is an abuse of the original insight behind type classes. >> I call. Name a language that is >> >> a) Completely statically typed (no type errors at runtime), >> b) Has an ad-hoc overloading mechanism powerful enough to encode >> Num and >> Monad, and >> c) Is substantially better than Haskell + extensions for your >> examples. > > No fair! I'm on haskell-cafe for a reason: every language sucks, > Haskell just sucks less :) Amen to that. > But I can give a couple of thoughts that almost meet your criteria: > 1) Ruby. Totally misses (a) but absolutely nails (b) and (c). I must have failed to communicate well. To me, the point of giving a class a name is that then you can write a program that is parametric over the elements of that class. Knowing that I can implement monads in Ruby doesn't impress me nearly as much as knowing that I can implement mapM does. Haskell has me addicted to code reuse (mapM) the way the rest of the programming world is addicted to design patterns (monads). What I mean by `encoding Num and Monad' is that you can do something like this: sum = foldr (+) 0 sequence = foldr (liftM2 (:)) (return []) I don't know of any language that is dynamically typed and also can encode `return' or `0' in a way that lets those examples work. Statically typed languages where it works are rare, even. Haskell gives up a fair amount of control by making these things implicit, which is what I think you're running up against --- but I think it gets something useful and non-trivial to acheive in return. > 2) C++: Fine on (a) as long as you don't write stupid stuff. C++ would be a decent successor to C if it had HM typing and GC and dropped the whole silly OO business. Sum in C++ (I forget how to do higher-order templates): template foldr(Fun f, T z, Iter begin, Iter end) { if (begin < end) { return f(*begin, foldr(f, z, begin + 1, end)); } else { return z; } } template struct plus { plus() { } operator()(T t0, T t1) { return t0 + t1; } }; template sum(Iter begin, Iter end) { return foldr(plus(), T::zero, begin, end); } Not bad for a language as determined to join the 1980s as C++. > Template meta-programming involves pattern-matching on types and I > believe is > strong enough for (b). But it's really verbose; from an elegance > point of view it probably misses (c). > 3) Scala? I don't know enough about it to say for sure but what I > have seen looks promising. Scala indeed looks promising. I was secretly hoping you'd know something I didn't. But I'm still not sure it knows how to encode mapM. >> On 18 Apr 2008, at 9:29 PM, Ryan Ingram wrote: >>> 1) You can't make sensible default implementations. For example, >>> it'd >>> be nice to make all my Monads be Applicatives and Functors without >>> resorting to Template Haskell or infinite boilerplate. Why can't I >>> just write this? >>> >>> instance Monad m => Applicative m where >>> pure = return >>> (<*>) = ap >>> >>> Sure, I get that there might be ambiguity of which instance to >>> choose. >>> But why not warn me about that ambiguity, or let me choose >>> somehow on >>> a case-by-case basis when it happens? >>> >> >> You can already choose on a case-by-case basis. > > That's true, but if the authors of Applicative could, I am sure they > would have chosen to make it (and Functor) a superclass of Monad with > the proper default implementation; after all (1) Applicative is damn > useful, and (2) it's the common case. Sure. And sometimes they'd get complaints (or engender flamewars) when the default instance wasn't what someone wanted. >> More generally, specifying what you want is really not hard. Do >> you really >> have gazillions of monads in your code you have to repeat this >> implementation for? > > Yes, actually. First, I like writing monads. See > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ > MonadPrompt-1.0.0.1 > > And second, just today I had to write > instance Applicative STM where > pure = return > (<*>) = ap > > It felt like it was driving home the point. I'll agree with this point. I've complained, concretely, about the lack of instances for (some) standard types before. (STM is actually a rather bad offender here; it's lacking MonadPlus, as well, despite the specific observation in the paper that it has the right signature for that class.) >>> 2) You can't add sensible superclasses. I was playing with >>> QuickCheck >>> and wanted to write "equal with regards to testing". So I wrote >>> up a >>> class for it: >>> >>> class TestableEq a where >>> (~=) :: a -> a -> Property >>> >>> instance Eq a => TestableEq a where >>> -- should be a superclass of Eq instead! >>> a ~= b = a == b >>> >> >> Again, this is one (*) line per type. How many types do you >> declare? > > I don't declare too many myself, except on days when I'm trying to > embed system F in Haskell via GADTs, but I use a lot of them; and many > of them the authors have conveniently already made instances of useful > typeclasses. Then I try to add some new functionality and run into a > lot of friction because now every library I use needs an > implementation which matches. > > Have you ever tried to write a monad transformer that is compatible > with the MTL? O(n^2) instances is not a fun place to be, especially > when most of the definitions are just variations on "lift". Not yet. For which I am grateful. But I think this is more a problem with monad transformers than with type classes; monad transformers just do not seem to have solid mathematical underpinnings. > Disclaimer: this is actually a hard problem; I don't expect the > compiler to be able to solve it, but it's frustrating nonetheless. > The things I bring up here are easy in comparison. > >>> Sure, there is an alternative: I could manually declare instances of >>> TestableEq for EVERY SINGLE TYPE that is an instance of Eq. I am >>> sure >>> nobody here would actually suggest that I do so. > >> Bzzzt. Wrong. Thanks for playing! > > Ha ha, you got me there :) > >>> But why do I need to jump through these hoops for a perfectly safe & >>> commonly desired operation? >> >> It's called a proof obligation. > > My argument is that there shouldn't even be a proof obligation here; > the language is just not expressive enough to allow me to write the > code that I want; something that is actually completely decidable & > non-overlapping. Just remember that `choose this instance if there's no other instance available' means `no other instance on the planet' everywhere but Main. >>> 3) There's no reflection or ability to choose an implementation >>> based >>> on other constraints. >>> >>> In QuickCheck, (a -> b) is an instance of Arbitrary for >>> appropriate a, >>> b. But you can't use this instance in forAll or for testing >>> functions >>> without being an instance of Show. Now, this is probably a design >>> mistake, but it's the right choice with the current typeclass system >>> (see (2)). But it'd be a million times better to have something >>> like >>> the following: >>> >>> class Arbitrary a => MkArbitrary a where >>> mkArbitrary :: Gen (a, String) >>> >>> case instance MkArbitrary a where >>> Show a => >>> mkArbitrary = do >>> x <- arbitrary >>> return (x, show x) >>> otherwise => >>> mkArbitrary = do >>> st <- getGenState >>> x <- arbitrary >>> return (x, "evalGen arbitrary " ++ show st) >>> >> >> So we compile in a table of every instance and every datatype, add a >> Typeable constraint to forAll (since parametricity just got shot >> to heck), >> and scan through that table on every test. Millions of times >> better. And >> slower. > > It's had a lot of research; I want the best of all worlds. For a > start: > http://www.google.com/search?q=optimizing+dynamic+dispatch I'll read through the results. My complaint about parametricity stands, I think. > You could get close without going to full dynamic dispatch, though; > consider the following "core": > > -- This part is all in haskell now > data ShowDict a = ShowDict { show :: a -> String } > > show_String :: ShowDict String > show_Int :: ShowDict Int > show_List :: ShowDict a -> ShowDict [a] > > -- foo :: Show a => [a] -> String > -- foo x = show x ++ "!" > foo :: ShowDict a -> [a] -> String > foo sd x = show (show_List sd) x ++ "!" > > -- This part isn't in haskell, and the syntax sucks, but the idea > is there. > type MaybeShow a = Maybe (ShowDict a) > > -- bar :: MaybeInstance Show a => [a] -> String > -- bar xs > -- | Show a = foo xs > -- | otherwise = show (length xs) > bar :: MaybeShow a -> [a] -> String > bar (Just sd) xs = foo sd xs > bar Nothing xs = show (show_Int) (length xs) > > With this I could write > > instance (MaybeInstance Show a, Arbitrary a) => MkArbitrary a where > mkArbitrary xs > | Show a = do > x <- arbitrary > return (x, show x) > | otherwise = do > st <- getGenState > x <- arbitrary > return (x, "evalGen arbitrary " ++ show st) > > Now, every concrete type would be an instance of MaybeInstance > , and "dynamic" dispatch and (I think) closed typeclasses > would be a free benefit. When can we discharge a MaybeInstance context? >> And more likely to develop odd changes and hard-to-debug errors. > > Or so you claim :) Having the | Show a test suddenly trip from False to True because some other module imported Text.Show.Functions sounds like an odd change to me. At any rate, it scares me enough to make me oppose the idea. >> QuickCheck makes testing so easy, I think the Arbitrary (a -> b) >> instance >> is almost unnecessary; (btw., functions /are/ instances of Show). > > Now it's my turn to call: > > Prelude Test.QuickCheck> show ((\x -> x) :: Int -> Int) > :1:0: > No instance for (Show (Int -> Int)) Prelude Text.Show.Functions> show ((\x -> x) :: Int -> Int) "" > Although, I do see a useless instance in the standard prelude at > http://www.haskell.org/haskell-report/standard-prelude.html > > I actually would love to have (unsafeShow :: a -> String) which made a > "best effort" attempt (subject to the compiler's debugging level) to > evaluate an object and tell you what it contains, including source > code for functions if possible. I wonder how useful this would be in practice. >> You can easily write a showable ADT encoding the functions you >> want to test. > > That's fair (and actually pretty interesting). But definitely less > elegant than > > -- assuming Arbitrary (Behavior Int) > prop_fmap_at :: (Int -> Int) -> Property > prop_fmap_at f = fmap f . at ~= at . fmap f > > (see Conal's recent FRP paper for the formulation of this property) Point. >>> 4) Every concrete type should be an instance of Typeable without >>> having to do anything, >> >> Sure. And seq should go back to being a class method. (See >> earlier about >> parametricity being shot to heck). I have an excellent design >> which will >> preserve the language's semantics (which are fine the way they >> are, thank >> you), while being convenient for programmers, which this margin is >> too small >> to contain.[1] > > At least we agree on something. But please don't keep your design to > yourself, share! class Forceable alpha where seq :: alpha -> beta -> beta Instances derived automatically by the compiler, when possible, for every type (like Typeable should be). We can omit functions if desired (I don't remember why I thought this was a good idea). When you say f :: alpha -> beta or f :: C alpha => alpha -> beta The compiler adds implicit Forceable constraints on alpha and beta. But, if you say f :: !Forceable alpha => alpha -> beta The compiler leaves the Forceable alpha constraint off. Then you can say build :: (forall c. !Forceable c => (a -> c -> c) -> c -> c) -> [a] And the foldr/build law is still sound. >> Reflection is harder, because of the need for the lookup table >> with every >> instance of every class I mentioned earlier. (And you get to >> figure out how >> to encode polymorphic instances, too! Good luck[2]). > > See dynamic dispatch, above. Although polymorphic instances do seem > tricky. But you could probably get away with treating each typeclass > as a member of the "typerep" object for each type with some amount of > lookup; doesn't one of the existing compilers implement typeclasses in > this way already? I can't speak to the specific issue of dynamic dispatch. Most of the links I've looked at thus far seem to be about deciding when you actually /don't/ need dynamic dispatch. Haskell has that down pat, now; I haven't seen anything about making the actual function call go faster yet. Neither have I seen anything suggesting that the behavior of a function in one module cannot change because I added a multi-method in another module. That's what I'm most worried about; it sounds too much like perl's spooky action at a distance 10x over. jcc From Malcolm.Wallace at cs.york.ac.uk Tue Apr 22 07:22:37 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Apr 22 07:18:45 2008 Subject: [Haskell-cafe] GSoC accepted projects Message-ID: <20080422122237.19470715.Malcolm.Wallace@cs.york.ac.uk> Haskell.org is pleased to announce that we received 7 funded student slots from Google for this year's Summer of Code. Of the 30 proposals we received, the mentoring group chose the following 7: * GHC API Improvements by Thomas Schilling, mentored by Simon Marlow * Dynamically Loaded Plugins for the Glasgow Haskell Compiler by Maximilian Conroy Bolingbroke, mentored by Sean Seefried * Haskell API Search as an interface to Hackage by Neil Mitchell, mentored by Niklas Broberg * Language.C, a standalone parser/pretty printer library for C99 by Benedikt Huber, mentored by Iavor S. Diatchki * Cabal 'make-like' dependency framework by Andrea Vezzosi, mentored by Duncan Coutts * #1560 Efficient maps using generalised tries by Jamie Brandon, mentored by Adrian Charles Hey * Data parallel physics engine by Roman Cheplyaka, mentored by Manuel M. T. Chakravarty Slightly fuller details at http://code.google.com/soc/2008/haskell/about.html Congratulations to these students! Before coding begins officially at the end of May, there is a "community bonding period", where the students and community are encouraged to interact and further refine the work that will be done. To those students that did not get funding: do not be disheartened. Almost all of the proposals were good, and we had some difficult choices to make. What's more, since this is Open Source, you can continue to work on your projects anyway! Many of them will be useful to the community. In fact, Google have said that if any GSoC applicant manages (in the judgement of the mentors) to complete their project by the end of the summer, despite not receiving a funded place, they will send you a goodie-bag of Google swag (including a standard Google T-shirt, not the special GSoC one). Regards, Malcolm From hthiel.char at zonnet.nl Tue Apr 22 07:40:34 2008 From: hthiel.char at zonnet.nl (Hans van Thiel) Date: Tue Apr 22 07:40:28 2008 Subject: [Haskell-cafe] Hackage being too strict? In-Reply-To: <1208807940.27748.34.camel@localhost> References: <1208511804.5960.14.camel@dell.linuxdev.us.dell.com> <200804180805.12793.jgoerzen@complete.org> <20080418151911.B6895E4001@webmail219.herald.ox.ac.uk> <1208777929.3503.59.camel@localhost.localdomain> <1208807940.27748.34.camel@localhost> Message-ID: <1208864434.2770.33.camel@localhost.localdomain> [snip] > > The current a priori check, which said there were no fatal errors, while the > > a posteriori check failed, is misleading. Wouldn't it be better to warn potential > > uploaders that this first check is not complete? > > I'm not sure I see what you're getting at. We can't do a full build > check synchronously at upload time. Yes, I thought something like that would probably be the reason. What I meant is that not everybody will realize this immediately, and will think everything is OK because the message was that there are no fatal errors (even though there's another message on the page that uploaders should test their builds first...) > > > I'd also like the warning about the -O2 optimization flag to go > > away...I'd guess this is a leftover from an earlier time in GHC. > > It's not a leftover, it was added recently. The intention is that user > gets to set the optimisation level (cabal configure -O or -O2 or -O0). > It's not really great when packages override that choice. From > experience packaging haskell libraries for gentoo we found that most > packages that do set -O2 do so out of habit without any particular > justification and it significantly increases compile times and memory > use. Compile time was negligible in my case, but I didn't think about memory usage. That does not seem an issue either right now, but it's useful to know, for the future... > It's not banned though as there are some cases where it's perfectly > justified. Oh, all right. So it's recommended to leave that as a user option when configuring the installation. > > > More importantly, if Cabal is sort of an rpm for Haskell programs, shouldn't > > the uploader use version numbers of the libraries in the Cabal file? For example, > > I believe in my case at least gtk2hs 0.9.12 is needed, while Ubuntu seems to have > > only 0.9.11 (until a few months ago, at least). So, if an uploader knows such > > dependencies, how to express them? > > build-depends: gtk >= 0.9.12 && < 0.10 Thanks, that's clear now. Regards, Hans From thomas at cs.ru.nl Tue Apr 22 08:03:02 2008 From: thomas at cs.ru.nl (Thomas van Noort) Date: Tue Apr 22 07:57:55 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: Generic Haskell 1.80 (Emerald) In-Reply-To: <480D03C7.7080007@iee.org> References: <49766.82.157.212.81.1208003963.squirrel@squirrel.science.ru.nl> <480D03C7.7080007@iee.org> Message-ID: <480DD3F6.9060306@cs.ru.nl> Hello, I took the liberty to move this discussion to the Haskell-Cafe mailing list. Adrian Hey wrote: > Thomas van Noort wrote: >> Pleasant programming, > > Hello, > > This looks like good stuff. But having done all this work it seems > a pity not to go the extra mm and cabalise this and make it buildable > on all platforms (at least ghc supported platforms). You are right, cabalizing the Makefiles implies that Generic Haskell can be build on any platform that is supported by GHC. However, this requires a tremendous amount of effort since the Makefiles of Generic Haskell are enormous. > > The reason I'm interested is this may be useful for the GSoC project > I'm mentoring.. > > http://code.google.com/soc/2008/haskell/about.html > > But as things are, I'd be unlikely to consider introducing a dependency > on this. Even if it built "out of the box" with cygwin (which it > doesn't BTW) I don't really think many windows users will be keen to > install cygwin and learn how to use it just so they can build GH. As you already noticed, there is no Windows binary available for the Emerald release. However, there is one for the Coral release, available from: http://www.generic-haskell.org Although this is an old release of Generic Haskell, this release already supports generic types, which is what you need for your project probably. In the user's guide, there is a small example available which defines a generic type to represent tries. The latest release of Generic Haskell supports generic views for generic types. This allows you to define a generic type that generates efficient balanced tries, as you can read in my Master's thesis :) This requires the use of the balanced view on the type level. Unfortunately, this generic view is not implemented in the Generic Haskell compiler... > > Thanks > -- > Adrian Hey Regards, Thomas From lemming at henning-thielemann.de Tue Apr 22 08:26:17 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Apr 22 08:20:10 2008 Subject: [Haskell-cafe] functional update In-Reply-To: <2f9b2d30804211643p29a8c685g92233f8a69bef03c@mail.gmail.com> References: <2518b95d0804211112k1eae26d2j6fa0a5befd4c772@mail.gmail.com> <2f9b2d30804211643p29a8c685g92233f8a69bef03c@mail.gmail.com> Message-ID: On Mon, 21 Apr 2008, Ryan Ingram wrote: > I recommend this blog entry: > http://twan.home.fmf.nl/blog/haskell/overloading-functional-references.details > > along with a few additional combinators for imperative update: > > data FRef s a = FRef > { frGet :: s -> a > , frSet :: a -> s -> s > } http://darcs.haskell.org/record-access/src/Data/Accessor.hs http://darcs.haskell.org/record-access/src/Data/Accessor/Example.hs I should upload this to Hackage, I know ... From jno at di.uminho.pt Tue Apr 22 09:09:37 2008 From: jno at di.uminho.pt (J.N. Oliveira) Date: Tue Apr 22 09:04:21 2008 Subject: [Haskell-cafe] Anyone mind proofing a short monad transformers explanation? In-Reply-To: <2f9b2d30712171608g7bbff971lb26f5f4c705bf2d5@mail.gmail.com> References: <4767087F.1050306@gmail.com> <2f9b2d30712171608g7bbff971lb26f5f4c705bf2d5@mail.gmail.com> Message-ID: <480DE391.3020304@di.uminho.pt> Ryan Ingram wrote: > On 12/17/07, *Jack Kelly* > wrote: > > > liftIO $ hPutStrLn h "You lose" > > liftIO $ hFlush h > > IO is once again special. For other inner monads, the lift function > does the same thing. Note also that IO has no transformer and must > therefore always be the innermost monad. > > > Actually, this isn't true. In the case of ReaderT Config IO (), > liftIO is the same as lift. Where can I find proofs that the monad transformers found in the Haskell libraries indeed produce monads as results? There should be a general construction and proof (eg. based on adjoint functor compositionality) but couldn't find it yet. Looking at "Monads and Effects" (Benton et al, LNCS 2395), for instance, I don't see any foundations discussed beyond section 6. Is this somewhere else? jno (www.di.uminho.pt/~jno) From jgoerzen at complete.org Tue Apr 22 09:20:09 2008 From: jgoerzen at complete.org (John Goerzen) Date: Tue Apr 22 09:15:05 2008 Subject: [Haskell-cafe] ANNOUNCE: Galois web libraries for Haskell released In-Reply-To: <20080421181119.GB8601@scytale.galois.com> References: <20080421181119.GB8601@scytale.galois.com> Message-ID: <200804220820.10015.jgoerzen@complete.org> On Mon April 21 2008 1:11:19 pm Don Stewart wrote: > Galois, Inc. is pleased to announce the open source release of a suite of > web programming libraries for Haskell! Lots of cool stuff here! A few questions: > * xml > A simple, lightweight XML parser/generator. > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml Can you describe how this compares to HaXml? Were there deficiencies in HaXml? > * sqlite > Haskell binding to sqlite3 , a light, fast > database. > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sqlite Similar questions here regarding HDBC. Did HDBC (and HDBC-sqlite3) not address some need? > * feed > Interfacing with RSS (v 0.9x, 2.x, 1.0) and Atom feeds > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/feed Sweet. Might have to refactor hpodder to use this. > > * mime > Haskell support for working with MIME types. > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mime FWIW, I have some similar but slightly different functions in MissingH. http://software.complete.org/static/missingh/doc//MissingH/Data-MIME-Types.html hsemail and WASH both also have some stuff in this area. Probably not as nice as yours though. -- John From atomb at galois.com Tue Apr 22 11:57:55 2008 From: atomb at galois.com (Aaron Tomb) Date: Tue Apr 22 11:53:01 2008 Subject: [Haskell-cafe] ANNOUNCE: Galois web libraries for Haskell released In-Reply-To: <200804220820.10015.jgoerzen@complete.org> References: <20080421181119.GB8601@scytale.galois.com> <200804220820.10015.jgoerzen@complete.org> Message-ID: On Apr 22, 2008, at 6:20 AM, John Goerzen wrote: >> * xml >> A simple, lightweight XML parser/generator. >> >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml > > Can you describe how this compares to HaXml? Were there > deficiencies in > HaXml? The main difference is that it's simpler. It's perhaps 10-20% the size of HaXml. For a program that just has to do simple XML processing, it's sometimes undesirable to have to link in a library that does a lot more than you need. Another difference is that this package is BSD licensed, while HaXml is under the LGPL. Aaron From ryani.spam at gmail.com Tue Apr 22 12:53:57 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Apr 22 12:48:49 2008 Subject: [Haskell-cafe] I hate Haskell's typeclasses In-Reply-To: <17C32BFB-7B07-418A-A56C-0FBF9D4C6A0C@fastmail.fm> References: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> <2f9b2d30804210050h58aac9e4xf2de56331d244ba@mail.gmail.com> <17C32BFB-7B07-418A-A56C-0FBF9D4C6A0C@fastmail.fm> Message-ID: <2f9b2d30804220953w7ea55e9fj58c5d268d89e92ab@mail.gmail.com> On Mon, Apr 21, 2008 at 10:58 PM, Jonathan Cast wrote: > I must have failed to communicate well. To me, the point of giving a class > a name is that then you can write a program that is parametric over the > elements of that class. Knowing that I can implement monads in Ruby doesn't > impress me nearly as much as knowing that I can implement mapM does. > Haskell has me addicted to code reuse (mapM) the way the rest of the > programming world is addicted to design patterns (monads). What I mean by > `encoding Num and Monad' is that you can do something like this: > > sum = foldr (+) 0 > sequence = foldr (liftM2 (:)) (return []) > > I don't know of any language that is dynamically typed and also can encode > `return' or `0' in a way that lets those examples work. Statically typed > languages where it works are rare, even. Haskell gives up a fair amount of > control by making these things implicit, which is what I think you're > running up against --- but I think it gets something useful and non-trivial > to acheive in return. I think ruby generally solves this problem via duck-typing; instead of the cast happening in the (implicit) fromInteger call in sum above, instead the cast happens in the function with more information via a call to otherclass#to_whatever_i_am. You can do something like this: class Frob attr_reader :val def initialize(i) @val = i end def to_frob self end def +(rhs) rhsF = rhs.to_frob Frob.new(rhsF.val + @val) end end class Integer def to_frob Frob.new(self) end end class Array def sum foldl(0) {|acc,x| acc + x} end def foldl(z) each {|x| z = yield(z,x)} z end end irb(main):055:0> [1,2,3].sum => 6 irb(main):057:0> [1,2,3].map {|x| Frob.new(x)}.sum => # > I'll agree with this point. I've complained, concretely, about the lack of > instances for (some) standard types before. (STM is actually a rather bad > offender here; it's lacking MonadPlus, as well, despite the specific > observation in the paper that it has the right signature for that class.) Actually: GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m Control.Monad Control.Monad.STM Prelude Control.Monad.STM Control.Monad> :i STM ... instance MonadPlus STM -- Defined in Control.Monad.STM > When can we discharge a MaybeInstance context? On any concrete type. Like Typeable should be :) The compiler then determines whether that type is an instance of the class and provides the appropriate dictionary if applicable. > Having the | Show a test suddenly trip from False to True because some > other module imported Text.Show.Functions sounds like an odd change to me. > At any rate, it scares me enough to make me oppose the idea. I see the worry now. I think this is more of a problem with orphan instances; are orphan instances considered to be a valuable enough feature to avoid potentially more powerful constructs? Maybe there is a better solution to the "I have class C from library X and type T from library Y and I want to make them play nice together" problem than orphan instances. > class Forceable alpha where > seq :: alpha -> beta -> beta > > Instances derived automatically by the compiler, when possible, for every > type (like Typeable should be). We can omit functions if desired (I don't > remember why I thought this was a good idea). When you say > > f :: alpha -> beta > > or > > f :: C alpha => alpha -> beta > > The compiler adds implicit Forceable constraints on alpha and beta. But, > if you say > > f :: !Forceable alpha => alpha -> beta > > The compiler leaves the Forceable alpha constraint off. Then you can say > > build :: (forall c. !Forceable c => (a -> c -> c) -> c -> c) -> [a] > > And the foldr/build law is still sound. This seems like a really interesting idea. -- ryan From dons at galois.com Tue Apr 22 13:20:34 2008 From: dons at galois.com (Don Stewart) Date: Tue Apr 22 13:15:50 2008 Subject: [Haskell-cafe] ANNOUNCE: Galois web libraries for Haskell released In-Reply-To: <200804220820.10015.jgoerzen@complete.org> References: <20080421181119.GB8601@scytale.galois.com> <200804220820.10015.jgoerzen@complete.org> Message-ID: <20080422172034.GA27147@scytale.galois.com> jgoerzen: > On Mon April 21 2008 1:11:19 pm Don Stewart wrote: > > Galois, Inc. is pleased to announce the open source release of a suite of > > web programming libraries for Haskell! > > Lots of cool stuff here! A few questions: > > > * xml > > A simple, lightweight XML parser/generator. > > > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml > > Can you describe how this compares to HaXml? Were there deficiencies in > HaXml? Much smaller, fewer dependencies. I think of it as the "tagsoup" of xml parsers. > > * sqlite > > Haskell binding to sqlite3 , a light, fast > > database. > > > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sqlite > > Similar questions here regarding HDBC. Did HDBC (and HDBC-sqlite3) not > address some need? Yes, we needed full, low-level access to sqlite for some unusual use cases. For high level stuff, HDBC and Takusen are nicer. > > * feed > > Interfacing with RSS (v 0.9x, 2.x, 1.0) and Atom feeds > > > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/feed > > Sweet. Might have to refactor hpodder to use this. > > > > > * mime > > Haskell support for working with MIME types. > > > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mime > > FWIW, I have some similar but slightly different functions in MissingH. > > http://software.complete.org/static/missingh/doc//MissingH/Data-MIME-Types.html > > hsemail and WASH both also have some stuff in this area. Probably not as > nice as yours though. We should probably bundle up a bunch of the small mime libs into a single package at some point. -- Don From midfield at gmail.com Tue Apr 22 13:32:12 2008 From: midfield at gmail.com (Ben) Date: Tue Apr 22 13:27:08 2008 Subject: [Haskell-cafe] mapM vs mapM_ performance Message-ID: <9157df230804221032q3a19bf15u7f1f6d522511d935@mail.gmail.com> Hello Haskellers, I'm running ghc 6.8.2 on vista 64. Consider the following program, which is compiled with -02 -prof -auto-all: module Main where import System.IO (openFile, IOMode(..), hPutStr) testlst = let ls = [(i, [(j, (fromIntegral j)::Float) | j <- [1..5]::[Int]]) | i <- [1..500000]::[Int]] in ls main2 = do h <- openFile "bardump" WriteMode mapM_ ((hPutStr h) . show) testlst main = do h <- openFile "bardump2" WriteMode mapM ((hPutStr h) . show) testlst return () main and main2 are different in only that mapM_ versus mapM_ are used. But the mapM version runs about 20x slower! I'm running with +RTS -p -hc -RTS and I see that the amount of memory allocated is about the same, and I think the resident memory is about the same too. But the mapM_ version runs in about 8.7 seconds, and the mapM version takes 167 seconds. You may ask, why use mapM if you're discarding the values? Unfortunately in my real app I need the values, which are more interesting than IO (). ? Take care, Ben From jgoerzen at complete.org Tue Apr 22 13:32:50 2008 From: jgoerzen at complete.org (John Goerzen) Date: Tue Apr 22 13:27:45 2008 Subject: [Haskell-cafe] ANNOUNCE: Galois web libraries for Haskell released In-Reply-To: <20080422172034.GA27147@scytale.galois.com> References: <20080421181119.GB8601@scytale.galois.com> <200804220820.10015.jgoerzen@complete.org> <20080422172034.GA27147@scytale.galois.com> Message-ID: <200804221232.51444.jgoerzen@complete.org> On Tue April 22 2008 12:20:34 pm Don Stewart wrote: > Yes, we needed full, low-level access to sqlite for some unusual use > cases. For high level stuff, HDBC and Takusen are nicer. Can you elaborate on these use cases? I would like to either add support for them to HDBC-sqlite3, or perhaps make HDBC-sqlite3 a wrapper around your library. -- John From dons at galois.com Tue Apr 22 13:35:10 2008 From: dons at galois.com (Don Stewart) Date: Tue Apr 22 13:30:23 2008 Subject: [Haskell-cafe] ANNOUNCE: Galois web libraries for Haskell released In-Reply-To: <200804221232.51444.jgoerzen@complete.org> References: <20080421181119.GB8601@scytale.galois.com> <200804220820.10015.jgoerzen@complete.org> <20080422172034.GA27147@scytale.galois.com> <200804221232.51444.jgoerzen@complete.org> Message-ID: <20080422173510.GC27147@scytale.galois.com> jgoerzen: > On Tue April 22 2008 12:20:34 pm Don Stewart wrote: > > > Yes, we needed full, low-level access to sqlite for some unusual use > > cases. For high level stuff, HDBC and Takusen are nicer. > > Can you elaborate on these use cases? I would like to either add support for > them to HDBC-sqlite3, or perhaps make HDBC-sqlite3 a wrapper around your > library. Strange hardware. So we needed to be able to monkey around somewhat. It might make sense to wrap our sqlite3 binding with HDBC-sqlite3 though, so you don't need to maintain your own sqlite binding. -- Don From usenet at mkarcher.dialup.fu-berlin.de Tue Apr 22 13:28:27 2008 From: usenet at mkarcher.dialup.fu-berlin.de (Michael Karcher) Date: Tue Apr 22 13:34:54 2008 Subject: [Haskell-cafe] Re: Some clarity please! References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> <47D8F442.40704@iee.org> <87iqzqubo1.fsf@nmd9999.imr.no> Message-ID: In gmane.comp.lang.haskell.prime Aaron Denney wrote: > > Prelude> :i Ord > > class (Eq a) => Ord a where > > compare :: a -> a -> Ordering > > (<) :: a -> a -> Bool > > (>=) :: a -> a -> Bool > > (>) :: a -> a -> Bool > > (<=) :: a -> a -> Bool > > max :: a -> a -> a > > min :: a -> a -> a > > > > ..while all functions could be easily derived from 'compare'. Or from > > the Eq instance's (==) and (<), say. > > > > What is the reason for this? Efficiency? (Which couldn't be handled > > equally well by RULES?) Otherwise, it looks like an invitation for > > writing inconsistent instances. > > My impression (which may not be entirely accurate) is not primarily for > efficiency (though that is one reason), but for ease of implementation. [...] > max and min seem to have neither justification going for them, although > I suppose it's technically possible to write compare in terms of them > and (==). I am quite late to join this thread, but as I just read the thread about Conal's AddBounds where he had a very valid point for implementing min/max without resorting to <= or compare: min [] ys = [] min xs [] = [] min (x:xs) (y:ys) | cmp == LT = (x:xs) | cmp == GT = (y:ys) | cmp == EQ = x:min xs ys where cmp = compare x y This is a properly lazy implementation for min (the one in GHC's prelude is not), as it is able to calculate (take 5 $ min [1,2..] [1,2..]). This is not possible if min has to wait for compare or <= to compare the full lists before returning the head. Regards, Michael Karcher From s.clover at gmail.com Tue Apr 22 14:05:52 2008 From: s.clover at gmail.com (Sterling Clover) Date: Tue Apr 22 14:00:58 2008 Subject: [Haskell] Re: [Haskell-cafe] ANNOUNCE: Galois web libraries for Haskell released In-Reply-To: <200804220820.10015.jgoerzen@complete.org> References: <20080421181119.GB8601@scytale.galois.com> <200804220820.10015.jgoerzen@complete.org> Message-ID: > > * feed > > Interfacing with RSS (v 0.9x, 2.x, 1.0) and Atom feeds > > > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/feed > Curious how well this handles malformed feeds -- i.e. is it strict in its parsing, or casual and tagsoup-like? Thanks, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080422/00393500/attachment.htm From rodrigo.bonifacio at uol.com.br Tue Apr 22 14:07:49 2008 From: rodrigo.bonifacio at uol.com.br (rodrigo.bonifacio) Date: Tue Apr 22 14:02:54 2008 Subject: [Haskell-cafe] Processing XML with HXT Message-ID: Hi all, I?m just starting with HXT. My question is, how can I expose a "use case" from the main function below (the XmlPickler for UseCase has been already defined): main :: IO () main = do runX ( xunpickleDocument xpUseCase [ (a_validate,v_0) ], "uc.xml" ) return () For example, if I just want to show the use case contents, how can I call "show" for a retrived use case. Thanks in advance. Rodrigo. From ben.franksen at online.de Tue Apr 22 14:18:32 2008 From: ben.franksen at online.de (Ben Franksen) Date: Tue Apr 22 14:19:13 2008 Subject: [Haskell-cafe] Re: Re: semi-closed handles References: <3c4d5adf0804140507k1bb786dehc6220f66af2f94ba@mail.gmail.com> <22fcbd520804141028n495e4ef6vab0219d0cbb70ace@mail.gmail.com> <3c4d5adf0804142309mc4fb184t1e957c8fe0e29d7c@mail.gmail.com> <2f9b2d30804150037u552caeat94ba3ab7ed30b033@mail.gmail.com> <2f9b2d30804151319v39342879h61cd6f2ce16fbb40@mail.gmail.com> Message-ID: Ryan Ingram wrote: > On 4/15/08, ChrisK wrote: >> A small idiomatic nitpick: When I see (length s) gets computed and >> thrown >> away I wince at the wasted effort. I would prefer (finiteSpine s): > > On every piece of hardware I've seen, the actual calculation done by > "length" is basically free. Compared to the cache misses you'll get > from traversing the list, or especially the disk access from reading > the file, it's vanishingly small. > > It's also directly from the prelude and it's usually pretty clear to a > newbie what it's doing, as compared to "foldr (const id) () s" which > is on the path to "functional languages make no sense" land. I > consider myself moderately experienced, and assuming that it > typechecks I know what it has to mean, but I can't just look at it and > know what it does like I can with "length". > > If there was a standard "seqList" or "deepSeq", I'd use that instead. I am almost sure that there is something in Control.Parallel.Strategies that you can use (but too lazy to look it up now...) Cheers Ben From vigalchin at gmail.com Tue Apr 22 15:23:53 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Tue Apr 22 15:18:44 2008 Subject: [Haskell-cafe] Storable class? Message-ID: <5ae4f2ba0804221223q127d927dl2650aaf71367936f@mail.gmail.com> Hello, Examples of instances of the Storable class please. Thank you, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080422/e1417f5f/attachment.htm From qdunkan at gmail.com Tue Apr 22 16:29:26 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Tue Apr 22 16:24:48 2008 Subject: [Haskell-cafe] Storable class? In-Reply-To: <5ae4f2ba0804221223q127d927dl2650aaf71367936f@mail.gmail.com> References: <5ae4f2ba0804221223q127d927dl2650aaf71367936f@mail.gmail.com> Message-ID: <2518b95d0804221329m3e980543hb79f845b53f15340@mail.gmail.com> This uses hsc2hs. As far as I can tell, alignment is unused. I've never had an error from using 'undefined' there. > #include "c_interface.h" > > instance Storable Color where > sizeOf _ = #size Color > alignment _ = undefined > peek = peek_color > poke = poke_color > > peek_color colorp = do > r <- (#peek Color, r) colorp :: IO CUChar > g <- (#peek Color, g) colorp :: IO CUChar > b <- (#peek Color, b) colorp :: IO CUChar > a <- (#peek Color, a) colorp :: IO CUChar > return $ Color (d r) (d g) (d b) (d a) > where d uchar = fromIntegral uchar / 255.0 > > poke_color colorp (Color r g b a) = do > (#poke Color, r) colorp (c r) > (#poke Color, g) colorp (c g) > (#poke Color, b) colorp (c b) > (#poke Color, a) colorp (c a) > where c double = Util.c_uchar (floor (double*255)) From gour at mail.inet.hr Tue Apr 22 16:30:26 2008 From: gour at mail.inet.hr (Gour) Date: Tue Apr 22 16:25:37 2008 Subject: [Haskell-cafe] Re: ANNOUNCE: Galois web libraries for Haskell released References: <20080421181119.GB8601@scytale.galois.com> <200804220820.10015.jgoerzen@complete.org> <20080422172034.GA27147@scytale.galois.com> <200804221232.51444.jgoerzen@complete.org> <20080422173510.GC27147@scytale.galois.com> Message-ID: <87fxtd4opp.fsf@gaura-nitai.no-ip.org> >>>>> "Don" == Don Stewart writes: Don> It might make sense to wrap our sqlite3 binding with HDBC-sqlite3 Don> though, so you don't need to maintain your own sqlite binding. How about support for user-defined functions in sqlite3? Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080422/ebf5da9c/attachment.bin From sebastian.sylvan at gmail.com Tue Apr 22 17:04:33 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Tue Apr 22 16:59:51 2008 Subject: [Haskell-cafe] Storable class? In-Reply-To: <2518b95d0804221329m3e980543hb79f845b53f15340@mail.gmail.com> References: <5ae4f2ba0804221223q127d927dl2650aaf71367936f@mail.gmail.com> <2518b95d0804221329m3e980543hb79f845b53f15340@mail.gmail.com> Message-ID: <3d96ac180804221404r4b8a4501i103f8a74a10ada86@mail.gmail.com> On Tue, Apr 22, 2008 at 9:29 PM, Evan Laforge wrote: > This uses hsc2hs. As far as I can tell, alignment is unused. I've > never had an error from using 'undefined' there. Some architectures require all sorts of wacky alignments. E.g. floats may need to be 4 byte aligned, so it's very important that you don't poke a single byte, and then a float, you need to pad with 3 empty bytes first (assuming the whole structure starts at a 4 byte alignment). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080422/4fbd414b/attachment.htm From andrewcoppin at btinternet.com Tue Apr 22 17:22:06 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Tue Apr 22 17:16:41 2008 Subject: [Haskell-cafe] ANNOUNCE: Galois web libraries for Haskell released In-Reply-To: <20080421181119.GB8601@scytale.galois.com> References: <20080421181119.GB8601@scytale.galois.com> Message-ID: <480E56FE.1010302@btinternet.com> Don Stewart wrote: > * utf8-string > A UTF8 layer for IO and Strings. The utf8-string > package provides operations for encoding UTF8 > strings to Word8 lists and back, and for reading and > writing UTF8 without truncation. > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utf8-string > When I read this, my first thought was "but does it support ByteStrings?" Apparently that's a "yes"... yay! > About: > > Galois researches, designs and develops high > assurance technologies for security-critical systems, networks and > applications. We use Haskell as a primary development tool for producing > robust components for a diverse range of clients. > You know, this has been puzzling me for ages. Everybody round here seems to "know" who or what Galois is, except me. So now I know! > Web-based technologies are increasingly important in this area, and we > believe Haskell has a key role to play in the production of reliable, > secure web software. The culture of correctness Haskell encourages is > ideally suited to web programming, where issues of security, > authentication, privacy and protection of resources abound. In > particular, Haskell's type system makes possible strong static > guarantees about access to resources, critical to building reliable web > applications. We hope that the release of this suite of libraries to the > community will push further the adoption of Haskell in the domain of web > programming. Well, all of that is true of course... but given that most people percieve I/O as being "hard" in Haskell, it seems like an interesting target. But hey, here's to success! From qdunkan at gmail.com Tue Apr 22 17:48:30 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Tue Apr 22 17:43:22 2008 Subject: [Haskell-cafe] Storable class? In-Reply-To: <3d96ac180804221404r4b8a4501i103f8a74a10ada86@mail.gmail.com> References: <5ae4f2ba0804221223q127d927dl2650aaf71367936f@mail.gmail.com> <2518b95d0804221329m3e980543hb79f845b53f15340@mail.gmail.com> <3d96ac180804221404r4b8a4501i103f8a74a10ada86@mail.gmail.com> Message-ID: <2518b95d0804221448g38653cd7r484146042d932f72@mail.gmail.com> > On Tue, Apr 22, 2008 at 9:29 PM, Evan Laforge wrote: > > This uses hsc2hs. As far as I can tell, alignment is unused. I've > > never had an error from using 'undefined' there. > > Some architectures require all sorts of wacky alignments. E.g. floats may > need to be 4 byte aligned, so it's very important that you don't poke a > single byte, and then a float, you need to pad with 3 empty bytes first > (assuming the whole structure starts at a 4 byte alignment). Does that mean that if ghc is on a sufficiently wacky architecture it will evaluate "alignment" and throw undefined? And if that's the case it would seem that you can't write "alignment" without introducing platform dependencies. I've also heard that even on x86, if you don't have things aligned properly, structure access will be slow. But I'd assume since I'm poking into a C structure, either the C compiler will have taken care of alignment or its definition in C will have to include some manual padding, and so the haskell side doesn't have to worry about it at all. The FFI doc doesn't really talk about the alignment method at all, so I don't really understand how to write one or how it's used. From ryani.spam at gmail.com Tue Apr 22 17:48:54 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Apr 22 17:43:49 2008 Subject: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it wrong? Message-ID: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> How can I implement the following operation efficiently in STM? Given a TVar "now", waitFor t0 = do t <- readTVar now if (t < t0) then retry else return () This naive implementation has the problem that the transaction gets restarted every time "now" gets updated, even if the new value is still less than t0. One primitive that would be strong enough is this: retryUntil :: TVar a -> (a -> Bool) -> STM () although it would still do some computation every time "now" changed. The thought I originally had was to register the "waitFor" time with some helper which kept track of the current time and fired off a notice when it was ready. But the problem with that is that "retry" undoes all the work of setting that up; the goal is still to block, but I want a stronger blocking primitive. Does anyone have any ideas? -- ryan Here's the background: I'm following along with Conal's excellent FRP paper at http://conal.net/papers/simply-reactive/ In his implementation of futures, Conal uses a race primitive which spawns two threads each computing a value that (if successful) is guaranteed to agree. I was (and still am) sure that an implementation using STM could avoid needing to race, with careful use of orElse & retry. Here's the datatype I'm using for Future: > -- semantic type for future > -- t = type of Time, an instance of Bounded. a = value type > type F t a = (t, a) > force :: Future t a -> F t a > data Future t a = Fut > { waitFor :: t -> STM () > , value :: STM (t, a) > } > firstFuture :: Future t a -> Future t a -> Future t a > -- with semantics: > -- force (firstFuture f1 f2) = (min t1 t2, if t1 <= t2 then v1 else v2) > -- where > -- (t1, v1) = force f1 > -- (t2, v2) = force f2 Each future lives in some universe; imagine you have the following: ] type Universe t -- abstract ] P :: Bounded t => Universe t -- universe of pure values ] R :: Universe Time -- universe of the real world ] univ :: Future t a -> Universe t ] now :: Universe t -> STM t ] -- now P = return maxBound ] -- now R = current time The main thrust of this is that each universe has its own idea of what time it is; but when combining futures, we get a new universe which tracks the later of the times in the two universes. The problem is combining two futures: Lets say we have: anyKey :: Future Time () -- fires when the user first presses a key thousand :: Num t => Future t () -- fires at tick 1000 thousand = exactly 1000 () and we are evaluating force (firstFuture anyKey thousand) Now, "clock" is going to fire at tick 1000; we know this because it lives in the pure universe and its value is always available. So firstFuture can get the following: x1 <- maybeSTM (value anyKey) -- x1 = Nothing x2 <- maybeSTM (value clock) -- x2 = Just (1000, ()) ... -- synchronize P with R at tick 1000 waitFor anyKey 1000 -- if nothing has changed before tick 1000 return (1000, ()) -- converts a possibly-retry-calling STM into one that never fails maybeSTM m = fmap Just m `orElse` return Nothing So if we use the naive implementation for "waitFor" in terms of "now", the whole transaction will get re-evaluated every tick. I only want it to get re-evaluated if the user presses a key (changing some TVar evaluated in "value anyKey"), or tick 1000 passes, whichever comes first. Is there a way to do this? Is my choice of "waitFor" as the basic "universe synchronization" operation too weak? From sebastian.sylvan at gmail.com Tue Apr 22 17:55:51 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Tue Apr 22 17:50:43 2008 Subject: [Haskell-cafe] Storable class? In-Reply-To: <2518b95d0804221448g38653cd7r484146042d932f72@mail.gmail.com> References: <5ae4f2ba0804221223q127d927dl2650aaf71367936f@mail.gmail.com> <2518b95d0804221329m3e980543hb79f845b53f15340@mail.gmail.com> <3d96ac180804221404r4b8a4501i103f8a74a10ada86@mail.gmail.com> <2518b95d0804221448g38653cd7r484146042d932f72@mail.gmail.com> Message-ID: <3d96ac180804221455u7d92a9d3gc1c644ef7556548e@mail.gmail.com> On Tue, Apr 22, 2008 at 10:48 PM, Evan Laforge wrote: > > On Tue, Apr 22, 2008 at 9:29 PM, Evan Laforge wrote: > > > This uses hsc2hs. As far as I can tell, alignment is unused. I've > > > never had an error from using 'undefined' there. > > > > Some architectures require all sorts of wacky alignments. E.g. floats > may > > need to be 4 byte aligned, so it's very important that you don't poke a > > single byte, and then a float, you need to pad with 3 empty bytes first > > (assuming the whole structure starts at a 4 byte alignment). > > Does that mean that if ghc is on a sufficiently wacky architecture it > will evaluate "alignment" and throw undefined? And if that's the case > it would seem that you can't write "alignment" without introducing > platform dependencies. > > I've also heard that even on x86, if you don't have things aligned > properly, structure access will be slow. But I'd assume since I'm > poking into a C structure, either the C compiler will have taken care > of alignment or its definition in C will have to include some manual > padding, and so the haskell side doesn't have to worry about it at > all. > > The FFI doc doesn't really talk about the alignment method at all, so > I don't really understand how to write one or how it's used. > Well I know that on the Xbox 360 (PowerPC with some extensions basically) alignment problems will sometimes cause slowness, and sometimes a crash depending on the data type. I can't remember which ones are which though, and usually the compiler takes care of it, but in cases such as this when you're manually poking bytes into a buffer, you do need to be very careful and make sure that anything actually using these values will either have the data in the correct alignment right away, or will copy it into an aligned variable before doing anything with it. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080422/27aabbb0/attachment.htm From bulat.ziganshin at gmail.com Tue Apr 22 18:05:10 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Apr 22 18:02:51 2008 Subject: [Haskell-cafe] Storable class? In-Reply-To: <2518b95d0804221448g38653cd7r484146042d932f72@mail.gmail.com> References: <5ae4f2ba0804221223q127d927dl2650aaf71367936f@mail.gmail.com> <2518b95d0804221329m3e980543hb79f845b53f15340@mail.gmail.com> <3d96ac180804221404r4b8a4501i103f8a74a10ada86@mail.gmail.com> <2518b95d0804221448g38653cd7r484146042d932f72@mail.gmail.com> Message-ID: <901664244.20080423020510@gmail.com> Hello Evan, Wednesday, April 23, 2008, 1:48:30 AM, you wrote: > The FFI doc doesn't really talk about the alignment method at all, so > I don't really understand how to write one or how it's used. write: easy. just specify how much data shoulkd be aligned. for primitive datatypes this usually equals to datasize, for complex structures this should be the same as maximum alignment of elements involved: instance Storable Float alignment = 4 instance Storable (a,b) alignment = maximum [alignment a, alignment b] use: just align memory blocks allocated to store this datatype. usual alignment technique is: alloc a = (allocBytes (sizeOf a + alignment a - 1) + (alignment a - 1)) .&. (alignment a - 1) well, many standard allocators such as C malloc, actually provide you blocks with a maximum alignment required to store any (primitive) type, so you don't need to worry about it -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From haskell at brecknell.org Tue Apr 22 18:47:31 2008 From: haskell at brecknell.org (Matthew Brecknell) Date: Tue Apr 22 18:42:21 2008 Subject: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> Message-ID: <1208904451.25464.1249335847@webmail.messagingengine.com> Ryan Ingram said: > How can I implement the following operation efficiently in STM? Given > a TVar "now", > > waitFor t0 = do > t <- readTVar now > if (t < t0) then retry else return () > > This naive implementation has the problem that the transaction gets > restarted every time "now" gets updated, even if the new value is > still less than t0. I'm not familiar with FRP, so this may be off the mark. Are you familiar with Control.Concurrent.STM.TVar.registerDelay? I realise your concept of time differs from that of registerDelay, but I suspect you'll need to use a similar approach. > One primitive that would be strong enough is this: > retryUntil :: TVar a -> (a -> Bool) -> STM () > > although it would still do some computation every time "now" changed. I don't think a primitive retryUntil would be able to do any better than the obvious implementation (which looks a lot like your waitFor). > The thought I originally had was to register the "waitFor" time with > some helper which kept track of the current time and fired off a > notice when it was ready. But the problem with that is that "retry" > undoes all the work of setting that up; the goal is still to block, > but I want a stronger blocking primitive. That's essentially what registerDelay does. The key is that registering a timer must occur in the IO monad, outside the transaction that waits for it. I vaguely recall that there is at least one hackage library which is somewhat more sophisticated than registerDelay, so you might also want to look there. From cdsmith at twu.net Tue Apr 22 20:48:17 2008 From: cdsmith at twu.net (Chris Smith) Date: Tue Apr 22 20:43:17 2008 Subject: [Haskell-cafe] Re: Stronger STM primitives needed? Or am I just doing it wrong? References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> Message-ID: On Tue, 22 Apr 2008 14:48:54 -0700, Ryan Ingram wrote: > waitFor t0 = do > t <- readTVar now > if (t < t0) then retry else return () > > This naive implementation has the problem that the transaction gets > restarted every time "now" gets updated, even if the new value is still > less than t0. > > One primitive that would be strong enough is this: retryUntil :: TVar a > -> (a -> Bool) -> STM () Hmm. This makes me suspicious. A change to a variable may change the transaction such that it never even calls your retryUntil the next time around. Is it really safe to not retry the transaction? -- Chris Smith From ryani.spam at gmail.com Tue Apr 22 21:14:25 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Apr 22 21:09:17 2008 Subject: [Haskell-cafe] Re: Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> Message-ID: <2f9b2d30804221814g54ca3bfchd0811e45e67f8511@mail.gmail.com> On 4/22/08, Chris Smith wrote: > > One primitive that would be strong enough is this: retryUntil :: TVar a > > -> (a -> Bool) -> STM () > > Hmm. This makes me suspicious. A change to a variable may change the > transaction such that it never even calls your retryUntil the next time > around. Is it really safe to not retry the transaction? Of course not; the semantics would be that the transaction log, instead of saying "I read from v" would say "I read from v and failed because v didn't satisfy this predicate". Changes to any other variable in the log would have the same effect as always: restarting the transaction. This is actually required in my desired use case; I want to block until "now" becomes >= t, or a different TVar gets filled with a non-Nothing value. -- ryan From haskell at brecknell.org Tue Apr 22 21:46:48 2008 From: haskell at brecknell.org (Matthew Brecknell) Date: Tue Apr 22 21:41:37 2008 Subject: [Haskell-cafe] Re: Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <2f9b2d30804221814g54ca3bfchd0811e45e67f8511@mail.gmail.com> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804221814g54ca3bfchd0811e45e67f8511@mail.gmail.com> Message-ID: <1208915208.21995.1249362141@webmail.messagingengine.com> Ryan Ingram said: > > retryUntil :: TVar a -> (a -> Bool) -> STM () > > [...] > > the semantics would be that the transaction log, > instead of saying "I read from v" would say "I read from v and failed > because v didn't satisfy this predicate". > > Changes to any other variable in the log would have the same effect as > always: restarting the transaction. This is actually required in my > desired use case; I want to block until "now" becomes >= t, or a > different TVar gets filled with a non-Nothing value. I see now what you mean, and I can see that it might be a nice little addition. By giving the STM runtime additional information about what conditions would allow the transaction to progress, it might be able to save some false retries. Note that the only work that is saved is the work done to get to the retryUntil. However, strictly speaking, the STM runtime doesn't need this additional information. You could view a composite STM transaction as an inverted tree, with individual reads at the leaves, merging through monadic bindings towards the root, which is the final result (which includes the transaction's atomic updates). A transaction waiting on a retry is just one of these trees in suspended animation, waiting for a new value to be written to one of the leaves. When such a value is written to one of the leaves, only its downstream nodes need re-evaluation. Implementing STM that way may not be worth the effort, though, whereas retryUntil might be. From trebla at vex.net Tue Apr 22 22:31:25 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Tue Apr 22 22:26:17 2008 Subject: [Haskell-cafe] Processing XML with HXT In-Reply-To: References: Message-ID: <480E9F7D.7060105@vex.net> rodrigo.bonifacio wrote: > I?m just starting with HXT. My question is, how can I expose a "use case" from the main function below (the XmlPickler for UseCase has been already defined): > > main :: IO () > main = do > runX ( xunpickleDocument xpUseCase [ (a_validate,v_0) ], "uc.xml" ) > return () > > For example, if I just want to show the use case contents, how can I call "show" for a retrived use case. y <- runX (xunpickleDocument xpUseCase [ (a_validate,v_0) ] "uc.xml") print y Remark: y :: [UseCase] From derek.a.elkins at gmail.com Tue Apr 22 23:03:47 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Apr 22 22:58:43 2008 Subject: [Haskell-cafe] I hate Haskell's typeclasses In-Reply-To: <17C32BFB-7B07-418A-A56C-0FBF9D4C6A0C@fastmail.fm> References: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> <2f9b2d30804210050h58aac9e4xf2de56331d244ba@mail.gmail.com> <17C32BFB-7B07-418A-A56C-0FBF9D4C6A0C@fastmail.fm> Message-ID: <1208919827.5538.16.camel@derek-laptop> On Mon, 2008-04-21 at 22:58 -0700, Jonathan Cast wrote: > class Forceable alpha where > seq :: alpha -> beta -> beta > > Instances derived automatically by the compiler, when possible, for > every type (like Typeable should be). We can omit functions if > desired (I don't remember why I thought this was a good idea). When > you say > > f :: alpha -> beta > > or > > f :: C alpha => alpha -> beta > > The compiler adds implicit Forceable constraints on alpha and beta. > But, if you say > > f :: !Forceable alpha => alpha -> beta > > The compiler leaves the Forceable alpha constraint off. Then you can > say > > build :: (forall c. !Forceable c => (a -> c -> c) -> c -> c) -> [a] > > And the foldr/build law is still sound. Why do you want types that lie, plus some crazy ad-hoc special case? Why not just let f :: a -> b mean what you write as f :: !Forceable a => a -> b exactly as it would if seq were moved (back) into a class? Then the free theorems would hold for the types as stated. From vigalchin at gmail.com Tue Apr 22 23:26:37 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Tue Apr 22 23:21:28 2008 Subject: [Haskell-cafe] Storable class? In-Reply-To: <901664244.20080423020510@gmail.com> References: <5ae4f2ba0804221223q127d927dl2650aaf71367936f@mail.gmail.com> <2518b95d0804221329m3e980543hb79f845b53f15340@mail.gmail.com> <3d96ac180804221404r4b8a4501i103f8a74a10ada86@mail.gmail.com> <2518b95d0804221448g38653cd7r484146042d932f72@mail.gmail.com> <901664244.20080423020510@gmail.com> Message-ID: <5ae4f2ba0804222026h19c9d7d7wd2240a6e745f63e3@mail.gmail.com> Hello, Below is a snippet of my code .... please look for the "poke" call with "<<<<<<<<<<<<<". This causes a "hang" when I run a test case. If I comment out the "poke" call then test case runs. Vasili -- |Correspond to some of the int flags from C's fcntl.h. data MQFlags = MQFlags { append1 :: Bool, -- ^ O_APPEND exclusive1 :: Bool, -- ^ O_EXCL noctty1 :: Bool, -- ^ O_NOCTTY nonBlock1 :: Bool, -- ^ O_NONBLOCK trunc1 :: Bool -- ^ O_TRUNC } -- |Default values for the 'MQFlags' type. False for each of -- append, exclusive, noctty, nonBlock, and trunc. -- TBD WNH MQdefaultFileFlags :: MQFlags defaultMQFlags = MQFlags { append1 = False, exclusive1 = False, noctty1 = False, nonBlock1 = False, trunc1 = False } data MQAttributes = MQAttributes { flags :: MQFlags, maxMsgNum :: Int, maxMsgSize :: Int, curNumMsgs :: Int } instance Storable MQAttributes where sizeOf (MQAttributes flags maxMsgNum maxMsgSize curNumMsgs) = 4 instance Storable MQFlags where sizeOf (MQFlags append1 exclusive1 noctty1 nonBlock1 trunc1) = 1 -- |Open and optionally create this message queue. See 'System.Posix.Files' -- for information on how to use the 'FileMode' type. mqOpen :: String -> MQOpenMode -> Maybe FileMode -- ^Just x => creates the file with the given modes, Nothing => the file must exist. -> MQFlags -> MQAttributes -> IO Fd mqOpen name how maybe_mode (MQFlags append1 exclusive1 noctty1 nonBlock1 truncate1) (MQAttributes flags maxMsgNum maxMsgSize curNumMsgs) = do withCString name $ \ p_name -> do putStrLn ("name -> " ++ name) allocaBytes (#const sizeof(struct mq_attr)) $ \ p_attrs -> do (#poke struct mq_attr, mq_flags) p_attrs flags <<<<<<<<<<<<<<<<<<< On Tue, Apr 22, 2008 at 5:05 PM, Bulat Ziganshin wrote: > Hello Evan, > > Wednesday, April 23, 2008, 1:48:30 AM, you wrote: > > > The FFI doc doesn't really talk about the alignment method at all, so > > I don't really understand how to write one or how it's used. > > write: easy. just specify how much data shoulkd be aligned. for > primitive datatypes this usually equals to datasize, for complex > structures this should be the same as maximum alignment of elements > involved: > > instance Storable Float > alignment = 4 > > instance Storable (a,b) > alignment = maximum [alignment a, alignment b] > > use: just align memory blocks allocated to store this datatype. usual > alignment technique is: > > alloc a = (allocBytes (sizeOf a + alignment a - 1) + (alignment a - 1)) > .&. (alignment a - 1) > > well, many standard allocators such as C malloc, actually provide you > blocks with a maximum alignment required to store any (primitive) > type, so you don't need to worry about it > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080422/db305e9f/attachment.htm From ryani.spam at gmail.com Tue Apr 22 23:48:24 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Apr 22 23:43:15 2008 Subject: [Haskell-cafe] Re: Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <1208915208.21995.1249362141@webmail.messagingengine.com> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804221814g54ca3bfchd0811e45e67f8511@mail.gmail.com> <1208915208.21995.1249362141@webmail.messagingengine.com> Message-ID: <2f9b2d30804222048h41c0755cxca036c6cec2d54bb@mail.gmail.com> Actually, I think I came up with a solution on the way home from work today. Instead of > data Future t a = Fut > { waitFor :: t -> STM () > , value :: STM (t, a) > } I will use > data Future t a = Fut > { waitFor :: t -> IO (STM ()) > , value :: IO (STM (t, a)) > } The goal is to be able to wait on multiple things at a time, but that doesn't mean all the setup has to happen in STM. Now I can setup some TVars in IO and then hand-off to STM for the niceness of "orElse". -- ryan On Tue, Apr 22, 2008 at 6:46 PM, Matthew Brecknell wrote: > Ryan Ingram said: > > > > retryUntil :: TVar a -> (a -> Bool) -> STM () > > > > [...] > > > > > the semantics would be that the transaction log, > > instead of saying "I read from v" would say "I read from v and failed > > because v didn't satisfy this predicate". > > > > Changes to any other variable in the log would have the same effect as > > always: restarting the transaction. This is actually required in my > > desired use case; I want to block until "now" becomes >= t, or a > > different TVar gets filled with a non-Nothing value. > > I see now what you mean, and I can see that it might be a nice little > addition. By giving the STM runtime additional information about what > conditions would allow the transaction to progress, it might be able to > save some false retries. Note that the only work that is saved is the > work done to get to the retryUntil. > > However, strictly speaking, the STM runtime doesn't need this additional > information. You could view a composite STM transaction as an inverted > tree, with individual reads at the leaves, merging through monadic > bindings towards the root, which is the final result (which includes the > transaction's atomic updates). A transaction waiting on a retry is just > one of these trees in suspended animation, waiting for a new value to be > written to one of the leaves. When such a value is written to one of the > leaves, only its downstream nodes need re-evaluation. > > Implementing STM that way may not be worth the effort, though, whereas > retryUntil might be. > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From derek.a.elkins at gmail.com Tue Apr 22 23:52:35 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Apr 22 23:47:31 2008 Subject: [Haskell-cafe] Laziness and Either In-Reply-To: <480CF85C.6040808@therning.org> References: <200804211318.25854.jgoerzen@complete.org> <480CF85C.6040808@therning.org> Message-ID: <1208922755.5538.19.camel@derek-laptop> On Mon, 2008-04-21 at 21:26 +0100, Magnus Therning wrote: > John Goerzen wrote: > > Back when I was working on the logic for the bin-packing solver that I added > > to MissingH (for use with datapacker), I had a design decision to make: do I > > raise runtime errors with the input using error, or do I use an Either type > > to return errors? > > > > Initially, for simplicity, I just used error. But when I did a simple > > refactoring to use Either, it occurred to me that this switch likely had a > > negative impact on laziness. > > > > In this particular algorithm, we cannot tell for sure that we have no errors > > until we have consumed all items of the input list. This is unlike, say, a > > safe version of "head" where you can tell whether you have an error just by > > whether you have an empty list or not. > > > > In the case of using "error", we can happily process the data assuming > > everything will be fine, and raise an error if and when it is encountered. > > By using Either, however, any pattern match on the Left/Right result is > > going to force the entire input to be evaluated so that we can know whether > > or not it had any error. > > > > Is this analysis sensible? If so, are there better solutions? > > This reminds me of a problem I had in dataenc[1], when trying to decode > large files I ran out of memory. It was simple to track that down to my > decision to use Maybe for the return type. Originally I only had one > function for decoding: > > decode :: String -> Maybe [Word8] > decode = sequence . decode' > > In order to allow lazy decoding I ended up exporting decode' as well: > > decode' :: String -> [Maybe Word8] > > Unfortunately that pushes handling of decoding errors to the layer > above. Not ideal maybe, but it was the easiest solution. > > Duncan mentioned that iconv took a similar route to provide laziness[2]. > > I'm curious to see whether Malcom's paper can offer some further insight. > > /M > > [1]: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dataenc > [2]: http://www.haskell.org/pipermail/haskell-cafe/2007-December/036282.html Indeed, years ago this is exactly what I suggested as a possible solution. See http://web.archive.org/web/20061011010615/http://www.haskell.org/hawiki/TyingTheKnot near the bottom. From john at repetae.net Wed Apr 23 00:41:33 2008 From: john at repetae.net (John Meacham) Date: Wed Apr 23 00:36:24 2008 Subject: [Haskell-cafe] Re: Some clarity please! In-Reply-To: References: <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> <47D8F442.40704@iee.org> <87iqzqubo1.fsf@nmd9999.imr.no> Message-ID: <20080423044133.GZ17560@sliver.repetae.net> On Tue, Apr 22, 2008 at 05:28:27PM +0000, Michael Karcher wrote: > I am quite late to join this thread, but as I just read the thread > about Conal's AddBounds where he had a very valid point for > implementing min/max without resorting to <= or compare: > > min [] ys = [] > min xs [] = [] > min (x:xs) (y:ys) > | cmp == LT = (x:xs) > | cmp == GT = (y:ys) > | cmp == EQ = x:min xs ys > where cmp = compare x y > > This is a properly lazy implementation for min (the one in GHC's > prelude is not), as it is able to calculate (take 5 $ min [1,2..] > [1,2..]). This is not possible if min has to wait for compare or <= to > compare the full lists before returning the head. In addition, you need special min and max functions to implement IEEE floating point properly. Of course, floating point is odd in general, but we should be correct when we can. John -- John Meacham - ?repetae.net?john? From jonathanccast at fastmail.fm Wed Apr 23 00:45:28 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Apr 23 00:40:26 2008 Subject: [Haskell-cafe] I hate Haskell's typeclasses In-Reply-To: <1208919827.5538.16.camel@derek-laptop> References: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> <2f9b2d30804210050h58aac9e4xf2de56331d244ba@mail.gmail.com> <17C32BFB-7B07-418A-A56C-0FBF9D4C6A0C@fastmail.fm> <1208919827.5538.16.camel@derek-laptop> Message-ID: On 22 Apr 2008, at 8:03 PM, Derek Elkins wrote: > On Mon, 2008-04-21 at 22:58 -0700, Jonathan Cast wrote: > >> class Forceable alpha where >> seq :: alpha -> beta -> beta >> >> Instances derived automatically by the compiler, when possible, for >> every type (like Typeable should be). We can omit functions if >> desired (I don't remember why I thought this was a good idea). When >> you say >> >> f :: alpha -> beta >> >> or >> >> f :: C alpha => alpha -> beta >> >> The compiler adds implicit Forceable constraints on alpha and beta. >> But, if you say >> >> f :: !Forceable alpha => alpha -> beta >> >> The compiler leaves the Forceable alpha constraint off. Then you can >> say >> >> build :: (forall c. !Forceable c => (a -> c -> c) -> c -> c) -> [a] >> >> And the foldr/build law is still sound. > > Why do you want types that lie, plus some crazy ad-hoc special case? > Why not just let f :: a -> b mean what you write as f :: !Forceable > a => > a -> b exactly as it would if seq were moved (back) into a class? > Then > the free theorems would hold for the types as stated. See /Being Lazy with Class/, on why seq was made polymorphic in the first place. I don't /want/ this design, but the most common case is that you don't care, for a type variable alpha, whether seq can be used on alpha or not. When you do care, the most common case is that you want seq, and adding seq where it wasn't previously legal requires a chain of modifications reminiscent of const poisoning. I'm willing to consider seq :: a -> b -> b a practical necessity, and compromise with it, as long as I can still declare properly parametric types on command. jcc PS ?Lie? is a bit strong. A lie is a statement crafted to have a meaning not in the belief set of the speaker. The meaning of a Haskell type judgement is given by the language. So square :: Num alpha => alpha -> alpha square x = x ** 2 contains a lie. But I don't think seq :: alpha -> beta -> beta does. From jonathanccast at fastmail.fm Wed Apr 23 00:58:17 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Apr 23 00:53:15 2008 Subject: [Haskell-cafe] I hate Haskell's typeclasses In-Reply-To: <2f9b2d30804220953w7ea55e9fj58c5d268d89e92ab@mail.gmail.com> References: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> <2f9b2d30804210050h58aac9e4xf2de56331d244ba@mail.gmail.com> <17C32BFB-7B07-418A-A56C-0FBF9D4C6A0C@fastmail.fm> <2f9b2d30804220953w7ea55e9fj58c5d268d89e92ab@mail.gmail.com> Message-ID: On 22 Apr 2008, at 9:53 AM, Ryan Ingram wrote: > On Mon, Apr 21, 2008 at 10:58 PM, Jonathan Cast > wrote: >> I must have failed to communicate well. To me, the point of >> giving a class >> a name is that then you can write a program that is parametric >> over the >> elements of that class. Knowing that I can implement monads in >> Ruby doesn't >> impress me nearly as much as knowing that I can implement mapM does. >> Haskell has me addicted to code reuse (mapM) the way the rest of the >> programming world is addicted to design patterns (monads). What I >> mean by >> `encoding Num and Monad' is that you can do something like this: >> >> sum = foldr (+) 0 >> sequence = foldr (liftM2 (:)) (return []) >> >> I don't know of any language that is dynamically typed and also >> can encode >> `return' or `0' in a way that lets those examples work. >> Statically typed >> languages where it works are rare, even. Haskell gives up a fair >> amount of >> control by making these things implicit, which is what I think you're >> running up against --- but I think it gets something useful and >> non-trivial >> to acheive in return. > > I think ruby generally solves this problem via duck-typing; instead of > the cast happening in the (implicit) fromInteger call in sum above, > instead the cast happens in the function with more information via a > call to otherclass#to_whatever_i_am. You can do something like this: > > class Frob > attr_reader :val > def initialize(i) > @val = i > end > def to_frob > self > end > def +(rhs) > rhsF = rhs.to_frob > Frob.new(rhsF.val + @val) > end > end > > class Integer > def to_frob > Frob.new(self) > end > end > > class Array > def sum > foldl(0) {|acc,x| acc + x} > end > def foldl(z) > each {|x| z = yield(z,x)} > z > end > end > > irb(main):055:0> [1,2,3].sum > => 6 > irb(main):057:0> [1,2,3].map {|x| Frob.new(x)}.sum > => # How do I extend Num, in this case? Assign into the Integer namespace (maybe the wrong terminology, I don't know Ruby and don't want to)? I've considered designs like this, but they feel like a hack compared to type classes. >> I'll agree with this point. I've complained, concretely, about >> the lack of >> instances for (some) standard types before. (STM is actually a >> rather bad >> offender here; it's lacking MonadPlus, as well, despite the specific >> observation in the paper that it has the right signature for that >> class.) > > Actually: > > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Prelude> :m Control.Monad Control.Monad.STM > Prelude Control.Monad.STM Control.Monad> :i STM > ... > instance MonadPlus STM -- Defined in Control.Monad.STM OK. I was going off the documentation (which is spotty for STM anyway). >> When can we discharge a MaybeInstance context? > > On any concrete type. Like Typeable should be :) > The compiler then determines whether that type is an instance of the > class and provides the appropriate dictionary if applicable. This works if orphan instances are outlawed. That invalidates Haskell 98 programs, of course, including ones both of us have written. Forbidding those would be an interesting language design choice, of course, and would make most of what you've asked for sensible. Hmm. >> Having the | Show a test suddenly trip from False to True because >> some >> other module imported Text.Show.Functions sounds like an odd >> change to me. >> At any rate, it scares me enough to make me oppose the idea. > > I see the worry now. I think this is more of a problem with orphan > instances; are orphan instances considered to be a valuable enough > feature to avoid potentially more powerful constructs? > > Maybe there is a better solution to the "I have class C from library X > and type T from library Y and I want to make them play nice together" > problem than orphan instances. I can't think of one, for the general case, but I guarantee I'll be worrying about both questions until I think I know the answer... jcc From uwe at fh-wedel.de Wed Apr 23 02:27:37 2008 From: uwe at fh-wedel.de (Uwe Schmidt) Date: Wed Apr 23 02:22:30 2008 Subject: [Haskell-cafe] Processing XML with HXT In-Reply-To: References: Message-ID: <200804230827.38066.uwe@fh-wedel.de> Hi Rodrigo, > I?m just starting with HXT. My question is, how can I expose a "use case" from the main function below (the XmlPickler for UseCase has been already defined): > > main :: IO () > main = do > runX ( xunpickleDocument xpUseCase [ (a_validate,v_0) ], "uc.xml" ) > return () > > For example, if I just want to show the use case contents, how can I call "show" for a retrived use case. ------------------------------------- 1. version main :: IO () main = do [x] <- runX ( xunpickleDocument xpUseCase [ (a_validate,v_0) ], "uc.xml" ) print x return () x is processed outside the arrow ------------------------------------- 2. version main :: IO () main = do runX ( xunpickleDocument xpUseCase [ (a_validate,v_0) ], "uc.xml" >>> arrIO print ) return () x is processed within an arrow by lifting the print function to then arrow level. ------------------------------------ There is a new wiki page about picklers http://www.haskell.org/haskellwiki/HXT/Conversion_of_Haskell_data_from/to_XML Cheers, Uwe -- Uwe Schmidt Web: http://www.fh-wedel.de/~si/ From magnus at therning.org Wed Apr 23 02:50:45 2008 From: magnus at therning.org (Magnus Therning) Date: Wed Apr 23 02:45:48 2008 Subject: [Haskell-cafe] Storable class? In-Reply-To: <5ae4f2ba0804221223q127d927dl2650aaf71367936f@mail.gmail.com> References: <5ae4f2ba0804221223q127d927dl2650aaf71367936f@mail.gmail.com> Message-ID: <480EDC45.3090200@therning.org> Galchin, Vasili wrote: > Hello, > > Examples of instances of the Storable class please. I believe this is linked from the Haskell Wiki: http://therning.org/magnus/archives/315 There are a few comments on the alignment as well. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?gmail?com http://therning.org/magnus What if I don't want to obey the laws? Do they throw me in jail with the other bad monads? -- Daveman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080423/5b338adc/signature-0001.bin From apfelmus at quantentunnel.de Wed Apr 23 07:12:16 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Wed Apr 23 07:07:24 2008 Subject: [Haskell-cafe] Re: Laziness and Either In-Reply-To: <200804211542.39334.jgoerzen@complete.org> References: <200804211318.25854.jgoerzen@complete.org> <480CF85C.6040808@therning.org> <200804211542.39334.jgoerzen@complete.org> Message-ID: John Goerzen wrote: > On Mon April 21 2008 3:26:04 pm Magnus Therning wrote: >> In order to allow lazy decoding I ended up exporting decode' as well: >> >> decode' :: String -> [Maybe Word8] > > I take it that in a situation like this, you'd have either: > > [] -- success with empty result > > a list full of Just x > -- success with valid results > > a list with 0 or more Just x, followed by one Nothing > -- an error > > Makes sense to me. What impact does this have on performance? I think that using [Maybe a] for this purpose is too fine-grained, I would use a custom list type data River a = a :< (River a) | Done | Error (I didn't want to call it Stream because that name is too overloaded already and PartialList is too long :) The three constructors correspond to the three cases you mention. In particular, Error takes the role of the last Nothing . In other words, we just replace the usual end of list [] with another data type. Thus, the general version is data River b a = a :< (River a) | End b Of course, this type is isomorphic to River b a ~ (b, [a]) The latter just puts the end result up front which is the original idea for lazy parsing: report the error b but also return a (partial) result [a] . > Also, I wonder if there is some call for tools in Data.Either to support this > type of usage? For example: > > type EitherList a b = [Either a b] > > then some functions such as, say, mapEither or foldEither that act like > try/catch: a special function to use for an exception, and otherwise > they "unwrap" the Right side passing it along to others. The River thing has the drawback that you have to rewrite all the standard list functions, but since you're ready to accept that for in the case of [Either a b] anyway, you can as well use the River thing. Regards, apfelmus From droundy at darcs.net Wed Apr 23 09:40:06 2008 From: droundy at darcs.net (David Roundy) Date: Wed Apr 23 09:35:00 2008 Subject: [Haskell-cafe] Re: Laziness and Either In-Reply-To: References: <200804211318.25854.jgoerzen@complete.org> <480CF85C.6040808@therning.org> <200804211542.39334.jgoerzen@complete.org> Message-ID: <20080423134005.GB8763@darcs.net> On Wed, Apr 23, 2008 at 01:12:16PM +0200, apfelmus wrote: > I think that using [Maybe a] for this purpose is too fine-grained, I > would use a custom list type > > data River a = a :< (River a) | Done | Error > > (I didn't want to call it Stream because that name is too overloaded > already and PartialList is too long :) The three constructors > correspond to the three cases you mention. In particular, Error takes > the role of the last Nothing . That sounds like a good idea. But I'd call it Creek, because a river is present year-round, while a creek sometimes dries up in the summer. :) And I'd also vote for adding a String (or more generic parameter) to the Error type, so you can give some sort of reporting when something goes wrong. String is appealing, because then you could make Creek a monad, and fail could generate a nice Error message (assuming fail = Error). Of course, you could take the silly metaphor even further data Creek a = a :< (Creek a) | Ocean | Drought String :) -- David Roundy Department of Physics Oregon State University From ahey at iee.org Wed Apr 23 09:40:16 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Apr 23 09:35:09 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: Generic Haskell 1.80 (Emerald) In-Reply-To: <480DD3F6.9060306@cs.ru.nl> References: <49766.82.157.212.81.1208003963.squirrel@squirrel.science.ru.nl> <480D03C7.7080007@iee.org> <480DD3F6.9060306@cs.ru.nl> Message-ID: <480F3C40.6010808@iee.org> Thomas van Noort wrote: > As you already noticed, there is no Windows binary available for the > Emerald release. However, there is one for the Coral release, available > from: > > http://www.generic-haskell.org > > Although this is an old release of Generic Haskell, this release already > supports generic types, which is what you need for your project > probably. In the user's guide, there is a small example available which > defines a generic type to represent tries. Thanks, but this won't register itself as a package with current ghc, and even I fixed that problem I guess it probably still wouldn't work :-( It's entirely up to you folks of course. I don't know if anyone at GHHQ cares enought to do anything about the buildability problem. But if not I'm afraid I can't see this being used or accepted as part of standard Haskell infrastructure. It'll just be something people look at, admire the coolness, maybe even tinker with for a while, but never really use for anything serious. Meanwhile I think the GSoC project I mentioned will have to make other arrangements :-) To be honest though, I'm not sure we'd use it anyway as I understand it generates essentially pure H98 and there are ghc extensions we'd probably want to use for performance reasons (like unboxed Ints and unboxed tuples). Regards -- Adrian Hey From rodrigo.bonifacio at uol.com.br Wed Apr 23 10:16:35 2008 From: rodrigo.bonifacio at uol.com.br (rodrigo.bonifacio) Date: Wed Apr 23 10:11:27 2008 Subject: [Haskell-cafe] Processing XML with HXT Message-ID: Hi Uwe Schmidt, thanks a lot. Just one more question, I didn't find any example describing how to get the text information of a XML element in the picklers tutorial. So, if the use case element is described as follwing: UC_01 Opening ... This use case describes how... How can I set the id, name and desription of a use case? -- use case data type data UseCaseModel = UCM Name [UseCase] data UseCase = UseCase Id Name Description deriving (Show) -- I tried the following picler implementation -- but I think that it is not correct. instance XmlPickler UseCase where xpickle = xpUseCase xpUseCase :: PU UseCase xpUseCase = xpElem "useCase" $ xpWrap ( \ (i, n, d) -> UseCase i n d, \t -> (ucId t, name t, description t)) $ (xpTriple (xpElem "id" xpText) (xpElem "name" xpText) (xpElem "description" xpText)) > Hi Rodrigo, > > > I?m just starting with HXT. My question is, how can I expose a "use case" from the main function below (the XmlPickler for UseCase has been already defined): > > > > main :: IO () > > main = do > > runX ( xunpickleDocument xpUseCase [ (a_validate,v_0) ], "uc.xml" ) > > return () > > > > For example, if I just want to show the use case contents, how can I call "show" for a retrived use case. > > ------------------------------------- > > 1. version > > main :: IO () > main = do > [x] <- runX ( xunpickleDocument xpUseCase [ (a_validate,v_0) ], "uc.xml" ) > print x > return () > > x is processed outside the arrow > > ------------------------------------- > 2. version > > main :: IO () > main = do > runX ( xunpickleDocument xpUseCase [ (a_validate,v_0) ], "uc.xml" > >>> > arrIO print > ) > return () > > x is processed within an arrow by lifting the print function to then arrow level. > > ------------------------------------ > > There is a new wiki page about picklers > http://www.haskell.org/haskellwiki/HXT/Conversion_of_Haskell_data_from/to_XML > > Cheers, > > Uwe > > -- > > Uwe Schmidt > Web: http://www.fh-wedel.de/~si/ > ----------------------------------- Rodrigo Bonif?cio de Almeida Universidade Cat?lica de Bras?lia - Grupo de Engenharia de Software - JavaComBr (www.ucb.br/java) From tharris at microsoft.com Wed Apr 23 10:54:15 2008 From: tharris at microsoft.com (Tim Harris (RESEARCH)) Date: Wed Apr 23 10:49:07 2008 Subject: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> Message-ID: Hi, I think this could be a nice addition. What do you think about a slight change: readTVarWhen :: TVar a -> (a -> bool) -> STM a This would retry until the (a->bool) function returns true (and, of course, as with a normal "retry", the implementation would need to watch all of the TVars that have been read). This would avoid replicating the condition in the control flow of the program and the parameter to retryUntil, and avoid the possibility that the two conditions might be inconsistent (or can you see any examples where it might be useful to have different conditions)? Do you have a program where the basic implementation with "retry" is performing badly? If you're OK distributing it then could we add it to the STM benchmark suite that the group at Barcelona Supercomputing Center are developing? Thanks, Tim -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Ryan Ingram Sent: 22 April 2008 14:49 To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it wrong? How can I implement the following operation efficiently in STM? Given a TVar "now", waitFor t0 = do t <- readTVar now if (t < t0) then retry else return () This naive implementation has the problem that the transaction gets restarted every time "now" gets updated, even if the new value is still less than t0. One primitive that would be strong enough is this: retryUntil :: TVar a -> (a -> Bool) -> STM () although it would still do some computation every time "now" changed. The thought I originally had was to register the "waitFor" time with some helper which kept track of the current time and fired off a notice when it was ready. But the problem with that is that "retry" undoes all the work of setting that up; the goal is still to block, but I want a stronger blocking primitive. Does anyone have any ideas? -- ryan Here's the background: I'm following along with Conal's excellent FRP paper at http://conal.net/papers/simply-reactive/ In his implementation of futures, Conal uses a race primitive which spawns two threads each computing a value that (if successful) is guaranteed to agree. I was (and still am) sure that an implementation using STM could avoid needing to race, with careful use of orElse & retry. Here's the datatype I'm using for Future: > -- semantic type for future > -- t = type of Time, an instance of Bounded. a = value type > type F t a = (t, a) > force :: Future t a -> F t a > data Future t a = Fut > { waitFor :: t -> STM () > , value :: STM (t, a) > } > firstFuture :: Future t a -> Future t a -> Future t a > -- with semantics: > -- force (firstFuture f1 f2) = (min t1 t2, if t1 <= t2 then v1 else v2) > -- where > -- (t1, v1) = force f1 > -- (t2, v2) = force f2 Each future lives in some universe; imagine you have the following: ] type Universe t -- abstract ] P :: Bounded t => Universe t -- universe of pure values ] R :: Universe Time -- universe of the real world ] univ :: Future t a -> Universe t ] now :: Universe t -> STM t ] -- now P = return maxBound ] -- now R = current time The main thrust of this is that each universe has its own idea of what time it is; but when combining futures, we get a new universe which tracks the later of the times in the two universes. The problem is combining two futures: Lets say we have: anyKey :: Future Time () -- fires when the user first presses a key thousand :: Num t => Future t () -- fires at tick 1000 thousand = exactly 1000 () and we are evaluating force (firstFuture anyKey thousand) Now, "clock" is going to fire at tick 1000; we know this because it lives in the pure universe and its value is always available. So firstFuture can get the following: x1 <- maybeSTM (value anyKey) -- x1 = Nothing x2 <- maybeSTM (value clock) -- x2 = Just (1000, ()) ... -- synchronize P with R at tick 1000 waitFor anyKey 1000 -- if nothing has changed before tick 1000 return (1000, ()) -- converts a possibly-retry-calling STM into one that never fails maybeSTM m = fmap Just m `orElse` return Nothing So if we use the naive implementation for "waitFor" in terms of "now", the whole transaction will get re-evaluated every tick. I only want it to get re-evaluated if the user presses a key (changing some TVar evaluated in "value anyKey"), or tick 1000 passes, whichever comes first. Is there a way to do this? Is my choice of "waitFor" as the basic "universe synchronization" operation too weak? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe From dave at zednenem.com Wed Apr 23 10:58:56 2008 From: dave at zednenem.com (David Menendez) Date: Wed Apr 23 10:54:01 2008 Subject: [Haskell-cafe] Laziness and Either In-Reply-To: <200804211318.25854.jgoerzen@complete.org> References: <200804211318.25854.jgoerzen@complete.org> Message-ID: <49a77b7a0804230758u15213b48vd64d5ec46ca27234@mail.gmail.com> On Mon, Apr 21, 2008 at 2:18 PM, John Goerzen wrote: > Back when I was working on the logic for the bin-packing solver that I added > to MissingH (for use with datapacker), I had a design decision to make: do I > raise runtime errors with the input using error, or do I use an Either type > to return errors? > > Initially, for simplicity, I just used error. But when I did a simple > refactoring to use Either, it occurred to me that this switch likely had a > negative impact on laziness. > > In this particular algorithm, we cannot tell for sure that we have no errors > until we have consumed all items of the input list. This is unlike, say, a > safe version of "head" where you can tell whether you have an error just by > whether you have an empty list or not. > > In the case of using "error", we can happily process the data assuming > everything will be fine, and raise an error if and when it is encountered. > By using Either, however, any pattern match on the Left/Right result is > going to force the entire input to be evaluated so that we can know whether > or not it had any error. > > Is this analysis sensible? If so, are there better solutions? >From my perspective, the version using Either is lazier. By delaying any further processing until the input is known to be correct, it avoids doing unnecessary work. On the other hand, if space is more of a concern than time, then you could combine the processing with a left fold that accumulates an answer. process :: [Input] -> Either Error [Output] -- lazy processAccum :: (seed -> Input -> seed) -> seed -> [Input] -> Either Error seed -- thrifty The type of 'processAccum' is essentially an encoding of the River type apfelmus proposed. It's also related to Oleg's left-fold enumerator pattern[1]. [1] http://okmij.org/ftp/Computation/Continuations.html#enumerator-stream -- Dave Menendez From cdsmith at twu.net Wed Apr 23 11:22:52 2008 From: cdsmith at twu.net (Chris Smith) Date: Wed Apr 23 11:17:56 2008 Subject: [Haskell-cafe] Re: Stronger STM primitives needed? Or am I just doing it wrong? References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> Message-ID: On Wed, 23 Apr 2008 15:54:15 +0100, Tim Harris (RESEARCH) wrote: > What do you think about a slight change: > > readTVarWhen :: TVar a -> (a -> bool) -> STM a > > This would retry until the (a->bool) function returns true (and, of > course, as with a normal "retry", the implementation would need to watch > all of the TVars that have been read). This looks nice to me, anyway. I was confusing myself with my earlier reply. So basically you'd accumulate a list of reads to any given TVar and the old value that was read, and then walk through that list to determine whether to retry a transaction, where: 1. If the predicate fails on the new value, then keep waiting. 2. If the predicate succeeds on the new value: 2a. If the new value is the same as the old, look at next in list. 2b. If the new value is different from the old, retry now. Case 2a is there because the TVar may have been changed to something that fails the predicate, and then changed back to the original. Of course, retrying now is always legal, so you could simplify this by only keeping a record of the first access to the TVar and throwing away the old value; then always do 2b if the predicate succeeds. That would involve considerably less bookkeeping, at the expense of replaying some transactions unnecessarily. Then readTVarWhen would basically be special only if it's the first access to the TVar within the transaction. -- Chris Smith From dave at zednenem.com Wed Apr 23 11:43:58 2008 From: dave at zednenem.com (David Menendez) Date: Wed Apr 23 11:38:48 2008 Subject: [Haskell-cafe] ANNOUNCE: Galois web libraries for Haskell released In-Reply-To: References: <20080421181119.GB8601@scytale.galois.com> <200804220820.10015.jgoerzen@complete.org> Message-ID: <49a77b7a0804230843n6fb3f7c4kf754cba213fc2e16@mail.gmail.com> On Tue, Apr 22, 2008 at 11:57 AM, Aaron Tomb wrote: > > On Apr 22, 2008, at 6:20 AM, John Goerzen wrote: > > > > > > * xml > > > A simple, lightweight XML parser/generator. > > > > > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml > > > > > > > Can you describe how this compares to HaXml? Were there deficiencies in > > HaXml? > > > > The main difference is that it's simpler. It's perhaps 10-20% the size of > HaXml. For a program that just has to do simple XML processing, it's > sometimes undesirable to have to link in a library that does a lot more than > you need. It would be convenient to have a list of unsupported XML features. The ones I've noticed so far are * doctypes (and all doctype-related markup) * processing instructions * notations Comments are recognized but not preserved, so you can't round-trip a document containing them. (Personally, I use namespaces more than I use any of these, which is why I don't use HaXml.) -- Dave Menendez From mrchebas at gmail.com Wed Apr 23 12:10:34 2008 From: mrchebas at gmail.com (Alexey Rodriguez) Date: Wed Apr 23 12:05:28 2008 Subject: [Haskell-cafe] Re: [Haskell] ANNOUNCE: Generic Haskell 1.80 (Emerald) In-Reply-To: <480F3C40.6010808@iee.org> References: <49766.82.157.212.81.1208003963.squirrel@squirrel.science.ru.nl> <480D03C7.7080007@iee.org> <480DD3F6.9060306@cs.ru.nl> <480F3C40.6010808@iee.org> Message-ID: <4b39c80a0804230910i2384d6f1w33b378827d2e52a1@mail.gmail.com> On Wed, Apr 23, 2008 at 3:40 PM, Adrian Hey wrote: > Thomas van Noort wrote: > > > As you already noticed, there is no Windows binary available for the > > Emerald release. However, there is one for the Coral release, available > > from: > > > > http://www.generic-haskell.org > > > > Although this is an old release of Generic Haskell, this release already > > supports generic types, which is what you need for your project probably. In > > the user's guide, there is a small example available which defines a generic > > type to represent tries. > > > > Thanks, but this won't register itself as a package with current ghc, > and even I fixed that problem I guess it probably still wouldn't > work :-( > > It's entirely up to you folks of course. I don't know if anyone at GHHQ > cares enought to do anything about the buildability problem. But if not > I'm afraid I can't see this being used or accepted as part of standard > Haskell infrastructure. It'll just be something people look at, admire > the coolness, maybe even tinker with for a while, but never really use > for anything serious. I don't see GH moving away from Makefiles in the future. First, we need to track dependencies on AG and GH source files, which would require a fair amount of effort to implement in a Cabal-based build. Second, GH installs with no problems on the platforms we use (Linux and Mac OS X systems). As an aside, note that there are other Haskell projects that do not have Cabal based builds such as GHC and Gtk2hs. GH previously supported cygwin-based builds but it is broken due to some cygwin changes. At the moment we do not plan to fix it, but if there is enough interest we could be persuaded to do so. However, if you really need a Cabal-based build without Cygwin or MSYS dependencies, then I guess you are out of luck :). > > > Meanwhile I think the GSoC project I mentioned will have to make other > arrangements :-) > > To be honest though, I'm not sure we'd use it anyway as I understand > it generates essentially pure H98 and there are ghc extensions we'd > probably want to use for performance reasons (like unboxed Ints and > unboxed tuples). You can always use a generated H98 module with a non-H98 module. However, if your generic function uses non-H98 features, it could get tricky. There are solutions for that, though. Cheers, Alexey > > > Regards > -- > Adrian Hey > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080423/0a996cac/attachment.htm From ryani.spam at gmail.com Wed Apr 23 12:13:14 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Apr 23 12:08:04 2008 Subject: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> Message-ID: <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> On Wed, Apr 23, 2008 at 7:54 AM, Tim Harris (RESEARCH) wrote: > What do you think about a slight change: > > readTVarWhen :: TVar a -> (a -> bool) -> STM a This seems strictly less powerful than retryUntil: > readTVarWhen v p = retryUntil v p >> readTVar v Consider the following transaction: > intV :: TVar Int > boolV :: TVar Bool > > interesting = atomically $ do > retryUntil intV (> 50) > retryUntil boolV id Lets say that intV contains 100 and boolV contains False. Then this transaction retries. Now, if intV changes to 101, this transaction doesn't need to re-run; we can see immediately that no predicate changed. Using "readTVarWhen", this is less clear; the transaction log would hold a read on intV which would be more difficult to ignore. -- ryan From sebastian.sylvan at gmail.com Wed Apr 23 12:24:20 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Wed Apr 23 12:19:10 2008 Subject: [Haskell-cafe] Re: [Haskell] Matrix multiplication In-Reply-To: <480F5D6E.5070705@rwth-aachen.de> References: <480F5D6E.5070705@rwth-aachen.de> Message-ID: <3d96ac180804230924h7beeecccy4689a77b2f69381e@mail.gmail.com> On Wed, Apr 23, 2008 at 5:01 PM, Tillmann Vogt wrote: > Hi, > > I am currently experimenting with parallelizing C-programs. I have > therefore written a matrix vector multiplication example that needs 13 > seconds to run (5 seconds with OpenMP). Because I like Haskell I did the > same in this language, but it takes about 134 seconds. Why is it so slow? > Does someone have an idea? > > Yes, in the C version you use unboxed arrays, in the Haskell version you use a linked list of linked lists. Naturally the latter will take up more space, require more work to index, and will thrash the cache quite a bit. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080423/213ba7a5/attachment.htm From derek.a.elkins at gmail.com Wed Apr 23 12:42:46 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Wed Apr 23 12:37:42 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <20080418213405.GT8763@darcs.net> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> <4310375315.20080419001919@gmail.com> <20080418203222.GQ8763@darcs.net> <48090E08.1020109@cs.pdx.edu> <20080418213405.GT8763@darcs.net> Message-ID: <1208968967.5538.22.camel@derek-laptop> On Fri, 2008-04-18 at 14:34 -0700, David Roundy wrote: > On Fri, Apr 18, 2008 at 02:09:28PM -0700, Jim Snow wrote: > > On a particular scene with one instance of the single-threaded renderer > > running, it takes about 19 seconds to render an image. With two > > instances running, they each take about 23 seconds. This is on an > > Athlon-64 3800+ dual core, with 512kB of L2 cache per core. So, it > > seems my memory really is slowing things down noticeably. > > This doesn't mean there's no hope, it just means that you'll need to be > extra-clever if you're to get a speedup that is close to optimal. The key > to overcoming memory bandwidth issues is to think about cache use and > figure out how to improve it. For instance, O(N^3) matrix multiplication > can be done in close to O(N^2) time provided it's memory-limited, by > blocking memory accesses so that you access less memory at once. > > In the case of ray-tracing I've little idea where or how you could improve > memory access patterns, but this is what you should be thinking about (if > you want to optimize this code). Of course, improving overall scaling is > best (e.g. avoiding using lists if you need random access). Next I'd ask > if there are more efficent or compact data structures that you could be > using. If your program uses less memory, a greater fraction of that memory > will fit into cache. Switching to stricter data structures and turning on > -funbox-strict-fields (or whatever it's called) may help localize your > memory access. Even better if you could manage to use unboxed arrays, so > that your memory accesses really would be localized (assuming that you > actually do have localize memory-access patterns). > > Of course, also ask yourself how much memory your program is using in > total. If it's not much more than 512kB, for instance, we may have > misdiagnosed your problem. Ingo Wald's work on interactive coherent raytracing springs to mind. http://www.sci.utah.edu/~wald/Publications/ "Interactive Rendering with Coherent Raytracing" http://graphics.cs.uni-sb.de/~wald/Publications/EG2001_IRCRT/InteractiveRenderingWithCoherentRayTracing.pdf is a decent, if dated, introduction. He clearly has much more newer stuff as well. From marco-oweber at gmx.de Wed Apr 23 12:43:42 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Wed Apr 23 12:38:33 2008 Subject: [Haskell-cafe] Re: [darcs-devel] announcing franchise 0.0 In-Reply-To: <20080418153703.GN8763@darcs.net> References: <20080418153703.GN8763@darcs.net> Message-ID: <20080423164342.GB16444@gmx.de> On Fri, Apr 18, 2008 at 08:37:06AM -0700, David Roundy wrote: > I'm pleased to announce the existence (not release, properly) of > franchise, a new configuration/build system for Haskell programs and > packages. Hi David! I like this idea.. ( I had it myself in another context : Generating nix expressions and figuring out dependencies automatically..) Is Franchise only meant to compile executables? Or is there some support for libraries as well? You need to feed in at least a list of exposed modules I guess Marc Weber From uwe at fh-wedel.de Wed Apr 23 12:55:00 2008 From: uwe at fh-wedel.de (Uwe Schmidt) Date: Wed Apr 23 12:49:51 2008 Subject: [Haskell-cafe] Processing XML with HXT Message-ID: <200804231855.00852.uwe@fh-wedel.de> Hi Rodrigo, > Just one more question, I didn't find any example describing how to get the > text information of a XML element in the picklers tutorial. So, if the use case > element is described as follwing: > ... here is a complete example for your use case. Take the following XML data in file "uc.xml" ------------------------ UC_01 Opening ... This use case describes how... ------------------------ and the following picker and test ------------------------ module Main where import Text.XML.HXT.Arrow type Id = String type Name = String type Description = String data UseCaseModel = UCM Name [UseCase] deriving (Show) data UseCase = UseCase Id Name Description deriving (Show) instance XmlPickler UseCase where xpickle = xpUseCase xpUseCaseModel :: PU UseCaseModel xpUseCaseModel = xpElem "useCaseModel" $ xpWrap ( uncurry UCM , \ (UCM n ucs) -> (n, ucs) ) $ xpPair ( xpAttr "name" xpText ) ( xpList xpUseCase ) xpUseCase :: PU UseCase xpUseCase = xpElem "useCase" $ xpWrap ( uncurry3 UseCase , \ (UseCase i n d) -> (i, n, d) ) $ xpTriple (xpElem "id" xpText) (xpElem "name" xpText) (xpElem "description" xpText) main :: IO () main = do runX ( xunpickleDocument xpUseCaseModel [ (a_validate,v_0) , (a_trace, v_1) , (a_remove_whitespace,v_1) -- !!!!!!!!!! throw away whitespace , (a_preserve_comment, v_0) -- !!!!!!!!!! throw away comments ] "uc.xml" >>> processUseCaseModel >>> xpickleDocument xpUseCaseModel [ (a_indent, v_1) ] "new-uc.xml" ) return () -- the dummy for processing the unpickled data processUseCaseModel :: IOSArrow UseCaseModel UseCaseModel processUseCaseModel = arrIO ( \ x -> do {print x ; return x}) ----------------------- This program will print the internal haskell value and writes the data to "new-uc.xml" Cheers Uwe -- Uwe Schmidt Web: http://www.fh-wedel.de/~si/ From jmaessen at alum.mit.edu Wed Apr 23 13:43:17 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Wed Apr 23 13:38:12 2008 Subject: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> Message-ID: <2F436402-5EB7-45A9-A29F-78C43081D64C@alum.mit.edu> On Apr 23, 2008, at 12:13 PM, Ryan Ingram wrote: > On Wed, Apr 23, 2008 at 7:54 AM, Tim Harris (RESEARCH) > wrote: >> What do you think about a slight change: >> >> readTVarWhen :: TVar a -> (a -> bool) -> STM a > > This seems strictly less powerful than retryUntil: >> readTVarWhen v p = retryUntil v p >> readTVar v > > Consider the following transaction: > >> intV :: TVar Int >> boolV :: TVar Bool >> >> interesting = atomically $ do >> retryUntil intV (> 50) >> retryUntil boolV id > > Lets say that intV contains 100 and boolV contains False. Then this > transaction retries. Now, if intV changes to 101, this transaction > doesn't need to re-run; we can see immediately that no predicate > changed. How can we tell, though? In effect, I need to either say "I care when intV changes" or I need read intV again and make sure that (> 50) still holds before I can commit. > Using "readTVarWhen", this is less clear; the transaction > log would hold a read on intV which would be more difficult to ignore. In order to guarantee that your test is atomic wrt the rest of the transaction, you'll need to do the same. What you do in response to a change in intV might be different, though. I've been trying to decide whether either of these is implementable in terms of `orElse`, in such a way that we immediately check the predicate upon retry before doing anything else. I can't quite make up my mind whether this is possible or not. -Jan-Willem Maessen > -- ryan > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From dons at galois.com Wed Apr 23 14:08:11 2008 From: dons at galois.com (Don Stewart) Date: Wed Apr 23 14:03:02 2008 Subject: [Haskell-cafe] ANNOUNCE: Galois web libraries for Haskell released In-Reply-To: <49a77b7a0804230843n6fb3f7c4kf754cba213fc2e16@mail.gmail.com> References: <20080421181119.GB8601@scytale.galois.com> <200804220820.10015.jgoerzen@complete.org> <49a77b7a0804230843n6fb3f7c4kf754cba213fc2e16@mail.gmail.com> Message-ID: <20080423180811.GC22492@scytale.galois.com> dave: > On Tue, Apr 22, 2008 at 11:57 AM, Aaron Tomb wrote: > > > > On Apr 22, 2008, at 6:20 AM, John Goerzen wrote: > > > > > > > > > * xml > > > > A simple, lightweight XML parser/generator. > > > > > > > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml > > > > > > > > > > Can you describe how this compares to HaXml? Were there deficiencies in > > > HaXml? > > > > > > > The main difference is that it's simpler. It's perhaps 10-20% the size of > > HaXml. For a program that just has to do simple XML processing, it's > > sometimes undesirable to have to link in a library that does a lot more than > > you need. > > It would be convenient to have a list of unsupported XML features. The > ones I've noticed so far are > > * doctypes (and all doctype-related markup) > * processing instructions > * notations > > Comments are recognized but not preserved, so you can't round-trip a > document containing them. > > (Personally, I use namespaces more than I use any of these, which is > why I don't use HaXml.) > I've created a wiki page to start on community documentation for the light xml library, http://haskell.org/haskellwiki/XML_Light Feel free to add text, examples, etc there -- Don From apfelmus at quantentunnel.de Wed Apr 23 14:49:58 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Wed Apr 23 14:45:10 2008 Subject: [Haskell-cafe] Re: Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> Message-ID: Ryan Ingram wrote: > Consider the following transaction: > >> intV :: TVar Int >> boolV :: TVar Bool >> >> interesting = atomically $ do >> retryUntil intV (> 50) >> retryUntil boolV id > > Lets say that intV contains 100 and boolV contains False. Then this > transaction retries. Now, if intV changes to 101, this transaction > doesn't need to re-run; we can see immediately that no predicate > changed. Using "readTVarWhen", this is less clear; the transaction > log would hold a read on intV which would be more difficult to ignore. I don't quite understand what you want to do but I presume it's related to the following: given an expression like readTVar intV >>= (\ -> ... readTVar boolV >>= (\_ -> ... retry)) The ... indicate branches that are there have not been taken in our example run, so the STM-side-effects that have been performed are readTVar intV readTVar boolV retry The thread waits for either intV or boolV to change. Now, assume that boolV changes. Then, the idea for improving performance is to not restart the whole transaction, but only the part after the readTVar boolV . In other words, only the continuation (\_ -> ... retry) will be executed again (and possibly yield something different from retry ). I'm not sure whether this is currently implemented in Control.STM. It seems that your scheme wants even more. You want to avoid work when intV changes, because the predicate for boolV clearly indicates that no matter what intV is, we'll have to retry anyway. Unfortunately, I don't think it works: the predicate itself might depend on intV interesting = atomically $ readTVar intV >>= $ \i -> if i > 50 then retry else retryUntil boolV (even i ==) That's the general property of >>= , you always have to evaluate its right argument when the left argument changes. In essence, we have the same problem with parser combinators. Applicative functors to the rescue! Regards, apfelmus From gwern0 at gmail.com Wed Apr 23 14:55:49 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Wed Apr 23 14:51:57 2008 Subject: [Haskell-cafe] Cabalizing darcs Message-ID: <20080423185549.GA21309@localhost> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080423/3d72a4f2/attachment.bin From droundy at darcs.net Wed Apr 23 15:02:48 2008 From: droundy at darcs.net (David Roundy) Date: Wed Apr 23 14:57:38 2008 Subject: [Haskell-cafe] Re: [Haskell] Matrix multiplication In-Reply-To: <3d96ac180804230924h7beeecccy4689a77b2f69381e@mail.gmail.com> References: <480F5D6E.5070705@rwth-aachen.de> <3d96ac180804230924h7beeecccy4689a77b2f69381e@mail.gmail.com> Message-ID: <20080423190247.GD8763@darcs.net> On Wed, Apr 23, 2008 at 05:24:20PM +0100, Sebastian Sylvan wrote: > On Wed, Apr 23, 2008 at 5:01 PM, Tillmann Vogt > wrote: > > > Hi, > > > > I am currently experimenting with parallelizing C-programs. I have > > therefore written a matrix vector multiplication example that needs 13 > > seconds to run (5 seconds with OpenMP). Because I like Haskell I did the > > same in this language, but it takes about 134 seconds. Why is it so slow? > > Does someone have an idea? > > > Yes, in the C version you use unboxed arrays, in the Haskell version you use > a linked list of linked lists. Naturally the latter will take up more space, > require more work to index, and will thrash the cache quite a bit. In fact, I'm impressed that Haskell can come within a factor of 10, given that it's using such a challenging data type! (I wonder if this may be due to inefficiencies in the C code, although I haven't looked at it.) -- David Roundy Department of Physics Oregon State University From droundy at darcs.net Wed Apr 23 15:04:21 2008 From: droundy at darcs.net (David Roundy) Date: Wed Apr 23 14:59:11 2008 Subject: [Haskell-cafe] Re: [darcs-devel] announcing franchise 0.0 In-Reply-To: <20080423164342.GB16444@gmx.de> References: <20080418153703.GN8763@darcs.net> <20080423164342.GB16444@gmx.de> Message-ID: <20080423190420.GE8763@darcs.net> On Wed, Apr 23, 2008 at 06:43:42PM +0200, Marc Weber wrote: > On Fri, Apr 18, 2008 at 08:37:06AM -0700, David Roundy wrote: > > I'm pleased to announce the existence (not release, properly) of > > franchise, a new configuration/build system for Haskell programs and > > packages. > > Hi David! > I like this idea.. ( I had it myself in another context : Generating nix > expressions and figuring out dependencies automatically..) > > Is Franchise only meant to compile executables? > Or is there some support for libraries as well? > You need to feed in at least a list of exposed modules I guess It does libraries also. It has to, since franchise itself is a library. Yes, you feed the list of exposed modules. You can look at franchise's Setup.hs for an example. It only exposes one module, but you can see that that module is given as a list. -- David Roundy Department of Physics Oregon State University From ryani.spam at gmail.com Wed Apr 23 15:07:06 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Apr 23 15:01:55 2008 Subject: [Haskell-cafe] Re: Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> Message-ID: <2f9b2d30804231207j5bb01dbfnf8e602724c100bac@mail.gmail.com> On 4/23/08, apfelmus wrote: > I don't quite understand what you want to do but I presume it's related to > the following: given an expression like > > readTVar intV >>= (\ -> ... readTVar boolV >>= (\_ -> ... retry)) > > The ... indicate branches that are there have not been taken in our example > run, so the STM-side-effects that have been performed are > > readTVar intV > readTVar boolV > retry > > The thread waits for either intV or boolV to change. Now, assume that > boolV changes. Then, the idea for improving performance is to not restart > the whole transaction, but only the part after the readTVar boolV . In > other words, only the continuation (\_ -> ... retry) will be executed again > (and possibly yield something different from retry ). I'm not sure whether > this is currently implemented in Control.STM. This isn't exactly correct, no. The idea was to attach an additional predicate to readTVar in the STM log, so that we know the result cannot affect the computation as long as the predicate is unchanged. > It seems that your scheme wants even more. You want to avoid work when intV > changes, because the predicate for boolV clearly indicates that no matter > what intV is, we'll have to retry anyway. Unfortunately, I don't think it > works: the predicate itself might depend on intV > > interesting = atomically $ > readTVar intV >>= $ \i -> > if i > 50 then retry else > retryUntil boolV (even i ==) > > That's the general property of >>= , you always have to evaluate its right > argument when the left argument changes. In essence, we have the same > problem with parser combinators. Applicative functors to the rescue! Ah, but that's the exact thing that retryUntil prevents; retryUntil doesn't return the value of the variable read; it has exactly two options: retryUntil v p ~= do x <- readTVar v if (p x) then return () else retry Now, a simple implementation would re-run the computation after each change to v. But we can take advantage of the knowledge that retryUntil imparts no knowledge to the rest of the computation besides "this predicate succeeded on the contents of this tvar", to make the transaction log smarter. So, in the case of "interesting", the transaction log would look something like this: retryUntil intV (> 50) => True retryUntil boolV id => False retry Now, lets say intV changes from 100 to 101; we can look at this transaction log, re-test the predicate (> 50), notice that the log itself remains unchanged, and leave the transaction suspended without worrying that the remainder of the computation was affected. Using Tim Harris' proposed "readTVarWhen" combinator, this guarantee is weakened; although the rule does hold for reads that fail the predicate: interesting2 = atomically $ do x <- readTVarWhen intV (>50) readTVarWhen intV2 (x ==) readTVarWhen intV (>50) => True readTVarWhen intV2 (x ==) => False retry If intV2 changes but the predicate stays false, we don't have to re-run the computation, but if intV changes we absolutely do. This is made clear by my definition of readTVarWhen: readTVarWhen v p = retryUntil v p >> readTVar v In this case the transaction log would look like this: retryUntil intV (>50) => True readTVar intV retryUntil intV2 (== x) => False retry Now if intV changes it's clear in the transaction log that the transaction needs to be re-run. -- ryan From ryani.spam at gmail.com Wed Apr 23 15:12:15 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Apr 23 15:07:04 2008 Subject: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <2F436402-5EB7-45A9-A29F-78C43081D64C@alum.mit.edu> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> <2F436402-5EB7-45A9-A29F-78C43081D64C@alum.mit.edu> Message-ID: <2f9b2d30804231212l5ca01e7ctd2261e8e396bec40@mail.gmail.com> On 4/23/08, Jan-Willem Maessen wrote: > I've been trying to decide whether either of these is implementable in terms > of `orElse`, in such a way that we immediately check the predicate upon > retry before doing anything else. I can't quite make up my mind whether > this is possible or not. I do not think it is possible; consider this case: broken = atomically $ do v <- expensive_computation :: STM (TVar Int) retryUntil v (> 50) Given that you don't know which tvar to use until the end of the expensive computation, I don't see how you can lift "orElse" to the make that tvar be the first thing checked when the transaction is rerun. From droundy at darcs.net Wed Apr 23 15:25:56 2008 From: droundy at darcs.net (David Roundy) Date: Wed Apr 23 15:20:45 2008 Subject: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <2f9b2d30804231212l5ca01e7ctd2261e8e396bec40@mail.gmail.com> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> <2F436402-5EB7-45A9-A29F-78C43081D64C@alum.mit.edu> <2f9b2d30804231212l5ca01e7ctd2261e8e396bec40@mail.gmail.com> Message-ID: <20080423192555.GF8763@darcs.net> On Wed, Apr 23, 2008 at 12:12:15PM -0700, Ryan Ingram wrote: > On 4/23/08, Jan-Willem Maessen wrote: > > I've been trying to decide whether either of these is implementable in terms > > of `orElse`, in such a way that we immediately check the predicate upon > > retry before doing anything else. I can't quite make up my mind whether > > this is possible or not. > > I do not think it is possible; consider this case: > > broken = atomically $ do > v <- expensive_computation :: STM (TVar Int) > retryUntil v (> 50) > > Given that you don't know which tvar to use until the end of the > expensive computation, I don't see how you can lift "orElse" to the > make that tvar be the first thing checked when the transaction is > rerun. I'm confused as to how your retryUntil gains you anything. If any of the TVars used in the expensive_computation change while waiting for a retry, then the expensive_computation will need to be done again. If none of them change, then we can skip the expensive_computation. How does retryUntil help us with this? i.e. how does your broken function using retryUntil differ from the following? broken = atomically $ do v <- expensive_computation :: STM (TVar Int) vv <- readTVar v unless (vv > 50) retry -- David Roundy Department of Physics Oregon State University From philip.weaver at gmail.com Wed Apr 23 15:26:35 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Wed Apr 23 15:21:23 2008 Subject: [Haskell-cafe] Cabalizing darcs In-Reply-To: <20080423185549.GA21309@localhost> References: <20080423185549.GA21309@localhost> Message-ID: It looks quite clean (no funny business in Setup.lhs). I would favor using this cabalized version over the other. Thanks! So, autoconf/configure generate cryptol.buildinfo from cryptol.buildinfo.in. Did you change configure.ac much? And the Makefile is no longer needed at all, right? - Phil 2008/4/23 Gwern Branwen : > So recently I spent a bit of time working on a cabalization of Darcs. It works well for me, and is reasonably easy to apply (attached are three files; do a 'darcs get --lazy http://darcs.net' with Darcs-2 to get the latest, and copy the files into it, the usual autoconf, and it should then work as normal; if this doesn't work for you, I'd appreciate knowing). > > My question for y'all is: would you find an unofficial version of Darcs - one with the cabalization added and uploaded to Hackage - useful? Or would it just be frustrating and redundant and Not Good? > > (If yes, any suggestions for a package name? 'darcs' is out, but 'darcs-cb' and 'darcs-cabalized' strike me as horribly clunky or obscure.) > > -- > gwern > Threat WANK football Talent anarchy RIT interception Hutsul forschung ISS > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From droundy at darcs.net Wed Apr 23 15:34:10 2008 From: droundy at darcs.net (David Roundy) Date: Wed Apr 23 15:28:59 2008 Subject: [Haskell-cafe] Cabalizing darcs In-Reply-To: <20080423185549.GA21309@localhost> References: <20080423185549.GA21309@localhost> Message-ID: <20080423193409.GG8763@darcs.net> On Wed, Apr 23, 2008 at 02:55:49PM -0400, Gwern Branwen wrote: > So recently I spent a bit of time working on a cabalization of Darcs. It > works well for me, and is reasonably easy to apply (attached are three > files; do a 'darcs get --lazy http://darcs.net' with Darcs-2 to get the > latest, and copy the files into it, the usual autoconf, and it should > then work as normal; if this doesn't work for you, I'd appreciate > knowing). It certainly doesn't work for me. -- David Roundy Department of Physics Oregon State University -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080423/1813a9bd/attachment.bin From carette at mcmaster.ca Wed Apr 23 15:49:49 2008 From: carette at mcmaster.ca (Jacques Carette) Date: Wed Apr 23 15:47:26 2008 Subject: [Haskell-cafe] PLMMS - Last call for papers Message-ID: <480F92DD.1000503@mcmaster.ca> LAST CALL FOR PAPERS Second Workshop on Programming Languages for Mechanized Mathematics (PLMMS 2008) http://events.cs.bham.ac.uk/cicm08/workshops/plmms/ As part of CICM / Calculemus 2008 Birmingham, UK, 28-29 July 2008 This workshop is focused on the intersection of programming languages (PL) and mechanized mathematics systems (MMS). The latter category subsumes present-day computer algebra systems (CAS), interactive proof assistants (PA), and automated theorem provers (ATP), all heading towards fully integrated mechanized mathematical assistants that are expected to emerge eventually (cf. the objective of Calculemus). The two subjects of PL and MMS meet in the following topics, which are of particular interest to this workshop: * Dedicated input languages for MMS: covers all aspects of languages intended for the user to deploy or extend the system, both algorithmic and declarative ones. Typical examples are tactic definition languages such as Ltac in Coq, mathematical proof languages as in Mizar or Isar, or specialized programming languages built into CA systems. Of particular interest are the semantics of those languages, especially when current ones are untyped. * Mathematical modeling languages used for programming: covers the relation of logical descriptions vs. algorithmic content. For instance the logic of ACL2 extends a version of Lisp, that of Coq is close to Haskell, and some portions of HOL are similar to ML and Haskell, while Maple tries to do both simultaneously. Such mathematical languages offer rich specification capabilities, which are rarely available in regular programming languages. How can programming benefit from mathematical concepts, without limiting mathematics to the computational worldview? * Programming languages with mathematical specifications: covers advanced "mathematical" concepts in programming languages that improve the expressive power of functional specifications, type systems, module systems etc. Programming languages with dependent types are of particular interest here, as is intentionality vs extensionality. * Language elements for program verification: covers specific means built into a language to facilitate correctness proofs using MMS. For example, logical annotations within programs may be turned into verification conditions to be solved in a proof assistant eventually. How need MMS and PL to be improved to make this work conveniently and in a mathematically appealing way? These issues have a very colorful history. Many PL innovations first appeared in either CA or proof systems first, before migrating into more mainstream programming languages. Some examples include type inference, dependent types, generics, term-rewriting, first-class types, first-class expressions, first-class modules, code extraction etc. However, such innovations were never aggressively pursued by builders of MMS, but often reconstructed by programming language researchers. This workshop is an opportunity to present the latest innovations in MMS design that may be relevant to future programming languages, or conversely novel PL principles that improve upon implementation and deployment of MMS. We also want to critically examine what has worked, and what has not. Why are all the languages of mainstream CA systems untyped? Why are the (strongly typed) proof assistants so much harder to use than a typical CAS? What forms of polymorphism exist in mathematics? What forms of dependent types may be used in mathematical modeling? How can MMS regain the upper hand on issues of "genericity" and "modularity"? What are the biggest barriers to using a more mainstream language as a host language for a CAS or PA/ATP? Invited Talk ------------ Conor McBride (Alta Systems, Northern Ireland) will give an invited talk "Theorem Proving for the Lazy Programmer" Submission ---------- Submission works through EasyChair http://www.easychair.org/conferences/?conf=plmms2008 Two kinds of papers will be considered: * Full research papers may be up to 12 pages long. Authors of accepted papers are expected to present their work on the workshop in a regular talk. * Position papers may be up to 4 pages long. The workshop presentation of accepted position papers consists of two parts: a stimulating statement of certain issues or challenges by the author, followed by a discussion in the plenum. Papers should use the usual ENTCS style http://www.entcs.org/prelim.html (11 point version), and will be reviewed by the program committee. Informal workshop proceedings will be circulated as a technical report. Moreover there will be post-workshop proceedings of improved research papers, or position papers that have been completed into full papers, to appear in a special issue of the Journal of Automated Reasoning. There will be a separate submission and review phase for this, where papers from both PLMMS 2007 and 2008 will be considered. Programme Committee ------------------- Jacques Carette (Co-Chair) (McMaster University, Canada) John Harrison (Intel Corporation, USA) Hugo Herbelin (INRIA, Ecole polytechnique, France) James McKinna (Radboud University Nijmegen, Netherlands) Ulf Norell (Chalmers University, Sweden) Bill Page Christophe Raffalli (Universite de Savoie, France) Josef Urban (Charles University, Czech Republic) Stephen Watt (ORCCA, University of Western Ontario, Canada) Makarius Wenzel (Co-Chair) (Technische Universitaet Muenchen, Germany) Freek Wiedijk (Radboud University Nijmegen, Netherlands) Important Dates --------------- * Submission deadline - 5 May 2008 * Notification of acceptance - 6 June 2008 * Final version - 7 July 2008 (approximately) * Workshop - 28-29 July 2008 From lemming at henning-thielemann.de Wed Apr 23 16:01:59 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Apr 23 15:55:24 2008 Subject: [Haskell-cafe] Re: [Haskell] Matrix multiplication In-Reply-To: <3d96ac180804230924h7beeecccy4689a77b2f69381e@mail.gmail.com> References: <480F5D6E.5070705@rwth-aachen.de> <3d96ac180804230924h7beeecccy4689a77b2f69381e@mail.gmail.com> Message-ID: On Wed, 23 Apr 2008, Sebastian Sylvan wrote: > On Wed, Apr 23, 2008 at 5:01 PM, Tillmann Vogt > wrote: > >> I am currently experimenting with parallelizing C-programs. I have >> therefore written a matrix vector multiplication example that needs 13 >> seconds to run (5 seconds with OpenMP). Because I like Haskell I did the >> same in this language, but it takes about 134 seconds. Why is it so slow? >> Does someone have an idea? >> > Yes, in the C version you use unboxed arrays, in the Haskell version you use > a linked list of linked lists. Naturally the latter will take up more space, > require more work to index, and will thrash the cache quite a bit. For full speed matrix computations see http://alberrto.googlepages.com/gslhaskell From graham.fawcett at gmail.com Wed Apr 23 16:27:50 2008 From: graham.fawcett at gmail.com (Graham Fawcett) Date: Wed Apr 23 16:22:39 2008 Subject: [Haskell-cafe] zipper for rose trees? (Data.Tree) Message-ID: Hi folks, Is there a common zipper implementation for the "Tree a" datatype, defined in Data.Tree? The wiki gives examples for binary trees and B-trees, but not for these. Thanks, Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080423/5f97117f/attachment.htm From cetin.sert at gmail.com Wed Apr 23 16:34:33 2008 From: cetin.sert at gmail.com (Cetin Sert) Date: Wed Apr 23 16:29:23 2008 Subject: [Haskell-cafe] lookup tables & style guidelines Message-ID: <1ff5dedc0804231334y1a14f93cobf6b97da93285728@mail.gmail.com> Dear Haskell Devs ^_^, 1) what is the most performant lookup table/hashtable/dictionary solution for Haskell? 1.1) should I use size-balanced binary trees for that or is there a more common way? 2) are there any established style guidelines for haskell code? Best Regards, Cetin Sert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080423/ffcab57d/attachment.htm From dons at galois.com Wed Apr 23 16:36:34 2008 From: dons at galois.com (Don Stewart) Date: Wed Apr 23 16:31:23 2008 Subject: [Haskell-cafe] lookup tables & style guidelines In-Reply-To: <1ff5dedc0804231334y1a14f93cobf6b97da93285728@mail.gmail.com> References: <1ff5dedc0804231334y1a14f93cobf6b97da93285728@mail.gmail.com> Message-ID: <20080423203634.GG22492@scytale.galois.com> cetin.sert: > Dear Haskell Devs ^_^, > > 1) what is the most performant lookup table/hashtable/dictionary solution > for Haskell? Data.IntMap is awfully good. > 1.1) should I use size-balanced binary trees for that or is there a more > common way? I would. Data.Map/Data.IntMap > 2) are there any established style guidelines for haskell code? http://haskell.org/haskellwiki/Category:Style Or pick an author you like, and look at their code on hackage.haskell.org -- Don From kr.angelov at gmail.com Wed Apr 23 16:40:55 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Wed Apr 23 16:35:43 2008 Subject: [Haskell-cafe] zipper for rose trees? (Data.Tree) In-Reply-To: References: Message-ID: Hi Graham, There is one implementation here: http://code.haskell.org/yi/Data/Tree/ I wrote it for Yi but it is quite general. It is a pity that we don't have it in the standard libraries. It is not completely tested but it seems to work for me. Regards, Krasimir 2008/4/23 Graham Fawcett : > Hi folks, > > Is there a common zipper implementation for the "Tree a" datatype, defined > in Data.Tree? The wiki gives examples for binary trees and B-trees, but not > for these. > > Thanks, > Graham > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From ryani.spam at gmail.com Wed Apr 23 16:46:53 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Apr 23 16:41:43 2008 Subject: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <20080423192555.GF8763@darcs.net> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> <2F436402-5EB7-45A9-A29F-78C43081D64C@alum.mit.edu> <2f9b2d30804231212l5ca01e7ctd2261e8e396bec40@mail.gmail.com> <20080423192555.GF8763@darcs.net> Message-ID: <2f9b2d30804231346y685820bdkb7f26defff1ee47b@mail.gmail.com> On 4/23/08, David Roundy wrote: > I'm confused as to how your retryUntil gains you anything. If any of the > TVars used in the expensive_computation change while waiting for a retry, > then the expensive_computation will need to be done again. If none of them > change, then we can skip the expensive_computation. Does the STM runtime do this? > i.e. how does your broken function using retryUntil differ from the > following? > > broken = atomically $ do > v <- expensive_computation :: STM (TVar Int) > vv <- readTVar v > unless (vv > 50) retry If the STM runtime does the optimization you suggest, it's not different at all. But consider this computation: > -- non-primitive retryUntil: > retryUntil v p = do > x <- readVar v > unless (p x) retry > > broken2 = atomically $ do > (v1, v2) <- expensive_computation :: STM (TVar Int, TVar Int) > retryUntil v1 (> 50) > x <- expensive_computation2 :: STM Int > retryUntil v2 (> x) If v1 succeeds and v2 fails, then v1 changes to some other value > 50, I am sure that the STM runtime as it stands now will re-run expensive_computation2. -- ryan From cetin.sert at gmail.com Wed Apr 23 16:55:30 2008 From: cetin.sert at gmail.com (Cetin Sert) Date: Wed Apr 23 16:50:19 2008 Subject: [Haskell-cafe] lookup tables & style guidelines In-Reply-To: <20080423203634.GG22492@scytale.galois.com> References: <1ff5dedc0804231334y1a14f93cobf6b97da93285728@mail.gmail.com> <20080423203634.GG22492@scytale.galois.com> Message-ID: <1ff5dedc0804231355w2aa365a4v899f4a439eae3b7f@mail.gmail.com> Thanks Don... You are amazing... o_O always so quick with replies... I was using GraphViz to generate some directed graphs*, knowing what to use for a dict/map will help speed things up! Cetin * (for analytic tableaux in Okitsune+) + (need a better name, maybe I should ask Haskell-Cafe for one in the near future) 2008/4/23 Don Stewart : > cetin.sert: > > Dear Haskell Devs ^_^, > > > > 1) what is the most performant lookup table/hashtable/dictionary > solution > > for Haskell? > > Data.IntMap is awfully good. > > > 1.1) should I use size-balanced binary trees for that or is there a > more > > common way? > > I would. Data.Map/Data.IntMap > > > 2) are there any established style guidelines for haskell code? > > http://haskell.org/haskellwiki/Category:Style > > Or pick an author you like, and look at their code on > hackage.haskell.org > > > -- Don > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080423/9ae7c40d/attachment.htm From droundy at darcs.net Wed Apr 23 17:09:36 2008 From: droundy at darcs.net (David Roundy) Date: Wed Apr 23 17:04:24 2008 Subject: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <2f9b2d30804231346y685820bdkb7f26defff1ee47b@mail.gmail.com> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> <2F436402-5EB7-45A9-A29F-78C43081D64C@alum.mit.edu> <2f9b2d30804231212l5ca01e7ctd2261e8e396bec40@mail.gmail.com> <20080423192555.GF8763@darcs.net> <2f9b2d30804231346y685820bdkb7f26defff1ee47b@mail.gmail.com> Message-ID: <20080423210936.GM8763@darcs.net> On Wed, Apr 23, 2008 at 01:46:53PM -0700, Ryan Ingram wrote: > On 4/23/08, David Roundy wrote: > > I'm confused as to how your retryUntil gains you anything. If any of the > > TVars used in the expensive_computation change while waiting for a retry, > > then the expensive_computation will need to be done again. If none of them > > change, then we can skip the expensive_computation. > > Does the STM runtime do this? > > > i.e. how does your broken function using retryUntil differ from the > > following? > > > > broken = atomically $ do > > v <- expensive_computation :: STM (TVar Int) > > vv <- readTVar v > > unless (vv > 50) retry > > If the STM runtime does the optimization you suggest, it's not > different at all. I doubt it does this, but my point is that you aren't suggesting a new primitive, you're suggesting an improved runtime. Once you've got your improved runtime, this optimization is trivial, as far as I can tell. And without an improved runtime, your function is equivalent to this one. > But consider this computation: > > > -- non-primitive retryUntil: > > retryUntil v p = do > > x <- readVar v > > unless (p x) retry > > > > broken2 = atomically $ do > > (v1, v2) <- expensive_computation :: STM (TVar Int, TVar Int) > > retryUntil v1 (> 50) > > x <- expensive_computation2 :: STM Int > > retryUntil v2 (> x) > > If v1 succeeds and v2 fails, then v1 changes to some other value > 50, > I am sure that the STM runtime as it stands now will re-run > expensive_computation2. I suppose it depends on how you rewrite the runtime. Rather than your very limited retryUntil + caching of results computed in the STM, why not make this caching explicit, and allow users to write their own more complicated variants of retryUntil? e.g. retryUntil2 :: TVar a -> TVar b -> (a -> b -> Bool) -> IO () A simple primitive to do this (in combination with a totally rewritten STM runtime) would be subatomically :: ReadOnlySTM a -> STM () which would run a STM computation that is guaranteed to have no side-effects (i.e. can't write to TVars) and ignore its results (and let the runtime know that the results have been ignored). Then your extra-fancy retryUntil could simply be. retryUntil v p = subatomically $ do x <- readVarRO v unless (p x) retryRO The only thing that is special about your retryUntil is that it does not allow the modification of TVars. On the other hand, I suspect the whole issue is silly. Is it ever actually wise to do an expensive calculation in the STM monad? That seems like it's guaranteed to be a performance nightmare. -- David Roundy Department of Physics Oregon State University From s.clover at gmail.com Wed Apr 23 18:37:17 2008 From: s.clover at gmail.com (Sterling Clover) Date: Wed Apr 23 18:32:13 2008 Subject: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <2f9b2d30804231346y685820bdkb7f26defff1ee47b@mail.gmail.com> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> <2F436402-5EB7-45A9-A29F-78C43081D64C@alum.mit.edu> <2f9b2d30804231212l5ca01e7ctd2261e8e396bec40@mail.gmail.com> <20080423192555.GF8763@darcs.net> <2f9b2d30804231346y685820bdkb7f26defff1ee47b@mail.gmail.com> Message-ID: <9B48F789-4A32-43E6-BBCC-60A589926EC5@gmail.com> >> -- non-primitive retryUntil: >> retryUntil v p = do >> x <- readVar v >> unless (p x) retry >> >> broken2 = atomically $ do >> (v1, v2) <- expensive_computation :: STM (TVar Int, TVar Int) >> retryUntil v1 (> 50) >> x <- expensive_computation2 :: STM Int >> retryUntil v2 (> x) > > If v1 succeeds and v2 fails, then v1 changes to some other value > 50, > I am sure that the STM runtime as it stands now will re-run > expensive_computation2. > But expensive_computation2 is in STM. This means that it *should* be rerun, no? Between the first run and the retry, the result of expensive_computation2 may well have changed. If it doesn't get rerun, then we may have violated another transactional integrity constraint unknowingly. STM transactions should either happen once, or not at all. But if expensive_computation2 is not rerun, there's the possibility of "spooky action at a distance" effects, as I understand it? A more specific solution would be to build a memo- table (either with a CAF or via either TVars or MVars) structure into expensive_computation2 such that if it is rerun with the same TVar input, its work doesn't need to be recomputed. --S. From graham.fawcett at gmail.com Wed Apr 23 18:43:45 2008 From: graham.fawcett at gmail.com (Graham Fawcett) Date: Wed Apr 23 18:38:35 2008 Subject: [Haskell-cafe] zipper for rose trees? (Data.Tree) In-Reply-To: References: Message-ID: On Wed, Apr 23, 2008 at 4:40 PM, Krasimir Angelov wrote: > Hi Graham, > > There is one implementation here: > > http://code.haskell.org/yi/Data/Tree/ > > I wrote it for Yi but it is quite general. It is a pity that we don't > have it in the standard libraries. It is not completely tested but it > seems to work for me. Thank very much, Krasimir! I agree, it would be a good addition to the standard library. I've added a link to your implementation from the Zipper page in the Haskell wiki. Regards, Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080423/30be8458/attachment.htm From simonmarhaskell at gmail.com Wed Apr 23 18:46:28 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Apr 23 18:41:17 2008 Subject: [Haskell-cafe] Re: compressed pointers? In-Reply-To: <1376368623.20080418154637@gmail.com> References: <20080415120614.15389413.malcwallace@googlemail.com> <5ab17e790804151005y703c5d0dj50cf2f9b51cf1362@mail.gmail.com> <87y77eky3j.fsf@nmd9999.imr.no> <87tzi2kxwz.fsf@nmd9999.imr.no> <87od8akx2b.fsf_-_@nmd9999.imr.no> <20080416145934.GB12207@scytale.galois.com> <87bq47ek62.fsf@nmd9999.imr.no> <1376368623.20080418154637@gmail.com> Message-ID: <480FBC44.6080101@gmail.com> Bulat Ziganshin wrote: > Hello Ketil, > > Friday, April 18, 2008, 10:44:53 AM, you wrote: > >> This probably becomes too complicated, but I thought it was >> interesting that the Java people are making use of 32bit pointers on a >> 64bit system, and are seeing a good performance benefit from it. > > afaik, C compilers support this model too, so it shouldn't too hard to > compile GHC in such mode. it's a bit like small/large memory models of > those 16-bit x86 systems :) Except that you'd need to compile all your libraries in that mode too. The reason Java can do this is I imagine because they JIT all the code at runtime so they can change some aspects of code-generation strategy without recompiling everything. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Wed Apr 23 19:11:45 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 23 19:06:31 2008 Subject: [Haskell-cafe] Hackage being too strict? In-Reply-To: References: Message-ID: <1208992305.27748.171.camel@localhost> Just to keep haskell-cafe updated on this issue... On Tue, 2008-04-15 at 22:15 -0500, John Goerzen wrote: > When I went to make my upload of MissingH 1.0.1, Hackage rejected it, > saying: > > Instead of 'ghc-options: -XPatternSignatures' use 'extensions: PatternSignatures' Now fixed! (Well, at least it's fixed in Cabal. Hopefully the hackage scripts will get rebuilt against the latest Cabal some time in the next few days.) For extensions that are present in ghc-6.8 but not 6.6 hackage will not warn about using ghc-options: -XTheExtensionName. > Now, my .cabal file has this: > > -- Hack because ghc-6.6 and the Cabal the comes with ghc-6.8.1 > -- does not understand the PatternSignatures extension. > -- The Cabal that comes with ghc-6.8.2 does understand it, so > -- this hack can be dropped if we require Cabal-Version: >=1.2.3 > If impl(ghc >= 6.8) > GHC-Options: -XPatternSignatures So this will work fine. If one did add: Cabal-Version: >=1.2 then hackage would again complain about ghc-options: -XPatternSignatures but in this case it's legitimate again to complain because we can use extensions: PatternSignatures since that does work with cabal >= 1.2. In addition, as I previously mentioned, this whole problem of old versions not knowing about new extensions will go away from Cabal-1.4 onwards. Duncan From simonmarhaskell at gmail.com Wed Apr 23 19:25:10 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Apr 23 19:20:02 2008 Subject: [Haskell-cafe] Re: announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <48091460.20604@serpentine.com> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> <48091460.20604@serpentine.com> Message-ID: <480FC556.2060205@gmail.com> Bryan O'Sullivan wrote: > Jim Snow wrote: > >> The concurrency bug has to do with excessive memory use, and was >> discussed earlier here on the mailing list (search for Glome). >> http://hackage.haskell.org/trac/ghc/ticket/2185 > > Interesting. I looked at your test case. I can reproduce your problem > when I build with the threaded runtime and run with a single core, but > not if I use +RTS -N2. Did you overlook the possibility that you may > not have told GHC how many cores to use? There's definitely a bug here, regardless of whether this example demonstrates it. Use of par shouldn't introduce a space leak, and currently it can. (fortunately I'm fixing it as we speak...) Cheers, Simon From daveroundy at gmail.com Wed Apr 23 19:46:49 2008 From: daveroundy at gmail.com (David Roundy) Date: Wed Apr 23 19:41:42 2008 Subject: [Haskell-cafe] Re: [Haskell] How to define tail function for Even/Odd GADT lists? In-Reply-To: <480FC566.8020104@cs.uu.nl> References: <480F9D02.3090406@gmail.com> <480FC566.8020104@cs.uu.nl> Message-ID: <117f2cc80804231646x426cc01fy592f562f23cba641@mail.gmail.com> 2008/4/23 Martijn Schrage : > It depends a bit on what you want to use these lists for, but the following > encoding works for your examples and doesn't need the type class. > > data E > data O > > type Even = (E,O) > type Odd = (O,E) That's a nice little trick! I like how you achieve type signatures relating two distinct types just by sticking them in a tuple. :) David From gwern0 at gmail.com Wed Apr 23 19:49:09 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Wed Apr 23 19:43:58 2008 Subject: [Haskell-cafe] Cabalizing darcs In-Reply-To: References: <20080423185549.GA21309@localhost> Message-ID: On 2008.04.23 12:26:35 -0700, Philip Weaver scribbled 1.2K characters: > It looks quite clean (no funny business in Setup.lhs). I would favor > using this cabalized version over the other. Thanks! > > So, autoconf/configure generate cryptol.buildinfo from > cryptol.buildinfo.in. Did you change configure.ac much? I had to make a number of changes to configure.ac - the problem was that a lot of Darcs capabilities get modified through CPP; hence the darcs.buildinfo, to smuggle exported variables from the configure script to Cabal and to insert them in the correct fields. But not all of the necessary information was exported, so I had to fix that. Straightforward if you understand what you need. But there seems to be very little documentation on Cabal and buildinfos, so I had to do a bit of trial-and-error.... (Also, I dunno how you guys do Cryptol so can't speak to that.) > And the > Makefile is no longer needed at all, right? > > - Phil Strictly speaking, the Darcs makefile does a lot of stuff besides just building and installing - it also generates various forms of documentation (Haddocks, the LaTeX manual for Darcs), run the tests, and do quite a bunch of miscellaneous stuff like support for some Windows installer and Debian package format. Some of this could no doubt be handled in a pure Cabal framework (ie. I understand Goerzen has a package which can automatically take a Cabal tarball and make a Debian source deb), but I was just aiming at the building part. If that's all you need (like most users), then the makefile isn't needed, yes. -- gwern BLACKER Loin JAVA anthrax AG Zemin The Internet Sayeret 3P-HV From iavor.diatchki at gmail.com Wed Apr 23 19:55:51 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Apr 23 19:50:39 2008 Subject: [Haskell-cafe] Re: [Haskell] How to define tail function for Even/Odd GADT lists? In-Reply-To: <117f2cc80804231646x426cc01fy592f562f23cba641@mail.gmail.com> References: <480F9D02.3090406@gmail.com> <480FC566.8020104@cs.uu.nl> <117f2cc80804231646x426cc01fy592f562f23cba641@mail.gmail.com> Message-ID: <5ab17e790804231655t591422e4j59c610ddb0703d08@mail.gmail.com> Hello, I am not sure of the use case here but you could also do the following: data EvenList a = Nil | ConsE a (OddList a) data OddList a = ConsO a (EvenList a) This does not use any type system extensions. -Iavor On Wed, Apr 23, 2008 at 4:46 PM, David Roundy wrote: > 2008/4/23 Martijn Schrage : > > > It depends a bit on what you want to use these lists for, but the following > > encoding works for your examples and doesn't need the type class. > > > > data E > > data O > > > > type Even = (E,O) > > type Odd = (O,E) > > That's a nice little trick! I like how you achieve type signatures > relating two distinct types just by sticking them in a tuple. :) > > David > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From daveroundy at gmail.com Wed Apr 23 20:07:18 2008 From: daveroundy at gmail.com (David Roundy) Date: Wed Apr 23 20:02:06 2008 Subject: [Haskell-cafe] Re: [Haskell] How to define tail function for Even/Odd GADT lists? In-Reply-To: <5ab17e790804231655t591422e4j59c610ddb0703d08@mail.gmail.com> References: <480F9D02.3090406@gmail.com> <480FC566.8020104@cs.uu.nl> <117f2cc80804231646x426cc01fy592f562f23cba641@mail.gmail.com> <5ab17e790804231655t591422e4j59c610ddb0703d08@mail.gmail.com> Message-ID: <117f2cc80804231707t7a0b0674n9d23493ba0ca59dc@mail.gmail.com> I presume the point was to allow the writing of functions that accept either list type, such as sort :: List a evenorodd -> List a evenorodd or similar. David On Wed, Apr 23, 2008 at 7:55 PM, Iavor DiIatchki wrote: > Hello, > I am not sure of the use case here but you could also do the following: > > data EvenList a = Nil > | ConsE a (OddList a) > > data OddList a = ConsO a (EvenList a) > > This does not use any type system extensions. > > -Iavor > > > > On Wed, Apr 23, 2008 at 4:46 PM, David Roundy wrote: > > 2008/4/23 Martijn Schrage : > > > > > It depends a bit on what you want to use these lists for, but the following > > > encoding works for your examples and doesn't need the type class. > > > > > > data E > > > data O > > > > > > type Even = (E,O) > > > type Odd = (O,E) > > > > That's a nice little trick! I like how you achieve type signatures > > relating two distinct types just by sticking them in a tuple. :) > > > > David > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > From ryani.spam at gmail.com Wed Apr 23 20:15:51 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Apr 23 20:10:40 2008 Subject: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <9B48F789-4A32-43E6-BBCC-60A589926EC5@gmail.com> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> <2F436402-5EB7-45A9-A29F-78C43081D64C@alum.mit.edu> <2f9b2d30804231212l5ca01e7ctd2261e8e396bec40@mail.gmail.com> <20080423192555.GF8763@darcs.net> <2f9b2d30804231346y685820bdkb7f26defff1ee47b@mail.gmail.com> <9B48F789-4A32-43E6-BBCC-60A589926EC5@gmail.com> Message-ID: <2f9b2d30804231715t7cc9736q1494a71bf73d7e27@mail.gmail.com> On 4/23/08, Sterling Clover wrote: > But expensive_computation2 is in STM. This means that it *should* be rerun, > no? Between the first run and the retry, the result of > expensive_computation2 may well have changed. Ah, but that's not true; the main "good thing" about retry is that you don't have to keep running the computation; instead you wait until something that you accessed in your transaction log changes and -then- you rerun it. Right now the transaction log for "retry" only contains "read from variable X" (for some list of variables). But it could instead contain "read from variable X" and "read from variable X using retryUntil with predicate p which gave result True". Then we have a "smarter" log which can use the pure predicate p to give more information about whether or not the whole transaction can run or whether it is just guaranteed to fail again. If we know a transaction is guaranteed to fail, we can skip running it because we know it will not commit. Given the semantics of retryUntil, it is impossible that changing v1 affects the results of running this STM computation -unless- it or something else prior in the computation read from v1, or the result of the predicate changes. No spooky-action-at-a-distance is possible. David's more general "subatomically" primitive would achieve the same results; the proof is that (1) no side effects can be caused by the subatomic action, that is, no writes happen which could change future reads. (2) the result of the computation is ignored -except- for whether it retries or returns, that is, it can't affect the control flow of the rest of the transaction. So, if have a transaction T that is waiting inside "retry" for a variable that it read to change, and a variable that is only accessed in a "subatomic" part of T is changed, we can try running the subatomic computation first. Here are the four cases: 1) The subatomic computation succeeded before and still succeeded. Then we know the end result of the computation is unaffected, and will still retry. No need to do anything. 2) The subatomic computation succeeded before and now fails (calls 'retry' or retryRO'). Then we know that the computation will now fail at this earlier point. Mark the change to "fail" in the transaction log and leave the computation in the "waiting for retry" state. 3) The subatomic computation failed before and still fails. See (1) 4) The subatomic computation failed before and now succeeds. The result of the entire computation can change, we should now re-run the entire computation. -- ryan From philip.weaver at gmail.com Wed Apr 23 20:25:12 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Wed Apr 23 20:19:59 2008 Subject: [Haskell-cafe] Cabalizing darcs In-Reply-To: References: <20080423185549.GA21309@localhost> Message-ID: On Wed, Apr 23, 2008 at 4:49 PM, Gwern Branwen wrote: > On 2008.04.23 12:26:35 -0700, Philip Weaver > scribbled 1.2K characters: > > > It looks quite clean (no funny business in Setup.lhs). I would favor > > using this cabalized version over the other. Thanks! > > > > So, autoconf/configure generate cryptol.buildinfo from > > cryptol.buildinfo.in. Did you change configure.ac much? > > I had to make a number of changes to configure.ac - the problem was > that a lot of Darcs capabilities get modified through CPP; hence the > darcs.buildinfo, to smuggle exported variables from the configure > script to Cabal and to insert them in the correct fields. But not all > of the necessary information was exported, so I had to fix that. > Straightforward if you understand what you need. But there seems to be > very little documentation on Cabal and buildinfos, so I had to do a > bit of trial-and-error.... (Also, I dunno how you guys do Cryptol so > can't speak to that.) > Trial-and-error was my experience with buildinfo files, too. > > > And the > > Makefile is no longer needed at all, right? > > > > - Phil > > Strictly speaking, the Darcs makefile does a lot of stuff besides just > building and installing - it also generates various forms of > documentation (Haddocks, the LaTeX manual for Darcs), run the tests, > and do quite a bunch of miscellaneous stuff like support for some > Windows installer and Debian package format. Some of this could no > doubt be handled in a pure Cabal framework (ie. I understand Goerzen > has a package which can automatically take a Cabal tarball and make a > Debian source deb), but I was just aiming at the building part. If > that's all you need (like most users), then the makefile isn't needed, > yes. > So do you feel like this process yielded an easier to maintain build system? > -- > gwern > BLACKER Loin JAVA anthrax AG Zemin The Internet Sayeret 3P-HV > From jsnow at cs.pdx.edu Wed Apr 23 20:00:07 2008 From: jsnow at cs.pdx.edu (Jim Snow) Date: Wed Apr 23 20:56:36 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <1208968967.5538.22.camel@derek-laptop> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> <4310375315.20080419001919@gmail.com> <20080418203222.GQ8763@darcs.net> <48090E08.1020109@cs.pdx.edu> <20080418213405.GT8763@darcs.net> <1208968967.5538.22.camel@derek-laptop> Message-ID: <480FCD87.7010803@cs.pdx.edu> Derek Elkins wrote: > > Ingo Wald's work on interactive coherent raytracing springs to mind. > http://www.sci.utah.edu/~wald/Publications/ > > "Interactive Rendering with Coherent Raytracing" > http://graphics.cs.uni-sb.de/~wald/Publications/EG2001_IRCRT/InteractiveRenderingWithCoherentRayTracing.pdf > is a decent, if dated, introduction. He clearly has much more newer stuff as well. > > Those are good links. It's good to see that the groups of people who know about Haskell and people who know about ray tracing do, in fact, overlap. Background information for everyone else: Wald's work is related to OpenRT, which is an OpenGL-like api for interactive ray tracing (despite the name, it is not, in fact, open source). OpenRT makes for stiff competition. Arauna (http://igad.nhtv.nl/~bikker/) is very impressive, as well. On the other end of the spectrum, there's POV-Ray, which isn't known for its speed, but it is very flexible in the kinds of things it can render and can generate some fairly realistic images. Unlike most real-time ray tracers, which only render triangles, POV-Ray can render native representations of spheres, cones, toruses, heightfields, julia fractals, and a few dozen other kinds of primitives. Pbrt (http://www.pbrt.org/) is another renderer, more modern than POV-Ray, that focuses more on output quality than speed. Unfortunately, all the notable ray tracers that I'm aware of are written in C or C++ (often with a little hand-coded SSE), and as you might imagine I find this to be a sad state of affairs. Not that those are bad languages for this kind of work, but they shouldn't be the only option. I've ended up writing something more like POV-Ray than OpenRT, and that's fine with me. I'd rather have something that's slower but more expressive than fast but inflexible. (The former is also perhaps more easily attainable, particularly in Haskell.) This isn't to say that I'm not interested in making it fast as well. There are plenty of ways to make my raytracer faster: Kd-trees built using a surface area heuristic performed better than naively-built BIH when I implemented them in my ocaml raytracer (though they take longer to construct). If I can figure out how quaternions work, I could probably use them instead of transformation matricies to store cones in order to cut down on memory overhead (4 floats versus 24, if I understand correctly). Ray packets, as described in Wald's paper linked above, might help as well. Simon Marlow wrote: > There's definitely a bug here, regardless of whether this example > demonstrates it. Use of par shouldn't introduce a space leak, and > currently it can. > > (fortunately I'm fixing it as we speak...) > > Cheers, > Simon Oh, good. -jim From haskell at brecknell.org Wed Apr 23 22:13:15 2008 From: haskell at brecknell.org (Matthew Brecknell) Date: Wed Apr 23 22:08:02 2008 Subject: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <2f9b2d30804231715t7cc9736q1494a71bf73d7e27@mail.gmail.com> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> <2F436402-5EB7-45A9-A29F-78C43081D64C@alum.mit.edu> <2f9b2d30804231212l5ca01e7ctd2261e8e396bec40@mail.gmail.com> <20080423192555.GF8763@darcs.net> <2f9b2d30804231346y685820bdkb7f26defff1ee47b@mail.gmail.com> <9B48F789-4A32-43E6-BBCC-60A589926EC5@gmail.com> <2f9b2d30804231715t7cc9736q1494a71bf73d7e27@mail.gmail.com> Message-ID: <1209003195.724.1249577729@webmail.messagingengine.com> Ryan Ingram said: > So, if have a transaction T that is waiting inside "retry" for a > variable that it read to change, and a variable that is only accessed > in a "subatomic" part of T is changed, we can try running the > subatomic computation first. Here are the four cases: > > 1) The subatomic computation succeeded before and still succeeded. > Then we know the end result of the computation is unaffected, and will > still retry. No need to do anything. > 2) The subatomic computation succeeded before and now fails (calls > 'retry' or retryRO'). Then we know that the computation will now fail > at this earlier point. Mark the change to "fail" in the transaction > log and leave the computation in the "waiting for retry" state. > 3) The subatomic computation failed before and still fails. See (1) > 4) The subatomic computation failed before and now succeeds. The > result of the entire computation can change, we should now re-run the > entire computation. I'm trying to figure out whether subatomic could be weakened to allow writes as well as reads. I don't think this change would affect cases 2 to 4 above. But in case 1, the subatomic computation might perform a different set of writes, which might affect the outcome of the outer computation, so it is not safe to continue blocking. It's case 1 which makes retryUntil (and subatomic) stronger than readTVarWhen. If it's not possible to weaken subatomic to allow writes, without affecting case 1, then I think this also means that subatomic/retryUntil is stronger than the hypothetical "continuation-logging" implementation previously hinted at by David, apfelmus and myself (that is, one which treats each individual read as a kind of checkpoint, by recording the read's continuation in the transaction log, and using that continuation to restart the blocked transaction). Nevertheless, the distinction between read-only and read-write transactions does not necessarily have to occur at the level of types. STM is fundamentally a dynamic approach to concurrency control, so I think it would make sense for transactions to *dynamically* determine whether they are read-only or read-write, as they compose with each other. In that case, we can treat subatomic as a "hint" to the STM runtime. It could have a simpler type, and the semantics of "id": subatomic :: STM a -> STM a If the subatomic transaction turns out to be read-only, then we get the benefit of all four cases Ryan describes above. If it turns out to be read-write, we only get the benefit of cases 2 to 4, while case 1 must restart. It doesn't matter if the subatomic transaction captures variables which depend on previous reads, since changes to those reads would cause a restart regardless of the outcome of the subatomic transaction. Moreover, note that the hypothetical "continuation-logging" implementation could implement (m >>= k) by implicitly wrapping every m in a call to subatomic. Of course, that would require a lot of speculative book-keeping. I think this means that subatomic is not a fundamental abstraction, but could be a useful pragmatic optimisation. From haskell at brecknell.org Wed Apr 23 22:28:38 2008 From: haskell at brecknell.org (Matthew Brecknell) Date: Wed Apr 23 22:23:26 2008 Subject: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <1209003195.724.1249577729@webmail.messagingengine.com> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> <2F436402-5EB7-45A9-A29F-78C43081D64C@alum.mit.edu> <2f9b2d30804231212l5ca01e7ctd2261e8e396bec40@mail.gmail.com> <20080423192555.GF8763@darcs.net> <2f9b2d30804231346y685820bdkb7f26defff1ee47b@mail.gmail.com> <9B48F789-4A32-43E6-BBCC-60A589926EC5@gmail.com> <2f9b2d30804231715t7cc9736q1494a71bf73d7e27@mail.gmail.com> <1209003195.724.1249577729@webmail.messagingengine.com> Message-ID: <1209004118.3223.1249579447@webmail.messagingengine.com> I said: > In that case, we can treat subatomic as a "hint" to the STM runtime. It > could have a simpler type, and the semantics of "id": > > subatomic :: STM a -> STM a > > If the subatomic transaction turns out to be read-only, then we get the > benefit of all four cases Ryan describes above. If it turns out to be > read-write, we only get the benefit of cases 2 to 4, while case 1 must > restart. It doesn't matter if the subatomic transaction captures > variables which depend on previous reads, since changes to those reads > would cause a restart regardless of the outcome of the subatomic > transaction. Scrap that. I realise now that it allows leakage of information read from variables. It would need to be: subatomic :: STM a -> STM () Which means it's no longer just a hint. From graham.fawcett at gmail.com Thu Apr 24 00:44:25 2008 From: graham.fawcett at gmail.com (Graham Fawcett) Date: Thu Apr 24 00:39:12 2008 Subject: [Haskell-cafe] searching via zipper over a tree Message-ID: Hi folks, I'm studying zippers (and by extension, the State monad), and have written a function for finding the first node-location in a 'zippered' tree that satisfies a predicate: http://paste.lisp.org/display/59636 (The code uses Krasimir Angelov's Data.Tree.Zipper.) My code works, but I suspect that I'm working too hard. I would appreciate any comments! Regards, Graham From ketil at malde.org Thu Apr 24 02:31:54 2008 From: ketil at malde.org (Ketil Malde) Date: Thu Apr 24 02:26:32 2008 Subject: [Haskell-cafe] lookup tables & style guidelines In-Reply-To: <20080423203634.GG22492@scytale.galois.com> (Don Stewart's message of "Wed\, 23 Apr 2008 13\:36\:34 -0700") References: <1ff5dedc0804231334y1a14f93cobf6b97da93285728@mail.gmail.com> <20080423203634.GG22492@scytale.galois.com> Message-ID: <87r6cvzrtx.fsf@nmd9999.imr.no> Don Stewart writes: >> 1) what is the most performant lookup table/hashtable/dictionary solution >> for Haskell? > Data.IntMap is awfully good. Is it benchmarked anywhere? Compared to the Judy bindings, or Adrian Hey's AVL trees, or Data.Hashtable? I rewrote (roughly) a Python program in Haskell, and it was my impression back then that Python's associative arrays was faster than Haskell maps - but this could well have been back in the FiniteMap days, and I don't think I benchmarked very precisely. Anyway, there's a Google Summer-of-code project that will hopefully produce some benchmarks of the different alternatives. Data.Map tends to consume a lot of memory as well. But - Data.(Int)Map is likely to be the easiest available - I'd try that first, and if things are still too slow, profile, and then look for alternatives. -k -- If I haven't seen further, it is by standing in the footprints of giants From allbery at ece.cmu.edu Thu Apr 24 03:59:32 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Apr 24 03:54:21 2008 Subject: [Haskell-cafe] lookup tables & style guidelines In-Reply-To: <87r6cvzrtx.fsf@nmd9999.imr.no> References: <1ff5dedc0804231334y1a14f93cobf6b97da93285728@mail.gmail.com> <20080423203634.GG22492@scytale.galois.com> <87r6cvzrtx.fsf@nmd9999.imr.no> Message-ID: On Apr 24, 2008, at 2:31 , Ketil Malde wrote: > Don Stewart writes: > >>> 1) what is the most performant lookup table/hashtable/ >>> dictionary solution >>> for Haskell? > >> Data.IntMap is awfully good. > > Is it benchmarked anywhere? Compared to the Judy bindings, or Adrian > Hey's AVL trees, or Data.Hashtable? I don't know if anyone has benched them recently, but some time back there was a comparison of Data.HashTable, Data.Map, and Data.IntMap posted to one of the Haskell lists; HashTable was usually the slowest, and IntMap the fastest because it could take advantage of optimizations due to the key being a specific type (among other things, IIRC it's unboxed). This also reduces the memory usage compared to the more general Data.Map. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From lemming at henning-thielemann.de Thu Apr 24 04:21:36 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Apr 24 04:15:15 2008 Subject: [Haskell-cafe] Re: [Haskell] How to define tail function for Even/Odd GADT lists? In-Reply-To: <5ab17e790804231655t591422e4j59c610ddb0703d08@mail.gmail.com> References: <480F9D02.3090406@gmail.com> <480FC566.8020104@cs.uu.nl> <117f2cc80804231646x426cc01fy592f562f23cba641@mail.gmail.com> <5ab17e790804231655t591422e4j59c610ddb0703d08@mail.gmail.com> Message-ID: On Wed, 23 Apr 2008, Iavor Diatchki wrote: > Hello, > I am not sure of the use case here but you could also do the following: > > data EvenList a = Nil > | ConsE a (OddList a) > > data OddList a = ConsO a (EvenList a) Or just use: http://darcs.haskell.org/event-list/src/Data/AlternatingList/List/ From lrpalmer at gmail.com Thu Apr 24 04:37:15 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Apr 24 04:32:01 2008 Subject: [Haskell-cafe] mapM vs mapM_ performance In-Reply-To: <9157df230804221032q3a19bf15u7f1f6d522511d935@mail.gmail.com> References: <9157df230804221032q3a19bf15u7f1f6d522511d935@mail.gmail.com> Message-ID: <7ca3f0160804240137p21326b81rae144ca264925873@mail.gmail.com> On Tue, Apr 22, 2008 at 11:32 AM, Ben wrote: > Hello Haskellers, > > I'm running ghc 6.8.2 on vista 64. Consider the following program, > which is compiled with -02 -prof -auto-all: > > module Main where > > import System.IO (openFile, IOMode(..), hPutStr) > > testlst = let ls = [(i, [(j, (fromIntegral j)::Float) | j <- > [1..5]::[Int]]) | i <- [1..500000]::[Int]] > in ls > > main2 = do > h <- openFile "bardump" WriteMode > mapM_ ((hPutStr h) . show) testlst > > > main = do > h <- openFile "bardump2" WriteMode > mapM ((hPutStr h) . show) testlst > return () > > main and main2 are different in only that mapM_ versus mapM_ are used. > But the mapM version runs about 20x slower! I'm running with +RTS -p > -hc -RTS and I see that the amount of memory allocated is about the > same, and I think the resident memory is about the same too. But the > mapM_ version runs in about 8.7 seconds, and the mapM version takes > 167 seconds. My first guess is that the garbage collector is not running at all in the mapM_ version, but is working it's ass off in the mapM version cleaning up the list that will never be used. > You may ask, why use mapM if you're discarding the values? > Unfortunately in my real app I need the values, which are more > interesting than IO (). If you need the values, then you've got to pay that price I suppose. If you need the values, I'm going to take a stab that in your real app you use a lot of memory because of this (because presumably you're keeping the values around), whereas you're just seeing a speed hit on this small test program. Luke From fmartini at gmail.com Thu Apr 24 04:46:45 2008 From: fmartini at gmail.com (Felix Martini) Date: Thu Apr 24 04:41:32 2008 Subject: [Haskell-cafe] lookup tables & style guidelines In-Reply-To: <1ff5dedc0804231334y1a14f93cobf6b97da93285728@mail.gmail.com> References: <1ff5dedc0804231334y1a14f93cobf6b97da93285728@mail.gmail.com> Message-ID: <6c0416190804240146w73ec6e9fmfdb3eb7d0d3f2407@mail.gmail.com> What are good options for concurrent dictionaries? A while ago i wrote a concurrent hash table prototype, but there are probably better solutions for Haskell. Regards, Felix From lrpalmer at gmail.com Thu Apr 24 05:08:52 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Apr 24 05:03:38 2008 Subject: [Haskell-cafe] functional update In-Reply-To: References: <2518b95d0804211112k1eae26d2j6fa0a5befd4c772@mail.gmail.com> <2f9b2d30804211643p29a8c685g92233f8a69bef03c@mail.gmail.com> Message-ID: <7ca3f0160804240208j6a5792e9i23309a1d6e5aa34a@mail.gmail.com> On Tue, Apr 22, 2008 at 6:26 AM, Henning Thielemann wrote: > On Mon, 21 Apr 2008, Ryan Ingram wrote: > > I recommend this blog entry: > > > http://twan.home.fmf.nl/blog/haskell/overloading-functional-references.details > > > > along with a few additional combinators for imperative update: > > > > data FRef s a = FRef > > { frGet :: s -> a > > , frSet :: a -> s -> s > > } > > > > http://darcs.haskell.org/record-access/src/Data/Accessor.hs > http://darcs.haskell.org/record-access/src/Data/Accessor/Example.hs > > I should upload this to Hackage, I know ... Not to toot my own horn, but there's already something like this on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/data-accessor-0.0.1 Which has template haskell routines for generating accessors for record types also. Luke From cetintozkoparan at yahoo.com Thu Apr 24 05:29:05 2008 From: cetintozkoparan at yahoo.com (cetin tozkoparan) Date: Thu Apr 24 05:23:51 2008 Subject: [Haskell-cafe] Fw: I have a problem Message-ID: <879714.68341.qm@web62205.mail.re1.yahoo.com> I have a problem which i can'tsolve. Is there any one who has an idea? Two lists is sent as parameter to a function. If second list contains first list, return true, else return false. This comparision must be in order of first list. You can look at examples. function type as follows: sublist:: [a] -> [a] -> Bool examples: For instance [2,4,5]list is sub list of [3,7,2,4,5,9] list but not of[3,7,4,2,5,9] list. sublist [2,8][1,5,6,2,4,7,8,2] False sublist [1,2,3][0,1,2,3,4,5,6] True sublist [5,4] [1,4,5,7,8,3,5,4] True sublist [1,2,4,3,4,5,7,8,9,5] [8,2,3,1,2,4,3,4,5,7,8,9,5,1,6,2] True ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080424/ca2c5452/attachment.htm From tom.davie at gmail.com Thu Apr 24 05:50:52 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Thu Apr 24 05:45:46 2008 Subject: [Haskell-cafe] Fw: I have a problem In-Reply-To: <879714.68341.qm@web62205.mail.re1.yahoo.com> References: <879714.68341.qm@web62205.mail.re1.yahoo.com> Message-ID: <3E1A692A-663E-4102-A1AB-CF675542E757@gmail.com> First, I'd refer you to this list's rules on homework, and what people will or won't answer. Secondly to that though, rather than provide a solution, I'll give you an idea that may lead to you coming up with a solution. First, try and write a function that can test if your first list is at the start of the second list: > startlist [2,3] [2,3,4,5] True > startlist [2,3] [1,2,3,4] False Then use this function to write your sublist function. Hope that helps Tom Davie On 24 Apr 2008, at 10:29, cetin tozkoparan wrote: > I have a problem which i can't solve. Is there any one who has an > idea? > Two lists is sent as parameter to a function. If second list > contains first list, return true, else return false. This > comparision must be in order of first list. You can look at examples. > > > function type as follows: > > sublist:: [a] -> [a] -> Bool > > > examples: > > > For instance [2,4,5] list is sub list of [3,7,2,4,5,9] list but not > of [3,7,4,2,5,9] list. > > > sublist [2,8] [1,5,6,2,4,7,8,2] > False > > sublist [1,2,3] [0,1,2,3,4,5,6] > True > sublist [5,4] [1,4,5,7,8,3,5,4] > True > sublist [1,2,4,3,4,5,7,8,9,5] [8,2,3,1,2,4,3,4,5,7,8,9,5,1,6,2] > True > > > > > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. > Try it now._______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From apfelmus at quantentunnel.de Thu Apr 24 06:57:56 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Thu Apr 24 06:52:57 2008 Subject: [Haskell-cafe] Re: Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <20080423210936.GM8763@darcs.net> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> <2F436402-5EB7-45A9-A29F-78C43081D64C@alum.mit.edu> <2f9b2d30804231212l5ca01e7ctd2261e8e396bec40@mail.gmail.com> <20080423192555.GF8763@darcs.net> <2f9b2d30804231346y685820bdkb7f26defff1ee47b@mail.gmail.com> <20080423210936.GM8763@darcs.net> Message-ID: David Roundy wrote: > A simple primitive to do this (in combination with a totally > rewritten STM runtime) would be > > subatomically :: ReadOnlySTM a -> STM () > > which would run a STM computation that is guaranteed to have no > side-effects (i.e. can't write to TVars) and ignore its results (and > let the runtime know that the results have been ignored). Matthew Brecknell wrote: > Nevertheless, the distinction between read-only and read-write > transactions does not necessarily have to occur at the level of > types. STM is fundamentally a dynamic approach to concurrency > control, so I think it would make sense for transactions to > *dynamically* determine whether they are read-only or read-write, as > they compose with each other. > > In that case, we can treat subatomic as a "hint" to the STM runtime. > > subatomic :: STM a -> STM () Concerning this question of whether the argument to subatomic should statically or dynamically be known to be read-only, there is also the option of collapsing ReadOnlySTM a and STM a by changing the semantics of writeTVar . I mean, writeTVar can be used for two different things: 1) communicate with other threads, i.e. crossing atomically boundaries 2) communicating inside a single thread/STM action ? la mutable state (IORef). We only want 1), but 2) is expendable, we can always use parameters to pass state around or wrap the whole thing into a state monad. For 1), it's enough to have a primitive scheduleWriteTVar :: TVar a -> a -> STM () that ensures to write the TVar at the very end of the atomically block. (This is similar to scheduleIO :: IO a -> STM ()). In other words, the current STM semantics can be implemented in terms of ReadOnlySTM assuming that the latter has such a primitive for scheduling. type ReadOnlySTM a = StateT TVarEnvironment STM a Regards, apfelmus From apfelmus at quantentunnel.de Thu Apr 24 07:02:35 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Thu Apr 24 06:59:53 2008 Subject: [Haskell-cafe] Re: Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <2f9b2d30804231715t7cc9736q1494a71bf73d7e27@mail.gmail.com> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> <2F436402-5EB7-45A9-A29F-78C43081D64C@alum.mit.edu> <2f9b2d30804231212l5ca01e7ctd2261e8e396bec40@mail.gmail.com> <20080423192555.GF8763@darcs.net> <2f9b2d30804231346y685820bdkb7f26defff1ee47b@mail.gmail.com> <9B48F789-4A32-43E6-BBCC-60A589926EC5@gmail.com> <2f9b2d30804231715t7cc9736q1494a71bf73d7e27@mail.gmail.com> Message-ID: Ryan Ingram wrote: > No spooky-action-at-a-distance is possible. David's more general > "subatomically" primitive would achieve the same results; the proof is > that > (1) no side effects can be caused by the subatomic action, that is, no > writes happen which could change future reads. > (2) the result of the computation is ignored -except- for whether it > retries or returns, that is, it can't affect the control flow of the > rest of the transaction. > > So, if have a transaction T that is waiting inside "retry" for a > variable that it read to change, and a variable that is only accessed > in a "subatomic" part of T is changed, we can try running the > subatomic computation first. Here are the four cases: > > 1) The subatomic computation succeeded before and still succeeded. > Then we know the end result of the computation is unaffected, and will > still retry. No need to do anything. > 2) The subatomic computation succeeded before and now fails (calls > 'retry' or retryRO'). Then we know that the computation will now fail > at this earlier point. Mark the change to "fail" in the transaction > log and leave the computation in the "waiting for retry" state. > 3) The subatomic computation failed before and still fails. See (1) > 4) The subatomic computation failed before and now succeeds. The > result of the entire computation can change, we should now re-run the > entire computation. Sounds good. But I wonder what "obscure" optimization comes next; can we have a toy-model of STM? I mean, it should be possible to express both the "continuation-logging" and "read-only-fail" optimization in terms of type STM a = Maybe a or similar? Regards, apfelmus From lemming at henning-thielemann.de Thu Apr 24 08:07:52 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Apr 24 08:01:17 2008 Subject: [Haskell-cafe] Infix search (Was: I have a problem) In-Reply-To: <879714.68341.qm@web62205.mail.re1.yahoo.com> References: <879714.68341.qm@web62205.mail.re1.yahoo.com> Message-ID: On Thu, 24 Apr 2008, cetin tozkoparan wrote: > I have a problem which i can'tsolve. Is there any one who has an idea? > Two lists is sent as parameter to > a function. If second list contains first list, return true, else > return false. This comparision must be in order of first list. You can look at > examples. > > function type as follows: > sublist:: [a] -> [a] -> Bool try 'List.tails' and 'List.isPrefixOf' From cdsmith at twu.net Thu Apr 24 09:32:59 2008 From: cdsmith at twu.net (Chris Smith) Date: Thu Apr 24 09:28:01 2008 Subject: [Haskell-cafe] Re: Stronger STM primitives needed? Or am I just doing it wrong? References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> <2F436402-5EB7-45A9-A29F-78C43081D64C@alum.mit.edu> <2f9b2d30804231212l5ca01e7ctd2261e8e396bec40@mail.gmail.com> <20080423192555.GF8763@darcs.net> <2f9b2d30804231346y685820bdkb7f26defff1ee47b@mail.gmail.com> <20080423210936.GM8763@darcs.net> Message-ID: On Thu, 24 Apr 2008 12:57:56 +0200, apfelmus wrote: > there is also the option of collapsing ReadOnlySTM a and STM a > by changing the semantics of writeTVar . > > I mean, writeTVar can be used for two different things: > > 1) communicate with other threads, i.e. crossing > atomically boundaries > 2) communicating inside a single thread/STM action > ? la mutable state (IORef). > > We only want 1), but 2) is expendable, we can always use parameters to > pass state around or wrap the whole thing into a state monad. For 1), > it's enough to have a primitive > > scheduleWriteTVar :: TVar a -> a -> STM () > > that ensures to write the TVar at the very end of the atomically block. Unfortunately, though, this breaks the very thing that makes STM attractive: namely, composability. Now in order to work with a TVar, I need to know whether anything that came before me might have modified it, and if so take the current value as a parameter instead of reading it like normal. Or am I misunderstanding something? -- Chris Smith From voigt at tcs.inf.tu-dresden.de Thu Apr 24 10:01:36 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Thu Apr 24 09:55:34 2008 Subject: [Haskell-cafe] Call for Contributions - Haskell Communities and Activities Report, May 2008 edition Message-ID: <481092C0.1030904@tcs.inf.tu-dresden.de> Dear Haskellers, so much has happened in the Haskell world in the past months. Therefore, we would very much like to collect contributions for the 14th edition of the ================================================================ Haskell Communities & Activities Report http://www.haskell.org/communities/ Submission deadline: 10 May 2008 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format) ================================================================ This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it to the us. Even if the project is very small or unfinished or you think it is not important enough -- please reconsider and submit an entry anyway! * If you are interested in any project related to Haskell that has not previously been mentioned in the HC&A Report, please tell us, so that we can contact the project leaders and ask them to submit an entry. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities & Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming 6 months. If you have only recently been exposed to Haskell, it might be a good idea to browse the December 2007 edition -- you will find interesting topics described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! As the purpose of the report is to collect recent or current activities, we encourage you to update all existing summaries and reports. We will probably drop any topics that have not had any activity for the past year, i.e., since May 2007, but we would very much prefer you to present an updated description of the topic. Of course, new entries are more than welcome. Reports should generally be kept brief and informative, ranging from a few sentences to a few hundred words, to keep the whole report reasonably sized. Looking forward to your contributions, Andres and Janis (current editors) FAQ: Q: Which topics are relevant? A: *All* topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports over distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we don't even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also ask the editors. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. You can use it to write ``wishlist'' items for libraries and language features you would like to see implemented. Q: How much should I write? A: There's no formal limit. But generally, entries should be short and to the point. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. There also is no minimum length of an entry! The report aims at being as complete as possible, so please consider writing an entry, even if it's only a few lines long. Q: If I don't update my entry, but want to keep it in the report, what should I do? A: Tell us that there are no changes. We will reuse the old entry in this case, but we might drop it if it's older than a year, to give more room and more attention to projects that change a lot. Don't resent complete entries if you haven't changed them. Q: What format should I write in? A: The best format is a LaTeX source file, adhering to the template that's available at: http://haskell.org/communities/05-2008/template.tex There's also a LaTeX style file at http://haskell.org/communities/05-2008/hcar.sty that you can use to preview your entry. If you don't know LaTeX, then use plain text. If you modify an old entry, we will send you your old entry as a template within the next hours (provided we have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. Don't worry about writing correct LaTeX, we will be able to handle your file. Please don't use HTML or even DOC. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From ahey at iee.org Thu Apr 24 11:33:55 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Apr 24 11:28:42 2008 Subject: [Haskell-cafe] lookup tables & style guidelines In-Reply-To: <87r6cvzrtx.fsf@nmd9999.imr.no> References: <1ff5dedc0804231334y1a14f93cobf6b97da93285728@mail.gmail.com> <20080423203634.GG22492@scytale.galois.com> <87r6cvzrtx.fsf@nmd9999.imr.no> Message-ID: <4810A863.4010703@iee.org> Ketil Malde wrote: > Don Stewart writes: > >>> 1) what is the most performant lookup table/hashtable/dictionary solution >>> for Haskell? > >> Data.IntMap is awfully good. > > Is it benchmarked anywhere? Compared to the Judy bindings, or Adrian > Hey's AVL trees, or Data.Hashtable? I must get around to putting the AVL clones of Data.Map/Set in Hackage sometime. Meanwhile anyone wanting to roll their own maps with an API of their chosing could do a lot worse than the raw AVL lib.. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/AvlTree-3.1 Also, if you're likely to be using union/intersection a lot you should know that Data.Map/Set are very slow for this because they use the not efficient hedge algorithm :-) There's a really cool demo I found from wikipedia that shows why it is that AVL trees perform so well in the "pathological" situation of sorted insertions.. http://www.csi.uottawa.ca/~stan/csi2514/applets/avl/BT.html If you try it you can see that after 2^n-1 sorted insertions you always get a perfectly balanced tree. This explains these benchmark results.. http://groups.google.co.uk/group/comp.lang.functional/msg/74a422ea04ff1217 DData is what became Data.Map/Set and it would appear to be the worst performing of the four tree types tested there :-( Don is right about Data.IntMap/IntSet. For Ints it will be much faster than Data.Map/Set or even (polymorphic) AVL tree. But an AVL tree of unboxed Ints gives faster lookup than IntMap/Set and about the same insert/delete times.. http://www.haskell.org/pipermail/libraries/2005-October/004518.html Union and Intersection times for AVL aren't so great, but I think I know what to do about that (especially intersection). But the real way ahead has to be Tries for non-trivial keys and (I suspect) AVL trees of unboxed Ints for simple keys (serialisable as 1 machine word). This is what that GSoC project is all about. At the moment we have the exact opposite, Tries for Ints and balanced trees for non-trivial keys. Oh well.. Regards -- Adrian Hey From clawsie at fastmail.fm Thu Apr 24 12:01:51 2008 From: clawsie at fastmail.fm (brad clawsie) Date: Thu Apr 24 11:56:48 2008 Subject: [Haskell-cafe] curl binding examples? Message-ID: <86bq3z1btc.fsf@jobbicycle.corp.yahoo.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 i was once given this snippet with reference to an earlier incarnation of the curl bindings: http://hpaste.org/3529 my guess is that this is no longer accurate documentation (?) anything that could be provided in the way of examples would be nice, i have placed a stub here: http://haskell.org/haskellwiki/Network.Curl it would be nice of people inlined small examples directly into the haddock docs for libraries. putting a minimal "hello world" example illustrating the basics of a library would preclude 90% of the followup questions on lists and irc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkgQrvMACgkQxRg3RkRK91NuEQCfUdInLYcjioLRsHfYGkwMW2Dp jI8An3uEuuF/aaXimZwhweJJ4zGz3CsY =qs80 -----END PGP SIGNATURE----- From graham.fawcett at gmail.com Thu Apr 24 12:02:51 2008 From: graham.fawcett at gmail.com (Graham Fawcett) Date: Thu Apr 24 11:57:37 2008 Subject: [Haskell-cafe] Re: searching via zipper over a tree In-Reply-To: References: Message-ID: On Thu, Apr 24, 2008 at 12:44 AM, Graham Fawcett wrote: > I'm studying zippers (and by extension, the State monad), and have > written a function for finding the first node-location in a 'zippered' > tree that satisfies a predicate: > > http://paste.lisp.org/display/59636 > > (The code uses Krasimir Angelov's Data.Tree.Zipper.) My code works, > but I suspect that I'm working too hard. I would appreciate any > comments! I did figure out an easier way: lazily walk every location in the tree, and take the first matching location. http://paste.lisp.org/display/59636#1 Much cleaner (though comments are still welcome.) Haskell seems to have a high 'commute factor' -- many solutions appear not at the keyboard, but while driving home... Graham From apfelmus at quantentunnel.de Thu Apr 24 12:43:07 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Thu Apr 24 12:38:12 2008 Subject: [Haskell-cafe] Re: Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> <2F436402-5EB7-45A9-A29F-78C43081D64C@alum.mit.edu> <2f9b2d30804231212l5ca01e7ctd2261e8e396bec40@mail.gmail.com> <20080423192555.GF8763@darcs.net> <2f9b2d30804231346y685820bdkb7f26defff1ee47b@mail.gmail.com> <20080423210936.GM8763@darcs.net> Message-ID: Chris Smith wrote: > apfelmus wrote: >> For 1), it's enough to have a primitive >> >> scheduleWriteTVar :: TVar a -> a -> STM () >> >> that ensures to write the TVar at the very end of the atomically block.. > > Unfortunately, though, this breaks the very thing that makes STM > attractive: namely, composability. Now in order to work with a TVar, I > need to know whether anything that came before me might have modified it, > and if so take the current value as a parameter instead of reading it > like normal. > > Or am I misunderstanding something? You're correct, that's what I meant. But it's nothing more and nothing less than the purely functional way of dealing with "mutable" state, isn't it? And you need a parameter anyway, namely the TVar a itself. I mean, when it's in scope like in do a <- readTVar v writeTVar v (a+1) readTVar v you don't need a parameter. But if the do-block is broken up into functions, you need a parameter foo v = do a <- readTVar v writeTVar v (a+1) bar v bar v = readTVar v and you may as well supply its value instead of the reference v . Regards, apfelmus From dons at galois.com Thu Apr 24 13:12:15 2008 From: dons at galois.com (Don Stewart) Date: Thu Apr 24 13:07:06 2008 Subject: [Haskell-cafe] curl binding examples? In-Reply-To: <86bq3z1btc.fsf@jobbicycle.corp.yahoo.com> References: <86bq3z1btc.fsf@jobbicycle.corp.yahoo.com> Message-ID: <20080424171215.GA32028@scytale.galois.com> clawsie: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > i was once given this snippet with reference to an earlier incarnation > of the curl bindings: > > http://hpaste.org/3529 > > my guess is that this is no longer accurate documentation (?) > > anything that could be provided in the way of examples would be nice, > i have placed a stub here: > > http://haskell.org/haskellwiki/Network.Curl > > it would be nice of people inlined small examples directly into the > haddock docs for libraries. putting a minimal "hello world" example > illustrating the basics of a library would preclude 90% of the > followup questions on lists and irc. Thanks for doing this, I'll see what I can dig up. From s.clover at gmail.com Thu Apr 24 14:06:27 2008 From: s.clover at gmail.com (Sterling Clover) Date: Thu Apr 24 14:01:15 2008 Subject: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: <2f9b2d30804231715t7cc9736q1494a71bf73d7e27@mail.gmail.com> References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> <2F436402-5EB7-45A9-A29F-78C43081D64C@alum.mit.edu> <2f9b2d30804231212l5ca01e7ctd2261e8e396bec40@mail.gmail.com> <20080423192555.GF8763@darcs.net> <2f9b2d30804231346y685820bdkb7f26defff1ee47b@mail.gmail.com> <9B48F789-4A32-43E6-BBCC-60A589926EC5@gmail.com> <2f9b2d30804231715t7cc9736q1494a71bf73d7e27@mail.gmail.com> Message-ID: > broken2 = atomically $ do > (v1, v2) <- expensive_computation :: STM (TVar Int, TVar Int) > retryUntil v1 (> 50) > x <- expensive_computation2 :: STM Int > retryUntil v2 (> x) Ah. I think I see now. I had thought you were trying to give more power to the primitive than you are. But I'm still finding the example confusing, in that expensive_computation2 is in STM, and thus isn't pure. The point, I suppose, would rather be to assert that retryUntil v2 (> x) depends on what v2 depends on, and what x depends on, but *not* on what v1 depends on, and thus to retry only when the appropriate portion of the dependency tree changed. However, in this case, that still doesn't buy you anything, I think, because from the information given, one can't disentangle what v1 and v2 depend on? I hope I'm somewhat closer to the mark here. --S On 4/23/08, Ryan Ingram wrote: > > On 4/23/08, Sterling Clover wrote: > > But expensive_computation2 is in STM. This means that it *should* be > rerun, > > no? Between the first run and the retry, the result of > > expensive_computation2 may well have changed. > > Ah, but that's not true; the main "good thing" about retry is that you > don't have to keep running the computation; instead you wait until > something that you accessed in your transaction log changes and -then- > you rerun it. Right now the transaction log for "retry" only contains > "read from variable X" (for some list of variables). But it could > instead contain "read from variable X" and "read from variable X using > retryUntil with predicate p which gave result True". Then we have a > "smarter" log which can use the pure predicate p to give more > information about whether or not the whole transaction can run or > whether it is just guaranteed to fail again. If we know a transaction > is guaranteed to fail, we can skip running it because we know it will > not commit. > > Given the semantics of retryUntil, it is impossible that changing v1 > affects the results of running this STM computation -unless- it or > something else prior in the computation read from v1, or the result of > the predicate changes. > > No spooky-action-at-a-distance is possible. David's more general > "subatomically" primitive would achieve the same results; the proof is > that > (1) no side effects can be caused by the subatomic action, that is, no > writes happen which could change future reads. > (2) the result of the computation is ignored -except- for whether it > retries or returns, that is, it can't affect the control flow of the > rest of the transaction. > > So, if have a transaction T that is waiting inside "retry" for a > variable that it read to change, and a variable that is only accessed > in a "subatomic" part of T is changed, we can try running the > subatomic computation first. Here are the four cases: > > 1) The subatomic computation succeeded before and still succeeded. > Then we know the end result of the computation is unaffected, and will > still retry. No need to do anything. > 2) The subatomic computation succeeded before and now fails (calls > 'retry' or retryRO'). Then we know that the computation will now fail > at this earlier point. Mark the change to "fail" in the transaction > log and leave the computation in the "waiting for retry" state. > 3) The subatomic computation failed before and still fails. See (1) > 4) The subatomic computation failed before and now succeeds. The > result of the entire computation can change, we should now re-run the > entire computation. > > -- ryan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080424/4a70c561/attachment.htm From andrewcoppin at btinternet.com Thu Apr 24 15:29:50 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Apr 24 15:24:15 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <480FCD87.7010803@cs.pdx.edu> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> <4310375315.20080419001919@gmail.com> <20080418203222.GQ8763@darcs.net> <48090E08.1020109@cs.pdx.edu> <20080418213405.GT8763@darcs.net> <1208968967.5538.22.camel@derek-laptop> <480FCD87.7010803@cs.pdx.edu> Message-ID: <4810DFAE.8040807@btinternet.com> Jim Snow wrote: > Those are good links. It's good to see that the groups of people who > know about Haskell and people who know about ray tracing do, in fact, > overlap. > > Background information for everyone else: Wald's work is related to > OpenRT, which is an OpenGL-like api for interactive ray tracing > (despite the name, it is not, in fact, open source). OpenRT makes for > stiff competition. Arauna (http://igad.nhtv.nl/~bikker/) is very > impressive, as well. On the other end of the spectrum, there's > POV-Ray, which isn't known for its speed, but it is very flexible in > the kinds of things it can render and can generate some fairly > realistic images. Unlike most real-time ray tracers, which only > render triangles, POV-Ray can render native representations of > spheres, cones, toruses, heightfields, julia fractals, and a few dozen > other kinds of primitives. Pbrt (http://www.pbrt.org/) is another > renderer, more modern than POV-Ray, that focuses more on output > quality than speed. Wow. The POV-Ray guys are talking about Haskell [or rather, my personal addiction to it] and the Haskell guys are talking about POV-Ray... on the same day... How unlikely is that? ;-) I've been using POV-Ray for a long time. I like it for several reasons: 1. It's the only program I've ever seen [on a PC] that does ray tracing. [I'm sure there must be others...] 2. It's the only program I've seen that can render *real* curves, not fake trickery with triangle meshes. 3. It can render *arbitrary* mathematical surfaces. Want to render a 3D slice of the 4D cubic Mandelbrot set? No problem! 4. It has a novel "scene description language", which does far more than describe scenes. It's Turing-complete, and you can build physics engines with it. [It's painfully slow though!] Basically, as a maths addict, POV-Ray appeals to me. However, there are problems... The scene description language is basically a macro expansion language, and is chronically poor in data types and control structures. (The worst thing about Haskell is that IT MAKES YOU HATE NORMAL LANGUAGES!) Preserving complex scene state from frame to frame in an animation is notoriously tedious to code. Certain features are accessed in unintuitive ways to avoid breaking backwards compatibility. Overall, you tend to spend a lot of time saying which effects to simulate. [Not all of them matter for a given scene, so some can be left out - thus saving on speed!] I dislike such "clutter". For no objective reason. The POV-Ray team is currently working on the first multi-threaded version. [After years of saying it would never happen.] It's taking a while. (That's partly because the developers take product quality very seriously.) It should be interesting when it's done, but it's still taking a while. Personally, I'd quite like to write my own ray tracer to address some of these limitations. But every time I try, I end up hitting design issues [Haskell works very differently to Java] or performance issues [which I don't even know how to begin debugging]. Not to mention that POV-Ray uses sophisticated techniques like volume bounding that I know nothing about. (There's nothing like using an inherantly superior algorithm to make your code orders of magnitude faster...) > Simon Marlow wrote: >> There's definitely a bug here, regardless of whether this example >> demonstrates it. Use of par shouldn't introduce a space leak, and >> currently it can. >> >> (fortunately I'm fixing it as we speak...) >> >> Cheers, >> Simon > Oh, good. Indeed - yay for Simon! From qdunkan at gmail.com Thu Apr 24 16:05:28 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Thu Apr 24 16:00:16 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <480FCD87.7010803@cs.pdx.edu> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> <4310375315.20080419001919@gmail.com> <20080418203222.GQ8763@darcs.net> <48090E08.1020109@cs.pdx.edu> <20080418213405.GT8763@darcs.net> <1208968967.5538.22.camel@derek-laptop> <480FCD87.7010803@cs.pdx.edu> Message-ID: <2518b95d0804241305s53667e7xfcab9c3f0beb8ba4@mail.gmail.com> > I've ended up writing something more like POV-Ray than OpenRT, and that's > fine with me. I'd rather have something that's slower but more expressive > than fast but inflexible. (The former is also perhaps more easily > attainable, particularly in Haskell.) Not knowing anything about raytracing, one of the things I found interesting about the paper was that he claimed that the speedups were from using coherent ray packets, and that the shader model was orthogonal, and enough much is spent raycasting that the shader code to make much difference. The implication was that you could graft a packet style raycasting engine onto even povray and give it a nice speed boost... though you might have to lose the nifty "real" shapes to tessellated approximations. Is this accurate? True but reality is more complicated? From jon at ffconsultancy.com Thu Apr 24 16:39:46 2008 From: jon at ffconsultancy.com (Jon Harrop) Date: Thu Apr 24 16:41:13 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <4810DFAE.8040807@btinternet.com> References: <4807B6D1.7090006@cs.pdx.edu> <480FCD87.7010803@cs.pdx.edu> <4810DFAE.8040807@btinternet.com> Message-ID: <200804242139.46355.jon@ffconsultancy.com> On Thursday 24 April 2008 20:29:50 Andrew Coppin wrote: > 2. It's the only program I've seen that can render *real* curves, not > fake trickery with triangle meshes. What you called "fake trickery with triangle meshes" is the core of all modern computer graphics. Focussing on ray tracing instead of that is rather missing the point, IMHO. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e From midfield at gmail.com Thu Apr 24 17:14:17 2008 From: midfield at gmail.com (Ben) Date: Thu Apr 24 17:09:03 2008 Subject: a faster, accumulating mapM (was Re: [Haskell-cafe] mapM vs mapM_ performance) Message-ID: <9157df230804241414j6c92a01cuccf4b6416bf9f370@mail.gmail.com> Hello Luke and other Haskellers, Thanks for the reply, but as I noted before, the amount of memory allocated (and resident) is roughly the same. Anyhow it's definitely not a GC issue because I wrote an accumulating version of mapM and got close to mapM_ 's performance. In the code below, main1 is mapM_, main2 is the current mapM (basicallly sequence . map), map3 is a hand-coded accumulating parameter version, mapM2 is the accumulating parameter mapM and main4 uses mapM2. The timings I get are about 15, 175, 20 and 20 seconds for main1, main2, main3 and main4 respectively. main2 uses about 2% less memory than main3 or main4 on this particular run, though I don't know if that is true generally. Unless someone can see a reason why mapM2 is not as good as mapM, can I suggest replacing the implementation of mapM by the implementation of mapM2. A 10x speedup seems to be a bigger deal than GCing 2% more memory. best regards, Ben module Main where import System.IO (openFile, IOMode(..), hPutStr) testlst = let ls = [(i, [(j, (fromIntegral j)::Float) | j <- [1..5]::[Int]]) | i <- [1..500000]::[Int]] in ls main = do h <- openFile "bardump" WriteMode mapM_ ((hPutStr h) . show) testlst main2 = do h <- openFile "bardump2" WriteMode result <- mapM ((hPutStr h) . show) testlst print $ length result main3 = do h <- openFile "bardump3" WriteMode result <- dump h testlst [] print $ length result where dump h (x:xs) accum = do hPutStr h $ show x dump h xs $ ():accum dump _ [] accum = return accum mapM2 :: Monad m => (a -> m b) -> [a] -> m [b] {-# INLINE mapM2 #-} mapM2 fn lst = mapM2accum fn lst [] where mapM2accum _ [] accum = return accum mapM2accum fn (x:xs) accum = do r <- fn x mapM2accum fn xs (r:accum) main4 = do h <- openFile "bardump2" WriteMode result <- mapM2 ((hPutStr h) . show) testlst print $ length result On Thu, Apr 24, 2008 at 1:37 AM, Luke Palmer wrote: > On Tue, Apr 22, 2008 at 11:32 AM, Ben wrote: > > Hello Haskellers, > > > > I'm running ghc 6.8.2 on vista 64. Consider the following program, > > which is compiled with -02 -prof -auto-all: > > > > module Main where > > > > import System.IO (openFile, IOMode(..), hPutStr) > > > > testlst = let ls = [(i, [(j, (fromIntegral j)::Float) | j <- > > [1..5]::[Int]]) | i <- [1..500000]::[Int]] > > in ls > > > > main2 = do > > h <- openFile "bardump" WriteMode > > mapM_ ((hPutStr h) . show) testlst > > > > > > main = do > > h <- openFile "bardump2" WriteMode > > mapM ((hPutStr h) . show) testlst > > return () > > > > main and main2 are different in only that mapM_ versus mapM_ are used. > > But the mapM version runs about 20x slower! I'm running with +RTS -p > > -hc -RTS and I see that the amount of memory allocated is about the > > same, and I think the resident memory is about the same too. But the > > mapM_ version runs in about 8.7 seconds, and the mapM version takes > > 167 seconds. > > My first guess is that the garbage collector is not running at all in > the mapM_ version, but is working it's ass off in the mapM version > cleaning up the list that will never be used. > > > > You may ask, why use mapM if you're discarding the values? > > Unfortunately in my real app I need the values, which are more > > interesting than IO (). > > If you need the values, then you've got to pay that price I suppose. > If you need the values, I'm going to take a stab that in your real app > you use a lot of memory because of this (because presumably you're > keeping the values around), whereas you're just seeing a speed hit on > this small test program. > > Luke > From bulat.ziganshin at gmail.com Thu Apr 24 17:21:43 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Apr 24 17:20:19 2008 Subject: a faster, accumulating mapM (was Re: [Haskell-cafe] mapM vs mapM_ performance) In-Reply-To: <9157df230804241414j6c92a01cuccf4b6416bf9f370@mail.gmail.com> References: <9157df230804241414j6c92a01cuccf4b6416bf9f370@mail.gmail.com> Message-ID: <404665122.20080425012143@gmail.com> Hello Ben, Friday, April 25, 2008, 1:14:17 AM, you wrote: mapM2 :: Monad m =>> (a -> m b) -> [a] -> m [b] > {-# INLINE mapM2 #-} > mapM2 fn lst = mapM2accum fn lst [] > where mapM2accum _ [] accum = return accum > mapM2accum fn (x:xs) accum = do > r <- fn x > mapM2accum fn xs (r:accum) it seems you forget to reverse accum before returning it? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From niklas.broberg at gmail.com Thu Apr 24 17:25:39 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Apr 24 17:20:37 2008 Subject: a faster, accumulating mapM (was Re: [Haskell-cafe] mapM vs mapM_ performance) In-Reply-To: <9157df230804241414j6c92a01cuccf4b6416bf9f370@mail.gmail.com> References: <9157df230804241414j6c92a01cuccf4b6416bf9f370@mail.gmail.com> Message-ID: Hi Ben, > mapM2 :: Monad m => (a -> m b) -> [a] -> m [b] > {-# INLINE mapM2 #-} > mapM2 fn lst = mapM2accum fn lst [] > where mapM2accum _ [] accum = return accum > mapM2accum fn (x:xs) accum = do > r <- fn x > mapM2accum fn xs (r:accum) Not that it should matter for performance any, but you really ought to reverse the result list too, or compute the accumulator in the right order. :-) mapM2 :: Monad m => (a -> m b) -> [a] -> m [b] {-# INLINE mapM2 #-} mapM2 fn lst = mapM2accum fn lst id where mapM2accum _ [] accum = return $ accum [] mapM2accum fn (x:xs) accum = do r <- fn x mapM2accum fn xs (accum . (r:)) Cheers, /Niklas From bulat.ziganshin at gmail.com Thu Apr 24 17:33:50 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Apr 24 17:32:21 2008 Subject: a faster, accumulating mapM (was Re: [Haskell-cafe] mapM vs mapM_ performance) In-Reply-To: References: <9157df230804241414j6c92a01cuccf4b6416bf9f370@mail.gmail.com> Message-ID: <1953845415.20080425013350@gmail.com> Hello Niklas, Friday, April 25, 2008, 1:25:39 AM, you wrote: > Not that it should matter for performance any, but you really ought to > reverse the result list too, or compute the accumulator in the right > order. :-) unfortunately, this affects performance too. reverse costs one more scan through the list and building lot of thunks has its own space and time cost -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From coveney at wharton.upenn.edu Thu Apr 24 17:59:05 2008 From: coveney at wharton.upenn.edu (Jonathan Coveney) Date: Thu Apr 24 17:53:53 2008 Subject: [Haskell-cafe] Terminal manipulation in windows? Message-ID: <8aad69ae0804241459i791621c9ha99644f77c07ee0a@mail.gmail.com> I have a program that requires the user to be in raw mode. This doesn't seem to be an issue on linux, but in Windows, it's a bit tricky (System.Posix.Terminal isn't an option). Is there a possible way to set this in Haskell? Or even outside of Haskell? It doesn't appear cygwin has a raw mode. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080424/25bfae0d/attachment.htm From ryani.spam at gmail.com Thu Apr 24 19:10:21 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Apr 24 19:05:10 2008 Subject: [Haskell-cafe] Help me refactor this type! Message-ID: <2f9b2d30804241610h7511900cwdf9eda2e24fd02fa@mail.gmail.com> More FRP stuff: a new type for Future that came to me in an inspiration this morning. But it's ugly and I need someone with better theoretical underpinnings than me to tell me what I've really built :) data Future t a = Known t a | Unknown (t -> IO (STM (Maybe (Future t a)))) Given Eq t, Ord t, Bounded t, this type is at least member of Monad, Applicative, Functor, and MonadPlus/Monoid. But the derivation gives me that "needs refactoring" feeling; here's an example: force :: (Ord t, Bounded t) => Future t a -> IO (t, a) force (Known t a) = return (t, a) force (Unknown f) = do stmF <- f maxBound mF <- atomically stmF case mF of Nothing -> return (maxBound, error "never") Just fut' -> force fut' delayF :: Ord t => t -> Future t a -> Future t a delayF t0 (Known t a) = Known (max t0 t) a delayF t0 (Unknown f) = Unknown $ \t -> fmap (fmap (fmap (delayF t0))) (f t) instance (Ord t, Bounded t) => Monad (Future t) where return = Known minBound Known t a >>= g = delayF t (g a) Unknown f >>= g = Unknown $ \t -> do -- IO stmF <- f t return $ do -- STM mF <- stmF return $ do -- Maybe fut' <- mF return (fut' >>= g) This code makes me sad; so many nested blocks. There's got to be a refactoring of this that I am missing! It's clearly got something to do with Fix, Either, ReaderT, and MaybeT, and type composition, but none of those seem to answer the whole question. Any thoughts? -- ryan From midfield at gmail.com Thu Apr 24 19:28:47 2008 From: midfield at gmail.com (Ben) Date: Thu Apr 24 19:23:33 2008 Subject: a faster, accumulating mapM (was Re: [Haskell-cafe] mapM vs mapM_ performance) In-Reply-To: <1953845415.20080425013350@gmail.com> References: <9157df230804241414j6c92a01cuccf4b6416bf9f370@mail.gmail.com> <1953845415.20080425013350@gmail.com> Message-ID: <9157df230804241628p54cd8c31s4b0a961efc1144fc@mail.gmail.com> On the test case i'm running the performance impacts of reversing the return list are negligible: mapM3 :: Monad m => (a -> m b) -> [a] -> m [b] {-# INLINE mapM3 #-} mapM3 fn lst = mapM3accum fn lst [] where mapM3accum _ [] accum = return $ reverse accum mapM3accum fn (x:xs) accum = do r <- fn x mapM3accum fn xs (r:accum) main5 = do print $ length $ mapM_ (flip replicate ()) [1..11] time ~ 18 seconds (about the same, faster on my machine probably due to timing artifacts) and the memory was about the same (strangely less than the non-reversing one though again that's probably an artifact.) In any case, I have some questions: 1) Why is the Prelude mapM so slow? It seems like running 10x slower than mapM_ when generating only 50,000 return values is a problem. 2) Is there a reason to not use mapM3 above? Thanks and take care, Ben On Thu, Apr 24, 2008 at 2:33 PM, Bulat Ziganshin wrote: > Hello Niklas, > > > Friday, April 25, 2008, 1:25:39 AM, you wrote: > > > Not that it should matter for performance any, but you really ought to > > reverse the result list too, or compute the accumulator in the right > > order. :-) > > unfortunately, this affects performance too. reverse costs one more scan > through the list and building lot of thunks has its own space and time > cost > > > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > From lrpalmer at gmail.com Thu Apr 24 19:45:45 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Apr 24 19:40:30 2008 Subject: a faster, accumulating mapM (was Re: [Haskell-cafe] mapM vs mapM_ performance) In-Reply-To: <9157df230804241628p54cd8c31s4b0a961efc1144fc@mail.gmail.com> References: <9157df230804241414j6c92a01cuccf4b6416bf9f370@mail.gmail.com> <1953845415.20080425013350@gmail.com> <9157df230804241628p54cd8c31s4b0a961efc1144fc@mail.gmail.com> Message-ID: <7ca3f0160804241645q3a08261bt3fe05d264fca7721@mail.gmail.com> On Thu, Apr 24, 2008 at 11:28 PM, Ben wrote: > 2) Is there a reason to not use mapM3 above? Yes, there certainly is. mapM3 is not equivalent to mapM; it is too strict: *Main> take 3 $ head $ mapM return [1,2,3,4,undefined] [1,2,3] *Main> take 3 $ head $ mapM3 return [1,2,3,4,undefined] [*** Exception: Prelude.undefined So, like foldl', mapM3 seems a viable alternative for mapM, but not a replacement. Luke From midfield at gmail.com Thu Apr 24 20:02:18 2008 From: midfield at gmail.com (Ben) Date: Thu Apr 24 19:57:03 2008 Subject: a faster, accumulating mapM (was Re: [Haskell-cafe] mapM vs mapM_ performance) In-Reply-To: <7ca3f0160804241645q3a08261bt3fe05d264fca7721@mail.gmail.com> References: <9157df230804241414j6c92a01cuccf4b6416bf9f370@mail.gmail.com> <1953845415.20080425013350@gmail.com> <9157df230804241628p54cd8c31s4b0a961efc1144fc@mail.gmail.com> <7ca3f0160804241645q3a08261bt3fe05d264fca7721@mail.gmail.com> Message-ID: <9157df230804241702l7b24ee67r58434a73b8171343@mail.gmail.com> Luke, Thanks for the nice answer. So maybe I'll give mapM3 the name mapM' and put it in my personal library. But I'm still a bit curious about the performance profile of mapM. The profiler is telling me they're allocating around the same amount of memory, so I am not clear what is making it slow. I am guessing it has something to do with extra thunks due to laziness, but a 10x slowdown? Thanks again, B On Thu, Apr 24, 2008 at 4:45 PM, Luke Palmer wrote: > On Thu, Apr 24, 2008 at 11:28 PM, Ben wrote: > > 2) Is there a reason to not use mapM3 above? > > Yes, there certainly is. mapM3 is not equivalent to mapM; it is too strict: > > *Main> take 3 $ head $ mapM return [1,2,3,4,undefined] > [1,2,3] > *Main> take 3 $ head $ mapM3 return [1,2,3,4,undefined] > [*** Exception: Prelude.undefined > > So, like foldl', mapM3 seems a viable alternative for mapM, but not a > replacement. > > Luke > From lrpalmer at gmail.com Thu Apr 24 20:06:23 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Apr 24 20:01:07 2008 Subject: [Haskell-cafe] Help me refactor this type! In-Reply-To: <2f9b2d30804241610h7511900cwdf9eda2e24fd02fa@mail.gmail.com> References: <2f9b2d30804241610h7511900cwdf9eda2e24fd02fa@mail.gmail.com> Message-ID: <7ca3f0160804241706v4ae1390dq41947000a92244de@mail.gmail.com> On Thu, Apr 24, 2008 at 11:10 PM, Ryan Ingram wrote: > More FRP stuff: a new type for Future that came to me in an > inspiration this morning. But it's ugly and I need someone with > better theoretical underpinnings than me to tell me what I've really > built :) > > data Future t a = > Known t a > | Unknown (t -> IO (STM (Maybe (Future t a)))) This looks similar to my friend the "free monad over exponentiation", or Suspend, which I also discovered while experimenting with FRP. After experimenting a bit, I found that the following variant lead to more elegant implementations of the same things: newtype SuspendT v m a = SuspendT (m (Either a (v -> SuspendT v m a))) Implemented pretty fully here: http://luqui.org/git/?p=luqui-misc.git;a=blob;f=work/code/haskell/frp/Fregl/Suspend.hs;h=d5d2daa02c9c392ac3788c3346fb8b6ab6acabf7;hb=63f7752229e63bd8d1aa9a7a9a8d6a785669cd45 I'm not quite sure whether you can make it have all the capabilities yours does (there is no STMT...). Luke From hpacheco at gmail.com Thu Apr 24 20:13:44 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Thu Apr 24 20:08:35 2008 Subject: [Haskell-cafe] Call for Contributions - Haskell Communities and Activities Report, May 2008 edition In-Reply-To: <481092C0.1030904@tcs.inf.tu-dresden.de> References: <481092C0.1030904@tcs.inf.tu-dresden.de> Message-ID: <7b92c2840804241713me3d7ef7w571f056d638dbaee@mail.gmail.com> se bem me lembro o 2lt j? est? neste report, que tal acrescentar uma refer?ncia a isto das type families ou n vale a pena? On Thu, Apr 24, 2008 at 3:01 PM, Janis Voigtlaender < voigt@tcs.inf.tu-dresden.de> wrote: > Dear Haskellers, > > so much has happened in the Haskell world in the past months. > Therefore, we would very much like to collect contributions for > the 14th edition of the > > ================================================================ > Haskell Communities & Activities Report > http://www.haskell.org/communities/ > > Submission deadline: 10 May 2008 > > (please send your contributions to hcar at haskell.org, in > plain text or LaTeX format) > ================================================================ > > This is the short story: > > * If you are working on any project that is in some way related > to Haskell, please write a short entry and submit it to the us. Even if > the project is very small or unfinished or you think it is not important > enough -- please reconsider and submit an entry anyway! > > * If you are interested in any project related to Haskell that has not > previously been mentioned in the HC&A Report, please tell us, so that we > can contact the project leaders and ask them to submit an entry. > > * Feel free to pass on this call for contributions to others that > might be interested. > > More detailed information: > > The Haskell Communities & Activities Report is a bi-annual overview of > the state of Haskell as well as Haskell-related projects over the > last, and possibly the upcoming 6 months. If you have only recently > been exposed to Haskell, it might be a good idea to browse the > December 2007 edition -- you will find interesting topics described as > well as several starting points and links that may provide answers to > many questions. > > Contributions will be collected until the submission deadline. They > will then be compiled into a coherent report that is published online > as soon as it is ready. As always, this is a great opportunity to > update your webpages, make new releases, announce or even start new > projects, or to talk about developments you want every Haskeller to > know about! > > As the purpose of the report is to collect recent or current > activities, we encourage you to update all existing summaries and > reports. We will probably drop any topics that have not had any > activity for the past year, i.e., since May 2007, but we would > very much prefer you to present an updated description of the > topic. Of course, new entries are more than welcome. Reports should > generally be kept brief and informative, ranging from a few sentences > to a few hundred words, to keep the whole report reasonably sized. > > Looking forward to your contributions, > > Andres and Janis (current editors) > > > FAQ: > > Q: Which topics are relevant? > > A: *All* topics which are related to Haskell in some way are relevant. We > usually had reports from users of Haskell (private, academic, or > commercial), from authors or contributors to projects related to Haskell, > from people working on the Haskell language, libraries, on language > extensions or variants. We also like reports over distributions of Haskell > software, Haskell infrastructure, books and tutorials on Haskell. Reports > on past and upcoming events related to Haskell are also relevant. Finally, > there might be new topics we don't even think about. As a rule of thumb: if > in doubt, then it probably is relevant and has a place in the HCAR. You can > also ask the editors. > > Q: Is unfinished work relevant? Are ideas for projects relevant? > > A: Yes! You can use the HCAR to talk about projects you are currently > working on. You can use it to look for other developers that might help > you. You can use it to write ``wishlist'' items for libraries and language > features you would like to see implemented. > > Q: How much should I write? > > A: There's no formal limit. But generally, entries should be short and > to the point. A general introduction is helpful. Apart from that, you > should focus on recent or upcoming developments. There also is no minimum > length of an entry! The report aims at being as complete as possible, so > please consider writing an entry, even if it's only a few lines long. > > Q: If I don't update my entry, but want to keep it in the report, what > should I do? > > A: Tell us that there are no changes. We will reuse the old entry in this > case, but we might drop it if it's older than a year, to give more room and > more attention to projects that change a lot. Don't resent complete entries > if you haven't changed them. > > Q: What format should I write in? > > A: The best format is a LaTeX source file, adhering to the template > that's available at: > > http://haskell.org/communities/05-2008/template.tex > > There's also a LaTeX style file at > > http://haskell.org/communities/05-2008/hcar.sty > > that you can use to preview your entry. If you don't know LaTeX, then use > plain text. If you modify an old entry, we will send you your old entry as > a > template within the next hours (provided we have your valid email address). > Please modify that template, rather than using your own version of the old > entry as a template. Don't worry about writing correct LaTeX, we will be > able to handle your file. Please don't use HTML or even DOC. > > -- > Dr. Janis Voigtlaender > http://wwwtcs.inf.tu-dresden.de/~voigt/ > mailto:voigt@tcs.inf.tu-dresden.de > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080425/f97803e4/attachment.htm From lrpalmer at gmail.com Thu Apr 24 20:19:03 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Apr 24 20:14:02 2008 Subject: a faster, accumulating mapM (was Re: [Haskell-cafe] mapM vs mapM_ performance) In-Reply-To: <9157df230804241702l7b24ee67r58434a73b8171343@mail.gmail.com> References: <9157df230804241414j6c92a01cuccf4b6416bf9f370@mail.gmail.com> <1953845415.20080425013350@gmail.com> <9157df230804241628p54cd8c31s4b0a961efc1144fc@mail.gmail.com> <7ca3f0160804241645q3a08261bt3fe05d264fca7721@mail.gmail.com> <9157df230804241702l7b24ee67r58434a73b8171343@mail.gmail.com> Message-ID: <7ca3f0160804241719k24f8cba4n36feae308896dbe2@mail.gmail.com> On Fri, Apr 25, 2008 at 12:02 AM, Ben wrote: > Luke, > > Thanks for the nice answer. So maybe I'll give mapM3 the name mapM' > and put it in my personal library. Except the answer was wrong. I forgot the reverse in my implementation, so that undefined we were seeing was just the last element of the list. But the conclusion is still true :-) *Main> take 3 $ runIdentity $ mapM return (1:2:3:4:undefined) [1,2,3] *Main> take 3 $ runIdentity $ mapM3 return (1:2:3:4:undefined) *** Exception: Prelude.undefined > But I'm still a bit curious about the performance profile of mapM. > The profiler is telling me they're allocating around the same amount > of memory, so I am not clear what is making it slow. I am guessing it > has something to do with extra thunks due to laziness, but a 10x > slowdown? Tail recursion can make a huge difference in strict settings: the difference between a loop and recursion in C. Luke From niklas.broberg at gmail.com Thu Apr 24 20:25:13 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Apr 24 20:19:59 2008 Subject: a faster, accumulating mapM (was Re: [Haskell-cafe] mapM vs mapM_ performance) In-Reply-To: <7ca3f0160804241645q3a08261bt3fe05d264fca7721@mail.gmail.com> References: <9157df230804241414j6c92a01cuccf4b6416bf9f370@mail.gmail.com> <1953845415.20080425013350@gmail.com> <9157df230804241628p54cd8c31s4b0a961efc1144fc@mail.gmail.com> <7ca3f0160804241645q3a08261bt3fe05d264fca7721@mail.gmail.com> Message-ID: > > 2) Is there a reason to not use mapM3 above? > > Yes, there certainly is. mapM3 is not equivalent to mapM; it is too strict: > > *Main> take 3 $ head $ mapM return [1,2,3,4,undefined] > [1,2,3] > *Main> take 3 $ head $ mapM3 return [1,2,3,4,undefined] > [*** Exception: Prelude.undefined > > So, like foldl', mapM3 seems a viable alternative for mapM, but not a > replacement. Wow. A 10x slowdown for a very commonly used function that in 99.8% of all use cases has no need for the extra laziness at all. No wonder some people say Haskell is a toy language... /Niklas From dons at galois.com Thu Apr 24 20:44:43 2008 From: dons at galois.com (Don Stewart) Date: Thu Apr 24 20:39:30 2008 Subject: a faster, accumulating mapM (was Re: [Haskell-cafe] mapM vs mapM_ performance) In-Reply-To: References: <9157df230804241414j6c92a01cuccf4b6416bf9f370@mail.gmail.com> <1953845415.20080425013350@gmail.com> <9157df230804241628p54cd8c31s4b0a961efc1144fc@mail.gmail.com> <7ca3f0160804241645q3a08261bt3fe05d264fca7721@mail.gmail.com> Message-ID: <20080425004443.GH32372@scytale.galois.com> niklas.broberg: > > > 2) Is there a reason to not use mapM3 above? > > > > Yes, there certainly is. mapM3 is not equivalent to mapM; it is too strict: > > > > *Main> take 3 $ head $ mapM return [1,2,3,4,undefined] > > [1,2,3] > > *Main> take 3 $ head $ mapM3 return [1,2,3,4,undefined] > > [*** Exception: Prelude.undefined > > > > So, like foldl', mapM3 seems a viable alternative for mapM, but not a > > replacement. > > Wow. A 10x slowdown for a very commonly used function that in 99.8% of > all use cases has no need for the extra laziness at all. No wonder > some people say Haskell is a toy language... > mapM_ is far more common, and optimised specially. -- Don From cetintozkoparan at yahoo.com Thu Apr 24 21:27:32 2008 From: cetintozkoparan at yahoo.com (cetin tozkoparan) Date: Thu Apr 24 21:22:16 2008 Subject: [Haskell-cafe] how can this code be less? Message-ID: <362977.63569.qm@web62206.mail.re1.yahoo.com> I wrote this code and Can it be less? [2,4,5]list is sub list of [3,7,2,4,5,9] list and return True but not of[3,7,4,2,5,9] list ; return False sublist :: Eq a => [a] -> [a] -> Bool sublist [] _ = True sublist (_:_) [] = False sublist (x:xs) (y:ys) | x == y = if isEqual (x:xs) (y:ys) == False then sublist (x:xs) ys else True | otherwise = sublist (x:xs) ys isEqual :: Eq a => [a] -> [a] -> Bool isEqual [] _ = True isEqual (_:_) [] = False isEqual (x:xs) (y:ys) | x==y = isEqual xs ys | otherwise = False ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080424/97bc4898/attachment.htm From kieran at us.ibm.com Thu Apr 24 22:32:34 2008 From: kieran at us.ibm.com (Kieran Beltran) Date: Thu Apr 24 22:27:26 2008 Subject: [Haskell-cafe] Kieran Beltran/Watson/IBM is out of the office. Message-ID: I will be out of the office starting 04/23/2008 and will not return until 04/28/2008. I will be on vacation for a few days. If this is urgent please reach my Admin Kristine Smester ((917) 472-3387), otherwise I will respond to your message when I return. From westondan at imageworks.com Thu Apr 24 22:40:23 2008 From: westondan at imageworks.com (Dan Weston) Date: Thu Apr 24 22:35:08 2008 Subject: [Haskell-cafe] how can this code be less? In-Reply-To: <362977.63569.qm@web62206.mail.re1.yahoo.com> References: <362977.63569.qm@web62206.mail.re1.yahoo.com> Message-ID: <48114497.2050604@imageworks.com> cetin tozkoparan wrote: > I wrote this code and Can it be less? > [2,4,5] list is sub list of [3,7,*2,4,5*,9] list and return True but > not of [3,7,*4,2,5*,9] list ; return False > > sublist :: Eq a => [a] -> [a] -> Bool > sublist [] _ = True > sublist (_:_) [] = False > sublist (x:xs) (y:ys) > | x == y = if isEqual (x:xs) (y:ys) == False > then sublist (x:xs) ys > else True > | otherwise = sublist (x:xs) ys > > > isEqual :: Eq a => [a] -> [a] -> Bool > isEqual [] _ = True > isEqual (_:_) [] = False > isEqual (x:xs) (y:ys) > | x==y = isEqual xs ys > | otherwise = False One way is to use existing library functions as Henning suggested (but maybe you missed it because he mischievously changed the subject!) Henning Thielemann wrote: > try 'List.tails' and 'List.isPrefixOf' You should be able to define sublist using only some combination of the following (and one pair of parentheses) in one line of code! import List(isPrefixOf,tails) (.) :: (b -> c) -> (a -> b) -> a -> c any :: (a -> Bool) -> [a] -> Bool tails :: [a] -> [[a]] isPrefixOf :: (Eq a) => [a] -> [a] -> Bool From alexander.dunlap at gmail.com Fri Apr 25 00:41:44 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Fri Apr 25 00:36:30 2008 Subject: [Haskell-cafe] how can this code be less? In-Reply-To: <48114497.2050604@imageworks.com> References: <362977.63569.qm@web62206.mail.re1.yahoo.com> <48114497.2050604@imageworks.com> Message-ID: <57526e770804242141m4a7a6654hc1692f2ee0e50af@mail.gmail.com> I think you're looking for Data.List.isInfixOf. Alex On Thu, Apr 24, 2008 at 7:40 PM, Dan Weston wrote: > cetin tozkoparan wrote: > > > I wrote this code and Can it be less? > > [2,4,5] list is sub list of [3,7,*2,4,5*,9] list and return True but not > of [3,7,*4,2,5*,9] list ; return False > > > > sublist :: Eq a => [a] -> [a] -> Bool > > sublist [] _ = True > > sublist (_:_) [] = False > > sublist (x:xs) (y:ys) > > | x == y = if isEqual (x:xs) (y:ys) == False > > then sublist (x:xs) ys > > else True > > | otherwise = sublist (x:xs) ys > > > > isEqual :: Eq a => [a] -> [a] -> Bool > > isEqual [] _ = True > > isEqual (_:_) [] = False > > isEqual (x:xs) (y:ys) > > | x==y = isEqual xs ys > > | otherwise = False > > > > One way is to use existing library functions as Henning suggested (but > maybe you missed it because he mischievously changed the subject!) > > Henning Thielemann wrote: > > try 'List.tails' and 'List.isPrefixOf' > > You should be able to define sublist using only some combination of the > following (and one pair of parentheses) in one line of code! > > import List(isPrefixOf,tails) > > (.) :: (b -> c) -> (a -> b) -> a -> c > any :: (a -> Bool) -> [a] -> Bool > tails :: [a] -> [[a]] > isPrefixOf :: (Eq a) => [a] -> [a] -> Bool > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jsnow at cs.pdx.edu Fri Apr 25 00:34:06 2008 From: jsnow at cs.pdx.edu (Jim Snow) Date: Fri Apr 25 01:30:23 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <4810DFAE.8040807@btinternet.com> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> <4310375315.20080419001919@gmail.com> <20080418203222.GQ8763@darcs.net> <48090E08.1020109@cs.pdx.edu> <20080418213405.GT8763@darcs.net> <1208968967.5538.22.camel@derek-laptop> <480FCD87.7010803@cs.pdx.edu> <4810DFAE.8040807@btinternet.com> Message-ID: <48115F3E.6020305@cs.pdx.edu> Andrew Coppin wrote: > > Wow. The POV-Ray guys are talking about Haskell [or rather, my > personal addiction to it] and the Haskell guys are talking about > POV-Ray... on the same day... How unlikely is that? ;-) > That's odd; I had a personal addiction to POV-Ray for a few years, and just now have started using Haskell. > I've been using POV-Ray for a long time. I like it for several reasons: > > 1. It's the only program I've ever seen [on a PC] that does ray > tracing. [I'm sure there must be others...] > 2. It's the only program I've seen that can render *real* curves, not > fake trickery with triangle meshes. > 3. It can render *arbitrary* mathematical surfaces. Want to render a > 3D slice of the 4D cubic Mandelbrot set? No problem! > 4. It has a novel "scene description language", which does far more > than describe scenes. It's Turing-complete, and you can build physics > engines with it. [It's painfully slow though!] > The Scene Description Language (SDL) is the best and worst thing about POV-Ray. It's very intuitive and user-friendly, so a person can reasonably write a complex scene in pure code without using an external GUI editor. Unfortunately, the SDL is so complex it's well-nigh impossible to support in other third-party applications. It's also slow. I don't know if this is still the case, but the standard way of doing an animation was to reference a "clock" variable in your scene source code that went from 0 to 1; for instance, a command to make a swing swing back and forth might looks like this: "rotate 15*sin((clock/2)*seconds*(2*pi)-((2/3)*pi))*x" "seconds" here is a variable set to the number of seconds in the animation, and "x" is the X axis unit vector <1,0,0>. The (2/3)*pi thing is to make it swing out of phase with the other swings. (this rather obfuscatory example taken from an actual ancient povray source file, you can see a rendering here: http://syn.cs.pdx.edu/~jsnow/playground.png) The scene then has to be re-parsed for every frame. For complex scenes, the scene parsing could take longer than the actual render. There are many other PC programs that do ray tracing, but POV-Ray is the only one I've had any experience with. > The POV-Ray team is currently working on the first multi-threaded > version. [After years of saying it would never happen.] It's taking a > while. (That's partly because the developers take product quality very > seriously.) It should be interesting when it's done, but it's still > taking a while. > Personally, I'd quite like to write my own ray tracer to address some > of these limitations. But every time I try, I end up hitting design > issues [Haskell works very differently to Java] or performance issues > [which I don't even know how to begin debugging]. Not to mention that > POV-Ray uses sophisticated techniques like volume bounding that I know > nothing about. (There's nothing like using an inherantly superior > algorithm to make your code orders of magnitude faster...) > I haven't really run into any issues where Haskell didn't let me do what I want, except for the performance counters thing mentioned way back at the beginning of this thread (and which I've more or less given up on for now, since the acceleration structure seems to be working okay and I have other things to work on). I would certainly welcome any patches to Glome if you want to contribute in some way rather than write something from scratch. A good acceleration structure definitely makes everything go a lot faster. It's the difference between rendering a scene in a few seconds or ten minutes. BIH is what I'm using. It's relatively new. Here's a paper about it: http://ainc.de/Research/BIH.pdf The actual constructor is based loosely on this pseudocode: http://ompf.org/forum/viewtopic.php?p=1411#p1411 Evan Laforge wrote: > Not knowing anything about raytracing, one of the things I found > interesting about the paper was that he claimed that the speedups were > from using coherent ray packets, and that the shader model was > orthogonal, and enough much is spent raycasting that the shader code > to make much difference. The implication was that you could graft a > packet style raycasting engine onto even povray and give it a nice > speed boost... though you might have to lose the nifty "real" shapes > to tessellated approximations. > > Is this accurate? True but reality is more complicated? > You don't need to drop support for the whole multitude of primitives, though the ones that are packet-friendly will render faster. Many modern ray tracers spend most of their time traversing the acceleration structure rather than doing intersection tests with actual geometry, so all you really need to do to get most of the benefit of packet tracing is to make the acceleration structure support packets. (For the actual geometry, you can fall back on mono-rays.) I tried 2x2 packets out last night and got about a 10-15% speed improvement on the level-3 SPD sphereflake. (Shadow and reflection rays are still mono rays; if I converted them over, the improvement would presumably be more significant.) The simplifying assumption you make when you're traversing the acceleration structure with packets is that if one ray in the packet hits a bounding volume, you assume that they all do. That adds a little overhead if the rays are coherent (all starting near a common origin and pointing in almost the same direction), or a lot of overhead if they aren't coherent. If used appropriately, the performance gains outweigh the overhead by a considerable margin. Jon Harrop wrote: > On Thursday 24 April 2008 20:29:50 Andrew Coppin wrote: > >> > 2. It's the only program I've seen that can render *real* curves, not >> > fake trickery with triangle meshes. >> > What you called "fake trickery with triangle meshes" is the core of all modern > computer graphics. Focussing on ray tracing instead of that is rather missing > the point, IMHO. > I agree that triangles are very important, and I support them in Glome. Cones and spheres and boxes and the like can be made into some fairly elaborate scenes, but you can't really make, say, a realistic human figure out of those sorts of primitives. Also, real data sets like terrain or 3d-scanned geometry are easy to represent as triangles. On the other hand, sometimes all you want is a box or a shiny sphere and it's silly (not to mention a waste of memory) to represent either as a bunch of triangle. So it's appropriate to support both approaches, so you can do whatever makes the most sense for the application. Ray tracing and triangles isn't an either-or thing. Some ray tracers only support triangles. There is a speed penalty for supporting other kinds of primitives, because then the ray tracer has to branch to figure out which ray-intersection test to run on each primitive, but I think the flexibility is worth the cost. -jim From ketil at malde.org Fri Apr 25 02:51:00 2008 From: ketil at malde.org (Ketil Malde) Date: Fri Apr 25 02:45:36 2008 Subject: [Haskell-cafe] how can this code be less? In-Reply-To: <362977.63569.qm@web62206.mail.re1.yahoo.com> (cetin tozkoparan's message of "Thu\, 24 Apr 2008 18\:27\:32 -0700 \(PDT\)") References: <362977.63569.qm@web62206.mail.re1.yahoo.com> Message-ID: <874p9qv357.fsf@nmd9999.imr.no> cetin tozkoparan writes: > sublist :: Eq a => [a] -> [a] -> Bool > sublist [] _ = True > sublist (_:_) [] = False This can be simplified a bit, I think (Reformatted to one line): > sublist (x:xs) (y:ys) > | x == y = if isEqual (x:xs) (y:ys) == False then sublist (x:xs) ys else True I don't like the "== False" for boolean expressions, so I'd write: sublist (x:xs) (y:ys) | x == y = if not (isEqual (x:xs) (y:ys)) then sublist (x:xs) ys else True Or, swithing then and else clauses: sublist (x:xs) (y:ys) | x == y = if isEqual (x:xs) (y:ys) then True else sublist (x:xs) ys If you look at the following clause: > | otherwise = sublist (x:xs) ys you'll notice that it is the same as the "else" clause. We can therefore write: sublist (x:xs) (y:ys) | x == y && isEqual (x:xs) (y:ys) = True | otherwise = sublist (x:xs) ys isEqual will re-test x==y, so this is redundant: sublist (x:xs) (y:ys) | isEqual (x:xs) (y:ys) = True | otherwise = sublist (x:xs) ys The pattern guard is a bit gratuitious, why not write: sublist (x:xs) (y:ys) = isEqual (x:xs) (y:ys) || sublist (x:xs) ys Which is how you'd define the problem: a list xs is a sublist of ys if they have equal prefixes, or if xs is a sublist of the tail of ys. > isEqual :: Eq a => [a] -> [a] -> Bool Slightly misleading name, since it checks a prefix, not complete equality. > isEqual [] _ = True > isEqual (_:_) [] = False > isEqual (x:xs) (y:ys) > | x==y = isEqual xs ys > | otherwise = False Similar to the above, you could write: isEqual (x:xs) (y:ys) = x == y && isEqual xs ys "lists (x:xs) and (y:ys) 'isEqual' if x == y and xs 'isEqual' ys" As pointed out, you could (and should) write this using a couple of Prelude functions. Oh, any errors in the code are left as excercises for the reader (in other words, I didn't test this code at all, but don't want to be perceived as lazy.) -k -- If I haven't seen further, it is by standing in the footprints of giants From wss at cs.nott.ac.uk Fri Apr 25 04:00:47 2008 From: wss at cs.nott.ac.uk (Wouter Swierstra) Date: Fri Apr 25 03:55:32 2008 Subject: [Haskell-cafe] Re: Stronger STM primitives needed? Or am I just doing it wrong? In-Reply-To: References: <2f9b2d30804221448o12bd374dqaf42a5c299b9c259@mail.gmail.com> <2f9b2d30804230913h31f6fcfax9051c5affa29fc9@mail.gmail.com> <2F436402-5EB7-45A9-A29F-78C43081D64C@alum.mit.edu> <2f9b2d30804231212l5ca01e7ctd2261e8e396bec40@mail.gmail.com> <20080423192555.GF8763@darcs.net> <2f9b2d30804231346y685820bdkb7f26defff1ee47b@mail.gmail.com> <9B48F789-4A32-43E6-BBCC-60A589926EC5@gmail.com> <2f9b2d30804231715t7cc9736q1494a71bf73d7e27@mail.gmail.com> Message-ID: <299978CD-8BD4-4BAF-A2CA-FDFA9B2B9043@cs.nott.ac.uk> On 24 Apr 2008, at 12:02, apfelmus wrote: > Sounds good. But I wonder what "obscure" optimization comes next; > can we have a toy-model of STM? I mean, it should be possible to > express both the "continuation-logging" and "read-only-fail" > optimization in terms of > > type STM a = Maybe a > > or similar? There's a pure version of STM in the latest version of the IOSpec library: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/IOSpec-0.2 I've used it to test a few non-trivial applications. I should warn you that it does use a very simple stop-the-world semantics - the model may not be fine-grained enough to try out all kinds of optimisations. Wouter From simonpj at microsoft.com Fri Apr 25 04:42:28 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Apr 25 04:37:13 2008 Subject: a faster, accumulating mapM (was Re: [Haskell-cafe] mapM vs mapM_ performance) In-Reply-To: <9157df230804241628p54cd8c31s4b0a961efc1144fc@mail.gmail.com> References: <9157df230804241414j6c92a01cuccf4b6416bf9f370@mail.gmail.com> <1953845415.20080425013350@gmail.com> <9157df230804241628p54cd8c31s4b0a961efc1144fc@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE5392066@EA-EXMSG-C334.europe.corp.microsoft.com> | 1) Why is the Prelude mapM so slow? It seems like running 10x slower | than mapM_ when generating only 50,000 return values is a problem. All this does seem odd. I've submitted a ticket so we don't forget it http://hackage.haskell.org/trac/ghc/ticket/2236 It appears to be some bad (possibly even non-linear) run-time system or garbage collector effect, caused by the very deep stack. Thanks for persisting with this. I'd expect mapM to be a bit slower, but not *that* much. Simon From haberg at math.su.se Fri Apr 25 07:21:20 2008 From: haberg at math.su.se (Hans Aberg) Date: Fri Apr 25 07:16:32 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <4808E2AE.2080703@gmail.com> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <5ab17e790804171009l6d974cf2va38cbd94dccf3303@mail.gmail.com> <48078851.1050201@gmail.com> <5ab17e790804171113i647ff98ftde208ca753f88f0d@mail.gmail.com> <48079F85.5030408@gmail.com> <5ab17e790804181028i20a6961au8ca528871170b460@mail.gmail.com> <4808E2AE.2080703@gmail.com> Message-ID: <844A9499-D833-4D29-8457-6695F94FCA64@math.su.se> On 18 Apr 2008, at 20:04, Martin Sulzmann wrote: > Let's consider our running example > > class D a b | a -> b > instance D a b => D [a] [b] > > which we can write in CHR notation > > D a b, D a c ==> b=c (FD) > > D [a] [b] <=> D a b (Inst) > > These rules overlap. I experimented with translations into GNU Prolog (gprolog). Since "=" is hard to get working in Prolog unless integrated into unification, I tried (using the idea of rewriting unique existence as functions, possible if one assumes the axiom of choice): class(d, A, b(A)). instance(d, l(A), l(B)) :- class(d, A, B). Then: ?- instance(d, l(A), l(B)). B = b(A) ?- instance(d, l(A), C). C = l(b(A)) ?- instance(d, l(A), l(B)), instance(d, l(A), C). B = b(A) C = l(b(A)) Though I am not sure about the intended semantics, it does produce unique solutions. Hans From apfelmus at quantentunnel.de Fri Apr 25 07:22:47 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Fri Apr 25 07:17:42 2008 Subject: [Haskell-cafe] Re: Help me refactor this type! In-Reply-To: <2f9b2d30804241610h7511900cwdf9eda2e24fd02fa@mail.gmail.com> References: <2f9b2d30804241610h7511900cwdf9eda2e24fd02fa@mail.gmail.com> Message-ID: Ryan Ingram wrote: > More FRP stuff: a new type for Future that came to me in an > inspiration this morning. But it's ugly and I need someone with > better theoretical underpinnings than me to tell me what I've really > built :) > > data Future t a = Known t a | Unknown (t -> IO (STM (Maybe (Future t a)))) This is a composition of (applicative) functors. Not sure whether this helps from the theoretical side, but it can be used to considerably shorten your code: type Tower t b = t -> IO (STM (Maybe b)) fmap4 :: (a -> b) -> Tower a -> Tower b fmap4 f = fmap . fmap . fmap . fmap $ f delayF :: Ord t => t -> Future t a -> Future t a delayF t0 (Known t a) = Known (max t0 t) a delayF t0 (Unknown f) = Unknown $ fmap4 (delayF0 t0) f instance (Ord t, Bounded t) => Monad (Future t) where return = Known minBound Known t a >>= g = delayF t (g a) Unknown f >>= g = Unknown $ fmap4 (>>= g) f Regards, apfelmus From Christian.Maeder at dfki.de Fri Apr 25 07:34:58 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Apr 25 07:29:42 2008 Subject: [Haskell-cafe] Re: how can this code be less? In-Reply-To: <362977.63569.qm@web62206.mail.re1.yahoo.com> References: <362977.63569.qm@web62206.mail.re1.yahoo.com> Message-ID: <4811C1E2.60501@dfki.de> You may want to study the code form Data.List first: isInfixOf :: (Eq a) => [a] -> [a] -> Bool isInfixOf needle haystack = any (isPrefixOf needle) (tails haystack) cetin tozkoparan wrote: > I wrote this code and Can it be less? > [2,4,5] list is sub list of [3,7,*2,4,5*,9] list and return True but > not of [3,7,*4,2,5*,9] list ; return False > > sublist :: Eq a => [a] -> [a] -> Bool > sublist [] _ = True > sublist (_:_) [] = False > sublist (x:xs) (y:ys) > | x == y = if isEqual (x:xs) (y:ys) == False > then sublist (x:xs) ys > else True > | otherwise = sublist (x:xs) ys > > > isEqual :: Eq a => [a] -> [a] -> Bool > isEqual [] _ = True > isEqual (_:_) [] = False > isEqual (x:xs) (y:ys) > | x==y = isEqual xs ys > | otherwise = False isEqual is not needed, because "Eq" provides "==" over lists, too. HTH Christian From Christian.Maeder at dfki.de Fri Apr 25 07:41:57 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Apr 25 07:36:40 2008 Subject: [Haskell-cafe] Re: how can this code be less? In-Reply-To: <4811C1E2.60501@dfki.de> References: <362977.63569.qm@web62206.mail.re1.yahoo.com> <4811C1E2.60501@dfki.de> Message-ID: <4811C385.3070200@dfki.de> Christian Maeder wrote: >> isEqual :: Eq a => [a] -> [a] -> Bool >> isEqual [] _ = True >> isEqual (_:_) [] = False >> isEqual (x:xs) (y:ys) >> | x==y = isEqual xs ys >> | otherwise = False > > isEqual is not needed, because "Eq" provides "==" over lists, too. Ah, isEqual isn't "==", but isPrefixOf. C. From Tom.Schrijvers at cs.kuleuven.be Fri Apr 25 08:20:55 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Fri Apr 25 08:16:40 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: <844A9499-D833-4D29-8457-6695F94FCA64@math.su.se> References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <5ab17e790804171009l6d974cf2va38cbd94dccf3303@mail.gmail.com> <48078851.1050201@gmail.com> <5ab17e790804171113i647ff98ftde208ca753f88f0d@mail.gmail.com> <48079F85.5030408@gmail.com> <5ab17e790804181028i20a6961au8ca528871170b460@mail.gmail.com> <4808E2AE.2080703@gmail.com> <844A9499-D833-4D29-8457-6695F94FCA64@math.su.se> Message-ID: On Fri, 25 Apr 2008, Hans Aberg wrote: > On 18 Apr 2008, at 20:04, Martin Sulzmann wrote: > >> Let's consider our running example >> >> class D a b | a -> b >> instance D a b => D [a] [b] >> >> which we can write in CHR notation >> >> D a b, D a c ==> b=c (FD) >> >> D [a] [b] <=> D a b (Inst) >> >> These rules overlap. > > I experimented with translations into GNU Prolog (gprolog). Since "=" is hard > to get working in Prolog unless integrated into unification, I tried (using > the idea of rewriting unique existence as functions, possible if one assumes > the axiom of choice): > class(d, A, b(A)). > instance(d, l(A), l(B)) :- class(d, A, B). > Then: > ?- instance(d, l(A), l(B)). > B = b(A) > > ?- instance(d, l(A), C). > C = l(b(A)) > > ?- instance(d, l(A), l(B)), instance(d, l(A), C). > B = b(A) > C = l(b(A)) > Though I am not sure about the intended semantics, it does produce unique > solutions. Prolog works under the assumption of a closed world. That's contrary to the open world view of regular type classes. So these aren't the intended semantics. Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From stevelihn at gmail.com Fri Apr 25 08:42:18 2008 From: stevelihn at gmail.com (Steve Lihn) Date: Fri Apr 25 08:37:02 2008 Subject: [Haskell-cafe] Higher order randomness and the fat tails Message-ID: Hi, Haskellers, This email is only remotely connected to this list. Recently I am doing some research on the fat tails (in fact, I simply bumped into it) on the stock market. I came up with an equation which I think solves the fat tails -- which is really the Levy stable distribution. During the complex arguments that led to the solution, I coined a term called "Higher order randomness". This is inspired by the concept of higher order function in Haskell. * Higher order function operates on another function, instead on an ordinary value. So higher order randomness operates on another randomness, instead of directly producing the time series. The request is the following. I know there are many scientists on this list. If you or your colleagues happen to be involved or know any scenario that has fat tail distribution, can you let me know? I only "solved" one scenario -- numerically, not even analytically. Probability-wise, it is a dangerous thing to claim I solve "the problem". So I'd like to collect as many scenarios as I can. It can be financial related, or in other fields of science. PS. I'd like to have some operational details and numbers. Not just a general statement like "fat tail is observed in astronomy". Thanks and sorry for the spam, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080425/8b25b0fc/attachment.htm From haberg at math.su.se Fri Apr 25 09:20:27 2008 From: haberg at math.su.se (Hans Aberg) Date: Fri Apr 25 09:15:16 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <5ab17e790804171009l6d974cf2va38cbd94dccf3303@mail.gmail.com> <48078851.1050201@gmail.com> <5ab17e790804171113i647ff98ftde208ca753f88f0d@mail.gmail.com> <48079F85.5030408@gmail.com> <5ab17e790804181028i20a6961au8ca528871170b460@mail.gmail.com> <4808E2AE.2080703@gmail.com> <844A9499-D833-4D29-8457-6695F94FCA64@math.su.se> Message-ID: On 25 Apr 2008, at 14:20, Tom Schrijvers wrote: > Prolog works under the assumption of a closed world. That's > contrary to the open world view of regular type classes. So these > aren't the intended semantics. By which I gather you mean the interpretation of ":-" as logical connective "=>" rather than provability "|-"? My point, though, was to interpret class a b | a -> b as a functional dependency b = b(a) rather than as D a b, D a c ==> b=c Thus trying to eliminate the use of "=". Might that be exploited in the type theory context? Hans From Tom.Schrijvers at CS.KULEUVEN.BE Fri Apr 25 09:38:19 2008 From: Tom.Schrijvers at CS.KULEUVEN.BE (Tom Schrijvers) Date: Fri Apr 25 09:34:24 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <5ab17e790804171009l6d974cf2va38cbd94dccf3303@mail.gmail.com> <48078851.1050201@gmail.com> <5ab17e790804171113i647ff98ftde208ca753f88f0d@mail.gmail.com> <48079F85.5030408@gmail.com> <5ab17e790804181028i20a6961au8ca528871170b460@mail.gmail.com> <4808E2AE.2080703@gmail.com> <844A9499-D833-4D29-8457-6695F94FCA64@math.su.se> Message-ID: On Fri, 25 Apr 2008, Hans Aberg wrote: > On 25 Apr 2008, at 14:20, Tom Schrijvers wrote: > >> Prolog works under the assumption of a closed world. That's contrary to the >> open world view of regular type classes. So these aren't the intended >> semantics. > > By which I gather you mean the interpretation of ":-" as logical connective > "=>" rather than provability "|-"? What I meant was that when Prolog says "there are no more solutions", it doesn't know of any more. In realtiy it means "there no more solutions under the closed world assumption". That means there could be more solutions if you haven't told Prolog everything. In this context, there may be more class instances (you simply haven't told the system yet). > My point, though, was to interpret > class a b | a -> b > as a functional dependency b = b(a) rather than as > D a b, D a c ==> b=c > Thus trying to eliminate the use of "=". I don't follow you here. Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From jmaessen at alum.mit.edu Fri Apr 25 10:20:58 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Fri Apr 25 10:15:45 2008 Subject: [Haskell-cafe] lookup tables & style guidelines In-Reply-To: <4810A863.4010703@iee.org> References: <1ff5dedc0804231334y1a14f93cobf6b97da93285728@mail.gmail.com> <20080423203634.GG22492@scytale.galois.com> <87r6cvzrtx.fsf@nmd9999.imr.no> <4810A863.4010703@iee.org> Message-ID: On Apr 24, 2008, at 11:33 AM, Adrian Hey wrote: > Also, if you're likely to be using union/intersection a lot you should > know that Data.Map/Set are very slow for this because they use the > not efficient hedge algorithm :-) OK, I'm going to bite here: What's the efficient algorithm for union on balanced trees, given that hedge union was chosen as being more efficient than naive alternatives (split and merge, repeated insertion)? My going hypothesis has been "hedge union is an inefficient algorithm, except that it's better than all those other inefficient algorithms". For IntSet/IntMap of course the split structure of the tree is fixed (we can think of these as being compressed versions of a complete binary tree) and union and intersection are quite efficient. -Jan-Willem Maessen From cetin.sert at gmail.com Fri Apr 25 10:28:26 2008 From: cetin.sert at gmail.com (Cetin Sert) Date: Fri Apr 25 10:23:12 2008 Subject: [Haskell-cafe] Haskell Web server Message-ID: <1ff5dedc0804250728y7c128270v23ecf62ad8c39ef7@mail.gmail.com> Hi, What is the fastest way to set up a web server that can redirect requests to a haskell application and serve results returned by it? I need to demonstrate a simple visualization tool I have written for analytic tableaux on Monday and need something easy and simple. Best Regards, Cetin Sert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080425/1764452e/attachment.htm From haberg at math.su.se Fri Apr 25 10:37:08 2008 From: haberg at math.su.se (Hans Aberg) Date: Fri Apr 25 10:31:56 2008 Subject: [Haskell-cafe] looking for examples of non-full Functional Dependencies In-Reply-To: References: <480615DF.6050807@gmail.com> <4806C8B6.6040603@cs.pdx.edu> <4806E8DA.9070503@gmail.com> <5ab17e790804171009l6d974cf2va38cbd94dccf3303@mail.gmail.com> <48078851.1050201@gmail.com> <5ab17e790804171113i647ff98ftde208ca753f88f0d@mail.gmail.com> <48079F85.5030408@gmail.com> <5ab17e790804181028i20a6961au8ca528871170b460@mail.gmail.com> <4808E2AE.2080703@gmail.com> <844A9499-D833-4D29-8457-6695F94FCA64@math.su.se> Message-ID: <322FEA93-FF4D-4E33-ADEC-8468D14891D9@math.su.se> On 25 Apr 2008, at 15:38, Tom Schrijvers wrote: >>> Prolog works under the assumption of a closed world. That's >>> contrary to the open world view of regular type classes. So these >>> aren't the intended semantics. >> >> By which I gather you mean the interpretation of ":-" as logical >> connective "=>" rather than provability "|-"? > > What I meant was that when Prolog says "there are no more > solutions", it doesn't know of any more. In realtiy it means "there > no more solutions under the closed world assumption". That means > there could be more solutions if you haven't told Prolog > everything. In this context, there may be more class instances (you > simply haven't told the system yet). I had no intention to deal with that problem. Just forget what Prolog says, and when it says "there are no more solutions" think of it as "no more solutions determined". (If one interprets ":-" as provability "|-", there needs to be additional axioms for the object theory, and if the theory is consistent, it becomes possible to prove that there are no more solutions.) >> My point, though, was to interpret >> class a b | a -> b >> as a functional dependency b = b(a) rather than as >> D a b, D a c ==> b=c >> Thus trying to eliminate the use of "=". > > I don't follow you here. I got ?- instance(d, l(A), l(B)). B = b(A) ?- instance(d, l(A), C). C = l(b(A)) so pattern-wise C and l(B) are the same. But I do not bother introduce an explicit operator "=". So at least in this case, if say D [a] Int will be reject as Int is not of the feom l(_). If one has D [Int] [Char] and tries to define D [Int] [Float], the leads to trying to associate the implicit b(Int) with both Char and Float, which would be rejected. Hans From dons at galois.com Fri Apr 25 11:36:52 2008 From: dons at galois.com (Don Stewart) Date: Fri Apr 25 11:31:36 2008 Subject: [Haskell-cafe] Haskell Web server In-Reply-To: <1ff5dedc0804250728y7c128270v23ecf62ad8c39ef7@mail.gmail.com> References: <1ff5dedc0804250728y7c128270v23ecf62ad8c39ef7@mail.gmail.com> Message-ID: <20080425153652.GA3198@scytale.galois.com> cetin.sert: > Hi, > > What is the fastest way to set up a web server that can redirect requests > to a haskell application and serve results returned by it? > > I need to demonstrate a simple visualization tool I have written for > analytic tableaux on Monday and need something easy and simple. apache and cgi? -- Don From r.kelsall at millstream.com Fri Apr 25 12:30:09 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Fri Apr 25 12:24:53 2008 Subject: [Haskell-cafe] Why doesn't GHC use the Hugs definition of splitAt to avoid traversing the first part of the list twice? Message-ID: <48120711.7060306@millstream.com> I've just been investigating a performance oddity in using splitAt on a long stream of random numbers. I don't understand why GHC appears to want to traverse the first part of the list twice. GHC seems to implement the splitAt function something like splitAt n xs = (take n xs, drop n xs) whereas Hugs is something like splitAt n (x : xs) = (x : xs', xs'') where (xs', xs'') = splitAt (n-1) xs which seems much more sensible to me. Wouldn't it be better to change GHC to the Hugs method? Have I misunderstood something? Richard. From ogina at mac.com Fri Apr 25 12:54:42 2008 From: ogina at mac.com (Jennifer Miller) Date: Fri Apr 25 12:49:26 2008 Subject: [Haskell-cafe] n00b circular dep question Message-ID: <77D13781-0119-1000-9CDD-7E9716BA858D-Webmail-10007@mac.com> Hi all, This is my first post, and I'm a n00b, so go easy if I breach protocol. :-) I have a graph where the nodes contain a number of fields of various types. The values for one of those fields -- call it Mass -- need to reside in a separate file from the main graph definition (this is for workflow reasons and is given to me as a constraint). In order to set the Mass for a particular node, I need access to the other fields of that node. The other constraint is that the graph needs to be available in an interpreter (eg GHCi). So, I have a circular dependency in my modules that I don't know how to resolve in Haskell. I went looking for the equivalent of #include which is how I would have solved this in C++. I'm sure there is a simple answer to this and I'm hoping this group can point me in the right direction. Many thanks, ogina From qdunkan at gmail.com Fri Apr 25 13:33:19 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Fri Apr 25 13:28:03 2008 Subject: [Haskell-cafe] functional update In-Reply-To: <7ca3f0160804240208j6a5792e9i23309a1d6e5aa34a@mail.gmail.com> References: <2518b95d0804211112k1eae26d2j6fa0a5befd4c772@mail.gmail.com> <2f9b2d30804211643p29a8c685g92233f8a69bef03c@mail.gmail.com> <7ca3f0160804240208j6a5792e9i23309a1d6e5aa34a@mail.gmail.com> Message-ID: <2518b95d0804251033j532c5fe1r3a7f6859cfd920a5@mail.gmail.com> Thanks everyone, this is all good stuff. I did look at Clean and it looks like it has somewhat nicer record syntax... but it doesn't look like anything haskell couldn't do better if it one day got a real record system. As for the rest of Clean, I'm afraid that spending too much time with it will just make me wish for more features in haskell :) I'm going to experiment with the TH and FRef stuff. Maybe someday when we have a nice record system, these techniques can be standardized and integrated into the standard library. From jake.mcarthur at gmail.com Fri Apr 25 13:47:12 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Fri Apr 25 13:41:57 2008 Subject: [Haskell-cafe] n00b circular dep question In-Reply-To: <77D13781-0119-1000-9CDD-7E9716BA858D-Webmail-10007@mac.com> References: <77D13781-0119-1000-9CDD-7E9716BA858D-Webmail-10007@mac.com> Message-ID: On Apr 25, 2008, at 11:54 AM, Jennifer Miller wrote: > I have a circular dependency in my modules that I don't know how to > resolve in Haskell. I'm pretty sure that GHC will sort out those dependencies for you as long as you are exporting the correct things from each module. - Jake From atomb at galois.com Fri Apr 25 14:02:33 2008 From: atomb at galois.com (Aaron Tomb) Date: Fri Apr 25 13:57:17 2008 Subject: [Haskell-cafe] n00b circular dep question In-Reply-To: <77D13781-0119-1000-9CDD-7E9716BA858D-Webmail-10007@mac.com> References: <77D13781-0119-1000-9CDD-7E9716BA858D-Webmail-10007@mac.com> Message-ID: On Apr 25, 2008, at 9:54 AM, Jennifer Miller wrote: > So, I have a circular dependency in my modules that I don't know how > to resolve in Haskell. I went looking for the equivalent of #include > which is how I would have solved this in C++. I'm sure there is a > simple answer to this and I'm hoping this group can point me in the > right direction. GHC supports CPP, so you could take the same approach in Haskell. # cat Main.hs data Foo = Foo { x :: Int, y :: Int } deriving Show foo = Foo { x = 2, #include "y.hs" } # cat y.hs y = (x foo) + 2 # ghci -cpp Main.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( Main.hs, interpreted ) Ok, modules loaded: Main. *Main> foo Foo {x = 2, y = 4} *Main> Aaron From bulat.ziganshin at gmail.com Fri Apr 25 14:07:40 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Apr 25 14:06:20 2008 Subject: [Haskell-cafe] n00b circular dep question In-Reply-To: <77D13781-0119-1000-9CDD-7E9716BA858D-Webmail-10007@mac.com> References: <77D13781-0119-1000-9CDD-7E9716BA858D-Webmail-10007@mac.com> Message-ID: <109832727.20080425220740@gmail.com> Hello Jennifer, Friday, April 25, 2008, 8:54:42 PM, you wrote: > So, I have a circular dependency in my modules that I don't know > how to resolve in Haskell. 1. haskell standard allows circular deps between modules 2. ghc supports this part of standard in a rather awkward way - you need to generate .hs-boot files using some switch (look into docs). which is like .h files generated automatic from .cpp. once these files aregenerated, your circular deps will be ok -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From mail at joachim-breitner.de Fri Apr 25 14:15:57 2008 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri Apr 25 14:10:50 2008 Subject: [Haskell-cafe] My try for a CoroutineT monad tranformer Message-ID: <1209147357.7546.14.camel@otto.ehbuehl.net> Hi, (for those who follow planet.haskell.org this is old news, but I thought I?d tell the others) In http://www.joachim-breitner.de/blog/archives/291-Pausable-IO-actions-for-better-GUI-responsiveness.html I describe how I wrote a monad transformer that allows me to pause a computation from within by returning another computation that I can use to re-start the computation (or to throw it away if I want). I needed this for a long running drawing computation in a gtk2hs program that I want to pause at convenient points (to allow user interaction), and that I need to abort when what I?m drawing is not up-to-date anymore. The API basically consists of the function > runCoroutineT :: Monad m => CoroutineT m () -> m (Maybe (CoroutineT m ())) which runs the pausable computation, any Maybe returns Just the resume action, and the function > pause :: Monad m => CoroutineT m () to be used inside the computation, which pauses it. I have put the complete module in the darcs repository that might later also contain the GUI program at http://darcs.nomeata.de/FrakView/ What do you think of CoroutineT? Could it have been easily implemented using the existing monad transformers? Is it useful enough so that it should be included somewhere, and where? Are there any problems with strictness or other tripping points that I have overlooked? Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080425/4bb95560/attachment.bin From westondan at imageworks.com Fri Apr 25 14:49:12 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri Apr 25 14:43:54 2008 Subject: [Haskell-cafe] My try for a CoroutineT monad tranformer In-Reply-To: <1209147357.7546.14.camel@otto.ehbuehl.net> References: <1209147357.7546.14.camel@otto.ehbuehl.net> Message-ID: <481227A8.3010508@imageworks.com> I guess like minds think alike! See the very recent e-mail thread started by Ryan Ingram: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/39155/focus=39159 Take a look at the code referenced in Luke Palmer's reply: http://luqui.org/git/?p=luqui-misc.git;a=blob;f=work/code/haskell/frp/Fregl/Suspend.hs A snippet follows: > class (Monad m) => MonadSuspend v m | m -> v where > attempt :: m a -> m (Either a (v -> m a)) > suspend :: m v > > newtype SuspendT v m a > = SuspendT { runSuspendT :: m (Either a (v -> SuspendT v m a)) } Your (Coroutine m a) appears to be isomorphic to (SuspendT () m a) [so Coroutine m () = SuspendT () m ()] Your runCoroutineT appears to be isomorphic to a specialization of runSuspendT: runSuspendT' :: SuspendT () m () -> m (Either () (() -> SuspendT () m ())) Here the () -> a ~ a and Either () a ~ Maybe a Dan Joachim Breitner wrote: > Hi, > > (for those who follow planet.haskell.org this is old news, but I thought > I?d tell the others) > > In > http://www.joachim-breitner.de/blog/archives/291-Pausable-IO-actions-for-better-GUI-responsiveness.html > I describe how I wrote a monad transformer that allows me to pause a > computation from within by returning another computation that I can use > to re-start the computation (or to throw it away if I want). I needed > this for a long running drawing computation in a gtk2hs program that I > want to pause at convenient points (to allow user interaction), and that > I need to abort when what I?m drawing is not up-to-date anymore. > > The API basically consists of the function >> runCoroutineT :: Monad m => CoroutineT m () -> m (Maybe (CoroutineT m ())) > which runs the pausable computation, any Maybe returns Just the resume > action, and the function >> pause :: Monad m => CoroutineT m () > to be used inside the computation, which pauses it. > > I have put the complete module in the darcs repository that might later > also contain the GUI program at http://darcs.nomeata.de/FrakView/ > > What do you think of CoroutineT? Could it have been easily implemented > using the existing monad transformers? Is it useful enough so that it > should be included somewhere, and where? Are there any problems with > strictness or other tripping points that I have overlooked? > > Greetings, > Joachim > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From mail at joachim-breitner.de Fri Apr 25 15:23:20 2008 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri Apr 25 15:18:10 2008 Subject: [Haskell-cafe] My try for a CoroutineT monad tranformer In-Reply-To: <481227A8.3010508@imageworks.com> References: <1209147357.7546.14.camel@otto.ehbuehl.net> <481227A8.3010508@imageworks.com> Message-ID: <1209151400.7546.19.camel@otto.ehbuehl.net> Hi, Am Freitag, den 25.04.2008, 11:49 -0700 schrieb Dan Weston: > I guess like minds think alike! See the very recent e-mail thread > started by Ryan Ingram: > http://thread.gmane.org/gmane.comp.lang.haskell.cafe/39155/focus=39159 > > Take a look at the code referenced in Luke Palmer's reply: > http://luqui.org/git/?p=luqui-misc.git;a=blob;f=work/code/haskell/frp/Fregl/Suspend.hs > > A snippet follows: > > > class (Monad m) => MonadSuspend v m | m -> v where > > attempt :: m a -> m (Either a (v -> m a)) > > suspend :: m v > > > > newtype SuspendT v m a > > = SuspendT { runSuspendT :: m (Either a (v -> SuspendT v m a)) } > > Your (Coroutine m a) appears to be isomorphic to (SuspendT () m a) [so > Coroutine m () = SuspendT () m ()] > > Your runCoroutineT appears to be isomorphic to a specialization of > runSuspendT: > > runSuspendT' :: SuspendT () m () -> m (Either () (() -> SuspendT () m ())) > > Here the () -> a ~ a and Either () a ~ Maybe a You are quite right, it really is the same thing. The implementation behind runCoroutineT is not just a specialization, but the exact same thing (with Left and Right switched). I just put the specialization there because I had no need for a return value in my use case. And interesting how Ryan and me had the same thoughts on the same day. Maybe the April 24th should be considered Suspend You Monadic Action Day. Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080425/86613df8/attachment.bin From westondan at imageworks.com Fri Apr 25 15:45:01 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri Apr 25 15:39:44 2008 Subject: [Haskell-cafe] My try for a CoroutineT monad tranformer In-Reply-To: <1209151400.7546.19.camel@otto.ehbuehl.net> References: <1209147357.7546.14.camel@otto.ehbuehl.net> <481227A8.3010508@imageworks.com> <1209151400.7546.19.camel@otto.ehbuehl.net> Message-ID: <481234BD.2000108@imageworks.com> Is there a Haskell Wiki page (or blog) on Monad Suspension? This looks like a nice paradigm that apfelmus points out "can be used to considerably shorten your code", but only if the rest of us learn how! If not, maybe someone can be persuaded to write one? Dan Joachim Breitner wrote: > Hi, > > Am Freitag, den 25.04.2008, 11:49 -0700 schrieb Dan Weston: >> I guess like minds think alike! See the very recent e-mail thread >> started by Ryan Ingram: >> http://thread.gmane.org/gmane.comp.lang.haskell.cafe/39155/focus=39159 >> >> Take a look at the code referenced in Luke Palmer's reply: >> http://luqui.org/git/?p=luqui-misc.git;a=blob;f=work/code/haskell/frp/Fregl/Suspend.hs >> >> A snippet follows: >> >> > class (Monad m) => MonadSuspend v m | m -> v where >> > attempt :: m a -> m (Either a (v -> m a)) >> > suspend :: m v >> > >> > newtype SuspendT v m a >> > = SuspendT { runSuspendT :: m (Either a (v -> SuspendT v m a)) } >> >> Your (Coroutine m a) appears to be isomorphic to (SuspendT () m a) [so >> Coroutine m () = SuspendT () m ()] >> >> Your runCoroutineT appears to be isomorphic to a specialization of >> runSuspendT: >> >> runSuspendT' :: SuspendT () m () -> m (Either () (() -> SuspendT () m ())) >> >> Here the () -> a ~ a and Either () a ~ Maybe a > > You are quite right, it really is the same thing. The implementation > behind runCoroutineT is not just a specialization, but the exact same > thing (with Left and Right switched). I just put the specialization > there because I had no need for a return value in my use case. > > And interesting how Ryan and me had the same thoughts on the same day. > Maybe the April 24th should be considered Suspend You Monadic Action > Day. > > Greetings, > Joachim > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From chaddai.fouche at gmail.com Fri Apr 25 16:30:20 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Fri Apr 25 16:25:04 2008 Subject: a faster, accumulating mapM (was Re: [Haskell-cafe] mapM vs mapM_ performance) In-Reply-To: References: <9157df230804241414j6c92a01cuccf4b6416bf9f370@mail.gmail.com> <1953845415.20080425013350@gmail.com> <9157df230804241628p54cd8c31s4b0a961efc1144fc@mail.gmail.com> <7ca3f0160804241645q3a08261bt3fe05d264fca7721@mail.gmail.com> Message-ID: 2008/4/25, Niklas Broberg : > Wow. A 10x slowdown for a very commonly used function that in 99.8% of > all use cases has no need for the extra laziness at all. No wonder > some people say Haskell is a toy language... > A toy language that is still much faster than many currently popular languages so... Is Ruby/Python/... a toy too ? Still these numbers seems odd, there's probably something that don't optimize very well here. -- Jeda? From ben.franksen at online.de Fri Apr 25 17:03:38 2008 From: ben.franksen at online.de (Ben Franksen) Date: Fri Apr 25 17:04:20 2008 Subject: [Haskell-cafe] Re: I hate Haskell's typeclasses References: <2f9b2d30804182129m295c89b3m25777ad0166b7c3d@mail.gmail.com> <00F07605-C8AA-49C9-A494-D10E635C4120@fastmail.fm> Message-ID: Jonathan Cast wrote: > Type case is easy: > > genericShow :: Typeable a => a -> String > genericShow x = fromJust $ do > s <- cast x :: Maybe String > return s > `mplus` do > n <- cast x :: Maybe Int > return (show n) > `mplus` do > return "" This is a nice idiom I didn't know before. Definitely worth page on the wiki or two. Cheers Ben From niklas.broberg at gmail.com Fri Apr 25 17:47:47 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Fri Apr 25 17:42:28 2008 Subject: a faster, accumulating mapM (was Re: [Haskell-cafe] mapM vs mapM_ performance) In-Reply-To: References: <9157df230804241414j6c92a01cuccf4b6416bf9f370@mail.gmail.com> <1953845415.20080425013350@gmail.com> <9157df230804241628p54cd8c31s4b0a961efc1144fc@mail.gmail.com> <7ca3f0160804241645q3a08261bt3fe05d264fca7721@mail.gmail.com> Message-ID: > > Wow. A 10x slowdown for a very commonly used function that in 99.8% of > > all use cases has no need for the extra laziness at all. No wonder > > some people say Haskell is a toy language... > > A toy language that is still much faster than many currently popular > languages so... Is Ruby/Python/... a toy too ? I didn't say I agree, I most certainly don't. What I meant with my comment was that a slowdown of 10x, just to preserve laziness, is perfect fuel for those who claim that laziness is good in theory but bad in practice. And my alarm was more directed towards the fact that others seemed to find that perfectly acceptable. There are of course mitigating factors, in particular that mapM is rather uncommon over input lists that size, and for smaller list (say 50k instead of 500k) the slowdown isn't even half as bad (more like 2-3x). But I'm glad to hear that Simon is alarmed too. ;-) Cheers, /Niklas From lemming at henning-thielemann.de Fri Apr 25 17:49:04 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Apr 25 17:42:39 2008 Subject: [Haskell-cafe] n00b circular dep question In-Reply-To: <77D13781-0119-1000-9CDD-7E9716BA858D-Webmail-10007@mac.com> References: <77D13781-0119-1000-9CDD-7E9716BA858D-Webmail-10007@mac.com> Message-ID: On Fri, 25 Apr 2008, Jennifer Miller wrote: > I have a graph where the nodes contain a number of fields of various types. The values for one of those fields -- call it Mass -- need to reside in a separate file from the main graph definition (this is for workflow reasons and is given to me as a constraint). In order to set the Mass for a particular node, I need access to the other fields of that node. The other constraint is that the graph needs to be available in an interpreter (eg GHCi). > > So, I have a circular dependency in my modules that I don't know how to resolve in Haskell. I went looking for the equivalent of #include which is how I would have solved this in C++. I'm sure there is a simple answer to this and I'm hoping this group can point me in the right direction. Sometimes circular module dependencies can be solved by using a type parameter. mutually recursive: module A where data LabeledTree label = LabeledTree label (Tree label) module B where data Tree label = Branch (LabeledTree label) (LabeledTree label) | Leaf no mutual recursion: module A where data LabeledTreeGen tree label = LabeledTree label (tree label) module B where type LabeledTree label = LabeledTreeGen Tree label data Tree label = Branch (LabeledTree label) (LabeledTree label) | Leaf From dave at zednenem.com Fri Apr 25 20:42:03 2008 From: dave at zednenem.com (David Menendez) Date: Fri Apr 25 20:36:44 2008 Subject: [Haskell-cafe] My try for a CoroutineT monad tranformer In-Reply-To: <481234BD.2000108@imageworks.com> References: <1209147357.7546.14.camel@otto.ehbuehl.net> <481227A8.3010508@imageworks.com> <1209151400.7546.19.camel@otto.ehbuehl.net> <481234BD.2000108@imageworks.com> Message-ID: <49a77b7a0804251742k3ce5bcd7va40ed1f54f2ae622@mail.gmail.com> On Fri, Apr 25, 2008 at 3:45 PM, Dan Weston wrote: > Is there a Haskell Wiki page (or blog) on Monad Suspension? This looks like > a nice paradigm that apfelmus points out "can be used to considerably > shorten your code", but only if the rest of us learn how! There are a few papers which deal with resumption monads, which appear to be closely related. You can also express CoroutineT (or something very much like it) using a free monad. data Term f a = Var a | Branch (f (Term f a)) instance Functor f => Monad (Term f) where return = Var Var a >>= f = f a Branch as >>= f = Branch (fmap (>>= f) as) lift :: (Functor f) => f a -> Term f a lift m = Branch (fmap Var m) runTerm :: (Monad m) => Term m () -> m (Maybe (Term m ())) runTerm (Var ()) = return Nothing runTerm (Branch m) = fmap Just m pause :: (Monad m) => Term m () pause = Branch (return (Var ())) Note that runTerm and pause really only require Applicative. I believe Suspend can be implemented similarly. Note that "SuspendT v m a" is isomorphic to "m (Term (ReaderT v m) a)". -- Dave Menendez From ps.haskell at gmail.com Fri Apr 25 22:05:06 2008 From: ps.haskell at gmail.com (Peter Schmitz) Date: Fri Apr 25 21:59:49 2008 Subject: [Haskell-cafe] Trying to build a stand-alone executable GLUT app with ghc, Windows XP Message-ID: Problem summary Trying to build a stand-alone executable GLUT app with ghc, Windows XP Problem description I compile and link (without errors) a simple GLUT application under Windows XP. When I run it, XP pops an error window saying the app cannot start due to a missing "glut32.dll". I want to do a static build to create a stand-alone executable GLUT app under Windows XP, without using DLL files, or placing any files in the Windows system dir. This is my first GUI code in Haskell, and I chose GLUT because it is a standard library. Following are some details. Thanks much for any advice. Source code -- Simple GLUT app to create a window module Main(main) where import Graphics.Rendering.OpenGL import Graphics.UI.GLUT main = do (progname, _) <- getArgsAndInitialize createWindow "Hello World" mainLoop Compile/run Environment ghc-6.8.2 on a USB flashdrive under a non-admin Windows XP account ghc dir is not on C: E:\apps\ghc\ghc-6.8.2 XP shell used: cmd.exe shell path E:\ghcTest>path PATH=C:\WINDOWS\system32;C:\WINDOWS;E:\apps\ghc\ghc-6.8.2\bin;.\ ghc library path E:\ghcTest>ghc --print-libdir E:/apps/ghc/ghc-6.8.2 compile/link output E:\ghcTest>ghc --make x -package GLUT [1 of 1] Compiling Main ( x.hs, x.o ) Linking x.exe ... E:\ghcTest> files (sizes in bytes) 186 x.hs 387 x.hi 3,184 x.o 498 x.exe.manifest 609,222 x.exe When application is run Error dialog window pops up window title a.exe - Unable To Locate Component window text The application has failed to start because glut32.dll was not found. Re-installing the application may fix this problem. No output in shell; no glut window is created. Other builds tried; same runtime error ghc --make x -package GLUT -static ghc -package GLUT x.hs -o x ghc --make x -package GLUT -LE:\apps\ghc\ghc-6.8.2\lib\GLUT-2.1.1.1 ghc --make x -LE:\apps\ghc\ghc-6.8.2\lib\GLUT-2.1.1.1 -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080425/4193c485/attachment-0001.htm From mad.one at gmail.com Fri Apr 25 22:22:50 2008 From: mad.one at gmail.com (Austin Seipp) Date: Fri Apr 25 22:17:38 2008 Subject: [Haskell-cafe] Trying to build a stand-alone executable GLUT app with ghc, Windows XP In-Reply-To: References: Message-ID: <1209176356-sup-2806@continuum> Perhaps try: $ ghc --make -static -optl-static -l x.hs The -optl-static passes the '-static' argument to ld so it will link statically; you may also need a copy of a compatable GLUT library in .a format on your windows machine which should be linked in with -l as well (where you can get this, I do not know.) -- "It was in the days of the rains that their prayers went up, not from the fingering of knotted prayer cords or the spinning of prayer wheels, but from the great pray-machine in the monastery of Ratri, goddess of the Night." Roger Zelazny From jefferson.r.heard at gmail.com Fri Apr 25 22:23:58 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Fri Apr 25 22:18:40 2008 Subject: [Haskell-cafe] Trying to build a stand-alone executable GLUT app with ghc, Windows XP In-Reply-To: References: Message-ID: <4165d3a70804251923j581ed220g35ad26a80652e268@mail.gmail.com> Google "download glut32.dll" and pull that file down and put it in the directory with your executable. I'd attach it myself, but gmail won't let me. I use that all the time, though. 2008/4/25 Peter Schmitz : > Problem summary > > Trying to build a stand-alone executable GLUT app with ghc, Windows XP > > Problem description > > I compile and link (without errors) a simple GLUT application under Windows > XP. > When I run it, XP pops an error window saying the app cannot start due to a > missing "glut32.dll". > > I want to do a static build to create a stand-alone executable GLUT app > under Windows XP, > without using DLL files, or placing any files in the Windows system dir. > This is my first GUI code in Haskell, and I chose GLUT because it is a > standard library. > > Following are some details. > Thanks much for any advice. > > Source code > > -- Simple GLUT app to create a window > module Main(main) where > > import Graphics.Rendering.OpenGL > import Graphics.UI.GLUT > > main = do > (progname, _) <- getArgsAndInitialize > createWindow "Hello World" > mainLoop > > Compile/run Environment > > ghc-6.8.2 on a USB flashdrive under a non-admin Windows XP account > > ghc dir is not on C: > > E:\apps\ghc\ghc-6.8.2 > > XP shell used: cmd.exe > > shell path > > E:\ghcTest>path > > PATH=C:\WINDOWS\system32;C:\WINDOWS;E:\apps\ghc\ghc-6.8.2\bin;.\ > > ghc library path > > E:\ghcTest>ghc --print-libdir > > E:/apps/ghc/ghc-6.8.2 > > compile/link output > > E:\ghcTest>ghc --make x -package GLUT > > [1 of 1] Compiling Main ( x.hs, x.o ) > > Linking x.exe ... > > E:\ghcTest> > > files (sizes in bytes) > > 186 x.hs > 387 x.hi > 3,184 x.o > 498 x.exe.manifest > 609,222 x.exe > > When application is run > > Error dialog window pops up > > window title > > a.exe - Unable To Locate Component > > window text > > The application has failed to start because glut32.dll was not found. > Re-installing the application may fix this problem. > > No output in shell; no glut window is created. > > > > Other builds tried; same runtime error > > ghc --make x -package GLUT -static > > ghc -package GLUT x.hs -o x > > ghc --make x -package GLUT -LE:\apps\ghc\ghc-6.8.2\lib\GLUT-2.1.1.1 > > ghc --make x -LE:\apps\ghc\ghc-6.8.2\lib\GLUT-2.1.1.1 > > -- > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080425/95254f44/attachment.htm From ogina at mac.com Fri Apr 25 23:50:51 2008 From: ogina at mac.com (Jennifer Miller) Date: Fri Apr 25 23:45:34 2008 Subject: [Haskell-cafe] n00b circular dep question In-Reply-To: References: <77D13781-0119-1000-9CDD-7E9716BA858D-Webmail-10007@mac.com> Message-ID: <7FAB9183-0119-1000-9D0C-3E38DE0B1188-Webmail-10023@mac.com> Thanks for the suggestions. The #include worked but I will look for ways to remove the circular dependency altogether. Jennifer On Friday, April 25, 2008, at 02:48PM, "Henning Thielemann" wrote: > >On Fri, 25 Apr 2008, Jennifer Miller wrote: > >> I have a graph where the nodes contain a number of fields of various types. The values for one of those fields -- call it Mass -- need to reside in a separate file from the main graph definition (this is for workflow reasons and is given to me as a constraint). In order to set the Mass for a particular node, I need access to the other fields of that node. The other constraint is that the graph needs to be available in an interpreter (eg GHCi). >> >> So, I have a circular dependency in my modules that I don't know how to resolve in Haskell. I went looking for the equivalent of #include which is how I would have solved this in C++. I'm sure there is a simple answer to this and I'm hoping this group can point me in the right direction. > > >Sometimes circular module dependencies can be solved by using a type parameter. > > >mutually recursive: > >module A where > >data LabeledTree label = LabeledTree label (Tree label) > > >module B where > >data Tree label = Branch (LabeledTree label) (LabeledTree label) | Leaf > > > > >no mutual recursion: > >module A where > >data LabeledTreeGen tree label = LabeledTree label (tree label) > > >module B where > >type LabeledTree label = LabeledTreeGen Tree label > >data Tree label = Branch (LabeledTree label) (LabeledTree label) | Leaf > > From ken.takusagawa.2 at gmail.com Sat Apr 26 02:36:43 2008 From: ken.takusagawa.2 at gmail.com (Ken Takusagawa) Date: Sat Apr 26 02:31:32 2008 Subject: [Haskell-cafe] asserting the type of a binding in a "do" expression Message-ID: <4dcea1d80804252336m4a5a1704m7890cbc942e479ac@mail.gmail.com> This works (with -fglasgow-exts): foo::IO Int; foo = do{ (x::Int) <- bar; return x;}; bar = undefined But this does not: foo::IO a; foo = do{ (x::a) <- bar; return x;}; Error message: A pattern type signature cannot bind scoped type variables `a' unless the pattern has a rigid type context. How can I accomplish my goal of asserting the type of x, as a programmer sanity check, when there are type variables? Thanks, --ken From allbery at ece.cmu.edu Sat Apr 26 02:49:32 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Apr 26 02:44:14 2008 Subject: [Haskell-cafe] asserting the type of a binding in a "do" expression In-Reply-To: <4dcea1d80804252336m4a5a1704m7890cbc942e479ac@mail.gmail.com> References: <4dcea1d80804252336m4a5a1704m7890cbc942e479ac@mail.gmail.com> Message-ID: On Apr 26, 2008, at 2:36 , Ken Takusagawa wrote: > But this does not: > > foo::IO a; > foo = do{ > (x::a) <- bar; > return x;}; > > Error message: A pattern type signature cannot bind scoped type > variables `a' unless the pattern has a rigid type context. This works for me (in a slightly out of date HEAD) if I explicitly forall the declaration as per the ghc manual (see section 8.7.6.3): > bar :: forall b. IO b > bar = return undefined -- just want a type for now > foo :: forall a. IO a > foo = do { (x :: a) <- bar; return x; } -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From andrewcoppin at btinternet.com Sat Apr 26 03:33:42 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Apr 26 03:28:00 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <200804242139.46355.jon@ffconsultancy.com> References: <4807B6D1.7090006@cs.pdx.edu> <480FCD87.7010803@cs.pdx.edu> <4810DFAE.8040807@btinternet.com> <200804242139.46355.jon@ffconsultancy.com> Message-ID: <4812DAD6.8060707@btinternet.com> Jon Harrop wrote: > On Thursday 24 April 2008 20:29:50 Andrew Coppin wrote: > >> 2. It's the only program I've seen that can render *real* curves, not >> fake trickery with triangle meshes. >> > > What you called "fake trickery with triangle meshes" is the core of all modern > computer graphics. Focussing on ray tracing instead of that is rather missing > the point, IMHO. > Well, that rather depends on what your "point" is, doesn't it? Personally, I don't see the point in rendering a couple of million mathematically flat surfaces, and then trying to blur the edges to give the false illusion of a curved surface - when you could just, you know, render a real curved surface. Sure, surface normal tricks can make lighting and reflections look almost correct, but they won't fix profile views, shadows and self-shadows, intersections, or any of the other artifacts caused by using triangles. But anyway, this is wandering off-topic. Suffice it to say, for my humble little hobby graphics, I intend to stick to ray tracing. If you disagree, feel free to use something else for your stuff. :-) From andrewcoppin at btinternet.com Sat Apr 26 03:50:05 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Apr 26 03:44:23 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <48115F3E.6020305@cs.pdx.edu> References: <4807B6D1.7090006@cs.pdx.edu> <20080418184327.GB3462@scytale.galois.com> <4809002F.8010302@cs.pdx.edu> <4310375315.20080419001919@gmail.com> <20080418203222.GQ8763@darcs.net> <48090E08.1020109@cs.pdx.edu> <20080418213405.GT8763@darcs.net> <1208968967.5538.22.camel@derek-laptop> <480FCD87.7010803@cs.pdx.edu> <4810DFAE.8040807@btinternet.com> <48115F3E.6020305@cs.pdx.edu> Message-ID: <4812DEAD.60609@btinternet.com> Jim Snow wrote: > The Scene Description Language (SDL) is the best and worst thing about > POV-Ray. Indeed. > It's very intuitive and user-friendly, so a person can reasonably > write a complex scene in pure code without using an external GUI editor. Not to mention that there's a smooth and continuous path from "I rendered a reflective sphere on a chequered plane" to "I build a complex CSG object" to "I wrote my first animation" to "I just built a particle physics system / fractal terrain generator / inverse kinetics animator / whatever". > Unfortunately, the SDL is so complex it's well-nigh impossible to > support in other third-party applications. I don't think it would be "impossible" to support in 3rd party apps. A lot of work, certainly! Especially the way the parser does parsing and macro expansion in the same pass, so a macro body need not contain a syntactically-complete code fragment. I think if somebody sat down and wrote something that would do all the macro expansion, variable substitution and so forth to leave just few geometry descriptions, *those* would be quite easy to parse and manipulate for 3rd parties. > It's also slow. The scene has to be re-parsed for every frame. For > complex scenes, the scene parsing could take longer than the actual > render. For complex scenes, or scenes involving complex algorithms like fractal generation or something, parsing can indeed take far longer than rendering. The SDL is basically a scripting language. It's kinda flexible in its own way, but totally useless in speed terms. It also lacks all the features of a "real" programming language - abstraction, encapsulation, rich data types, powerful control structures... actually, all the things that Haskell excells at. I did start a project a while back to try and make it possible to describe POV-Ray scenes in Haskell, thus leveraging the full power of the language. But that never came to much... [The "clock" variable is one way to animate, yes. Another is to use the "frame_number" variable. A common idiom is to generate an initial state at frame #1, and on each frame, read the state from disk, update it, write the updated version back to disk, and then render the frame. Obviously this destroys the ability to render frames in arbitrary order or distribute them across a render farm, but that's rather unavoidable. Note that the loading and saving must be hand-coded, from scratch, every time you want to do this. Tedious...] >> Personally, I'd quite like to write my own ray tracer to address some >> of these limitations. But every time I try, I end up hitting design >> issues [Haskell works very differently to Java] or performance issues >> [which I don't even know how to begin debugging]. Not to mention that >> POV-Ray uses sophisticated techniques like volume bounding that I >> know nothing about. (There's nothing like using an inherantly >> superior algorithm to make your code orders of magnitude faster...) >> > I haven't really run into any issues where Haskell didn't let me do > what I want, except for the performance counters thing mentioned way > back at the beginning of this thread (and which I've more or less > given up on for now, since the acceleration structure seems to be > working okay and I have other things to work on). Well, for example, Haskell doesn't have hetrogenous lists - which are trivial in any OOP language. That's quite awkward to get around. Also, both spheres and cylinders have a "radius" property, but then you end up with name clashes. Again, a non-issue in OOP languages. [I gather there's some new GHC language extension to partially solve this one - but only when types are statically known. In the general case, you'd have to write a "radius class" and define instances... yuck!] > A good acceleration structure definitely makes everything go a lot > faster. It's the difference between rendering a scene in a few > seconds or ten minutes. > > BIH is what I'm using. It's relatively new. Here's a paper about > it: http://ainc.de/Research/BIH.pdf > > The actual constructor is based loosely on this pseudocode: > http://ompf.org/forum/viewtopic.php?p=1411#p1411 I'll take a look. Certainly all the ray tracers I've written just test every ray against every object - O(n) complexity? Hmm, that's not good[tm]... > You don't need to drop support for the whole multitude of primitives, > though the ones that are packet-friendly will render faster. Many > modern ray tracers spend most of their time traversing the > acceleration structure rather than doing intersection tests with > actual geometry, so all you really need to do to get most of the > benefit of packet tracing is to make the acceleration structure > support packets. (For the actual geometry, you can fall back on > mono-rays.) I tried 2x2 packets out last night and got about a 10-15% > speed improvement on the level-3 SPD sphereflake. (Shadow and > reflection rays are still mono rays; if I converted them over, the > improvement would presumably be more significant.) The simplifying > assumption you make when you're traversing the acceleration structure > with packets is that if one ray in the packet hits a bounding volume, > you assume that they all do. That adds a little overhead if the rays > are coherent (all starting near a common origin and pointing in almost > the same direction), or a lot of overhead if they aren't coherent. If > used appropriately, the performance gains outweigh the overhead by a > considerable margin. Something else to add to my list of "things I should look into"... > Cones and spheres and boxes and the like can be made into some fairly > elaborate scenes, but you can't really make, say, a realistic human > figure out of those sorts of primitives. No, but with things like isosurfaces and parametric surfaces, the world is your oyster. And you can do a surprising amount of things with blobs. I understand that all those curved surfaces which are currently popular in consumer electronics are done with splines, not triangles... > Also, real data sets like terrain or 3d-scanned geometry are easy to > represent as triangles. Well that's true enough... > It's appropriate to support both approaches, so you can do whatever > makes the most sense for the application. Indeed. And since I never use triangles for anything, I've never bothered working out how to support them. ;-) From lemming at henning-thielemann.de Sat Apr 26 05:09:02 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Apr 26 05:02:20 2008 Subject: [Haskell-cafe] asserting the type of a binding in a "do" expression In-Reply-To: <4dcea1d80804252336m4a5a1704m7890cbc942e479ac@mail.gmail.com> References: <4dcea1d80804252336m4a5a1704m7890cbc942e479ac@mail.gmail.com> Message-ID: On Sat, 26 Apr 2008, Ken Takusagawa wrote: > This works (with -fglasgow-exts): > > foo::IO Int; > foo = do{ > (x::Int) <- bar; > return x;}; > > bar = undefined > > But this does not: > > foo::IO a; > foo = do{ > (x::a) <- bar; > return x;}; > > Error message: A pattern type signature cannot bind scoped type > variables `a' unless the pattern has a rigid type context. 'asTypeOf' is the answer for Haskell98. You can also write your own helper functions which might simplify that for your use cases. From dav.vire+haskell at gmail.com Sat Apr 26 05:21:04 2008 From: dav.vire+haskell at gmail.com (david48) Date: Sat Apr 26 05:15:44 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <4812DAD6.8060707@btinternet.com> References: <4807B6D1.7090006@cs.pdx.edu> <480FCD87.7010803@cs.pdx.edu> <4810DFAE.8040807@btinternet.com> <200804242139.46355.jon@ffconsultancy.com> <4812DAD6.8060707@btinternet.com> Message-ID: <4c88418c0804260221n70603390hace0ddd1a9c0bb6a@mail.gmail.com> On Sat, Apr 26, 2008 at 9:33 AM, Andrew Coppin wrote: > Personally, I don't see the point in rendering a couple of million > mathematically flat surfaces, What about speed ? From ndmitchell at gmail.com Sat Apr 26 05:44:48 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Apr 26 05:39:28 2008 Subject: a faster, accumulating mapM (was Re: [Haskell-cafe] mapM vs mapM_ performance) In-Reply-To: References: <9157df230804241414j6c92a01cuccf4b6416bf9f370@mail.gmail.com> <1953845415.20080425013350@gmail.com> <9157df230804241628p54cd8c31s4b0a961efc1144fc@mail.gmail.com> <7ca3f0160804241645q3a08261bt3fe05d264fca7721@mail.gmail.com> Message-ID: <404396ef0804260244i3c8c951fmd12d5d9ed0d021b4@mail.gmail.com> Hi > I didn't say I agree, I most certainly don't. What I meant with my > comment was that a slowdown of 10x, just to preserve laziness, is > perfect fuel for those who claim that laziness is good in theory but > bad in practice. A bad implementation of laziness will always be slower than a bad implementation of strictness - as we have strict CPU's. However, laziness gives you some really cool opportunities for deforestation and supercompilation - so at some point Haskell will overcome the performance penalty of laziness and start to reap the performance benefits - I think... Thanks Neil From duncan.coutts at worc.ox.ac.uk Sat Apr 26 05:51:46 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Apr 26 05:46:12 2008 Subject: [Haskell-cafe] Why doesn't GHC use the Hugs definition of splitAt to avoid traversing the first part of the list twice? In-Reply-To: <48120711.7060306@millstream.com> References: <48120711.7060306@millstream.com> Message-ID: <1209203506.30059.31.camel@localhost> On Fri, 2008-04-25 at 17:30 +0100, Richard Kelsall wrote: > I've just been investigating a performance oddity in using splitAt > on a long stream of random numbers. I don't understand why GHC > appears to want to traverse the first part of the list twice. > > GHC seems to implement the splitAt function something like > > splitAt n xs = (take n xs, drop n xs) > > whereas Hugs is something like > > splitAt n (x : xs) = (x : xs', xs'') > where (xs', xs'') = splitAt (n-1) xs > > which seems much more sensible to me. Wouldn't it be better to change > GHC to the Hugs method? Have I misunderstood something? Actually GHC uses this definition, in GHC.List: #ifdef USE_REPORT_PRELUDE splitAt n xs = (take n xs, drop n xs) #else /* hack away */ splitAt (I# n#) ls | n# <# 0# = ([], ls) | otherwise = splitAt# n# ls where splitAt# :: Int# -> [a] -> ([a], [a]) splitAt# 0# xs = ([], xs) splitAt# _ xs@[] = (xs, xs) splitAt# m# (x:xs) = (x:xs', xs'') where (xs', xs'') = splitAt# (m# -# 1#) xs #endif /* USE_REPORT_PRELUDE */ So ghc's version should be of equivalent strictness to the hugs version. What's interesting here is that the H98 specification of splitAt is silly. It got 'simplified' from a previous version of the Haskell spec and is so doing it was made less strict. With this definition: splitAt n xs = (take n xs, drop n xs) splitAt _|_ _|_ = (_|_, _|_) but with the sensible definition it'd return _|_ and that's really the only point of having splitAt, so that you can walk down the list once rather than twice. If someone needs the very lazy version there's always take and drop. Duncan From scook0 at gmail.com Sat Apr 26 05:57:47 2008 From: scook0 at gmail.com (Stuart Cook) Date: Sat Apr 26 05:52:28 2008 Subject: [Haskell-cafe] n00b circular dep question In-Reply-To: <109832727.20080425220740@gmail.com> References: <77D13781-0119-1000-9CDD-7E9716BA858D-Webmail-10007@mac.com> <109832727.20080425220740@gmail.com> Message-ID: <49b351060804260257t2d881551p8827f2177242168@mail.gmail.com> On Sat, Apr 26, 2008 at 4:07 AM, Bulat Ziganshin wrote: > 2. ghc supports this part of standard in a rather awkward way - you > need to generate .hs-boot files using some switch (look into docs). > which is like .h files generated automatic from .cpp. once these files > aregenerated, your circular deps will be ok Are you sure? I would be very interested in a switch that automatically generates hs-boot files, but I've been unable to find any mention of it. Stuart From bulat.ziganshin at gmail.com Sat Apr 26 06:06:35 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Apr 26 06:05:08 2008 Subject: [Haskell-cafe] n00b circular dep question In-Reply-To: <49b351060804260257t2d881551p8827f2177242168@mail.gmail.com> References: <77D13781-0119-1000-9CDD-7E9716BA858D-Webmail-10007@mac.com> <109832727.20080425220740@gmail.com> <49b351060804260257t2d881551p8827f2177242168@mail.gmail.com> Message-ID: <1262308781.20080426140635@gmail.com> Hello Stuart, Saturday, April 26, 2008, 1:57:47 PM, you wrote: > Are you sure? I would be very interested in a switch that > automatically generates hs-boot files, but I've been unable to find > any mention of it. no, i never used this function, so you should be informed better -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From prstanley at ntlworld.com Sat Apr 26 07:01:21 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Sat Apr 26 06:55:59 2008 Subject: [Haskell-cafe] Function Type Calculation (revisited) Message-ID: <7.0.1.0.0.20080426115942.01cfb420@ntlworld.com> Hi I know we've already looked at the topic of function type calculation though last time I didn't have the chance to go through it thoroughly. So here it is again. Apologies for the repetition. I've had a try at calculating function types for two examples below. So to start with I'd be grateful for an assessment of my efforts. All comments are welcome. Thanks, Paul [1] funk f x = f (funk f) x f :: a x :: b funk f x :: c therefore funk :: a -> b -> c RHS f (funk f) x :: c f (funk f) :: d -> c x :: d f :: e -> d -> c funk :: h -> e f :: h unification f :: a = h = (e -> d -> c) x b = d therefore funk :: ((h -> e) -> b -> c) -> b -> c [2] w f = f f Assigning Types f :: a w f :: b therefore w :: a -> b RHS f f :: b f :: c -> b f :: c f :: a = b = c = (c -> b) therefore w :: (a -> a) -> a From ahey at iee.org Sat Apr 26 07:41:40 2008 From: ahey at iee.org (Adrian Hey) Date: Sat Apr 26 07:36:22 2008 Subject: [Haskell-cafe] lookup tables & style guidelines In-Reply-To: References: <1ff5dedc0804231334y1a14f93cobf6b97da93285728@mail.gmail.com> <20080423203634.GG22492@scytale.galois.com> <87r6cvzrtx.fsf@nmd9999.imr.no> <4810A863.4010703@iee.org> Message-ID: <481314F4.8070601@iee.org> Jan-Willem Maessen wrote: > > On Apr 24, 2008, at 11:33 AM, Adrian Hey wrote: > >> Also, if you're likely to be using union/intersection a lot you should >> know that Data.Map/Set are very slow for this because they use the >> not efficient hedge algorithm :-) > > OK, I'm going to bite here: What's the efficient algorithm for union on > balanced trees, given that hedge union was chosen as being more > efficient than naive alternatives (split and merge, repeated > insertion)? My going hypothesis has been "hedge union is an inefficient > algorithm, except that it's better than all those other inefficient > algorithms". Divide and conquer seems to be the most efficient, though not the algorithm presented in the Adams paper. Hedge algorithm performs many more comparisons than are needed, which is obviously bad if you don't know how expensive those comparisons are going to be. IIRC it was something like 4..5 times as many of 2 sets of a million or so random Ints. But even in favourable circumstances (tree elements are boxed Ints) divide and conquer on AVL trees seemed much faster than Hedge on Data.Set. Of course ideally we would want implementations of Hedge for AVL and divide and conquer for Data.Set too, but I didn't feel inclined to write them. Regards -- Adrian Hey From r.kelsall at millstream.com Sat Apr 26 09:02:30 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Sat Apr 26 08:57:11 2008 Subject: [Haskell-cafe] Why doesn't GHC use the Hugs definition of splitAt to avoid traversing the first part of the list twice? In-Reply-To: <1209203506.30059.31.camel@localhost> References: <48120711.7060306@millstream.com> <1209203506.30059.31.camel@localhost> Message-ID: <481327E6.5060906@millstream.com> Duncan Coutts wrote: > On Fri, 2008-04-25 at 17:30 +0100, Richard Kelsall wrote: >> I've just been investigating a performance oddity in using splitAt >> on a long stream of random numbers. I don't understand why GHC >> appears to want to traverse the first part of the list twice. >> >> GHC seems to implement the splitAt function something like >> >> splitAt n xs = (take n xs, drop n xs) >> >> whereas Hugs is something like >> >> splitAt n (x : xs) = (x : xs', xs'') >> where (xs', xs'') = splitAt (n-1) xs >> >> which seems much more sensible to me. Wouldn't it be better to change >> GHC to the Hugs method? Have I misunderstood something? > > Actually GHC uses this definition, in GHC.List: > > #ifdef USE_REPORT_PRELUDE > > splitAt n xs = (take n xs, drop n xs) > > #else /* hack away */ > > splitAt (I# n#) ls > | n# <# 0# = ([], ls) > | otherwise = splitAt# n# ls > where > splitAt# :: Int# -> [a] -> ([a], [a]) > splitAt# 0# xs = ([], xs) > splitAt# _ xs@[] = (xs, xs) > splitAt# m# (x:xs) = (x:xs', xs'') > where > (xs', xs'') = splitAt# (m# -# 1#) xs > > #endif /* USE_REPORT_PRELUDE */ > > So ghc's version should be of equivalent strictness to the hugs version. > > What's interesting here is that the H98 specification of splitAt is > silly. It got 'simplified' from a previous version of the Haskell spec > and is so doing it was made less strict. > > With this definition: > splitAt n xs = (take n xs, drop n xs) > > splitAt _|_ _|_ = (_|_, _|_) > > but with the sensible definition it'd return _|_ > > and that's really the only point of having splitAt, so that you can walk > down the list once rather than twice. If someone needs the very lazy > version there's always take and drop. > > Duncan > That looks good, I didn't see this 'hack away' version when I found splitAt on the web. I'm now wondering why my splitAtRK function in the following code makes it run in 11 seconds given a parameter of 2500000 but it takes 14 seconds when I change it to splitAt. Am I accidentally invoking the (take, drop) version of splitAt? Why is mine so much faster than the built-in version? (Using GHC 6.8.2, W2K, Intel Core 2 Duo 2.33GHz) Maybe mine isn't working properly somehow. (I hadn't intended to post this code just yet because I wanted to do a bit more testing etc then ask for suggestions for simplifying and improving it. I actually want to get rid of the line containing splitAt because it's ugly. All suggestions for improvement gratefully received. The time function is just temporary. This code is about three or four times slower that the current fastest Haskell entry for the Fasta shootout benchmark. I'll elaborate it for speed when I've got down to the simplest version possible.) Richard. {-# OPTIONS -O2 -fexcess-precision #-} -- -- The Computer Language Shootout : Fasta -- http://shootout.alioth.debian.org/ -- -- Simple solution by Richard Kelsall. -- http://www.millstream.com/ -- import System import Text.Printf import System.CPUTime time :: IO t -> IO t time a = do start <- getCPUTime v <- a end <- getCPUTime let diff = (fromIntegral (end - start)) / (10 ^12) printf "Calc time %0.3f \n" (diff :: Double) return v main = do time $ comp comp :: IO () comp = do n <- getArgs >>= readIO . head title "ONE" "Homo sapiens alu" writeLined (cycle alu) (n * 2) title "TWO" "IUB ambiguity codes" let (r1, r2) = splitAtRK (fromIntegral (n * 3)) (rand 42) writeLined (map (look iubs) r1) (n * 3) title "THREE" "Homo sapiens frequency" writeLined (map (look homs) r2) (n * 5) splitAtRK n xs | n <= 0 = ([], xs) splitAtRK _ [] = ([], []) splitAtRK n (x : xs) = (x : xs', xs'') where (xs', xs'') = splitAtRK (n - 1) xs title :: String -> String -> IO () title a b = putStrLn $ ">" ++ a ++ " " ++ b look :: [(Char, Float)] -> Float -> Char look [(c, _)] _ = c look ((c, f) : cfs) r = if r < f then c else look cfs (r - f) lineWidth = 60 writeLined :: [Char] -> Integer -> IO () writeLined cs 0 = return () writeLined cs n = do let w = min n lineWidth (cs1, cs2) = splitAt (fromInteger w) cs putStrLn cs1 writeLined cs2 (n - w) rand :: Int -> [Float] rand seed = newran : (rand newseed) where im = 139968 ia = 3877 ic = 29573 newseed = (seed * ia + ic) `rem` im newran = fromIntegral newseed / fromIntegral im alu = "GGCCGGGCGCGGTGGCTCACGCCTGTAATCCCAGCACTTTGGGAGGCCGAGGCGGGCGGA\ \TCACCTGAGGTCAGGAGTTCGAGACCAGCCTGGCCAACATGGTGAAACCCCGTCTCTACT\ \AAAAATACAAAAATTAGCCGGGCGTGGTGGCGCGCGCCTGTAATCCCAGCTACTCGGGAG\ \GCTGAGGCAGGAGAATCGCTTGAACCCGGGAGGCGGAGGTTGCAGTGAGCCGAGATCGCG\ \CCACTGCACTCCAGCCTGGGCGACAGAGCGAGACTCCGTCTCAAAAA" iubs = [('a', 0.27), ('c', 0.12), ('g', 0.12), ('t', 0.27), ('B', 0.02), ('D', 0.02), ('H', 0.02), ('K', 0.02), ('M', 0.02), ('N', 0.02), ('R', 0.02), ('S', 0.02), ('V', 0.02), ('W', 0.02), ('Y', 0.02)] homs = [('a', 0.3029549426680), ('c', 0.1979883004921), ('g', 0.1975473066391), ('t', 0.3015094502008)] From allbery at ece.cmu.edu Sat Apr 26 09:19:10 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Apr 26 09:13:51 2008 Subject: [Haskell-cafe] Why doesn't GHC use the Hugs definition of splitAt to avoid traversing the first part of the list twice? In-Reply-To: <481327E6.5060906@millstream.com> References: <48120711.7060306@millstream.com> <1209203506.30059.31.camel@localhost> <481327E6.5060906@millstream.com> Message-ID: <28FE2DF8-EECC-4F70-9A41-939DEFC75B04@ece.cmu.edu> On Apr 26, 2008, at 9:02 , Richard Kelsall wrote: > I'm now wondering why my splitAtRK function in the following code > makes it run in 11 seconds given a parameter of 2500000 but it takes > 14 seconds when I change it to splitAt. Am I accidentally invoking It's somewhat unusual to build the standard libraries with -O2, I think. (It can be done but the build takes a very long time.) Also, 11 vs. 14 seconds seems not that much of a difference when you're talking 2500000 items, especially given how inefficient Haskell lists (Strings are lists) are. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From marco-oweber at gmx.de Sat Apr 26 09:21:47 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sat Apr 26 09:16:30 2008 Subject: [Haskell-cafe] Replacing RDMS - global lock and STM preventing retrying? Message-ID: <20080426132146.GB5431@gmx.de> What would be the right way to go to replace RDBMS (postgres/ mysql) etc using haskell only for small to medium sized (web)applications? I guess one way to go is using STM. But what happens if you have some tables each row represented as TVar and you'd like to do a full backup? Some occasionally occuring updates on single rows will make the atomic action get all rows and write them to disk retry again and again? Is there a way to make the update action retry in this case? And then you can implement something like: Try it 20 times, if the aciton doesn't succeed aquire global lock ! Wow. Has anyone already implemented such a RDBMS replacement? Anyone interested in working on this? Marc Weber One solution I came up within minutes :) I love haskell. You write it down fix error and it works :) Would you prefer another way to solve this? --packages: containers, binary, stm, mtl, random module Main where import System.IO.Unsafe import Random import Control.Concurrent import Control.Monad import Control.Concurrent.STM import Control.Monad.Trans -- running count of actions. if set to -1 a transaction has aquired global lock globalLock = unsafePerformIO $ newTVarIO (0::Int) modifyTVar tvar f = do v <- readTVar tvar writeTVar tvar $ f v -- of course this should be in it's own monad to force using this function -- myAtomically: aquires global lock -- of course I don't need 5 atomically calls, but this way an action will not be retried if only the global count changes myAtomically aquireGlobalLock stmAction = if aquireGlobalLock then do atomically $ do runningCount <- readTVar globalLock when (runningCount /= 0) retry writeTVar globalLock (negate 1) -- other actions should be retrying atomically $ do stmAction writeTVar globalLock 0 else do atomically $ do runningCount <- readTVar globalLock when (runningCount == (negate 1)) retry modifyTVar globalLock (+1) atomically stmAction atomically $ modifyTVar globalLock (\x -> x -1) -- log utility printing start / stop of an action stsp :: (MonadIO m) => String -> m r -> m r stsp msg act = do liftIO $ putStrLn $ "start: " ++ msg r <- act liftIO $ putStrLn $ "stop: " ++ msg return r data Table rec = Table { table :: [TVar rec] } newTable rowcount = liftM Table $ mapM newTVarIO [(1::Int)..rowcount] dumpTable fn t = do dat <- myAtomically True $ mapM readTVar $ table t writeFile fn $ show dat disturb t@(Table (row:_)) = do stsp "disturbing" $ do v <- randomRIO (0,1000000) myAtomically False $ writeTVar row v threadDelay 1000000 disturb t -- loop main = do stsp "application" $ do table <- newTable 100000 forkIO $ disturb table stsp "dumping" $ dumpTable "dump" table From ketil at malde.org Sat Apr 26 09:29:15 2008 From: ketil at malde.org (Ketil Malde) Date: Sat Apr 26 09:23:49 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <4c88418c0804260221n70603390hace0ddd1a9c0bb6a@mail.gmail.com> (david's message of "Sat\, 26 Apr 2008 11\:21\:04 +0200") References: <4807B6D1.7090006@cs.pdx.edu> <480FCD87.7010803@cs.pdx.edu> <4810DFAE.8040807@btinternet.com> <200804242139.46355.jon@ffconsultancy.com> <4812DAD6.8060707@btinternet.com> <4c88418c0804260221n70603390hace0ddd1a9c0bb6a@mail.gmail.com> Message-ID: <87tzhooic4.fsf@nmd9999.imr.no> david48 writes: >> Personally, I don't see the point in rendering a couple of million >> mathematically flat surfaces, > What about speed ? "If it doesn't have to be correct, it can be arbitrarily fast" :-) -k -- If I haven't seen further, it is by standing in the footprints of giants From mads_lindstroem at yahoo.dk Sat Apr 26 10:22:48 2008 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Sat Apr 26 10:19:52 2008 Subject: [Haskell-cafe] Replacing RDMS - global lock and STM preventing retrying? In-Reply-To: <20080426132146.GB5431@gmx.de> References: <20080426132146.GB5431@gmx.de> Message-ID: <1209219768.4158.4.camel@localhost.localdomain> Hi Marc Weber wrote: > What would be the right way to go to replace RDBMS (postgres/ mysql) etc > using haskell only for small to medium sized (web)applications? > I guess one way to go is using STM. > But what happens if you have some tables each row represented as TVar > and you'd like to do a full backup? Some occasionally occuring updates > on single rows will make the atomic action get all rows and write them > to disk retry again and again? Is there a way to make the update action > retry in this case? > And then you can implement something like: Try it 20 times, if the aciton > doesn't succeed aquire global lock ! Wow. > > Has anyone already implemented such a RDBMS replacement? Have you looked at http://happs.org/ ? Their HappS-State seems somewhat similar to what you are proposing. > Anyone interested in working on this? > > Marc Weber Another question is why do you want to we replace RDBMS-es? Greetings, Mads Lindstr?m > > One solution I came up within minutes :) I love haskell. You write it > down fix error and it works :) > Would you prefer another way to solve this? > > --packages: containers, binary, stm, mtl, random > module Main where > import System.IO.Unsafe > import Random > import Control.Concurrent > import Control.Monad > import Control.Concurrent.STM > import Control.Monad.Trans > > -- running count of actions. if set to -1 a transaction has aquired global lock > globalLock = unsafePerformIO $ newTVarIO (0::Int) > > modifyTVar tvar f = do > v <- readTVar tvar > writeTVar tvar $ f v > > -- of course this should be in it's own monad to force using this function > -- myAtomically: aquires global lock > -- of course I don't need 5 atomically calls, but this way an action will not be retried if only the global count changes > myAtomically aquireGlobalLock stmAction = > if aquireGlobalLock > then do > atomically $ do > runningCount <- readTVar globalLock > when (runningCount /= 0) retry > writeTVar globalLock (negate 1) > -- other actions should be retrying > atomically $ do > stmAction > writeTVar globalLock 0 > else do > atomically $ do > runningCount <- readTVar globalLock > when (runningCount == (negate 1)) retry > modifyTVar globalLock (+1) > atomically stmAction > atomically $ modifyTVar globalLock (\x -> x -1) > > -- log utility printing start / stop of an action > stsp :: (MonadIO m) => String -> m r -> m r > stsp msg act = do > liftIO $ putStrLn $ "start: " ++ msg > r <- act > liftIO $ putStrLn $ "stop: " ++ msg > return r > > data Table rec = Table { table :: [TVar rec] } > > newTable rowcount = liftM Table $ mapM newTVarIO [(1::Int)..rowcount] > > dumpTable fn t = do > dat <- myAtomically True $ mapM readTVar $ table t > writeFile fn $ show dat > > disturb t@(Table (row:_)) = do > stsp "disturbing" $ do > v <- randomRIO (0,1000000) > myAtomically False $ writeTVar row v > threadDelay 1000000 > disturb t -- loop > > main = do > stsp "application" $ do > table <- newTable 100000 > forkIO $ disturb table > stsp "dumping" $ dumpTable "dump" table > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From r.kelsall at millstream.com Sat Apr 26 10:38:44 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Sat Apr 26 10:33:40 2008 Subject: [Haskell-cafe] Why doesn't GHC use the Hugs definition of splitAt to avoid traversing the first part of the list twice? In-Reply-To: <28FE2DF8-EECC-4F70-9A41-939DEFC75B04@ece.cmu.edu> References: <48120711.7060306@millstream.com> <1209203506.30059.31.camel@localhost> <481327E6.5060906@millstream.com> <28FE2DF8-EECC-4F70-9A41-939DEFC75B04@ece.cmu.edu> Message-ID: <48133E74.9060702@millstream.com> Brandon S. Allbery KF8NH wrote: > > On Apr 26, 2008, at 9:02 , Richard Kelsall wrote: > >> I'm now wondering why my splitAtRK function in the following code >> makes it run in 11 seconds given a parameter of 2500000 but it takes >> 14 seconds when I change it to splitAt. Am I accidentally invoking > > It's somewhat unusual to build the standard libraries with -O2, I > think. (It can be done but the build takes a very long time.) > > Also, 11 vs. 14 seconds seems not that much of a difference when you're > talking 2500000 items, especially given how inefficient Haskell lists > (Strings are lists) are. > Yes, well spotted. If I lower the compile level from -O2 to -O the splitAtRK version takes 14.5 seconds vs 14 seconds for the built-in version. Thank you. That solves the puzzle. For the benchmarks I expect they use a default packaged GHC, I don't imagine I could get them to use specially compiled libraries to bump up the GHC score. Which gives an interesting dilemma of whether I could get away with adding a small relevant snippet of library code to the program in order to give it -O2 level compilation. I wonder how much the other compilers optimise their library code. Richard. From r.kelsall at millstream.com Sat Apr 26 11:22:30 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Sat Apr 26 11:17:10 2008 Subject: [Haskell-cafe] Simplest possible Fasta shootout entry. How do I zap the ugly line? Suggest any other improvements. Message-ID: <481348B6.6030205@millstream.com> (Extracting these questions from my previous thread for clarity.) Below is my simplest possible program to solve the Fasta shootout benchmark. http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=all http://haskell.org/haskellwiki/Shootout/Fasta I can see one remaining flaw - the line marked 'Ugly'. What's the best way to get rid of this line? Any other suggestions for simplifying or improving the program would also be interesting. This code is about three or four times slower that the current fastest GHC entry for the Fasta benchmark. I'll elaborate it for speed when I've produced the best version regardless of speed. Richard. {-# OPTIONS -O -fexcess-precision #-} -- The Computer Language Shootout : Fasta -- http://shootout.alioth.debian.org/ -- Simple solution by Richard Kelsall. -- http://www.millstream.com/ import System main = do n <- getArgs >>= readIO . head title "ONE" "Homo sapiens alu" writeLined (cycle alu) (n * 2) title "TWO" "IUB ambiguity codes" let (r1, r2) = splitAt (fromIntegral (n * 3)) (rand 42) -- Ugly !! writeLined (map (look iubs) r1) (n * 3) title "THREE" "Homo sapiens frequency" writeLined (map (look homs) r2) (n * 5) title :: String -> String -> IO () title a b = putStrLn $ ">" ++ a ++ " " ++ b look :: [(Char, Float)] -> Float -> Char look [(c, _)] _ = c look ((c, f) : cfs) r = if r < f then c else look cfs (r - f) lineWidth = 60 writeLined :: [Char] -> Integer -> IO () writeLined cs 0 = return () writeLined cs n = do let w = min n lineWidth (cs1, cs2) = splitAt (fromInteger w) cs putStrLn cs1 writeLined cs2 (n - w) rand :: Int -> [Float] rand seed = newran : (rand newseed) where im = 139968 ia = 3877 ic = 29573 newseed = (seed * ia + ic) `rem` im newran = fromIntegral newseed / fromIntegral im alu = "GGCCGGGCGCGGTGGCTCACGCCTGTAATCCCAGCACTTTGGGAGGCCGAGGCGGGCGGA\ \TCACCTGAGGTCAGGAGTTCGAGACCAGCCTGGCCAACATGGTGAAACCCCGTCTCTACT\ \AAAAATACAAAAATTAGCCGGGCGTGGTGGCGCGCGCCTGTAATCCCAGCTACTCGGGAG\ \GCTGAGGCAGGAGAATCGCTTGAACCCGGGAGGCGGAGGTTGCAGTGAGCCGAGATCGCG\ \CCACTGCACTCCAGCCTGGGCGACAGAGCGAGACTCCGTCTCAAAAA" iubs = [('a', 0.27), ('c', 0.12), ('g', 0.12), ('t', 0.27), ('B', 0.02), ('D', 0.02), ('H', 0.02), ('K', 0.02), ('M', 0.02), ('N', 0.02), ('R', 0.02), ('S', 0.02), ('V', 0.02), ('W', 0.02), ('Y', 0.02)] homs = [('a', 0.3029549426680), ('c', 0.1979883004921), ('g', 0.1975473066391), ('t', 0.3015094502008)] From s.clover at gmail.com Sat Apr 26 11:41:01 2008 From: s.clover at gmail.com (Sterling Clover) Date: Sat Apr 26 11:35:46 2008 Subject: [Haskell-cafe] Generic functional references for free, now! In-Reply-To: <2f9b2d30804211643p29a8c685g92233f8a69bef03c@mail.gmail.com> References: <2518b95d0804211112k1eae26d2j6fa0a5befd4c772@mail.gmail.com> <2f9b2d30804211643p29a8c685g92233f8a69bef03c@mail.gmail.com> Message-ID: <20E9EFDC-AB23-4A7D-9153-C67094AC7DB8@gmail.com> Recent discussions inspired me to cook up the attached, which through controlled abuse of various extensions gives functional references for all records deriving Data and Typeable for free, with no template haskell necessary. Composition is fully supported, as is "overloading" of standard record accessors. For the sake of preserving at least mild sanity, the (.) operator is not overloaded, and composition is instead provided via an overloaded `o`. For anyone that doesn't mind the absurdity of how this is implemented, it should be suitable for "drop in" use. For those that do mind the absurdity, it nonetheless serves as a proof-of-concept for how far Haskell's reflective capacities can be pushed. Cheers, and happy hacking, Sterl. Example usage: data Test = Test {t1 :: Int, t2 :: Int, t3 :: String, t4 :: InnerTest} deriving (Data, Typeable, Show) data InnerTest = InnerTest {t'1 :: Int, t'2 :: Int, t'3 :: String} deriving (Data, Typeable, Show) testData = Test {t1 = 1, t2 = 2, t3 = "foo", t4 = InnerTest {t'1 = 2, t'2 = 3, t'3 = "bar"}} *GenericFRef> set t1 23 testData Test {t1 = 23, t2 = 2, t3 = "foo", t4 = InnerTest {t'1 = 2, t'2 = 3, t'3 = "bar"}} *GenericFRef> set (t'1 `o` t4) 23 testData Test {t1 = 1, t2 = 2, t3 = "foo", t4 = InnerTest {t'1 = 23, t'2 = 3, t'3 = "bar"}} *GenericFRef> update (t2) (\x->x*x) testData Test {t1 = 1, t2 = 4, t3 = "foo", t4 = InnerTest {t'1 = 2, t'2 = 3, t'3 = "bar"}} *GenericFRef> update (t'2 `o` t4) (\x->x*x) testData Test {t1 = 1, t2 = 2, t3 = "foo", t4 = InnerTest {t'1 = 2, t'2 = 9, t'3 = "bar"}} p.s. I have a nagging sensation that somebody may have done this before, although I can't trace the source. -------------- next part -------------- A non-text attachment was scrubbed... Name: GenericFRef.hs Type: application/octet-stream Size: 3580 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080426/20054ce2/GenericFRef-0001.obj From marco-oweber at gmx.de Sat Apr 26 12:26:52 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sat Apr 26 12:21:33 2008 Subject: [Haskell-cafe] Replacing RDMS - why I want this retrying? In-Reply-To: <1209219768.4158.4.camel@localhost.localdomain> References: <20080426132146.GB5431@gmx.de> <1209219768.4158.4.camel@localhost.localdomain> Message-ID: <20080426162652.GB5989@gmx.de> > Have you looked at http://happs.org/ ? :) It should be used with HAppS. But it's only a state system. It doesn't tell you yet how to organize your data. The IxSet is nice but it's not relational. > Another question is why do you want to we replace RDBMS-es? a) Speed. A simple HAppS state benchmark shows that inserting records can be 10 times faster than MySQL don't know wether its' because switching processes, parsing SQL queries ? b) Type safety. HaskellDB is nice.. But it's limiting because you can't optimize queries very well. Having something (maybe completeley in mem as HAppS proposes it) beeing as easy as Data.Map would be nice. Sincerly Marc Weber From jake.mcarthur at gmail.com Sat Apr 26 12:54:38 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Sat Apr 26 12:49:20 2008 Subject: [Haskell-cafe] Caching the Result of a Transaction? Message-ID: <9FE63F02-C400-49EF-B54F-823A0464BB4B@gmail.com> I have a problem I've been trying to work around using the existing STM API, and so far it seems that I may be unable to do it. For more background, see my blog post at . Here, for brevity, I will only describe exactly what I think I need, not what it's for. Say I have a function f :: STM a. The transaction reads from one or more TMVars, performs some computation, and returns the result in the STM monad. Also, in this scenario, it is known that once the TMVars have values, those values will never be changed again (write once, read many, somewhat like IVars before they were removed). Now say I try to use this function as so. liftM2 (,) f f So the desired result is a pair in the STM monad where both components are the result from f. The problem I have is that, in the above example, the TMVars are all read twice and the computations are all performed twice, once for each of the components of the resulting pair. In many cases, this may be the correct thing to do because the values of the TMVars may have changed, but what about this case where I _know_ that the values have not been modified? What I need is a way to cache the result of f so that future uses of f don't have to reread from the TMVars, even across multiple transactions, maybe even leading to the eventual garbage collection of the TMVars if they are not used elsewhere. Right now I think the only way to do this would be to change the STM implementation slightly and create a new primitive function. If there is a way to do something like this with the current STM API, I would love to hear suggestions. Any ideas? - Jake McArthur From mads_lindstroem at yahoo.dk Sat Apr 26 13:20:34 2008 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Sat Apr 26 13:17:39 2008 Subject: [Haskell-cafe] Replacing RDMS - why I want this retrying? In-Reply-To: <20080426162652.GB5989@gmx.de> References: <20080426132146.GB5431@gmx.de> <1209219768.4158.4.camel@localhost.localdomain> <20080426162652.GB5989@gmx.de> Message-ID: <1209230434.4158.16.camel@localhost.localdomain> Hi, Marc Weber wrote: > > Another question is why do you want to we replace RDBMS-es? > a) Speed. A simple HAppS state benchmark shows that inserting records > can be 10 times faster than MySQL > don't know wether its' because switching processes, parsing SQL queries ? You could try using prepared statements, see http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html . According to the article, this will save the parsing overhead but not the prepare-plan overhead. However, the article is about MySQL 4.1, so maybe newer versions of MySQL may only need to prepare the execution plan once. PostgreSQL seems to supports preparing both parse result and the prepare-plan result (see http://www.postgresql.org/docs/8.1/interactive/sql-prepare.html ). /Mads Lindstr?m > b) Type safety. HaskellDB is nice.. But it's limiting because you can't > optimize queries very well. > Having something (maybe completeley in mem as HAppS proposes it) beeing > as easy as Data.Map would be nice. > > Sincerly > Marc Weber > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From philip.weaver at gmail.com Sat Apr 26 13:34:15 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Sat Apr 26 13:28:55 2008 Subject: [Haskell-cafe] asserting the type of a binding in a "do" expression In-Reply-To: References: <4dcea1d80804252336m4a5a1704m7890cbc942e479ac@mail.gmail.com> Message-ID: On Fri, Apr 25, 2008 at 11:49 PM, Brandon S. Allbery KF8NH wrote: > > On Apr 26, 2008, at 2:36 , Ken Takusagawa wrote: > > > > But this does not: > > > > foo::IO a; > > foo = do{ > > (x::a) <- bar; > > return x;}; > > > > Error message: A pattern type signature cannot bind scoped type > > variables `a' unless the pattern has a rigid type context. > > > Yeah, using the "forall" is exactly what you want to fix this problem. It puts the type variable in scope throughout the definition of the function. > This works for me (in a slightly out of date HEAD) if I explicitly forall > the declaration as per the ghc manual (see section 8.7.6.3): > > > bar :: forall b. IO b > > bar = return undefined -- just want a type for now > > foo :: forall a. IO a > > > foo = do { (x :: a) <- bar; return x; } > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From sebastian.sylvan at gmail.com Sat Apr 26 15:11:10 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Sat Apr 26 15:05:49 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <4c88418c0804260221n70603390hace0ddd1a9c0bb6a@mail.gmail.com> References: <4807B6D1.7090006@cs.pdx.edu> <480FCD87.7010803@cs.pdx.edu> <4810DFAE.8040807@btinternet.com> <200804242139.46355.jon@ffconsultancy.com> <4812DAD6.8060707@btinternet.com> <4c88418c0804260221n70603390hace0ddd1a9c0bb6a@mail.gmail.com> Message-ID: <3d96ac180804261211s658ea5d2o40bbeef0a7a7cfb@mail.gmail.com> On Sat, Apr 26, 2008 at 10:21 AM, david48 > wrote: > On Sat, Apr 26, 2008 at 9:33 AM, Andrew Coppin > wrote: > > > Personally, I don't see the point in rendering a couple of million > > mathematically flat surfaces, > > What about speed ? > If you tessellate the curve so that there is zero error, then it's probably going to be faster to ray trace the actual curve, since you'll essentially have loads of very small (1 pixel or thereabouts) triangles... -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080426/8a07c16a/attachment.htm From andrewcoppin at btinternet.com Sat Apr 26 16:34:43 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Apr 26 16:28:59 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer) In-Reply-To: <4c88418c0804260221n70603390hace0ddd1a9c0bb6a@mail.gmail.com> References: <4807B6D1.7090006@cs.pdx.edu> <480FCD87.7010803@cs.pdx.edu> <4810DFAE.8040807@btinternet.com> <200804242139.46355.jon@ffconsultancy.com> <4812DAD6.8060707@btinternet.com> <4c88418c0804260221n70603390hace0ddd1a9c0bb6a@mail.gmail.com> Message-ID: <481391E3.9070300@btinternet.com> david48 wrote: > On Sat, Apr 26, 2008 at 9:33 AM, Andrew Coppin > wrote: > > >> Personally, I don't see the point in rendering a couple of million >> mathematically flat surfaces, >> > > What about speed ? > Speed is not always the most important thing. ;-) ["The best things come to those who wait" and all that...] From jmaessen at alum.mit.edu Sat Apr 26 17:03:37 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Sat Apr 26 16:58:20 2008 Subject: [Haskell-cafe] lookup tables & style guidelines In-Reply-To: <481314F4.8070601@iee.org> References: <1ff5dedc0804231334y1a14f93cobf6b97da93285728@mail.gmail.com> <20080423203634.GG22492@scytale.galois.com> <87r6cvzrtx.fsf@nmd9999.imr.no> <4810A863.4010703@iee.org> <481314F4.8070601@iee.org> Message-ID: <8693D2BC-AC6C-4D88-9263-6EDA56259CA1@alum.mit.edu> On Apr 26, 2008, at 7:41 AM, Adrian Hey wrote: > Jan-Willem Maessen wrote: >> On Apr 24, 2008, at 11:33 AM, Adrian Hey wrote: >>> Also, if you're likely to be using union/intersection a lot you >>> should >>> know that Data.Map/Set are very slow for this because they use the >>> not efficient hedge algorithm :-) >> OK, I'm going to bite here: What's the efficient algorithm for >> union on balanced trees, given that hedge union was chosen as being >> more efficient than naive alternatives (split and merge, repeated >> insertion)? My going hypothesis has been "hedge union is an >> inefficient algorithm, except that it's better than all those other >> inefficient algorithms". > > Divide and conquer seems to be the most efficient, though not the > algorithm presented in the Adams paper. Just to clarify: divide and conquer splits one tree on the root value of the other (possibly avoiding enforcing the balance metric until after joining trees, though not obvious how / if that's useful)? The definition of "divide and conquer" on trees without a fixed structure is rather unclear, which is why the question comes up in the first place. > Hedge algorithm performs many > more comparisons than are needed, which is obviously bad if you don't > know how expensive those comparisons are going to be. That makes sense. I found myself having the same kinds of thoughts when reading Knuth's analyses of (eg) different binary search algorithms in TAOCP v.3; if comparison was the dominant cost, which algorithm looked best suddenly changed. -Jan From d at vidplace.com Sat Apr 26 17:25:20 2008 From: d at vidplace.com (David F. Place) Date: Sat Apr 26 17:20:05 2008 Subject: [Haskell-cafe] Trouble compiling collections-0.3 (from Hackage) Message-ID: <48139DC0.4090809@vidplace.com> Hi, I am not able to build collections-0.3 because on an error. I hope someone can give me a hint. Below, please find a short transcript with various version information. Cheers, David [david@congo ~]$ cd Desktop/collections-0.3 [david@congo collections-0.3]$ runghc Setup.hs configure Configuring collections-0.3... [david@congo collections-0.3]$ runghc Setup.hs build Preprocessing library collections-0.3... Building collections-0.3... Data/Collections.hs:154:17: Could not find module `Data.ByteString.Lazy': it is a member of package bytestring-0.9.0.4, which is hidden [david@congo collections-0.3]$ uname -a Linux congo 2.6.16-1.2111_FC5 #1 SMP Thu May 4 21:16:04 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux [david@congo collections-0.3]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 [david@congo collections-0.3]$ ghc-pkg list /usr/local/lib/ghc-6.8.2/package.conf: ALUT-2.1.0.0, Cabal-1.2.3.0, GLUT-2.1.1.1, HUnit-1.2.0.0, OpenAL-1.3.1.1, OpenGL-2.2.1.1, QuickCheck-1.1.0.0, array-0.1.0.0, base-3.0.1.0, bytestring-0.9.0.1, bytestring-0.9.0.4, cgi-3001.1.5.1, containers-0.1.0.1, directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, (ghc-6.8.2), haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, html-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, readline-1.0.1.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, time-1.1.2.0, unix-2.3.0.0, xhtml-3000.0.2.1 [david@congo collections-0.3]$ From jake.mcarthur at gmail.com Sat Apr 26 17:30:47 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Sat Apr 26 17:25:28 2008 Subject: [Haskell-cafe] Trouble compiling collections-0.3 (from Hackage) In-Reply-To: <48139DC0.4090809@vidplace.com> References: <48139DC0.4090809@vidplace.com> Message-ID: <7EE26CA2-D0B2-49CB-9649-5745ACEAB1F6@gmail.com> On Apr 26, 2008, at 4:25 PM, David F. Place wrote: > Data/Collections.hs:154:17: > Could not find module `Data.ByteString.Lazy': > it is a member of package bytestring-0.9.0.4, which is hidden In the .cabal file, add "bytestring" to the dependencies property. - Jake From conal at conal.net Sat Apr 26 20:18:26 2008 From: conal at conal.net (Conal Elliott) Date: Sat Apr 26 20:13:06 2008 Subject: [Haskell-cafe] Caching the Result of a Transaction? In-Reply-To: <9FE63F02-C400-49EF-B54F-823A0464BB4B@gmail.com> References: <9FE63F02-C400-49EF-B54F-823A0464BB4B@gmail.com> Message-ID: Here's another angle on part of Jake's question: Can we implement a type 'TIVal a' (preferably without unsafePerformIO) with the following interface: newIVal :: STM (TIVal a, a -> STM ()) -- or IO (...) force :: TIVal a -> STM a instance Functor IVal instance Applicative IVal instance Monad IVal where * 'newIVal' makes something like an IVar that can be written/defined (just once) with the returned a->STM(). * 'force' gets the value, retrying if not yet defined; once force is able to succeed, it always yields the same value. * 'fmap f tiv' becomes defined (force yields a value instead of retrying) when tiv does. Similarly for (<*>) and join. * Forcing 'fmap f tiv' more than once results in f being called only once, i.e., the result is cached and reused, as in pure values. Similarly for (<*>) and join. - Conal On Sat, Apr 26, 2008 at 9:54 AM, Jake Mcarthur wrote: > I have a problem I've been trying to work around using the existing STM > API, and so far it seems that I may be unable to do it. For more background, > see my blog post at < > http://geekrant.wordpress.com/2008/04/25/stm-caching-need/>. Here, for > brevity, I will only describe exactly what I think I need, not what it's > for. > > Say I have a function f :: STM a. The transaction reads from one or more > TMVars, performs some computation, and returns the result in the STM monad. > Also, in this scenario, it is known that once the TMVars have values, those > values will never be changed again (write once, read many, somewhat like > IVars before they were removed). Now say I try to use this function as so. > > liftM2 (,) f f > > So the desired result is a pair in the STM monad where both components are > the result from f. The problem I have is that, in the above example, the > TMVars are all read twice and the computations are all performed twice, once > for each of the components of the resulting pair. In many cases, this may be > the correct thing to do because the values of the TMVars may have changed, > but what about this case where I _know_ that the values have not been > modified? > > What I need is a way to cache the result of f so that future uses of f > don't have to reread from the TMVars, even across multiple transactions, > maybe even leading to the eventual garbage collection of the TMVars if they > are not used elsewhere. > > Right now I think the only way to do this would be to change the STM > implementation slightly and create a new primitive function. If there is a > way to do something like this with the current STM API, I would love to hear > suggestions. Any ideas? > > - Jake McArthur > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080426/e91f57f7/attachment.htm From jsnow at cs.pdx.edu Sat Apr 26 20:25:38 2008 From: jsnow at cs.pdx.edu (Jim Snow) Date: Sat Apr 26 21:21:39 2008 Subject: [Haskell-cafe] announce: Glome.hs-0.3 (ray tracing digression, glome tutorial) In-Reply-To: <4812DAD6.8060707@btinternet.com> References: <4807B6D1.7090006@cs.pdx.edu> <480FCD87.7010803@cs.pdx.edu> <4810DFAE.8040807@btinternet.com> <200804242139.46355.jon@ffconsultancy.com> <4812DAD6.8060707@btinternet.com> Message-ID: <4813C802.7090103@cs.pdx.edu> David48 wrote: > On Sat, Apr 26, 2008 at 9:33 AM, Andrew Coppin > wrote: > > >> > Personally, I don't see the point in rendering a couple of million >> > mathematically flat surfaces, >> > > What about speed ? That is a good point. Ray tracing may give you a better image approximation than rasterizing triangles, but unless you're tracing an infinite number of rays, it is still just an approximation. Some shapes (like spheres) can be rendered more quickly in a ray tracer than triangles, and they use less memory as well, so if you really want a sphere, there's no reason to approximate it with triangles. For other objects, the trade-offs are more complex. > ... > >> Unfortunately, the SDL is so complex it's well-nigh impossible to >> support in other third-party applications. > > I don't think it would be "impossible" to support in 3rd party apps. A > lot of work, certainly! Especially the way the parser does parsing and > macro expansion in the same pass, so a macro body need not contain a > syntactically-complete code fragment. I think if somebody sat down and > wrote something that would do all the macro expansion, variable > substitution and so forth to leave just few geometry descriptions, > *those* would be quite easy to parse and manipulate for 3rd parties. > I guess a pov importer wouldn't necessarily be all that difficult, or an exporter, for that matter. (Supporting every single primitive type, texture, and rendering feature would be a daunting challenge, but just supporting the basics might be relatively simple.) The problem comes when you want to import a nice short hand-edited script, and then do a few things to it and export it again: suddenly the file turns into a multi-megabyte monstrosity with all the loops unrolled and all the recursive macros expanded and you lose the ability to hand-edit the scene. Depending on what you're doing, this might not be a problem. > >>> Personally, I'd quite like to write my own ray tracer to address >>> some of these limitations. But every time I try, I end up hitting >>> design issues [Haskell works very differently to Java] or >>> performance issues [which I don't even know how to begin debugging]. >>> Not to mention that POV-Ray uses sophisticated techniques like >>> volume bounding that I know nothing about. (There's nothing like >>> using an inherantly superior algorithm to make your code orders of >>> magnitude faster...) >>> >> I haven't really run into any issues where Haskell didn't let me do >> what I want, except for the performance counters thing mentioned way >> back at the beginning of this thread (and which I've more or less >> given up on for now, since the acceleration structure seems to be >> working okay and I have other things to work on). > > Well, for example, Haskell doesn't have hetrogenous lists - which are > trivial in any OOP language. That's quite awkward to get around. Also, > both spheres and cylinders have a "radius" property, but then you end > up with name clashes. Again, a non-issue in OOP languages. [I gather > there's some new GHC language extension to partially solve this one - > but only when types are statically known. In the general case, you'd > have to write a "radius class" and define instances... yuck!] > It's funny you mention that, those are actually problems I ran into, but (having learned my lesson the hard way in Ocaml), I decided not to try and force the language to do things my way, but instead try to do things in a way that Haskell makes easy. For instance, I started out by making each primitive a separate type (Sphere, Triangle, etc...), and then made a type class that defines a ray intersection method (and a few other odds and ends), but then I realized that I can't do something as simple as store a list of primitives (or if there is in fact a way, I'm not aware of it). Instead, I made a single large sum type with all my primitives: data Solid = Sphere {center :: Vec, radius, invradius :: Flt} | Triangle {v1, v2, v3 :: Vec} | TriangleNorm {v1, v2, v3, n1, n2, n3 :: Vec} | Disc Vec Vec Flt -- position, normal, r*r | Cylinder Flt Flt Flt -- radius height1 height2 | Cone Flt Flt Flt Flt -- r clip1 clip2 height | Plane Vec Flt -- normal, offset from origin | Box Bbox | Group [Solid] | Intersection [Solid] | Bound Solid Solid | Difference Solid Solid | Bih {bihbb :: Bbox, bihroot :: BihNode} | Instance Solid Xfm | Tex Solid Texture | Nothing deriving Show etc... (strictness annotations and a few broken primitives omitted for brevity) so that now I can easily make a list of primitives. (In fact, that's what a Group is.) I also gave up on using named fields, since coming up with a separate name for each one gets ugly: instead of radius, you have sphere_radius, cylinder_radius, cone_radius disc_radius, etc... >> Cones and spheres and boxes and the like can be made into some fairly >> elaborate scenes, but you can't really make, say, a realistic human >> figure out of those sorts of primitives. > > No, but with things like isosurfaces and parametric surfaces, the > world is your oyster. And you can do a surprising amount of things > with blobs. I understand that all those curved surfaces which are > currently popular in consumer electronics are done with splines, not > triangles... > That world is a very slow oyster. I've used blobs and isosurfaces in POV-Ray, and they're wonderfully expressive but also incredibly slow. (The water in this scene, for instance, is an isosurface, and the boat hull is a blob and some CSG: http://syn.cs.pdx.edu/~jsnow/castle-crop.jpg) There are also other problems: the isosurface solvers are sometimes wrong, leading to ugly artifacts (and a lot of manual tweaking to make them go away), and applying a texture to an isosurface or blob isn't necessarily straightforward. Another issue is that isosurfaces are great for filling the scene with procedurally-generated complexity, but sometimes you need to do actual physics computations in order to make the object do the right thing. For instance, in the image I linked above, the water looks pretty good, but the waves should really be reflecting off of the castle when they hit it, and there's no way I know of to do that without actually doing some sort of finite-element fluid simulation. And since that's already an approximation, and it's already taking up a lot of memory, you might as well just represent it as a triangle mesh (or whatever happens to be the easiest representation to render efficiently). There's really a trade-off here between quality, time, and space. Any blob or isosurface can be approximated with triangles, and if the triangles are smaller than a pixel (or sometimes even if they're quite a bit bigger) the difference isn't going to be noticeable. However, using huge numbers of triangles consumes a ridiculous amount of memory, so you often have to use a coarser representation. (Here's an interesting paper about doing this sort of thing in a clever way: http://www.llnl.gov/graphics/ROAM/roam.pdf) Isosurfaces and blobs (http://povray.org/documentation/view/3.6.1/71/, http://povray.org/documentation/view/3.6.1/73/) are two features I really like about POV-Ray, but they're very CPU intensive. In other news, I have the beginnings of a tutorial up on the Haskell wiki that describes how to write your own scene with Glome: http://www.haskell.org/haskellwiki/Glome_tutorial -jim From haskell at brecknell.org Sat Apr 26 23:37:25 2008 From: haskell at brecknell.org (Matthew Brecknell) Date: Sat Apr 26 23:32:03 2008 Subject: [Haskell-cafe] Caching the Result of a Transaction? In-Reply-To: References: <9FE63F02-C400-49EF-B54F-823A0464BB4B@gmail.com> Message-ID: <1209267445.7465.1250064633@webmail.messagingengine.com> Conal Elliott said: > Can we implement a type 'TIVal a' (preferably without unsafePerformIO) > with the following interface: > > newIVal :: STM (TIVal a, a -> STM ()) -- or IO (...) > force :: TIVal a -> STM a > > instance Functor IVal > instance Applicative IVal > instance Monad IVal > > where > > * 'newIVal' makes something like an IVar that can be written/defined > (just once) with the returned a->STM(). > * 'force' gets the value, retrying if not yet defined; once force is able > to succeed, it always yields the same value. > * 'fmap f tiv' becomes defined (force yields a value instead of retrying) > when tiv does. Similarly for (<*>) and join. > * Forcing 'fmap f tiv' more than once results in f being called only > once, > i.e., the result is cached and reused, as in pure values. Similarly for > (<*>) and join. Perhaps what you and Jake are looking for are fully-fledged "triggers" on transactional memory. To solve the fmap problem, have each TIVar backed by a separate TVar. Then the TIVar returned by fmap would act as a cache for the original TIVar. A trigger would watch the TVar which backs the original TIVar, updating the cache TVar when the original TIVar is written. Nested fmaps would work simply as a cascade of triggers. The STM authors considered the possibility of triggers in their paper on invariants [1], but instead took the safer option of read-only invariants. [1]http://research.microsoft.com/~simonpj/papers/stm/stm-invariants.pdf From jake.mcarthur at gmail.com Sun Apr 27 01:03:57 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Sun Apr 27 00:58:38 2008 Subject: [Haskell-cafe] Caching the Result of a Transaction? In-Reply-To: References: <9FE63F02-C400-49EF-B54F-823A0464BB4B@gmail.com> Message-ID: On Apr 26, 2008, at 7:18 PM, Conal Elliott wrote: > Here's another angle on part of Jake's question: > > Can we implement a type 'TIVal a' (preferably without > unsafePerformIO) with the following interface: > > newIVal :: STM (TIVal a, a -> STM ()) -- or IO (...) > force :: TIVal a -> STM a > > instance Functor IVal > instance Applicative IVal > instance Monad IVal > > where > > * 'newIVal' makes something like an IVar that can be written/defined > (just once) with the returned a->STM(). > * 'force' gets the value, retrying if not yet defined; once force is > able to succeed, it always yields the same value. > * 'fmap f tiv' becomes defined (force yields a value instead of > retrying) when tiv does. Similarly for (<*>) and join. > * Forcing 'fmap f tiv' more than once results in f being called only > once, i.e., the result is cached and reused, as in pure values. > Similarly for (<*>) and join. Well, I think I may have done it! This is only code that I typed up really quick. I haven't even made sure it compiles. Regardless, I think the gist is pretty clear... data TIVal a = TIVal (STM a) (TMVar a) newTIVal = do uc <- newEmptyTMVar c <- newEmptyTMVar return (TIVal (takeTMVar uc) c, putTMVar uc) force (TIVal uc c) = readTMVar c `orElse` cache where cache = do x <- uc putTMVar c x return x unsafeNewEmptyTMVar = unsafePerformIO newEmptyTMVarIO -- insert NOINLINE and/or other magical pragmas here instance Functor TIVal where f `fmap` x = TIVal (return . f =<< force x) unsafeNewEmptyTMVar -- Applicative, Monad, and Monoid omitted I did have to resort to unsafePerformIO, but I think the reason is innocent enough to still feel good about. This implementation, if it works, seems to be embarrassingly simple. From andrewcoppin at btinternet.com Sun Apr 27 05:05:45 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun Apr 27 04:59:59 2008 Subject: [Haskell-cafe] Glome.hs-0.3 (ray tracing digression) In-Reply-To: <4813C802.7090103@cs.pdx.edu> References: <4807B6D1.7090006@cs.pdx.edu> <480FCD87.7010803@cs.pdx.edu> <4810DFAE.8040807@btinternet.com> <200804242139.46355.jon@ffconsultancy.com> <4812DAD6.8060707@btinternet.com> <4813C802.7090103@cs.pdx.edu> Message-ID: <481441E9.6020200@btinternet.com> Jim Snow wrote: > I guess a pov importer wouldn't necessarily be all that difficult, or > an exporter, for that matter. (Supporting every single primitive > type, texture, and rendering feature would be a daunting challenge, > but just supporting the basics might be relatively simple.) The > problem comes when you want to import a nice short hand-edited script, > and then do a few things to it and export it again: suddenly the file > turns into a multi-megabyte monstrosity with all the loops unrolled > and all the recursive macros expanded and you lose the ability to > hand-edit the scene. Depending on what you're doing, this might not > be a problem. I see what you mean... I guess you'd want to seperate the machine-generated parts from the hand-written parts by careful use of #includes... >> Well, for example, Haskell doesn't have hetrogenous lists - which are >> trivial in any OOP language. That's quite awkward to get around. >> Also, both spheres and cylinders have a "radius" property, but then >> you end up with name clashes. Again, a non-issue in OOP languages. [I >> gather there's some new GHC language extension to partially solve >> this one - but only when types are statically known. In the general >> case, you'd have to write a "radius class" and define instances... >> yuck!] >> > It's funny you mention that, those are actually problems I ran into, > but (having learned my lesson the hard way in Ocaml), I decided not to > try and force the language to do things my way, but instead try to do > things in a way that Haskell makes easy. > For instance, I started out by making each primitive a separate type > (Sphere, Triangle, etc...), and then made a type class that defines a > ray intersection method (and a few other odds and ends), but then I > realized that I can't do something as simple as store a list of > primitives (or if there is in fact a way, I'm not aware of it). > Instead, I made a single large sum type with all my primitives: > so that now I can easily make a list of primitives. (In fact, that's > what a Group is.) I also gave up on using named fields, since coming > up with a separate name for each one gets ugly: instead of radius, > you have sphere_radius, cylinder_radius, cone_radius disc_radius, etc... All of which works, but now it's a pain to add new primitives. And *all* supported primitives must be defined in a single monolithic module. And you can't reuse spheres as bounding volumes without either reimplementing them or loosing type safety. > That world is a very slow oyster. I've used blobs and isosurfaces in > POV-Ray, and they're wonderfully expressive but also incredibly slow. This explains why my PC contains the fastest CPU that I could afford, and why a while back I actually considered purchasing an 8-core server box that was on special offer for ?600. (I'm now really kicking myself that I didn't buy that! 8 Xeon cores... it would have been so fast!) But yeah, I guess it depends on what your patience level is. I like the way a couple of lines of SDL can construct a blob object so intricate that it would be impossible to construct a triangle mesh like that with any known tool... but that's just me. > There are also other problems: the isosurface solvers are sometimes > wrong, leading to ugly artifacts Only if you set the max_gradient too low. And that's not surprising, given how the algorithm works... [Indeed, what's surprising is that they built a solver that works for arbitrary functions!] > and applying a texture to an isosurface or blob isn't necessarily > straightforward. That is a pitty. On the other hand, with function-based pigments, you can do some pretty impressive stuff. [For example, using the same function as the isosurface to distribute a texture map.] > Another issue is that isosurfaces are great for filling the scene with > procedurally-generated complexity, but sometimes you need to do actual > physics computations in order to make the object do the right thing. > For instance, in the image I linked above, the water looks pretty > good, but the waves should really be reflecting off of the castle when > they hit it, and there's no way I know of to do that without actually > doing some sort of finite-element fluid simulation. And since that's > already an approximation, and it's already taking up a lot of memory, > you might as well just represent it as a triangle mesh (or whatever > happens to be the easiest representation to render efficiently). The way I did that is as follows: 1. Create a function that represents the waves. 2. Sample that function at multiple points along the edges of whatever is protruding through the water. 3. Add another wave source at that point with an appropreate phase offset as per the samples you just took. 4. The actual isosurface is the sum of all the waves thus mentioned. Apparently the samples just need to be "close together" relative to the wavelength of the waves and it looks right. So if you have fairly large waves, you don't need many samples [and many wave functions to sum!] The results looked fairly good to me. I have yet to see anybody doing water simulation using a triangle mesh. Invariably people just make each particle in the system into a blob component, and let POV-Ray smooth the surface. > There's really a trade-off here between quality, time, and space. Indeed. If I was trying to render a feature-length movie Pixar style, I'd probably be making different choices. But I'm not. I'm building still images, and the occasional short animation. For me, quality is the main concern. ;-) > Any blob or isosurface can be approximated with triangles, and if the > triangles are smaller than a pixel (or sometimes even if they're quite > a bit bigger) the difference isn't going to be noticeable. False. 1. As I understand it, tesselating arbitrary surfaces is still an unsolved problem. 2. If you have curved reflective or refractive surfaces, these can magnify elements of the geometry, so even if every triangle is smaller than a pixel, you can still see the difference. (Ditto for shadow considerations.) From ahey at iee.org Sun Apr 27 05:22:36 2008 From: ahey at iee.org (Adrian Hey) Date: Sun Apr 27 05:17:17 2008 Subject: [Haskell-cafe] lookup tables & style guidelines In-Reply-To: <8693D2BC-AC6C-4D88-9263-6EDA56259CA1@alum.mit.edu> References: <1ff5dedc0804231334y1a14f93cobf6b97da93285728@mail.gmail.com> <20080423203634.GG22492@scytale.galois.com> <87r6cvzrtx.fsf@nmd9999.imr.no> <4810A863.4010703@iee.org> <481314F4.8070601@iee.org> <8693D2BC-AC6C-4D88-9263-6EDA56259CA1@alum.mit.edu> Message-ID: <481445DC.9000702@iee.org> Jan-Willem Maessen wrote: > Just to clarify: divide and conquer splits one tree on the root value of > the other (possibly avoiding enforcing the balance metric until after > joining trees, though not obvious how / if that's useful)? The > definition of "divide and conquer" on trees without a fixed structure is > rather unclear, which is why the question comes up in the first place. The Divide and conquer algorithm presented in the Adams paper treats the two trees differently, depending on size. The algorithm used in AVL lib doesn't do this, it treats them both the same. You split each tree by the root of the other tree, then do the sub-unions on the three resulting ranges, then join these using the 2 orignal roots as "bridging" elements. This seems to give better results, and also aesthetically (an important consideration) seems more natural. With AVL I don't think there's really anything to be gained by not balancing intermediate trees as balancing costs practically nothing and has obvious advantages. Still it's not perfect. If the two trees are about the same size this still seemed to cost about 20% more comparisons than a noddy list merge union would. It's a big win over lists if there's a substantial difference in tree sizes though (and a big win over Hedge in all cases I think). It would be nice if someone could do a good theoretical analysis of the performance of these algorithms. I didn't because my maths wasn't good enough. I just chose algorithms empirically to minimise comparison counts (not execution times), which is the right thing to do for polymorphic implementations. Regards -- Adrian Hey From a_regidor at yahoo.es Sun Apr 27 05:50:05 2008 From: a_regidor at yahoo.es (=?iso-8859-1?q?Antonio=20Regidor=20Garc=EDa?=) Date: Sun Apr 27 05:44:43 2008 Subject: [Haskell-cafe] [help] Program immplementing an alarm Message-ID: <86873.37311.qm@web28615.mail.ukl.yahoo.com> Hi, I'm trying to implement an alarm in Haskell and wrote the following code: http://hpaste.org/7201 But it doesn't work as expected. The expected behaviour is: The user enters a time in minutes. If the time is reached, a bell rings. If, before the time is reached, he press enter, the program finish and prints the elapsed time. The actual behaviour is: The user enters a time in minutes. If time is reached, nothing happens. If the user press enter, the elapsed time is printed and the program finish. Also, if he pressed enter after the time had elapsed, the bell rings. Some ideas? Antonio Regidor Garc?a ______________________________________________ Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. From fernanbolando at mailc.net Sun Apr 27 06:30:30 2008 From: fernanbolando at mailc.net (Fernan Bolando) Date: Sun Apr 27 06:25:07 2008 Subject: [Haskell-cafe] Finite Difference Implementation Message-ID: <1d5d51400804270330t70ba8897j945a27f229073e7@mail.gmail.com> Hi all I was wondering if anyone has or knows of a Finite Difference or Finite Element Implementation in pure haskell. I would like to write this myself, but my haskell skills is not that good. I did a bit of google search I've seen it bieng discussed, but did not point to an actual code. thanks fernan -- http://www.fernski.com From paul at cogito.org.uk Sun Apr 27 07:07:58 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Sun Apr 27 07:02:43 2008 Subject: [Haskell-cafe] Help with complicated type inference Message-ID: <48145E8E.1040107@cogito.org.uk> I'm trying to write an AMQP framing layer. AMQP has two very similar union types: there is a "variant" that contains a single item, and an "array" which consists of a list of elements of the same type. So I thought I could define a "Unit" type container thus: > newtype Unit a = Unit {unUnit :: a} So now I can say: > type AmqpVariant = AmqpVariantBase Unit > type AmqpArray = AmqpVariantBase [] Then the AmqpVariantBase type looks something like this (except that it doesn't work, see below): > data forall a . (AmqpWire a, AmqpWire (c a)) => > AmqpVariantBase c = AmqpVarBin8 (c Bin8) > | AmqpVarInt8 (c Int8) > | AmqpVarUint8 (c Word8) > | AmqpVarChar (c Word8) > | AmqpVarBoolean (c Bool) > | AmqpVarBin16 (c Bin16) > | AmqpVarInt16 (c Int16) > | AmqpVarUint16 (c Word16) > | AmqpVarBin32 (c Bin32) > | AmqpVarInt32 (c Int32) > -- And on for about 20 more types, including compound types. All AMQP types have to be seralised, so I've defined a class "AmqpWire" for serialisation in AMQP format. All the individual types (Bin8, Int8 etc) are instances of this class. I've also defined instances for Unit and [] such as: > instance (AmqpWire a) => AmqpWire (Unit a) where > amqpPut = amqpPut . unUnit > amqpGet = map Unit amqpGet The problem is with the type constraint for AmqpVariantBase. I need to say "AmqpWire (c a)" without explicitly listing all the values of "a" (i.e. Bin8, Int8, etc) because any time I use AmqpVariantBase I have to repeat the same constraint. How do I do this? Paul. From conal at conal.net Sun Apr 27 10:36:45 2008 From: conal at conal.net (Conal Elliott) Date: Sun Apr 27 10:31:22 2008 Subject: [Haskell-cafe] Caching the Result of a Transaction? In-Reply-To: References: <9FE63F02-C400-49EF-B54F-823A0464BB4B@gmail.com> Message-ID: Looks good to me, Jake. A few comments: First, I think we want readTMVar instead of takeTMVar in newTIVal. I think we *do* want unsafeNewEmptyTMVar inlined. Here's a convenient caching wrapper: cached :: STM a -> TIVal a cached m = TIVal m (unsafePerformIO newEmptyTMVarIO) The instances are then lovely: instance Functor TIVal where f `fmap` tiv = cached (f `fmap` force tiv) instance Applicative TIVal where pure x = cached (pure x) ivf <*> ivx = cached (force ivf <*> force ivx) instance Monad TIVal where return x = cached (return x) tiv >>= k = cached (force tiv >>= force . k) I've assumed a standard monad-as-applicative instance for STM. Otherwise, give one for TIVal. Cheers, - Conal On Sat, Apr 26, 2008 at 10:03 PM, Jake Mcarthur wrote: > On Apr 26, 2008, at 7:18 PM, Conal Elliott wrote: > > Here's another angle on part of Jake's question: > > > > Can we implement a type 'TIVal a' (preferably without unsafePerformIO) > > with the following interface: > > > > newIVal :: STM (TIVal a, a -> STM ()) -- or IO (...) > > force :: TIVal a -> STM a > > > > instance Functor IVal > > instance Applicative IVal > > instance Monad IVal > > > > where > > > > * 'newIVal' makes something like an IVar that can be written/defined > > (just once) with the returned a->STM(). > > * 'force' gets the value, retrying if not yet defined; once force is > > able to succeed, it always yields the same value. > > * 'fmap f tiv' becomes defined (force yields a value instead of > > retrying) when tiv does. Similarly for (<*>) and join. > > * Forcing 'fmap f tiv' more than once results in f being called only > > once, i.e., the result is cached and reused, as in pure values. Similarly > > for (<*>) and join. > > > > Well, I think I may have done it! This is only code that I typed up really > quick. I haven't even made sure it compiles. Regardless, I think the gist is > pretty clear... > > data TIVal a = TIVal (STM a) (TMVar a) > > newTIVal = do uc <- newEmptyTMVar > c <- newEmptyTMVar > return (TIVal (takeTMVar uc) c, putTMVar uc) > > force (TIVal uc c) = readTMVar c `orElse` cache > where cache = do x <- uc > putTMVar c x > return x > > unsafeNewEmptyTMVar = unsafePerformIO newEmptyTMVarIO > -- insert NOINLINE and/or other magical pragmas here > > instance Functor TIVal where > f `fmap` x = TIVal (return . f =<< force x) unsafeNewEmptyTMVar > > -- Applicative, Monad, and Monoid omitted > > I did have to resort to unsafePerformIO, but I think the reason is > innocent enough to still feel good about. This implementation, if it works, > seems to be embarrassingly simple. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080427/69201f6b/attachment.htm From jake.mcarthur at gmail.com Sun Apr 27 11:05:06 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Sun Apr 27 10:59:48 2008 Subject: [Haskell-cafe] Caching the Result of a Transaction? In-Reply-To: References: <9FE63F02-C400-49EF-B54F-823A0464BB4B@gmail.com> Message-ID: On Apr 27, 2008, at 9:36 AM, Conal Elliott wrote: > First, I think we want readTMVar instead of takeTMVar in newTIVal. I don't see any reason it would hurt to use takeTMVar, and I suspect the garbage collector might be slightly happier this way since it potentially means once less reference to the data stored in the TMVar. > I think we *do* want unsafeNewEmptyTMVar inlined. Here's a > convenient caching wrapper: > > cached :: STM a -> TIVal a > cached m = TIVal m (unsafePerformIO newEmptyTMVarIO) > > The instances are then lovely: > > instance Functor TIVal where > f `fmap` tiv = cached (f `fmap` force tiv) > > instance Applicative TIVal where > pure x = cached (pure x) > ivf <*> ivx = cached (force ivf <*> force ivx) > > instance Monad TIVal where > return x = cached (return x) > tiv >>= k = cached (force tiv >>= force . k) Yes, this is essentially what I am working with in Reaction at the moment. It seems to be working great, but I have not specifically tested the caching behavior yet, only that it doesn't screw up what I had working in the first place. I must admit that I think I don't fully understand the implications of inlining vs. not inlining unsafePerformIO. - Jake From jake.mcarthur at gmail.com Sun Apr 27 11:12:04 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Sun Apr 27 11:06:43 2008 Subject: [Haskell-cafe] Caching the Result of a Transaction? In-Reply-To: References: <9FE63F02-C400-49EF-B54F-823A0464BB4B@gmail.com> Message-ID: <347AFC0F-2615-44FA-9A4C-1664DE2F516F@gmail.com> On Apr 27, 2008, at 10:05 AM, Jake Mcarthur wrote: > On Apr 27, 2008, at 9:36 AM, Conal Elliott wrote: > >> I think we *do* want unsafeNewEmptyTMVar inlined. Here's a >> convenient caching wrapper: >> >> cached :: STM a -> TIVal a >> cached m = TIVal m (unsafePerformIO newEmptyTMVarIO) > > Yes, this is essentially what I am working with in Reaction at the > moment. Actually, that is not quite what I have been doing. Here is what I had: cachedFuture :: STM (a, Time) -> Future a cachedFuture stm = unsafePerformIO $ return . Future stm =<< newEmptyTMVarIO {-# NOINLINE cachedFuture #-} (Clearly I am skipping right past an implementation of TIVals, despite the fact that they may be useful as a separate abstraction. This is just laziness.) If I replace the above with... cachedFuture :: STM (a, Time) -> Future a cachedFuture stm = Future stm (unsafePerformIO newEmptyTMVarIO) then my test program hangs, with or without the NOINLINE pragma. I can't guess why because, like I already said, I haven't yet thought all the way through the relationship between unsafePerformIO and NOINLINE. - Jake From iavor.diatchki at gmail.com Sun Apr 27 12:12:08 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun Apr 27 12:06:44 2008 Subject: [Haskell-cafe] Help with complicated type inference In-Reply-To: <48145E8E.1040107@cogito.org.uk> References: <48145E8E.1040107@cogito.org.uk> Message-ID: <5ab17e790804270912t755e14aco5a05c67268e38122@mail.gmail.com> Hello, How about defining the types like this: data PVal a = Unit a | Array [a] data Val = IntVal (PVal Int) | BoolVal (PVal Bool) -- | etc instance Serialize Int where ... instance Serialize a => Serialize (PVal a) where ... instance Serialize Val where ... Hope this helps. -Iavor On Sun, Apr 27, 2008 at 4:07 AM, Paul Johnson wrote: > I'm trying to write an AMQP framing layer. AMQP has two very similar union > types: there is a "variant" that contains a single item, and an "array" > which consists of a list of elements of the same type. So I thought I could > define a "Unit" type container thus: > > > newtype Unit a = Unit {unUnit :: a} > > So now I can say: > > > type AmqpVariant = AmqpVariantBase Unit > > type AmqpArray = AmqpVariantBase [] > > Then the AmqpVariantBase type looks something like this (except that it > doesn't work, see below): > > > data forall a . (AmqpWire a, AmqpWire (c a)) => > > AmqpVariantBase c = AmqpVarBin8 (c Bin8) > > | AmqpVarInt8 (c Int8) > > | AmqpVarUint8 (c Word8) > > | AmqpVarChar (c Word8) > > | AmqpVarBoolean (c Bool) > > | AmqpVarBin16 (c Bin16) > > | AmqpVarInt16 (c Int16) > > | AmqpVarUint16 (c Word16) > > | AmqpVarBin32 (c Bin32) > > | AmqpVarInt32 (c Int32) > > -- And on for about 20 more types, including compound types. > > All AMQP types have to be seralised, so I've defined a class "AmqpWire" for > serialisation in AMQP format. All the individual types (Bin8, Int8 etc) are > instances of this class. I've also defined instances for Unit and [] such > as: > > > instance (AmqpWire a) => AmqpWire (Unit a) where > > amqpPut = amqpPut . unUnit > > amqpGet = map Unit amqpGet > > The problem is with the type constraint for AmqpVariantBase. I need to say > "AmqpWire (c a)" without explicitly listing all the values of "a" (i.e. > Bin8, Int8, etc) because any time I use AmqpVariantBase I have to repeat the > same constraint. How do I do this? > > Paul. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jnf at arcor.de Sun Apr 27 12:12:46 2008 From: jnf at arcor.de (=?ISO-8859-1?Q?J=FCrgen?= Nicklisch-Franken) Date: Sun Apr 27 12:07:26 2008 Subject: [Haskell-cafe] Ann: Lekash.org Message-ID: <1209312767.1524.8.camel@jutaro-laptop> The Haskell IDE written in Haskell ?(currently in early infancy) called Leksah has now a website (with reference to a Google Code issue tracker): http://leksah.org/ Contributions of all kind welcome. (The released version is still 0.11 but the development version 0.3 has made some progress.) J?rgen From d at vidplace.com Sun Apr 27 12:16:30 2008 From: d at vidplace.com (David F. Place) Date: Sun Apr 27 12:11:10 2008 Subject: [Haskell-cafe] Trouble compiling collections-0.3 (from Hackage) In-Reply-To: <7EE26CA2-D0B2-49CB-9649-5745ACEAB1F6@gmail.com> References: <48139DC0.4090809@vidplace.com> <7EE26CA2-D0B2-49CB-9649-5745ACEAB1F6@gmail.com> Message-ID: <05E80D26-6853-4B75-B86C-F1D9F193D235@vidplace.com> Thanks for the tip. I edited the collections.cabal file to add "bytestring" to the Build-depends. It also needed "containers" and "array"! The build gave streams of warnings and finally failed, so I guess this library is not ready for use. On Apr 26, 2008, at 5:30 PM, Jake Mcarthur wrote: > On Apr 26, 2008, at 4:25 PM, David F. Place wrote: > >> Data/Collections.hs:154:17: >> Could not find module `Data.ByteString.Lazy': >> it is a member of package bytestring-0.9.0.4, which is hidden > > In the .cabal file, add "bytestring" to the dependencies property. > > - Jake ___________________ (---o-------o-o-o---o-o-o----( David F. Place mailto:d@vidplace.com From niklas.broberg at gmail.com Sun Apr 27 13:20:30 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Apr 27 13:15:26 2008 Subject: [Haskell-cafe] Help with complicated type inference In-Reply-To: <48145E8E.1040107@cogito.org.uk> References: <48145E8E.1040107@cogito.org.uk> Message-ID: On 4/27/08, Paul Johnson wrote: > I'm trying to write an AMQP framing layer. AMQP has two very similar union > types: there is a "variant" that contains a single item, and an "array" > which consists of a list of elements of the same type. So I thought I could > define a "Unit" type container thus: > > > newtype Unit a = Unit {unUnit :: a} > > So now I can say: > > > type AmqpVariant = AmqpVariantBase Unit > > type AmqpArray = AmqpVariantBase [] > > Then the AmqpVariantBase type looks something like this (except that it > doesn't work, see below): > > > data forall a . (AmqpWire a, AmqpWire (c a)) => > > AmqpVariantBase c = AmqpVarBin8 (c Bin8) > > | AmqpVarInt8 (c Int8) > > | AmqpVarUint8 (c Word8) > > | AmqpVarChar (c Word8) > > | AmqpVarBoolean (c Bool) > > | AmqpVarBin16 (c Bin16) > > | AmqpVarInt16 (c Int16) > > | AmqpVarUint16 (c Word16) > > | AmqpVarBin32 (c Bin32) > > | AmqpVarInt32 (c Int32) > > -- And on for about 20 more types, including compound types. > > All AMQP types have to be seralised, so I've defined a class "AmqpWire" for > serialisation in AMQP format. All the individual types (Bin8, Int8 etc) are > instances of this class. I've also defined instances for Unit and [] such > as: > > > instance (AmqpWire a) => AmqpWire (Unit a) where > > amqpPut = amqpPut . unUnit > > amqpGet = map Unit amqpGet > > The problem is with the type constraint for AmqpVariantBase. I need to say > "AmqpWire (c a)" without explicitly listing all the values of "a" (i.e. > Bin8, Int8, etc) because any time I use AmqpVariantBase I have to repeat the > same constraint. How do I do this? How about class AmqpWireC c where amqpPutC :: AmqpWire a => c a -> ... amqpGetC :: AmqpWire a => ... -> c a instance AmqpWireC Unit where amqpPutC = amqPut . unUnit amqpGetC = Unit . amqpGet instance (AmqpWire a, AmqpWireC c) => AmqpWire (c a) where amqpPut = amqpPutC amqpGet = amqpGetC data (AmqpWireC c) => AmqpVariantBase c = AmqpVarBin8 (c Bin8) | AmqpVarInt8 (c Int8) ... Does that work like you intended? Cheers, /Niklas From claus.reinke at talk21.com Sun Apr 27 13:40:01 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Sun Apr 27 13:34:42 2008 Subject: [Haskell-cafe] some questions about type improvement, FDs vs TFs, and Hugs vs GHCi Message-ID: <006e01c8a88d$b9e8dc80$11257ad5@cr3lt> consider class FD a b | a -> b instance CFD a b => FD a b class CFD a b instance CFD Bool Char and the constraint 'CFD Bool c'. logically, we know that if we have 'CFD Bool c', we also have 'FD Bool c', which implies that 'c' is uniquely determined, which implies that 'c~Char'. practically, the need to find an instance for 'CFD Bool c' does not generate a demand for implied instances that could lead to this improvement. q1: should there be such a forward demand? ie, instead of failing to find the instance for 'CFD Bool c', should the transitive closure of forward implications be taken into account for FDs, similar to the transitive closure of backward implications? without such forward inferences, consistency of FDs seems hard to guarantee, unless one conservatively rules out everything that might lead to an inconsistency. without such forward inference, implementations differ in their interpretation of this kind of code (as so often): Hugs rejects the program ("Instance is more general than a dependency allows"), which is conservative, but seems to make perfect sense: there's no FD for class 'CFD', so there's no guarantee that all those implied instances of class 'FD' will conform to its own FD. that is easily fixed, it seems: class FD a b | a -> b instance CFD a b => FD a b class FD a b => CFD a b instance CFD Bool Char now, there cannot be an instance of 'CFD' unless there also is an instance of 'FD', in such a way that the parameters of 'CFD' obey the FD of 'FD'. and, in fact, Hugs does now accept this code, and is able to improve 'CFD Bool c' to 'CFD Bool Char', reducing the latter as given: :t undefined :: CFD Bool c => c undefined :: Char but wait a second: we have given an instance of 'CFD', which according to the superclass constraint for that class, is valid only if there is a corresponding instance of 'FD', and there is such an instance of 'FD' if there is an instance of 'CFD'. in other words: if the 'CFD' instance is accepted, it is valid, if it isn't accepted, it is not valid. q2: is this treatment of recursion for class instances intended, or is it an unexpected artifact of the special treatment of superclass constraints? GHCi also accepts this code, but it doesn't seem to do the reduction or improvement: :t undefined :: CFD Bool c => c undefned :: CFD Bool c => c :: (CFD Bool c) => c actually, GHCi accepts the first program, too! perhaps it is delaying the FD consistency check until there is an actual rather than a possible FD conflict? unfortunately not, as we can see if we add a conflicting 'CFD' instance: class FD a b | a -> b instance CFD a b => FD a b class {- FD a b => -} CFD a b instance CFD Bool Char instance CFD Bool Bool note that the conflict is not in 'CFD' but in the implied instances of 'FD', which GHCi doesn't seem to take into account for any FD consistency check: *Main> :t undefined :: CFD Bool c => c undefined :: CFD Bool c => c :: (CFD Bool c) => c *Main> :t undefined :: CFD Bool Char => c undefined :: CFD Bool Char => c :: c *Main> :t undefined :: FD Bool c => c undefined :: FD Bool c => c :: (CFD Bool c) => c *Main> :t undefined :: FD Bool Char => c undefined :: FD Bool Char => c :: c only if we explicitly mention the inconsistent constraints together, and directly in terms of 'FD', not just in terms of 'CFD', do we get the expected error, and even then, the FD isn't used for improvement: *Main> :t undefined :: (CFD Bool Char,CFD Bool Bool) => c undefined :: (CFD Bool Char,CFD Bool Bool) => c :: c *Main> :t undefined :: (FD Bool Char,FD Bool Bool) => c :1:0: Couldn't match expected type `Char' against inferred type `Bool' When using functional dependencies to combine FD Bool Bool, arising from the polymorphic type `forall c. (FD Bool Char, FD Bool Bool) => c' at :1:0-44 FD Bool Char, arising from the polymorphic type `forall c. (FD Bool Char, FD Bool Bool) => c' at :1:0-44 *Main> :t undefined :: (FD Bool Char,FD Bool c) => c undefined :: (FD Bool Char,FD Bool c) => c :: (CFD Bool c) => c this looks like a bug to me, or am i missing something? perhaps we fare better with TFs, as FD development in GHC was put on hold while the new foundations for TFs were put in place? unfortunately, we can't even define TFs in terms of classes, as has been discussed here before (in the context of using FD-based libaries in TF-based client code). what we'd like to write is something like: type family TF a type instance TF a = CTF a b => b -- won't work.. class {- FD a b => -} CTF a b instance CTF Bool Char instance CTF Bool Bool as with the FD-based variant, the definition of TF should not work unless there is a functional relationship between the parameters of 'CTF', but the 'TF' instance isn't even accepted syntactically ("Illegal polymorphic type in type instance"). q3: (a) are qualified types in type instances problematic, or just not yet implemented, or not yet investigated in theory? (b) what about the intended interaction of TFs and FDs in the example. it would seem to permit the use of FD-based code in TFs, as requested here earlier, but is this ever going to be supported? questions, questions,.. does anybody have answers?-) claus From paul at cogito.org.uk Sun Apr 27 14:11:23 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Sun Apr 27 14:06:01 2008 Subject: [Haskell-cafe] Help with complicated type inference In-Reply-To: <5ab17e790804270912t755e14aco5a05c67268e38122@mail.gmail.com> References: <48145E8E.1040107@cogito.org.uk> <5ab17e790804270912t755e14aco5a05c67268e38122@mail.gmail.com> Message-ID: <4814C1CB.7070900@cogito.org.uk> Iavor Diatchki wrote: > Hello, > How about defining the types like this: > > data PVal a = Unit a | Array [a] > data Val = IntVal (PVal Int) | BoolVal (PVal Bool) -- | etc > > instance Serialize Int where ... > instance Serialize a => Serialize (PVal a) where ... > instance Serialize Val where ... > Thanks, but its not quite what I'm looking for. It gives an AMQP "array" of Int8 the same type as an AMQP "variant" containing an Int8. I'd prefer them to have distinct types. Paul. From zefria at gmail.com Sun Apr 27 14:58:52 2008 From: zefria at gmail.com (Daniel Gee) Date: Sun Apr 27 14:53:29 2008 Subject: [Haskell-cafe] question about GHC and Unicode Message-ID: <73871fc00804271158m4b071bd0se0821b2ae91af1f2@mail.gmail.com> In GHC there's a GHC.Unicode library, but for a string such as "?????", a GHC compiled program prints it as a string of unknown characters, and in the interpreter, the string evaluates to a string of escape sequences instead of displaying properly. Is there a way to get/activate unicode support in GHC? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080427/e82bb242/attachment.htm From dons at galois.com Sun Apr 27 15:02:25 2008 From: dons at galois.com (Don Stewart) Date: Sun Apr 27 14:57:02 2008 Subject: [Haskell-cafe] question about GHC and Unicode In-Reply-To: <73871fc00804271158m4b071bd0se0821b2ae91af1f2@mail.gmail.com> References: <73871fc00804271158m4b071bd0se0821b2ae91af1f2@mail.gmail.com> Message-ID: <20080427190225.GB5954@scytale.galois.com> zefria: > In GHC there's a GHC.Unicode library, but for a string such as " *AIOO", a > GHC compiled program prints it as a string of unknown characters, and in > the interpreter, the string evaluates to a string of escape sequences > instead of displaying properly. > > Is there a way to get/activate unicode support in GHC? GHC supports unicode internally, and String and Char are all unicode. To do unicode IO however, you need to use the utf8-string package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utf8-string Just import and use IO functions from System.IO.UTF8, and that's it! -- Don From zefria at gmail.com Sun Apr 27 15:26:20 2008 From: zefria at gmail.com (Daniel Gee) Date: Sun Apr 27 15:20:55 2008 Subject: [Haskell-cafe] question about GHC and Unicode In-Reply-To: <20080427190225.GB5954@scytale.galois.com> References: <73871fc00804271158m4b071bd0se0821b2ae91af1f2@mail.gmail.com> <20080427190225.GB5954@scytale.galois.com> Message-ID: <73871fc00804271226y184cb7a8x4e79a7dcb75b7c5c@mail.gmail.com> On Sun, Apr 27, 2008 at 1:02 PM, Don Stewart wrote: > GHC supports unicode internally, and String and Char are all unicode. > > To do unicode IO however, you need to use the utf8-string package: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utf8-string > > Just import and use IO functions from System.IO.UTF8, and that's it! crap... I was hoping for a switch or something. The program is supposed to be an interpreter that includes unicode IO support, and I wanted to use readline or editline or similar for it. Is there any library you know of that would have that kind of an ability while still using unicode? Between readline and unicode, unicode is the more important, but a readline ability would still be very nice. From dons at galois.com Sun Apr 27 15:29:34 2008 From: dons at galois.com (Don Stewart) Date: Sun Apr 27 15:24:14 2008 Subject: [Haskell-cafe] question about GHC and Unicode In-Reply-To: <73871fc00804271226y184cb7a8x4e79a7dcb75b7c5c@mail.gmail.com> References: <73871fc00804271158m4b071bd0se0821b2ae91af1f2@mail.gmail.com> <20080427190225.GB5954@scytale.galois.com> <73871fc00804271226y184cb7a8x4e79a7dcb75b7c5c@mail.gmail.com> Message-ID: <20080427192934.GC5954@scytale.galois.com> zefria: > On Sun, Apr 27, 2008 at 1:02 PM, Don Stewart wrote: > > GHC supports unicode internally, and String and Char are all unicode. > > > > To do unicode IO however, you need to use the utf8-string package: > > > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utf8-string > > > > Just import and use IO functions from System.IO.UTF8, and that's it! > > crap... I was hoping for a switch or something. > > The program is supposed to be an interpreter that includes unicode IO > support, and I wanted to use readline or editline or similar for it. > Is there any library you know of that would have that kind of an > ability while still using unicode? Between readline and unicode, > unicode is the more important, but a readline ability would still be > very nice. Ian Lynagh wrote a pure haskell readline implementation a while ago, that would be trivial to change to use System.IO.UTF8.getLine -- or you could write your own (basic history/readline editing is fairly simple). -- Don From paul at cogito.org.uk Sun Apr 27 15:32:39 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Sun Apr 27 15:27:17 2008 Subject: [Haskell-cafe] Help with complicated type inference In-Reply-To: References: <48145E8E.1040107@cogito.org.uk> Message-ID: <4814D4D7.8080901@cogito.org.uk> Niklas Broberg wrote: > How about > > class AmqpWireC c where > amqpPutC :: AmqpWire a => c a -> ... > amqpGetC :: AmqpWire a => ... -> c a > That looks like it might work. I'll give it a go and let you know what happens. Thanks, Paul. From igloo at earth.li Sun Apr 27 15:39:03 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Apr 27 15:33:43 2008 Subject: [Haskell-cafe] question about GHC and Unicode In-Reply-To: <20080427192934.GC5954@scytale.galois.com> References: <73871fc00804271158m4b071bd0se0821b2ae91af1f2@mail.gmail.com> <20080427190225.GB5954@scytale.galois.com> <73871fc00804271226y184cb7a8x4e79a7dcb75b7c5c@mail.gmail.com> <20080427192934.GC5954@scytale.galois.com> Message-ID: <20080427193903.GA13281@matrix.chaos.earth.li> On Sun, Apr 27, 2008 at 12:29:34PM -0700, Donald Bruce Stewart wrote: > > Ian Lynagh wrote a pure haskell readline implementation a while ago, I think that was Malcolm Wallace. Thanks Ian From bulat.ziganshin at gmail.com Sun Apr 27 15:44:05 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Apr 27 15:43:22 2008 Subject: [Haskell-cafe] question about GHC and Unicode In-Reply-To: <20080427193903.GA13281@matrix.chaos.earth.li> References: <73871fc00804271158m4b071bd0se0821b2ae91af1f2@mail.gmail.com> <20080427190225.GB5954@scytale.galois.com> <73871fc00804271226y184cb7a8x4e79a7dcb75b7c5c@mail.gmail.com> <20080427192934.GC5954@scytale.galois.com> <20080427193903.GA13281@matrix.chaos.earth.li> Message-ID: <123966996.20080427234405@gmail.com> Hello Ian, Sunday, April 27, 2008, 11:39:03 PM, you wrote: >> Ian Lynagh wrote a pure haskell readline implementation a while ago, > I think that was Malcolm Wallace. it may become even more interesting if Malcolm thinks that it was Don :)) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From zefria at gmail.com Sun Apr 27 15:55:13 2008 From: zefria at gmail.com (Daniel Gee) Date: Sun Apr 27 15:49:48 2008 Subject: [Haskell-cafe] question about GHC and Unicode In-Reply-To: <20080427192934.GC5954@scytale.galois.com> References: <73871fc00804271158m4b071bd0se0821b2ae91af1f2@mail.gmail.com> <20080427190225.GB5954@scytale.galois.com> <73871fc00804271226y184cb7a8x4e79a7dcb75b7c5c@mail.gmail.com> <20080427192934.GC5954@scytale.galois.com> Message-ID: <73871fc00804271255w15be599cn9c6da590c19dfc53@mail.gmail.com> ah ha, yes. I seem to have found it here: http://www.haskell.org/pipermail/glasgow-haskell-bugs/2001-April/000401.html I'll use this as a base. Many thanks to the both of you. I'll be sure to submit it to Hackage for others to enjoy if I end up adding some capability to it. From dons at galois.com Sun Apr 27 15:55:49 2008 From: dons at galois.com (Don Stewart) Date: Sun Apr 27 15:50:31 2008 Subject: [Haskell-cafe] question about GHC and Unicode In-Reply-To: <73871fc00804271255w15be599cn9c6da590c19dfc53@mail.gmail.com> References: <73871fc00804271158m4b071bd0se0821b2ae91af1f2@mail.gmail.com> <20080427190225.GB5954@scytale.galois.com> <73871fc00804271226y184cb7a8x4e79a7dcb75b7c5c@mail.gmail.com> <20080427192934.GC5954@scytale.galois.com> <73871fc00804271255w15be599cn9c6da590c19dfc53@mail.gmail.com> Message-ID: <20080427195549.GE5954@scytale.galois.com> zefria: > ah ha, yes. I seem to have found it here: > http://www.haskell.org/pipermail/glasgow-haskell-bugs/2001-April/000401.html > > I'll use this as a base. Many thanks to the both of you. I'll be sure > to submit it to Hackage for others to enjoy if I end up adding some > capability to it. yeah, a pure unicode-readline would be an awesome contribution! -- Don From prstanley at ntlworld.com Sun Apr 27 16:16:24 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Sun Apr 27 16:10:55 2008 Subject: [Haskell-cafe] Function Type Calculation (Take 2) Message-ID: <7.0.1.0.0.20080427211156.01d75368@ntlworld.com> In case you missed it the first time here is my query again: Hi I know we've already looked at the topic of function type calculation though last time I didn't have the chance to go through it thoroughly. So here it is again. Apologies for the repetition. I've had a try at calculating function types for two examples below. So to start with I'd be grateful for an assessment of my efforts. All comments are welcome. Thanks, Paul [1] funk f x = f (funk f) x f :: a x :: b funk f x :: c therefore funk :: a -> b -> c RHS f (funk f) x :: c f (funk f) :: d -> c x :: d f :: e -> d -> c funk :: h -> e f :: h unification f :: a = h = (e -> d -> c) x b = d therefore funk :: ((h -> e) -> b -> c) -> b -> c [2] w f = f f Assigning Types f :: a w f :: b therefore w :: a -> b RHS f f :: b f :: c -> b f :: c f :: a = b = c = (c -> b) therefore w :: (a -> a) -> a From allbery at ece.cmu.edu Sun Apr 27 16:31:40 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Apr 27 16:26:18 2008 Subject: [Haskell-cafe] Trouble compiling collections-0.3 (from Hackage) In-Reply-To: <05E80D26-6853-4B75-B86C-F1D9F193D235@vidplace.com> References: <48139DC0.4090809@vidplace.com> <7EE26CA2-D0B2-49CB-9649-5745ACEAB1F6@gmail.com> <05E80D26-6853-4B75-B86C-F1D9F193D235@vidplace.com> Message-ID: On Apr 27, 2008, at 12:16 , David F. Place wrote: > Thanks for the tip. I edited the collections.cabal file to add > "bytestring" to the Build-depends. It also needed "containers" and > "array"! The build gave streams of warnings and finally failed, so > I guess this library is not ready for use. That's a red flag for a library that doesn't support the major library changes that happened with ghc 6.8.2. (It will work with ghc 6.6.1.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From miguelimo38 at yandex.ru Sun Apr 27 16:39:22 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Sun Apr 27 16:34:07 2008 Subject: [Haskell-cafe] Function Type Calculation (Take 2) In-Reply-To: <7.0.1.0.0.20080427211156.01d75368@ntlworld.com> References: <7.0.1.0.0.20080427211156.01d75368@ntlworld.com> Message-ID: <53AF6B0E-0143-411C-9108-695ABA1B79B1@yandex.ru> > [1] > funk f x = f (funk f) x > > f :: a > x :: b > funk f x :: c > therefore funk :: a -> b -> c > > RHS > f (funk f) x :: c > > f (funk f) :: d -> c > x :: d > > f :: e -> d -> c > > funk :: h -> e > f :: h > > unification > f :: a = h = (e -> d -> c) > x b = d No. x :: b = d (a typo?) Don't forget also that funk :: a -> b -> c = h -> e, which means that e = b -> c > therefore funk :: ((h -> e) -> b -> c) -> b -> c No. I don't understand where you've got this expression from. It's funk :: a -> b -> c = (e -> d -> c) -> b -> c = ((b -> c) -> b -> c) - > b -> c According to GHCi: Prelude> let funk f x = f (funk f) x Prelude> :t funk funk :: ((t1 -> t) -> t1 -> t) -> t1 -> t which is about the same. > [2] > w f = f f Can't be typed in Haskell. > Assigning Types > f :: a > w f :: b > therefore w :: a -> b > > RHS > f f :: b > > f :: c -> b > f :: c > > f :: a = b = c = (c -> b) And that's why. It can't happen that c = c -> b. Ever. Prelude> let w f = f f :1:10: Occurs check: cannot construct the infinite type: t = t -> t1 From malcolm.wallace at cs.york.ac.uk Sun Apr 27 16:44:00 2008 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Sun Apr 27 16:39:13 2008 Subject: [Haskell-cafe] question about GHC and Unicode In-Reply-To: <20080427193903.GA13281@matrix.chaos.earth.li> References: <73871fc00804271158m4b071bd0se0821b2ae91af1f2@mail.gmail.com> <20080427190225.GB5954@scytale.galois.com> <73871fc00804271226y184cb7a8x4e79a7dcb75b7c5c@mail.gmail.com> <20080427192934.GC5954@scytale.galois.com> <20080427193903.GA13281@matrix.chaos.earth.li> Message-ID: <9E27210A-4922-44C2-B1E5-BA220C2E0225@cs.york.ac.uk> >> Ian Lynagh wrote a pure haskell readline implementation a while ago, > > I think that was Malcolm Wallace. ... and it is part of the readline package! See System.Console.SimpleLineEditor. Needless to say, it is far from perfect, but does give some basic facilities. There are lots of ways it could be extended. (I haven't checked, but I really hope the cabal mechanisms for configuring the readline package do not require a working actual- readline installation, because SimpleLineEditor is explicitly designed to workaround its absence! It is supposed to provide a uniform interface regardless of whether readline is there.) Regards, Malcolm From duncan.coutts at worc.ox.ac.uk Sun Apr 27 16:57:37 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 27 16:51:51 2008 Subject: [Haskell-cafe] question about GHC and Unicode In-Reply-To: <9E27210A-4922-44C2-B1E5-BA220C2E0225@cs.york.ac.uk> References: <73871fc00804271158m4b071bd0se0821b2ae91af1f2@mail.gmail.com> <20080427190225.GB5954@scytale.galois.com> <73871fc00804271226y184cb7a8x4e79a7dcb75b7c5c@mail.gmail.com> <20080427192934.GC5954@scytale.galois.com> <20080427193903.GA13281@matrix.chaos.earth.li> <9E27210A-4922-44C2-B1E5-BA220C2E0225@cs.york.ac.uk> Message-ID: <1209329857.30059.49.camel@localhost> On Sun, 2008-04-27 at 21:44 +0100, Malcolm Wallace wrote: > >> Ian Lynagh wrote a pure haskell readline implementation a while ago, > > > > I think that was Malcolm Wallace. > > ... and it is part of the readline package! See > System.Console.SimpleLineEditor. Needless to say, it is far from > perfect, but does give some basic facilities. There are lots of ways > it could be extended. > > (I haven't checked, but I really hope the cabal mechanisms for > configuring the readline package do not require a working actual- > readline installation, because SimpleLineEditor is explicitly designed > to workaround its absence! It is supposed to provide a uniform > interface regardless of whether readline is there.) It's certainly possible though from a quick look at the .cabal description and configure.ac script it's not quite clear if it'll do what you want. Duncan From ahey at iee.org Sun Apr 27 18:46:35 2008 From: ahey at iee.org (Adrian Hey) Date: Sun Apr 27 18:41:15 2008 Subject: [Haskell-cafe] Trouble compiling collections-0.3 (from Hackage) In-Reply-To: <05E80D26-6853-4B75-B86C-F1D9F193D235@vidplace.com> References: <48139DC0.4090809@vidplace.com> <7EE26CA2-D0B2-49CB-9649-5745ACEAB1F6@gmail.com> <05E80D26-6853-4B75-B86C-F1D9F193D235@vidplace.com> Message-ID: <4815024B.1010401@iee.org> David F. Place wrote: > Thanks for the tip. I edited the collections.cabal file to add > "bytestring" to the Build-depends. It also needed "containers" and > "array"! The build gave streams of warnings and finally failed, so I > guess this library is not ready for use. I don't think anyone is interested in working on this or maintaining it, so it's probably best not to use it for new stuff. Regards -- Adrian Hey From ry at tinyclouds.org Sun Apr 27 20:31:45 2008 From: ry at tinyclouds.org (ry dahl) Date: Sun Apr 27 20:26:20 2008 Subject: [Haskell-cafe] approximating pi Message-ID: <3ae7f4480804271731j65aea73fl38df214dc7b13637@mail.gmail.com> By picking points randomly from a square one can calculate pi. Keep track of how many points from the square you pick lay in the inscribed circle. Supposing the square's edges are length 2, then the inscribed circle has radius 1. Thus the area of the circle is pi*r^2 = pi. The area of the square is 4. The ratio of points picked from the circle to the total number of picked points will converge to pi / 4. What is the best way to express this algorithm in Haskell? ry From dons at galois.com Sun Apr 27 20:35:23 2008 From: dons at galois.com (Don Stewart) Date: Sun Apr 27 20:29:59 2008 Subject: [Haskell-cafe] approximating pi In-Reply-To: <3ae7f4480804271731j65aea73fl38df214dc7b13637@mail.gmail.com> References: <3ae7f4480804271731j65aea73fl38df214dc7b13637@mail.gmail.com> Message-ID: <20080428003523.GC28162@scytale.galois.com> ry: > By picking points randomly from a square one can calculate pi. Keep > track of how many points from the square you pick lay in the inscribed > circle. Supposing the square's edges are length 2, then the inscribed > circle has radius 1. Thus the area of the circle is pi*r^2 = pi. The > area of the square is 4. The ratio of points picked from the circle > to the total number of picked points will converge to pi / 4. > > What is the best way to express this algorithm in Haskell? Using a random generator, such as System.Random or System.Random.Mersenne, generate random numbers in your range, testing if they're inside the circle, and loop until your limit condition is reached. The full program is about 10 lines or so, so shouldn't be too hard to work out, once you've worked out how to generate Doubles from System.Random.random -- Don From jerzy.karczmarczuk at info.unicaen.fr Sun Apr 27 20:54:39 2008 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Sun Apr 27 20:49:15 2008 Subject: [Haskell-cafe] approximating pi In-Reply-To: <20080428003523.GC28162@scytale.galois.com> References: <3ae7f4480804271731j65aea73fl38df214dc7b13637@mail.gmail.com> <20080428003523.GC28162@scytale.galois.com> Message-ID: Don Stewart writes: > Ry Dahl: >> By picking points randomly from a square one can calculate pi. ... >> What is the best way to express this algorithm in Haskell? > > Using a random generator, such as System.Random or > System.Random.Mersenne, generate random numbers in your range, > testing if they're inside the circle, and loop until your limit > condition is reached. > > The full program is about 10 lines or so, so shouldn't be too hard to > work out, once you've worked out how to generate Doubles from > System.Random.random Ry Dahl seems to know Ruby. Ruby has also comprehensions. So, why not use 'randoms' to generate an infinite list of them, 'take' some N, and then 'sum' 1 on randoms filtered by the circle condition. I think that you won't need full 10 lines of code... Jerzy Karczmarczuk From derek.a.elkins at gmail.com Sun Apr 27 21:05:06 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sun Apr 27 20:59:44 2008 Subject: [Haskell-cafe] approximating pi In-Reply-To: References: <3ae7f4480804271731j65aea73fl38df214dc7b13637@mail.gmail.com> <20080428003523.GC28162@scytale.galois.com> Message-ID: <1209344706.5538.34.camel@derek-laptop> On Mon, 2008-04-28 at 02:54 +0200, jerzy.karczmarczuk@info.unicaen.fr wrote: > Don Stewart writes: > > > Ry Dahl: > >> By picking points randomly from a square one can calculate pi. > ... > >> What is the best way to express this algorithm in Haskell? > > > > Using a random generator, such as System.Random or > > System.Random.Mersenne, generate random numbers in your range, > > testing if they're inside the circle, and loop until your limit > > condition is reached. > > > > The full program is about 10 lines or so, so shouldn't be too hard to > > work out, once you've worked out how to generate Doubles from > > System.Random.random > > Ry Dahl seems to know Ruby. Ruby has also comprehensions. So, why not use > 'randoms' to generate an infinite list of them, 'take' some N, and then > 'sum' 1 on randoms filtered by the circle condition. I think that you > won't need full 10 lines of code... Indeed. I just stuck in one line into lambdabot to do this. As an actual executable and more nicely factored/laid out I'd say it would probably be about 8 wc -l lines (that is everything, the module declarations, imports, blank lines, etc.) From dan.doel at gmail.com Sun Apr 27 22:34:13 2008 From: dan.doel at gmail.com (Dan Doel) Date: Sun Apr 27 22:28:50 2008 Subject: [Haskell-cafe] ANNOUNCE: category-extras 0.2 Message-ID: <200804272234.13482.dan.doel@gmail.com> Hello, all. After quite a bit of collaboration with Edward Kmett over the past few days, I've rolled up a new release of category-extras. Perhaps the most significant addition is the generalized hylomorphism he first blogged about here: http://comonad.com/reader/2008/generalized-hylomorphisms/ added to Control.Recursion under the name 'refoldWith', as all other combinators in the library turn out to be special cases of it. Other changes include: * Data.BranchingStream moves to Control.Comonad.Cofree, and various functions are renamed accordingly, as it is the cofree comonad of a functor: Cofree F A = nu X. A * FX * Similarly, a new module