[Haskell-cafe] Zippers, Random Numbers Terrain
Hi All, To amuse myself while waiting for test-runs to complete, I was thinking about random terrain generation. I came across a bunch of nice posts by Torben Mogensen, where he describes a neat way of constructing random terrains by recursively subdividing right angled isosceles triangles. It got me thinking - it's all well and good subdividing to give more detail as you zoom in, but what about when you zoom out? This got me thinking that it would be cool to make an infinite terrain generator using a zipper, so you can zoom in/out infinitely, and by implication, infinitely in any direction. One of the key components that seems to be necessary is a random number generator zipper. In Mogensen's scheme, you have a number associated with each point, and when you subdivide, you create a new RNG seed from the numbers at each end of the hypotenuse which you are bisecting. These numbers are used to generate height variation. The trick, is to make the combination order independent (e.g. xor). This is easy for zooming in, but it's not clear how to do this for zooming out. It's probably sufficient to assume a (parameterizable) hashing/mixing scheme, and to simply number the nodes in some deterministic fashion. The subdivision is binary, so we could number the children deterministically. If we use decimals, from some arbitrary starting point, we can extend in the fractional direction when we zoom in, and extend in the whole number direction. I'm only just discovering zippers, so my question to the learned members of this forum is: Am I on the right track? Is a scheme like this going to work? cheers, Tom -- Dr Thomas Conway [EMAIL PROTECTED] Silence is the perfectest herald of joy: I were but little happy, if I could say how much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Space usage and CSE in Haskell
|power_list :: [a] - [[a]] |power_list = foldr (\x ~(_:xs) - []:xs = \ys - [ys, x:ys]) [[]] | | I loved how short and sweet this version is, but sadly with GHC it's | noticeably slower than Bertram's first, more directly coded, version | (1.32 seconds vs 0.55 seconds for power_list [1..24]). | | The two-line variant below is just over 25% faster than the above | oneliner under GHC, but at 1.04 seconds, it's still bested by the | explicit version: | |power_list :: [a] - [[a]] |power_list [] = [[]] |power_list (x:xs) = [] : tail [y | ps - power_list xs, y - [ps, | x:ps]] | | Anyway, we're now far from our original topic, but thanks to Bertram, | we can see that power_list can be coded in a way that is memory | efficient, lazy-list friendly, and (relatively) easy to read. I wonder if it'd be worth writing up this thread into a Wiki page? Some neat programming here! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Strange behavior of executeFile
| Anything involving sharing file descriptors between processes becomes | similarly broken if the GHC runtime starts using a file descriptor as a | Handle. You're not the only one to be surprised by this behaviour, but | unfortunately it's not trivial to work around. | | Simon Marlow was going to look into this problem a few months ago, but I | don't know if he's had a chance to. File a Trac bug report? (If there isn't one already.) Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Zippers, Random Numbers Terrain
Thomas Conway wrote: To amuse myself while waiting for test-runs to complete, I was thinking about random terrain generation. I came across a bunch of nice posts by Torben Mogensen, where he describes a neat way of constructing random terrains by recursively subdividing right angled isosceles triangles. It got me thinking - it's all well and good subdividing to give more detail as you zoom in, but what about when you zoom out? Can you post a hyperlink for an exact description of the algorithm? This got me thinking that it would be cool to make an infinite terrain generator using a zipper, so you can zoom in/out infinitely, and by implication, infinitely in any direction. An infinite random terrain sounds like great fun :) I can't say whether it's possible or whether zippers are needed without knowing the details, though. One problem is probably having a point of reference, i.e. one needs a point (0,0) with a fixed height 0. In the bounded case, one has a rectangle to subdivide instead. Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] View patterns in GHC: Request for feedback
With the functional dependency, you can't work with the view datatypes at all. Once you write type Typ data TypView = Unit | Arrow Typ Typ instance View Typ TypView where view = ... you're no longer allowed to take apart a TypView at all! E.g. you can't write outUnit :: TypView - Bool outUnit Unit = True outUnit _= False because the implicit application of the view function will mean that outUnit must consume a Typ. Personally, I'd rather have special syntax in the pattern (- pat) than have these global effects on what you can do with certain types. -Dan On Jul27, Stefan O'Rear wrote: On Fri, Jul 27, 2007 at 05:22:37AM -0400, Dan Licata wrote: On Jul26, Stefan O'Rear wrote: So, this syntax affects a lot of code, existing or otherwise, that doesn't use view patterns, which is something we're trying to avoid. Eh? I *think* the typing rules are the same for the no-view case. If the auto-deriving hack isn't implemented, you only need a deriving(View), otherwise there should be no change at all... Assuming you don't have the functional dependency: affects in the sense that any code you write has a generalized type, so you have to explain view patterns to beginners right out of the gate, etc. If you write length [] = [] length (h : t) = 1 + length t we don't want to have to explain to beginners why it has type length :: forall a,b,c. View a [b] - a - Num c Right, which is why I think the functional dependency is good. If we have it, and the auto-deriving hack, what breaks? length [] = [] length (h : t) = 1 + length t length :: forall a b c. (View a [b], Num c) = a - c == (one of the FD rules) length :: forall a b c. (View [a] [b], Num c) = [a] - c == (plain context reduction, the first constraint is tautological) length :: forall a c. Num c = [a] - c Stefan ___ 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] Re: [Haskell] View patterns in GHC: Requestforfeedback
On Jul30, Claus Reinke wrote: one could turn that promise into a type-checked guarantee by using explicit sum types (and thus structural rather than name-based typing), but that gets awkward in plain haskell. I don't think the choice of whether you label your variants with names or with numbers (in1, in2, in3...) has anything to do with the choice of whether you require your cases to be exhaustive or not. i was talking about name-based (as in: this is the sum type named List) vs structural (as in: this is the sum type build from Cons and Nil) typing. the former hides (in-)exhaustiveness from the type system, the latter exposes it. I don't think the juxtaposition you're setting up here, between name-based and structural, is correct. You could just as well choose the elimination form for name-based sum types (i.e., datatypes) to be an exhaustive case analysis. It just happens that Haskell chooses to permit non-exhaustive case expressions. -Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Zippers, Random Numbers Terrain
apfelmus apfelmus at quantentunnel.de writes: Thomas Conway wrote: To amuse myself while waiting for test-runs to complete, I was thinking about random terrain generation. I came across a bunch of nice posts by Torben Mogensen, where he describes a neat way of constructing random terrains by recursively subdividing right angled isosceles triangles. It got me thinking - it's all well and good subdividing to give more detail as you zoom in, but what about when you zoom out? Can you post a hyperlink for an exact description of the algorithm? This got me thinking that it would be cool to make an infinite terrain generator using a zipper, so you can zoom in/out infinitely, and by implication, infinitely in any direction. An infinite random terrain sounds like great fun :) I can't say whether it's possible or whether zippers are needed without knowing the details, though. One problem is probably having a point of reference, i.e. one needs a point (0,0) with a fixed height 0. In the bounded case, one has a rectangle to subdivide instead. Regards, apfelmus You might want to consider Perlin-Noise: http://wiki.delphigl.com/index.php/Perlin_Noise (good introduction) It uses a chaotic function (ergodic?) that works on integers. In the case of Terrain it uses 2. One for the x and one for y coordinate. It should be infinite for Zooming out. When zooming in one uses interpolation. The drawback(?) is when zooming out is that it becomes more noisy. When zooming in it becomes less. The advantage is that you dont need a reference point. That means you can render any portion of your infinite terrain without tracing back to the origin. But I fear you would need a reference point if you want to attach other kinds of data (not just the hight) with each point. Of course you could layer another perlin-noise for plants and another for rivers. But in the end all this will get boring pretty soon because its static. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] View patterns in GHC: Request?for?feedback
ChrisK [EMAIL PROTECTED] writes:
And the readability is destroyed because you cannot do any type inference in
your head.
If you see
{
Matrix m = ;
Matrix x = m * y;
...;
}
Then you know very little about the possible types of y
since can only conclude that:
[snippage] This is all very horrid, but as far as I can tell
what I was proposing wouldn't lead to such a mess, except
possibly via defaulting, which, as the least important
aspect of the idea could easily be abandoned.
--
Jón Fairbairn [EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Zippers, Random Numbers Terrain
On Monday 30 July 2007 09:51:48 apfelmus wrote: Thomas Conway wrote: To amuse myself while waiting for test-runs to complete, I was thinking about random terrain generation. I came across a bunch of nice posts by Torben Mogensen, where he describes a neat way of constructing random terrains by recursively subdividing right angled isosceles triangles. It got me thinking - it's all well and good subdividing to give more detail as you zoom in, but what about when you zoom out? Can you post a hyperlink for an exact description of the algorithm? Maybe this: http://www.geocities.com/Area51/6902/t_torben.html This got me thinking that it would be cool to make an infinite terrain generator using a zipper, so you can zoom in/out infinitely, and by implication, infinitely in any direction. An infinite random terrain sounds like great fun :) I can't say whether it's possible or whether zippers are needed without knowing the details, though. I wrote a real-time infinite-detail random planet renderer along similar lines in C++ many years ago. Thomas' description makes it sound ROAM based (isosceles triangles) but mine subdivided and perturbed an icosahedron into roughly-equilateral triangles. This is a good task for a functional programming language. It is based upon graph theory and you must consider splitting and joining triangles to keep the subdivision suitably accurate in the region currently in view. The perturbations and split/join metric can be made up and tinkered with. For a real time implementation, you maintain a priority queue of splits and joins, doing a few each frame. All in all, a very fun project. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Definition of the Haskell standard library
Can someone clarify what's going on with the standard library in Haskell? As of right now, I can download, say, GHC from haskell.org/ghc and get a set of libraries with it. I can visit http://haskell.org/ghc/docs/latest/html/libraries/, linked from the haskell.org home page, and see descriptions of all of those libraries. I can build with --make (or if I'm feeling masochistic, add several lines of -package options) and it works. That's all great. I've seen some stuff lately on -libraries and this list indicating that there's an effort to change this. People asking whether something should be included in the standard library are being told that there is no standard library really. I'm hearing that the only distinction that matters is used by GHC or not used by GHC, and that being on hackage is as official as it gets. Am I misunderstanding? Is there something awesome about Hackage that I'm not seeing? I hope one of those two is the case. Otherwise, there's a serious mistake being made here. Having a web site where people can download any of hundreds of independent libraries is not the same thing as having a good standard library for the language. I don't want to see the day when setting up Haskell involves a day-long effort of figuring out what libraries to download and install from Hackage, and in what order to do it to satisfy all the dependencies, and new Haskellers poring over web sites for the thousandth time before realizing that so-and-so's GUI library hasn't actually been touched since they finished their class project in 1998 and doesn't build with the latest version of Qt or whatever. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: HDBC or HSQL
Hi, I was also wandering between these different db-libs and thanks for your information. I tried several (HDBC, HSQL, HaskellDB) and made only small trials. HaskellDB has quite many examples on wiki that gave a quick start to further trials. But, I wasn't able to tell that some of the fields have default values and then it was already time to move on to the HSQL and HDBC trials. Is it possible to use sql-array-types with HDBC with postgresql? I don't remember was this the reason why I eventually tried HSQL - anyhow, it was rather difficult to get started with HDBC but the src test cases helped here. One example in a wiki would do miracles :) HSQL didn't have the array-types but it took only couple of hours to add a sort of support for those. There are some problems though... (indexed table queries returning some nulls is not yet working and ghci seems to be allergic to this) I was even wondering, should I propose a patch in some near future for this. But if HDBC can handle those sql-arrays or if you can give a couple of hints, how to proceed in order to add them there, given your view below, I'd be willing to try to help / to try to use HDBC. br, Isto 2007/7/30, John Goerzen [EMAIL PROTECTED]: On 2007-07-25, George Moschovitis [EMAIL PROTECTED] wrote: I am a Haskell newbie and I would like to hear your suggestions regarding a Database conectivity library: HSQL or HDBC ? which one is better / more actively supported? I am the author of HDBC, so take this for what you will. There were several things that bugged me about HSQL, if memory serves: 1) It segfaulted periodically, at least with PostgreSQL 2) It had memory leaks 3) It couldn't read the result set incrementally. That means that if you have a 2GB result set, you better have 8GB of RAM to hold it. 4) It couldn't reference colums in the result set by position, only by name 5) It didn't support pre-compiled queries (replacable parameters) 6) Its transaction handling didn't permit enough flexibility I initially looked at fixing HSQL, but decided it would be easier to actually write my own interface from scratch. HDBC is patterned loosely after Perl's DBI, with a few thoughts from Java's JDBC, Python's DB-API, and HSQL mixed in. I believe it has fixed all of the above issues. The HDBC backends that I've written (Sqlite3, PostgreSQL, and ODBC) all use Haskell's C memory management tools, which *should* ensure that there is no memory leakage. I use it for production purposes in various applications at work, connecting to both Free and proprietary databases. I also use it in my personal projects. hpodder, for instance, stores podcast information in a Sqlite3 database accessed via HDBC. I have found HDBC+Sqlite3 to be a particularly potent combination for a number of smaller projects. http://software.complete.org/hdbc/wiki/HdbcUsers has a list of some programs that are known to use HDBC. Feel free to add yours to it. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- br, Isto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Definition of the Haskell standard library
Chris Smith cdsmith at twu.net writes: Can someone clarify what's going on with the standard library in Haskell? ... sites for the thousandth time before realizing that so-and-so's GUI library hasn't actually been touched since they finished their class Short answer: Our system is very democratic. Long answer: You remind me of the usual academic debate, what to do about students using the web to do research? There's a lot of uncertain information out there, the right answer is to teach discrimination skills. Put differently, take the most famous problem in computer science, P vs NP. If a genie in a bottle is going to lie to you a couple of times before telling you a truth you can easily check, you're still better off. In, say, Perl, it's all about the libraries. One connects lots of pieces one doesn't understand with short bits of line noise, and gets serious real-world work done. That's one pole in a range of attitudes. I may be near the other pole; in a hurry I'll use libraries included with GHC without looking at the source code. I view anything else in hackage as a truly awesome repository of sample code. It's on me to make sure that it works, or that I should be using it at all, rather than doing something else. My pet example is a PDF library. No language should have its own PDF library, when Postscript is so easy to write, and Ghostscript is a cross-platform conversion tool maintained by thousands of our best and brightest. So our Haskell desire to have lots of libraries is another version of How big should a language be? The Common Lisp specification has an appendix bigger than the Scheme specification in its entirety. I've gone through several cycles in the last decade of getting rid of half my possessions; I get more than twice the utility out of what's left, in part because I understand and I can find what's left. Programming languages are the same story; I prefer lean. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] MAPI provider?
Hi, I apologize if this is off-topic or stupid. I'm not very familiar (at all) with Windows programming... I have a Haskell program that I want to get called when someone sends a message on Windows. This sending a message will happen from various programs that call MAPI. It doesn't seem very easy to plug into MAPI from Haskell as a MAPI *provider*, though if anybody has examples, that'd be great. Does anybody know of an MAPI provider that receives send requests, writes the data to a file, and then just invokes a program passing the file as a parameter? That would let me do all I need to plug in. Thanks, -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Definition of the Haskell standard library
On Mon, 2007-07-30 at 09:19 -0600, Chris Smith wrote: Can someone clarify what's going on with the standard library in Haskell? As of right now, I can download, say, GHC from haskell.org/ghc and get a set of libraries with it. I can visit http://haskell.org/ghc/docs/latest/html/libraries/, linked from the haskell.org home page, and see descriptions of all of those libraries. I can build with --make (or if I'm feeling masochistic, add several lines of -package options) and it works. That's all great. I've seen some stuff lately on -libraries and this list indicating that there's an effort to change this. People asking whether something should be included in the standard library are being told that there is no standard library really. I'm hearing that the only distinction that matters is used by GHC or not used by GHC, and that being on hackage is as official as it gets. Am I misunderstanding? Is there something awesome about Hackage that I'm not seeing? It's not finished yet :-) I hope one of those two is the case. Otherwise, there's a serious mistake being made here. Having a web site where people can download any of hundreds of independent libraries is not the same thing as having a good standard library for the language. I don't want to see the day when setting up Haskell involves a day-long effort of figuring out what libraries to download and install from Hackage, and in what order to do it to satisfy all the dependencies, We have tools to solve the downloading and installing all deps problem. It's called cabal-install. It's sort-of almost ready for wider testing. and new Haskellers poring over web sites for the thousandth time before realizing that so-and-so's GUI library hasn't actually been touched since they finished their class project in 1998 and doesn't build with the latest version of Qt or whatever. So, yes, at the moment hackage looks like a big list of packages, but the tools for automatically downloading and installing will mature. Also we expect further improvements to hackage to do more automated QA and gather testing feedback, so we can detect and manage bitrot. People have also been talking about gathering usage stats, so one can see which out of a collection of packages in a similar area are most used. I'm sure there are other ideas that can be borrowed from CPAN and similar things. On the other hand, it's not entirely true that there's no standard library, it's just that it's borders are slightly fuzzy. For example, we do have the library change submission process for modifying the standard libraries. Up until now that has been taken to mean changes to the base package. That package is now being split up, so we'll have to think about what it'll apply to in the future. My opinion is that in the past it has been too difficult to get changes into the base library, that there's been too much stability at the expense of improving scope and quality. Making it easy to install new packages and upgrade existing standard libraries should make it easier to trial more major changes outside of the standard libs before proposing getting those changes integrated. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Zippers, Random Numbers Terrain
On 7/30/07, Martin Lütke [EMAIL PROTECTED] wrote: It uses a chaotic function (ergodic?) that works on integers. In the case of Terrain it uses 2. One for the x and one for y coordinate. It should be infinite for Zooming out. When zooming in one uses interpolation. The drawback(?) is when zooming out is that it becomes more noisy. Typically you'd sum different 'octaves' of noise to get a function that's approximately self-similar under scaling, that way it'd be qualitatively similar when zooming in or out. There are many descriptions on the web. Here's one I found: http://local.wasp.uwa.edu.au/~pbourke/texture_colour/perlin/ -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Definition of the Haskell standard library
On Mon, Jul 30, 2007 at 05:27:21PM +0100, Duncan Coutts wrote: We have tools to solve the downloading and installing all deps problem. It's called cabal-install. It's sort-of almost ready for wider testing. duncan - will this have an interactive prompt? i have found perl -MCPAN -e shell immensely useful over the years thanks ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Definition of the Haskell standard library
On Mon, 2007-07-30 at 11:05 -0700, brad clawsie wrote: On Mon, Jul 30, 2007 at 05:27:21PM +0100, Duncan Coutts wrote: We have tools to solve the downloading and installing all deps problem. It's called cabal-install. It's sort-of almost ready for wider testing. duncan - will this have an interactive prompt? i have found perl -MCPAN -e shell immensely useful over the years At the moment it doesn't, but you're not the only one to suggest that it should. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GSL special functions (Re: [Haskell] math library for Haskell)
(moved to Haskell-cafe) On Wednesday 25 July 2007 12:52, Gregory Wright wrote: On Jul 25, 2007, at 6:39 AM, Chris Kuklewicz wrote: Alberto Ruiz wrote: I have included a binding to gsl_sf_gamma in the darcs repo of GSLHaskell: http://dis.um.es/~alberto/GSLHaskell/doc/GSL-Special.html#v%3Agamma I will try to upload to hackage a recent version of the library in a few days. Alberto It occurs to me that generating the binding for all the GSL Special functions by hand may be labor intensive. Would it be reasonable to have a (perhaps customized) tool generate the wrapping code? Absolutely! I am busy working on my applications and rewriting the internal support for the linear algebra wrappers, so I usually add new functions only when I need them for my own work. But a GSL library without the simplest functions is not very useful... I have some functions that make wrapping the GSL special functions much simpler. I've used them to wrap all of the Airy and Bessel functions. The process could be automated, but there are a few more cases than convenient. (For example, the computationally expensive functions take an additional argument specifying how much precision is desired.) It wouldn't be too much work to automate the most common cases (double arg, double return and double arg, error struct return); perhaps doing the remainder by hand is reasonable. That's also right, so I have written a (very crude and ad-hoc) tool to generate wrappers for the most common cases. The results look promising: http://perception.inf.um.es/~aruiz/darcs/HSSL/doc/html/GSL-Special.html They are available in the new version of the library. In principle it is already working but needs more testing. I plan to upload a version to hackage (the repo can be found in the GSLHaskell web page). A problem with automatic wrappers is that we should still add a small piece of useful haddock documentation and appropriate tests for each function. I also have bindings for all of the ODE integration routines and all of the numerical differentiation routines. All are low level, just exposing the underlying GSL routines without any convenience wrapper. I can make them available if anyone is interested. Best Wishes, Greg Good! I'd like to include a high level interface to the ODE routines. Perhaps it could be based on your bindings... Best regards, Alberto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] View patterns in GHC: Request for feedback
On Mon, Jul 30, 2007 at 05:31:40AM -0400, Dan Licata wrote: With the functional dependency, you can't work with the view datatypes at all. Once you write type Typ data TypView = Unit | Arrow Typ Typ instance View Typ TypView where view = ... you're no longer allowed to take apart a TypView at all! Exactly. And I'm 100% convinced it's a non-issue, since all the heavyweight view proposals don't allow you to manipulate view objects *at all*. My approach is no worse. E.g. you can't write outUnit :: TypView - Bool outUnit Unit = True outUnit _= False because the implicit application of the view function will mean that outUnit must consume a Typ. What would you use it for, anyway? TypView objects don't exist anywhere except internally in case-expressions. Personally, I'd rather have special syntax in the pattern (- pat) than have these global effects on what you can do with certain types. You can only declare the instance for TypView in the same module as TypView itself, since otherwise it would conflict with the implicit instance. Therefore, providing an instance is no more global than just renaming the type. Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Definition of the Haskell standard library
On 2007-07-30, Dave Bayer [EMAIL PROTECTED] wrote: My pet example is a PDF library. No language should have its own PDF library, when Postscript is so easy to write, and Ghostscript is a cross-platform conversion tool maintained by thousands of our best and brightest. Except, of course, that there are PDF features that are not easily used by converting from PostScript. And then there's reading and parsing PDF... -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Latest AngloHaskell news and a request
Two pieces of news regarding AngloHaskell: 1) We've been offered WiFi access at Microsoft Research for any attendees who want it. We'll need a name, email address and company/institution affiliation where appropriate - see wiki for details. 2) We're being given lunch on Friday! Finally, a request: We're a little short on crashspace, and I suspect this is affecting who's able to show up. Could people who can only make it with crashspace (or who can only make one day without) add their names on the wiki? Is there anyone in the area able to offer people at least some space on a floor? Last year we had offers early, and I think this helped get plans moving. For those who could use the reminder, the wiki page is at http://www.haskell.org/haskellwiki/AngloHaskell Many thanks, and I hope to see you there! -- [EMAIL PROTECTED] Society does not owe people jobs. Society owes it to itself to find people jobs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] infinite list of random elements
I'm trying to do something I thought would be pretty simple, but it's giving me trouble. Given a list, say [1,2,3], I'd like to be able to generate an infinite list of random elements from that list, in this case maybe [1,2,1,3,2,1,3,2,3,1,2,...]. I'm using IO for random purely due to laziness (my own, not Haskell's). I was thinking the best way to do this might be to first write this function: randomElts :: [a] - [IO a] randomElts [] = [] randomElts [x] = repeat (return x) randomElts xs = repeat r where bds = (1, length xs) xArr = listArray bds xs r = do i - randomRIO bds return (xArr ! i) Then I should be able to do this in ghci: sequence . take 5 $ randomElts [1,2,3] [*** Exception: stack overflow Any idea what's going on? I thought laziness (Haskell's, not my own) would save me on this one. Thanks! Chad ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] infinite list of random elements
On Mon, Jul 30, 2007 at 02:40:35PM -0700, Chad Scherrer wrote: I'm trying to do something I thought would be pretty simple, but it's giving me trouble. Given a list, say [1,2,3], I'd like to be able to generate an infinite list of random elements from that list, in this case maybe [1,2,1,3,2,1,3,2,3,1,2,...]. I'm using IO for random purely due to laziness (my own, not Haskell's). I was thinking the best way to do this might be to first write this function: randomElts :: [a] - [IO a] randomElts [] = [] randomElts [x] = repeat (return x) randomElts xs = repeat r where bds = (1, length xs) xArr = listArray bds xs r = do i - randomRIO bds return (xArr ! i) Then I should be able to do this in ghci: sequence . take 5 $ randomElts [1,2,3] [*** Exception: stack overflow Any idea what's going on? I thought laziness (Haskell's, not my own) would save me on this one. The code you posted works fine for me (GHCi 6.7.20070712). However, it's pretty bad style in a way that suggests a misunderstanding of IO. A value of type IO t is not a tainted t, it's an action that returns t. So, in general: do let xv = randomRIO (1,20) a - xv b - xv return (a == b) will normally return *False*. Why? Because, while the same action is used, it doesn't always return the same value! In general, when you see a type of the form [IO a] or Maybe (IO a) or IO a - b, ask yourself if that's what you really want. (Sometimes it is, and the flexibility of having IO anywhere is very powerful). A better way to write randomElts is: randomElt :: [a] - IO a randomElt xs = do ix - randomRIO bds return (arr ! i) where arr = listArray bds xs bds = (1, length xs) randomElts :: Int - [a] - IO [a] randomElts n xs = replicateM n (randomElt xs) -- uses replicateM from Control.Monad Sadly, it's very hard to just return an infinite list in IO. it can be done in dedicated monads, however. Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] infinite list of random elements
On 30/07/07, Chad Scherrer [EMAIL PROTECTED] wrote: I'm trying to do something I thought would be pretty simple, but it's giving me trouble. Given a list, say [1,2,3], I'd like to be able to generate an infinite list of random elements from that list, in this case maybe [1,2,1,3,2,1,3,2,3,1,2,...]. I'm using IO for random purely due to laziness (my own, not Haskell's). I was thinking the best way to do this might be to first write this function: randomElts :: [a] - [IO a] randomElts [] = [] randomElts [x] = repeat (return x) randomElts xs = repeat r where bds = (1, length xs) xArr = listArray bds xs r = do i - randomRIO bds return (xArr ! i) Then I should be able to do this in ghci: sequence . take 5 $ randomElts [1,2,3] [*** Exception: stack overflow Any idea what's going on? I thought laziness (Haskell's, not my own) would save me on this one. I don't get that result. However, you can't compute an infinite random list in IO without using something like unsafeInterleaveIO. However, you will probably be interested in randoms/randomRs, which take a random generator, and give an infinite list of results. Using that, we could write something like: randomElts :: [a] - IO [a] randomElts [] = return [] randomElts xs = do g - newStdGen return (map (xArr !) (randomRs bds g)) where bds = (1, length xs) xArr = listArray bds xs which for a nonempty input list, gives an infinite list of pseudorandom elements of that input list. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] infinite list of random elements
On Mon, Jul 30, 2007 at 02:40:35PM -0700, Chad Scherrer wrote: Given a list, say [1,2,3], I'd like to be able to generate an infinite list of random elements from that list, in this case maybe [1,2,1,3,2,1,3,2,3,1,2,...]. I'm using IO for random purely due to laziness (my own, not Haskell's). You can be even lazier and let the Random library do more of the work for you, seeing that it includes randomRs: randomElts rg xs = map (arr !) (randomRs bds rg) where bds = (1, length xs) arr = listArray bds xs Lauri ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] infinite list of random elements
Why this obsession with IO? There should be no IO involved in this, except for getting the initial generator. Using IO just confuses what is going on. -- Lennart On 7/30/07, Cale Gibbard [EMAIL PROTECTED] wrote: On 30/07/07, Chad Scherrer [EMAIL PROTECTED] wrote: I'm trying to do something I thought would be pretty simple, but it's giving me trouble. Given a list, say [1,2,3], I'd like to be able to generate an infinite list of random elements from that list, in this case maybe [1,2,1,3,2,1,3,2,3,1,2,...]. I'm using IO for random purely due to laziness (my own, not Haskell's). I was thinking the best way to do this might be to first write this function: randomElts :: [a] - [IO a] randomElts [] = [] randomElts [x] = repeat (return x) randomElts xs = repeat r where bds = (1, length xs) xArr = listArray bds xs r = do i - randomRIO bds return (xArr ! i) Then I should be able to do this in ghci: sequence . take 5 $ randomElts [1,2,3] [*** Exception: stack overflow Any idea what's going on? I thought laziness (Haskell's, not my own) would save me on this one. I don't get that result. However, you can't compute an infinite random list in IO without using something like unsafeInterleaveIO. However, you will probably be interested in randoms/randomRs, which take a random generator, and give an infinite list of results. Using that, we could write something like: randomElts :: [a] - IO [a] randomElts [] = return [] randomElts xs = do g - newStdGen return (map (xArr !) (randomRs bds g)) where bds = (1, length xs) xArr = listArray bds xs which for a nonempty input list, gives an infinite list of pseudorandom elements of that input list. - Cale ___ 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] infinite list of random elements
On 30/07/07, Lennart Augustsson [EMAIL PROTECTED] wrote: Why this obsession with IO? There should be no IO involved in this, except for getting the initial generator. Using IO just confuses what is going on. Indeed. Here's my version: -- first define a shuffle function, completely pure! pick 1 (x:xs) = (x, xs) pick n (x:xs) = (y, x:ys) where (y, ys) = pick (n-1) xs shuffle gen xs = shuffle' gen xs (length xs) shuffle' _ [] _ = [] shuffle' gen xs n = p : shuffle' gen' xs' (n-1) where (r, gen') = randomR (1,n) gen (p, xs') = pick r xs -- a function for giving us an infinite list of generators from -- an initial generator gens g = unfoldr (Just . split) g -- shuffles the given list an infinite number of times -- with a different generator each time shuffles xs g = zipWith shuffle (gens g) (repeat xs) You can then pass in whatever generator you wish to shuffles. E.g. create a pure one with mkStdGen or create one in the IO monad with newStdGen. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Code and Perf. Data for Prime Finders (was: Genuine Eratosthenes sieve)
Hello, On Wednesday 25 July 2007 01:42, Thorkil Naur wrote: Hello Melissa, On Tuesday 24 July 2007 19:09, Melissa O'Neill wrote: ... (See ONeillPrimes.hs in http://www.cs.hmc.edu/~oneill/code/haskell- primes.zip for the complete code. I've also added Thorkil Naur's code from March, which is also a good performer, Do you have detailed measurements that you wish to share? I would be most interested, I assure you. although its another case where most readers would find a detailed explanation of the code instructive.) I'll do my very best to provide such an explanation within, say, the next couple of weeks. ... And now that time has come, so brace yourselves. For your convenience, my code from March is thorkilnaur.dk/~tn/T64_20070303_1819.tar.gz See also a preliminary description in http://www.haskell.org/pipermail/haskell-cafe/2007-March/023095.html. The new explanation is here: thorkilnaur.dk/~tn/Haskell/EratoS/EratoS2.txt Best regards Thorkil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Constraing satisfaction
Hi. I have a set of problems in the field of constaint satisfaction and I'm looking for a tool for this. In simplest form, these task are like Sudoku puzzle solver, school schedule creator, etc. Prolog language comes to mind at first. But if to choose Haskell? Can be these tasks defined in Haskell with the same elegance as in Prolog, or I'll need some additional framework or library? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Constraing satisfaction
I have a set of problems in the field of constaint satisfaction and I'm looking for a tool for this. In simplest form, these task are like Sudoku puzzle solver, school schedule creator, etc. Prolog language comes to mind at first. Have you seen Eclipse? http://eclipse.crosscoreop.com/ - it looks perfect for the problems you are listing. Yes. It looks like further development of Prolog. You could do the same in a domain specific language in Haskell, but I'm not sure anyone has written one, so I'd recommend Eclipse. So, my question is not about language but about some constraint satisfaction engine? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Constraing satisfaction
Haskell is certainly up for the challenge. You may be interested in this paper, for example: http://citeseer.ist.psu.edu/335780.html On 7/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I have a set of problems in the field of constaint satisfaction and I'm looking for a tool for this. In simplest form, these task are like Sudoku puzzle solver, school schedule creator, etc. Prolog language comes to mind at first. Have you seen Eclipse? http://eclipse.crosscoreop.com/ - it looks perfect for the problems you are listing. Yes. It looks like further development of Prolog. You could do the same in a domain specific language in Haskell, but I'm not sure anyone has written one, so I'd recommend Eclipse. So, my question is not about language but about some constraint satisfaction engine? ___ 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] infinite list of random elements
Thanks for your responses. Stefan, I appreciate your taking a step back for me (hard to judge what level of understanding someone is coming from), but the example you gave doesn't contradict my intuition either. I don't consider the output [IO a] a list of tainted a's, but, as you suggest, a list of IO actions, each returning an a. I couldn't return an IO [a], since that would force evaluation of an infinite list of random values, so I was using [IO a] as an intermediary, assuming I'd be putting it through something like (sequence . take n) rather than sequence alone. Unfortunately, I can't use your idea of just selecting one, because I don't have any way of knowing in advance how many values I'll need (in my case, that depends on the results of several layers of Map.lookup). Also, I'm using GHC 6.6, so maybe there have been recent fixes that would now allow my idea to work. Cale, that's interesting. I wouldn't have thought this kind of laziness would work in this context. Lennart, I prefer the purely functional approach as well, but I've been bitten several times by laziness causing space leaks in this context. I'm on a bit of a time crunch for this, so I avoided the risk. Sebastian, this seems like a nice abstraction to me, but I don't think it's the same thing statistically. If I'm reading it right, this gives a concatenation of an infinite number of random shuffles of a sequence, rather than sampling with replacement for each value. So shuffles [1,2] g would never return [1,1,...], right? Chad I was thinking the best way to do this might be to first write this function: randomElts :: [a] - [IO a] randomElts [] = [] randomElts [x] = repeat (return x) randomElts xs = repeat r where bds = (1, length xs) xArr = listArray bds xs r = do i - randomRIO bds return (xArr ! i) Then I should be able to do this in ghci: sequence . take 5 $ randomElts [1,2,3] [*** Exception: stack overflow ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem building lambdabot
On Mon, Jul 30, 2007 at 06:57:25PM -0700, Michael Vanier wrote: When I try to build lambdabot, I get this: Configuring lambdabot-4.0... configure: Dependency base-any: using base-2.1.1 configure: Dependency unix-any: using unix-2.1 configure: Dependency network-any: using network-2.0.1 configure: Dependency parsec-any: using parsec-2.0 configure: Dependency mtl-any: using mtl-1.0.1 configure: Dependency haskell-src-any: using haskell-src-1.0.1 configure: Dependency readline-any: using readline-1.0 configure: Dependency QuickCheck-any: using QuickCheck-1.0.1 Setup.hs: cannot satisfy dependency arrows-any I'm using ghc 6.6.1 compiled from source (by me) on Debian Linux. I thought that arrows were included with the ghc distribution. Does anyone know what's happening and how to fix it? I don't know what's happening, but you can get arrows easily enough from http://hackage.haskell.org (our CPAN). Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem building lambdabot
Thanks, but this doesn't answer the question. I can load up the Control.Arrow module fine in ghci. Is there a problem with the packaging information? I did a google search, and this problem has come up on IRC, but nobody figured out what was causing it as far as I can tell. Mike Stefan O'Rear wrote: On Mon, Jul 30, 2007 at 06:57:25PM -0700, Michael Vanier wrote: When I try to build lambdabot, I get this: Configuring lambdabot-4.0... configure: Dependency base-any: using base-2.1.1 configure: Dependency unix-any: using unix-2.1 configure: Dependency network-any: using network-2.0.1 configure: Dependency parsec-any: using parsec-2.0 configure: Dependency mtl-any: using mtl-1.0.1 configure: Dependency haskell-src-any: using haskell-src-1.0.1 configure: Dependency readline-any: using readline-1.0 configure: Dependency QuickCheck-any: using QuickCheck-1.0.1 Setup.hs: cannot satisfy dependency arrows-any I'm using ghc 6.6.1 compiled from source (by me) on Debian Linux. I thought that arrows were included with the ghc distribution. Does anyone know what's happening and how to fix it? I don't know what's happening, but you can get arrows easily enough from http://hackage.haskell.org (our CPAN). Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem building lambdabot
mvanier: Thanks, but this doesn't answer the question. I can load up the Control.Arrow module fine in ghci. Is there a problem with the packaging information? It needs the 'arrows' package from hackage, not just Control.Arrow. You'll get by fine by just removing the 'arrows' dependency : its only needed if you wish to run arrows code in @eval -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem building lambdabot
OK, Stefan was right. The arrows package is an extension of Control.Arrow, not a from-scratch implementation. The name confused me. Perhaps a better name would be arrows-ext or something like that. Mike Michael Vanier wrote: Thanks, but this doesn't answer the question. I can load up the Control.Arrow module fine in ghci. Is there a problem with the packaging information? I did a google search, and this problem has come up on IRC, but nobody figured out what was causing it as far as I can tell. Mike Stefan O'Rear wrote: On Mon, Jul 30, 2007 at 06:57:25PM -0700, Michael Vanier wrote: When I try to build lambdabot, I get this: Configuring lambdabot-4.0... configure: Dependency base-any: using base-2.1.1 configure: Dependency unix-any: using unix-2.1 configure: Dependency network-any: using network-2.0.1 configure: Dependency parsec-any: using parsec-2.0 configure: Dependency mtl-any: using mtl-1.0.1 configure: Dependency haskell-src-any: using haskell-src-1.0.1 configure: Dependency readline-any: using readline-1.0 configure: Dependency QuickCheck-any: using QuickCheck-1.0.1 Setup.hs: cannot satisfy dependency arrows-any I'm using ghc 6.6.1 compiled from source (by me) on Debian Linux. I thought that arrows were included with the ghc distribution. Does anyone know what's happening and how to fix it? I don't know what's happening, but you can get arrows easily enough from http://hackage.haskell.org (our CPAN). Stefan ___ 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] problem building lambdabot
So, now that I've got all the libraries installed, the compile fails like this: Building lambdabot-4.0... [13 of 91] Compiling Lib.Parser ( Lib/Parser.hs, dist/build/lambdabot/lambdabot-tmp/Lib/Parser.o ) Lib/Parser.hs:19:39: Module `Language.Haskell.Syntax' does not export `as_name' Lib/Parser.hs:19:48: Module `Language.Haskell.Syntax' does not export `qualified_name' Lib/Parser.hs:19:64: Module `Language.Haskell.Syntax' does not export `hiding_name' Lib/Parser.hs:19:77: Module `Language.Haskell.Syntax' does not export `minus_name' Lib/Parser.hs:19:89: Module `Language.Haskell.Syntax' does not export `pling_name' I'm using the latest darcs pull of lambdabot along with ghc 6.6.1. Anyone have any ideas? Thanks in advance for all the help, Mike Michael Vanier wrote: OK, Stefan was right. The arrows package is an extension of Control.Arrow, not a from-scratch implementation. The name confused me. Perhaps a better name would be arrows-ext or something like that. Mike Michael Vanier wrote: Thanks, but this doesn't answer the question. I can load up the Control.Arrow module fine in ghci. Is there a problem with the packaging information? I did a google search, and this problem has come up on IRC, but nobody figured out what was causing it as far as I can tell. Mike Stefan O'Rear wrote: On Mon, Jul 30, 2007 at 06:57:25PM -0700, Michael Vanier wrote: When I try to build lambdabot, I get this: Configuring lambdabot-4.0... configure: Dependency base-any: using base-2.1.1 configure: Dependency unix-any: using unix-2.1 configure: Dependency network-any: using network-2.0.1 configure: Dependency parsec-any: using parsec-2.0 configure: Dependency mtl-any: using mtl-1.0.1 configure: Dependency haskell-src-any: using haskell-src-1.0.1 configure: Dependency readline-any: using readline-1.0 configure: Dependency QuickCheck-any: using QuickCheck-1.0.1 Setup.hs: cannot satisfy dependency arrows-any I'm using ghc 6.6.1 compiled from source (by me) on Debian Linux. I thought that arrows were included with the ghc distribution. Does anyone know what's happening and how to fix it? I don't know what's happening, but you can get arrows easily enough from http://hackage.haskell.org (our CPAN). Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem building lambdabot
On Mon, Jul 30, 2007 at 08:54:12PM -0700, Michael Vanier wrote: So, now that I've got all the libraries installed, the compile fails like this: Building lambdabot-4.0... [13 of 91] Compiling Lib.Parser ( Lib/Parser.hs, dist/build/lambdabot/lambdabot-tmp/Lib/Parser.o ) Lib/Parser.hs:19:39: Module `Language.Haskell.Syntax' does not export `as_name' Lib/Parser.hs:19:48: Module `Language.Haskell.Syntax' does not export `qualified_name' Lib/Parser.hs:19:64: Module `Language.Haskell.Syntax' does not export `hiding_name' Lib/Parser.hs:19:77: Module `Language.Haskell.Syntax' does not export `minus_name' Lib/Parser.hs:19:89: Module `Language.Haskell.Syntax' does not export `pling_name' I'm using the latest darcs pull of lambdabot along with ghc 6.6.1. Anyone have any ideas? Thanks in advance for all the help, Mike Lambdabot is incompatible with GHC 6.6.1, because of changes in undocumented internal modules that lambdabot really shouldn't be importing in the first place. I had an idea for how to avoid the nasty dependency a few days ago, *tries to implement it*. Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] curious hxt error
i am having a problem with hxt, i was wondering if anyone here has experience with it. in particular, i find that the xread function chokes on xml files with xml declarations, and i am not sure why. consider this sample script: module Main where import Text.XML.HXT.Parser main = do xml - getContents print $ head $ xread xml and this file content (test.xml): ?xml version=1.0? foobarBAR1/barbarBAR2/bar/foo running: $ runhaskell hxt.hs test.xml NTree (XError 2 \string: \?xml version=\\\1.0\\\?\\nfoobarBAR1/ba...\\ (line 1, column 6):\nunexpected xml\nexpecting legal XML name character\n) [] which clearly indicates a choke on the xml declaration but if i remove the xml declaration, i see no errors and i am able to get a valid data structure printing out any ideas? thanks brad ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
