Re: [Haskell-cafe] mtl and transformers
Günther Schmidt wrote: Hi, when I cabal-installed the iteratee package, the transformers package was also installed as a dependency. Now when I run applications that import Control.Monad.Transformers I get this: Could not find module `Control.Monad.Trans': it was found in multiple packages: transformers-0.1.4.0 mtl-1.1.0.2 Another solution is to build your applications using Cabal and specify your dependency on mtl in the cabal file. HTH, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mtl and transformers
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... -- 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] 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] mtl and transformers
On Mon, Jan 11, 2010 at 10:16 AM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com wrote: 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. Thanks for this tip! I always make a ghci.sh bash script in each of my projects that calls ghci -hide-all-packages -package x -package y -package z. However a cabal ghci or cabal interactive command that does this automatically would be ideal. I see there already is a ticket[1] about it. regards, Bas [1] http://hackage.haskell.org/trac/hackage/ticket/382 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] New blog: mainly Haskell and wxHaskell related
Hi all, I have just started a new blog at http://wewantarock.wordpress.com. At least initially, my intention is to provide a set of 'tutorial' style articles to help new wxHaskell users get beyond the 'Hello World' stage by offering a few worked examples on things you might want to do to put together a usable application. The idea is to offer something which fits between the first tutorial and the reference documents. The first few postings will explain the anatomy of a complete custom wxHaskell control written in Haskell. Comments gratefully accepted, including (gentle please - I'm not dons!) criticism of my Haskell style. Regards Jeremy O'Donoghue ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal bug?
L.S., I had a strange response from Cabal: cabal upgrade hlint Resolving dependencies... cabal: cannot configure containers-0.3.0.0. It requires base =4.2 6 For the dependency on base =4.2 6 there are these packages: base-4.2.0.0. However none of them are available. base-4.2.0.0 was excluded because of the top level dependency base -any So, base-4.2.0.0 cannot be used, because any version of base is OK? Is this a bug in Cabal? Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal bug?
Henk-Jan van Tuyl hjgt...@chello.nl writes: I had a strange response from Cabal: cabal upgrade hlint I thought upgrade was disabled... what version of cabal-install do you have? Resolving dependencies... cabal: cannot configure containers-0.3.0.0. It requires base =4.2 6 For the dependency on base =4.2 6 there are these packages: base-4.2.0.0. Base 4.2 and containers-0.3 come with/are for GHC-6.12.* So, base-4.2.0.0 cannot be used, because any version of base is OK? Is this a bug in Cabal? The latest version of hlint doesn't need containers-0.3; so just do cabal install --reinstall hlint to get the new version. -- 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
[Haskell-cafe] Re: Approaches to dependent types (DT)
pbrowne wrote: Dependent Types (DT) The purpose of dependent types (DT) is to allow programmers to specify dependencies between the parameters of a multiple parameter class. 'Dependent type' means result type (of a function) can depend on argument values. This is not (directly) supported in Haskell. What you are talking about is called 'functional dependencies', not 'dependent types'. Sometimes abbreviated as 'fundeps'. DTs can be seen as a move towards more general purpose parametric type classes. This is at least misleading, as adding a functional dependency does not make the class more general, but more special, as it reduces the number of possible instances. Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] short licensing question
Hello Café, when writing a Haskell library that uses two other Haskell libraries -- one licensed under BSD3 and one under LGPL -- what are allowed possibilities for licensing the written package? PublicDomain? BSD3? LGPL? Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mtl and transformers
Bas van Dijk v.dijk@gmail.com wrote: I always make a ghci.sh bash script in each of my projects that calls ghci -hide-all-packages -package x -package y -package z. However a cabal ghci or cabal interactive command that does this automatically would be ideal. I see there already is a ticket[1] about it. regards, Bas [1] http://hackage.haskell.org/trac/hackage/ticket/382 Shell script can be replaced with .ghci file. See http://neilmitchell.blogspot.com/2010/01/using-ghci-files-to-run-projects.html (Just my two cents.) -- vvv ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] short licensing question
sebf: Hello Café, when writing a Haskell library that uses two other Haskell libraries -- one licensed under BSD3 and one under LGPL -- what are allowed possibilities for licensing the written package? PublicDomain? BSD3? LGPL? Libraries don't link in other things as such -- the .cabal file is the only thing that ties them together -- so you can use whatever license you like. Any resulting binaries might contain a mixture of such libraries, and the most restrictive license will usually be the license of the result. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] short licensing question
On Mon, Jan 11, 2010 at 2:08 PM, Don Stewart d...@galois.com wrote: sebf: Hello Café, when writing a Haskell library that uses two other Haskell libraries -- one licensed under BSD3 and one under LGPL -- what are allowed possibilities for licensing the written package? PublicDomain? BSD3? LGPL? Libraries don't link in other things as such -- the .cabal file is the only thing that ties them together -- so you can use whatever license you like. Any resulting binaries might contain a mixture of such libraries, and the most restrictive license will usually be the license of the result. So, let's look at binaries then. In this case, LGPL is a problem. It requires you to offer a way to re-link such binaries against new versions/implementations of the library, which in practice requires it to be either open source or dynamically linked. Dynamic linking doesn't exist in GHC 6.10 and below. LGPL is thus restricted to open-source applications there. In 6.12.. well, dynamic linking exists, but in practice trying to replace a library implementation won't work. In fact, there's code in specifically to prevent it from working (well, crashing, really). So LGPL isn't very useful on that either. In practice, then, LGPL'd haskell libraries are probably useless for the stated purpose of supporting closed-source applications. You'd have to modify the license, or rather find something that fits better. I'm sure that exists, and chances are the author will be understanding if you ask. -- Svein Ove Aas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Approaches to dependent types (DT)
Ben, I have added your input. Thanks for putting me right. Pat Functional Dependencies The purpose of functional dependencies (FD) is to allow programmers to specify dependencies between the parameters of a multiple parameter class. FD reduces the number of possible instances, or models of a class. Note, the notion of FD is distinct from the concept of 'Dependent types', where the result type (of a function) can depend on argument values. FD are declared in a class header, where the type of one class parameter is declared to depend on another class parameter. Consider the following example: class Named object name | object - name where namef :: object - name instance (Eq name, Named object name) = Eq object where object1 == object2 = (namef object1) == (namef object2) The first part of the class definition Named takes two type variables as parameters; namely object and name. We say, that object determines name or alternatively that name is determined by object. This is denoted in the second part of the class header (i.e. | object - name). With DTs, the dependent type depends on values of the determining type. Hence, a FD involves a relation between Haskell’s value-level and the type-level (or type system). The Named class contains the signature, but not the definition, of one function called namef. Note, the in the definition of namef, the argument and return type (object - name) are textually identical to that occurring in the class header, however the semantic is that of function definition rather that of type dependency. In the instance declaration, the part before the = is called the context, while the part after the = is called the head of the instance declaration. The context contains one or more class assertions, which is a list of classes each with their respective type variables, asserting that a type variable is a parameter of a particular class. The context for the above example includes two previously defined classes. The Eq class is defined in the Haskell prelude and our user defined Named class. The instance asserts: If (type of name is an instance of the Eq class) and (type pair (object, name) is an instance of Named) then object is an instance of Eq The new Eq instance defined is quite general, it asserts that every type object is an instance of the Eq class. It does not say that every type object that is an instance of Named is also an instance of Eq. Now we consider the definition of equality (==) for the type object in the instance body. Initially, the definition determines the type name in a type-type dependency (e.g. via the function call namef object1). When the two names have been calculated the function uses this information to define equality on values of type object via equality on values of type name. Benjamin Franksen wrote: pbrowne wrote: Dependent Types (DT) The purpose of dependent types (DT) is to allow programmers to specify dependencies between the parameters of a multiple parameter class. 'Dependent type' means result type (of a function) can depend on argument values. This is not (directly) supported in Haskell. What you are talking about is called 'functional dependencies', not 'dependent types'. Sometimes abbreviated as 'fundeps'. DTs can be seen as a move towards more general purpose parametric type classes. This is at least misleading, as adding a functional dependency does not make the class more general, but more special, as it reduces the number of possible instances. Cheers Ben ___ 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] short licensing question
Svein Ove Aas svein@aas.no writes: when writing a Haskell library that uses two other Haskell libraries -- one licensed under BSD3 and one under LGPL -- what are allowed possibilities for licensing the written package? Any resulting binaries might contain a mixture of such libraries, and the most restrictive license will usually be the license of the result. In this case, LGPL is a problem. It requires you to offer a way to re-link such binaries against new versions/implementations of the library, which in practice requires it to be either open source or dynamically linked. Isn't it possible to provide the proprietary bits as compiled object files (.o or .a) to be linked by the recipient? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal bug?
On Mon, 2010-01-11 at 13:33 +0100, Henk-Jan van Tuyl wrote: L.S., I had a strange response from Cabal: cabal upgrade hlint Resolving dependencies... cabal: cannot configure containers-0.3.0.0. It requires base =4.2 6 For the dependency on base =4.2 6 there are these packages: base-4.2.0.0. However none of them are available. base-4.2.0.0 was excluded because of the top level dependency base -any So, base-4.2.0.0 cannot be used, because any version of base is OK? Is this a bug in Cabal? It's a bug in the sense that the error message is misleading. What it actually means is base-4.2.0.0 cannot be used, because an installed version of base is required. The pretty printing for installed constraints (as opposed to version constraints) is borked. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Update for type-level library (0.2.4)
Dear Haskell developers, A new version of the type-level library for type-level programming is pushed into the development repository and uploaded to the Hackage database. This is only a minor update to fix the compatibility issues with base 4, GHC=6.10 and cabal-install (not backward compatible). Bests, Hosein Attarzadeh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] short licensing question
Svein Ove Aas wrote: In this case, LGPL is a problem. It requires you to offer a way to re-link such binaries against new versions/implementations of the library, which in practice requires it to be either open source or dynamically linked. Don't understand that. Can't we just put a constraint: our binary works only with versions x.x.x-y.y.y of this LGPL licensed library? The Cabal provides a way to put such constraint in build-depends... Andrey -- View this message in context: http://old.nabble.com/short-licensing-question-tp27110059p27114282.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] short licensing question
On Mon, Jan 11, 2010 at 6:58 AM, Sebastian Fischer s...@informatik.uni-kiel.de wrote: when writing a Haskell library that uses two other Haskell libraries -- one licensed under BSD3 and one under LGPL -- what are allowed possibilities for licensing the written package? PublicDomain? BSD3? LGPL? There was a long thread on licensing recently: http://www.mail-archive.com/haskell-cafe@haskell.org/msg68237.html I'm still waiting to hear back from the SFLC regarding the questions we came up with, and I'll post them as soon as I get them. I think in your case you can license the library you're writing any way you'd like, but distributing a statically linked binary might leave you with additional obligations under the LGPL. (Things get wonderfully more confusing when one of the libraries is the GPL, but hopefully we'll have more insight regarding that soon.) I'm not a lawyer, though, and I suggest that you take any advice from non-lawyers as hints rather than definitive answers. If you want an answer from a lawyer, the SFLC can be useful: http://www.softwarefreedom.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: chp-2.0.0, chp-plus-1.0.0
Hi, I've just released version 2.0.0 of the Communicating Haskell Processes (CHP) message-passing concurrency library onto Hackage. The main change from 1.x is that I have split the functionality into two libraries: the core functionality remains in the chp package (now version 2.0.0), while some of the additional capabilities have been moved out to the new chp-plus package (version 1.0.0). This should help in the long run by keeping the packages from becoming too large, and by allowing me to trim the dependencies of the core chp package. I've written more about the changes here, for those who it will affect: http://chplib.wordpress.com/2010/01/11/splitting-chp/ This will require small changes to your build system if you're using CHP and you upgrade to the new versions. The new versions should also fix build troubles with GHC 6.12 -- let me know if you have any troubles installing under 6.10 or 6.12. Hackage links: http://hackage.haskell.org/package/chp-2.0.0 http://hackage.haskell.org/package/chp-plus-1.0.0 Thanks, Neil. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] short licensing question
On Mon, Jan 11, 2010 at 12:02:46PM -0600, Tom Tobin wrote: On Mon, Jan 11, 2010 at 6:58 AM, Sebastian Fischer s...@informatik.uni-kiel.de wrote: when writing a Haskell library that uses two other Haskell libraries -- one licensed under BSD3 and one under LGPL -- what are allowed possibilities for licensing the written package? PublicDomain? BSD3? LGPL? There was a long thread on licensing recently: http://www.mail-archive.com/haskell-cafe@haskell.org/msg68237.html I'm still waiting to hear back from the SFLC regarding the questions we came up with, and I'll post them as soon as I get them. I think in your case you can license the library you're writing any way you'd like, but distributing a statically linked binary might leave you with additional obligations under the LGPL. (Things get wonderfully more confusing when one of the libraries is the GPL, but hopefully we'll have more insight regarding that soon.) I'm not a lawyer, though, and I suggest that you take any advice from non-lawyers as hints rather than definitive answers. If you want an answer from a lawyer, the SFLC can be useful: http://www.softwarefreedom.org/ You can also ask the Freedom Task Force of the FSFE: http://fsfe.org/projects/ftf/ftf.en.html They may offer better legal advice for Europe. Regards, Matthias-Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] short licensing question
On Jan 11, 2010, at 2:08 PM, Don Stewart wrote: Libraries don't link in other things as such -- the .cabal file is the only thing that ties them together -- so you can use whatever license you like. On Jan 11, 2010, at 7:02 PM, Tom Tobin wrote: I think in your case you can license the library you're writing any way you'd like, but distributing a statically linked binary might leave you with additional obligations under the LGPL. Thank you all for your comments. It seems consensus that it is no problem to depend on LGPL libraries if no binary that links to LGPL'ed code is distributed. I understand that this consensus is no definite legal advice, though. What reasons do people have to use a BSD license over a Public Domain license, for example with the license text from: http://www.lemur.com/pd-disclaimers.html ? Is the only difference that, with a BSD license, the copyright notice must be maintained? Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] short licensing question
What reasons do people have to use a BSD license over a Public Domain license, for example with the license text from: http://www.lemur.com/pd-disclaimers.html ? Is the only difference that, with a BSD license, the copyright notice must be maintained? I've heard rumors that you can't license your code as public domain in some countries. Not sure if the BSD3 helps with that though. But, one reason I license my Haskell code as BSD3 is that GHC and most(?) of the libraries on hackage are BSD3. And the BSD3 license is very widely known. As a result, I don't expect to have to deal with licensing issues. If I used a different license, then people would have to wonder... even if the license was more liberal. I figure people want to code, not think about licenses :p Also, I think it is kind of rude/conceited to license my code as GPL when it builds on so much BSD3 code. As if my code is some how so much better that the BSD3 isn't good enough for it :p - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] short licensing question
Sebastian Fischer wrote: What reasons do people have to use a BSD license over a Public Domain license, for example with the license text from: http://www.lemur.com/pd-disclaimers.html ? Is the only difference that, with a BSD license, the copyright notice must be maintained? One important reason is that public domain does not exist (or is not the same) in all countries, which can make international sharing a hassle. If you feel the BSD3 is too restrictive, another alternative is the WTFPL[1][2] which provides a formal contract of, essentially, public domain privileges (and is GPL-compatible). [1] http://sam.zoy.org/wtfpl/ [2] http://en.wikipedia.org/wiki/WTFPL -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Parsers (Parsec and Iteratee-based Parsers)
Hi, are there any examples how to build parsers using the library in Oleg's iteratee package? I've been using parsec for almost all my parsing needs, in fact it was parsec that got me started with Haskell. I'd like to try to build a few parsers based on the left-fold-enumerator thingy and compare this approach to parsec. Any good tips how to get started? Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsers (Parsec and Iteratee-based Parsers)
2010/1/11 Günther Schmidt gue.schm...@web.de Hi, are there any examples how to build parsers using the library in Oleg's iteratee package? I've been using parsec for almost all my parsing needs, in fact it was parsec that got me started with Haskell. I think you should be in contact with John Lato. Last time we had correspondence he mentioned a hybrid between iteratees and parsec. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell-iPhone mailing list?
Is there a mailing list for efforts to get Haskell running on the iPhone? As I've been maintaining an iPhone app for my employer (and nearly foaming at the mouth with hatred for Objective-C), I'd love to see a more sane option in this space. I've seen the wiki page [1], but I'm not aware of any other space for collaboration here. [1] http://www.haskell.org/haskellwiki/IPhone ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsers (Parsec and Iteratee-based Parsers)
2010/1/11 Jason Dagit da...@codersbase.com: 2010/1/11 Günther Schmidt gue.schm...@web.de Hi, are there any examples how to build parsers using the library in Oleg's iteratee package? I've been using parsec for almost all my parsing needs, in fact it was parsec that got me started with Haskell. I think you should be in contact with John Lato. Last time we had correspondence he mentioned a hybrid between iteratees and parsec. I don't know if I'd call it a hybrid, however there is a way to embed Parsec parsers (v.3 only) in iteratee. The necessary code is available at: http://inmachina.net/~jwlato/haskell/ParsecIteratee.hs It's intended to be used for embedding relatively small parsers in iteratees. It does concatenate chunks, so if it looks too far into the stream it can be inefficient. Chunks of up to 2000 characters shouldn't require more than 1 concat (depending on what other functions you're using). This code is available as Public Domain. Thanks to Erik de Castro Lopo for suggesting integrating iteratee and parsec in some manner. It's still pretty new, so suggestions are welcome. If you want to build parsers directly with iteratee, there currently aren't any published tutorials although I can provide some working code if you like. The interface is much lower-level than Parsec. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsers (Parsec and Iteratee-based Parsers)
Hi John, thanks for responding. As I said I've been using Parsec quite a lot, but wonder if there is a different approach possible/feasible to parsing. Parsec (2x) isn't an online parser, ie, it doesn't produce a result before the whole parse is completed. There is AFAIK one alternative, the uulib, but at first glance it seemed very elaborate, so I wonder if Oleg's Iteratee offers something simpler. I am not in particular looking for some sort of parsec-iteratee-hybrid, I'd be quite happy with something entirely based on Iteratee. In the Iteratee package there are 2 sample parsers, one for TIFF and one for WAVE files. I wish I could say that the accompanying documentation is sufficient for me to get the idea, alas it's not. Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Tokenizing and Parsec
Hi all, I've used Parsec to tokenize data from a text file. It was actually quite easy, everything is correctly identified. So now I have a list/stream of self defined Tokens and now I'm stuck. Because now I need to write my own parsec-token-parsers to parse this token stream in a context-sensitive way. Uhm, how do I that then? Günther a Token is something like: data Token = ZE String | OPS | OPSShort String | OPSLong String | Other String | ZECd String deriving Show ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hackage build errors
Hello Cafe, I noticed on my package's hackage page there is a build failure message: http://hackage.haskell.org/package/txt-sushi I don't know if these are real errors or not (I don't experience them on OS X and it's pure Haskell code) but I did poke around and noticed that some popular packages on hackage also have build failures: http://hackage.haskell.org/package/xmonad http://hackage.haskell.org/package/haddock http://hackage.haskell.org/package/pandoc http://hackage.haskell.org/package/alex http://hackage.haskell.org/package/hlint ... so what should I make of these errors? Are they useful in some way or just a problem with the build environment? (If that's the case I think they should probably be removed since they're confusing for potential users) Best Keith -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tokenizing and Parsec
Hi, Günther, you could write functions that pattern-match on various sequences of tokens in a list, you could for example have a look at the file Evaluator.hs in my scheme interpreter haskeem, or you could build up more-complex data structures entirely within parsec, and for this I would point you at the file Parser.hs in my accounting program umm; both are on hackage. Undoubtedly there are many more and probably better examples, but I think these are at least a start... regards, Uwe On 1/11/10, Günther Schmidt gue.schm...@web.de wrote: Hi all, I've used Parsec to tokenize data from a text file. It was actually quite easy, everything is correctly identified. So now I have a list/stream of self defined Tokens and now I'm stuck. Because now I need to write my own parsec-token-parsers to parse this token stream in a context-sensitive way. Uhm, how do I that then? Günther a Token is something like: data Token = ZE String | OPS | OPSShort String | OPSLong String | Other String | ZECd String deriving Show ___ 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] Parsers (Parsec and Iteratee-based Parsers)
2010/1/12 Günther Schmidt gue.schm...@web.de: Hi John, thanks for responding. As I said I've been using Parsec quite a lot, but wonder if there is a different approach possible/feasible to parsing. Parsec (2x) isn't an online parser, ie, it doesn't produce a result before the whole parse is completed. This appears to be a common source of confusion. You can produce a result by not trying to parse the entire input in one go, instead parse as much as you want to consume, then return the rest of the input with the tokens that you have collected. For example, in Parsec 2 a regular approach I use is something like: get1 = do token - parse1token remaining - getInput return (remaining,token) Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hackage build errors
I noticed on my package's hackage page there is a build failure message: http://hackage.haskell.org/package/txt-sushi I don't know if these are real errors or not (I don't experience them on OS X and it's pure Haskell code) but I did poke around and noticed that some popular packages on hackage also have build failures: Just as an extra data point, I've found that some of the build errors on Hackage are due to the machine's build state and not due to any intrinsic failure in the package in question. Furthermore, Hackage does not generate Haddock for these packages even though generating Haddock would still be 1) possible and 2) useful. I think it would be better to divorce the build process from the Haddock generation, since they aren't necessarily related (and Haddock builds will fail if the package *is* trivially broken.) -- Jonathan Daugherty ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
