[Haskell] (no subject)
Can u still purchase general admission tkts Sent from my iPhone ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: [Haskell-cafe] Subject: ANNOUNCE: grid-3.0.1 (tile maps for board games or maths)
Twan van Laarhoven twanvl at gmail.com writes: After taking a peek at the documentation: have you considered removing the size function from Grid? . . . It might also be useful to add a rectangular grid type where diagonally adjacent cells are also neighbors. . . . Another interesting idea is to have modifier types that change which cells are neighbors, for example you could have Those are all great suggestions, thank you. I'll look into incorporating them into the next major release. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Subject: ANNOUNCE: grid-3.0.1 (tile maps for board games or maths)
I'm happy to announce a new major release of the grid package: http://hackage.haskell.org/package/grid https://github.com/mhwombat/grid/wiki (wiki) WHAT'S NEW: Functions for reporting the boundary and centre of bounded grid have been added, along with some miscellaneous new utility functions. IMPORTANT: The order of parameters for some functions has changed to make it easier to use them with map and fold operations. ABOUT GRID: Grid provides tools for working with regular arrangements of tiles, such as might be used in a board game or self-organising map (SOM). Grid currently supports triangular, square, and hexagonal tiles, with various 2D and toroidal layouts. If you need a tile shape or layout that isn't currently provided, please let me know. See Math.Geometry.Grid for an example of how to use the package. Suggestions for improvement are welcome. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: ANNOUNCE: grid-3.0.1 (tile maps for board games or maths)
On 18/02/13 13:41, Amy de Buitléir wrote: I'm happy to announce a new major release of the grid package: http://hackage.haskell.org/package/grid https://github.com/mhwombat/grid/wiki (wiki) After taking a peek at the documentation: have you considered removing the size function from Grid? It is the only function that actually uses the type parameter 's'. If you really need it, I would suggest putting it in a separate class, class HasSize a s | a - s where size :: a - s It might also be useful to add a rectangular grid type where diagonally adjacent cells are also neighbors. Another interesting idea is to have modifier types that change which cells are neighbors, for example you could have class Colinear g x | g x where -- | Are three points separated by moves in the same direction? isColinear :: g - x - x - x - Bool -- neighbors are separated by diagonal moves newtype Diagonal g = Diagonal g instance (Grid g, Colinear g x) = Grid (Diagonal g) x where neighbors g x = [z | y - neigbhors x, z - neigbhors y , not (isColinear x y z)] newtype Rook g = ... newtype Knight g = ... -- etc. Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] (no subject)
___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] (no subject)
smime.p7s Description: S/MIME cryptographic signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] (no subject)
wow look into this http://www.stenews.net/biz/?read=3610300 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] (no subject)
a href=http://isukeworld.com/test/cat13/02efpk.html; http://isukeworld.com/test/cat13/02efpk.html/a___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] (no subject)
Haskellers, I'm pleased to announce the first public release of NetSpec, a little Network library to simplify networking tasks that involve a fixed number of connections, using Erlang-esque send and receive primitives. Check out the docs: http://hackage.haskell.org/package/netspec And the repo on github (with examples): https://github.com/DanBurton/netspec -- Dan Burton ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Subject: A universal data store interface
On Mon, Feb 13, 2012 at 11:52, Greg Weber g...@gregweber.info wrote: That being said, I would like to have a Template Haskell interface instead of just a QQ interface. The reason why we haven't bothered with doing that ourselves is because the record name-spacing issue makes the current QQ interface much more convenient. I am actively working to solve the namespace issue. This all brings up a great point though: as part of the GSoC we should create a Template Haskell interface (similar to acid-state as you mention). Given the structure of things that Michael has already pointed out, and that we are already using Template Haskell with the DSL, this should only be a few day's work. I'm joining this thread slightly late, but thought I point to a similar TH approach: http://hackage.haskell.org/package/structured-mongoDB The implementation is very much MongoDB-specific, but we're working on targeting different backends (package is on github, so we welcome other hackers). Of course, some of the issues that have been brought up (e.g., no support for projection) still exist in structured-mongoDB, but our goals have been more relaxed: 1) provide a type-safe interface to MongoDB, 2) to avoid QQ DSL approach if possible, and 3) support a HaskellDB-like query interface. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
Hi Deian, Thanks for bringing this to our attention - this is a neat project! It actually looks *exactly* like persistent - I can't actually discern a meaningful difference, although likely your internals are slightly simpler if you only support MongoDB. If your goals are to support multiple backends then it seems your goals are *exactly* the same as Persistent. Lets collaborate on this off of the mail list. The url listed on hackage for the git repo points to Stanford, not github. Greg Weber On Tue, Feb 14, 2012 at 11:17 AM, Deian Stefan haskell-c...@deian.net wrote: On Mon, Feb 13, 2012 at 11:52, Greg Weber g...@gregweber.info wrote: That being said, I would like to have a Template Haskell interface instead of just a QQ interface. The reason why we haven't bothered with doing that ourselves is because the record name-spacing issue makes the current QQ interface much more convenient. I am actively working to solve the namespace issue. This all brings up a great point though: as part of the GSoC we should create a Template Haskell interface (similar to acid-state as you mention). Given the structure of things that Michael has already pointed out, and that we are already using Template Haskell with the DSL, this should only be a few day's work. I'm joining this thread slightly late, but thought I point to a similar TH approach: http://hackage.haskell.org/package/structured-mongoDB The implementation is very much MongoDB-specific, but we're working on targeting different backends (package is on github, so we welcome other hackers). Of course, some of the issues that have been brought up (e.g., no support for projection) still exist in structured-mongoDB, but our goals have been more relaxed: 1) provide a type-safe interface to MongoDB, 2) to avoid QQ DSL approach if possible, and 3) support a HaskellDB-like query interface. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
Hi Greg, Thanks for bringing this to our attention - this is a neat project! It actually looks *exactly* like persistent - I can't actually discern a meaningful difference, although likely your internals are slightly simpler if you only support MongoDB. If your goals are to support multiple backends then it seems your goals are *exactly* the same as Persistent. Lets collaborate on this off of the mail list. Great, I think collaborating on this will be useful! (Posting this on cafe to reflect the github url.) The url listed on hackage for the git repo points to Stanford, not github. Here is the github mirror: https://github.com/deian/structued-mongoDB Thanks, Deian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Subject: A universal data store interface
Hi Sergiu, Thanks you for your interest in that proposal. I rushed it off a year ago. Since then we have made a lot of improvements to Persistent and the library forms a basic building block for most Yesod users and other Haskellers. Persistent offers a level of type-safety and convenience not available elsewhere (except perhaps for libraries like acid-state that are limited to in-memory storage). That being said, there are still a lot of improvements that could be made. With the effort of a GSoC volunteer we could probably get it to the point of being the go-to data storage library for Haskellers, at least those planning on using the subset of backends (likely SQL) with great support. This proposal is vague and we would need to work with you to narrow things down a bit. I am biased, but I believe the Yesod project is one of the most compelling in the Haskell ecosystem. There are a lot of different ways a GSoC project could help make things even better besides improving the associated Persistent library, and we would really like to mentor at least one GSoC student. I would open more tickets for this in the system, but I am not sure how helpful it will be. It seems that we need to reach out to more students like yourself, but I am not sure how to do that unless I see messages like these first. Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
With respect, I don't think that Persistent is a natural choice as the go-to tool for Haskell users, simply because it requires knowledge of a lot of Yesod-EDSL syntax. The set of users with persistent data needs seems a very different set than that of those who are familiar with Yesod, and I think the syntax is quite confusing without fuller understanding of Yesod. The syntax of acid-state (not familiar with this one), and swapper (https://github.com/roman-smrz/swapper/blob/master/test/) seem to have a much more linear learning curve for an intermediate Haskell user. amindfv / Tom On 2/13/12, Greg Weber g...@gregweber.info wrote: Hi Sergiu, Thanks you for your interest in that proposal. I rushed it off a year ago. Since then we have made a lot of improvements to Persistent and the library forms a basic building block for most Yesod users and other Haskellers. Persistent offers a level of type-safety and convenience not available elsewhere (except perhaps for libraries like acid-state that are limited to in-memory storage). That being said, there are still a lot of improvements that could be made. With the effort of a GSoC volunteer we could probably get it to the point of being the go-to data storage library for Haskellers, at least those planning on using the subset of backends (likely SQL) with great support. This proposal is vague and we would need to work with you to narrow things down a bit. I am biased, but I believe the Yesod project is one of the most compelling in the Haskell ecosystem. There are a lot of different ways a GSoC project could help make things even better besides improving the associated Persistent library, and we would really like to mentor at least one GSoC student. I would open more tickets for this in the system, but I am not sure how helpful it will be. It seems that we need to reach out to more students like yourself, but I am not sure how to do that unless I see messages like these first. Greg Weber ___ 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] Subject: A universal data store interface
Actually, Persistent is fully usable without any special syntax, DSLs, or Template Haskell. In fact, Persistent itself has no template-haskell dependencies, specifically so that it can be built on ghc-iphone. Additionally, the Persistent DSL syntax is completely separate from any other Yesod DSL syntaxes that exist, so it's not like you have to learn five new things to get the automatic code generation. On Mon, Feb 13, 2012 at 9:30 PM, Tom Murphy amin...@gmail.com wrote: With respect, I don't think that Persistent is a natural choice as the go-to tool for Haskell users, simply because it requires knowledge of a lot of Yesod-EDSL syntax. The set of users with persistent data needs seems a very different set than that of those who are familiar with Yesod, and I think the syntax is quite confusing without fuller understanding of Yesod. The syntax of acid-state (not familiar with this one), and swapper (https://github.com/roman-smrz/swapper/blob/master/test/) seem to have a much more linear learning curve for an intermediate Haskell user. amindfv / Tom On 2/13/12, Greg Weber g...@gregweber.info wrote: Hi Sergiu, Thanks you for your interest in that proposal. I rushed it off a year ago. Since then we have made a lot of improvements to Persistent and the library forms a basic building block for most Yesod users and other Haskellers. Persistent offers a level of type-safety and convenience not available elsewhere (except perhaps for libraries like acid-state that are limited to in-memory storage). That being said, there are still a lot of improvements that could be made. With the effort of a GSoC volunteer we could probably get it to the point of being the go-to data storage library for Haskellers, at least those planning on using the subset of backends (likely SQL) with great support. This proposal is vague and we would need to work with you to narrow things down a bit. I am biased, but I believe the Yesod project is one of the most compelling in the Haskell ecosystem. There are a lot of different ways a GSoC project could help make things even better besides improving the associated Persistent library, and we would really like to mentor at least one GSoC student. I would open more tickets for this in the system, but I am not sure how helpful it will be. It seems that we need to reach out to more students like yourself, but I am not sure how to do that unless I see messages like these first. Greg Weber ___ 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] Subject: A universal data store interface
It seems that all tutorials and resources for Persistent use Template Haskell along with several Yesod specifics. But, I could be wrong, or new tutorials could be written. Tom On 2/13/12, Michael Snoyman mich...@snoyman.com wrote: Actually, Persistent is fully usable without any special syntax, DSLs, or Template Haskell. In fact, Persistent itself has no template-haskell dependencies, specifically so that it can be built on ghc-iphone. Additionally, the Persistent DSL syntax is completely separate from any other Yesod DSL syntaxes that exist, so it's not like you have to learn five new things to get the automatic code generation. On Mon, Feb 13, 2012 at 9:30 PM, Tom Murphy amin...@gmail.com wrote: With respect, I don't think that Persistent is a natural choice as the go-to tool for Haskell users, simply because it requires knowledge of a lot of Yesod-EDSL syntax. The set of users with persistent data needs seems a very different set than that of those who are familiar with Yesod, and I think the syntax is quite confusing without fuller understanding of Yesod. The syntax of acid-state (not familiar with this one), and swapper (https://github.com/roman-smrz/swapper/blob/master/test/) seem to have a much more linear learning curve for an intermediate Haskell user. amindfv / Tom On 2/13/12, Greg Weber g...@gregweber.info wrote: Hi Sergiu, Thanks you for your interest in that proposal. I rushed it off a year ago. Since then we have made a lot of improvements to Persistent and the library forms a basic building block for most Yesod users and other Haskellers. Persistent offers a level of type-safety and convenience not available elsewhere (except perhaps for libraries like acid-state that are limited to in-memory storage). That being said, there are still a lot of improvements that could be made. With the effort of a GSoC volunteer we could probably get it to the point of being the go-to data storage library for Haskellers, at least those planning on using the subset of backends (likely SQL) with great support. This proposal is vague and we would need to work with you to narrow things down a bit. I am biased, but I believe the Yesod project is one of the most compelling in the Haskell ecosystem. There are a lot of different ways a GSoC project could help make things even better besides improving the associated Persistent library, and we would really like to mentor at least one GSoC student. I would open more tickets for this in the system, but I am not sure how helpful it will be. It seems that we need to reach out to more students like yourself, but I am not sure how to do that unless I see messages like these first. Greg Weber ___ 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] Subject: A universal data store interface
Persistent is a database abstraction layer with no dependencies on Yesod. Those that need a persistence layer have the same needs to interface with the database in a type-safe way, regardless of whether their program presents a web interface. Have you tried using Persistent? We have never heard a report from a user that the Persistent DSL schema syntax is confusing. These complaints always seem to be from someone that hasn't actually tried it but is adverse to quasi-quoting. The DSL is basically the exact same as Haskell record syntax. I am not sure who the mythical users are that can figure out Haskell but can't understand dead-simple DSL's. That being said, I would like to have a Template Haskell interface instead of just a QQ interface. The reason why we haven't bothered with doing that ourselves is because the record name-spacing issue makes the current QQ interface much more convenient. I am actively working to solve the namespace issue. This all brings up a great point though: as part of the GSoC we should create a Template Haskell interface (similar to acid-state as you mention). Given the structure of things that Michael has already pointed out, and that we are already using Template Haskell with the DSL, this should only be a few day's work. On Mon, Feb 13, 2012 at 11:40 AM, Tom Murphy amin...@gmail.com wrote: It seems that all tutorials and resources for Persistent use Template Haskell along with several Yesod specifics. But, I could be wrong, or new tutorials could be written. Tom On 2/13/12, Michael Snoyman mich...@snoyman.com wrote: Actually, Persistent is fully usable without any special syntax, DSLs, or Template Haskell. In fact, Persistent itself has no template-haskell dependencies, specifically so that it can be built on ghc-iphone. Additionally, the Persistent DSL syntax is completely separate from any other Yesod DSL syntaxes that exist, so it's not like you have to learn five new things to get the automatic code generation. On Mon, Feb 13, 2012 at 9:30 PM, Tom Murphy amin...@gmail.com wrote: With respect, I don't think that Persistent is a natural choice as the go-to tool for Haskell users, simply because it requires knowledge of a lot of Yesod-EDSL syntax. The set of users with persistent data needs seems a very different set than that of those who are familiar with Yesod, and I think the syntax is quite confusing without fuller understanding of Yesod. The syntax of acid-state (not familiar with this one), and swapper (https://github.com/roman-smrz/swapper/blob/master/test/) seem to have a much more linear learning curve for an intermediate Haskell user. amindfv / Tom On 2/13/12, Greg Weber g...@gregweber.info wrote: Hi Sergiu, Thanks you for your interest in that proposal. I rushed it off a year ago. Since then we have made a lot of improvements to Persistent and the library forms a basic building block for most Yesod users and other Haskellers. Persistent offers a level of type-safety and convenience not available elsewhere (except perhaps for libraries like acid-state that are limited to in-memory storage). That being said, there are still a lot of improvements that could be made. With the effort of a GSoC volunteer we could probably get it to the point of being the go-to data storage library for Haskellers, at least those planning on using the subset of backends (likely SQL) with great support. This proposal is vague and we would need to work with you to narrow things down a bit. I am biased, but I believe the Yesod project is one of the most compelling in the Haskell ecosystem. There are a lot of different ways a GSoC project could help make things even better besides improving the associated Persistent library, and we would really like to mentor at least one GSoC student. I would open more tickets for this in the system, but I am not sure how helpful it will be. It seems that we need to reach out to more students like yourself, but I am not sure how to do that unless I see messages like these first. Greg Weber ___ 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] Subject: A universal data store interface
I have quiet a lot of experience in the business of web services strongly backed by data stores, in a company that allowed me to apply a technologies such as RubyOnRails, DataMapper, PostgreSQL, Redis, Riak, HappStack and Snap. Greg, with no offense intended, I will share with the café a conclusion that we took year to draw, but that made out job much better since : Abstraction over high level data stores is one of the worst idea in software engineering. The most proeminent example is probably PostgreSQL, which is an incredibly strong product with high SQL power. But as soon as you access it through the ActiveRecord or Persistent API, it gets turned into a very limited store, with the SQL power of SQLITE or MongoDB. So Sergiu, my POV is that universal data stores is at best a glue targeting small projects, so that they can be hacked quickly. They offer a set of features that, by design, is the greatest common divisor of the backends, which unfortunately isn't that great. This is certainly nice for a do-a-blog-in-5-minutes with MyFramework init video tutorial, but probably not for industrial projects in the long run. As a side note, the acid-state package that Greg kindly mentioned, takes a very different approach to data storage, resulting in a haskell-centric solution with an original features set. Regarding your other option, the value behind the LLVM backend seems huge for the whole Haskell community. It has the power to lighten GHC, improve runtime performance, bring binaries to more platforms and much more. In my opinion, that's quiet exciting :) Greg Hi Sergiu, Greg Thanks you for your interest in that proposal. I rushed it off a year Greg ago. Since then we have made a lot of improvements to Persistent and Greg the library forms a basic building block for most Yesod users and Greg other Haskellers. Persistent offers a level of type-safety and Greg convenience not available elsewhere (except perhaps for libraries like Greg acid-state that are limited to in-memory storage). That being said, Greg there are still a lot of improvements that could be made. With the Greg effort of a GSoC volunteer we could probably get it to the point of Greg being the go-to data storage library for Haskellers, at least those Greg planning on using the subset of backends (likely SQL) with great Greg support. This proposal is vague and we would need to work with you to Greg narrow things down a bit. Greg I am biased, but I believe the Yesod project is one of the most Greg compelling in the Haskell ecosystem. There are a lot of different ways Greg a GSoC project could help make things even better besides improving Greg the associated Persistent library, and we would really like to mentor Greg at least one GSoC student. I would open more tickets for this in the Greg system, but I am not sure how helpful it will be. It seems that we Greg need to reach out to more students like yourself, but I am not sure Greg how to do that unless I see messages like these first. Greg Greg Weber -- Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
On Mon, Feb 13, 2012 at 9:01 PM, Greg Weber g...@gregweber.info wrote: Thanks you for your interest in that proposal. I rushed it off a year ago. Since then we have made a lot of improvements to Persistent and the library forms a basic building block for most Yesod users and other Haskellers. Persistent offers a level of type-safety and convenience not available elsewhere (except perhaps for libraries like acid-state that are limited to in-memory storage). I see; this sounds great. I'm not familiar with Persistent, but I surely understand that type safety in persistence is very helpful, if not crucial sometimes. Also, my experience with Haskell makes me expect that Persistent allows addressing persistence with concise, safe code which just cannot be inspiring :-) That being said, there are still a lot of improvements that could be made. With the effort of a GSoC volunteer we could probably get it to the point of being the go-to data storage library for Haskellers, at least those planning on using the subset of backends (likely SQL) with great support. That would be great! Besides, a stable, flexible, and easy-to-work-with, already existing storage interface should allow Haskell programmers to focus less on IO and more on the purely functional logic. This proposal is vague and we would need to work with you to narrow things down a bit. Yes, that would be cool :-) Since I'm not familiar with Persistence at all (unfortunately :-( ), do you have some suggestions for me to start with? I've found this http://www.yesodweb.com/book/persistent and I'm going to get familiar with it in the first place. I hope it won't take me much longer than a couple days. I am biased, but I believe the Yesod project is one of the most compelling in the Haskell ecosystem. There are a lot of different ways a GSoC project could help make things even better besides improving the associated Persistent library, and we would really like to mentor at least one GSoC student. I would open more tickets for this in the system, but I am not sure how helpful it will be. I am rather far away from Web programming, so, unfortunately, I am not sure whether it would be relevant if I volunteered to contribute to Yesod directly. In my perspective, there are possibilities for a non-Web programmer to contribute to Yesod, though, so, if I am not too much off with my perspectives, I'll be glad to work on Yesod as well. It seems that we need to reach out to more students like yourself, but I am not sure how to do that unless I see messages like these first. I'd suppose that the larger part of the problem is that people aren't taught (or aren't properly taught) functional programming in conventional institutions, so they find it very hard to wrap their head around the strictly functional, type-safe Haskell. Haskell has a lot of packages, there's Yesod, there's quite a bit of documentation; I just can't see any other reason for people not rushing to program in Haskell :-) Sergiu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
On 2/13/12, Paul R paul.r...@gmail.com wrote: [...] Abstraction over high level data stores is one of the worst idea in software engineering. The most proeminent example is probably PostgreSQL, which is an incredibly strong product with high SQL power. But as soon as you access it through the ActiveRecord or Persistent API, it gets turned into a very limited store, with the SQL power of SQLITE or MongoDB. Limited /= Worst, though [0]. The popularity of SQLite and NoSQL prove that sometimes a limited feature set is worth the gains in abstraction. Definitely not for every project, of course. Tom [0] Prelude limited == worst False ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
On Mon, Feb 13, 2012 at 9:53 PM, Paul R paul.r...@gmail.com wrote: So Sergiu, my POV is that universal data stores is at best a glue targeting small projects, so that they can be hacked quickly. They offer a set of features that, by design, is the greatest common divisor of the backends, which unfortunately isn't that great. This is certainly nice for a do-a-blog-in-5-minutes with MyFramework init video tutorial, but probably not for industrial projects in the long run. [...] Regarding your other option, the value behind the LLVM backend seems huge for the whole Haskell community. It has the power to lighten GHC, improve runtime performance, bring binaries to more platforms and much more. In my opinion, that's quiet exciting :) I am absolutely not in the position to question or deny your conclusion. Obviously, I am not going to drop my commitment to the LLVM backend; however, I tried to find a second project idea that would interest me, and the idea of working on a universal data storage interface seemed quite attractive. It still seems attractive to me; mainly (but not only) because Greg said it could actually run of a purely Haskell backend, which means that, ideally, one could write Haskell programs with very little effort dedicated to storage. Sergiu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
For one, I am adverse to DSL based on quasi-quotation. Not because I find the syntax hard - to be honnest it is often the opposite, with DSL designed with ease of use in mind - but because of the volatile nature of languages without specification, be them basic DSL. It is quiet hard to settle on a language spec that users will be able to rely on in the long run, and we all know that. The haskell commitee did a fine job with Haskell 98, so people felt confident to spend days and months and years working through Haskell 98, building blocks of it and sharing them so that they can be used together in the long term. I'd rather type more of Haskell 98 than less of a unspecified DSL, simply because of that. On Mon, 13 Feb 2012 11:52:00 -0800, Greg Weber g...@gregweber.info said: Greg Persistent is a database abstraction layer with no dependencies on Greg Yesod. Those that need a persistence layer have the same needs to Greg interface with the database in a type-safe way, regardless of whether Greg their program presents a web interface. Greg Have you tried using Persistent? We have never heard a report from a Greg user that the Persistent DSL schema syntax is confusing. These Greg complaints always seem to be from someone that hasn't actually tried Greg it but is adverse to quasi-quoting. The DSL is basically the exact Greg same as Haskell record syntax. I am not sure who the mythical users Greg are that can figure out Haskell but can't understand dead-simple Greg DSL's. Greg That being said, I would like to have a Template Haskell interface Greg instead of just a QQ interface. The reason why we haven't bothered Greg with doing that ourselves is because the record name-spacing issue Greg makes the current QQ interface much more convenient. I am actively Greg working to solve the namespace issue. This all brings up a great point Greg though: as part of the GSoC we should create a Template Haskell Greg interface (similar to acid-state as you mention). Given the structure Greg of things that Michael has already pointed out, and that we are Greg already using Template Haskell with the DSL, this should only be a few Greg day's work. Greg On Mon, Feb 13, 2012 at 11:40 AM, Tom Murphy amin...@gmail.com wrote: It seems that all tutorials and resources for Persistent use Template Haskell along with several Yesod specifics. But, I could be wrong, or new tutorials could be written. Tom On 2/13/12, Michael Snoyman mich...@snoyman.com wrote: Actually, Persistent is fully usable without any special syntax, DSLs, or Template Haskell. In fact, Persistent itself has no template-haskell dependencies, specifically so that it can be built on ghc-iphone. Additionally, the Persistent DSL syntax is completely separate from any other Yesod DSL syntaxes that exist, so it's not like you have to learn five new things to get the automatic code generation. On Mon, Feb 13, 2012 at 9:30 PM, Tom Murphy amin...@gmail.com wrote: With respect, I don't think that Persistent is a natural choice as the go-to tool for Haskell users, simply because it requires knowledge of a lot of Yesod-EDSL syntax. The set of users with persistent data needs seems a very different set than that of those who are familiar with Yesod, and I think the syntax is quite confusing without fuller understanding of Yesod. The syntax of acid-state (not familiar with this one), and swapper (https://github.com/roman-smrz/swapper/blob/master/test/) seem to have a much more linear learning curve for an intermediate Haskell user. amindfv / Tom On 2/13/12, Greg Weber g...@gregweber.info wrote: Hi Sergiu, Thanks you for your interest in that proposal. I rushed it off a year ago. Since then we have made a lot of improvements to Persistent and the library forms a basic building block for most Yesod users and other Haskellers. Persistent offers a level of type-safety and convenience not available elsewhere (except perhaps for libraries like acid-state that are limited to in-memory storage). That being said, there are still a lot of improvements that could be made. With the effort of a GSoC volunteer we could probably get it to the point of being the go-to data storage library for Haskellers, at least those planning on using the subset of backends (likely SQL) with great support. This proposal is vague and we would need to work with you to narrow things down a bit. I am biased, but I believe the Yesod project is one of the most compelling in the Haskell ecosystem. There are a lot of different ways a GSoC project could help make things even better besides improving the associated Persistent library, and we would really like to mentor at least one GSoC student. I would open more tickets for this in the system, but I am not sure how helpful it will be. It seems that we need to reach out to more students like yourself, but I am not sure how to do that unless I see messages like these first. Greg Weber
Re: [Haskell-cafe] Subject: A universal data store interface
On 2/13/12, Sergiu Ivanov unlimitedscol...@gmail.com wrote: [...] a stable, flexible, and easy-to-work-with, already existing storage interface should allow Haskell programmers to focus less on IO and more on the purely functional logic. +1 - Very exciting! Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
The most proeminent example is probably PostgreSQL, which is an incredibly strong product with high SQL power. But as soon as you access it through the ActiveRecord or Persistent API, it gets turned into a very limited store, with the SQL power of SQLITE or MongoDB. Tom Limited /= Worst, though [0]. Tom The popularity of SQLite and NoSQL prove that sometimes a limited Tom feature set is worth the gains in abstraction. Tom Definitely not for every project, of course. I don't dismiss MongoDB nor SQLite, they are great. But you probably don't want to limit MongoDB to a SQL features set, and you don't want to limit SQLite to a NoSQL interface, and you don't want to limit PostgreSQL to a SQLite features set ... As you said, each of these stores has strenghs for particular needs and weaknesses for others. Pick the one that best suits your project, and use its full power, raw :) -- Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
You make it sound like your options are use the crippled abstraction layer or use the full-powered database layer. You're leaving out two very important points: 1. There's a reason the abstraction layer exists: it can be clumsy to go directly to the full-powered database for simple stuff. 2. You can bypass the abstraction layer whenever you want. I like to describe Persistent's goal as doing 95% of what you need, and getting out of your way for the other 5%. You can write raw SQL queries with Persistent. I use this for implementing full-text search. I haven't needed to write deep analytical tools recently, but if I did, I would use raw SQL for that too. Persistent's advantage over going directly to the database is concise, type-safe code. Are you really telling me that `runSql SELECT * FROM foo where id=? [someId]` plus a bunch of marshal code is better then `get someId`? Michael On Mon, Feb 13, 2012 at 9:53 PM, Paul R paul.r...@gmail.com wrote: I have quiet a lot of experience in the business of web services strongly backed by data stores, in a company that allowed me to apply a technologies such as RubyOnRails, DataMapper, PostgreSQL, Redis, Riak, HappStack and Snap. Greg, with no offense intended, I will share with the café a conclusion that we took year to draw, but that made out job much better since : Abstraction over high level data stores is one of the worst idea in software engineering. The most proeminent example is probably PostgreSQL, which is an incredibly strong product with high SQL power. But as soon as you access it through the ActiveRecord or Persistent API, it gets turned into a very limited store, with the SQL power of SQLITE or MongoDB. So Sergiu, my POV is that universal data stores is at best a glue targeting small projects, so that they can be hacked quickly. They offer a set of features that, by design, is the greatest common divisor of the backends, which unfortunately isn't that great. This is certainly nice for a do-a-blog-in-5-minutes with MyFramework init video tutorial, but probably not for industrial projects in the long run. As a side note, the acid-state package that Greg kindly mentioned, takes a very different approach to data storage, resulting in a haskell-centric solution with an original features set. Regarding your other option, the value behind the LLVM backend seems huge for the whole Haskell community. It has the power to lighten GHC, improve runtime performance, bring binaries to more platforms and much more. In my opinion, that's quiet exciting :) Greg Hi Sergiu, Greg Thanks you for your interest in that proposal. I rushed it off a year Greg ago. Since then we have made a lot of improvements to Persistent and Greg the library forms a basic building block for most Yesod users and Greg other Haskellers. Persistent offers a level of type-safety and Greg convenience not available elsewhere (except perhaps for libraries like Greg acid-state that are limited to in-memory storage). That being said, Greg there are still a lot of improvements that could be made. With the Greg effort of a GSoC volunteer we could probably get it to the point of Greg being the go-to data storage library for Haskellers, at least those Greg planning on using the subset of backends (likely SQL) with great Greg support. This proposal is vague and we would need to work with you to Greg narrow things down a bit. Greg I am biased, but I believe the Yesod project is one of the most Greg compelling in the Haskell ecosystem. There are a lot of different ways Greg a GSoC project could help make things even better besides improving Greg the associated Persistent library, and we would really like to mentor Greg at least one GSoC student. I would open more tickets for this in the Greg system, but I am not sure how helpful it will be. It seems that we Greg need to reach out to more students like yourself, but I am not sure Greg how to do that unless I see messages like these first. Greg Greg Weber -- 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
Re: [Haskell-cafe] Subject: A universal data store interface
Paul, I appreciate your experience and you might find it interesting that I have come to similar conclusions from my own experience! As Tom commented though, just because something is limited does not mean it is bad for every project. There are many small scale projects that do just fine with about any database abstraction layer, and are probably better off for it. And as Michael said, many find it a good approach to use a database abstraction layer for some of their code and then go raw for other parts of it. like-wise, the acid-state project (which I actually think is very similar to Persistent, but it only stores in the process memory) is a nice approach until the point that you run out of RAM. So lets assume our project has very demanding needs from our persistence layer, and we don't want to ever have to spend time re-writing an abstraction-layer query into a raw form. Does that mean it is impossible to write anything more than a database driver? I still believe there are several important areas that a database layer can be awesome for. The first is proper serialization - converting between Haskell values and database value. We have re-factored Persistent to separate this out from the querying. So you can use Persistent's serilization layer without using its query layer. The new rawSql function lets you write raw queries and get back real Haskell values. The second aspect is declaring the schema and leveraging that to help make things more type-safe. This is even more important in a schema-less data store like MongoDB. Using raw strings means you are a typo away from silent error. Declaring your schema in a database layer creates the possibility of catching these error in your code. This is less important overall in SQL, but Persistent still has your back by checking the schema and telling you what you need to migrate. But I want to take this a step further in Haskell: I want to know at compile time that my query is valid, even if I want to write it in a raw form. Something like Persistent is needed to make sure the columns referenced are correct, but we also want to know that the entire query is correct. There are some interesting but immature efforts in this area, which is yet another way that Persistent could be improved. On Mon, Feb 13, 2012 at 11:53 AM, Paul R paul.r...@gmail.com wrote: I have quiet a lot of experience in the business of web services strongly backed by data stores, in a company that allowed me to apply a technologies such as RubyOnRails, DataMapper, PostgreSQL, Redis, Riak, HappStack and Snap. Greg, with no offense intended, I will share with the café a conclusion that we took year to draw, but that made out job much better since : Abstraction over high level data stores is one of the worst idea in software engineering. The most proeminent example is probably PostgreSQL, which is an incredibly strong product with high SQL power. But as soon as you access it through the ActiveRecord or Persistent API, it gets turned into a very limited store, with the SQL power of SQLITE or MongoDB. So Sergiu, my POV is that universal data stores is at best a glue targeting small projects, so that they can be hacked quickly. They offer a set of features that, by design, is the greatest common divisor of the backends, which unfortunately isn't that great. This is certainly nice for a do-a-blog-in-5-minutes with MyFramework init video tutorial, but probably not for industrial projects in the long run. As a side note, the acid-state package that Greg kindly mentioned, takes a very different approach to data storage, resulting in a haskell-centric solution with an original features set. Regarding your other option, the value behind the LLVM backend seems huge for the whole Haskell community. It has the power to lighten GHC, improve runtime performance, bring binaries to more platforms and much more. In my opinion, that's quiet exciting :) Greg Hi Sergiu, Greg Thanks you for your interest in that proposal. I rushed it off a year Greg ago. Since then we have made a lot of improvements to Persistent and Greg the library forms a basic building block for most Yesod users and Greg other Haskellers. Persistent offers a level of type-safety and Greg convenience not available elsewhere (except perhaps for libraries like Greg acid-state that are limited to in-memory storage). That being said, Greg there are still a lot of improvements that could be made. With the Greg effort of a GSoC volunteer we could probably get it to the point of Greg being the go-to data storage library for Haskellers, at least those Greg planning on using the subset of backends (likely SQL) with great Greg support. This proposal is vague and we would need to work with you to Greg narrow things down a bit. Greg I am biased, but I believe the Yesod project is one of the most Greg compelling in the Haskell ecosystem. There are a lot of different ways Greg a GSoC project could help make
Re: [Haskell-cafe] Subject: A universal data store interface
Hello Michael, From Persistent documentation : Persistent follows the guiding principles of type safety and concise, declarative syntax. Some other nice features are: * Database-agnostic. There is first class support for PostgreSQL, SQLite and MongoDB, with experimental CouchDB and MySQL support in the works. * By being non-relational in nature, we simultaneously are able to support a wider number of storage layers and are not constrained by some of the performance bottlenecks incurred through joins. * A major source of frustration in dealing with SQL databases is changes to the schema. Persistent can automatically perform database migrations. You raise a good point mentioning that persistent has raw queries facilities. That certainly makes is suitable for complex queries, but as soon as you do so, you are not anymore store-agnostic, so this part of Persistent becomes irrelevant in any project using SQL features specific to the store (all of mines, what about yours Michael ?). That makes the first two points not very convincing. The third point does not make much sense to me. Here we spend a lot of time designing efficient SQL schemas and migrations so that the store stays fast and migrations are safe. That's not the kind of job that can be automatically derived by a program by just looking at two models descriptions. Back to the feature of persistent raised by Greg, which is serializing to and from the database with type-safety, I agree that this is desirable. On Mon, 13 Feb 2012 22:36:17 +0200, Michael Snoyman mich...@snoyman.com said: Michael You make it sound like your options are use the crippled abstraction Michael layer or use the full-powered database layer. You're leaving out Michael two very important points: Michael 1. There's a reason the abstraction layer exists: it can be clumsy to Michael go directly to the full-powered database for simple stuff. Michael 2. You can bypass the abstraction layer whenever you want. Michael I like to describe Persistent's goal as doing 95% of what you need, Michael and getting out of your way for the other 5%. You can write raw SQL Michael queries with Persistent. I use this for implementing full-text search. Michael I haven't needed to write deep analytical tools recently, but if I Michael did, I would use raw SQL for that too. Michael Persistent's advantage over going directly to the database is concise, Michael type-safe code. Are you really telling me that `runSql SELECT * FROM Michael foo where id=? [someId]` plus a bunch of marshal code is better then Michael `get someId`? Michael Michael Michael On Mon, Feb 13, 2012 at 9:53 PM, Paul R paul.r...@gmail.com wrote: I have quiet a lot of experience in the business of web services strongly backed by data stores, in a company that allowed me to apply a technologies such as RubyOnRails, DataMapper, PostgreSQL, Redis, Riak, HappStack and Snap. Greg, with no offense intended, I will share with the café a conclusion that we took year to draw, but that made out job much better since : Abstraction over high level data stores is one of the worst idea in software engineering. The most proeminent example is probably PostgreSQL, which is an incredibly strong product with high SQL power. But as soon as you access it through the ActiveRecord or Persistent API, it gets turned into a very limited store, with the SQL power of SQLITE or MongoDB. So Sergiu, my POV is that universal data stores is at best a glue targeting small projects, so that they can be hacked quickly. They offer a set of features that, by design, is the greatest common divisor of the backends, which unfortunately isn't that great. This is certainly nice for a do-a-blog-in-5-minutes with MyFramework init video tutorial, but probably not for industrial projects in the long run. As a side note, the acid-state package that Greg kindly mentioned, takes a very different approach to data storage, resulting in a haskell-centric solution with an original features set. Regarding your other option, the value behind the LLVM backend seems huge for the whole Haskell community. It has the power to lighten GHC, improve runtime performance, bring binaries to more platforms and much more. In my opinion, that's quiet exciting :) Greg Hi Sergiu, Greg Thanks you for your interest in that proposal. I rushed it off a year Greg ago. Since then we have made a lot of improvements to Persistent and Greg the library forms a basic building block for most Yesod users and Greg other Haskellers. Persistent offers a level of type-safety and Greg convenience not available elsewhere (except perhaps for libraries like Greg acid-state that are limited to in-memory storage). That being said, Greg there are still a lot of improvements that could be made. With the Greg effort of a GSoC volunteer we could probably get it to the point of Greg being the go-to data storage library for Haskellers, at least
Re: [Haskell-cafe] Subject: A universal data store interface
This proposal is vague and we would need to work with you to narrow things down a bit. Yes, that would be cool :-) Since I'm not familiar with Persistence at all (unfortunately :-( ), do you have some suggestions for me to start with? I've found this http://www.yesodweb.com/book/persistent and I'm going to get familiar with it in the first place. I hope it won't take me much longer than a couple days. That is definitely the best place to start. If you want to look at more example usage code you can look at the test suite in the persistent-test folder of the repository. Perhaps you have a Haskell program that could benefit from persisting data (and maybe already does in a flat file) and you could try integrating Persistent with it. I am rather far away from Web programming, so, unfortunately, I am not sure whether it would be relevant if I volunteered to contribute to Yesod directly. In my perspective, there are possibilities for a non-Web programmer to contribute to Yesod, though, so, if I am not too much off with my perspectives, I'll be glad to work on Yesod as well. I also opened up a GSoC ticket for making Haskell ready for the real-time web. This is also another somewhat self-contained project that does not really require web development experience. More and more programs would like to have a web interface or at least speak some HTTP at some point. Most web programmers don't have a great understanding of the internals of web development that they are abstracted from. I wouldn't shy away from something web related because you are afraid you won't be able to hack it. The only problem would be that you might not be able to judge the project well before starting the project. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
On 02/13/2012 09:36 PM, Michael Snoyman wrote: You make it sound like your options are use the crippled abstraction layer or use the full-powered database layer. You're leaving out two very important points: 1. There's a reason the abstraction layer exists: it can be clumsy to go directly to the full-powered database for simple stuff. That's simply a reason to make access to the *full-powered database* easier, not a reason to make access to *every database* identical. Doing that is a mistake *unless* you're going to avoid SQL entirely but somehow still retain the full database power. For example, SQLite requires entirely different SQL contortions to get certain types of fields in query results from the way PostgreSQL does it. That means you'll have to change your program a lot even if you use e.g. HDBC for database access. My experience is roughly similar to Paul R's. You often give up too much by going with generic ORM and such. That's not to say you can't make working with each particular DB much more pleasant that it is currently -- postgresql-libpq, for example, is almost useless as an application-level API, and I'm working on (no guarantees!) a little postgresql-libpq-conduit thingy which will hopefully make issuing queries and iterating over results a much more pleasant experience without burdening you will all kinds of ridiculously low-level detail, and at the same time will NOT shield you from the low-level detail that actually *matters*. The Database Supported Haskell stuff (http://hackage.haskell.org/package/DSH) also seems relevant to this discussion, since this does seem like it could actually leverage the immense power of (some) databases without having to bother too much with low-level DB access. 2. You can bypass the abstraction layer whenever you want. I like to describe Persistent's goal as doing 95% of what you need, and getting out of your way for the other 5%. You can write raw SQL queries with Persistent. I use this for implementing full-text search. I haven't needed to write deep analytical tools recently, but if I did, I would use raw SQL for that too. Yes, but then you end up being fully tied to the database *anyway*, so why not just make *that* easier and safer from the start? (I realize that this is a hard problem in practice. It's certainly NOT small enough for a GSoC, IMO.) Persistent's advantage over going directly to the database is concise, type-safe code. Are you really telling me that `runSql SELECT * FROM foo where id=? [someId]` plus a bunch of marshal code is better then `get someId`? For starters you should probably never do a SELECT * (which is what one assumes Persistent would/will do) -- on an SQL database the performance characteristics and locking behavior may change dramatically over time... while on $generic-NoSQL database there may not really any other option, and the performance characteristics *won't* necessarily change too dramatically. This is an example of why introducing something like Persistent (or ORMs in general) may be a non-trivial decision. Besides, you probably won't need a lot of marshalling code if you know what the query result field types are going to be (you should!). You just pattern-match, e.g. processQueryResult [SqlInteger i, SqlByte j, SqlText x] = ... -- do whatever to i,j and x processQueryResult _ = error Invalid columns in query result Yes, this means you'll need to know exactly how the table was created (but not in the case of SQLite -- there you MAY have to add various casts to the SQL or to manually convert from SqlText to your intended Haskell datatype). I don't think anyone denies that having a compile-time guarantee of a successful match would be a bad thing. It's just that this are is far more complicated than people give it credit for. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] (no subject)
http://poorogies.com/wp-content/plugins/scan.php ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] (no subject)
http://www.myvisionview.com/images/scan.php ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] (no subject)
= Call for Participation ACM SIGPLAN Haskell Symposium 2009 http://haskell.org/haskell-symposium/2009/ Edinburgh, Scotland, 3 September 2009 = The ACM SIGPLAN Haskell Symposium 2009 will be co-located with the 2009 International Conference on Functional Programming (ICFP). The purpose of the Haskell Symposium is to discuss experiences with Haskell and future developments for the language. The scope of the symposium includes all aspects of the design, semantics, theory, application, implementation, and teaching of Haskell. Preliminary program: * http://haskell.org/haskell-symposium/2009/schedule.html REGISTRATION IS NOW OPEN: * http://www.regmaster.com/conf/icfp2009.html * Early registration deadline: July 30, 2009 Local arrangements (including travel and accommodation): * http://www.haskell.org/haskellwiki/ICFP_2009_Local_Arrangements * Conference reservation/rate deadline: July 20, 2009 * ICFP09 Haskell 09 coincides with the final week of the Edinburgh Festival, one of the premier arts and cultural festivals in the world. The opportunity to attend the Festival is a plus! Due to the popularity of Edinburgh during the festival period, we strongly recommend booking accommodation early. See you in Edinburgh, Stephanie Weirich Haskell 2009 Program Chair = p.s., don't forget about the ICFP Programming Contest this weekend!! * http://www.icfpcontest.org * Friday, June 26 to Monday, June 29 * Organizers: Computer Systems Design Laboratory (University of Kansas) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] (no subject)
To: haskell@haskell.org Subject: 10 jobs in declarative programming TEN DECLARATIVE PROGRAMMING CONSULTANTS SOUGHT Semmle and LogicBlox are creating a platform for declarative programming in Datalog, a pure logic programming language. Semmle is based in Oxford, headed by Oege de Moor; LogicBlox is based in Atlanta, headed by Molham Aref. To configure our solution at a number of large corporate clients in the retail, insurance and software quality industries, we urgently require 10 full-time staff to act as consultants. These consultants will work with clients to write custom queries in Datalog, and to create user interfaces in a declarative framework. This is a unique opportunity to change the way enterprise software is constructed, and to become part of the revolution to adopt declarative programming in mainstream applications. Semmle and LogicBlox offer a vibrant, intellectually stimulating environment to work on exciting applications of cutting-edge technology. Requirements: You must be passionate about simplifying the construction of complex software systems. A good undergraduate degree in computer science or related discipline is necessary. Substantial programming experience, and familarity with declarative programming (both functional and logic) is a must. Some travel will be required. Starting date and renumeration: The openings are available immediately. The renumeration depends on experience and qualifications; it is especially competitive for recent graduates. Further information: To find out more about this opportunity, write to Oege de Moor (o...@semmle.com) and Molham Aref (mol...@logicblox.com). To apply: Send a CV and the names of three referees (at least two of whom must be able to comment on your programming abilities) to recr...@semmle.com, by June 12. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Re: [Haskell] (no subject)
I think at some intermediate stage that flag helped me compile, but in the
final version it's unnecessary.
my bad.
Thomas Hartman [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
09/05/2007 06:29 PM
To
[EMAIL PROTECTED]
cc
[EMAIL PROTECTED], haskell-cafe@haskell.org, Tomi Owens
[EMAIL PROTECTED]
Subject
Re: [Haskell-cafe] Re: [Haskell] (no subject)
I think you want something like this
{-# OPTIONS -fglasgow-exts #-}
f :: (Integer, Float) - Integer
f (a,b) = a * floor (10/b)
lst :: [(Integer, Integer)]
lst = [(a ^ 2 + b ^ 2, a) | a - [1..4], b - [1..4], a^2 + b^2 20, b =
a]
lst3 = map (f) ( map ( intTupToFloatTup ) lst )
intTupToFloatTup :: (Integer, Integer) - (Integer, Float)
intTupToFloatTup (int1, int2) = (int1, fromInteger int2)
load the whole thing into ghci with ghci proggie.hs
when I have this type of problem, my usual approach is to put the code
into a text file, load that in ghci, derive type sigs on the functions
that work, and then see if I can figure out
the mismatch.
you could probably get a fast answer to this kind of question on the
#haskell irc channel as well.
hope this helps,
thomas.
Scott Williams [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
09/05/2007 05:28 PM
To
Tomi Owens [EMAIL PROTECTED]
cc
haskell-cafe@haskell.org
Subject
[Haskell-cafe] Re: [Haskell] (no subject)
[bcc haskell, cc haskell-cafe]
On 9/5/07, Tomi Owens [EMAIL PROTECTED] wrote:
Hi there. I'm a teacher of Maths and am working my way through the Euler
Project problems for fun. I have mostly been using Basic, but have read up
about Haskell and think it looks like a sensible way to solve many of the
problems.
OK, so I've downloaded GHCi and am trying to teach myself.
So far I have done this:
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... linking ... done.
Prelude let f (a,b) = a * floor (10/b)
Prelude f(2,5)
4
Here you can find out type ghci has inferred for this function.
:t f
f :: (RealFrac b, Integral b1) = (b1, b) - b1
This function works just as I want it to.
Now I try creating a list:
Prelude [(a2+b2,a)| a - [1..4] , b- [1..4], a2+b220, b=a]
[(2,1),(5,2),(8,2),(10,3),(13,3),(18,3),(17,4)]
Let's assign this to an intermediate variable so we can query it's type:
Prelude let lst = [(a ^ 2 + b ^ 2, a) | a - [1..4], b - [1..4], a^2 +
b^2 20, b = a]
Prelude lst
[(2,1),(5,2),(8,2),(10,3),(13,3),(18,3),(17,4)]
Prelude :t lst
lst :: [(Integer, Integer)]
aha; here's the source of the type mismatch:
Prelude :t floor
floor :: (RealFrac a, Integral b) = a - b
Floor has to take a RealFrac. According to hoogle[1], we can use various
floating-point approximations (Float, Double, CFloat, etc) or we can use
the exact Rational type.
[1] http://haskell.org/hoogle/?q=RealFrac
You can get your types to match by declaring your list to be of type
[(Rational, Rational)] either by explicitly typing one of the untyped
variables or the entire expression:
Prelude let lst = [(a ^ 2 + b ^ 2, a) | (a::Rational) - [1..4], b -
[1..4], a^2 + b^2 20, b = a]
Prelude :t lst
lst :: [(Rational, Rational)]
Prelude let lst :: [(Rational, Rational)] = [(a ^ 2 + b ^ 2, a) | a -
[1..4], b - [1..4], a^2 + b^2 20, b = a]
Prelude :t lst
lst :: [(Rational, Rational)]
and this works
So now I try to apply the function to the list:
Prelude map (f) [(a2+b2,a)| a - [1..4] , b- [1..4], a2+b220, b=a]
and I get this result:
interactive:1:5:
Ambiguous type variable `t' in the constraints:
`Integral t' arising from use of `f' at interactive:1:5
`RealFrac t' arising from use of `f' at interactive:1:5
Probable fix: add a type signature that fixes these type variable(s)
I'm sorry, but I don't quite get how to set the type signature and how it
will apply to my function...
Thanks,
Hope this helps
Tomi
Department for Education, Sport and Culture E Mail
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify
the sender. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the
intended recipient. The Department for Education, Sport and Culture and
any of its establishments each reserve the right to monitor all e-mail
communications through its networks.
Any views expressed in this message are those of the individual sender,
except where the message states otherwise and the sender is authorised
[Haskell] (no subject)
Hi there. I'm a teacher of Maths and am working my way through the Euler Project problems for fun. I have mostly been using Basic, but have read up about Haskell and think it looks like a sensible way to solve many of the problems. OK, so I've downloaded GHCi and am trying to teach myself. So far I have done this: ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Prelude let f (a,b) = a * floor (10/b) Prelude f(2,5) 4 This function works just as I want it to. Now I try creating a list: Prelude [(a2+b2,a)| a - [1..4] , b- [1..4], a2+b220, b=a] [(2,1),(5,2),(8,2),(10,3),(13,3),(18,3),(17,4)] and this works So now I try to apply the function to the list: Prelude map (f) [(a2+b2,a)| a - [1..4] , b- [1..4], a2+b220, b=a] and I get this result: interactive:1:5: Ambiguous type variable `t' in the constraints: `Integral t' arising from use of `f' at interactive:1:5 `RealFrac t' arising from use of `f' at interactive:1:5 Probable fix: add a type signature that fixes these type variable(s) I'm sorry, but I don't quite get how to set the type signature and how it will apply to my function... Thanks, Tomi Department for Education, Sport and Culture E Mail This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The Department for Education, Sport and Culture and any of its establishments each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. The Department for Education, Sport and Culture shall not be liable to the recipient or any third party for any loss or damage, however it appears, from this e-mail or its content. This includes loss or damage caused by viruses. It is the responsibility of the recipient to ensure that the opening of this message and its attachments shall not adversely affect systems or data. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] (no subject)
On Sep 5, 2007, at 21:10 , Tomi Owens wrote:
Prelude let f (a,b) = a * floor (10/b)
Prelude f(2,5)
4
This function works just as I want it to.
Now I try creating a list:
Prelude [(a2+b2,a)| a - [1..4] , b- [1..4], a2+b220, b=a]
[(2,1),(5,2),(8,2),(10,3),(13,3),(18,3),(17,4)]
and this works
So now I try to apply the function to the list:
Prelude map (f) [(a2+b2,a)| a - [1..4] , b- [1..4], a2+b220, b=a]
and I get this result:
interactive:1:5:
Ambiguous type variable `t' in the constraints:
`Integral t' arising from use of `f' at interactive:1:5
`RealFrac t' arising from use of `f' at interactive:1:5
Probable fix: add a type signature that fixes these type variable
(s)
I'm sorry, but I don't quite get how to set the type signature and
how it will apply to my function...
The problem here is that (assuming the a\sup{2} etc. are actually
a^2) the (^) operator expects and returns Integrals, but (/) requires
a RealFrac. Thus, the type of your list comprehension is inferred to
be [(Integer,Integer)] but needs to be RealFrac a = [(Integer,a)]
(or, more simply, [(Integer,Double)].
Prelude let f (a,b) = a * floor (10/b)
Prelude :t f
f :: (RealFrac t1, Integral t) = (t, t1) - t
Prelude let v :: [(Integer,Double)]; v = [(a^2 + b^2,fromIntegral
a) | a - [1..4], b - [1..4], a^2 + b^2 20, b = a]
Prelude :t v
v :: [(Integer, Double)]
Prelude map f v
[20,25,40,30,433329,54,425000]
--
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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] (no subject)
2007/9/5, Tomi Owens [EMAIL PROTECTED]: So now I try to apply the function to the list: Prelude map (f) [(a2+b2,a)| a - [1..4] , b- [1..4], a2+b220, b=a] and I get this result: interactive:1:5: Ambiguous type variable `t' in the constraints: `Integral t' arising from use of `f' at interactive:1:5 `RealFrac t' arising from use of `f' at interactive:1:5 Probable fix: add a type signature that fixes these type variable(s) I'm sorry, but I don't quite get how to set the type signature and how it will apply to my function... It's because f need a real, not an integer as the second element of its parameter (since it use (/) in (1/b)), and as it also needs an integer as it's first, the type checker don't know what the type of a should be (it can't be both an integer and a floating value at the same time). The easiest IMO is to keep a as an integer, but use fromIntegral to convert it to a real in the second part of the tuple : map f [( a^2+b^2, fromIntegral a) | a - [1..4] , b- [1..4], a^2+b^220, b=a] You would get more help and faster from an IRC channel like [EMAIL PROTECTED] though. -- Jedaï ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] (no subject)
Tomi Owens [EMAIL PROTECTED] writes: Hi there. I'm a teacher of Maths and am working my way through the Euler Project problems for fun. I have mostly been using Basic, but have read up about Haskell and think it looks like a sensible way to solve many of the problems. It certainly is. Prelude let f (a,b) = a * floor (10/b) From the floor and the rest of your message, it looks like you want truncating integer division here. So, instead of floor and (/), use div. let f (a,b) = a * 10 `div` b With that change the rest of your program should work. The other replies explain why the interpreter couldn't figure out which type to use. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Re: [Haskell] (no subject)
I think you want something like this
{-# OPTIONS -fglasgow-exts #-}
f :: (Integer, Float) - Integer
f (a,b) = a * floor (10/b)
lst :: [(Integer, Integer)]
lst = [(a ^ 2 + b ^ 2, a) | a - [1..4], b - [1..4], a^2 + b^2 20, b =
a]
lst3 = map (f) ( map ( intTupToFloatTup ) lst )
intTupToFloatTup :: (Integer, Integer) - (Integer, Float)
intTupToFloatTup (int1, int2) = (int1, fromInteger int2)
load the whole thing into ghci with ghci proggie.hs
when I have this type of problem, my usual approach is to put the code
into a text file, load that in ghci, derive type sigs on the functions
that work, and then see if I can figure out
the mismatch.
you could probably get a fast answer to this kind of question on the
#haskell irc channel as well.
hope this helps,
thomas.
Scott Williams [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
09/05/2007 05:28 PM
To
Tomi Owens [EMAIL PROTECTED]
cc
haskell-cafe@haskell.org
Subject
[Haskell-cafe] Re: [Haskell] (no subject)
[bcc haskell, cc haskell-cafe]
On 9/5/07, Tomi Owens [EMAIL PROTECTED] wrote:
Hi there. I'm a teacher of Maths and am working my way through the Euler
Project problems for fun. I have mostly been using Basic, but have read up
about Haskell and think it looks like a sensible way to solve many of the
problems.
OK, so I've downloaded GHCi and am trying to teach myself.
So far I have done this:
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... linking ... done.
Prelude let f (a,b) = a * floor (10/b)
Prelude f(2,5)
4
Here you can find out type ghci has inferred for this function.
:t f
f :: (RealFrac b, Integral b1) = (b1, b) - b1
This function works just as I want it to.
Now I try creating a list:
Prelude [(a2+b2,a)| a - [1..4] , b- [1..4], a2+b220, b=a]
[(2,1),(5,2),(8,2),(10,3),(13,3),(18,3),(17,4)]
Let's assign this to an intermediate variable so we can query it's type:
Prelude let lst = [(a ^ 2 + b ^ 2, a) | a - [1..4], b - [1..4], a^2 +
b^2 20, b = a]
Prelude lst
[(2,1),(5,2),(8,2),(10,3),(13,3),(18,3),(17,4)]
Prelude :t lst
lst :: [(Integer, Integer)]
aha; here's the source of the type mismatch:
Prelude :t floor
floor :: (RealFrac a, Integral b) = a - b
Floor has to take a RealFrac. According to hoogle[1], we can use various
floating-point approximations (Float, Double, CFloat, etc) or we can use
the exact Rational type.
[1] http://haskell.org/hoogle/?q=RealFrac
You can get your types to match by declaring your list to be of type
[(Rational, Rational)] either by explicitly typing one of the untyped
variables or the entire expression:
Prelude let lst = [(a ^ 2 + b ^ 2, a) | (a::Rational) - [1..4], b -
[1..4], a^2 + b^2 20, b = a]
Prelude :t lst
lst :: [(Rational, Rational)]
Prelude let lst :: [(Rational, Rational)] = [(a ^ 2 + b ^ 2, a) | a -
[1..4], b - [1..4], a^2 + b^2 20, b = a]
Prelude :t lst
lst :: [(Rational, Rational)]
and this works
So now I try to apply the function to the list:
Prelude map (f) [(a2+b2,a)| a - [1..4] , b- [1..4], a2+b220, b=a]
and I get this result:
interactive:1:5:
Ambiguous type variable `t' in the constraints:
`Integral t' arising from use of `f' at interactive:1:5
`RealFrac t' arising from use of `f' at interactive:1:5
Probable fix: add a type signature that fixes these type variable(s)
I'm sorry, but I don't quite get how to set the type signature and how it
will apply to my function...
Thanks,
Hope this helps
Tomi
Department for Education, Sport and Culture E Mail
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify
the sender. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the
intended recipient. The Department for Education, Sport and Culture and
any of its establishments each reserve the right to monitor all e-mail
communications through its networks.
Any views expressed in this message are those of the individual sender,
except where the message states otherwise and the sender is authorised to
state them to be the views of any such entity.
The Department for Education, Sport and Culture shall not be liable to the
recipient or any third party for any loss or damage, however it appears,
from this e-mail or its content. This includes loss or damage caused by
viruses. It is the responsibility of the recipient to ensure that the
opening of this message and its
[Haskell] (no subject)
Hi all! The List module provides isPrefixOf, isSuffixOf, and -- since recently -- isInfixOf, to check whether a list is a prefix, a suffix, or an infix to another list. Similarly, we have inits and tails to obtain the prefixes and the suffixes of a list, but there is no standard function that would return a list of infixes. For reasons of symmetry, perhaps it is worth having a function in List returning, say, a list of infixes of fixed length, such as e.g., infixes n as = map (take n) $ take (length as - n + 1) (tails as) Or, instead, there might be included a function that lists all infixes lexicographically (map (tail . inits) . tails) or perhaps otherwise, e.g. in the order of increasing/decreasing lengths. (In the latter case, the result might be a list of lists of same-length infixes each.) What do you think? Regards, Boyko ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] (no subject)
[Foundations of AOP and AO languages have benefitted from the functional programming community for a while now. Haskellers, please have a look. Thanks! Ralf] Call For Papers FOAL: Foundations of Aspect-Oriented Languages 2007 A one day workshop affiliated with AOSD 2007 in Vancouver, British Columbia. Submission Deadline: 23:00 GMT, 10 January 2007 Notification of Acceptance: 2 February 2007 Final Versions of Papers Due: 1 March 2007 Workshop: 13 March 2007 Themes and Goals FOAL is a forum for research in foundations of aspect-oriented programming languages. Areas of interest include but are not limited to: * Semantics of aspect-oriented languages * Specification and verification for such languages * Type systems * Static analysis * Theory of testing * Theory of aspect composition * Theory of aspect translation (compilation) and rewriting The workshop aims to foster work in foundations, including formal studies, promote the exchange of ideas, and encourage workers in the semantics and formal methods communities to do research in the area of aspect-oriented programming languages. All theoretical and foundational studies of this topic are welcome. The goals of FOAL are to: * Make progress on the foundations of aspect-oriented programming languages. * Exchange ideas about semantics and formal methods for aspect-oriented programming languages. * Foster interest within the programming language theory and types communities in aspect-oriented programming languages. * Foster interest within the formal methods community in aspect-oriented programming and the problems of reasoning about aspect-oriented programs. Workshop Format The planned workshop format is primarily presentation of papers and group discussion. Talks will come in three categories: long (30 minutes plus 15 minutes of discussion), regular (20 minutes plus 5 minutes of discussion) and short (7 minutes plus 3 minutes of discussion). The short talks will allow for presentations of topics for which results are not yet available, perhaps for researchers who are seeking feedback on ideas or seek collaborations. We also plan to ensure sufficient time for discussion of each presentation by limiting the overall number of talks. Submissions Invitation to the workshop will be based on papers selected by the program committee; those wishing to attend but not having a paper to submit should contact the organizers directly to see if there is sufficient space in the workshop. FOAL solicits long, regular, and short papers on all areas of formal foundations of AOP languages. Submissions will be read by the program committee and designated reviewers. Papers will be selected for long, regular, and short presentation at the workshop based on their length, scientific merit, innovation, readability, and relevance. Papers previously published or already being reviewed by another conference are not eligible. Some papers may not be selected for presentation, and some may be selected for presentation in shorter talks than their paper length would otherwise command. We will limit the length of paper presentations and the number of papers presented to make sure that there is enough time for discussion. Papers presented at the workshop will be included in a technical report (from Iowa State University). Authors will retain their own copyright to the papers. Publication of papers at other venues will thus remain possible. We will also investigate having a special issue of a journal for revisions of selected papers after the workshop. Authors should note the following details: * Submissions are due no later than 23:00 GMT, 10 January 2007. (This is a firm deadline.) * Authors must indicate whether they wish to be considered for a long, regular, or short presentation. * Papers for long presentations must not exceed 10 pages in length; those for regular presentations must not exceed 7 pages in length, and those for short presentations must not exceed 3 pages in length. * Some papers may not be selected for presentation, and some may be selected for presentation in shorter talks than requested. * We encourage use of the ACM Conference format http://www.acm.org/sigs/pubs/proceed/template.html for submissions, as this will be required for accepted papers. You must add page numbers (which are not part of the standard format) to your submissions, to make adding comments easier. * Submissions are to be made to the following URL: http://continue.cs.brown.edu/servlets/foal07/continue.ss We will notify the corresponding author of papers that are selected for presentation at the workshop by 2 February 2006. Early registration for AOSD (you must register for AOSD to attend the workshop) is 9
[Haskell] (no subject)
From: John Peterson [EMAIL PROTECTED] To: haskell@haskell.org Subject: Blown disk on haskell.org Sorry for the downtime - haskell.org lost a disk today. Everything is back to normal (I hope). If you have software installed there, we upgraded to a new OS. Hope this doesn't break anything! John ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] (no subject)
Gtk2Hs - A Haskell GUI library based on the Gtk+ GUI Toolkit. Version 0.9.7.1 is now available from: http://gtk2hs.sourceforge.net/ This release is only needed for Windows users. If you have version 0.9.7 working there is no need to upgrade. Source and binary packages are available for Windows. There are binary packages for Gtk+ 2.4.x and 2.6.x. The binary packages require GHC 6.2.2. You may wish to use Gtk+ 2.6 since it follows the Windows native look and themes whereas Gtk+ 2.4 did not. Installation on Windows is fairly straightforward. There is an installer for Gtk+ on Windows and installing Gtk2Hs just involves unzipping and running a batch file. Instructions are here: http://gtk2hs.sourceforge.net/archives/2005/02/17/installing-on-windows/ For future Gtk2Hs releases we hope to provide an MSI installer to make it even easier. Changes since 0.9.7: * build fixes for Windows * almost all modules now carry LGPL 2.1 license * a couple of extra functions are now bound Other changes and news since the last release announcement: * there is an introductory article by Kenneth Hoste in the first issue of The Monad.Reader: http://www.haskell.org/hawiki/TheMonadReader_2fIssueOne * a complete website redesign * many new screenshots: http://sourceforge.net/project/screenshots.php?group_id=49207 * packages of version 0.9.7 are available for Gentoo and FreeBSD Please report all problems to [EMAIL PROTECTED] . Contributions and feedback are also most welcome. Duncan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] (no subject)
Hi. I'm trying to use the hs-plugins with ghci for Windows. Do you know how to do it? I've tried several ways to install the and I haven't managed it. Thanks for your help This message was sent using IMP, the Internet Messaging Program. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Module Initialisation? (was Re: [Haskell] (no subject))
On Sun, Oct 17, 2004 at 01:53:22PM +0100, Ben Rudiak-Gould wrote: [snip] Since a lot of the concerns expressed about this seem to centre around possible abuse of arbitrary IO operations in these top level constructions, maybe the problem could be addressed by insisting that a restricted monad was used, call it SafeIO say. How about (forall s. ST s)? We can require module init actions to have a type (forall s. ST s a) instead of IO a. The compiler or RTS wraps the actions with stToIO (which is a safe function) before executing them. Benefits: * It's just as easy as before to allocate global refs (and global mutable arrays). * It's still possible to perform arbitrary IO actions (e.g. FFI calls), but you have to wrap them in unsafeIOToST -- a good thing since they really are unsafe. unsafeIOToST is much safer than unsafePerformIO when used in this way. Problems: * stToIO (newSTRef 'x') doesn't have type IO (IORef Char). This problem can be solved by adopting a reform that I've wanted for a long time anyway: make IO, IORef, etc. aliases for (ST RealWorld), (STRef RealWorld), etc. instead of completely different types. Then stToIO is the identity function and we only need a single set of state-thread functions instead of the parallel IO and ST equivalents that we have currently. It definitely sounds nice, but is it actually possible to generalize e.g. MVar from RealWorld to forall s or are we always going to have to say: v - unsafeIOToST (newMVar / newChan ... ) GHC's definition: data MVar a = MVar (MVar# RealWorld a) -- Nobody can be exactly like me. Even I have trouble doing it. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Module Initialisation? (was Re: [Haskell] (no subject))
Remi Turk wrote: It definitely sounds nice, but is it actually possible to generalize e.g. MVar from RealWorld to forall s or are we always going to have to say: v - unsafeIOToST (newMVar / newChan ... ) I hadn't thought of that, but I don't think there's any problem with type MVar = STMVar RealWorld newMVar :: a - ST s (STMVar s a) withMVar :: STMVar s a - (a - ST s b) - ST s b ... For that matter it seems like we could (should?) have forkST :: ST s () - ST s (STThreadId s) forkIO = forkST and so on. -- Ben ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Module Initialisation? (was Re: [Haskell] (no subject))
On Sun, Oct 17, 2004 at 05:11:02PM +0100, Ben Rudiak-Gould wrote: Remi Turk wrote: It definitely sounds nice, but is it actually possible to generalize e.g. MVar from RealWorld to forall s or are we always going to have to say: v - unsafeIOToST (newMVar / newChan ... ) I hadn't thought of that, but I don't think there's any problem with type MVar = STMVar RealWorld newMVar :: a - ST s (STMVar s a) withMVar :: STMVar s a - (a - ST s b) - ST s b ... For that matter it seems like we could (should?) have forkST :: ST s () - ST s (STThreadId s) forkIO = forkST and so on. -- Ben But what semantics would they have? It cannot be the normal concurrency as AFAIK runST is supposed to be deterministic. Groetjes, Remi -- Nobody can be exactly like me. Even I have trouble doing it. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Module Initialisation? (was Re: [Haskell] (no subject))
On Sunday 17 Oct 2004 4:45 am, Wolfgang Thaller wrote: Adrian Hey wrote: I'm puzzled about this idea of module init action in a declarative language. Perhaps, if it's desirable to have some module initialisation applied to a module if anything from it is used, the way to do this would be to have a reserved identifier specially for the purpose, like main, but at the module level. (Though this idea still seems a bit strange to me). I don't see what's so strange about that. What's strange about it IMHO is that at the moment the mere presence of some definition in a module has no effect on actual programs. What counts is whether or not defined thing is actually connected to the top level main via some chain of explicit (I.E. named) dependency. This is a property I would like to preserve. If I've understood the proposal correctly, we'd lose this. At least, it's not any stranger than on-demand execution of IO actions in a pure functional language. And the toplevel - is definitely a natural syntax for that. True, but maybe this isn't neccessary, and even if it is, performing the IO creation acts only if the created thing is actually used by a program still seems the lesser of two evils to me. Of course used could mean one of at least two different things.. 1- The compiler does some kind of dependency analysis and mops up all referenced things which must be created into some kind of pre-main action. 2- Things which must be created are just compiled into some kind of thunk which gets reduced (post-main), if and when it is actually required by a running program. Option 1 seems like quite a difficult thing to implement, but does have the advantage that well defined semantics could be given to arbitrary IO operations. It also has the disadvantage that a some of these may be redundant (just because something is referenced doesn't imply that is will actually be used in any given program run). Option 2 seems easier to implement and is nice and lazy, but suffers from semantic ambiguity if arbitrary IO operations are allowed (encouraged). But do we need to do this? I'm begining think maybe we don't. The only reason it seems like we do is because currently the only way of creating IORefs and wotnot is via the IO monad, but this need not be so IMO. You're taking away a feature I want to use. Sorry, I didn't mean to deprive you of something you would find useful. But maybe it should be considered as a separate issue. It's not clear to me how the compiler (or Joe programmer for that matter) would determine and/or control which modules initialisation actions would be executed or not, if there's no obvious connection to the top level main. 1) Initialising global IORefs is a good thing, no matter when it's actually done. Yes, the hypothetical SafeIO monad allows you to do this (what you can't do is read or write IORefs). 2) Being able to initialize things at program startup is a good thing, even if they're not explicitly referred to. Well here is where we disagree I think. Not that I think this is a bad thing as such, but the rules that determine which modules init actions do or don't get invoked seem quite unclear to me if there's no requirement that they are referenced from main, directly or indirectly. But maybe you could clarify what you have in mind? Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Module Initialisation? (was Re: [Haskell] (no subject))
Remi Turk wrote: On Sun, Oct 17, 2004 at 05:11:02PM +0100, Ben Rudiak-Gould wrote: I don't think there's any problem with type MVar = STMVar RealWorld newMVar :: a - ST s (STMVar s a) withMVar :: STMVar s a - (a - ST s b) - ST s b ... For that matter it seems like we could (should?) have forkST :: ST s () - ST s (STThreadId s) forkIO = forkST But what semantics would they have? It cannot be the normal concurrency as AFAIK runST is supposed to be deterministic. Okay, so I'm being silly. Forget forkST then. But STMVar is still okay, isn't it? The only MVars you could use in a state thread would be those you'd created in the same state thread, and without forkST they can't be accessed in a nondeterministic way. Their presence is pointless, true, but at least not unsafe. It does seem a bit of a hack, but it still seems preferable to the other alternatives currently on the table (namely unrestricted IO, a new SafeIO, or unsafeIOToST.newMVar). -- Ben ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Module Initialisation? (was Re: [Haskell] (no subject))
On Sun, Oct 17, 2004 at 07:20:28PM +0100, Ben Rudiak-Gould wrote: Remi Turk wrote: On Sun, Oct 17, 2004 at 05:11:02PM +0100, Ben Rudiak-Gould wrote: I don't think there's any problem with type MVar = STMVar RealWorld newMVar :: a - ST s (STMVar s a) withMVar :: STMVar s a - (a - ST s b) - ST s b ... For that matter it seems like we could (should?) have forkST :: ST s () - ST s (STThreadId s) forkIO = forkST But what semantics would they have? It cannot be the normal concurrency as AFAIK runST is supposed to be deterministic. Okay, so I'm being silly. Forget forkST then. But STMVar is still okay, isn't it? The only MVars you could use in a state thread would be those I won't ever remind you of your being silly if you tell me about the current state of your implicit-(parameter|return)-IO story ;) STMVar does indeed still seem okay, except that I have no idea if it actually makes any sense outside of IO. (That is: newSTMVar x = unsafeIOToST (newMVar x) seems a bit pointless and might be the actual way it needs to be implemented. Has a vague feeling of being silly too now...) By the way, I'm still in favour of `type IO a = ST RealWorld a': It just seems wrong to either let's just make it IO or having to sprinkle stToIO's around... you'd created in the same state thread, and without forkST they can't be accessed in a nondeterministic way. Their presence is pointless, true, but at least not unsafe. It does seem a bit of a hack, but it still seems preferable to the other alternatives currently on the table (namely unrestricted IO, a new SafeIO, or unsafeIOToST.newMVar). -- Ben I'm waiting to be convinced either way ;) Groetjes, Remi -- Nobody can be exactly like me. Even I have trouble doing it. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Module Initialisation? (was Re: [Haskell] (no subject))
Adrian Hey wrote: I'm puzzled about this idea of module init action in a declarative language. Perhaps, if it's desirable to have some module initialisation applied to a module if anything from it is used, the way to do this would be to have a reserved identifier specially for the purpose, like main, but at the module level. (Though this idea still seems a bit strange to me). I don't see what's so strange about that. At least, it's not any stranger than on-demand execution of IO actions in a pure functional language. And the toplevel - is definitely a natural syntax for that. I've interpreted this correctly this means that someAction will always get executed, whether or not foo (or anything dependent on foo) is used elsewhere? This seems like a bad thing to me. It's a feature. I'd actually _want_ to use that one independently. It may be harmless enough if all it does is create a few IORefs which are then promptly garbage collected, but in some situations it could involve quite complex and expensive initialisation operations on foreign libraries (for example). Well if you want those IO operations to be lazily interleaved with the rest of the program (or not executed at all), you can use valueToBeInitedLazily - unsafeInterleaveIO $ do blah ... which explicitly says what you are doing that might be slightly unsafe. Since a lot of the concerns expressed about this seem to centre around possible abuse of arbitrary IO operations in these top level constructions, maybe the problem could be addressed by insisting that a restricted monad was used, call it SafeIO say. You're taking away a feature I want to use. 1) Initialising global IORefs is a good thing, no matter when it's actually done. 2) Being able to initialize things at program startup is a good thing, even if they're not explicitly referred to. 3) Lazy, on-demand initialization of things is a good thing, if you know what you're doing. 4) Lazy, on-demand initialization of things (with potential side effects) is a bad thing, if you don't know what you're doing. If we define toplevel IO bindings to be just like the unsafePerformIO hack, we get 1,3 and 4 (and 4 is actually a bad thing). If we define toplevel IO bindings as mdo-style module initialisation, we get 1 and 2 directly, and 3 with an obvious use of unsafeInterleaveIO. We don't get 4, because obviously, when you use unsafeInterleaveIO, you're already claiming to know what you're doing. Also note that if useless initialization of IORefs ever becomes a problem, we can still use lots of nasty hacks inside the compiler to optimize for those common functions. But I don't think we'll ever have to do this. Cheers, Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Module Initialisation? (was Re: [Haskell] (no subject))
On Thursday 14 Oct 2004 10:18 am, Simon Marlow wrote: On 13 October 2004 16:17, Wolfgang Thaller wrote: We could get away with desugaring them to some very unsafe non-IO- bindings and having the module init action do something evil to make the IO happen in the right order... should be possible to make that look exactly like mdo from the outside. We'll end up using the unsafePerformIO hack inside the implementation again, so that people end up with two IORefs instead of one, but that should be cheap enough: foo - someAction ... could be transformed into ... foo_var = unsafePerformIO $ newIORef (throw NonTermination) foo_action = someAction = writeIORef foo_var foo = unsafePerformIO $ readIORef foo ... with the appropriate NOINLINEs. The module init action would then make sure that foo_action gets invoked. Yes, we could do that. The fact that we're using NOCSE/NOINLINE internally still seems very fragile, though. Oh well, perhaps we have to live with that if we don't want the pain of a special binding type throughout the compiler. I'm puzzled about this idea of module init action in a declarative language. Perhaps, if it's desirable to have some module initialisation applied to a module if anything from it is used, the way to do this would be to have a reserved identifier specially for the purpose, like main, but at the module level. (Though this idea still seems a bit strange to me). Also, I'm still not convinced that mdo is something I want emulated anyway, (well not if it means doing something like the above). If I've interpreted this correctly this means that someAction will always get executed, whether or not foo (or anything dependent on foo) is used elsewhere? This seems like a bad thing to me. It may be harmless enough if all it does is create a few IORefs which are then promptly garbage collected, but in some situations it could involve quite complex and expensive initialisation operations on foreign libraries (for example). Since a lot of the concerns expressed about this seem to centre around possible abuse of arbitrary IO operations in these top level constructions, maybe the problem could be addressed by insisting that a restricted monad was used, call it SafeIO say. So we'd have something like this: initIORef :: a - SafeIO (IORef a) initMVar :: a - SafeIO (MVar a) initEmptyMVar :: SafeIO (MVar a) liftSafeIO:: SafeIO a - IO a The idea being that from within SafeIO you couldn't read or modify IORefs or do any other IO operation, all you could do is create new ones (or incorporate existing ones into the data structure). Wouldn't this + mdo suffice for the safe construction and initialisation of complex mutable data structures (which is probably all people want most of the time)? I guess you'd still need a get out occasionally, especially for FFI.. flakyLiftIO :: IO a - SafeIO a :-) So at the top level you'd probably have.. myThing :: Thing myThing - safeNewThing safeNewThing :: SafeIO Thing safeNewThing = mdo ... newThing :: IO Thing newThing = liftSafeIO safeNewThing Now that all seems so simple, I'm certain I must have overlooked something :-( Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] (no subject)
b) Some predetermined order, with semantics like mdo: Hmm, I just realized that this also means we can execute moduke intialisation code that returns no result using: _ - do ... I like that, I desperately need that for my Objective-C binding... So the extension with the specified order actually allows one to do more things than the unsafePerformIO hack. I wouldn't care about specifying the order otherwise. If the default order is wrong, people can still use unsafeInterleaveIO. GHC already has an initialisation procedure for each module in the program which could be adapted to run the initialisation-time IO actions, with a little effort. Hmm, doesn't the initialisation procedure run before the Stg machine is properly set up? I guess all the GHC init code could do is to register IO actions to be executed later (but before main is run). We probably want all the GHC module init procedures to be run before we execute any IO actions. I'm more worried about what other changes we have to make to the compiler: if we can avoid having to flag top-level bindings as monadic/non-monadic all the way through the compiler, then we could avoid a pervasive change to the compiler. At the moment I can't see an obvious way to do that. We could get away with desugaring them to some very unsafe non-IO- bindings and having the module init action do something evil to make the IO happen in the right order... should be possible to make that look exactly like mdo from the outside. We'll end up using the unsafePerformIO hack inside the implementation again, so that people end up with two IORefs instead of one, but that should be cheap enough: foo - someAction ... could be transformed into ... foo_var = unsafePerformIO $ newIORef (throw NonTermination) foo_action = someAction = writeIORef foo_var foo = unsafePerformIO $ readIORef foo ... with the appropriate NOINLINEs. The module init action would then make sure that foo_action gets invoked. So we'd only need to annotate modules with a list of init actions and extend the RTS appropriately for that... Cheers, Wolfgang -- GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] (no subject)
Hello dear haskellers: My name is Alfonso Meléndez I work in Computer Science in a Colombian University. Right now, I am developing an application for discrete mathematics and I need to comunicate Java with Haskell, more precisely I use Java for the interface of the application and from here I need to call several Haskell Functions. In Haskell.org there are two libraries ( Java Bridge and JNI) that communicate Haskell with Java (but not viceversa). Is there and easy and direct way to do this job? Thank you!!! Alfonso Meléndez Dirección de Proyectos Facultad de Ingeniería de Sistemas Escuela Col de Ingeniería Tels: 676266,6763888, Ext: 224, 371 Cel: (315) 8938216 This e-mail message has been scanned for Viruses and Content and cleared by NetIQ MailMarshal ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
