Re: [Haskell-cafe] Data.IntMap union complexity
Folding insert might still be a win if one of the maps is very much smaller than the other, but since size is O(n) for Data.IntMap, there's no way to find out if that's the case. - chris On Fri, Feb 24, 2012 at 4:48 AM, wren ng thornton w...@freegeek.org wrote: When the two maps are of vastly different sizes, O(min(m,n)) is a more intuitive way to think about it. Since you only have to look at the places where the spines clash, that will be on the order of the smaller map. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [haskell-cafe] Some reflections on Haskell
Since people are mentioning how great the Haskell type system is for refactoring, here's one of those wow, that's really great experiences I just had hacking on some Java code in Eclipse. I wanted to remove duplicate code, so I selected one of the duplications and used Refactor-Extract method. To my astonishment and delight, Eclipse also automatically replaced all duplications with a call to the new method. It's things like that which make me really like advanced IDEs and sometimes choose a lesser language with better IDE support (the code in question was actually backported from Scala, because the pains of a Java+Scala project far outweighed the gains). It does not matter that much when writing new small to mid-size programs, but when working in a larger codebase, or inside frameworks (Yesod might be an example in the Haskell world), I'll take any help I can get, even if it's only autocomplete and suggestions based on type. And the larger the ecosystem gets, the more important that will become. Apart from the IDE matter, I'd also would like to see some sort of rating system on Hackage, or at least some support to choose between the available packages. Indicators might be popularity, actively maintained, age, ... Many participants in Johan Tibell's survey seemed to want something along these lines. Just my 2 cents, Chris On Tue, Feb 14, 2012 at 8:05 PM, Alejandro Serrano Mena trup...@gmail.comwrote: Hi, 2012/2/14 Doug McIlroy d...@cs.dartmouth.edu Kevin Jardine notices the full Haskell ecosystem ... is huge, and laments the absence of a sophisticated IDE to help manage it. Being a small-code type, I don't personally enjoy IDE's, which are undeniably useful in big projects, at the cost of a whole lot more to learn about programmering in addition to programming. There are now several IDEs (or development environments) that you may use for Haskell programming: I personally work on EclipseFP (so the environment is quite similar to Java), but there is also Leksah. I've seen people making incredible things using Emacs and the Haskell modes, so I think there is now quite nice support for Haskell programming. Apart from that, Haskell Platform and cabal makes it easy to use Haskell (at least as easy as PHP if you are using any of the LAMP packages in Windows, or Perl or Python). (Disclaimer: I'm currently one of the developers of EclipseFP) Nevertheless, I share Jardine's concern about the central problem. It is hard to find one's way in this ecosystem. It needn't be, as Java illustrates. To my mind Java's great contribution to the world is its library index--light years ahead of typical documentation one finds at haskell.org, which lacks the guiding hand of a flesh-and-blood librarian. In this matter, it seems, industrial curation can achieve clarity more easily than open source. I disagree with that. For me, one of the best things about Haskell community is Hackage, where I can actually find and browse package documentation in a centralized way. In these days, Maven or Ivy (for automatically resolving and getting Java dependencies) are seen as great tools for Java ecosystem, and in Haskell we have that, with an even easier way to add packages and new versions to the index! Indeed, I find that Hackage enables a workflow not available in any other programming language: say you don't find a feature in Hackage libraries. Well, you can be pretty sure that no one has programmed a library for your task (opposed to Java or .NET, where it may be a commercial library, and be found somewhere random in the internet). Once you program it, you can upload it to Hackage and share easily with the rest of the community. Finally, even though we may argue about the point that core Java libraries have better documentation that core Haskell libraries (although libraries such as container even give complexity bounds to their operations), I find better Haskell documentation for other different resources: see the free-available Learn you a Haskell, Real World Haskell (just to name some tutorials), the Snap and Yesod documentation (as opposed to the documentation of other web frameworks in the wild)... ___ 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
Re: [Haskell-cafe] Good Java book? (not off-topic)
How about recommending a Scala book instead of Java? That would teach a functional mindset, and on stepping back to Java, they'd just have a different syntax for types, and some missing stuff. On the Java side, I own A Little Java, a Few Patterns by Friedmann and Felleisen. This would certainly not make them impervious to anything functional, but I don't think it serves as a general introduction to Java. Maybe it would be suitable in addition to another book. I can second the recommendation of Effective Java. - Chris On Fri, Feb 17, 2012 at 12:19 AM, Ivan Perez ivanperezdoming...@gmail.comwrote: Hi, cafe, I find myself in the unusual position of having to recommend a few books on Java to people who want to use it professionally. As the people demanding this live in Burundi, I can't really say Learn Haskell. Odds are they won't find a job there if they don't use mainstream languages. Is there any book on Java that approaches the language in a way that doesn't make programmers impervious to FP and Haskell? Not meaning to insult anybody here, I too learned Java before Haskell. But I also think it made learning Haskell much more difficult. Cheers, Ivan. ___ 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
Re: [Haskell-cafe] The State of Testing?
On Thu, Feb 9, 2012 at 6:57 PM, Thomas Tuegel ttue...@gmail.com wrote: You need Cabal 1.12 for '--enable-library-coverage'. The only place it's documented is in 'cabal configure --help' (a major oversight on my part). The online docs for Cabal are only from version 1.10 anyway, so that wouldn't have helped. I'm sorry for your struggles getting the detailed type to work. It's a known issue: the detailed test interface is intentionally disabled in all the released versions because it's going to change. That's why none of the test libraries support it yet and why you weren't able to get it to work. No problem - I was just wondering where my error lay. The stdio tests do the trick for the time being. - Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The State of Testing?
Hello Thomas, On Wed, Feb 8, 2012 at 4:03 AM, Thomas Tuegel ttue...@gmail.com wrote: First, as author of the test suite code, let me apologize for the terrible documentation. This is absolutely NOT how coverage reports are supposed to work. If you configure with '--enable-tests --enable-library-coverage', Cabal will take care of _everything_ else for you, including excluding the test module from the coverage report. You should not have to put any flag gymnastics in your .cabal file. I get only cabal: unrecognized option `--enable-library-coverage' when doing that. Which cabal version do I need? Can you point me to any docs about this? I'm still using test type exitcode-stdio-1.0, because I could not get detailed-1.0 to work. TIA, Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] where to put general-purpose utility functions
One thing I found useful when looking if a function already exists under a different name is to use Hayoo to search for the type, i.e.: http://holumbus.fh-wedel.de/hayoo/hayoo.html#0:(a%20-%3E%20Bool)%20-%3E%20%5Ba%5D%20-%3E%20(%5Ba%5D%2C%5Ba%5D) - Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] where to put general-purpose utility functions
On Sat, Jan 21, 2012 at 11:08 PM, Christoph Breitkopf chbreitk...@googlemail.com wrote: One thing I found useful when looking if a function already exists under a different name is to use Hayoo to search for the type, i.e.: Uh - please ignore the bogus link - I had blindly assumed that it would show my search results. Just use http://holumbus.fh-wedel.de/hayoo/hayoo.html to search for (a - Bool) - [a] - ([a],[a]), for eaxample, and it will find break, span, partiion, etc. - Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple type-class experiment turns out not so simple...
On Sun, Jan 8, 2012 at 9:25 PM, Brent Yorgey byor...@seas.upenn.edu wrote: On Fri, Jan 06, 2012 at 10:51:58AM +, Steve Horne wrote: If I specify both extensions (-XMultiParamTypeClasses and -XFlexibleInstances) it seems to work, but needing two language extensions is a pretty strong hint that I'm doing it the wrong way. Not necessarily. These two extensions in particular (and especially the second) are quite uncontroversial. I really don't know much about the subject, but http://hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClassesDilemma does not sound uncontroversial to me. That's why I avoided them so far. - Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Motivation for having indexed access in Data.Map?
Hello, I wonder why Data.Map provides the indexed access functions: http://hackage.haskell.org/packages/archive/containers/latest/doc/html/Data-Map.html#g:21 These functions seem rather out-of-place to me in the map api. The only use case I could think of so far would be to find the median, or in general n-th smallest key, but that does not seem sufficient reason (also, I think there are faster methods for that). Anything else? Regards, Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (no subject)
Hello, I'm trying to figure out how to handle versioning of my IntervalMap package. I've just read the package versioning policy: http://www.haskell.org/haskellwiki/Package_versioning_policy I don't quite understand all the recommendations in the above document, though: a) You are not allowed to remove or change the types of existing stuff. Ok. b) You are allowed to add new functions. But that can break compilation because of name conflicts. Seems to be allowed on the grounds that this is easy to fix in the client code. c) You are not allowed to add new instances. I don't get this - how is this any worse than b)? I do understand that it is not generally possible to prevent breaking code - for example if the client code depends on buggy behavior that gets fixed in a minor version update. That seems unavoidable - after all, bugfixes are _the_ reason for minor updates. Regards, Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package Versioning Policy
Forgot the header, sorry. On Thu, Jan 5, 2012 at 5:54 PM, Christoph Breitkopf chbreitk...@googlemail.com wrote: Hello, I'm trying to figure out how to handle versioning of my IntervalMap package. I've just read the package versioning policy: http://www.haskell.org/haskellwiki/Package_versioning_policy I don't quite understand all the recommendations in the above document, though: a) You are not allowed to remove or change the types of existing stuff. Ok. b) You are allowed to add new functions. But that can break compilation because of name conflicts. Seems to be allowed on the grounds that this is easy to fix in the client code. c) You are not allowed to add new instances. I don't get this - how is this any worse than b)? I do understand that it is not generally possible to prevent breaking code - for example if the client code depends on buggy behavior that gets fixed in a minor version update. That seems unavoidable - after all, bugfixes are _the_ reason for minor updates. Regards, Chris ___ 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
Re: [Haskell-cafe] Package Versioning Policy
HI, On Thu, Jan 5, 2012 at 6:15 PM, Johan Tibell johan.tib...@gmail.com wrote: c) You are not allowed to add new instances. I don't get this - how is this any worse than b)? You cannot prevent the import of new instances. When you import a module you get all its instances. This means that explicit import lists can't protect you. What I don't get is how a new instance may break existing code. Any example? Bugfixes you be in bugfix releases (i.e. bumps to the 4th version component.) I though I would do without the patchlevel component at first. If I understand correctly, you would recommend: - Mayor Version changes: as described in the guidelines: changed interface, new instances - Minor version change: when I just add functions - Patchlevel change: for bugfixes, performance fixes, documentation changes Thanks, Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package Versioning Policy
Am 05.01.2012 20:08 schrieb Johan Tibell johan.tib...@gmail.com: - Mayor Version changes: as described in the guidelines: changed interface, new instances - Minor version change: when I just add functions - Patchlevel change: for bugfixes, performance fixes, documentation changes Yes. This is in fact what the PVP specifies IIRC. It says that anything beyond the minor version is optional. Also, in the cabal files I looked at, most seemed to use the major version for dependencies, e.g. package = 0.5 0.6. So I wondered if I misunderstood, or if the maintainers of those packages just live with the risk of minor breakage once in a while. But anyway, I'm not trying to be overly pedantic - I'm just new to the Haskell community, so I ask a lot of questions ;-) Thanks again, Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package Versioning Policy
Am 05.01.2012 19:14 schrieb Brandon Allbery allber...@gmail.com: What I don't get is how a new instance may break existing code. Any example? It's not unusual for people to define their own instances for things; if a new release of the library then adds its own version of those instances, even if they are identical, then those people's code will break. Google orphan instances to see both general and concrete discussion of the problem. I'm blanking on recent practical examples, but there have been some. I see. No examples needed - I just had to do that myself in benchmark code, because FingerTree does not instance NFData. When it does, my code will break. Got that. Thanks, Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Module name space question
Hi, I recently asked about what interfaces to implement for a new data type. Following the rule that the last 10% of work take the second 90% of time, some other questions have come up. If anyone wants to look at the code in question: http://www.chr-breitkopf.de/comp/IntervalMap Some time ago, I was looking for a data structure to search in sets of possibly overlapping intervals, and found only Data.SegmentTree, which did not fit my needs (nice term for I did not understand the type signatures). So I started to roll my own IntervalMap implementation. But yesterday I used Hayoo instead of Hoogle for the first time, and found Data.IntervalMap.FingerTree. This has an Interface that I _do_ understand, and, while slightly different from my aims (depite the name, it seems more like a multi-map and does not offer lookup of specific keys), it raises some tasks/questions: Tasks: Benchmark against my implementation, and maybe scrap own if it performs worse. And questions: 1. Why doesn't Hoogle find this? 2. Module name space pollution I would have been so bold to name my module Data.IntervalMap. Now, since even Ross Patterson uses a submodule name instead, what is the accepted practice? If I decide to release my class after all, what should be the name? Data.IntervalMap.RedBlackTree ? Or even Data.IntervalMap.MyDomaindNameOrSomething. An I even have a module Data.IntervalMap.Interval, so if Ross had decided to put his Interval type into a separate module, even FingerTree vs RedBlackTree would not have prevented a name clash. 3. Are there more wothwile operations on this data structure? Data.IntervalMap.FingerTree has 'dominators', which I missed. A function to extract the interval with the largest endpoint might be useful, too. Any more ideas? TIA, Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Recommended class instances for container type
It's just a variant of Data.Map that takes intervals as keys and offers an efficient stabbing query. I'm reasonably optimistic on the performance front. Will probably release a 0.1 soon. Thanks again for all opinions, Chris Am 08.12.2011 20:41 schrieb Johan Tibell johan.tib...@gmail.com: On Thu, Dec 8, 2011 at 8:12 AM, Christoph Breitkopf chbreitk...@googlemail.com wrote: Hello, I'm in the process of implementing a container data type, and wonder what class instances are generally considered necessary. E.g. is it ok to start out with a Show that's adequate for debugging, or is it a 'must' to include instances of everything possible (Eq, Ord if possible, Read, Show, Functor, ...). Start out with Show and spend your time making sure that you're container type performs well (unless you're doing this as an exercise of course). A featureful API for something that's as slow as linked lists isn't very useful. ;) -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Recommended class instances for container type
Hello, I'm in the process of implementing a container data type, and wonder what class instances are generally considered necessary. E.g. is it ok to start out with a Show that's adequate for debugging, or is it a 'must' to include instances of everything possible (Eq, Ord if possible, Read, Show, Functor, ...). And what about the more experimental things? Say, DeepSeq, Typeable, Data? I'd like to keep this simple at start, and I've admittedly not followed recent developments in Haskell-land (recent meaning the last 10 years or so. I _do_ know about hierachical modules ;-) ). OTOH, if not having such instances makes it impossible to do things the modern way, I'd probably take the time to implement (and maybe understand) them. Thanks, Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Recommended class instances for container type
That's what I did, and the reason for my question. 'Cause I was scared off by looking at Data.Map (CPP, lots of language extensions). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Recommended class instances for container type
Hello Bryan, On Thu, Dec 8, 2011 at 6:03 PM, Bryan O'Sullivan b...@serpentine.com wrote: And what about the more experimental things? Say, DeepSeq, Typeable, Data? None of those are experimental. They're all frequently used in production code. DeepSeq is far more important than the other two, though. For Typeable and Data, you could copy the approach taken by Data.Map and be fine. Well, including a some file via CPP did look experimental enough to me. I'd like to stay away from GHC-only code, if possible. At some point, if you want your container class to be useful to others, you'll want to implement Foldable and Traversable. Being useful to others would be the whole point in releasing it at all :-) Thanks for your explanations - I take this as: Yes, the Haskell community is really using all this stuff in production code, so better offer it, or your library might not be that usable. I'll try to be complete, then. - Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage down!
Yep, same here. - Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
