RE: [Haskell-cafe] libffi mystery
Conor McBride wrote: Is there some way I can get some more static linking to happen? I did poke about online a bit and found some remarks to the effect that GHC got so much more portable after switching to the dynamic libffi. That sounds great, but tough luck for me. So, being both powerless and clueless, I can only ask: how hosed am I? I'd be grateful for any glimmers of light. Have you tried passing -optl-static to ghc (which causes -static to be passed to ld)? Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Bug in HTTP (bad internal error handling)
Bit Connor wrote: On Sat, Oct 16, 2010 at 10:29 AM, Claus Reinke claus.rei...@talk21.com wrote: After it catches this error, the function returns (line 376): return (fail (show e)) The fail is running in the Either monad (The Result type = Either). This calls the default Monad implementation of fail, which is just a call to plain old error. This basically causes the entire program to crash. Actually, it appears that simpleHTTP isn't actually supposed to throw an IOException, and it is instead supposed to return a ConnError result. So the real fix is to fix the code to make this happen. But Sounds like a victim of http://hackage.haskell.org/trac/ghc/ticket/4159 For mtl clients, 'fail' for 'Either' used to call 'Left'. That was changed, though the ticket does not indicate the library versions affected. This looks like the problem. Any idea how to get the HTTP package fixed? I could try making a patch myself, but I would prefer hearing from the HTTP maintainer first, who doesn't seem to be around. I've tried contacting him a few times about getting the base dependencies in HTTP bumped and an upload made, without success. This is a widely used package that's in the platform and that won't work with GHC 7.0 with the current dependencies, so it really needs to get fixed soon. libraries@, what's the right way to proceed? Can I make a Debian-style non-maintainer upload with minimal changes to fix urgent issues like these? Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
Vincent Hanquez wrote: On Fri, Oct 08, 2010 at 12:54:48PM +0100, Sittampalam, Ganesh wrote: What's the motivation for this? Well, I wanted to have a tls/ssl module that integrate nicely with haskell. until then the 2 solutions were: - shelling out to curl: that's not great, usually works until you have an error, and then you're greeted with a curl command line error. the control is pretty poor, what if you want a fancy certificate control ? Also you have absolutely no server support in this case, this is client only. - using either gnutls or openssl bindings: there's multiples reasons this is not great. depending on huge C libraries (security wise, platform wise), massive usage of IO even in place where it shouldn't, low hacking potential (adding ciphers/hash, etc). Apart from that, we all know here why programming in haskell is better than doing the same thing in says, C or python. I think it apply even more when the focus of this is a secure library. While I agree with the potential benefits, I also worry that you will end up making something that is far less well tested in practice. For widely used and fairly low-level libraries like gnutls, openssl and zlib, I'm just skeptical that the benefits outweigh the risks and costs. Anyway, it's just a feeling. Please do prove me wrong :-) Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
Vincent Hanquez wrote: On Fri, Oct 08, 2010 at 11:14:01AM +0530, C K Kashyap wrote: Does native mean Haskell only - without FFI? Native means the implementation is in haskell, and the library is not using another implementation (in another language) to do the work: either through FFI as a binding, or as a wrapper to an external program. What's the motivation for this? One thing I can see is that it would make things easier to install on Windows. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] base-3 - base-4
Johannes Waldmann wrote: Is there a conversion guide for switching from base-3 to base-4? I noticed that ghc-HEAD (6.13) comes with base-4.3 (and no base-3). This will break an awful lot of packages (?), in fact the breakage starts with cabal-install (since it depends on HTTP which depends on base-3). HTTP can build and seems to work with base 4 if you bump the dependency. I contacted Sigbjorn about making a new release a while ago, but nothing has happened yet. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Page rank and GHC docs directory organization
Ketil Malde wrote: Robin KAY komad...@gekkou.co.uk writes: the redirects and ignore the original URLs [2]. Using a 302 Found redirect instead might produce better results, at least for Google But the page you point to suggests 302 is discouraged, and says they don't help for the other search engines. Perhaps 'latest' could just be a symlink to the latest version instead of a redirect? In addition, all versions could have a blurb saying this is for version x.y.z, the latest version can be found (- url with /latest). I believe this should boost the page rank of the 'latest' URL. If you both implement 'latest' as a symlink and have this blurb, then the latest page will always have a rather silly looking link to itself. If the latest numbered version and latest could be generated separately, then I think this would work very well. The quick-n-dirty thing to do would be to switch to the 302 redirects, which given the dominance of google, may well be good enough. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] cabal, Setup.lhs example
Mark Wotton wrote: Perhaps cabal should print a warning if you have a Setup.hs file, _and_ try to use Simple? It'd at least give the hint that they're unhappy together. I think it should instead verify that Setup.hs is consistent with a Simple build. I don't know how much variation exists, but I believe import Distribution.Simple\nmain = defaultMain\n is all such a Setup.hs file actually needs. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Ocaml for Haskellers tutorial
Stephen Tetley wrote: I suspect the difference between the ML module system vs. typeclasses will be as important as lazy vs. strict. As a style point, Ocaml programmers don't seem too prone to combinator mania - so I think golf is a bit less popular over there. Both the lack of laziness and the value restriction can sometimes force combinator definitions to be eta-expanded, which I think makes this style of programming much less attractive. Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Asynchronous exception wormholes kill modularity
Simon Marlow wrote: I came to the conclusion that counting nesting layers doesn't solve the problem: the wormhole still exists in the form of nested unmasks. That is, a library function could always escape out of a masked context by writing unmask $ unmask $ unmask $ ... enough times. [...] mask :: ((IO a - IO a) - IO b) - IO b mask io = do b - blocked if b then io id else block $ io unblock to be used like this: a `finally` b = mask $ \restore - do r - restore a `onException` b b return r So the property we want is that if I call a library function mask $ \_ - call_library_function then there's no way that the library function can unmask exceptions. If all they have access to is 'mask', then that's true. [...] It's possible to mis-use the API, e.g. getUnmask = mask return Given that both the simple mask/unmask and your alternate proposal have backdoors, is the extra complexity really worth it? The problem with the existing API is that it's not possible even for well-behaved library code to use block/unblock without screwing up callers. With the simple mask/unmask, the rule is simply that you don't call unmask except within the context of your own mask calls. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Hackage accounts and real names
Ivan Miljenovic wrote: 5) No-one is convincing anyone else to their point of view, so we have a stale mate. Would allowing pseudonyms but requiring them to be explicitly marked as such be an acceptable compromise? Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Where are the haskell elders?
Günther Schmidt wrote: Is there a listing of sorts for all Haskell-relevant blogs? http://planet.haskell.org Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Lazy language on JVM/CLR
Tom Lokhorst wrote: Also, I wonder if there is some efficient way of implementing the Lazy class, perhaps by having the Force method using runtime code generation to override itself. I don't know if this is possible, but I vaguely remember the Dynamic Language Runtime on .NET doing something like that. .NET 4 (final release due in the next few months) will have a built-in lazy type. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Anyone up for Google SoC 2010?
Gwern Branwen wrote: On Wed, Feb 3, 2010 at 8:14 PM, Henk-Jan van Tuyl hjgt...@chello.nl wrote: On Wed, 03 Feb 2010 23:34:34 +0100, Neil Mitchell ndmitch...@gmail.com wrote: Hi Gwern, Please update: haskell-src-exts - haskell-src **Unknown** This project was an unqualified success. haskell-src-exts is now one of the most commonly used Haskell libraries, achieved the goals in the project proposal, and is an essential piece of Haskell infrastructure. You can see this using Roel van Dijk's reversed dependencies overview [1]: 23 direct and 57 indirect dependencies on haskell-src-exts-1.8.0 Regards, Henk-Jan van Tuyl And how many of those used haskell-src-exts *before* the SoC project? And would have used it regardless? You can't point to a popular project which got a SoC student, and say look at how popular it is - obviously the SoC student was hugely successful. Regardless of that, is there any reason to disregard Neil's summary and not update your page? Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
The problem with interfaces as a replacement for type classes is that they only provide dispatch based on the specific type of the first argument (i.e. the receiver). Type classes allow you to dispatch based on return type, and on the instantiations of generic parameters. Neither of these things is reasonably possible with interfaces. For example you can't directly implement the Read type class with interfaces. Neither can you implement a function of type [a] - ... where the dispatch is based on the instantiation of a - even if you can add an interface to the [] generic type, you might not have a concrete object of type a to dispatch from if the empty list is passed as an argument. From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Peter Verswyvelen Sent: 13 January 2010 09:52 To: Gregory Collins Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP? On Sun, Nov 1, 2009 at 2:57 AM, Gregory Collins g...@gregorycollins.net wrote: Doing OO-style programming in Haskell is difficult and unnatural, it's true (although technically speaking it is possible). That said, nobody's yet to present a convincing argument to me why Java gets a free pass for lacking closures and typeclasses. I might be wrong, but doesn't Java's concepts of inner classes and interfaces together with adapter classes can be used to replace closures and typeclasses in a way? An inner class allows you to implicitly capture the parent object (environment), just like a closure does in a sense. Interfaces group together methods, like type classes do. Although I'm actually a C# fanboy for doing industrial programming, I think the Java designers did an excellent job, finding a good balance in language features, ease of use and readability, and although C# does offer closures and many more FP constructs, I really miss the above Java constructs. === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] mtl and transformers
Ivan Lazar Miljenovic wrote: Martijn van Steenbergen mart...@van.steenbergen.nl writes: Another solution is to build your applications using Cabal and specify your dependency on mtl in the cabal file. But until we have cabal ghci, this completely fails for actual hacking purposes... Just do cabal build -v, then cut and paste the ghc --make command-line and replace --make with --interactive. Obviously rather a hack, but remarkably usable in practice, in my experience. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] darcs 2.4 beta 1 release
Obviously source code documentation would be nice, but why is it show-stopping? Ivan Lazar Miljenovic wrote: I really feel that bug 1720 [1] is a show-stopping bug for darcs, especially since it means that building Haddock for darcs with GHC-6.12.* isn't possible. [1] http://bugs.darcs.net/issue1720 I tried to make a fix, but didn't know enough of how darcs is documented to be able to do anything. Reinier Lamers tux_roc...@reinier.de writes: Hi all, The darcs team would like to announce the immediate availability of darcs 2.4 beta 1. darcs 2.4 will contain many improvements and bugfixes compared to darcs 2.3.1. Highlights are the fast index-based diffing which is now used by all darcs commands, and the interactive hunk-splitting in darcs record. This beta is your chance to test-drive these improvements and make darcs even better. If you have installed the Haskell Platform or cabal-install, you can install this beta release by doing: $ cabal update $ cabal install --reinstall darcs-beta Alternatively, you can download the tarball from http://darcs.net/releases/darcs-2.3.98.1.tar.gz , and build it by hand as explained in the README file. A list of important changes since 2.3.1 is as follows (please let me know if there's something you miss!): * Use fast index-based diffing everywhere (Petr) * Interactive patch splitting (Ganesh) * An 'optimize --upgrade' option to convert to hashed format in-place (Eric) * Hunk matching (Kamil Dworakowski, tat.wright) * Progress reporting is no longer deceptive (Roman Plášil) * A 'remove --recursive' option to remove a directory tree from revision control (Roman Plášil) * A '--remote-darcs' flag for pushing to a host where darcs isn't called darcs * Many miscellaneous Windows improvements (Salvatore, Petr and others) * 'darcs send' now mentions the repository name in the email body (Joachim) * Handle files with boring names in the repository correctly (Petr) * Fix parsing of .authorspellings file (Tomáš Caitt) * Various sane new command-line option names (Florent) * Remove the '--checkpoint' option (Petr) * Use external libraries for all UTF-8 handling (Eric, Reinier) * Use the Haskell zlib package exclusively for compression (Petr) Kind Regards, the darcs release manager, Reinier Lamers ___ 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 === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: no sparks?
\a b - Left a `amb` Right b From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Jamie Morgenstern Sent: 21 December 2009 16:50 To: Benedikt Huber Cc: haskell-cafe@haskell.org Subject: [Haskell-cafe] Re: no sparks? Thank you for all of the responses! The amb package is something like what I want; though, as aforementioned, the right and left rules won't return the same proof and so we can't really use it here. I've been thinking about this problem generally, not just in the Haskell setting. It makes sense (in the very least, with theorem proving) to allow a p|| b to return the value of a or b, whichever returns first, wrapped in a constructor which would allow you to case analyze which result returned case (a p|| b) of (1, Xa) = ... (2, Xb) = ... On Sun, Dec 20, 2009 at 8:52 PM, Benedikt Huber benj...@gmx.net wrote: Daniel Fischer schrieb: Am Sonntag 20 Dezember 2009 23:25:02 schrieb Jamie Morgenstern: Hello; Also, I was wondering if something akin to a parallel or exists. By this, I mean I am looking for a function which, given x : a , y : a, returns either, whichever computation returns first. This wouldn't be easy to reconcile with referential transparency. You can do that in IO, roughly m - newEmptyMVar t1 - forkIO $ method1 = putMVar m t2 - forkIO $ method2 = putMVar m rs - takeMVar m killThread t1 killThread t2 return rs And in this case (returning (Maybe Proof)), you are not happy with any of the results, but with one of the proofs. So you would need something like solve :: Ctx - Prop - Int - IO (Maybe Proof) solve ctx goal n = amb leftRight rightLeft where leftRight = m1 `mplus` m2 rightLeft = m2 `mplus` m1 m1 = (tryRight ctx goal n) m2 = (tryLeft ctx goal n) I think the idea of directly supporting this kind of thing is quite interesting. benedikt === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] ANN: hakyll-0.1
Gregory Crosswhite wrote: Tom Tobin wrote: The 3 clause BSD license is officially a GPL compatible license. See: http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses It is within the terms of the GPL to link GPL code to a bunch of BSD3 code as long as you abide by both the GPL and the BSD3 license. That really just means that BSD3 code can be used in GPL code; you still have to release your own code as GPL if you are including any GPL code. The main licence of darcs is GPL, but I've licensed all my contributions to it as BSD3. My view of this is that while darcs as a whole is obviously still GPL, any of my contributions that can be extracted independently can be used in other projects under BSD3. I'd say that with hakyll, the library itself can be under BSD3 but any executable you produce from it at the moment will necessarily be GPL. Not sure if there's any good way to communicate this fact in the metadata, though. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Working with multiple projects
To install a package from local sources, just run 'cabal install' in the directory with the package's .cabal file. Tony Morris wrote: I don't want to have to upload every time I make a minor change as I am working. Surely there is an easier way. Martijn van Steenbergen wrote: Tony Morris wrote: I have two projects that I intend to put on hackage soon. One depends on the other. I have cabaled both. I am wondering how others work with this kind of set up where changes are made to both libraries as they work. You just update and re-upload the packages as necessary. It really helps here if you follow the versioning guidelines: http://www.haskell.org/haskellwiki/Package_versioning_policy HTH, Martijn. === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] A proposals
Martijn van Steenbergen wrote: wren ng thornton wrote: Another nice thing this suggests is the ability to use underscore as a pattern for when you know the compiler will infer the type but it's too complex to want to write out (e.g. while experimenting). I'd love this! F# has this and I find it very useful. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Haskell - .NET
I think Sigbjorn's binding (http://haskell.forkio.com/dotnet/ http://haskell.forkio.com/dotnet/ as linked below) is the most complete and likely to work, but it's still just a binding not a compiler backend. From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Matthew Podwysocki Sent: 16 September 2009 15:25 To: Peter Verswyvelen Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Haskell - .NET There was in fact another attempt as well, Salsa: http://haskell.org/haskellwiki/Salsa This showed quite a bit of promise but unfortunately was not more than just an experiment. Matt On Wed, Sep 16, 2009 at 10:21 AM, Peter Verswyvelen bugf...@gmail.com wrote: Yes, but interop only touches the surface of what is possible. When a Haskell compiler could create IL code, it would be possible to use the generated code inside a sandbox, e.g. to be used on the web as loadable Silverlight code. Of course the same could be said about other virtual machines, such as Flash or Java, but I don't know about the tail call issue here. I guess for now F# would be the best option, but it would be awesome if Haskell compilers could have more backends. I realize this is a very big undertaking, and has been mentioned before, but it doesn't hurt to refresh the cache lines once in a while, so maybe some bright student picks this up and hacks together something cool during the summer :) On Wed, Sep 16, 2009 at 4:03 PM, Paul Sujkov psuj...@gmail.com wrote: Hi Peter, it seems that this question has been already raised before: http://www.haskell.org/pipermail/haskell-cafe/2005-January/008244.html and there are some .Net interop implementations on the net (it is a question how mature they are, however): http://php.cin.ufpe.br/~haskell/haskelldotnet/ http://php.cin.ufpe.br/%7Ehaskell/haskelldotnet/ http://haskell.forkio.com/dotnet/ 2009/9/16 Peter Verswyvelen bugf...@gmail.com I heard that compiling Haskell to Java is not obvious since tail calls are not supported. .NET's intermediate language (IL) does support tail calls, however it is currently slower than regular calls, and is not always supported by all JITs. But given that F# will soon be officially released, I hope that eventually tail calls will work as expected, and fast See e.g. http://blogs.msdn.com/clrcodegeneration/archive/2009/05/11/tail-call-imp rovements-in-net-framework-4.aspx So, might it be worth considering a .NET backend for a Haskell compiler? Peter Verswyvelen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Regards, Paul Sujkov ___ 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 === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Control.Exception base-3/base-4 woes
Neil Brown wrote: Can anyone tell me how to fix this? I don't think that changing to always use Control.Exception would fix this, because I need to give a different type for catch in base-3 to base-4, so there's still the incompatibility to be dealt with. http://hackage.haskell.org/package/extensible-exceptions ? Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Credit Suisse is hiring
Hi, Just to chime in with the spate of job advertisements, the Global Modelling and Analytics Group (GMAG) at Credit Suisse is once again looking to hire functional programmers. The group consists of about 130 people worldwide. The majority of the group are mathematicians engaged in developing mathematical models for financial products traded by the division. Approximately 20 people are primarily computing experts, based in the Architecture and Delivery (AD) subgroup within GMAG, and successful candidates will also be based in this group. We are already making heavy use of functional programming within the group, and we expect to increase this in the future. Some information about our Haskell projects can be found here: http://www.haskell.org/communities/05-2009/html/report.html#creditsuisse ; more recently we have adopted F# for implementing and deploying models on the .NET platform and we are currently ramping up our F# usage. Our team works closely with the modellers to help them leverage functional programming to improve the design of their code. Key requirements: At least one of: - An academic track record in functional programming. - Significant experience of real-world computing environments, preferably using functional programming. Excellent communication skills in order to convey new ideas to our modelling team. Location: London or New York Contact: Howard Mansell howard.mans...@credit-suisse.com Myself (Ganesh Sittampalam ganesh.sittampa...@credit-suisse.com) and Tobias Gedell tobias.ged...@credit-suisse.com will be attending ICFP 2009 and associated workshops in Edinburgh - if you'd like to discuss this in person, get in touch with us by email, or just grab one of us there. Background information: As one of the world's leading banks, Credit Suisse provides its clients with investment banking, private banking and asset management services worldwide. Founded in 1856, Credit Suisse has a long tradition of meeting the complex financial needs of a wide range of clients, offering advisory services, comprehensive solutions and innovative products to companies, institutional clients and high-net-worth private clients globally. Credit Suisse is active in over 50 countries and employs approximately 46,000 people. Further information can be found at www.credit-suisse.com. Cultural diversity is essential to our success. As such, we employ people from more than 100 countries. Credit Suisse empowers employees to work openly and respectfully with each other and with clients, ultimately striving to deliver superior results while offering initiatives and programs to assist employees achieve a healthy work-life balance. The Global Modelling and Analytics Group (GMAG) is responsible for producing state-of-the-art pricing, trading and risk management models for Credit Suisse. These models are used across a range of businesses in the Fixed Income and Equity departments. The group performs the full spectrum of quantitative work, from mathematical modelling through software implementation and delivery, to risk analysis of trades and existing portfolios. The group's mandate covers all major asset classes, including Credit Derivatives, Commodities, Emerging Markets, Equity Derivatives and Convertibles, Exotics, Foreign Exchange, Fund Linked Products, Interest Rate Products and Mortgage Derivatives. GMAG operates globally with members located in London, New York, Hong Kong, Tokyo, Zurich and São Paolo. Established in 1990, GMAG stands out as a unified quant group that has been covering all major product areas since its inception. The group has always enjoyed a strong relationship with Trading, Structuring and Sales, assisting them with trade pricing and risk management. As the group is based on the trading floor, it is ideally placed to respond to the financial modelling needs of the businesses it supports. The breadth of GMAG's mandate makes it uniquely positioned to leverage the skills and experience of its members, and to provide a consistent modelling approach across all areas. Over time, the group has developed an extensive suite of pricing models on a common platform with complete integration across all asset classes. Quantitative Analysts in GMAG carry out a range of activities which include the creation of sophisticated mathematical models for the valuation of complex derivatives, development of the technology platform used to deliver models and driving the use of these models throughout the bank. Our Quantitative Analysts typically hold an advanced quantitative degree, have excellent analytical and problem-solving skills, demonstrate creative thinking, have strong programming skills, and are confident communicators. === Please access the attached hyperlink for an important electronic communications disclaimer:
RE: [Haskell-cafe] Re: DDC compiler and effects; better than Haskell?
What would preOrder foldr/foldl mean? What about preOrder (reverse . map) and preOrder (map . reverse) ? Another option would be for map to take a strategy as a parameter, sort of like Control.Parallel.Strategies. Peter Verswyvelen wrote: Well, in DDC I believe the order is left to right. But you guys are right, many orders exist. On the other hand, a language might offer primitives to convert pure-to-effectfull functions no, in which you indicate the order you want. e.g. preOrder map No? (anyway Oleg's reply seems to give a definite answer to this thread no? :-) On Thu, Aug 13, 2009 at 11:06 AM, Heinrich Apfelmusapfel...@quantentunnel.de wrote: Russell O'Connor wrote: Peter Verswyvelen wrote: I kind of agree with the DDC authors here; in Haskell as soon as a function has a side effect, and you want to pass that function to a pure higher order function, you're stuck, you need to pick the monadic version of the higher order function, if it exists. So Haskell doesn't really solve the modularity problem, you need two versions of each higher order function really, Actually you need five versions: The pure version, the pre-order traversal, the post-order traversal, the in-order traversal, and the reverse in-order traversal. And that is just looking at syntax. If you care about your semantics you could potentially have more (or less). Exactly! There is no unique choice for the order of effects when lifting a pure function to an effectful one. For instance, here two different versions of an effectful map : mapM f [] = return [] mapM f (x:xs) = do y - f x ys - mapM f xs return (y:ys) mapM2 f [] = return [] mapM2 f (x:xs) = do ys - mapM2 f xs y - f x return (y:ys) Which one will the DCC compiler chose, given map f [] = [] map f (x:xs) = f x : map f xs ? Whenever I write a pure higher order function, I'd also have to document the order of effects. Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Proposal: TypeDirectedNameResolution
Cale Gibbard wrote: There was a great related idea on #haskell the other day: Make explicit qualification unnecessary whenever there is a *unique* choice of module qualifications from those imported which would make the expression typecheck. Ambiguities would still need to be qualified, but I feel that this would eliminate 99% of all ugly qualified names from code. It would be especially good in the case of infix operators, which as far as I know, nobody actually enjoys qualifying explicitly. [...] What do people think of this idea? Personally, it really annoys me whenever I'm forced to give explicit module qualifications, and I think this would really help. It would also subsume the DisambiguateRecordFields extension rather handily. I think this idea would severely damage compositionality. One example of this is that it would make it substantially less likely that subexpressions could be abstracted into a separate declaration without giving a type signature to fix the type of the new declaration. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Proposal: TypeDirectedNameResolution
(To be clear, this about Cale's proposal, not simonpj's one) Johannes Waldmann wrote: Sittampalam, Ganesh wrote: ... it would make it substantially less likely that subexpressions could be abstracted into a separate declaration without giving a type signature to fix the type of the new declaration. OK, then give a type signature to fix the type of (really, to document) the new declaration. I can't understand why declarative programmers insist they should be able to omit (type) declarations ... I find type inference a valuable feature. Generally at some point I annotate top-level declarations, but while developing it's nice not to have to worry about it. Having to annotate every single declaration would be painful. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] powerSet = filterM (const [True, False]) ... is this obfuscated haskell?
perms = sortByM (const [True,False]) This doesn't seem right, since the comparison function is inconsistent and moreover the results will depend on the sorting algorithm chosen. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] powerSet = filterM (const [True, False]) ... is this obfuscated haskell?
Sebastian Fischer wrote: On Jul 28, 2009, at 11:06 AM, Sittampalam, Ganesh wrote: perms = sortByM (const [True,False]) and moreover the results will depend on the sorting algorithm chosen. Is it only that different sorting algorithms enumerate all permutations in different orders or is there a sorting algorithm, such that the above definition does not enumerate all permutations? [..] Hence, perm as defined above can yield a list that contains all permutations of the input (at least once) regardless of the sorting algorithm. Where is the hitch? The at least once bit - unless your non-determinism is based on set rather than bag semantics, it's wrong to duplicate results. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Implicit concatenation in list comprehensions
Roel van Dijk wrote: On Mon, Jul 20, 2009 at 1:27 PM, Roel van Dijkvandijk.r...@gmail.com wrote: I think the tuple sections are a great idea! It also makes tuple types and constructors more alike: x :: (,) String Double x = (,) Pi 3.14159 I just realised this is already in GHC :-) But does you patch also add the equivalent for tuple type annotations? x :: (String, ) Double x = (Pi, ) 3.14159 I am also wondering what the following would/should mean: (1, , ( , 2), ) 'a' 'b' 'c' I would expect it to be a type error, since I think the following is the only sane type the tuple can have (assuming numeric literals :: Int): (1, , ( , 2), ) :: a - b - (Int, a, c - (c, Int), b) Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] A small puzzle: inTwain as function of foldr
Martijn van Steenbergen wrote: Consider the function inTwain that splits a list of even length evenly into two sublists: inTwain Hello world! (Hello ,world!) Is it possible to implement inTwain such that the recursion is done by one of the standard list folds? Does this help? http://www.brics.dk/RS/02/12/BRICS-RS-02-12.pdf Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Bool as type class to serve EDSLs.
There are multiple possible classes that you might want under different circumstances (I think the most interesting issue is whether the class (==), () etc is in has a fundep from the type of the thing being compared to the type of the boolean), but if NoImplicitPrelude (or some other extension) just desugars if-then-else into ifthenelse (with a default implementation of ifthenelse somewhere) I think that would be enough. Of course once you've got ifthenelse you find yourself wanting explicit desugaring of pattern matching (could view patterns help here?), recursion (into an explicit use of fix), etc... Cheers, Ganesh Simon Peyton-Jones wrote: You are absolutely right about the tantalising opportunity. I know that Lennart has thought quite a bit about this very point when designing his Paradise system. Likewise Conal for Pan. One difficulty is, I think, that it's easy to get ambiguity. Eg ifthenelse (a b) e1 e2 The (ab) produces a boolean-thing, and ifthenelse consumes it; but which type of boolean? The Expr type? Real Bools? Or what? If there was a nice design, then GHC's existing -fno-implicit-prelude flag could be extended (again) to desugar if-then-else to the new thing. But the design is unclear, to me anyway. Simon -Original Message- From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Sebastiaan Visser Sent: 27 May 2009 13:32 To: Haskell Cafe Subject: [Haskell-cafe] Bool as type class to serve EDSLs. Hello, While playing with embedded domain specific languages in Haskell I discovered the Num type class is a really neat tool. Take this simple example embedded language that can embed primitives from the output language and can do function application. data Expr :: * - * where Prim :: String - Expr a App :: Expr (a - b) - Expr a - Expr b Take these two dummy types to represent things in the output language. data MyNum data MyBool Now it is very easy to create an Num instance for this language: primPlus :: Expr (MyNum - MyNum - MyNum) primPlus = Prim prim+ instance Num (Epxr MyNum) where a + b = primPlus `App` a `App` b fromInteger = Prim . show ... Which allows you to create very beautiful expression for your language embedded inside Haskell. The Haskell expression `10 * 5 + 2' produces a nice and well typed expression in your embedded domain. But unfortunately, not everyone in the Prelude is as tolerant as the Num instance. Take the Eq and the Ord type classes for example, they require you to deliver real Haskell `Bool's. This makes it impossible make your DSL an instance of these two, because there are no `Bool's only `Expr Bool's. Which brings me to the point that, for the sake of embedding other languages, Haskell's Prelude (or an alternative) can greatly benefit from (at least) a Boolean type class like this: class Boolean a where ifthenelse :: a - b - b - b -- Not sure about this representation. ... And one instance: instance Boolean (Expr MyBool) whereifthenelse c a b = Prim if-then-else `App` c `App` a `App` b Now we can change (for example) the Eq type class to this: class Eq a where (==) :: Boolean b = a - a - b (/=) :: Boolean b = a - a - b For which we can give an implementation for our domain: primEq :: Epxr (a - a - MyBool) primEq = Prim == instance Eq (Expr a) where a == b = primEq `App` a `App` b And now we get all functionality from the Prelude that is based on Eq (like not, , ||, etc) for free in our domain specific language! Off course there are many, many more examples of things from the standard libraries that can be generalised in order to serve reuse in EDSLs. Anyone already working on such a generalized Prelude? I can imagine much more domains can benefit from this than my example above. Any interesting thoughts or pointers related to this subject? Gr, -- Sebastiaan Visser ___ 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 === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] I love purity, but it's killing me.
Sebastiaan Visser wrote: On May 27, 2009, at 1:49 AM, Conal Elliott wrote: Hi Tom, I've been working on another code-generating graphics compiler, generating GPU code. As always, I run into the problem of efficient common subexpression elimination. In Pan, Vertigo Pajama, I used lazy memoization, using stable pointers and weak references, to avoid the worst-case-exponential behavior you mention below. I'm now using a bottom-up CSE method that's slower and more complicated than I'm going for. What do you mean with `exponential behavior'? Exponential related to what? For my FRP EDSL to JavaScript (toy) compiler[1] I've been implementing CSE as well. I traverses the expression tree recursively and creates an small intermediate language containing id's (pointers) to expressions instead of real sub-expressions. Maybe (probably) I am very naive, but I think this trick takes time linear to the amount of sub-expressions in my script. When using a trie instead of a binary tree for the comparisons there should be no more character (or atomic expression) comparisons that the amount of characters in the script. So the problem seems not to be CSE algorithm, but the fact that EDSL itself tends to blow up because it is hosted in Haskell. Like Tom's example: let d = Add c c e = Add d d-- e now as 16 leaf nodes. But again, I might be missing some important point here. That's exactly right. But it's pretty inconvenient to have your expression tree to blow up exponentially in relation to the code the user actually wrote! You can indeed construct an intermediate language that collapses this blowup, but the pass to create it must take exponential time if written completely purely, since it has to visit everything at least once. In my experience [1], observable sharing using GHC's stable names is a pretty effective solution to this problem. Ganesh [1] http://www.earth.li/~ganesh/research/paradise-icfp08/ === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] I love purity, but it's killing me.
Yes, though we don't bother with weak pointers as we only keep the stable names map around for the duration of CSE so there's no ongoing memory leak issue. From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Conal Elliott Sent: 27 May 2009 16:14 To: Sittampalam, Ganesh Cc: Haskell Cafe Subject: Re: [Haskell-cafe] I love purity, but it's killing me. In my experience [1], observable sharing using GHC's stable names is a pretty effective solution to this problem. Plus unsafePerformIO and weak references as in Stretching the storage manager: weak pointers and stable names in Haskell http://citeseer.ist.psu.edu/peytonjones99stretching.html ? Lacking a more elegant alternative, that's what I'll probably do again, as in Pan, Vertigo, and Pajama. - Conal On Wed, May 27, 2009 at 3:51 AM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com wrote: Sebastiaan Visser wrote: On May 27, 2009, at 1:49 AM, Conal Elliott wrote: Hi Tom, I've been working on another code-generating graphics compiler, generating GPU code. As always, I run into the problem of efficient common subexpression elimination. In Pan, Vertigo Pajama, I used lazy memoization, using stable pointers and weak references, to avoid the worst-case-exponential behavior you mention below. I'm now using a bottom-up CSE method that's slower and more complicated than I'm going for. What do you mean with `exponential behavior'? Exponential related to what? For my FRP EDSL to JavaScript (toy) compiler[1] I've been implementing CSE as well. I traverses the expression tree recursively and creates an small intermediate language containing id's (pointers) to expressions instead of real sub-expressions. Maybe (probably) I am very naive, but I think this trick takes time linear to the amount of sub-expressions in my script. When using a trie instead of a binary tree for the comparisons there should be no more character (or atomic expression) comparisons that the amount of characters in the script. So the problem seems not to be CSE algorithm, but the fact that EDSL itself tends to blow up because it is hosted in Haskell. Like Tom's example: let d = Add c c e = Add d d-- e now as 16 leaf nodes. But again, I might be missing some important point here. That's exactly right. But it's pretty inconvenient to have your expression tree to blow up exponentially in relation to the code the user actually wrote! You can indeed construct an intermediate language that collapses this blowup, but the pass to create it must take exponential time if written completely purely, since it has to visit everything at least once. In my experience [1], observable sharing using GHC's stable names is a pretty effective solution to this problem. Ganesh [1] http://www.earth.li/~ganesh/research/paradise-icfp08/ http://www.earth.li/%7Eganesh/research/paradise-icfp08/ === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Strange type error with associated type synonyms
Simon Peyton-Jones wrote: NoMatchErr.hs:20:11: Couldn't match expected type `Memo d' against inferred type `Memo d1' NB: `Memo' is a (non-injective) type function In the second argument of `(.)', namely `appl' In the expression: abst . appl In the definition of `f': f = abst . appl (Rather than give its kind, I thought it was better to focus on the reason for the mis-match, namely the non-injectivity.) I'd suggest is a type function and thus may not be injective or similar, otherwise people will think that type functions which are injective according to the instances they've defined would be ok. Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: [Haskell] [ANN] Safe Lazy IO in Haskell
Nicolas Pouillard wrote: Excerpts from Ryan Ingram's message of Tue May 19 10:23:01 +0200 2009: To be fair, you can do this with some extensions; I first saw this in a paper on Oleg's site [1]. Here's some sample code: This seems like the same trick as the rmonad package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/rmonad It's similar, but rmonad uses an associated datatype to wrap up the constraint, and doesn't split the Monad class up into separate pieces (which generally makes type inference harder). rmonad also supplies an embedding to turn any restricted monad into a normal monad at the cost of using embed/unEmbed to get into and out of the embedding. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] conflicting variable definitions in pattern
Martin Hofmann wrote: It is pretty clear, that the following is not a valid Haskell pattern: foo (x:x:xs) = x:xs My questions is _why_ this is not allowed. IMHO, the semantics should be clear: The pattern is expected to succeed, iff 'x' is each time bound to the same term. How do you define the same term? One natural way of compiling it would be to foo (x:y:xs) | x == y = x:xs but then pattern matching can introduce Eq constraints which some might see as a bit odd. Isn't this allowed, because this would require a strict evaluation of the 'x' variables? The translation into == would probably introduce some strictness, for most implementations of Eq. I don't think this is a huge problem in itself. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] conflicting variable definitions in pattern
Conor McBride wrote: On 15 May 2009, at 09:11, Sittampalam, Ganesh wrote: but then pattern matching can introduce Eq constraints which some might see as a bit odd. Doesn't seem that odd to me. Plenty of other language features come with constraints attached. It's the introduction of a constraint from tweaking a pattern that is odd, I think. By way of precedent H98 rejected this kind of idea in favour of putting 'fail' into Monad. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Removing mtl from the Haskell Platform
rocon...@theorem.ca wrote: I think that use of the mtl should be deprecated so that we move on to improved monad transformer libraries. Having the mtl in the Haskell Platform does the opposite by further entrenching its use, possibly to the point where we may not be able to get rid of it for years. If I had to recommend a replace library, I would pick monadLib. However, there are other libraries, such as the mmtl and transformers and it's related packages that I haven't looked at, and may also make fine replacements for the mtl. We've discussed replacing it with transformers+monads-fd+an mtl compatiblity layer on librar...@. Ross and I plan to propose doing this for the second release of the platform - it's not fair to disrupt the first release at this stage. transformers+monads-fd is quite a small evolution over mtl - it factors out the fundeps into a separate package, tightens up some of the class constraints, and makes State = StateT Identity etc rather than a separate type. Even this breaks a few packages, but doing anything more substantial would be quite disruptive. That's not to say that we shouldn't do it, though. I guess the libraries@ list will continue to be the place that such decisions get made, but I think it's a bit up in the air at the moment. Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [darcs-users] [Haskell-cafe] Darcs as undo/redo system?
Wolfgang Jeltsch wrote: Am Freitag, 8. Mai 2009 18:43 schrieb Jason Dagit: If you wanted to work on this, I would encourage you to read more about patch theory[1,2,3,4] and also try out libdarcs[5]. Is libdarcs the same as the darcs library package on Hackage (which exports the darcs API)? Yes. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] is value evaluated?
Brandon S. Allbery KF8NH wrote: On May 8, 2009, at 16:31 , Sittampalam, Ganesh wrote: Brandon S. Allbery KF8NH wrote: Unless it catches exceptions itself (which strikes me as a bad idea; it becomes a trivial way to ignore exceptions, leading to bad programming practices) either they're handled inside the _|_ (in which case it isn't _|_ from the standpoint of our test) or in an outer scope (in which case our test produces _|_ from the standpoint of the exception handler). Surely it just needs to inspect the thunk to decide whether it's _|_ or not, rather than entering it? The point is it can never be given a thunk that is _|_ because exception handling will have either converted it to a non-_|_ or shunted past the test. You can set up a thunk in one place, enter it wrapped in a catch in another place, and then inspect it in a third place, e.g. (somewhat pseudo-code): do let x = if 1==1 then error foo else 3 y - catch (evaluate x) (\_ - 2) b - isEvaluated x Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Why is Bool no instance of Num and Bits?
Stephan Friedrichs wrote: When looking for an xor function, I found one in Data.Bits but couldn't use it for Bool, because Bool is no instance of Bits and of Num (which would be necessary, because it's class (Num b) = Bits b). My question is: Why not? [...] quite trivial... Why is this not part of base? Or am I missing something? One reason would be that we don't want 1 + True to typecheck, even if it does have a sensible interpretation. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] is value evaluated?
Brandon S. Allbery KF8NH wrote: On May 8, 2009, at 01:33 , Joe Fredette wrote: That strikes me as being bad in a I'm violating the Halting Problem sort of way- but I'm not sure how. Is there some contradictory construction that could be built from such a function? I don't think it is; surely the Haskell runtime knows which thunks it has evaluated. It just explicitly violates referential transparency, and therefore must be in IO. You may be thinking that it would return a result for _|_, but as described if you fed it _|_ it could only produce False (if the _|_ has been evaluated you would not be able to reach the test). It could probably return True in GHC since you can catch exceptions. That still doesn't mean it solves the halting problem, of course. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] is value evaluated?
Brandon S. Allbery KF8NH wrote: On May 8, 2009, at 13:08 , Sittampalam, Ganesh wrote: Brandon S. Allbery KF8NH wrote: and therefore must be in IO. You may be thinking that it would return a result for _|_, but as described if you fed it _|_ it could only produce False (if the _|_ has been evaluated you would not be able to reach the test). It could probably return True in GHC since you can catch exceptions. That still doesn't mean it solves the halting problem, of course. Unless it catches exceptions itself (which strikes me as a bad idea; it becomes a trivial way to ignore exceptions, leading to bad programming practices) either they're handled inside the _|_ (in which case it isn't _|_ from the standpoint of our test) or in an outer scope (in which case our test produces _|_ from the standpoint of the exception handler). Surely it just needs to inspect the thunk to decide whether it's _|_ or not, rather than entering it? Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Data.Map and strictness (was: Is Haskell a GoodChoice for WebApplications?(ANN: Vocabulink))
seq something like size map that will force a traversal of the entire tree, and ensure that the result is actually demanded, e.g. when writing to a TVar: do ... let map' = Data.Map.delete key map size map' `seq` writeTVar tvar map' ... (Not tested) Note that this also won't force any of the values; it sounds like in this case you don't want them forced. -Original Message- From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Tim Docker Sent: 07 May 2009 09:46 To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Data.Map and strictness (was: Is Haskell a GoodChoice for WebApplications?(ANN: Vocabulink)) Actually, I'm unsure how to fix this. For an expression like this: Data.Map.delete key map how can I use seq (or something else) to sufficiently evaluate the above to ensure that the value associated with key can be garbage collected? My knowledge of Data.Map is limited to it's haddock documentation. -Original Message- From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Tim Docker Sent: Thursday, 7 May 2009 6:04 PM To: haskell-cafe@haskell.org Subject: RE: [Haskell-cafe] Is Haskell a Good Choice for WebApplications?(ANN: Vocabulink) I think that multi-threading in combination with laziness makes space usage harder to manage. In fact, just today I have discovered a problem with a long running server process with a subtle space leak. With a regular process that communicates with the outside world via IO, I know that the act of communicating a value causes it to be fully evaluated. However, with a multi threaded process, communication occurs via writes to TVars/IOVars and nothing gets evaluated. This gives lots of opportunities for space leaks. In this particularly case cleanup code was removing a large entry from a map stored in a Tvar. Because that map is only read infrequently, however, the memory release is delayed. This is the second such problem I've found. The profiling tools do help in discovering them, but it still needs a bit of thought and analysis. I wonder if, for my application, I should work out some means of deepseqing every value written to a Tvar. Tim -Original Message- From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of wren ng thornton Sent: Thursday, 7 May 2009 2:06 PM To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Is Haskell a Good Choice for Web Applications?(ANN: Vocabulink) FFT wrote: Anton van Straaten wrote: The app is written for a client under NDA, so a blog about it would have to be annoyingly vague. No doubt the potential for encountering space leaks goes up as one writes less pure code, persist more things in memory, and depend on more libraries. Exactly. I'm worried about, e.g. needing to use something as simple as a stream of prime numbers (see the recent thread about leaks there) The issues here are going to be the same in Haskell as in every other language. There's always a tradeoff between the memory of caching old results vs the time of recalculating them. At present no language's RTS/GC is smart enough to make that tradeoff for you, and so memoization must be done manually. There are some tricks to help make this easier (e.g. weak pointers), but the problem will always remain. The only thing that makes this perhaps trickier than in other languages is that, AFAIK/R, the reflection API to ask the RTS how it's feeling about memory at any given point isn't terribly portable (between Haskell compilers) or polished/pretty. Then again, the other GC languages I've dealt with aren't much better and are often worse. -- Live well, ~wren ___ 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 === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Template Haskell + Profiling
Do your profiling builds with -osuf p_o -hisuf p_hi, and then run a non-profiling build first. This means that both sets of object/hi files are available which placates TH. Ganesh From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Krzysztof Skrzetnicki Sent: 24 April 2009 16:28 To: Haskell Cafe Subject: [Haskell-cafe] Template Haskell + Profiling Hi I'm trying to build some modules that use TH with profiling enabled. The normal build works: $ ghc -fforce-recomp --make -cpp -O -DXQUERY2_TEST Main [1 of 8] Compiling Text.XML.Expat.FormatCustom ( Text/XML/Expat/FormatCustom.hs, Text/XML/Expat/FormatCustom.o ) [2 of 8] Compiling DataStructures ( DataStructures.hs, DataStructures.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package containers-0.2.0.1 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package filepath-1.1.0.2 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package old-time-1.0.0.2 ... linking ... done. Loading package unix-2.3.2.0 ... linking ... done. Loading package directory-1.0.0.3 ... linking ... done. Loading package process-1.0.1.1 ... linking ... done. Loading package random-1.0.0.1 ... linking ... done. Loading package derive-0.1.4 ... linking ... done. [3 of 8] Compiling Utils( Utils.hs, Utils.o ) [4 of 8] Compiling Semantics.Pure ( Semantics/Pure.hs, Semantics/Pure.o ) [5 of 8] Compiling Database ( Database.hs, Database.o ) [6 of 8] Compiling XPathDSL ( XPathDSL.hs, XPathDSL.o ) [7 of 8] Compiling QueryParse ( QueryParse.hs, QueryParse.o ) [8 of 8] Compiling Main ( Main.hs, Main.o ) Linking Main ... But profiling one fails: $ ghc -prof -auto -auto-all -fforce-recomp --make -cpp -O -DXQUERY2_TEST Main [1 of 8] Compiling Text.XML.Expat.FormatCustom ( Text/XML/Expat/FormatCustom.hs, Text/XML/Expat/FormatCustom.o ) [2 of 8] Compiling DataStructures ( DataStructures.hs, DataStructures.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. DataStructures.hs:1:0: Dynamic linking required, but this is a non-standard build (eg. prof). You need to build the program twice: once the normal way, and then in the desired way using -osuf to set the object file suffix. The error message is somewhat cryptic to me. Does anyone know how to perform profiling build when using TH? Regards Christopher Skrzętnicki === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] compilation to C, not via-C
Ryan Ingram wrote: There was another talk about compiling Haskell into Excel spreadsheets for finance, but I can't seem to locate it right now. It was an ICFP experience report. http://www.earth.li/~ganesh/research/paradise-icfp08 Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] (n+k) patterns
Richard O'Keefe wrote: The thing is that it really seems bizarre to see this one feature singled out for non-implementation. If I can do the equivalent of n+k patterns by programming in the *type system*, why *not* in a pattern? Do you mean by something like the following? data Z = Z data S n = S n type Plus2 a = S (S a) minus2 :: Plus2 a - a minus2 _ = undefined -- or actually use the values, or whatever If so, I'd say that n+k patterns go well beyond this kind of pattern aliases, particularly since they operate on arbitrary Nums, not just an inductively defined natural number type. Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) --first release
Jon Fairbairn wrote:
John A. De Goes j...@n-brain.net writes:
That's absurd. You have no way to access private source code, so any
decision on what features to exclude from future versions of Haskell
must necessarily look at publicly accessible source code.
This is all entirely beside the point. The question is not whether
n+k patterns should be in the language, it's whether an
implementation of Haskell 98 should include them.
The only alternative is to continuously add, and never remove,
features from Haskell, even if no one (that we
know) uses them.
But we can remove them in future language versions. The point I was
trying to make at the beginning of this subthread was that
implementations should follow the definition, because having a core
language (Haskell 98) that can be relied on is simpler and wastes
less time than the alternative.
There has to be a bit of give and take here between standards and
implementations. The Haskell 98 standard is now very old and becoming
increasingly less relevant, hence the Haskell' effort. (n+k) patterns
were always controversial and the decision to include them has indeed
been reversed by the Haskell' committee. So I would say that {Haskell 98
- (n+k)} is itself a worthwhile standard to implement. UHC is clear that
this is what it has implemented, so it's not as if they are
misrepresenting themselves.
Ganesh
===
Please access the attached hyperlink for an important electronic
communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) --firstrelease
Jon Fairbairn wrote:
Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com writes:
So I would say that {Haskell 98 - (n+k)} is itself a worthwhile
standard to implement.
It's not a standard. You have to document the difference (waste of
time), programmers have to notice the difference (waste of time),
books that describe H 98 no longer apply (waste of effort).
Interestingly, the removal discussion from Haskell'
(http://hackage.haskell.org/trac/haskell-prime/wiki/RemoveNPlusK)
explicitly mentions some Haskell books use it (this was the main reason
it was kept in Haskell 98) and also points out that the report
explicitly warned that they might be removed in future.
Presumably those were books about Haskell 1.4 or before. If n+k was only
kept to keep those books still valid, then they certainly shouldn't
survive any longer; any H98 books that used them deserve their fate,
IMO.
You can
argue that the wastes here are individually small, but you have to
multiply them by the number of times they happen (and again, I'm
taking n+k as an example of a general problematic attitude that's
been with us since FORTRAN I*, rather than really arguing about n+k
specifically).
[*] The FORTRAN IV standard contains some really quite entertaining
examples of what happens when you try to standardise the intersection
of divergent implementations of a programming language.
I'd be much more inclined to agree with you if the example in question
was not n+k. Also, divergence by omission of features is much easier to
recover from than mutually incompatible implementation of the same
feature.
Ganesh
===
Please access the attached hyperlink for an important electronic
communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) --first release
Miguel Mitrofanov wrote: Jon Fairbairn wrote on 20.04.2009 13:59: Achim Schneider bars...@web.de writes: Jon Fairbairn jon.fairba...@cl.cam.ac.uk wrote: a...@cs.uu.nl writes: Utrecht Haskell Compiler -- first release, version 1.0.0 The UHC team is happy to announce the first public release of the Utrecht Haskell Compiler (UHC). UHC supports almost all Haskell98 features Why? Is there something about Haskell 98 that's hard to implement? Insanity. I doubt anyone is going to miss n+k patterns: That (taken with the followup from Richard O'Keefe saying he does use them) underlines my point, really. What follows is specific to Haskell, but the general point applies to most languages I've encountered. I have no love for n+k patterns, but they are part of Haskell98 -- and were the subject of protracted arguments for and against them before the Report was finished (I was against them, if I remember correctly). Any implementation claiming to be of Haskell98 should have them, whether or not the implementor likes them, because otherwise someone will come along with a valid Haskell98 programme and it won't compile, so they'll have to hack it around. This sort of thing (and resulting #ifdef all over the place) wastes far more programmer time in the end (assuming the compiler becomes popular) than it would take to implement the feature. It's not an implementor's place to make such decisions -- they can legitimately say this feature sucks and tell the next Haskell committee so. If they care enough about it, they can lobby or get on that next committee, but the arguments for n+k patterns /in Haskell98/ were done long ago. I disagree. First of all, UHC states explicitly that some features are not supported (and probably never would be). Secondly, it seems like almost nobody uses (n+k)-patterns, and when they are used, they make the code less readable; so it's good NOT to support them, in order to make programmers avoid them as much as possible. I don't think #ifdef's would be really all over the place; it's more likely that a minor refactoring would take place so that (n+k)-patterns would disappear. In addition, (n+k) patterns will be removed from the standard as soon as the Haskell prime process produces a new one, so people who want to make their code support that new standard should be removing them right now. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] ANNOUNCE: vacuum-cairo: a cairo frontend to vacuumfor live Haskell data visualization
I have this problem too, but I don't understand it because librsvg-2-2.dll is in the same directory as the rest of the gtk2hs DLLs - c:/gtk2hs/0.10.0/bin on my system. Yesterday I was also having trouble with not being able to find the glib DLL but that problem has mysteriously vanished today leaving me with just the rsvg one. The problem happens with 'ghci -package svgcairo' so it's nothing specific to vacuum-cairo (unsurprisingly). This might be best asked about on the gtk2hs mailing list (https://lists.sourceforge.net/lists/listinfo/gtk2hs-users). Mark Wassell wrote: Great work. However I am have a problem running on windows - it needs librsvg: Prelude System.Vacuum.Cairo view [1] Loading package mtl-1.1.0.2 ... linking ... done. Loading package parallel-1.1.0.0 ... linking ... done. Loading package glib-0.10.0 ... linking ... done. Loading package cairo-0.10.0 ... linking ... done. Loading package svgcairo-0.10.0 ... can't load .so/.DLL for: librsvg-2-2 (addDLL: could not load DLL) Prelude System.Vacuum.Cairo Anyone know where I can get this? I have googled around and whilst there is the librsvg development site, there is no sign of a windows DLL. All I can find is some generic site which seems to provide DLLs. I don't trust it. Cheers Mark Don Stewart wrote: I am pleased to announce the release of vacuum-cairo, a Haskell library for interactive rendering and display of values on the GHC heap using Matt Morrow's vacuum library. This library takes vacuum's output, generates dot graph format from it, renders it to SVG with graphviz, and displays the resulting structure using the gtk2hs Cairo vector graphics bindings ... all at the GHCi command line. This tool is useful for examining Haskell data structures as they are represented directly in the heap. In particular, it makes sharing visible for the first time, as well as unboxed values. It should be useful for teaching Haskell, or for library authors debugging the design of their data structures. You can see pictures of the rendered display here: http://code.haskell.org/~dons/images/vacuum/intmap.png And youtube screencasts of vacuum-cairo in action: http://www.youtube.com/watch?v=oujaqo9GAmA Get it: cabal install vacuum-cairo And on Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vacuum-cair o -- Don ___ 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 === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Conditional compilation
Robin Green wrote: I am writing some code for citation support in gitit, and all the #ifdefs I'm using to do conditional compilation are a bit tiresome. Suppose you have the requirement that a certain feature of your software be disable-able at compile time, to avoid having to pull in certain dependencies (which may not be available on all platforms). Disabling a feature may entail removing certain fields from certain constructors (again, to avoid pulling in certain dependencies), and/or removing certain functions from certain modules. What is the best way to do this in Haskell? I would parameterise over the functionality (i.e. use type parameters to datatypes and HOF parameters to functions where appropriate), and instantiate the types with () or some useful type as appropriate. Some CPP would still be required but hopefully only at the top level. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Haskell Logo write-in candidate
Jon Fairbairn wrote: semi-rant warning: This whole badge/logo business seems to me to be an excellent example of Parkinson's law of triviality (choosing the colour of the bikeshed). We have a large (too large) number of variations on relatively few themes and a really sophisticated voting system, but no very clear idea of what they're for and no explanation (such as my of type Haskell above) of why the candidates are the way they are. I didn't join in much to the earlier discussion because I thought things would work out to something sensible in the end, but it doesn't look like that happened. Work out what the problem is before putting the solution up for election! I agree with this. I have voted, but as with many others I found the process very cumbersome, and I don't think it really expresses my opinions properly. I'm concerned that this process may well end up producing a outcome that's worse than the current situation but will have some aura of legitimacy because of the vote. Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Crash in GHCI - what is the correct behavior here?
I also see a segfault on Windows XP SP2 and GHC 6.10.1, very quick so I'm fairly sure it's not memory. I agree this should be a bug report. From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Luke Palmer Sent: 19 March 2009 05:00 To: Zachary Turner Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Crash in GHCI - what is the correct behavior here? On Wed, Mar 18, 2009 at 10:55 PM, Zachary Turner divisorthe...@gmail.com wrote: Regarding the black hole detection, is GHCI supposed to exit after printing loop? Or is just supposed to print loop then return to a GHCI prompt? Here's a transcript: C:\Documents and Settings\Zachghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude let f x = let p = x*x in let p = x*p in p Prelude f 7 C:\Documents and Settings\Zach Hmm, that's weird. I note that here on linux, this expression gobbles up memory like nobody's business. Maybe it's being killed for eating too much? (I dunno) Luke === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Does anybody dislike implicit params as much asI do?
Jules Bean wrote: Thomas Hartman wrote: http://blog.patch-tag.com/2009/03/09/implicitparams-are-evil-thoughts- on-adapting-gitit/ I understand there are arguments for using IPs, but after this experience, the ImplicitParams extension is a code smell for me. It's not just you. Implicit parameters are a scourge on the language. I think they have a useful place in propagating semi-global configuration information without imposing huge syntactic overhead. I think using them like in the code referred to in the URL above, where their values are frequently changed down the call stack, is dangerous. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Request: warn about language extensions that are not used
As I understand it the current scheme is that you vote for a bug by
adding yourself to the CC list.
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Peter Verswyvelen
Sent: 12 March 2009 14:27
To: Conal Elliott
Cc: haskell mailing list
Subject: Re: [Haskell-cafe] Request: warn about language extensions that
are not used
Thanks Conal.
For people interested, here's the ticket.
http://hackage.haskell.org/trac/ghc/ticket/3085
http://hackage.haskell.org/trac/ghc/ticket/3085
Martijn Van Steenbergen indirectly revealed a feature request to the
feature request feature of the feature database :-) Okay, I'll stop the
nonsense: it would be nice if the community could rate the popularity of
a feature request, which Martijn now just did by adding a comment.
On Thu, Mar 12, 2009 at 3:12 PM, Conal Elliott co...@conal.net wrote:
Thanks Peter. I'd love to have this feature also. I go back
every so often and try removing each of the extensions listed in my
LANGUAGE pragma. Didn't occur to me that the compiler could be doing it
for me. Regards, - Conal
2009/3/11 Peter Verswyvelen bugf...@gmail.com
Okay, I submitted it as a GHC feature request. Thanks
for the feedback.
On Wed, Mar 11, 2009 at 5:16 PM, Creighton Hogg
wch...@gmail.com wrote:
2009/3/11 Peter Verswyvelen bugf...@gmail.com:
When I put
{-# OPTIONS_GHC -Wall -Werror #-}
in my source file, I don't get compiler (GHC)
warnings about redundant
language extensions that I enabled.
It would be nice if the compiler gave warnings
about this, since after
refactoring, some language extensions might
not be needed anymore, and hence
should be removed since fewer language
extensions mean more stable and
portable code no?
What do you think?
So you mean something like if you put {-#
LANGUAGE
GeneralizedNewtypeDeriving #-} in a file, but
never do newtype
deriving, it would warn you?
I have no idea how hard that'd be to implement,
but that sounds kind
of cool. Useful for both refactoring and when
you've inherited old
code.
Cheers,
C
___
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
===
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Performance question
Ben Lippmeier wrote: The first thing I would do is replace your isInCircle :: (Floating a, Ord a) = (a,a) - Bool with isInCircle :: (Double, Double) - Bool Can you point me to why that matters? At the machine level, GHC treats the (Floating a, Ord a) as an extra argument to the function. This argument holds function pointers that tell it how to perform multiplication and = for the unknown type 'a'. If you use Double instead of 'a', then it's more likely to use the actual machine op. I'd recommend use of a SPECIALIZE pragma instead of rewriting the code itself: http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html (section 8.13.8) Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Hoogle and Network.Socket
Jonathan Cast wrote: On Wed, 2009-02-25 at 10:23 +, John Lato wrote: 4. Cross-platform concerns are something that responsible developers need to consider, just like localization and i18n. I.e., why *shouldn't* you think of that? Sorry, wtf? I have a *responsibility* to design software for a miserably poorly-designed God-awful platform I'd have to pay *extra* for, and even then couldn't get source to or *fix* if I found a bug? I think there's a distinction between actively trying to support a specific platform, and simply trying to work in a cross-platform way, i.e. using the appropriate cross-platform APIs and packages where possible. Other people will already have done the work of making those things work on a specific platform, and if they don't work the issue can be raised with those people rather than you. No. You don't control me, to the best of my knowledge you haven't done squat for me, and by trying to force me to develop to *that* platform you are actively attempting to harm me. *plonk* Please could you moderate your tone? The original post wasn't aimed at you personally, it just expressed a general opinion about development practices, and certainly made no mention of forcing you or anyone else to do anything. By making it personal and expressing your response in rather intemperate language, you are adding more heat than light. In addition, the original subject of this thread is Hoogle, and if we take your comments in that context (and I do realise that your comments may have been generic rather than specific to Hoogle), then you have the choice of not using it at all, in which case you are not affected at all by its design choices; but if you do use it then the author certainly has done something for you, and his feeling that people should be encouraged to use cross-platform APIs where possible should certainly be accorded some respect. Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Memoization local to a function
Dusan Kolar wrote: Nevertheless, local version does not work. Restructure your code like this: fibL m = let allfib = 0:1:[allfib!!n + allfib!!(n+1) | n - [0..]] in allfib !! m fibL = let allfib = 0:1:[allfib!!n + allfib!!(n+1) | n - [0..]] in \m - allfib !! m i.e. move the definition of the memo table outside the scope of the specific parameter you want to memoise over. Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Hac5 projects page
Wolfgang Jeltsch wrote: on http://www.haskell.org/haskellwiki/Hac5/Projects, you can list a project under Project descriptions and under Experiences. What's the difference? A project description is something you plan to work on, and an experience is something you could help other people with if they were to work on it. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Henning Thielemann wrote: On Mon, 16 Feb 2009, Louis Wasserman wrote: Overnight I had the following thought, which I think could work rather well. The most basic implementation of the idea is as follows: class MonadST s m | m - s where liftST :: ST s a - m a instance MonadST s (ST s) where ... instance MonadST s m = MonadST ... Like MonadIO, isn't it? I think it should be, except that you need to track 's' somewhere. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Well, I think a type system like Clean's that had linear/uniqueness types could fix the issue by actually checking that the state is single-threaded (and thus stop you from applying it to a forking monad). But there's a fundamental operational problem that ST makes destructive updates, so to support it as a monad transformer in general you'd need a type system that actually introduced fork operations (which linear implicit parameters used to do in GHC , but they were removed because they were quite complicated semantically and noone really used them). From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Louis Wasserman Sent: 16 February 2009 03:31 To: Dan Doel Cc: Henning Thielemann; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl Okay, I tested it out and the arrow transformer has the same problem. I realized this after I sent the last message -- the point is that at any particular point, intuitively there should be exactly one copy of a State# s for each state thread, and it should never get duplicated; allowing other monads or arrows to hold a State# s in any form allows them to hold more than one, violating that goal. I'm not entirely convinced yet that there isn't some really gorgeous type system magic to fix this issue, like the type-system magic that motivates the type of runST in the first place, but that's not an argument that such magic exists...it's certainly an interesting topic to mull. Louis Wasserman wasserman.lo...@gmail.com On Sun, Feb 15, 2009 at 9:20 PM, Dan Doel dan.d...@gmail.com wrote: On Sunday 15 February 2009 9:44:42 pm Louis Wasserman wrote: Hello all, I just uploaded stateful-mtl and pqueue-mtl 1.0.1. The ST monad transformer and array transformer have been removed -- I've convinced myself that a heap transformer backed by an ST array cannot be referentially transparent -- and the heap monad is now available only as a basic monad and not a transformer, though it still provides priority queue functionality to any of the mtl wrappers around it. stateful-mtl retains a MonadST typeclass which is implemented by ST and monad transformers around it, allowing computations in the the ST-bound heap monad to perform ST operations in its thread. Since this discussion had largely led to the conclusion that ST can only be used as a bottom-level monad, it would be pretty uncool if ST computations couldn't be performed in a monad using ST internally because the ST thread was hidden and there was no way to place ST computations 'under' the outer monad. Anyway, it's essentially just like the MonadIO typeclass, except with a functional dependency on the state type. There was a question I asked that never got answered, and I'm still curious: would an ST *arrow* transformer be valid? Arrows impose sequencing on their operations that monads don't... I'm going to test out some ideas, I think. Your proposed type: State (Kleisli []) x y = (s, x) - [(s, y)] is (roughly) isomorphic to: x - StateT s [] y = x - s - [(s, y)] The problem with an ST transformer is that the state parameter needs to be used linearly, because that's the only condition under which the optimization of mutable update is safe. ST ensures this by construction, as opposed to other languages (Clean) that have type systems that can express this kind of constraint directly. However, with STT, whether the state parameter is used linearly is a function of the wrapped monad. You'd have to give a more fleshed out version of your proposed state arrow transformer, but off the top of my head, I'm not sure it'd be any better. -- Dan == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
I don't think this can be right, because the m - s dependency will
contradict the universal quantification of s required by runST. In other
words, unwrapping the transformers will leave you with an ST computation
for a specific s, which runST will reject.
From: Louis Wasserman [mailto:wasserman.lo...@gmail.com]
Sent: 16 February 2009 16:01
To: Sittampalam, Ganesh
Cc: Dan Doel; Henning Thielemann; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Overnight I had the following thought, which I think could work rather
well. The most basic implementation of the idea is as follows:
class MonadST s m | m - s where
liftST :: ST s a - m a
instance MonadST s (ST s) where ...
instance MonadST s m = MonadST ...
newtype FooT m e = FooT (StateT Foo m e)
instance (Monad m, MonadST s m) = Monad (FooT m) where ...
instance (Monad m, MonadST s m) = MonadBar (FooT m) where
operations using an ST state
instance (Monad m, MonadST s m) = MonadST s (FooT m) where ...
The point here is that a MonadST instance guarantees that the bottom
monad is an ST -- and therefore single-threaded of necessity -- and
grants any ST-based monad transformers on top of it access to its single
state thread.
The more fully general approach to guaranteeing an underlying monad is
single-threaded would be to create a dummy state parameter version of
each single-threaded monad -- State, Writer, and Reader -- and add a
typeclass called MonadThreaded or something.
The real question with this approach would be how to go about unwrapping
ST-based monad transformers in this fashion: I'm thinking that you would
essentially perform unwrapping of the outer monad using an ST
computation which gets lifted to the next-higher monad. So, say, for
example:
newtype MonadST s m = ArrayT e m a = ArrayT {execArrayT :: StateT
(STArray s Int e) m a}
runArrayT :: (Monad m, MonadST s m) = Int - ArrayT e m a - m a
runArrayT n m = liftST (newArray_ (0, n-1)) = evalStateT (execArrayT
m)
Key points:
- A MonadST s m instance should always imply that the bottom-level monad
is of type ST s, preferably a bottom level provided when defining a
monad by stacking transformers. The fact that the bottom monad is in ST
should guarantee single-threaded, referentially transparent behavior.
- A non-transformer implementation of an ST-bound monad transformer
would simply involve setting the bottom monad to ST, rather than
Identity as for most monad transformers.
- Unwrapping an ST-bound monad transformer involves no universal
quantification on the state type. After all transformers have been
unwrapped, it should be possible to invoke runST on the final ST s a.
- Both normal transformers and ST-bound transformers should propagate
MonadST.
I'm going to go try implementing this idea in stateful-mtl now...
Louis Wasserman
wasserman.lo...@gmail.com
On Mon, Feb 16, 2009 at 3:07 AM, Sittampalam, Ganesh
ganesh.sittampa...@credit-suisse.com wrote:
Well, I think a type system like Clean's that had
linear/uniqueness types could fix the issue by actually checking that
the state is single-threaded (and thus stop you from applying it to a
forking monad). But there's a fundamental operational problem that ST
makes destructive updates, so to support it as a monad transformer in
general you'd need a type system that actually introduced fork
operations (which linear implicit parameters used to do in GHC , but
they were removed because they were quite complicated semantically and
noone really used them).
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Louis Wasserman
Sent: 16 February 2009 03:31
To: Dan Doel
Cc: Henning Thielemann; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Okay, I tested it out and the arrow transformer has the same
problem. I realized this after I sent the last message -- the point is
that at any particular point, intuitively there should be exactly one
copy of a State# s for each state thread, and it should never get
duplicated; allowing other monads or arrows to hold a State# s in any
form allows them to hold more than one, violating that goal.
I'm not entirely convinced yet that there isn't some really
gorgeous type system magic to fix this issue, like the type-system magic
that motivates the type of runST in the first place, but that's not an
argument that such magic exists...it's certainly an interesting topic to
mull.
Louis Wasserman
wasserman.lo...@gmail.com
On Sun, Feb 15, 2009 at 9:20 PM, Dan Doel dan.d...@gmail.com
wrote:
On Sunday 15 February 2009 9:44:42 pm Louis Wasserman
wrote:
Hello all,
I just uploaded stateful-mtl and pqueue
RE: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Oh, I see, every derived monad has to have an 's' in its type somewhere.
From: Louis Wasserman [mailto:wasserman.lo...@gmail.com]
Sent: 16 February 2009 16:17
To: Sittampalam, Ganesh
Cc: Dan Doel; Henning Thielemann; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
But the m - s dependency will have been removed by the time runST gets
a hold of it! It works, I just tested it.
*Control.Monad.Array.ArrayM :t runST (runArrayT 5 Nothing getContents)
runST (runArrayT 5 Nothing getContents) :: [Maybe a]
*Control.Monad.Array.ArrayM runST (runArrayT 5 Nothing getContents)
[Nothing,Nothing,Nothing,Nothing,Nothing]
There is, unfortunately, one last key point needed in this approach: the
transformer cannot implement MonadTrans, which requires that it work for
all monads. The hack I added is
class MonadSTTrans s t where
stLift :: MonadST s m = m a - t m a
instance MonadTrans t = MonadSTTrans s t where
stLift = lift
which, as a side effect, makes explicit the distinction between normal
monad transformers and ST-wrapped monad transformers.
Louis Wasserman
wasserman.lo...@gmail.com
On Mon, Feb 16, 2009 at 10:04 AM, Sittampalam, Ganesh
ganesh.sittampa...@credit-suisse.com wrote:
I don't think this can be right, because the m - s dependency
will contradict the universal quantification of s required by runST. In
other words, unwrapping the transformers will leave you with an ST
computation for a specific s, which runST will reject.
From: Louis Wasserman [mailto:wasserman.lo...@gmail.com]
Sent: 16 February 2009 16:01
To: Sittampalam, Ganesh
Cc: Dan Doel; Henning Thielemann; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Overnight I had the following thought, which I think could work
rather well. The most basic implementation of the idea is as follows:
class MonadST s m | m - s where
liftST :: ST s a - m a
instance MonadST s (ST s) where ...
instance MonadST s m = MonadST ...
newtype FooT m e = FooT (StateT Foo m e)
instance (Monad m, MonadST s m) = Monad (FooT m) where ...
instance (Monad m, MonadST s m) = MonadBar (FooT m) where
operations using an ST state
instance (Monad m, MonadST s m) = MonadST s (FooT m) where ...
The point here is that a MonadST instance guarantees that the
bottom monad is an ST -- and therefore single-threaded of necessity --
and grants any ST-based monad transformers on top of it access to its
single state thread.
The more fully general approach to guaranteeing an underlying
monad is single-threaded would be to create a dummy state parameter
version of each single-threaded monad -- State, Writer, and Reader --
and add a typeclass called MonadThreaded or something.
The real question with this approach would be how to go about
unwrapping ST-based monad transformers in this fashion: I'm thinking
that you would essentially perform unwrapping of the outer monad using
an ST computation which gets lifted to the next-higher monad. So, say,
for example:
newtype MonadST s m = ArrayT e m a = ArrayT {execArrayT ::
StateT (STArray s Int e) m a}
runArrayT :: (Monad m, MonadST s m) = Int - ArrayT e m a - m
a
runArrayT n m = liftST (newArray_ (0, n-1)) = evalStateT
(execArrayT m)
Key points:
- A MonadST s m instance should always imply that the
bottom-level monad is of type ST s, preferably a bottom level provided
when defining a monad by stacking transformers. The fact that the
bottom monad is in ST should guarantee single-threaded, referentially
transparent behavior.
- A non-transformer implementation of an ST-bound monad
transformer would simply involve setting the bottom monad to ST, rather
than Identity as for most monad transformers.
- Unwrapping an ST-bound monad transformer involves no universal
quantification on the state type. After all transformers have been
unwrapped, it should be possible to invoke runST on the final ST s a.
- Both normal transformers and ST-bound transformers should
propagate MonadST.
I'm going to go try implementing this idea in stateful-mtl
now...
Louis Wasserman
wasserman.lo...@gmail.com
On Mon, Feb 16, 2009 at 3:07 AM, Sittampalam, Ganesh
ganesh.sittampa...@credit-suisse.com wrote:
Well, I think a type system like Clean's that had
linear/uniqueness types could fix the issue by actually checking that
the state is single-threaded (and thus stop you from applying it to a
forking monad). But there's a fundamental operational problem that ST
makes
RE: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Dan Doel wrote: Someone already mentioned using Dynamic as an alternate base (for instance, use a Map of dynamics for underlying storage). Of course, the implementation of Dynamic in GHC uses unsafeCoerce, just like ST, so you may not count that. However, using GADTs, you can implement Dynamic safely for a closed universe of types. So you could create a polymorphic reference monad for whatever such universe you wished. Further, if you actually had open GADTs, you could actually add the relevant type-rep constructor for every type you declared. For instance, jhc's implementation of type classes internally uses such a GADT, so one could theoretically make a safe Dynamic, and thus a safe polymorphic reference monad. Apart from the other inconveniences, all of these solutions involve runtime overhead, which is a shame. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Stateful-mtl provides an ST monad transformer, Is this safe? e.g. does it work correctly on [], Maybe etc? If not this should be flagged very prominently in the documentation. Cheers, Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Monad explanation
My bad, I restate: a value cannot be both static and dynamic. Or an object and a morphism. Or an element and a function. Sure, you can treat a morphism as an object, but only by moving to a higher (or different) level of abstraction. That doesn't erase the difference between object and morphism. If you do erase that difference you end up with mush. getChar /looks/ like an object, but semantically it must be a morphism. But it can't be a function, since it is non-deterministic. So actually the logical contradiction comes from the nature of the beast. Another reason it's confusing to newcomers: it's typed as IO Char, which looks like a type constructor. One would expect getChar to yield a value of type IO Char, no? But it delivers a Char instead. This is way confusing. So I take type IO foo to mean type foo, after a side effect. In a sense getChar :: IO Char isn't even a true type signature. It does yield a value of type IO Char, which it also happens that you can ask the Haskell runtime to interpret by combining it with other IO values using = and invoking it from the top-level. *When interpreted in this way* it delivers a Char, but that's precisely the point at which we move to the different level of abstraction you mention above. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: 1,000 packages, so let's build a few!
Don Stewart wrote: ganesh.sittampalam: Don Stewart wrote: So, wind...@haskell.org anyone? Get the wiki going, get the set of tasks created. Isn't the Haskell Platform going to do all this? Shouldn't interested people just help out there? The platform is a set of blessed libraries and tools. The distros will still need to package that. To do that for Windows, we're still going to need a windows packaging team, along side Debian, Arch, Gentoo, Mac etc. http://www.haskell.org/haskellwiki/Haskell_Platform section 4 talks about making distributions. So what should people be trying to do? Focus on (a) general infrastructure for packaging any Haskell library/binary on Windows (etc), or on (b) the specific task of packaging the Haskell Platform? If (b) then I don't think a whole new mailing list/wiki etc is worthwhile. (a) would obviously be nicer but is no doubt a much harder problem - I guess we'd want to start with Bamse and perhaps make use of the nestedInstalls feature somehow. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: 1,000 packages, so let's build a few!
Don Stewart wrote: GHC doesn't bundle with cabal-install on any system. What is needed is not for the GHC team to be doing Windows platform packages, but for the Windows Haskell devs to build their own system, as happens on all the Unices. Take GHC's release, wrap it up with native installers, throw in useful libraries and executables like cabal. Done. It's not the GHC compiler team's job to build distro-specific bundles. So, wind...@haskell.org anyone? Get the wiki going, get the set of tasks created. Isn't the Haskell Platform going to do all this? Shouldn't interested people just help out there? Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: list choices
Malcolm Wallace wrote: As for Reply-to: munging - I agree that _changing_ an existing header would be bad, but would be very happy if mailing lists were to _introduce_ one on messages where none already existed. That would IMO be the worst of both worlds, as people might use Reply-To for reasons entirely unconnected with the mailing list. So you'd end up with a confusing situation where the default target of replies varied depending on some completely irrelevant factor. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Employment
Andrew Coppin wrote: Andrew Wagner wrote: http://www.haskell.org/haskellwiki/Haskell_in_industry could be of interest to you Hmm, interesting... So lots happening in Portland, Oregon. Lots in Cambridge, MA. A few things in Europe. And nothing at all in the UK... We (Credit Suisse) have Haskell developers in both London and NY, although the page only listed NY (I've now corrected it). Two other companies without locations listed - Barclays Capital and Standard Chartered - also have at least some Haskell development in the UK, and I think that's where Amgen's development is based too. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: I have replied on his blog, but I'll repeat the gist of it here. Why is there a fear of using existing terminology that is exact? Why do people want to invent new words when there are already existing ones with the exact meaning that you want? If I see Monoid I know what it is, if I didn't know I could just look on Wikipedia. If I see Appendable I can guess what it might be, but exactly what does it mean? I would suggest that having to look things up slows people down and might distract them from learning other, perhaps more useful, things about the language. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: a name that anyone can figure out with just a little effort. I think the problem is that all these pieces of little effort soon mount up. It's not just the cost of looking it up, but also of remembering it the next time and so on. It's fine when you only encounter the occasional unfamiliar term, but a barrage of them all at once can be quite disorienting. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: I think the documentation should be reasonably newbie-friendly too. But that doesn't mean we should call Monoid Appendable. Appendable is just misleading, since Monoid is more general than appending. Then why does it have a member named 'mappend'? :-) Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: Most people don't understand pure functional programming either. Does that mean we should introduce unrestricted side effects in Haskell? No, just that we should seek to minimise the new stuff they have to get to grips with. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] The problem with Monads...
Jonathan Cast wrote: On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira Pinto wrote: Inspired by the paper Functional Programming with Overloading and Higher-Order Polymorphism, Mark P Jones (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html) Advanced School of Functional Programming, 1995. SO WHAT? So have you read Jones' paper? Or do you have a *concrete* explanation of how it differs from your desired `guided tour'? To give a specific example, a few weeks ago I wanted an explanation of the 'pass' function and couldn't find it in that paper. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] mailing list choices?
I would call Yahoo and Google groups a major step backwards from mailman. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conal Elliott Sent: 08 September 2008 11:34 To: Haskell Café Subject: [Haskell-cafe] mailing list choices? I want to set up some kind of mailing list for reactive (which I plan to release soon). The most obvious thing is to set up a mailman-based list on haskell.org, but I wonder -- do people really want to keep using mailman technology? Or something more modern like Yahoo or Google groups. I use my email reader also with Yahoo Google groups, so my day-to-day experience is the same as with mailman-based lists. For less regular operations like searching archives, I prefer the experience on Yahoo Google group. And I like some of the other modern features, like personal profiles and polls. I've been wondering if haskellers really like mailman or are just used to it. Maybe people make new mailman lists simply because others did it before them. Any thoughts/preferences? Thanks, - Conal == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] mailing list choices?
The Yahoo mailing list server is notoriously unreliable and randomly drops mails and/or drops people from lists because their email server was temporarily refusing mails (4xx SMTP responses not 5xx). I also find the Yahoo groups web interface absolutely awful; mailman's list archives aren't great, but are ok for casual browsing, and you can download the entire archives and load them up locally if you need to. A quick look around Google groups suggests that my initial assumption that it'd be as bad as Yahoo groups is probably unfounded. But if I hadn't already given in and created a Google account for other things, I'd be unhappy about doing so just for your list, given the way it tracks your web browsing in ways that I don't entirely understand while you are logged into it. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conal Elliott Sent: 08 September 2008 12:52 To: Sittampalam, Ganesh Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] mailing list choices? In what ways? 2008/9/8 Sittampalam, Ganesh [EMAIL PROTECTED] I would call Yahoo and Google groups a major step backwards from mailman. == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] Top Level -
Ashley Yakeley wrote: Sittampalam, Ganesh wrote: Oh dear. To fix this, I suppose the RTS would have to be able to keep track of all static initialisers. But it shouldn't otherwise affect program optimisation. What would the RTS actually do? I don't know enough about the RTS to say. I imagine initialisers would have to be marked in object files, so the RTS could link them separately when dynamically loading. The RTS would also keep a list of initialisers in the main program. Sounds plausible, although dynamic relocations do slow down linking. Unloading is another interesting problem. Are we allowed to re-run - if the module that contained it is unloaded and then reloaded? I'm not quite sure what the conditions for allowing a module to be unloaded in general should be, though. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] Top Level -
Ashley Yakeley wrote: I really don't know enough about the RTS to know. The alternative would be to keep all initialised values when the module is unloaded. I'm guessing this is more feasible. Easier, but a guaranteed memory leak. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] Top Level -
Ashley Yakeley wrote: Sittampalam, Ganesh wrote: In compiled code module boundaries don't necessarily exist. So how do you relink the loaded code so that it points to the unique copy of the module? hs-plugins loads modules as single .o files, I believe. Yes, but (a) the loading program doesn't and (b) that's an implementation choice, not a necessity. Two RTSs? Are you quite sure? How would GC work? I talked to Don about this and you're right, that doesn't happen. However he also confirmed that it does load modules a second time if they are in the main program as well as the plugin, and it would be difficult to merge the static and dynamic versions of the module. Cheers, Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: [Haskell] Top Level -
Ashley Yakeley wrote: Ganesh Sittampalam wrote: In any case, what I'm trying to establish below is that it should be a safety property of - that the entire module (or perhaps mutually recursive groups of them?) can be duplicated safely - with a new name, or as if with a new name - and references to it randomly rewritten to the duplicate, as long as the result still type checks. That's not acceptable. This would cause Unique to break, as its MVar would be created twice. It would also mean that individual Unique and IOWitness values created by - would have different values depending on which bit of code was referencing them. It would render the extension useless as far as I can see. The result wouldn't typecheck if two Unique values that now pointed to the two different modules were compared. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: [Haskell] Top Level -
Dave Menendez wrote: The Haskell 98 report includes NOINLINE, but also states that environments are not required to respect it. So hs-plugins wouldn't necessarily be at fault if it didn't support Data.Unique. Also, the definition of NOINLINE in the report doesn't preclude copying both the MVar *and* its use sites, which is what I am proposing should be considered generally safe. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] Top Level -
Ashley Yakeley wrote: I don't understand. If the dynamic loader were to load the same package name and version, and it duplicated the MVar, then Unique values would have the same type and could be compared. I am suggesting that this duplication process, whether conducted by the dynamic loader or something else, should behave as if they did not have the same package name or version. This is certainly a valid transformation for Data.Unique, I am simply saying that it should be a valid transformation on any module. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: [Haskell] Top Level -
Ashley Yakeley wrote: To solve this the hs-plugins dynamic loader maintains state storing a list of what modules and packages have been loaded already. If load is called on a module that is already loaded, or dependencies are attempted to load, that have already been loaded, the dynamic loader ignores these extra dependencies. This makes it quite easy to write an application that will allows an arbitrary number of plugins to be loaded. http://www.cse.unsw.edu.au/~dons/hs-plugins/hs-plugins-Z-H-6.html My recollection from using it a while ago is that if a module is used in the main program it will still be loaded once more in the plugin loader. This is because the plugin loader is basically an embedded copy of ghci without much knowledge of the host program's RTS. Cheers, Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] Top Level -
Ashley Yakeley wrote: Sittampalam, Ganesh wrote: I am suggesting that this duplication process, whether conducted by the dynamic loader or something else, should behave as if they did not have the same package name or version. This is certainly a valid transformation for Data.Unique, I am simply saying that it should be a valid transformation on any module. So if I dynamically load module M that uses base, I will in fact get a completely new and incompatible version of Maybe, IO, [], Bool, Char etc. in all the type-signatures of M? I think it treats them as compatible, using the fact that Data.Typeable returns the same type reps (which was why I initially mentioned Data.Typeable in this thread). This is fine for normal modules. There's a bit of description in the Dynamic Typing section of http://www.cse.unsw.edu.au/~dons/hs-plugins/hs-plugins-Z-H-5.html#node_s ec_9 It's clearly the wrong thing to do for Data.Unique and any anything else that might use -; but if there are no such types in the interface of the plugin, then it won't matter. I can't see how to make it safe to pass Data.Unique etc across a plugin interface without severely restricting the possible implementation strategies for a plugin library and its host. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] Top Level -
Ashley Yakeley wrote: I think it's bad design for a dynamic loader to load a module more than once anyway. In compiled code module boundaries don't necessarily exist. So how do you relink the loaded code so that it points to the unique copy of the module? It's a waste of memory, for a start. We already know that hs-plugins won't for modules it already loaded itself (apparently it crashes the RTS), and I suspect it doesn't at all. It crashes the RTS of the plugins loader, which is based on ghci, which is built around loading modules independently. I believe there's a separate RTS running at the top level of the program which has no knowledge of the plugin loader. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: [Haskell] Top Level -
Yitzhak Gale wrote: Right. It would not be a bug in hs-plugins. That is the most urgent problem right now. [...] For the short term - can we *please* get an ONLYONCE pragma that has the correct semantics? So the purpose of this pragma would solely be so that you can declare hs-plugins buggy for not respecting it? Or do you have some way to fix hs-plugins so that it does do so? (Assuming that my belief about how hs-plugins works is correct, of course) Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: [Haskell] Top Level -
(apologies for misspelling your name when quoting you last time) Yitzchak Gale wrote: For the short term - can we *please* get an ONLYONCE pragma that has the correct semantics? Until a permanent solution is implemented and deployed in the compilers (if ever), can we please have a pragma that allows the current hack to really work? How do you propose that this pragma would be implemented? Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: [Haskell] Top Level -
Yitzchak Gale wrote Other applications and libraries that support the pragma - such as other compilers, and hs-plugins - would be required to respect the guarantee, and bugs could be filed against them if they don't. If hs-plugins were loading object code, how would it even know of the existence of the pragma? Given such knowledge, how would it implement it? Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Top Level -
John Meacham wrote: On Fri, Aug 29, 2008 at 04:33:50PM -0700, Dan Weston wrote: C++ faced this very issue by saying that with global data, uniqueness of initialization is guaranteed but order of evaluation is not. Assuming that the global data are merely thunk wrappers over some common data source, this means that at minimum, there can be no data dependencies between plugins where the order of evaluation matters. Fortunately, we can do a whole lot better with haskell, the type system guarentees that order of evaluation is irrelevant :) no need to specify anything about implementations. Can't you write two recursive modules with - that depend on each other, so that there's no valid initialisation order? Contrived example follows: module Module1 where glob1 :: IORef Int glob1 - mod2 = newIORef mod1 :: IO Int mod1 = readIORef glob1 module Module2 where glob2 :: IORef Int glob2 - mod1 = newIORef mod2 :: IO Int mod2 = readIORef glob2 It might need some strictness annotations to actually cause non-termination at initialisation rather than just make the results of mod1 and mod2 be _|_. I think those initialisers do satisfy ACIO, though I'm not certain - from the point of view of dataflow, you can certainly remove them both together if the rest of the code doesn't use mod1 or mod2, and likewise they commute with any other IO operations. But on the other hand there's no way to actually put them in an order that doesn't cause non-termination. Cheers, Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Top Level -
Contrived example follows: module Module1 (mod1) where import Module2 glob1 :: IORef Int glob1 - mod2 = newIORef mod1 :: IO Int mod1 = readIORef glob1 module Module2 (mod2) where import Module1 glob2 :: IORef Int glob2 - mod1 = newIORef mod2 :: IO Int mod2 = readIORef glob2 This is illegal because you're only allowed to use ACIO in top level - bindings and readIORef isn't (and clearly could not be) ACIO. (made a couple of changes to quoted example; added import statements and explicit export lists) Even though I never call writeIORef on glob1 or glob2, and can change the example as above so we don't export them, so it's impossible to ever do so? As an alternative, consider module Module1 (mod1) where import Module2 glob1 :: Int glob1 - return $! mod2 mod1 :: Int mod1 = glob1 module Module2 (mod2) where import Module1 glob2 :: Int glob2 - return $! mod1 mod2 :: Int mod2 = glob2 Even more artificial, of course. Arguably both of these cases are not ACIO simply because of the non-termination effects, but it's not obvious to me how you tell just by looking at either one's code together with the declared API of the other. Is anything strict automatically forbidden by ACIO? Cheers, Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Top Level -
David Roundy wrote: On Tue, Sep 02, 2008 at 10:10:31AM +0100, Sittampalam, Ganesh wrote: Arguably both of these cases are not ACIO simply because of the non-termination effects, but it's not obvious to me how you tell just by looking at either one's code together with the declared API of the other. Is anything strict automatically forbidden by ACIO? Isn't this just a pure infinite loop? Why is it a problem that ACIO allows you the flexibility that's present in any pure code? ACIO promises that you can remove anything unused without changing the behaviour. The same problem doesn't arise in pure code because you can't write top-level strict bindings. The GHC extension to have strict bindings (bang patterns) is explicitly disallowed at top-level: http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.ht ml Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Mutually recursive modules and google protocol-buffers
Hi, module A(A) where data A deriving Show I think you should use instance Show A rather than deriving Show. All the boot file needs to do is say that the instance exists, not explain how it is constructed. Cheers, Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] More on performance
I wonder what can be said about stable optimizations which are insensitive to their environments in some sense. http://citeseer.ist.psu.edu/veldhuizen02guaranteed.html Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] looking for examples of non-full Functional Dependencies
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 == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] looking for examples of non-full Functional Dependencies
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 == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] type families and type signatures
OK, thanks. I think I'm finally understanding :-)
Cheers,
Ganesh
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
==
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] type families and type signatures
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 == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
