RE: [Haskell-cafe] Equality constraints in type families
| * GHC says that these constraints must be obeyed only | *after* the programmer-written type has been normalised | by expanding saturated type synonyms | ... | I regard this as a kind of pre-pass, before serious type checking | takes place, so I don't think it should interact with type checking | at all. | | I don't think this normalisation should include type families, | although H98 type synonyms are a kind of degenerate case of type | families. | | Would that design resolve this particular issue? | | Not quite, but it refines my proposal of requiring that type synonyms | in the rhs of type instances need to be saturated. Let me elaborate. Why not quite? | So, the crucial point is that, as you wrote, | | I don't think this normalisation should include type families, | although H98 type synonyms are a kind of degenerate case of type | families. Exactly! Just to state it more clearly again: Any programmer-written type (i.e one forming part of the source text of the program) must obey the following rules: - well-kinded - type synonyms saturated - arguments of type applications are monotypes (but - is special) However these rules are checked ONLY AFTER EXPANDING SATURATE TYPE SYNONYMS (but doing no reduction on type families) OK, let's try the examples Manuel suggests: | The current implementation is wrong, as it permits | |type S a b = a |type family F a :: * - * |type instance F a = S a This is illegal because a programmer-written type (the (S a) on the rhs) is an unsaturated type synonym. |type S a b = a |type family F (a :: * - *) b :: * - * |type instance F a b = S (S a) b b This is legal because the programmer-written type (S (S a) b b) can be simplified to 'a' by expanding type synonyms. The above checks are performed by checkValidType in TcMType. In particular, the check for saturated synonyms is in check_type (line 1134 or thereabouts). I'm not sure why these checks are not firing for the RHS of a type family declaration. Maybe we aren't calling checkValidType on it. So I think we are agreed. I think the above statement of validity should probably appear in the user manual. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Equality constraints in type families
Hugo Pacheco: Since I was the one to start this thread, I have managed to implement what I initially wanted as F a :: *-* with F a x::*, and the cost of not having partially applied type synonyms was not much apart from some more equality coercions that I wasn't expecting. [..] Generally, I love type-indexed types. Glad to hear that! Manuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Equality constraints in type families
Well, we still need normal subject reduction (i.e., types don't change under value term reduction), and we have established that for System FC (in the TLDI paper). In addition, type term normalisation (much like value term normalisation) needs to be confluent; otherwise, you won't get a complete type inference/checking algorithm. if you have separate rules for generating constraints (decomposition) and type term normalisation, that also needs to include confluence of the combined system, which was the issue here, i believe. as far as i could determine, the TLDI paper does not deal with the full generality of ghc's type extensions, so it doesn't stumble over this issue, and might need elaboration. System FC as described in the paper is GHC's current Core language. What are you missing? for now, interaction with pre-Core features, such as generalised type synonyms?-) i just tend to program in ghc Front, not ghc Core;-) later, there'll be other fun, eg, my extensible record code depends on ghc's particular interpretation of the interaction between FDs and overlap resolution, much of Oleg's code depends on a trick that he has isolated in a small group of type equality predicates, carefully exploiting ghc's ideosynchrasies. neither his nor my code works in hugs, even though we nominally use language features supported by both ghc and hugs, even originating in hugs. probably, closed type families can provide better answers to these issues, but until they are here, and their interaction with other ghc type system features has been studied, the idea of mapping FDs to type families has to be taken with a grain of salt, i guess. as with FDs, it isn't a single feature that causes trouble, it is the interaction of many features, combined with real-life programs that stretch the language boundaries they run into. I don't think we can avoid losing that expressiveness, as you demonstrated that it leads to non-confluence of type term normalisation - see also my reply to SimonPJ's message in this thread. i know that we sometimes have to give up features that look nice but have hidden traps - that doesn't mean i have to like it, though!-) Haskell always had the decomposition rule. Maybe we confused the matter, by always showing a particular instance of the decomposition rule, rather than the general rule. Here it is in all it's glory: t1 t2 ~ t1' t2' == t1 ~ t1', t2 ~ t2' No mention of a type family. However, the rule obviously still needs to be correct if we allow any of the type terms (including t1 and t1') to include *saturated* applications of type families. before type families, t1 and t1' were straightforward type constructors (unless you include type synonyms, for which the decomposition doesn't apply). with type families, either may be a type-level function, and suddenly it looks as if you are matching on a function application. compare the expression-level: f (Just x) = x -- ok, because 'Just x' is irreducible g (f x) = x -- oops? so what i was missing was that you had arranged matters to exclude some problematic cases from that decomposition rule: - partially applied type synonyms (implicitly, by working in core) - partially applied (in terms of type indices) type families (by a side condition not directly visible in the rule system) in other words, the rule looks too general for what you had in mind, not too specific!-) claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HDBC, character encoding
Hi, I wrote a CGI program to access a Postgres database using HDBC. The database stores books and I want to display those from a certain author. Everything works fine, unless I search for someone with an umlaut in his name. Böll, for example. I have a function like this bookByAuthor :: Connection - AutorName - IO [[String]] bookByAuthor c aName = do writeFile ./err.log ((show aName)++ ++(show $ toSql aName)) rows - quickQuery c SELECT * FROM buecher WHERE lower (autor_name) LIKE ? ORDER BY autor_name, buch_name [toSql $ map toLower $ '%':aName++%] return $ map (map fromSql) rows It returns me a SqlError. However, doing the same in ghci works perfectly. I can't understand why. err.log contains b\195\182ll SqlString b\195\182ll which is ok I think. Since quickQuery c SELECT * FROM buecher WHERE lower(autor_name) LIKE ? ORDER BY autor_name, buch_name [toSql %b\195\182%] works in ghci. I have tried b\246ll, but that doesn't even work in ghci, although the database-encoding is utf-8. This all is really annoying... Adrian PGP.sig Description: Signierter Teil der Nachricht ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Equality constraints in type families
Simon Peyton-Jones: | * GHC says that these constraints must be obeyed only | *after* the programmer-written type has been normalised | by expanding saturated type synonyms | ... | I regard this as a kind of pre-pass, before serious type checking | takes place, so I don't think it should interact with type checking | at all. | | I don't think this normalisation should include type families, | although H98 type synonyms are a kind of degenerate case of type | families. | | Would that design resolve this particular issue? | | Not quite, but it refines my proposal of requiring that type synonyms | in the rhs of type instances need to be saturated. Let me elaborate. Why not quite? Maybe I was thinking too much in terms of GHC's implementation, but due to the lazy expansion type synonyms, the expansion is interleaved with all the rest of type checking. But I think I now know what you meant: the outcome should be *as if* type synonym expansion was done as a pre-pass. | So, the crucial point is that, as you wrote, | | I don't think this normalisation should include type families, | although H98 type synonyms are a kind of degenerate case of type | families. Exactly! Just to state it more clearly again: Any programmer-written type (i.e one forming part of the source text of the program) must obey the following rules: - well-kinded - type synonyms saturated - arguments of type applications are monotypes (but - is special) However these rules are checked ONLY AFTER EXPANDING SATURATE TYPE SYNONYMS (but doing no reduction on type families) I agree. The above checks are performed by checkValidType in TcMType. In particular, the check for saturated synonyms is in check_type (line 1134 or thereabouts). I'm not sure why these checks are not firing for the RHS of a type family declaration. Maybe we aren't calling checkValidType on it. I'll check that. Might be an oversight. So I think we are agreed. I think the above statement of validity should probably appear in the user manual. Yes, I'll take care of that. Manuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] No newlines in the whitespace for Parsec lexeme parsers
Hi, I'm looking to parse a Fortran dialect using Parsec, and was hoping to use the ParsecToken module. Fortran though is unlike the Parsec examples, and prohibits default line continuation (requiring instead an explicit ampersand token ). The lexical parsers of the ParsecToken module skip whitespace after each symbol parsed (lexeme parsers); including the newline. I was thinking of making a minor change to Parsec: In Token.hs, lexeme, whiteSpace, and simpleSpace are defined. lexeme uses whiteSpace which uses simpleSpace. simpleSpace is defined: simpleSpace = skipMany1 (satisfy isSpace) I could replace this locally with: simpleSpace = skipMany1 (satisfy isSpacePlusAmpersandMinusNewline) This approach may have other problems though. Has anyone experience of using Parsec to parse such a language? For example assembly or a preprocessor? Thanks in advance, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No newlines in the whitespace for Parsec lexeme parsers
Hello Paul, Wednesday, March 26, 2008, 2:32:53 PM, you wrote: I'm looking to parse a Fortran dialect using Parsec, and was afair, some months ago BASIC parsing was discussed here. the first solution one can imagine is to add preprocessing stage replacing line ends with ';'-alike -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Equality constraints in type families
| Why not quite? | | Maybe I was thinking too much in terms of GHC's implementation, but | due to the lazy expansion type synonyms, the expansion is interleaved | with all the rest of type checking. But I think I now know what you | meant: the outcome should be *as if* type synonym expansion was done | as a pre-pass. Well, validity checking is done when (and only when) converting an HsType to a Type. (The former being a programmer written type.) That's just what we want. It's done by checkValidType, which is not at all interleaved. Once that check is done, the lazy expansion can, I think, be left to itself; no further checking is required. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No newlines in the whitespace for Parsec lexeme parsers
Paul Keir wrote: Hi, I'm looking to parse a Fortran dialect using Parsec, and was hoping to use the ParsecToken module. Fortran though is unlike the Parsec examples, and prohibits default line continuation (requiring instead an explicit ampersand token ). The lexical parsers of the ParsecToken module skip whitespace after each symbol parsed (lexeme parsers); including the newline. If you mean Text.ParserCombinators.Parsec.Token, can't you just change the setting of whiteSpace in TokenParser? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No newlines in the whitespace for Parsec lexeme parsers
On Mar 26, 2008, at 7:42 , Bulat Ziganshin wrote: Wednesday, March 26, 2008, 2:32:53 PM, you wrote: I'm looking to parse a Fortran dialect using Parsec, and was afair, some months ago BASIC parsing was discussed here. the first solution one can imagine is to add preprocessing stage replacing line ends with ';'-alike FWIW I just ignored the lexeme parser and did my own on top of the basic Parsec primitives. You may need to do that anyway if you want to support older variants of Fortran, which don't actually have keywords and ignore spaces outside of string constants (Hollerith constants) --- Parsec's lexeme stuff doesn't even pretend to support this. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Unboxed arrays
Somebody asked me, so now I'm asking you... In Haskell, you can make unboxed arrays of certain value types. These are typically more efficient in space, and probably time too, and also make the array strict in its values. However, you can only do this magic trick for certain types - not for *all* types. Why is that? Is it because nobody has done anything about it yet? Is it because it's thought to be not necessary in some way? Is there some theoretical problem? Has somebody got a better idea? I did think it was along the lines of oh, well, if you want to unbox a type of your own, you just need to write your own instance. The thing that makes me suspicious of this logic is the absense of an instance for tuples. Surely this would be trivial to write, and yet it's not present. If we had instances for a couple of sizes of tuples, it would surely be quite easy to write your own custom instances that just sit on top of this and tuple/untuple your custom values... Any insights here? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unboxed arrays
Hello Andrew,
Wednesday, March 26, 2008, 3:37:53 PM, you wrote:
type of your own, you just need to write your own instance. The thing
that makes me suspicious of this logic is the absense of an instance for
tuples.
Any insights here?
and even insiders :) i've rewrote arrays library to be more uniform
using ideas of Simon Marlow and Oleg Kiselyov
unboxed arrays implementation uses GHC primitives that fetches/stores
array element by its index. these primitives implemented for simple
types - from Word8 to Double but nothing more. they use *indexes*, not
*byte offsets* which means that you can use them for addressing array
of {Word8,Double}, for example
i believe that it should be possible to rewrite array machinery using
storable class (now it should not have any overheads compared to these
primitives). meanwhile i recommend you to use storable array together
with Storable instances for tuples
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unboxed arrays
* Andrew Coppin [EMAIL PROTECTED] [2008-03-26 12:37:53+] Somebody asked me, so now I'm asking you... In Haskell, you can make unboxed arrays of certain value types. These are typically more efficient in space, and probably time too, and also make the array strict in its values. However, you can only do this magic trick for certain types - not for *all* types. Why is that? Is it because nobody has done anything about it yet? Is it because it's thought to be not necessary in some way? Is there some theoretical problem? Has somebody got a better idea? I did think it was along the lines of oh, well, if you want to unbox a type of your own, you just need to write your own instance. The thing that makes me suspicious of this logic is the absense of an instance for tuples. Surely this would be trivial to write, and yet it's not present. If we had instances for a couple of sizes of tuples, it would surely be quite easy to write your own custom instances that just sit on top of this and tuple/untuple your custom values... Any insights here? Could Data Parallel Haskell[1] be useful for you? It was designed for parallel computation, but it includes unboxed arrays, nice list-like syntax and array comprehensions. 1. http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell -- Roman I. Cheplyaka :: http://ro-che.info/ ...being in love is totally punk rock... signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unboxed arrays
On Wed, 26 Mar 2008, Roman Cheplyaka wrote: * Andrew Coppin [EMAIL PROTECTED] [2008-03-26 12:37:53+] Somebody asked me, so now I'm asking you... In Haskell, you can make unboxed arrays of certain value types. These are typically more efficient in space, and probably time too, and also make the array strict in its values. However, you can only do this magic trick for certain types - not for *all* types. Why is that? Is it because nobody has done anything about it yet? Is it because it's thought to be not necessary in some way? Is there some theoretical problem? Has somebody got a better idea? I did think it was along the lines of oh, well, if you want to unbox a type of your own, you just need to write your own instance. The thing that makes me suspicious of this logic is the absense of an instance for tuples. Surely this would be trivial to write, and yet it's not present. If we had instances for a couple of sizes of tuples, it would surely be quite easy to write your own custom instances that just sit on top of this and tuple/untuple your custom values... Any insights here? Could Data Parallel Haskell[1] be useful for you? It was designed for parallel computation, but it includes unboxed arrays, nice list-like syntax and array comprehensions. 1. http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell A light-weight unboxed array variant is: http://code.haskell.org/~sjanssen/storablevector/ I thought it might be more efficient sometimes to split, say Word8 and Double data into two arrays, instead of padding data in order to align a (Word8,Double) record, but this wouldn't fit into the array data structure. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unboxed arrays
Roman Cheplyaka wrote: * Andrew Coppin [EMAIL PROTECTED] [2008-03-26 12:37:53+] Any insights here? Could Data Parallel Haskell[1] be useful for you? It was designed for parallel computation, but it includes unboxed arrays, nice list-like syntax and array comprehensions. 1. http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell Mmm, maybe. Does it implement unboxed arrays for arbitrary types? For that matter, it seems like this NDP stuff has been in development for a seemingly long time now. Does anybody know what the current status is? (I'm guessing the people working on this are more interested in working on it than documenting every step of their progress... which leaves outsiders with the impression that nothing is happening.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unboxed arrays
Andrew Coppin wrote: Roman Cheplyaka wrote: * Andrew Coppin [EMAIL PROTECTED] [2008-03-26 12:37:53+] Any insights here? Could Data Parallel Haskell[1] be useful for you? It was designed for parallel computation, but it includes unboxed arrays, nice list-like syntax and array comprehensions. 1. http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell Mmm, maybe. Does it implement unboxed arrays for arbitrary types? For that matter, it seems like this NDP stuff has been in development for a seemingly long time now. Does anybody know what the current status is? Google - http://research.microsoft.com/~simonpj/papers/ndp/ (I'm guessing the people working on this are more interested in working on it than documenting every step of their progress... which leaves outsiders with the impression that nothing is happening.) I don't think the above suggests that nothing is happening ... -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unboxed arrays
Janis Voigtlaender wrote: Google - http://research.microsoft.com/~simonpj/papers/ndp/ I don't think the above suggests that nothing is happening ... The latet thing on that page is dated over a year ago. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unboxed arrays
Andrew Coppin wrote: Janis Voigtlaender wrote: Google - http://research.microsoft.com/~simonpj/papers/ndp/ I don't think the above suggests that nothing is happening ... The latet thing on that page is dated over a year ago. Well, if you expect monthly updates... -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [GSoC] student applications deadline approaching
Reply-To: haskell-cafe@haskell.org Just to remind students who are interested in Google Summer of Code. Student applications are now open, and the final deadline for submitting your proposals is 2400 UTC, 31st March. http://code.google.com/soc/2008/ Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unboxed arrays
* Henning Thielemann [EMAIL PROTECTED] [2008-03-26 14:22:20+0100] On Wed, 26 Mar 2008, Roman Cheplyaka wrote: * Andrew Coppin [EMAIL PROTECTED] [2008-03-26 12:37:53+] Somebody asked me, so now I'm asking you... In Haskell, you can make unboxed arrays of certain value types. These are typically more efficient in space, and probably time too, and also make the array strict in its values. However, you can only do this magic trick for certain types - not for *all* types. Why is that? Is it because nobody has done anything about it yet? Is it because it's thought to be not necessary in some way? Is there some theoretical problem? Has somebody got a better idea? I did think it was along the lines of oh, well, if you want to unbox a type of your own, you just need to write your own instance. The thing that makes me suspicious of this logic is the absense of an instance for tuples. Surely this would be trivial to write, and yet it's not present. If we had instances for a couple of sizes of tuples, it would surely be quite easy to write your own custom instances that just sit on top of this and tuple/untuple your custom values... Any insights here? Could Data Parallel Haskell[1] be useful for you? It was designed for parallel computation, but it includes unboxed arrays, nice list-like syntax and array comprehensions. 1. http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell A light-weight unboxed array variant is: http://code.haskell.org/~sjanssen/storablevector/ I thought it might be more efficient sometimes to split, say Word8 and Double data into two arrays, instead of padding data in order to align a (Word8,Double) record, but this wouldn't fit into the array data structure. As far as I know, ndp (which I linked above) takes exactly this approach. -- Roman I. Cheplyaka :: http://ro-che.info/ ...being in love is totally punk rock... signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type synonyms
Hi guys, There is something I think not to fully understand: what are the differences between these two type synonyms? type FInt x = Either One x type FInt = Either One Their kind is the same, so do they differ or are exactly the same type? Thanks, hugo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type synonyms
On Wednesday 26 March 2008, Hugo Pacheco wrote: Hi guys, There is something I think not to fully understand: what are the differences between these two type synonyms? type FInt x = Either One x type FInt = Either One Their kind is the same, so do they differ or are exactly the same type? The difference comes in that type synonyms must be fully applied to all the type parameters listed in their declaration. So, for instance, with the second, you could declare (with a type synonym instances extension), say: instance Monad FInt where ... But you could not with the first, because FInt would be partially applied; the first needs to always appear as 'FInt x' for some x. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unboxed arrays
On Wed 2008-03-26 14:22, Henning Thielemann wrote: A light-weight unboxed array variant is: http://code.haskell.org/~sjanssen/storablevector/ There is also CArray which offers an immutable interface for any Storable. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/carray You can also do unsafe (no-copy) freeze/thaw to IOCArray which is equivalent to StorableArray. Unfortunately there is a performance hit to using Storable versus the built in unboxed types. On the other hand, CArray is binary compatible with C which is handy if you are making foreign calls. I thought it might be more efficient sometimes to split, say Word8 and Double data into two arrays, instead of padding data in order to align a (Word8,Double) record, but this wouldn't fit into the array data structure. This depends on the access pattern, but if it makes you miss the cache frequently, then it is certainly not the way to go. For split storage to win, you must frequently traverse while only referencing one entry. It is not clear (to me) how to make an interface where the split storage is hidden, but the compiler can still remove all references to the unused part (without boxing which defeats the purpose). Jed pgpsQTUt7ru5r.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Unboxed arrays
Hello Jed, Wednesday, March 26, 2008, 7:02:28 PM, you wrote: StorableArray. Unfortunately there is a performance hit to using Storable versus the built in unboxed types. are you sure? it was in ghc 6.4, now afair they should be the same. look in http://haskell.org/haskellwiki/Modern_array_libraries -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unboxed arrays
On Wed 2008-03-26 19:50, Bulat Ziganshin wrote: Hello Jed, Wednesday, March 26, 2008, 7:02:28 PM, you wrote: StorableArray. Unfortunately there is a performance hit to using Storable versus the built in unboxed types. are you sure? it was in ghc 6.4, now afair they should be the same. look in http://haskell.org/haskellwiki/Modern_array_libraries The comparison I'm referring to is a micro-benchmark taken from the shootout. I modified the nsieve-bits code here: http://shootout.alioth.debian.org/gp4/benchmark.php?test=nsievebitslang=ghcid=0 The shootout code uses STUArray, one modification uses IOCArray, another uses StorableArray (which should be equivalent to IOCArray). Here are some timing results with ghc-6.8.2 on x86_64. $ for e in nsU nsC nsS; do time ./$e 12 /dev/null; done 1.087 real 1.087 user 0.000 sys 99.96 cpu 3.454 real 3.326 user 0.127 sys 99.98 cpu 3.448 real 3.343 user 0.103 sys 99.94 cpu With ghc-6.8.2 on x86, I get $ for e in nsU nsC nsS; do time ./$e 12 /dev/null; done ./nsU 124.57 real 4.45 user 0.01 sys ./nsC 1210.46 real 9.88 user 0.27 sys ./nsS 1210.59 real 9.86 user 0.24 sys That is, the STUArray version (nsU) is much faster than IOCArray (nsC) and StorableArray (nsS) for this test. To see for yourself, checkout CArray darcs get http://code.haskell.org/carray build it, then see the script in tests/runtests.sh. It will build an run these benchmarks, confirming that the output is the same and providing timing information. I would love to see this discrepancy go away, but sadly, it is not there yet. Jed pgprbNe5PRMWN.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HDBC, character encoding
aneumann: Hi, I wrote a CGI program to access a Postgres database using HDBC. The database stores books and I want to display those from a certain author. Everything works fine, unless I search for someone with an umlaut in his name. Böll, for example. I have a function like this bookByAuthor :: Connection - AutorName - IO [[String]] bookByAuthor c aName = do writeFile ./err.log ((show aName)++ ++(show $ toSql aName)) rows - quickQuery c SELECT * FROM buecher WHERE lower (autor_name) LIKE ? ORDER BY autor_name, buch_name [toSql $ map toLower $ '%':aName++%] return $ map (map fromSql) rows It returns me a SqlError. However, doing the same in ghci works perfectly. I can't understand why. err.log contains b\195\182ll SqlString b\195\182ll which is ok I think. Since quickQuery c SELECT * FROM buecher WHERE lower(autor_name) LIKE ? ORDER BY autor_name, buch_name [toSql %b\195\182%] works in ghci. I have tried b\246ll, but that doesn't even work in ghci, although the database-encoding is utf-8. This all is really annoying... Are you using the utf8-string package for necessary IO ? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Wumpus World
Hi guys I have to build the wumpus world problem. I didn't start yet since this is the first time in my life I have to do something like that and I feel not confident in starting it. So I have basic idea of what prolog and haskell can do and I know a bit of Java. I am wandering if you can tell me which one is best to use to build this problem.Thanks couse I am really confused -- View this message in context: http://www.nabble.com/Wumpus-World-tp16310198p16310198.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] Unboxed arrays
andrewcoppin: Janis Voigtlaender wrote: Google - http://research.microsoft.com/~simonpj/papers/ndp/ I don't think the above suggests that nothing is happening ... The latet thing on that page is dated over a year ago. It's very active. See: http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell and watch the commits coming in from Roman. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unboxed arrays
Don Stewart wrote: It's very active. See: http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell and watch the commits coming in from Roman. *digs around* Hmm. So in summary, stuff is happening behind the scenes, there's just not a lot of visible activity at the surface. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] announce: Glome.hs raytracer
I have recently posted a haskell port of my ocaml raytracer, Glome: http://syn.cs.pdx.edu/~jsnow/glome/ It supports spheres and triangles as base primitives, and is able to parse files in the NFF format used by the standard procedural database (http://tog.acm.org/resources/SPD/). It uses a bounding interval heirarchy acceleration structure, so it can render fairly complicated scenes in a reasonable amount of time. Shadows and reflections are supported, but not specular highlights or refraction. It's still slower than the ocaml version, but at least they're in the same ballpark (and a good part of that difference may be inefficiencies in my BIH traversal). I would welcome any advice on making it go faster or use less memory. I compile the program with ghc Glome.hs --make -fasm -O2 -threaded -fglasgow-exts -funbox-strict-fields -fbang-patterns -fexcess-precision -optc-ffast-math -optc-O2 -optc-mfpmath=sse -optc-msse2. (I assume the -optc options don't do anything unless you compile via C.) Here are some of my current concerns: -Multi-core parallelism is working, but not as well as I'd expect: I get about a 25% reduction in runtime on two cores rather than 50%. I split the default screen size of 512x512 into 16 blocks, and run parMap on those blocks with a function that turns the screen coordinates of that block into a list of (x,y,r,g,b) tuples that get drawn as pixels to the screen through OpenGL by the original thread. -Memory consumption is atrocious: 146 megs to render a scene that's a 33k ascii file. Where does it all go? A heap profile reports the max heap size at a rather more reasonable 500k or so. (My architecture is 64 bit ubuntu on a dual-core amd.) -Collecting rendering stats is not easy without global variables. It occurs to me that it would be neat if there were some sort of write-only global variables that can be incremented by pure code but can only be read from within monadic code; that would be sufficient to ensure that the pure code wasn't affected by the values. The sorts of things I'm looking for are the number of calls to trace per image, the number of BIH branches traversed and ray/triangle and ray/sphere intersections per pixel. (Disclaimer: I don't really fully understand monads, so I may be oblivious to an obvious solution.) -Is there a fast way to cast between Float and Double? I'm using Float currently, and the only reason is because that's what the OpenGL api expects. I'd like to be able to use either representation, but the only way to cast that I've found so far is float_conv x = fromRational(toRational x), which is too slow. thanks, -jim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] announce: Glome.hs raytracer
jsnow: I have recently posted a haskell port of my ocaml raytracer, Glome: http://syn.cs.pdx.edu/~jsnow/glome/ It supports spheres and triangles as base primitives, and is able to parse files in the NFF format used by the standard procedural database (http://tog.acm.org/resources/SPD/). It uses a bounding interval heirarchy acceleration structure, so it can render fairly complicated scenes in a reasonable amount of time. Shadows and reflections are supported, but not specular highlights or refraction. It's still slower than the ocaml version, but at least they're in the same ballpark (and a good part of that difference may be inefficiencies in my BIH traversal). I would welcome any advice on making it go faster or use less memory. I compile the program with ghc Glome.hs --make -fasm -O2 -threaded -fglasgow-exts -funbox-strict-fields -fbang-patterns -fexcess-precision -optc-ffast-math -optc-O2 -optc-mfpmath=sse -optc-msse2. (I assume the -optc options don't do anything unless you compile via C.) Here are some of my current concerns: -Multi-core parallelism is working, but not as well as I'd expect: I get about a 25% reduction in runtime on two cores rather than 50%. I split the default screen size of 512x512 into 16 blocks, and run parMap on those blocks with a function that turns the screen coordinates of that block into a list of (x,y,r,g,b) tuples that get drawn as pixels to the screen through OpenGL by the original thread. -Memory consumption is atrocious: 146 megs to render a scene that's a 33k ascii file. Where does it all go? A heap profile reports the max heap size at a rather more reasonable 500k or so. (My architecture is 64 bit ubuntu on a dual-core amd.) -Collecting rendering stats is not easy without global variables. It occurs to me that it would be neat if there were some sort of write-only global variables that can be incremented by pure code but can only be read from within monadic code; that would be sufficient to ensure that the pure code wasn't affected by the values. The sorts of things I'm looking for are the number of calls to trace per image, the number of BIH branches traversed and ray/triangle and ray/sphere intersections per pixel. (Disclaimer: I don't really fully understand monads, so I may be oblivious to an obvious solution.) Use a Writer monad to log statistics? Maybe a State monad. -Is there a fast way to cast between Float and Double? I'm using Float currently, and the only reason is because that's what the OpenGL api expects. I'd like to be able to use either representation, but the only way to cast that I've found so far is float_conv x = fromRational(toRational x), which is too slow. I'd try realToFrac, which should be pretty much optimised away. With doubles, ensure you use -fexcess-precision -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] announce: Glome.hs raytracer
On Wed, 26 Mar 2008, Don Stewart wrote: jsnow: -Is there a fast way to cast between Float and Double? I'm using Float currently, and the only reason is because that's what the OpenGL api expects. I'd like to be able to use either representation, but the only way to cast that I've found so far is float_conv x = fromRational(toRational x), which is too slow. I'd try realToFrac, which should be pretty much optimised away. http://haskell.org/haskellwiki/Converting_numbers ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] announce: Glome.hs raytracer
On Wed, Mar 26, 2008 at 2:33 PM, Jim Snow [EMAIL PROTECTED] wrote: -Memory consumption is atrocious: 146 megs to render a scene that's a 33k ascii file. Where does it all go? A heap profile reports the max heap size at a rather more reasonable 500k or so. (My architecture is 64 bit ubuntu on a dual-core amd.) Try retainer profiling to see who's holding on to memory. To track down a suspect, add SCC annotations and filter the retainer profile to just those annotations (-hC option). Heap profiling is documented at http://haskell.org/ghc/docs/latest/html/users_guide/prof-heap.html Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] announce: Glome.hs raytracer
Hello Jim, Thursday, March 27, 2008, 12:33:20 AM, you wrote: -Multi-core parallelism is working, but not as well as I'd expect: I get about a 25% reduction in runtime on two cores rather than 50%. I split this may be an effect of limited memory bandwidth -Memory consumption is atrocious: 146 megs to render a scene that's a standard answer: ByteString -Collecting rendering stats is not easy without global variables. It occurs to me that it would be neat if there were some sort of write-only global variables that can be incremented by pure code but can only be read from within monadic code; that would be sufficient to ensure that the pure code wasn't affected by the values. the code is called *pure* exactly because it has no side-effects and compiler may select either to call some function two times or reuse already computed result. actually, you can make sideeffects with unsafePerformIO, but there is no guarantees of how many times such code will be executed. try this: plus a b = unsafePerformIO (modifyIORef counter (+1)) `seq` a+b -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] announce: Glome.hs raytracer
On Wed, 2008-03-26 at 14:45 -0700, Don Stewart wrote: jsnow: I have recently posted a haskell port of my ocaml raytracer, Glome: http://syn.cs.pdx.edu/~jsnow/glome/ It supports spheres and triangles as base primitives, and is able to parse files in the NFF format used by the standard procedural database (http://tog.acm.org/resources/SPD/). It uses a bounding interval heirarchy acceleration structure, so it can render fairly complicated scenes in a reasonable amount of time. Shadows and reflections are supported, but not specular highlights or refraction. It's still slower than the ocaml version, but at least they're in the same ballpark (and a good part of that difference may be inefficiencies in my BIH traversal). I would welcome any advice on making it go faster or use less memory. I compile the program with ghc Glome.hs --make -fasm -O2 -threaded -fglasgow-exts -funbox-strict-fields -fbang-patterns -fexcess-precision -optc-ffast-math -optc-O2 -optc-mfpmath=sse -optc-msse2. (I assume the -optc options don't do anything unless you compile via C.) Here are some of my current concerns: -Multi-core parallelism is working, but not as well as I'd expect: I get about a 25% reduction in runtime on two cores rather than 50%. I split the default screen size of 512x512 into 16 blocks, and run parMap on those blocks with a function that turns the screen coordinates of that block into a list of (x,y,r,g,b) tuples that get drawn as pixels to the screen through OpenGL by the original thread. -Memory consumption is atrocious: 146 megs to render a scene that's a 33k ascii file. Where does it all go? A heap profile reports the max heap size at a rather more reasonable 500k or so. (My architecture is 64 bit ubuntu on a dual-core amd.) -Collecting rendering stats is not easy without global variables. It occurs to me that it would be neat if there were some sort of write-only global variables that can be incremented by pure code but can only be read from within monadic code; that would be sufficient to ensure that the pure code wasn't affected by the values. The sorts of things I'm looking for are the number of calls to trace per image, the number of BIH branches traversed and ray/triangle and ray/sphere intersections per pixel. (Disclaimer: I don't really fully understand monads, so I may be oblivious to an obvious solution.) Use a Writer monad to log statistics? Maybe a State monad. -Is there a fast way to cast between Float and Double? I'm using Float currently, and the only reason is because that's what the OpenGL api expects. I'd like to be able to use either representation, but the only way to cast that I've found so far is float_conv x = fromRational(toRational x), which is too slow. I'd try realToFrac, which should be pretty much optimised away. With doubles, ensure you use -fexcess-precision Unless something has changed, you also want to be compiling with -fvia-C if you are going to be doing floating point intensive computations. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wumpus World
iliali16 wrote: Hi guys I have to build the wumpus world problem. I didn't start yet since this is the first time in my life I have to do something like that and I feel not confident in starting it. So I have basic idea of what prolog and haskell can do and I know a bit of Java. I am wandering if you can tell me which one is best to use to build this problem.Thanks couse I am really confused This sounds like a homework problem. Any of those languages will do. Of course Haskell will be shorter. Jump in, get started. The way to solve a problem you don't understand is to do any bit of it you do understand, and then look at the problem again. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] announce: Glome.hs raytracer
On Thu, Mar 27, 2008 at 01:09:47AM +0300, Bulat Ziganshin wrote: -Collecting rendering stats is not easy without global variables. It occurs to me that it would be neat if there were some sort of write-only global variables that can be incremented by pure code but can only be read from within monadic code; that would be sufficient to ensure that the pure code wasn't affected by the values. the code is called *pure* exactly because it has no side-effects and compiler may select either to call some function two times or reuse already computed result. actually, you can make sideeffects with unsafePerformIO, but there is no guarantees of how many times such code will be executed. try this: plus a b = unsafePerformIO (modifyIORef counter (+1)) `seq` a+b This is exactly what he wants to do. The point of putting traces into the code is precisely to figure out how many times it is called. The only trouble is that unsafePerformIO (I believe) can inhibit optimizations, since there are certain transformations that ghc won't do to unsafePerformIO code. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] announce: Glome.hs raytracer
droundy: On Thu, Mar 27, 2008 at 01:09:47AM +0300, Bulat Ziganshin wrote: -Collecting rendering stats is not easy without global variables. It occurs to me that it would be neat if there were some sort of write-only global variables that can be incremented by pure code but can only be read from within monadic code; that would be sufficient to ensure that the pure code wasn't affected by the values. the code is called *pure* exactly because it has no side-effects and compiler may select either to call some function two times or reuse already computed result. actually, you can make sideeffects with unsafePerformIO, but there is no guarantees of how many times such code will be executed. try this: plus a b = unsafePerformIO (modifyIORef counter (+1)) `seq` a+b This is exactly what he wants to do. The point of putting traces into the code is precisely to figure out how many times it is called. The only trouble is that unsafePerformIO (I believe) can inhibit optimizations, since there are certain transformations that ghc won't do to unsafePerformIO code. could we just use -fhpc or profiling here. HPC at least will tell you how many times top level things are called, and print pretty graphs about it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] announce: Glome.hs raytracer
On Wed, Mar 26, 2008 at 05:07:10PM -0700, Don Stewart wrote: droundy: On Thu, Mar 27, 2008 at 01:09:47AM +0300, Bulat Ziganshin wrote: -Collecting rendering stats is not easy without global variables. It occurs to me that it would be neat if there were some sort of write-only global variables that can be incremented by pure code but can only be read from within monadic code; that would be sufficient to ensure that the pure code wasn't affected by the values. the code is called *pure* exactly because it has no side-effects and compiler may select either to call some function two times or reuse already computed result. actually, you can make sideeffects with unsafePerformIO, but there is no guarantees of how many times such code will be executed. try this: plus a b = unsafePerformIO (modifyIORef counter (+1)) `seq` a+b This is exactly what he wants to do. The point of putting traces into the code is precisely to figure out how many times it is called. The only trouble is that unsafePerformIO (I believe) can inhibit optimizations, since there are certain transformations that ghc won't do to unsafePerformIO code. could we just use -fhpc or profiling here. HPC at least will tell you how many times top level things are called, and print pretty graphs about it. It depends what the point is. I've found traces to be very helpful at times when debugging (for instance, to get values as well as counts). Also, I imagine that manual tracing is likely to be far less invasive (if you do it somewhat discretely) than profiling or using hpc. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] announce: Glome.hs raytracer
David Roundy wrote: On Wed, Mar 26, 2008 at 05:07:10PM -0700, Don Stewart wrote: droundy: On Thu, Mar 27, 2008 at 01:09:47AM +0300, Bulat Ziganshin wrote: -Collecting rendering stats is not easy without global variables. It occurs to me that it would be neat if there were some sort of write-only global variables that can be incremented by pure code but can only be read from within monadic code; that would be sufficient to ensure that the pure code wasn't affected by the values. the code is called *pure* exactly because it has no side-effects and compiler may select either to call some function two times or reuse already computed result. actually, you can make sideeffects with unsafePerformIO, but there is no guarantees of how many times such code will be executed. try this: plus a b = unsafePerformIO (modifyIORef counter (+1)) `seq` a+b This is exactly what he wants to do. The point of putting traces into the code is precisely to figure out how many times it is called. The only trouble is that unsafePerformIO (I believe) can inhibit optimizations, since there are certain transformations that ghc won't do to unsafePerformIO code. could we just use -fhpc or profiling here. HPC at least will tell you how many times top level things are called, and print pretty graphs about it. It depends what the point is. I've found traces to be very helpful at times when debugging (for instance, to get values as well as counts). Also, I imagine that manual tracing is likely to be far less invasive (if you do it somewhat discretely) than profiling or using hpc. The unsafePerformIO looks like what I want. Profiling isn't really that helpful in this situation, since sometimes what you want is the number of times something gets called per ray and then add a bit to the color value of the corresponding pixel. Something like this http://syn.cs.pdx.edu/~jsnow/glome/dragon-bih.png tells you a lot more about where your code is spending its time (the bright green places) than some numbers from a profiler. I could return the relevant stats as part of the standard results from ray-intersection tests, but I think that would clutter the code unnecessarily. Thanks everyone for the advice, it'll keep me busy for awhile. I got converted over to doubles, it seems to be about 10% faster or so with -fvia-C than regular floats with -fasm. (I'm using ghc 6.8.2 by the way, which seems to generate faster code than the 6.6.1 version I was using earlier, so maybe the difference between -fasm and -fvia-C isn't as significant as it used to be.) I'm looking into using ByteString, but it doesn't seem compatible with lex and reads. I should probably do more heap profiling before I get too carried away, though. -jim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] announce: Glome.hs raytracer
On Wed, Mar 26, 2008 at 02:33:20PM -0700, Jim Snow wrote:
-Memory consumption is atrocious: 146 megs to render a scene that's a
33k ascii file. Where does it all go? A heap profile reports the max
heap size at a rather more reasonable 500k or so. (My architecture is
64 bit ubuntu on a dual-core amd.)
I haven't looked properly yet, but it looks like something is leaking
memory that shouldn't be. The attached Gloom.hs uses constant memory,
but if you replace the map with the commented out (parMap rnf) then
the memory use seems to keep increasing, even once it has run display
once and is running it a second or third time.
Thanks
Ian
import Vec
import Clr
import Solid
import Trace
import Spd
import Control.Parallel.Strategies
import Data.Time.Clock.POSIX
import IO
get_color :: Flt - Flt - Scene - Clr.Color
get_color x y scn =
let (Scene sld lights (Camera pos fwd up right) dtex bgcolor) = scn
dir = vnorm $ vadd3 fwd (vscale right (-x)) (vscale up y)
ray = Ray pos dir
in
Trace.trace scn ray infinity 3
seqPixel :: (Float,Float,Float,Float,Float) - ()
seqPixel (f1, f2, f3, f4, f5)
= f1 `seq` f2 `seq` f3 `seq` f4 `seq` f5 `seq` ()
seqList' :: (a - ()) - [a] - ()
seqList' _ [] = ()
seqList' f (x : xs) = f x `seq` seqList' f xs
gen_pixel_list :: Flt - Flt - Flt - Flt - Flt - Flt - Scene
- [(Float,Float,Float,Float,Float)]
gen_pixel_list curx cury stopx stopy maxx maxy scene =
[ let scx = (x - midx) / midx
scy = (y - midy) / midy
Clr.Color r g b = get_color scx (scy * (midy / midx)) scene
in (scx, scy, r, g, b)
| x - [curx .. (stopx - 1)],
y - [cury .. (stopy - 1)]
]
where midx = maxx / 2
midy = maxy / 2
gen_blocks_list :: Flt - Flt - Flt - Scene - IO ()
gen_blocks_list maxx maxy block_size scene =
let xblocks = maxx / block_size
yblocks = maxy / block_size
blocks = [ (x*block_size, y*block_size)
| x - [0..xblocks-1],
y - [0..yblocks-1] ]
pixels = map -- (parMap rnf)
(\(x,y) - gen_pixel_list x y (x+block_size) (y+block_size) maxx maxy scene)
blocks
in
do
print ('A', xblocks)
print ('B', yblocks)
print ('C', blocks)
seqList' (seqList' seqPixel) pixels `seq` return ()
main :: IO ()
main = do
filedes - openFile scene.spd ReadMode
filestring - hGetContents filedes
(scene,s) - return $ head $ reads filestring
print $ leftover: ++ s
display scene
display scene
display scene
display :: Scene - IO ()
display scene = do
t1 - getPOSIXTime
gen_blocks_list 512 512 128 scene
t2 - getPOSIXTime
print (t2-t1)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wumpus World
After briefly searching the Internet and coming up with a page entitled CIS587: The Wumpus World (http://www.cis.temple.edu/~ingargio/cis587/readings/wumpus.shtml), I think that since the statement of this problem there, involving the Situation Calculus, chiefly involves a sequence of logical statements with truth values and the relations between the statements, the statements there could perhaps initially be more directly applied with Prolog than with Haskell. However, note that it has been demonstrated in the following book that it is possible to consider logic programming as a natural extension of functional programming as well (although this book is on Scheme, the concepts can be extended to Haskell as well): * Daniel P. Friedman, William E. Byrd and Oleg Kiselyov. _The Reasoned Schemer._ Cambridge, MA: The MIT Press, July 2005. ISBN-10: 0-262-56214-6 ISBN-13: 978-0-262-56214-0 http://mitpress.mit.edu/catalog/item/default.asp?ttype=2tid=10663 I would suggest that you read about both Prolog and Haskell, take a look at the above book (after first looking at its prerequisite, _The Little Schemer_), and then compare whether you would prefer more directly applying Prolog or using the above book and extending it to apply Haskell. Also, you may wish to keep in mind the following differences between Haskell and Prolog: * Prolog is initially better suited to representing knowledge originally represented as a sequence of logic statements and the relations among them * Haskell is well-suited to writing programs that can be expressed as mathematical functions, and incorporates lazy evaluation, which allows delaying the evaluation of an argument until evaluation is required * Haskell code tends to be more succinct (as Paul Johnson mentioned) * Haskell code tends to run faster, and can often be optimized to run at a speed on par with OCaml * Prolog tends to be one of the slowest-running programming languages I would also suggest that you take a look at the HaskellWiki (http://www.haskell.org/haskellwiki/Haskell), and in particular, at the following example related to logic programming: * HaskellWiki Logic programming example: http://www.haskell.org/haskellwiki/Logic_programming_example Compare this example to examples of Prolog code, and see which one suits your taste. Lastly, when learning Haskell, please try to learn from books, not tutorials. Haskell has a very steep learning curve, and is very difficult to cover adequately in a short tutorial. In particular, I recommend the following titles: * Hudak, Paul. _The Haskell School of Expression._ New York: Cambridge University Press, 2000. http://www.haskell.org/soe/ (Just make sure that you review your trigonometry before reading this book, because some of the exercises in it assume knowledge of trigonometry. I found this book extremely interesting, but discovered that it does assume some domain knowledge in that area.) * Kees Doets and Jan van Eijck. _The Haskell Road to Logic, Maths and Programming._ College Publications, April 2004. http://homepages.cwi.nl/~jve/HR/ A book that uses Haskell as a tool for learning about logic and mathematics. Nevertheless, the book is highly readable, and does a good job of introducing Haskell. It also assumes less domain knowledge than the above book. (Write to me personally if you want more information about this book.) Good luck! Benjamin L. Russell --- Paul Johnson [EMAIL PROTECTED] wrote: iliali16 wrote: Hi guys I have to build the wumpus world problem. I didn't start yet since this is the first time in my life I have to do something like that and I feel not confident in starting it. So I have basic idea of what prolog and haskell can do and I know a bit of Java. I am wandering if you can tell me which one is best to use to build this problem.Thanks couse I am really confused This sounds like a homework problem. Any of those languages will do. Of course Haskell will be shorter. Jump in, get started. The way to solve a problem you don't understand is to do any bit of it you do understand, and then look at the problem again. Paul. ___ 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] Re: SoC project: Python-Haskell bridge - request for feedback
Hi, This is my second take on the project proposal. I have expanded on a few points, and hopefully also clarified a little bit. Please comment :) Regards, Michal Python-Haskell bridge = Description --- This project will seek to provide a comprehensive, high level (and thus easy to use) binding between Haskell and Python programming languages. This will allow using libraries of either side from each language. If we decide to support function callbacks, these two functionalities (embedding Haskell in Python, and vice versa) become interrelated. In this light, it makes sense to implement them in the scope of the same project. Advantages of calling Haskell from Python - * Robust components It might be beneficial to implement safety-critical componenets in a strongly, statically typed language. Since Python itself is a terrific glue language, such components would usually be purely functional, leaving IO to the Python side. Embedding Haskell code in this way is of particular interest when there already is a large existing Python infrastructure. One can implement new functionality in a form of Haskell plugin/component, even if complete rewrite is not feasible. * Performance improvements for speed-critical code Haskell compiled to native code is typically an order of magnitude faster than Python. Aside from that, advanced language features (such as multicore parallel runtime, very lightweight threads and software transactional memory) further serve to improve the performance. Haskell could become a safe, high level alternative to commonly used C extensions. * Access to sophisticated libraries While its set of libraries is not as comprehensive as that of Python, Haskell can still offer some well tested, efficient libraries. Some of the examples might be: * rich parser combinator libraries (like Parsec) * persistent, functional data structures (i.e. Data.Map, Data.IntMap, Data.Sequence, Data.ByteString) * QuickCheck testing library to drive analysis of Python code Advantages of calling Python from Haskell - * Python as a scripting language for Haskell applications Python is widely considered to be more approachable for regular users. As such, it could be used as a configuration/extension language for applications that benefit from extra flexibility. One example of such application is xmonad window manager. * Access to a large number of libraries As a much more popular language, Python has built up an impressive suite of libraries. There already are Haskell projects which rely on Python code to implement missing functionality, for example a paste bin application hpaste, which uses Pygments syntax coloring library. Deliverables * A low level library to access and manage Python objects from Haskell * Library support for wrapping Haskell values in Python objects. This is necessary to allow function callbacks. In addition, thanks to that feature large and/or lazy data structures can be efficiently passed from Haskell to Python * A set of low level functions to convert built-in data types between Haskell and Python (strings, numbers, lists, dictionaries, generators etc.) * A high level wrapper library for Haskell that simplifies embedding and calling Python code * A set of functions, and possibly a tool, to wrap up monomorphic functions and expose them to Python through foreign export facility * A way (an external tool, or a Template Haskell macro) to easily derive conversion functions for user-defined data types/objects * Documentation and a set of examples for all of above Optional goals -- In order of increasing amount of work and decreasing priority: * Exporting a wider class of functions to Python * A Python module that inspects a compiled Haskell module and transparently exposes functions within. This might be possible thanks to GHC API ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wumpus World
On 27 Mar 2008, at 4:23 pm, Benjamin L. Russell wrote: After briefly searching the Internet and coming up with a page entitled CIS587: The Wumpus World (http://www.cis.temple.edu/~ingargio/cis587/readings/wumpus.shtml), I think that since the statement of this problem there, involving the Situation Calculus, chiefly involves a sequence of logical statements with truth values and the relations between the statements, the statements there could perhaps initially be more directly applied with Prolog than with Haskell. A solution to the problem is a sequence of actions. In Prolog, action(right). action(left). action(forward). action(shoot). action(grab). action(release). action(climb). solution(Actions) :- initial_state(State0), length(Actions, _), fill_in(Actions, State0). fill_in([], State) :- final_state(State). fill_in([Action|Actions], State0) :- action(Action), effect(Action, State0, State1), fill_in(Actions, State1). Now all that's left is to implement effect(Action, State0, State1), which means (known) action Action can be carried out in (known) state State0 and results in state State1. By inspection, we can see that [forward,left,forward,forward,grab,left,shoot, left,forward,forward,right,forward,climb] will solve the problem, so we must search to a depth of 13, and have 7 actions to choose from, so a blind iterative-deepening search like this must check on the order of 1.1x10**11 states. Also, you may wish to keep in mind the following differences between Haskell and Prolog: [snip] * Haskell code tends to be more succinct (as Paul Johnson mentioned) Not really an issue for this problem. * Haskell code tends to run faster, and can often be optimized to run at a speed on par with OCaml * Prolog tends to be one of the slowest-running programming languages That largely depends on which compiler you use and what coding style you follow. I've known Prolog code outperform published Fortran for the same problem, thanks to using a better algorithm that was easy to express in Prolog and practically impossible in Fortran 77. The Prolog results at http://shootout.alioth.debian.org/ are only for the open source system SWI Prolog, which is basically a one-man effort. The commercial SICStus Prolog is substantially faster. Some of the Prolog benchmark versions look distinctly odd. It is certainly true that Prolog can be slow *if* you try to write conventional imperative code in it, which many people do. But then, conventional imperative code isn't the best way to use Haskell either. Prolog's strongly-typed-and-moded brother, Mercury, gives you a combination of - logic programming - strict functional programming - Haskell-like typeclasses which makes it a candidate. However, checking 1.1x10**11 states is going to take a while no matter *what* language you use. Looking at the problem again, we see that if you can get the gold and shoot the wumpus, then you can certainly get out again by retracing your steps, because the pits do not move around. So in the solution [forward,left,forward,forward,grab,left,shoot, left,forward,forward,right,forward,climb] the second line consists of steps that are entirely predictable from the first. So we *really* only have to search to a depth of 7, checking 9.5x10**5 states. That's a speedup of 117649, which is much more than you are going to get from ANY programming language. I should point out that Prolog is not well suited to *directly* expressing rules like Smelly(l1) = (EXISTS l2 At(Wumpus,l2,s) (l2=l1 OR Adjacent(l1,l2))) This is going to require some programming. Something that might be rather fun would be feeding the Wumpus World axioms to the free theorem prover OTTER, which is quite impressive. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
