[Haskell-cafe] yaml and aeson Was: Growing Haskell Platform
On Fri, Dec 7, 2012 at 10:54 AM, Roman Cheplyaka r...@ro-che.info wrote: * Michael Snoyman mich...@snoyman.com [2012-12-07 09:52:07+0200] Let me bring up one other package: yaml (written by me). I think it's a pretty good fit for the standard YAML packaging library, since it simply reuses the existing infrastructure from the aeson package (i.e. the ToJSON and FromJSON typeclasses, and the Value datatype). But I'm actually a bit concerned about proposing it, based on some history. When I was looking at existing YAML libraries, I rejected yours when I saw JSON types. (I did see the do not let that confuse you, it's intentional warning, and no, it didn't help.) Besides giving the feeling that the API is a hack, this will inevitably confuse readers of my code who are not familiar with the library and, just based on the names, will assume that the code is working with JSON, not YAML. If you mean the naming is a hack, I agree. But if we pretend for a moment that the word JSON was actually replaced with YAML everywhere, I think the abstraction is correct. The Value datatype represents a very sane subset of YAML that people usually want to deal with. And if they want to deal with all the glories of aliases and tags, we still have the Text.Libyaml interface which preserves all information. In other words, the hack is in the name, not the abstraction. IIUC, all of the existing tools for JSON processing are mainly just existing FromJSON instances. I am not sure how common this situation is, but for that you could define a newtype whose FromYAML instance would internally use the FromJSON instance of the underlying type. It's the two typeclasses and the Value datatype. Don't underestimate the importance of reusing infrastructure here. If we had our own types and classes in YAML, then everyone who wants to include serialization classes in their packages would have to write redundant instances for both packages. Most likely, that would just mean incomplete instances for both packages. It would also mean that we'd have to duplicate libraries like aeson-lens, and duplicate all bugfixes in built-in instances, Generics code, TH code, etc. As a side benefit, the current setup allows code to remain serialization-format-agnostic. For example, Persistent can read configuration from either JSON to YAML files. Since YAML is a superset of JSON, that's not such an amazing statement, but it does mean that users can avoid an extra yaml package dependency if they really are just sticking with JSON data. Or perhaps the JSON-agnostic subset of aeson could be extracted into a separate library, which both aeson and yaml would depend on. I'd be very much in favor of that. I'm not so irked by the name hack to have bothered bringing this up with Bryan, but if he's willing to make that change, I'd certainly be grateful. I actually think it would be more logical for the typeclasses to be called ToValue and FromValue anyway, since that more directly states what they do. As for toYAML/toJSON, I guess most of the time they are different anyway — otherwise it's defeating the purpose of YAML to be more human-readable than JSON. I don't think that's true in practice. Most of the readability of YAML comes from the syntax, not the choice of actual serialization structure. But I could be mistaken. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is it possible to have constant-space JSON decoding?
See also the incremental XML parser in HaXml, described in Partial parsing: combining choice with commitment, IFL 2006. It has constant space usage (for some patterns of usage), even with extremely large inputs. http://www.google.co.uk/url?sa=trct=jq=malcolm+wallace+partial+parsingsource=webcd=2ved=0CEEQFjABurl=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.135.7512%26rep%3Drep1%26type%3Dpdfei=Db3BUNmiOsfS4QTAkoDYAwusg=AFQjCNHHywUCvaFv8eBoQ-x9jj4GOMHo2w On 5 Dec 2012, at 05:37, Johan Tibell wrote: Hi Oleg, On Tue, Dec 4, 2012 at 9:13 PM, o...@okmij.org wrote: I am doing, for several months, constant-space processing of large XML files using iteratees. The file contains many XML elements (which are a bit complex than a number). An element can be processed independently. After the parser finished with one element, and dumped the related data, the processing of the next element starts anew, so to speak. No significant state is accumulated for the overall parsing sans the counters of processed and bad elements, for statistics. XML is somewhat like JSON, only more complex: an XML parser has to deal with namespaces, parsed entities, CDATA sections and the other interesting stuff. Therefore, I'm quite sure there should not be fundamental problems in constant-space parsing of JSON. BTW, the parser itself is described there http://okmij.org/ftp/Streams.html#xml It certainly is possible (using a SAX style parser). What you can't have (I think) is a function: decode :: FromJSON a = ByteString - Maybe a and constant-memory parsing at the same time. The return type here says that we will return Nothing if parsing fails. We can only do so after looking at the whole input (otherwise how would we know if it's malformed). The use cases aeson was designed for (which I bet is the majority use case) is parsing smaller messages sent over the network (i.e. in web service APIs) so this is the only mode of parsing it supplies. -- Johan ___ 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] yaml and aeson Was: Growing Haskell Platform
* Michael Snoyman mich...@snoyman.com [2012-12-07 11:51:40+0200] As for toYAML/toJSON, I guess most of the time they are different anyway — otherwise it's defeating the purpose of YAML to be more human-readable than JSON. I don't think that's true in practice. Most of the readability of YAML comes from the syntax, not the choice of actual serialization structure. But I could be mistaken. Not the serialization structure, no. I meant that YAML has some flexibility in syntax, which probably should be exploited by the instance writer to improve readability. For that you'd need a sufficiently adjustable pretty-printer, but that also means that you can't reuse ToJSON. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] yaml and aeson Was: Growing Haskell Platform
On Fri, Dec 7, 2012 at 12:00 PM, Roman Cheplyaka r...@ro-che.info wrote: * Michael Snoyman mich...@snoyman.com [2012-12-07 11:51:40+0200] As for toYAML/toJSON, I guess most of the time they are different anyway — otherwise it's defeating the purpose of YAML to be more human-readable than JSON. I don't think that's true in practice. Most of the readability of YAML comes from the syntax, not the choice of actual serialization structure. But I could be mistaken. Not the serialization structure, no. I meant that YAML has some flexibility in syntax, which probably should be exploited by the instance writer to improve readability. For that you'd need a sufficiently adjustable pretty-printer, but that also means that you can't reuse ToJSON. Roman I see what you mean. You're talking about pretty-printing features such as how strings get quoted. That's true, to have full support for this, you can't use the ToJSON interface, but instead need to use the Text.Libyaml low-level interface. IMO, that's an acceptable trade-off. I consider the readability of YAML much more important for human-generated files. But if you'd like to see a higher-level interface which allows more control, I see no problem with adding it in. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintainer of fixpoint
Thanks Brent, that's just what I needed. I'm switching to recursion-schemes immediately. Best regards, Petr 2012/12/6 Brent Yorgey byor...@seas.upenn.edu On Wed, Dec 05, 2012 at 08:22:32PM +0100, Petr P wrote: Dear Haskellers, I've made some minor improvements of fixpoint package http://hackage.haskell.org/package/fixpoint. I tried to contact the original maintainer twice, but without success. The package hasn't been updated for 4 years. How should I proceed? Should I start a new fork of the package? Or is there a way how to take over an orphaned package? Thanks for help, Petr Pudlak I should also point out that I think the (much more recent) recursion-schemes package implements everything in 'fixpoint' and a lot more besides. -Brent ___ 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] Is it possible to have constant-space JSON decoding?
On 12-12-05 12:48 AM, Jason Dagit wrote: I thought it was possible to get around this with lazy patterns such Wadler's force function [1]? (untested code) force y = let Just x = y in Just x lazyDecode :: FromJSON a = ByteString - Maybe a lazyDecode = force . decode This says, the type is Maybe, but the value is always Just. If there will be a parse error, you will get an async imprecise exception, not Nothing, at the later time when you look closer. This respects the letter, but not the point, of the Maybe type. If you are to do this (I have no moral, I hold nothing against doing this, the async imprecise exception will give you enough grief), you may as well skip the Just wrapping and directly go ByteString - a. The point of the Maybe type is to communicate parse errors by a less async, less imprecise way. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Understanding GHC's instance inference.
Thank you, Adam, for I didn't know about paczesiowa's article. That will be useful for me. What I was trying to make is a zipWithN that takes the zipper function as its last argument, not the first. This is because in my applications the zipper functions tend to be complicated lambdas, as illustrated in [1] . Since we live in curried world where all functions are superficially unary, to define the last argument, and to implement forZN, needs extra work than to implement zipWithN, I believe [2] . I'm interested how much we can make these two share their internal mechanisms. [1] https://github.com/nushio3/practice/blob/master/free-objects/zipf-05.hs [2] https://groups.google.com/forum/?fromgroups=#!topic/haskell-cafe/-e-xaCEbd-w 2012/12/6 adam vogt vogt.a...@gmail.com: On Wed, Dec 5, 2012 at 12:12 AM, Takayuki Muranushi muranu...@gmail.com wrote: Dear everyone, I have a code https://github.com/nushio3/practice/blob/master/instance-inference/zipf-11-1.hs that produces a type-error when I remove a type signature. https://github.com/nushio3/practice/blob/master/instance-inference/zipf-11.hs Hi Takayuki, The ghc manual sections about the extensions are a good place to start. Also check out http://okmij.org/ftp/Haskell/ I think you are expecting forZN to be able to use the number of - in the function(s) supplied to decide how many lists to take, as done here: http://paczesiowa.blogspot.ca/2010/03/generalized-zipwithn.html Replacing the [] container used in the above zipWithN with a `Data.Key.Zip v = v' that is the same for all of the arguments might be straightforward. But there are a lot of type signatures that have to add that parameter, and maybe that will interfere with the incoherent instance business going on. Adam ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best approach to avoid dependency hells
On 12-12-05 01:52 PM, Ivan Perez wrote: I've spent the last couple of days fighting my way around a dependency hell with my own libraries and packages. If I install them package by package (by hand), I'm very likely to hit one of these conflicts that I'm talking about. A simple example of something that did happen: - Package A depends on bytestring, and is compatible with both 0.9.* and 0.10.* - Package B depends on ghc, which I installed using the package manager and which depends on bytestring 0.9.2 - Package B depends on package A. I do not understand the conflict. First you have GHC, and it comes with bytestring-0.9.2. Then one of two things happen, but I can't see a conflict either way: * You request A, but A should be fine with the existing bytestring-0.9.2. Then you request B, but B should be fine with the existing A you have, and indifferent about bytestring. OR * You request B. So cabal-install bring in A and then B. A should be fine with the existing bytestring-0.9.2, and then B should be fine with that A and indifferent about bytestring. If there is a conflict, it cannot be deduced from your data. I would like to the best approach to 1) avoid these situations and 2) fix them when they happen. To prevent or foresee problems, add --dry-run to your cabal install commands to see what packages are to be brought in, and check that list. If the list contains packages you already have, same version or different version, then it is a potential problem. It is fine with the pros of cabal matters, they know how to live with it, and they tell others it's fine. But it is not fine for non-pros, it causes confusion. I am fine with adding constraints such as bytestring == the version that comes with GHC to your cabal install commands and/or your ~/.cabal/config, contrary to what someone else says. The problem with setting it in ~/.cabal/config is that you will forget to change it when you change to another GHC version. But adding it manually as --constraint flags to cabal install may help with specific cases. How do you know whether it helps or hurts one case? Use --dry-run to find out. Play with adding and omitting constraints to see which list you like most. Your different projects can have different needs. This is why cabal-dev or other sandboxing methods are a good idea. This does not deny that some packages benefit all of your projects and can be installed outside sandboxes. You have to choose carefully. To clean up a mess or bad state, see my http://www.vex.net/~trebla/haskell/sicp.xhtml#remove Actually, see the whole thing. It does not suffice to erase ~/.cabal (and mostly unnecessary). It does not suffice to erase GHC and then install the same GHC version again. You are still missing an important piece of metadata. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
