Re: [Haskell-cafe] Data.IArray rant
On 3 September 2011 12:53, Evan Laforge wrote: > >> To an extent, I wonder how much of this has been that arrays were >> considered to be bad in Haskell, so no-one used them and no-one >> bothered to try and improve the API much (and instead went and created >> Vector, etc.). > > Right, so we have arrays with nicer APIs, it's just that IArray has > been kind of left behind. I don't think arrays are bad in haskell, if > that were true all those array libraries wouldn't be so popular! They > might not be quite the go-to type as in other languages, but they > still have their uses. By "bad" I was referring to the API, not the data structure itself. >> Any particular reason you used Data.Graph rather than fgl, etc.? > > Well... it's built-in... I needed something simple... so I just hit > the ghc stdlib doc and searched for "graph". Is this another "left > behind" module? And if so... well, maybe it's in the same situation > as IArray. Pretty much; most people don't even think much of FGL. I _really_ should get around to expanding and improving Edward Kmett's graph library so that it covers more of a variety of common graph types and operations, but I've been busy on specialised graph libraries that I need lately. > Right, it's hard to dislike the underlying data structure, arrays are > about as simple as you can get :) My guess was the same as yours, > i.e. that it's been sort of neglected but it's a bootlib and H98 so > nothing can happen to it quickly. > > I can't realistically suggest a course of action here, other than > "gosh someone should update these modules" to which everyone is likely > to say "yes, it would be nice if you did that" :) Or maybe in 10 > years vector will be mature and standard and the old Array stuff can > be deprecated and removed. So that's why this was more of a little > rant than actual constructive comment. Maybe as a stop-gap some more useful/constructive examples/documentation on how to use Data.Array.IArray compared to vector, etc.? That said, apart from Data.Graph I don't know of many uses of it nowadays, as everyone seems to have migrated to vector for 1-Dimensional and hmatrix/repa for multi-dimensional. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.IArray rant
> I've used this a fair amount: e.g. 2D grids going from (-n,-n) to > (n,n). This is one of the things I liked about Haskell arrays, in > that you _weren't_ limited to the [0,n-1] bounds found in C-based > languages (and that annoyed me to no end when I was using them). Even And to be honest, it's fairly easy to wrap the array functions to specialize them for (0..n-1). It just took me a while to figure out that I would have to make my own array module to stop getting those off-by-one errors. >> Meanwhile, they lack basic features like concatenation. > > I obviously don't know what you're doing with arrays, but this sounds > a bit like using the wrong datatype for the job: if you're > concatenating arrays, wouldn't you have to explicitly create or extend > one of those arrays to get the contiguous memory (unless you're using > a DiffArray)? Yes, that's also the case for vector, or bytestring, or any of the other array libraries. Concatenating arrays is not a crazy thing to do if it's uncommon and the arrays are not large. You have to copy them in imperative languages too, so it's hardly unique to haskell. Admittedly, I could have used an IntMap but it's a small dense array that's very infrequently changed, and I do mostly iterating forwards and backwards and a plain array seemed simpler than an IntMap with the condition that the keys should be consecutive. > To an extent, I wonder how much of this has been that arrays were > considered to be bad in Haskell, so no-one used them and no-one > bothered to try and improve the API much (and instead went and created > Vector, etc.). Right, so we have arrays with nicer APIs, it's just that IArray has been kind of left behind. I don't think arrays are bad in haskell, if that were true all those array libraries wouldn't be so popular! They might not be quite the go-to type as in other languages, but they still have their uses. > Any particular reason you used Data.Graph rather than fgl, etc.? Well... it's built-in... I needed something simple... so I just hit the ghc stdlib doc and searched for "graph". Is this another "left behind" module? And if so... well, maybe it's in the same situation as IArray. > I see there are two possible sources of your "problems" here: > > 1. The underlying data structure (index types and bounds, etc.) > 2. The API > > You mainly seem to have an issue with the API itself. My guess is > that the API for array hasn't changed much because it was already > there and a boot library (so incremental changes, etc.) whereas when > vector, etc. was being written the opportunity was being taken to > create an API better suited for the task, taking into account people's > usage of array. Right, it's hard to dislike the underlying data structure, arrays are about as simple as you can get :) My guess was the same as yours, i.e. that it's been sort of neglected but it's a bootlib and H98 so nothing can happen to it quickly. I can't realistically suggest a course of action here, other than "gosh someone should update these modules" to which everyone is likely to say "yes, it would be nice if you did that" :) Or maybe in 10 years vector will be mature and standard and the old Array stuff can be deprecated and removed. So that's why this was more of a little rant than actual constructive comment. Maybe at the least I could submit a patch to the IArray haddock saying "there are other array interfaces out there on hackage if you're looking for the 'default array' and this one isn't doing it for you". Maybe the same with Data.Graph and fgl, if that's so much nicer. But then, you know, it feels strange for a stdlib to come with such disclaimers :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.IArray rant
On 3 September 2011 11:38, Evan Laforge wrote: > I never liked Data.IArray. Recently I had to deal with it again and > it kind of touched off a bit of a rant: > > Array bounds are an inclusive range, which runs counter to almost all > other uses of ranges, and for good reason. Length of an array is > (high - low + 1). If you want to convert a list to an array it's > 'IArray.listArray (0, length xs - 1) xs'. And if you forget to > subtract one or add one it's likely to be a runtime crash. Off-by-one > errors and runtime crashes... I've gotten accustomed to not having > those in haskell! > > The vast majority of data types have their own set of monomorphic > fuctions, and yet array all of the sudden wants to be an interface. > That's nice and all, but who actually uses that interface? I recall > there used to be a DiffArray and some other variants, but they were > decried as being slow and appear to be gone now. > > So it appears that there's a complexity price paid to support > different array types under the same interface, namely giant class > contexts that can't be abstracted away and dependence on MPTCs... and > appears to be unused. And then another price paid to support > arbitrary indices... which I at least have never used. Maybe there is > a field where arrays with strange index ranges like 5--20 are useful, > but I always just want 0--length-1. I've used this a fair amount: e.g. 2D grids going from (-n,-n) to (n,n). This is one of the things I liked about Haskell arrays, in that you _weren't_ limited to the [0,n-1] bounds found in C-based languages (and that annoyed me to no end when I was using them). Even _Fortran_ had arrays where you can specify the index bounds you want to use rather than being forced to translate from the bounds that make sense to your code to the bounds imposed by the array implementation. Admittedly, I don't use arrays much anymore, but that's because I tend to play with graphs nowadays... > Meanwhile, they lack basic features like concatenation. I obviously don't know what you're doing with arrays, but this sounds a bit like using the wrong datatype for the job: if you're concatenating arrays, wouldn't you have to explicitly create or extend one of those arrays to get the contiguous memory (unless you're using a DiffArray)? > No Monoid instance. In fact, hardly any useful instances. Maybe someone needs to suggest + implement such instances then. > The result is that my first contact with haskell > arrays left me with the impression that they were complicated, hard to > use, and designed for someone with different priorities than me. Of > course, Data.Vector didn't exist back then, but if someone were new to > haskell now I would recommend they skip Data.IArray and head straight > for vector. To an extent, I wonder how much of this has been that arrays were considered to be bad in Haskell, so no-one used them and no-one bothered to try and improve the API much (and instead went and created Vector, etc.). > If they wanted 2 dimensional arrays then I know there are some matrix > libraries. We now have repa, but hmatrix (the only other matrix library that I know of on Hackage) limits you to only 2D matrices. > Of course, sometimes IArray is hard to avoid, e.g. Data.Graph is just > a type synonym for an array. I wrote a small library of graph > utilities, and dealing with the arrays was back to awkward land. Any particular reason you used Data.Graph rather than fgl, etc.? > So... am I alone in this dislike of IArray? Or maybe someone can > explain why it's actually a very useful interface? Admittedly vector > is a mere 'cabal install' away, but array has a blessed status as a > ghc bundled library and is likely to be the first place people will > look, as well as the natural base for other data types that want an > array, like Data.Graph. > > I know it's not as simple as "just debundle IArray" because it's a > bootlib and presumably used in ghc itself, though I know there is > support for reducing the set of bootlibs. There's also the whole > mutable interface, which I haven't used, but maybe I'd like it more. > I know the array stuff winds up integrated fairly deeply with ghc's > unboxed arrays and whatnot, so there's a lot of detail I don't > understand. I just know I dread going back to array using code while > I tend to enjoy working with vector, bytestring, text, storablevector, > etc. I see there are two possible sources of your "problems" here: 1. The underlying data structure (index types and bounds, etc.) 2. The API You mainly seem to have an issue with the API itself. My guess is that the API for array hasn't changed much because it was already there and a boot library (so incremental changes, etc.) whereas when vector, etc. was being written the opportunity was being taken to create an API better suited for the task, taking into account people's usage of array. I don't disagree that IArray's API isn't that great and could be imp
[Haskell-cafe] Data.IArray rant
I never liked Data.IArray. Recently I had to deal with it again and it kind of touched off a bit of a rant: Array bounds are an inclusive range, which runs counter to almost all other uses of ranges, and for good reason. Length of an array is (high - low + 1). If you want to convert a list to an array it's 'IArray.listArray (0, length xs - 1) xs'. And if you forget to subtract one or add one it's likely to be a runtime crash. Off-by-one errors and runtime crashes... I've gotten accustomed to not having those in haskell! The vast majority of data types have their own set of monomorphic fuctions, and yet array all of the sudden wants to be an interface. That's nice and all, but who actually uses that interface? I recall there used to be a DiffArray and some other variants, but they were decried as being slow and appear to be gone now. So it appears that there's a complexity price paid to support different array types under the same interface, namely giant class contexts that can't be abstracted away and dependence on MPTCs... and appears to be unused. And then another price paid to support arbitrary indices... which I at least have never used. Maybe there is a field where arrays with strange index ranges like 5--20 are useful, but I always just want 0--length-1. Meanwhile, they lack basic features like concatenation. No Monoid instance. In fact, hardly any useful instances. The result is that my first contact with haskell arrays left me with the impression that they were complicated, hard to use, and designed for someone with different priorities than me. Of course, Data.Vector didn't exist back then, but if someone were new to haskell now I would recommend they skip Data.IArray and head straight for vector. If they wanted 2 dimensional arrays then I know there are some matrix libraries. Of course, sometimes IArray is hard to avoid, e.g. Data.Graph is just a type synonym for an array. I wrote a small library of graph utilities, and dealing with the arrays was back to awkward land. So... am I alone in this dislike of IArray? Or maybe someone can explain why it's actually a very useful interface? Admittedly vector is a mere 'cabal install' away, but array has a blessed status as a ghc bundled library and is likely to be the first place people will look, as well as the natural base for other data types that want an array, like Data.Graph. I know it's not as simple as "just debundle IArray" because it's a bootlib and presumably used in ghc itself, though I know there is support for reducing the set of bootlibs. There's also the whole mutable interface, which I haven't used, but maybe I'd like it more. I know the array stuff winds up integrated fairly deeply with ghc's unboxed arrays and whatnot, so there's a lot of detail I don't understand. I just know I dread going back to array using code while I tend to enjoy working with vector, bytestring, text, storablevector, etc. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: hledger-web 0.15.1 (& hledger 0.15)
I've made a bugfix release of the hledger-web package, to fix build problems. hledger-web 0.15.1: * web: add missing Hledger.Web.Options to cabal file * web: tighten up dependencies to reduce build problems And here's another new dependency I forgot to mention: flot, the js charting library. The rest of this mail is a repeat of yesterday's announcement, since that one seriously confused google groups, gmane, and perhaps your mailreader (pro tip: don't re-edit old announcements with Mail.app's cmd-shift-d. :) -Simon Date: 2011/9/1 Subject: ANN: hledger 0.15 I'm pleased to announce hledger 0.15! This release includes work by Trygve Laugstøl, Dmitry Astapov, Clint Adams, Johann Klähn and myself. hledger is a library and set of user tools for working with financial data (or anything that can be tracked in a double-entry accounting ledger.) It is a haskell port and friendly fork of John Wiegley's Ledger. hledger provides command-line, curses and web interfaces, and aims to be a reliable, practical tool for daily use. Given a plain text file describing transactions of money or any other commodity, it will print the chart of accounts, account balances, or just the transactions you're interested in. It can also help you record new transactions, or convert CSV data from your bank. Home: http://hledger.org IRC: irc://irc.freenode.net/#ledger Install: cabal update; cabal install hledger [hledger-web hledger-vty hledger-chart hledger-interest] Platform-specific binaries, which are time-consuming to make and support, are now provided on request to financial donors - a great way to give back and help pay hosting costs! Best, -Simon Release notes for 0.15: * hledger's options are now modal, providing better help (using cmdargs) * hledger now lists and runs any hledger-* add-ons found in the user's path * case insensitivity of filter patterns has been fixed * parsing: `alias`/`end aliases` directives, for renaming accounts, are supported, like ledger's but a bit more powerful; also an `--alias` option for renaming on the fly * parsing: the `account` directive now preserves posting type (normal/virtual/balanced virtual) * parsing: the `pop` directive is supported as an alias for `end tag`, like ledger * parsing: `P` (historical price) directives can contain a (ignored) numeric time zone, like ledger * parsing: the leading `!` in directives is now optional and deprecated, like ledger * parsing: entries with a negative amount in the first posting now infer the correct balancing amount * parsing: bad date checking is more accurate * balance: collapsing of boring accounts to one line can be disabled with `--no-elide` * balance: fix a wrong precision regression from last release * convert: standard input can be converted * convert: an alternate rules file can be specified with `--rules` * convert: `account2-field` can be used when the CSV file specifies both accounts * convert: `description-field` can have a custom format and combine multiple CSV fields * convert: `in-field` and `out-field` support CSV files that use two amount columns * convert: don't fail when there's no default journal file * web: the web interface has been overhauled/cleaned up * web: account register views are now transaction-based, like gnucash etc., and show accurate historical balances when possible * web: simple balance charts are displayed (using flot) * web: more expressive and consistent search patterns, using a new matching engine * web: add form uses currently focussed account as default, redirects to itself, formats status messages better * web: sidebar now shows empty/boring accounts too * web: now uses warp and a newer yesod * api simplifications * importable Hledger, Hledger.Web, Hledger.Vty and Hledger.Chart modules * the basic reports are now provided by hledger-lib for easier reuse * new api use examples: `equity.hs`, `uniquify.hs` * some old base 3 support has been dropped * the old -s flag has been dropped Stats: Release contributors: Simon Michael, Trygve Laugstøl, Dmitry Astapov, Clint Adams, Johann Klähn 132 days, 314 commits, 18 end-user features and 6 end-user bugfixes since last release. 210 unit & functional tests and 55% unit test coverage (hledger, hledger-lib packages). 7642 lines of code (all packages). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] type profiling not helpful
Cafe, Using "prog +RTS -M1G -hy" for my program prog, I generate a heap profile as documented in [1]. There is one big block in the output graph labelled with "*" though, which is not very helpful. The star character isn't even mentioned in the documentation, I wonder what it represents. Thanks in advance, [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/prof-heap.html#rts-options-heap-prof -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: job position
For anybody interested in programming languages or markup languages, there is an open job position for a junior developer at Stilo (http://www.stilo.com/). Haskell is currently used only for prototyping, but there are plans to begin some major development in Haskell within a year. The job ad is attached. Job Vacancy.docx Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Regular Expression Parsing via derivatives
Hi, In regex-pderiv, we gave a practical implementation of regex matching using partial derivative. But of course we could easy write one which using brzozoski's derivative, but some simplification is required other wise there are infinitely many states. Probably Martin has an implementation somewhere. Regards, Kenny On Tue, Aug 2, 2011 at 12:38 AM, Alex Clemmer wrote: > Hmm. Not sure how I missed that. And, I also inquired about developing a > "core featre" instead of a library -- implying disparity where in retrospect > there doesn't appear to be any. > > That's too bad, but thanks for the helpful response! > > > On Mon, Aug 1, 2011 at 12:26 PM, Antoine Latter wrote: > >> On Mon, Aug 1, 2011 at 10:51 AM, Alex Clemmer >> wrote: >> > Hi Haskell people, >> > >> > I've been snooping through various mailing lists and the current Haskell >> > implementation of regular expressions and I was wondering if there has >> been >> > a discussion about implementing regex parsing with derivatives. If so, I >> > haven't seen it. If not, I'd like to have a discussion about it -- if >> for no >> > other reason than to decide whether I should implement it as a library, >> or >> > (to attempt to implement it) as a core feature. >> > >> > For those of you who don't know, recent work by Might and Darais >> indicates >> > that parsing CFGs can be done better (i.e., significantly faster) than >> more >> > "traditional" approaches. Might's presenting at ICFP later in September >> > about it. >> > >> > I guess the first thing I should ask is, which mailing list is actually >> the >> > right place to field this inquiry. I considered dropping it in the main >> > haskell list, but wasn't sure how people would respond. >> > >> >> This is probably the right list to ask. >> >> I don't know much about the topic, a a quick Google search turned up: >> >> http://hackage.haskell.org/package/regex-pderiv >> >> which has the right keywords. >> >> More discussion on related (or not!) here: >> >> >> http://www.google.com/search?q=Regular+Expression+derivative+haskell&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:unofficial&client=firefox-a >> >> Antoine >> >> > -- >> > Alex >> > >> > >> > ___ >> > Haskell-Cafe mailing list >> > Haskell-Cafe@haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >> > >> > > > > -- > Alex > > > ___ > 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] ANN: EclipseFP 2.1.0 released
Hello Haskellers, Version 2.1.0 of the EclipseFP project (Eclipse plugins for Haskell development) has been released. Based mainly on the work Alejandro Serrano did for his GSoC project, this release features a lot of enhancements: - A package/module browser - Hoogle integration: select a identifier in your code and jump to its hoogle definitions - HLint integration: jump directly to HLint errors and warnings - Profiling graphs: run an executable with profiling flags and its the resulting graphs - SourceGraph: generate SourceGraph reports - Better auto completion information And of course some bug fixes. Please go to http://eclipsefp.github.com/, the new website Alejandro designed for more information and installation instructions. Feedback welcome! -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Finger Tree without using Monoid
Xinyu LIU writes: > I was trying to implement MTF (move-to-front) algorithm, However, neither > Array nor List satisfied all aspects. Array: Although the random access is O(1), However, move an element to front takes O(N) in average; List: Although move to front is O(1), However, random access takes O(N) in average; > I dig out the paper [1] and find the Finger Tree solution. There is already > good Finger Tree implementation in Haskell as Data.Sequence [2] based on [3]. > I wrote a simple version based on the original paper, but avoid using Monoid > when augment (or cache) the size of the tree. The idea is to wrap every > element as a leaf of node. Unless I've misread this, I think you're specializing the finger tree to the monoid of natural numbers under addition, as in Section 4.5 of the paper, and also in Data.Sequence. So one could write move-to-front directly with Data.Sequence as moveToFront :: Seq a -> Int -> Seq a moveToFront t i = let (f, b) = splitAt i t in case viewl b of x :< b' -> x <| f >< b' EmptyL -> t ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Finger Tree without using Monoid
Chris Smith wrote: I'm curious why you wanted a finger tree without the Monoid instance... if you need a different Monoid instance, you can probably simplify your code significantly by using a newtype wrapper around Seq rather than re-implementing it. Indeed, the whole point of the Monoid is that you can use one and the same finger tree implementation for a variety of data structures. Practically every tree-based data structure can be obtained this way. See also http://apfelmus.nfshost.com/articles/monoid-fingertree.html Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
