Re: [Haskell-community] (no subject)
Hello Prajawal, Let me know which project(s) you are interested in and I can provide you with the contact information. Cheers Jasper On Sun, Mar 04, 2018 at 02:19:28PM +0530, prajawal sinha wrote: > Hey!!! where could I get haskell gsco mentors contact from? > ___ > Haskell-community mailing list > Haskell-community@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
[Haskell-community] (no subject)
Hey!!! where could I get haskell gsco mentors contact from? ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
[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
[Haskell-cafe] (no subject)
Hi all, Haskell, is arguably the best example of a design-by-committee language. The syntax is clean and most importantly, consistent. The essence of a purely functional programming is maintained, without disturbing its real world capacity. To all the people who revise the Haskell standard, and implement the language, 1. Promise to me, and the rest of the community, that you will keep up the good effort :) 2. Promise to me, and the rest of the community, that Haskell will always spiritually remain the same clean, consistent programming language as it is now! Regards, Zed Becker ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On Mon, Jun 10, 2013 at 05:41:05PM +0530, Zed Becker wrote: Haskell, is arguably the best example of a design-by-committee language. You do realize that design-by-committee is generally understood to refer to the antipattern where a committee discusses a design to death and delivers an inconsistent, mediocre spec, as opposed to a situation where a leader figure takes the loose ends, runs with them, and turns them into a coherent, inspiring whole? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On Mon, Jun 10, 2013 at 05:41:05PM +0530, Zed Becker wrote: Haskell, is arguably the best example of a design-by-committee language. The syntax is clean and most importantly, consistent. The essence of a purely functional programming is maintained, without disturbing its real world capacity. To all the people who revise the Haskell standard, and implement the language, 1. Promise to me, and the rest of the community, that you will keep up the good effort :) 2. Promise to me, and the rest of the community, that Haskell will always spiritually remain the same clean, consistent programming language as it is now! Hear hear! Hopefully we, the Haskell community, will be able to support this endevour with our time and efforts. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
Zed, while I don't disagree regarding the clean and consistent syntax of Haskell, do you realize that some people would argue that camels are horses designed by committee too? :) While designing by committee guarantees agreement across a large number of people, it does not always ensure efficiency, as committees may lead to poor compromises, sometimes. However, Haskell may be an example of a good case of design-by-committee computer language. Flavio Flavio Villanustre On Mon, Jun 10, 2013 at 8:11 AM, Zed Becker zed.bec...@gmail.com wrote: Hi all, Haskell, is arguably the best example of a design-by-committee language. The syntax is clean and most importantly, consistent. The essence of a purely functional programming is maintained, without disturbing its real world capacity. To all the people who revise the Haskell standard, and implement the language, 1. Promise to me, and the rest of the community, that you will keep up the good effort :) 2. Promise to me, and the rest of the community, that Haskell will always spiritually remain the same clean, consistent programming language as it is now! Regards, Zed Becker ___ 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] (no subject)
Hm... Haskell was /developed/ by teams, but we had BEFORE: hope, miranda, ML ... The heritage is quite important. And individuals (say, Mark Jones) contributed to Haskell constructs. So, the /design/ is not entirely committe based 1. Promise to me, and the rest of the community, that Haskell will always spiritually remain the same clean, consistent programming language as it is now! Yes. Dear Mom, dear Dad! Promise me that you will never die... I wish that for all of you. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
It really sounds rude, to demand promises from somebody who just gave you a big present. Отправлено с iPhone 10.06.2013, в 16:11, Zed Becker zed.bec...@gmail.com написал(а): Hi all, Haskell, is arguably the best example of a design-by-committee language. The syntax is clean and most importantly, consistent. The essence of a purely functional programming is maintained, without disturbing its real world capacity. To all the people who revise the Haskell standard, and implement the language, Promise to me, and the rest of the community, that you will keep up the good effort :) Promise to me, and the rest of the community, that Haskell will always spiritually remain the same clean, consistent programming language as it is now! Regards, Zed Becker ___ 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] (no subject)
On Mon, Jun 10, 2013 at 05:44:26PM +0400, MigMit wrote: It really sounds rude, to demand promises from somebody who just gave you a big present. Without wishing to preempt Zed Becker, I interpreted his email as an expression of delight at how well Haskell has been designed and of hope that it may endure, rather than literally as a demand for the Haskell committee to grant him promises. I hope I haven't misunderstood. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
I have ever wondered how a committee could have made Haskell. My conclusion is the following: For one side there were many mathematicians involved, the authors of the most terse language(s) existent: the math notation. For the other, the lemma avoid success at all costs which kept the committee away of pressures for doing it quick and dirty and also freed it from deleterious individualities 2013/6/10 Tobias Dammers tdamm...@gmail.com On Mon, Jun 10, 2013 at 05:41:05PM +0530, Zed Becker wrote: Haskell, is arguably the best example of a design-by-committee language. You do realize that design-by-committee is generally understood to refer to the antipattern where a committee discusses a design to death and delivers an inconsistent, mediocre spec, as opposed to a situation where a leader figure takes the loose ends, runs with them, and turns them into a coherent, inspiring whole? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Alberto. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On 11/06/2013, at 1:58 AM, Alberto G. Corona wrote: I have ever wondered how a committee could have made Haskell. A committee made Algol 60, described as an improvement on most of its successors. A committee maintains Scheme. On the other hand, an individual gave us Perl. And an individual gave us JavaScript. And let's face it, an individual gave C++ its big start. ___ 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)
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-cafe] (no subject)
Hi Ertugrul, Thank you for the detailed reply. From what you wrote, partial FFI still seems like the way to go. Unfortunately Ogre isn't the only large library I'm using, so difficult several times over sounds like a good way to handicap the project early on. I'm perfectly happy to use Haskell for the strengths that will most benefit my project. I can always go back and try to bring the C++ specific parts into the fold once a prototype is up and running. As it seems there is a great deal of c/c++ to do either way, I would really appreciate so thoughts towards my original question. What practices in C++ are preferred by Haskell users, in the know, for the parts of the app that will not be pure Haskell? Should I be looking to avoid OOP? Dependency Injection? I wont reiterate all the facets of the first post, but it would help me immensely to zero in on a few patterns and strategies that can minimized the damage I inflict in c++ land. Thanks, Casey p.s. With That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there. What do you mean? Which packages should I be looking at? I am on iOS like I said, its a stage 1 GHC compiler so I don't have access to GHCI or template haskell. Casey Basichis caseybasichis at gmail.com wrote: I'm not entirely sure what you mean. I'm intending on using Ogre for GUI - for which there is the Hogre bindings, but after emailing the DEV about it, I didn't get the impression from his advice that I should be using it for production code. Here is what he suggested: It depends, really. Hogre is good for running Ogre from within Haskell, but it has its limitations. The number one thing people have been struggling with is handling input with hogre - there's Hois (Haskell wrapper for OIS) but it's not perfect (it misses input events), and the other option is having to write some C++ glue. Hogre is a solid proof of concept and you can do some demos with it, but if you're e.g. writing a game it might be a bit of a struggle. In the end it's about how much you value being able to write code in Haskell (or how allergic to C++ you are). I'm on iOS so I imagine those difficulties are compounded. I am using several other C++ libraries for which there are no existing bindings and no Haskell alternative packages that are even remotely close. Are you suggesting it would be better to write all my own FFI bindings for all the needed libraries? That's not what I'm suggesting. It was just too little information to properly judge the difficulty of doing everything in Haskell. Binding to Ogre (or C++ in general) is indeed difficult. If Hogre doesn't work or is too limited, your best option might be to write a C wrapper around the Hogre functionality you need. Another option is to use SDL/OpenGL directly, which may be easier or harder depending on your application. However, if you can build the bridge between your rendering library and Haskell, then Haskell is certainly the better choice. Everything I read suggests that Haskells strengths are in transformation and that interaction is not its strong suit. I am interested in your thoughts and I am open to whatever, but you are the first to suggest that the mix is a bad idea. That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there. Nowadays you can write all sorts of interactive applications in Haskell, including GUIs, TUIs, games, simulations and web applications. However, I've long been waiting for useful bindings to Ogre or Irrlicht, but I'm afraid that it's not going to happen any time soon. Ultimately it's your choice. Let me summarize the possiblities: * C wrapper around Ogre. Easy integration, but need to write the rendering code in C/C++. * Full FFI bindings to Ogre. Difficult integration, but you can write your rendering code in Haskell. * Partial FFI bindings to Ogre. Integration may be somewhat easy, if you do the initialization in Haskell and the actual rendering in C/C++. However, this again requires to write the rendering in C/C++. * Using SDL/OpenGL directly: Everything available for Haskell. May be difficult, because you need to write OpenGL code. I hope, this helps. Greets, Ertugrul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[no subject]
Hello, I was just doing some work with Template Haskell and I noticed that the AST does not have support for record puns and wild-cards. I know that these could be desugared into ordinary record patterns but I think that it would be more convenient for users (and also more consistent with the rest of the AST) if we provided direct support for them. So I propose to change: type FieldPat = (Name, Pat) to data FieldPat = RecordFileldP Name Pat -- x = P | RecordPunP Name -- x | RecordWildP -- .. Would there be any objections to doing so? If not, I'd be happy to have a go at making the change. -Iavor ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[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-cafe] (no subject)
buildPair = do arr - newArray ((1,1),(1,10)) 37 :: ST s (STArray s (Int,Int) Int) a - readArray arr (1,1) writeArray arr (1,1) 64 b - readArray arr (1,1) return (a,b) main = print $ runST buildPair -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[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-cafe] (no subject)
a href=http://dreadscottart.com/mynewwebsite/wp-content/plugins/extended-comment-options/02efpk.html; http://dreadscottart.com/mynewwebsite/wp-content/plugins/extended-comment-options/02efpk.html/a___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [GHC] #5670: Document that Enum Integer is subject to list fusion.
#5670: Document that Enum Integer is subject to list fusion.
-+--
Reporter: nomeata | Owner:
Type: bug | Status: patch
Priority: high | Milestone: 7.4.2
Component: Documentation | Version: 7.0.4
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Documentation bug
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by mail@…):
commit 4a3b8c3f6d9e86ff0df2595484f71bc85d4fca37
{{{
Author: Joachim Breitner m...@joachim-breitner.de
Date: Thu Dec 1 22:31:05 2011 +0100
Documentation update: Enumerations of Integers are subject to list
fusion (#5670)
docs/users_guide/glasgow_exts.xml |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5670#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5670: Document that Enum Integer is subject to list fusion.
#5670: Document that Enum Integer is subject to list fusion. +--- Reporter: nomeata| Owner: Type: bug| Status: closed Priority: high | Milestone: 7.4.2 Component: Documentation |Version: 7.0.4 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Changes (by pcapriotti): * status: patch = closed * resolution: = fixed Comment: Merged to stable as 09a58302c560e01af7c28b65c1efa45439d5b7b8. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5670#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[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
[Haskell-cafe] (no subject)
___ 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 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-cafe] (no subject)
Hello, I'm trying to figure out how to handle versioning of my IntervalMap package. I've just read the package versioning policy: http://www.haskell.org/haskellwiki/Package_versioning_policy I don't quite understand all the recommendations in the above document, though: a) You are not allowed to remove or change the types of existing stuff. Ok. b) You are allowed to add new functions. But that can break compilation because of name conflicts. Seems to be allowed on the grounds that this is easy to fix in the client code. c) You are not allowed to add new instances. I don't get this - how is this any worse than b)? I do understand that it is not generally possible to prevent breaking code - for example if the client code depends on buggy behavior that gets fixed in a minor version update. That seems unavoidable - after all, bugfixes are _the_ reason for minor updates. Regards, Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On Thu, Jan 5, 2012 at 10:54 AM, Christoph Breitkopf chbreitk...@googlemail.com wrote: Hello, I'm trying to figure out how to handle versioning of my IntervalMap package. I've just read the package versioning policy: http://www.haskell.org/haskellwiki/Package_versioning_policy I don't quite understand all the recommendations in the above document, though: a) You are not allowed to remove or change the types of existing stuff. Ok. b) You are allowed to add new functions. But that can break compilation because of name conflicts. Seems to be allowed on the grounds that this is easy to fix in the client code. This will never break clients who are using qualified imports, or only importing the symbols they use, which is strongly recommended behavior. c) You are not allowed to add new instances. I don't get this - how is this any worse than b)? Unlike adding functions, there is no way for a client of your library to control which instances they import. Antoine I do understand that it is not generally possible to prevent breaking code - for example if the client code depends on buggy behavior that gets fixed in a minor version update. That seems unavoidable - after all, bugfixes are _the_ reason for minor updates. Regards, Chris ___ 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: [GHC] #5670: Document that Enum Integer is subject to list fusion.
#5670: Document that Enum Integer is subject to list fusion. -+-- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.4.1 Component: Documentation | Version: 7.0.4 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Documentation bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * priority: normal = high * difficulty: = Unknown * status: new = patch * milestone: = 7.4.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5670#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #5670: Document that Enum Integer is subject to list fusion.
#5670: Document that Enum Integer is subject to list fusion. -+-- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal| Component: Documentation Version: 7.0.4 |Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: Documentation bug -+-- The documentation does not mention it, but it is the case (verified in 7.0.4), so the docu should reflect that. Trivial patch attached. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5670 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[Haskell-cafe] (no subject)
Hello, I get this error when I try to derive an instance of the Show typeclass: Abc.hs:21:60:Couldn't match expected type `Vector' with actual type `[Point]'In the first argument of `show'', namely `xs'In the second argument of `(++)', namely `show' xs'In the second argument of `(++)', namely `, ++ show' xs'Failed, modules loaded: none. Here's the faulty code: newtype Point = Point Intinstance Show Point where show (Point a) = [chr $ a + 48] data Vector = Vector [Point]instance Show Vector where show (Vector ys) = let show' (Vector [z]) = show z show' (Vector (x:xs)) = show x ++ , ++ show' xs show' (Vector []) = [] in ( ++ show' ys ++ ) What I'm trying to do, is to print out a vector like Vector [Point 1, Point 2, Point 3] as (1, 2, 3).My question is: what should I change in order to make it work? Best regards, William ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On Mon, Nov 28, 2011 at 4:12 PM, Willem Obbens dub...@hotmail.com wrote: Hello, I get this error when I try to derive an instance of the Show typeclass: Abc.hs:21:60: Couldn't match expected type `Vector' with actual type `[Point]' In the first argument of `show'', namely `xs' In the second argument of `(++)', namely `show' xs' In the second argument of `(++)', namely `, ++ show' xs' Failed, modules loaded: none. Here's the faulty code: newtype Point = Point Int instance Show Point where show (Point a) = [chr $ a + 48] data Vector = Vector [Point] instance Show Vector where show (Vector ys) = let show' (Vector [z]) = show z show' (Vector (x:xs)) = show x ++ , ++ show' xs show' (Vector []) = [] in ( ++ show' ys ++ ) Here you're treating the value 'ys' as if its type was 'Vector', but its type is '[Point]'. Does that help? Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On Mon, Nov 28, 2011 at 04:20:54PM -0600, Antoine Latter wrote: On Mon, Nov 28, 2011 at 4:12 PM, Willem Obbens dub...@hotmail.com wrote: Hello, I get this error when I try to derive an instance of the Show typeclass: Abc.hs:21:60: Couldn't match expected type `Vector' with actual type `[Point]' In the first argument of `show'', namely `xs' In the second argument of `(++)', namely `show' xs' In the second argument of `(++)', namely `, ++ show' xs' Failed, modules loaded: none. Here's the faulty code: newtype Point = Point Int instance Show Point where show (Point a) = [chr $ a + 48] data Vector = Vector [Point] instance Show Vector where show (Vector ys) = let show' (Vector [z]) = show z show' (Vector (x:xs)) = show x ++ , ++ show' xs show' (Vector []) = [] in ( ++ show' ys ++ ) You've made show' :: Vector - String, but I'm guessing you actually want to make it show' :: [Point] - String; i.e. get rid of the Vector constructors in the show' patterns. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
Yes, thank you. Here's my simple fix: newtype Point = Point Int instance Show Point where show (Point a) = [chr $ a + 48] data Vector = Vector [Point] instance Show Vector where show (Vector ys) = let show' [z] = show z show' (x:xs) = show x ++ , ++ show' xs show' [] = [] in ( ++ show' ys ++ ) And I added this function: createPoint :: Int - PointcreatePoint x = Point x When I loaded the file containing all this into ghci and executed 'Vector $ map createPoint [1..5]' the result was '(1, 2, 3, 4, 5)' (without the quotes).This was actually more or less a test question as I'm new to haskell-cafe, but I hope people who will read this message will learn from my mistake. Thank you. From: aslat...@gmail.com Date: Mon, 28 Nov 2011 16:20:54 -0600 Subject: Re: [Haskell-cafe] (no subject) To: dub...@hotmail.com CC: haskell-cafe@haskell.org On Mon, Nov 28, 2011 at 4:12 PM, Willem Obbens dub...@hotmail.com wrote: Hello, I get this error when I try to derive an instance of the Show typeclass: Abc.hs:21:60: Couldn't match expected type `Vector' with actual type `[Point]' In the first argument of `show'', namely `xs' In the second argument of `(++)', namely `show' xs' In the second argument of `(++)', namely `, ++ show' xs' Failed, modules loaded: none. Here's the faulty code: newtype Point = Point Int instance Show Point where show (Point a) = [chr $ a + 48] data Vector = Vector [Point] instance Show Vector where show (Vector ys) = let show' (Vector [z]) = show z show' (Vector (x:xs)) = show x ++ , ++ show' xs show' (Vector []) = [] in ( ++ show' ys ++ ) Here you're treating the value 'ys' as if its type was 'Vector', but its type is '[Point]'. Does that help? Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On Mon, Nov 28, 2011 at 23:55, Willem O dub...@hotmail.com wrote: And I added this function: createPoint :: Int - Point createPoint x = Point x When I loaded the file containing all this into ghci and executed 'Vector $ map createPoint [1..5]' the result was '(1, 2, 3, 4, 5)' (without the quotes). Note that you do not need this function. You can just use the 'Point' constructor: map Point [1..5] Erik ___ 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-cafe] (no subject)
http://elikat.com/blogs/wp-content/plugins/index1.php ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-fr] (no subject)
main = readFile /etc/passwd = mapM_ print . lines ___ Haskell-fr mailing list Haskell-fr@haskell.org http://www.haskell.org/mailman/listinfo/haskell-fr
Re: [Haskell-fr] (no subject)
On Sun, Aug 21, 2011 at 03:42:33PM +0200, Marc Chantreux wrote: main = readFile /etc/passwd = mapM_ print . lines hello, je suis désolé pour les autres messages (modification un peu hative de la conf. de mon mailer). La question était en fait: comment produire une liste paresseuse des lignes d'un fichier. J'aimmerais pouvoir décrire une fonction cat :: filePath - [String] afin de pouvoir écrire des choses telles que mapM_ putStrLn $ filter (isInfixOf root) $ cat /etc/passwd cordialement, marc ___ Haskell-fr mailing list Haskell-fr@haskell.org http://www.haskell.org/mailman/listinfo/haskell-fr
Re: [Haskell-fr] (no subject)
2011/8/21 Marc Chantreux kha...@phear.org: On Sun, Aug 21, 2011 at 03:42:33PM +0200, Marc Chantreux wrote: main = readFile /etc/passwd = mapM_ print . lines hello, Salut, je suis désolé pour les autres messages (modification un peu hative de la conf. de mon mailer). La question était en fait: comment produire une liste paresseuse des lignes d'un fichier. J'aimmerais pouvoir décrire une fonction cat :: filePath - [String] Si la fonction «cat» a ce type alors elle ne peut faire aucun effet de bord. Sa seule donnée en entrée est le nom d'un fichier et comme on le sait on ne peut généralement pas déduire le contenu exacte d'un fichier étant donné son nom :) Tu cherches donc une fonction avec IO dans le type ou une variante permettant d'acceder au système de fichier. Un bon candidat semble être readFile (ou ses cousins getContents et hGetContents). La documentation mentione le fait que cette fonction lit paraisseusement le fichier, ce qui étant donné sont type est un peut étrange... readFile :: FilePath - IO String En effet sont type nous dit que une fois le nom de fichier donné, readFile /etc/passwd est un effet qui va lire le fichier et /etc/passwd et renvoyé sont contenu. Il n'y a donc normalement qu'un seul effet. Enfin bon bref readFile triche un peut mais c'est normalement pas perceptible (malheureusement ça l'est), et l'on appelle cette technique le Lazy IO. Donc si readFile est un bon candidat il nous reste à découper le contenue en une liste de lignes avec lines: lines :: String - [String] cat :: FilePath - IO [String] cat fp = do xs - readFile fp return (lines fp) ou en plus court: cat :: FilePath - IO [String] cat = fmap lines . readFile (fmap, ($), et liftM font la même chose.) Au final, un petit = et le tour est joué: mapM_ putStrLn . filter (isInfixOf root) = cat /etc/passwd (Un autre remarque au passage isInfixOf est fait pour être utilisé en infix : root `isInfixOf` line) ou directement: mapM_ putStrLn . filter (root `isInfixOf`) . lines = readFile /etc/passwd ou aussi putStr . unlines . filter (root `isInfixOf`) . lines = readFile /etc/passwd Amuse toi bien! -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-fr mailing list Haskell-fr@haskell.org http://www.haskell.org/mailman/listinfo/haskell-fr
Re: [Haskell-cafe] (no subject)
On Sat, 2011-07-30 at 15:07 -0700, KC wrote: A language that runs on the JVM or .NET has the advantage of Oracle Microsoft making those layers more parallelizable. On top of the answers you've got regarding whether this exists, let me warn you against making assumptions like the above. There are certainly good reasons for wanting Haskell to run on the JVM or CLR, but parallelism doesn't look like one of them. The problem is that the cost models of things on the JVM or CLR are so different that if you directly expose the threading and concurrency stuff from the JVM or CLR, you're going to kill all the Haskell bits of parallelism. A huge contribution of Haskell is to have very light-weight threads, which can be spawned cheaply and can number in the tens of thousands, if not hundreds of thousands. If you decide that forkIO will just spawn a new Java or CLR thread, performance of some applications will change by orders of magnitude, or they will just plain crash and refuse to run. Differences of that scope are game-changing. So you risk, not augmenting Haskell concurrency support by that of the JVM or CLR, but rather replacing it. And that certainly would be a losing proposition. Maybe there's a creative way to combine advantages from both, but it will require something besides the obvious one-to-one mapping of execution contexts. -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (no subject)
Suppose I have two terms s and t of type a and b respectively, and I want to write a function that returns s applied to t if a is an arrow type of form b - c, and nothing otherwise. How do i convince the compiler to accept the functional application only in the correct instance? Thanks, Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
Ian, This requires dynamic typing using Data.Dynamic (for application) and Data.Typeable (to do the typing). Namely, you are asking for the dynApply function: START CODE import Data.Dynamic import Data.Typeable import Control.Monad maybeApp :: (Typeable a, Typeable b, Typeable c) = a - b - Maybe c maybeApp a = join . fmap fromDynamic . dynApply (toDyn a) . toDyn END CODE In the above we obtain representations of your types in the form of Dynamic data types using toDyn. Then, using dynApply, we get a value of type Maybe Dynamic, which we convert back into a c type with fromDynamic. The join is just there to collapse the type from a Maybe (Maybe c) into the desired type of Maybe c. Cheers, Thomas P.S. If I totally misunderstood, and you want static typing then you just need to realize you _don't_ want types a and b (fully polymorphic) but rather types (b - c) and b: apply :: (b - c) - b - c apply a b = a b But this seems rather silly, so I hope you were looking for my first answer. On Wed, Jul 6, 2011 at 2:12 AM, Ian Childs ian.chi...@hertford.ox.ac.uk wrote: Suppose I have two terms s and t of type a and b respectively, and I want to write a function that returns s applied to t if a is an arrow type of form b - c, and nothing otherwise. How do i convince the compiler to accept the functional application only in the correct instance? Thanks, Ian ___ 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] (no subject)
http://maipenarai.com/lindex02.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
I'm sorry, somehow my e-mail account got kidnapped. The link is a virus and should NOT be opened. I apologise for any inconvenience. Fernando Henrique Sanches 2011/6/13 Fernando Henrique Sanches fernandohsanc...@gmail.com ___ 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] (no subject)
As you my friend I invite you to visit my own site first!. http://prospero.ch/friends_links.php?uGIS=45ru4 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[no subject]
http://www.buonviaggioitaly.com/modules/mod_osdonate/myhome.html ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: (no subject)
On 19/12/2006 08:45, mm wrote: I can not login to the GHC Trac with the login/password suggested at the homepage. Could someone please confirm that it is currently not working? I just tried it here, and it worked for me. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[Haskell-cafe] (no subject)
This is another proof-layout question, this time from Bird 1.4.7. We're asked to define the functions curry2 and uncurry2 for currying and uncurrying functions with two arguments. Simple enough: curry2 :: ((a, b) - c) - (a - (b - c))curry2 f x y = f (x, y) uncurry2 :: (a - (b - c)) - ((a, b) - c)uncurry2 f (x, y) = f x y The following two assertions are obviously true theorems, but how are the formal proofs laid out? 1. curry2 (uncurry2 f) x y = f x y 2. uncurry2 (curry 2 f) (x, y) = f (x, y) _ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccountocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On Wed, May 19, 2010 at 01:37:49PM +, R J wrote:
This is another proof-layout question, this time from Bird 1.4.7.
We're asked to define the functions curry2 and uncurry2 for currying and
uncurrying functions with two arguments. Simple enough:
curry2 :: ((a, b) - c) - (a - (b - c))curry2 f x y = f
(x, y)
uncurry2 :: (a - (b - c)) - ((a, b) - c)uncurry2 f (x, y) = f
x y
The following two assertions are obviously true theorems, but how are the
formal proofs laid out?
There are lots of variations, I wouldn't say there's one right way
to organize/lay out the proofs. But here's how I might do it:
curry2 (uncurry2 f) x y
= { def. of curry2 }
uncurry2 f (x,y)
= { def. of uncurry2 }
f x y
I'll let you do the other one.
By the way, are you working through these problems just for
self-study, or is it homework for a class?
-Brent
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (no subject)
* * * * * * * More o BigCharts o Virtual Stock Exchange o FiLife.com o WSJ Asia o WSJ Europe o WSJ Portuguese o WSJ Spanish o WSJ Chinese o WSJ Japanese o WSJ Radio o Financial News SEARCH * Wednesday, March 31, 2010 Autos o Welcome, William Halchin Logout o + My Account + My Journal + Help + Message Center ( new) * U.S. Edition WSJ.com is available in the following editions and languages: o U.S. o Asia + India + China + Japan o Europe o Americas + en Español + em Português o Login/Register to set your edition o Set my edition o Today's Paper o Video o Columns o Blogs o Topics o Journal Community Register for FREE Register for FREE Thank you for registering. We sent an email to: Please click on the link inside the email to complete your registration Please register to gain free access to WSJ tools. An account already exists for the email address entered. Forgot your username or password? This service is temporary unavailable due to system maintenance. Please try again later. The username entered is already associated with another account. Please enter a different username The email address you have entered is already in use. Please re-enter the email address. o First Name o Last Name o Email (your email address will be your login) o Confirm Email o Create a Password o Confirm Password o Company Size (Optional) From time to time, we will send you e-mail announcements on new features and special offers from The Wall Street Journal Online. Create a profile for me in the Journal Community Why Register? Privacy Policy | Terms Conditions As a registered user of The Wall Street Journal Online, you will be able to: o Setup and manage your portfolio o Personalize your own news page o Receive and manage newsletters Log In Log In Login Password Log in Your login is either a username or an email address. Keep me logged in. Forgot your password? close window Close * Home * World * U.S. * Business * Markets * Tech * Personal Finance * Life Style * Opinion * Careers * Real Estate * Small Business * Asia * Europe * Earnings * Economy * Health * Law * Autos * Management * Media Marketing * expand More Industries up down o Accounting o Advertising o Airlines o Banking o Chemicals o Computer Hardware o Computer Software o Consumer Products o Defense Aerospace o Energy o Broadcasting Entertainment o Financial Services Insurance o Food Tobacco o Hospitality o Industrial Goods Services o Marketing Strategy o Media Agencies o Metals Mining o Paper Forest Products o Pharmaceutical Biotech o Real Estate o Retail o Semiconductors o Transportation o Utilities * Columns Blogs * * Dow Jones Reprints: This copy is for your personal, non-commercial use only. To order presentation-ready copies for distribution to your colleagues, clients or customers, use the Order Reprints tool at the bottom of any article or visit www.djreprints.com See a sample reprint in PDF format. Order a reprint of this article now * The Wall Street Journal * MARCH 31, 2010 Now, Even NASA Is Involved in Toyota Crisis * Article * Comments (2) more in Auto Industry News » * Email * Print * Save This ↓ More * o facebook facebook o Twitter Twitter o Digg Digg o StumbleUpon StumbleUpon o + More close o Yahoo! Buzz o MySpace o del.icio.us o Reddit o LinkedIn o Fark o Viadeo o Orkut * larger Text smaller By BEN WORTHEN U.S. regulators on Tuesday announced a broad investigation into automotive computer systems and software, which have come under scrutiny because of sudden
Re: [Haskell-cafe] (no subject)
Jake McArthur wrote: staafmeister wrote: Yes I know but there are a lot of problems requiring O(1) array updates so then you are stuck with IO again Or use ST. Or use IntMap (which is O(log n), but n is going to max out on the integer size for your architecture, so it's really just O(32) or O(64), which is really just constant time). Actually, IntMap is O(min(n,W)) where W is the number of bits in an Int. Yes, IntMaps are linear time in the worst case (until they become constant-time). In practice this is competitive with all those O(log n) structures though. Whereas Data.Map is O(log n) for the usual balanced tree approach. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
There are also the judy arrays http://hackage.haskell.org/package/HsJudy http://hackage.haskell.org/package/judy dons recently advertised the latter as being 2x faster than IntMap, but I don't know in what respect these two packages differ and why Don decided to create 'judy' despite the existence of HsJudy. 2009/10/15 wren ng thornton w...@freegeek.org: Jake McArthur wrote: staafmeister wrote: Yes I know but there are a lot of problems requiring O(1) array updates so then you are stuck with IO again Or use ST. Or use IntMap (which is O(log n), but n is going to max out on the integer size for your architecture, so it's really just O(32) or O(64), which is really just constant time). Actually, IntMap is O(min(n,W)) where W is the number of bits in an Int. Yes, IntMaps are linear time in the worst case (until they become constant-time). In practice this is competitive with all those O(log n) structures though. Whereas Data.Map is O(log n) for the usual balanced tree approach. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
At Thu, 15 Oct 2009 10:15:46 +0400, Eugene Kirpichov wrote: but I don't know in what respect these two packages differ and why Don decided to create 'judy' despite the existence of HsJudy. HsJudy doesn't compile against the latest judy library (as Don knew) - presumably he had a good reason to start a new package instead of patching the old one. There should be a way to mark packages as deprecated on hackage, and at the same time direct people to a more suitable alternative. Aside from uploading a dummy new version (ugh!), I don't see a way to do that currently. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (no subject)
Martin Sulzmann wrote:
Undecidable instances means that there exists a program for which there's
an infinite reduction sequence.
I believe this may be too strong of a statement. There exists patently
terminating type families that still require undecidable
instances in GHC. Here is an example:
{-# LANGUAGE TypeFamilies #-}
type family I x :: *
type instance I x = x
type family B x :: *
type instance B x = I x
GHC 6.8.3 complaints:
Application is no smaller than the instance head
in the type family application: I x
(Use -fallow-undecidable-instances to permit this)
In the type synonym instance declaration for `B'
But there cannot possibly be any diverging reduction sequence here, can it?
The type family I is the identity, and the type family B is its
alias. There is no recursion. The fact that type families are open is
not relevant here: our type families I and B are effectively closed,
because one cannot define any more instance for I and B (or risk
overlap, which is rightfully not supported for type families).
The reason GHC complains is because it checks termination
instance-by-instance. To see the termination in the above program, one
should consider instances I and B together. Then we will see that I
does not refer to B, so there are no loops. But this global
termination check -- for a set of instances -- is beyond the
abilities of GHC. This is arguably the right decision: after all, GHCi
is not a full-blown theorem prover.
Thus there are perfectly decidable type programs that require
undecidable instances. Indeed, there is no reason to be afraid of that
extension.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On Fri, Aug 21, 2009 at 7:03 PM, Sebastian Sylvansebastian.syl...@gmail.com wrote: I think that there must be standard function that can do this. What do experienced Haskellers use? I usually just whip up a quick parser using Text.ParserCombinators.Parsec I usually prefer ReadP for quick stuff, for an unknown reason. I guess it feels like there is less infrastructure to penetrate, it gives me the primitives and I structure the parser according to my needs. But yeah, I think parser combinators are the way to go. It's really not much work at all once you get the hang of it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
Thank you for the reply. Thomas ten Cate wrote: Although you most certainly can use a State monad, in most problems this isn't necessary. Most algorithms that you need to solve programming contest problems can be written in a purely functional style, so you can limit monadic code to just a few helper functions. Yes I know but there are a lot of problems requiring O(1) array updates so then you are stuck with IO again Thomas ten Cate wrote: For example, this reads input in the style you mention (assuming the strings don't contain whitespace): import Control.Monad answer = id parse [] = [] parse (s:p:r) = (s, (read p) :: Int) : parse r run = getLine getLine = putStrLn . show . answer . parse . words main = flip replicateM_ run = readLn The answer function would be a pure function that computes the answer for a particular run. This main function is reusable for all problems with many runs. Observe that the number of edges (e), provided as a convenience for memory allocation in many other languages, is not even necessary in Haskell :) Yes you're main is short. But how would you do it elegantly if instead of line breaks and spaces one would have only spaces. Every thing on one big line. My C code would not mind one bit. Thomas ten Cate wrote: (If anyone knows a better way than explicit recursion to map over a list, two elements at a time, or zip its even elements with its odd elements, I'd love to hear! I can imagine a convoluted fold with a boolean in its state, but it's ugly.) Yes I missed such a function in a couple of problems I wanted to solve. I would expect a generic function groupN::Int - [a] - [[a]] that groups a list into groups of N Best, Gerben -- View this message in context: http://www.nabble.com/%28no-subject%29-tp25088427p25094244.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On Sat, Aug 22, 2009 at 3:20 PM, staafmeister g.c.stave...@uu.nl wrote: Thank you for the reply. Thomas ten Cate wrote: Although you most certainly can use a State monad, in most problems this isn't necessary. Most algorithms that you need to solve programming contest problems can be written in a purely functional style, so you can limit monadic code to just a few helper functions. Yes I know but there are a lot of problems requiring O(1) array updates so then you are stuck with IO again Not necessarily. The ST monad will usually do just as well. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: quick and dirty file parsing (was: no subject)
From: staafmeister g.c.stave...@uu.nl Thank you for the reply. Thomas ten Cate wrote: Although you most certainly can use a State monad, in most problems this isn't necessary. Most algorithms that you need to solve programming contest problems can be written in a purely functional style, so you can limit monadic code to just a few helper functions. Yes I know but there are a lot of problems requiring O(1) array updates so then you are stuck with IO again Depending on the problem, you may be able to find a better data type than an array. Of course, since we're discussing generalities it's hard to make any specific recommendations. Thomas ten Cate wrote: For example, this reads input in the style you mention (assuming the strings don't contain whitespace): import Control.Monad answer = id parse [] = [] parse (s:p:r) = (s, (read p) :: Int) : parse r run = getLine getLine = putStrLn . show . answer . parse . words main = flip replicateM_ run = readLn The answer function would be a pure function that computes the answer for a particular run. This main function is reusable for all problems with many runs. Observe that the number of edges (e), provided as a convenience for memory allocation in many other languages, is not even necessary in Haskell :) Yes you're main is short. But how would you do it elegantly if instead of line breaks and spaces one would have only spaces. Every thing on one big line. My C code would not mind one bit. If I read it properly, this code won't either. The words function at the end of the pipeline will split tokens on any whitespace. Thomas ten Cate wrote: (If anyone knows a better way than explicit recursion to map over a list, two elements at a time, or zip its even elements with its odd elements, I'd love to hear! I can imagine a convoluted fold with a boolean in its state, but it's ugly.) Yes I missed such a function in a couple of problems I wanted to solve. I would expect a generic function groupN::Int - [a] - [[a]] that groups a list into groups of N I often use this function as well. I think it's not in the libraries because it's so simple to define: groupN :: Int - [a] - [[a]] groupN n [] = [] groupN n xs = let (h,t) = splitAt n xs in h:groupN n t Or, for a nonrecursive version: groupN2 = fix g where g f n [] = [] g f n xs = let (h,t) = splitAt n xs in h: f n t but that's probably not what you had in mind. I've found that using unfoldr is simpler than fold if you wish to use HOFs to accomplish this, but neither is as simple as explicit recursion. John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
staafmeister wrote: Yes I know but there are a lot of problems requiring O(1) array updates so then you are stuck with IO again Or use ST. Or use IntMap (which is O(log n), but n is going to max out on the integer size for your architecture, so it's really just O(32) or O(64), which is really just constant time). And, realistically, very few problems actually require indexed access on a large scale like this. [parsing stuff] As far as parsing is concerned, maybe you should look at Parsec. I know it sounds like overkill, but it's easy enough to use that it's quite lightweight in practice. Your example scenario: inputData :: Parser InputData inputData = many1 digit * newline * many (testCase * newline) where testCase = many1 digit * newline * sepBy edge (char ' ') edge = liftA2 (,) (many nonspace * char ' ') (read $ digits) - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (no subject)
Hi, I'm just started to learn Haskell. Coming from a programming contest background (where it is important to be able to solve problems in a small amount of code) I'm wondering what the best way is for simple IO. A typical input file (in a programming contest) is just a bunch of numbers which you want to read one by one (sometimes interspersed with strings). In C/C++ this is easily done with either scanf or cin which reads data separated by spaces. In Haskell I have not found an equally satisfactionary method. The methods I know of 1) Stay in the IO monad and write your own readInt readString functions. A lot of code for something easy. 2) Use interact together with words and put the list of lexemes in a State monad and define getInt where at least you can use read. 3) Use ByteString.Char8 which has readInt (but I couldn't find a readString). But one has to put it also in a State monad. I think that there must be standard function that can do this. What do experienced Haskellers use? Thanks in advance ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
G.C.Stavenga: Hi, I'm just started to learn Haskell. Coming from a programming contest background (where it is important to be able to solve problems in a small amount of code) I'm wondering what the best way is for simple IO. A typical input file (in a programming contest) is just a bunch of numbers which you want to read one by one (sometimes interspersed with strings). In C/C++ this is easily done with either scanf or cin which reads data separated by spaces. In Haskell I have not found an equally satisfactionary method. The methods I know of 1) Stay in the IO monad and write your own readInt readString functions. A lot of code for something easy. 2) Use interact together with words and put the list of lexemes in a State monad and define getInt where at least you can use read. 3) Use ByteString.Char8 which has readInt (but I couldn't find a readString). But one has to put it also in a State monad. I think that there must be standard function that can do this. What do experienced Haskellers use? map read . lines ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
Don Stewart-2 wrote: G.C.Stavenga: Hi, I'm just started to learn Haskell. Coming from a programming contest background (where it is important to be able to solve problems in a small amount of code) I'm wondering what the best way is for simple IO. A typical input file (in a programming contest) is just a bunch of numbers which you want to read one by one (sometimes interspersed with strings). In C/C++ this is easily done with either scanf or cin which reads data separated by spaces. In Haskell I have not found an equally satisfactionary method. The methods I know of 1) Stay in the IO monad and write your own readInt readString functions. A lot of code for something easy. 2) Use interact together with words and put the list of lexemes in a State monad and define getInt where at least you can use read. 3) Use ByteString.Char8 which has readInt (but I couldn't find a readString). But one has to put it also in a State monad. I think that there must be standard function that can do this. What do experienced Haskellers use? map read . lines Thank you for the reply. But this only works for if you read only integers all on different lines. But in general you have a structure like first line -- integer specifying the number of testcases (n) Then for each testcase a line with an integer specifying the number of edges (e) a line with e pairs of string s and int p where p is the number asociated with string s, etc. Such a structure cannot be parsed by map read.lines What I used is words to tokenize and put the list in a State monad with readInt, readString, etc. functions, to mimic C code. This seems to be a lot of overkill, so there must be an simpler way ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- View this message in context: http://www.nabble.com/%28no-subject%29-tp25088427p25088830.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On Fri, Aug 21, 2009 at 11:42 PM, Stavenga, G.C. g.c.stave...@uu.nl wrote: Hi, I'm just started to learn Haskell. Coming from a programming contest background (where it is important to be able to solve problems in a small amount of code) I'm wondering what the best way is for simple IO. A typical input file (in a programming contest) is just a bunch of numbers which you want to read one by one (sometimes interspersed with strings). In C/C++ this is easily done with either scanf or cin which reads data separated by spaces. In Haskell I have not found an equally satisfactionary method. The methods I know of 1) Stay in the IO monad and write your own readInt readString functions. A lot of code for something easy. 2) Use interact together with words and put the list of lexemes in a State monad and define getInt where at least you can use read. 3) Use ByteString.Char8 which has readInt (but I couldn't find a readString). But one has to put it also in a State monad. I think that there must be standard function that can do this. What do experienced Haskellers use? I usually just whip up a quick parser using Text.ParserCombinators.Parsechttp://www.haskell.org/ghc/docs/latest/html/libraries/parsec/Text-ParserCombinators-Parsec.html -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[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-cafe] (no subject)
Hi, Seems that Haskell allows to specify dummy type variables in a declaration of a type synonym, which do not appear in its right-hand side. This can lead to interesting effects, which appears differently in GHC and Hugs. I would like to know, what behavior is correct according to the haskell 98 report. 1) -- type F a = Int class A a where foo :: A b = a (F b) -- GHC - OK Hugs - Illegal type F b in constructor application 2) -- type F a = Int class A a where foo :: F a instance A Bool where foo = 1 instance A Char where foo = 2 xs = [foo :: F Bool, foo :: F Char] -- GHC: M.hs:14:6: Ambiguous type variable `a' in the constraint: `A a' arising from a use of `foo' at M.hs:14:6-8 Probable fix: add a type signature that fixes these type variable(s) M.hs:14:21: Ambiguous type variable `a1' in the constraint: `A a1' arising from a use of `foo' at M.hs:14:21-23 Probable fix: add a type signature that fixes these type variable(s) Hugs: [1,2] Thanks, Vladimir ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
-- type F a = Int class A a where foo :: A b = a (F b) -- GHC - OK Hugs - Illegal type F b in constructor application This time, I'd say Hugs is wrong (though eliminating that initial complaint leads back to an ambiguous and unusable method 'foo'). 4.2.2 Type Synonym Declarations, lists only class instances as exceptions for type synonyms, and 'Int' isn't illegal there. -- type F a = Int class A a where foo :: F a instance A Bool where foo = 1 instance A Char where foo = 2 xs = [foo :: F Bool, foo :: F Char] -- GHC: M.hs:14:6: Ambiguous type variable `a' in the constraint: `A a' arising from a use of `foo' at M.hs:14:6-8 Probable fix: add a type signature that fixes these type variable(s) M.hs:14:21: Ambiguous type variable `a1' in the constraint: `A a1' arising from a use of `foo' at M.hs:14:21-23 Probable fix: add a type signature that fixes these type variable(s) Hugs: [1,2] Neither seems correct? 4.3.1 Class Declarations, says: The type of the top-level class method vi is: vi :: forall u,w. (C u, cxi) =ti The ti must mention u; .. 'foo's type, after synonym expansion, does not mention 'a'. Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
-- type F a = Int class A a where foo :: A b = a (F b) -- GHC - OK Hugs - Illegal type F b in constructor application This time, I'd say Hugs is wrong (though eliminating that initial complaint leads back to an ambiguous and unusable method 'foo'). I only just recognized the horrible error message from the first example.. what Hugs is trying to tell us about is a kind error! The kind of 'a' in 'F' defaults to '*', but in 'A', 'F' is applied to 'b', which, via 'A b' is constrained to '*-*'. So Hugs is quite right (I should have known!-). The error message can be improved drastically, btw: :set +k ERROR file:.\hugs-vs-ghc.hs:19 - Kind error in constructor application *** expression : F b *** constructor : b *** kind : a - b *** does not match : * See http://cvs.haskell.org/Hugs/pages/hugsman/started.html and search for '+k' - highly recommended if you're investigating kinds. Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[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
[Haskell-cafe] (no subject)
Could someone provide an elegant solution to Bird problem 4.2.13? Here are the problem and my inelegant solution: Problem --- Since concatenation seems such a basic operation on lists, we can try to construct a data type that captures concatenation as a primitive. For example, data (CatList a) = CatNil | Wrap a | Cat (CatList a) (CatList a) The intention is that CatNil represents [], Wrap x represents [x], and Cat x y represents x ++ y. However, since ++ is associative, the expressions Cat xs (Cat ys zs) and Cat (Cat xs ys) zs should be regarded as equal. Define appropriate instances of Eq and Ord for CatList. Inelegant Solution -- The following solution works: instance (Eq a) = Eq (CatList a) where CatNil == CatNil =True CatNil == Wrap z =False CatNil == Catz w = ( z == CatNil w == CatNil ) Wrap x== CatNil =False Wrap x== Wrap z =x == z Wrap x== Catz w = ( Wrap x == z w == CatNil ) || ( Wrap x == w z == CatNil ) Catx y == CatNil =x == CatNil y == CatNil Catx y == Wrap z = ( x == Wrap z y == CatNil ) || ( x == CatNil y == Wrap z ) Catx y == Catz w = unwrap (Cat x y) == unwrap (Cat z w) unwrap :: CatList a - [a] unwrap CatNil= [] unwrap (Wrap x) = [x] unwrap (Cat x y) = unwrap x ++ unwrap y instance (Eq a, Ord a) = Ord (CatList a) where x y = unwrap x unwrap y This solution correctly recognizes the equality of the following, including nested lists(represented, for example, by Wrap (Wrap 1), which corresponds to [[1]]): Wrap 1 == Cat (Wrap 1) CatNil Cat (Wrap 1) (Cat (Wrap 2) (Wrap 3)) == Cat (Wrap 1) (Cat (Wrap 2) (Wrap 3)) Wrap (Wrap 1)== Wrap (Cat (Wrap 1) CatNil) Although this solution works, it's a hack, because unwrap converts CatLists to lists. The question clearly seeks a pure solution that does not rely on Haskell's built-in lists. What's the pure solution that uses cases and recursion on CatList, not Haskell's built-in lists, to capture the equality of nested CatLists? _ Windows Live™: Life without walls. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_032009___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On 5 Mar 2009, at 4:02 am, R J wrote: Could someone provide an elegant solution to Bird problem 4.2.13? This is the classic Lisp SAMEFRINGE problem in disguise. You say that the method of converting CatLists to lists and then comparing those is a hack, but I take leave to doubt that. It's easy to get right, and it works. == and are, in general, O(n) operations on lists, so the O(n) cost of converting trees to lists isn't unreasonable. In fact given ((Wrap 1) ++ ..) ++ ..) ) it can take O(n) time to reach the very first element. Best of all, the fact that Haskell is lazy means that converting trees to lists and comparing the lists are interleaved; if comparison stops early the rest of the trees won't be converted. One way to proceed in a strict language is to work with a (pure) state involving - the current focus of list 1 - the current focus of list 2 - the rest of list 1 (as a list of parts) - the rest of list 2 (as a list of parts). I thought I had demonstrated this when one last check showed a serious bug in my code. In any case, this relies on lists to implement the stacks we use for the rest of the tree. Your unwrap approach is much easier to get right. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (no subject)
Hi, I managed to miss not one, but two separate emails containing patches to haskell-src meta. My sincere apologies to those who've sent me patches. I'll be applying them among other improvement to src-meta and will update the package on hackage in short time (today :). Matt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (no subject)
hi, i am looking for someone to help me with an assignment! can anyone help me? i am looking forward to your reply. sincerely, Tolis _ BigSnapSearch.com - 24 prizes a day, every day - Search Now! http://clk.atdmt.com/UKM/go/117442309/direct/01/___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
2008/11/25 apostolos flessas [EMAIL PROTECTED]: hi, i am looking for someone to help me with an assignment! can anyone help me? Hi Tolis! Have a look at the homework help policy, so you know what people will and will not answer. http://www.haskell.org/haskellwiki/Homework_help Then let us know what you're trying to do, and what your difficulty has been. Cheers, D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (no subject)
Hello. I'm trying to apply the nested regions (as in Lightweight Monadic
Regions by Oleg Kiselyov and Chung-chieh Shan) design pattern, if that's the
proper term. I was hoping to gain a bit more type safety in this little library
I'm working on -- Streaming Component Combinators, available on Hackage. I
guess the problem is that I'm getting too much type safety now, because I can't
get the thing to compile. Most of the existing code works, the only exceptions
seem to be various higher-order functions. I've reduced the problem to several
lines of Literate Haskell code below, can anybody think of a solution or a
reason there can't be one?
{-# LANGUAGE MultiParamTypeClasses, EmptyDataDecls, Rank2Types #-}
{-# LANGUAGE FunctionalDependencies, FlexibleInstances, IncoherentInstances
#-}
module Main where
main = undefined
I'll call the main type, originally a monad transformer, simply Region. I'm
leaving out the Monad and MonadTransformer instances, because they don't
contribute to the problem. The parameter r is the phantom region type.
newtype Region r a = Region a
The Ancestor class is used to denote relationship between two regions where one
is nested in another.
data Child r
class Ancestor r r'
instance Ancestor r (Child r)
instance Ancestor r1 r2 = Ancestor r1 (Child r2)
Handle is a simple wrapper around a value. It carries information about the
region that originates the value.
data Handle r x = Handle x
A typical calculation in the Region monad will take a bunch of Handles
inherited from an Ancestor region and do something with them. The Ancestor
constraint is there to ensure that the handles are not fake but genuinely
inherited.
type SingleHandler x y = forall r1s rs. Ancestor r1s rs =
Handle r1s x - Region rs y
type DoubleHandler x y z = forall r1d r2d rd. (Ancestor r1d rd, Ancestor r2d
rd) =
Handle r1d x - Handle r2d y - Region rd z
And now I'm getting to the problem. The following higher-order function doesn't
type-check:
mapD :: (SingleHandler x z - SingleHandler y z)
- DoubleHandler x w z - DoubleHandler y w z
mapD f d = \y w- f (\x- d x w) y
I get the same error from GHC 6.8.2 and 6.8.2:
Test.lhs:36:28:
Could not deduce (Ancestor r2d rs)
from the context (Ancestor r1s rs)
arising from a use of `d' at Test.lhs:36:28-32
Possible fix:
add (Ancestor r2d rs) to the context of
the polymorphic type
`forall r1s rs. (Ancestor r1s rs) = Handle r1s x - Region rs z'
In the expression: d x w
In the first argument of `f', namely `(\ x - d x w)'
In the expression: f (\ x - d x w) y
The same code compiles just fine if all the Ancestor constraints are removed. I
don't see any place to add the extra (Ancestor r2d rs) constraint, as GHC
recommends. I think it ought to be able to figure things out based on the
exisisting constraints, but I may be wrong: perhaps higher-order functions pose
an insurmountable problem for type-level programming in Haskell. Can anybody
shed any light on this?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
(no subject)
Hi Claus, I was reading your instructions on the GHC wiki page, http://hackage.haskell.org/trac/ghc/wiki/Building/Windows, and they are wonderful - exactly what I wanted. However, they don't work. When downloading Cygwin you are told to add haskell.org/ghc/cygwin as a path so it can pick up the setup.ini file. However, in the latest version of Cygwin it obvious wants signatures for all the .ini files: --- Cygwin Setup --- Unable to get http://www.haskell.org/ghc/cygwin/setup.ini.sig from http://www.haskell.org/ghc/cygwin --- OK --- Could someone please add the appropriate signature file? Thanks Neil == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: (no subject)
Hi Neil, I was reading your instructions on the GHC wiki page, http://hackage.haskell.org/trac/ghc/wiki/Building/Windows, and they are wonderful - exactly what I wanted. However, they don't work. When downloading Cygwin you are told to add haskell.org/ghc/cygwin as a path so it can pick up the setup.ini file. However, in the latest version of Cygwin it obvious wants signatures for all the .ini files: --- Cygwin Setup --- Unable to get http://www.haskell.org/ghc/cygwin/setup.ini.sig from http://www.haskell.org/ghc/cygwin --- OK --- Could someone please add the appropriate signature file? Grr, not just the Haskell Cabal keeps marching on. Apparently, that is a change in last month's setup.exe: Updated: Setup.exe updated to version 2.573.2.3 http://cygwin.com/ml/cygwin-announce/2008-08/msg1.html If I understand the implications correctly, one would need a three point change to adapt properly: - sign the setup.ini file with a key, in place - put up a public key to check against, somewhere else - point setup.exe to the location of the public key Given that all we want are the dependencies (the package is empty), this is starting to look ridiculous (one has to put in more administrative information than one saves from not having to specify the dependencies by hand..). Meanwhile, there is apparently a command-line option to bypass the check, when using setup.exe on this repository: -X --no-verify Don't verify setup.ini signatures You can easily check the package contents yourself before/after downloading (because it is empty, only the setup.ini text matters;-). Of course, I wouldn't recommend using that switch while you're also sourcing from another repository (the verification has been added for a reason), so one would have to recommend running setup.exe twice, once with verification for the main stuff, once without for ghc-depends? But setup.exe will presumably want to run the check on both downloading and installing, and since the dependencies ought to be installed with verification, it isn't quite clear to me whether there is a successful sequence of calling setup.exe, unless ghc-depends is signed and an additional key is provided.. GHC HQ: unless you want to sign that package, and provide a key to check against, I don't know what to do about this. Please remember to update the log on the wiki page when you succeed - the value of this log comes from being applied from scratch (when just updating, it is easy to miss something). Thanks, Claus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] (no subject)
Hi has anyone had any success in running a recent version of hs-plugins on a windows platform. I refer to this post to the haskell list in December last year. The current version of hs-plugins dosn't appear to work either. Same problem ... http://www.haskell.org/pipermail/haskell/2007-December/020043.html jvl _ Meet singles near you. Try ninemsn dating now! http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fchannel%2Findex%2Easpx%3Ftrackingid%3D1046247_t=773166080_r=WL_TAGLINE_m=EXT___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
