- Haskell-Cafe - Haskell.org

ICFP 2011: Call for participation
by Wouter Swierstra 26 Jul '11

26 Jul '11

===================================================================== Call for Participation The 16th ACM SIGPLAN International Conference on Functional Programming (ICFP 2011) http://www.icfpconference.org/icfp2011/ Tokyo, Japan September 19-21, 2011 ===================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. * Program: http://www.icfpconference.org/icfp2011/program.html * Registration link: https://regmaster3.com/2011conf/ICFP11/register.php * Local arrangements (including travel and accommodation): http://www.biglab.org/icfp11local/index.html Schedule including related events: September 18 Workshop on Generic Programming (WGP) Workshop on High-Level Parallel Programming and Applications (HLPP) Workshop on ML September 19-21 ICFP September 22 Commercial Users of Functional Programming – Day 1 (CUFP Tutorials) Haskell Symposium September 23 Commercial Users of Functional Programming – Day 2 (CUFP Tutorials) Erlang Workshop Haskell Implementors' Workshop September 24 Commercial Users of Functional Programming – Day 3 (CUFP Talks) Continuation Workshop Conference organizers: * General Co-Chairs: Manuel Chakravarty, University of New South Wales Zhenjiang Hu, National Institute of Informatics * Program Chair: Olivier Danvy, Aarhus University * Local Arrangements Chair: Soichiro Hidaka, National Institute of Informatics * Workshop Co-Chairs: Gabriele Keller, University of New South Wales Derek Dreyer, MPI-SWS * Programming Contest Chair: Eijiro Sumii, Tohoku University * Publicity Chair: Wouter Swierstra, Radboud Universiteit Nijmegen =====================================================================

1 0

More QuickCheck Questions
by Mark Spezzano 25 Jul '11

25 Jul '11

Hi all, I still don't understand exactly how the QuickCheck "sized" function is meant to work, and what it's useful for. Please explain! Also, I think that class CoArbitrary can help to generate random *functions *(as opposed to values; but tell me if I'm wrong) but I don't see how this could be useful. Also what does shrink do? Example code of these would be tremendously helpful understanding these concepts. Thanks in advance, Mark Spezzano

4 3

deriving ListLike instance
by bob zhang 25 Jul '11

25 Jul '11

Hi, all, newtype Stream a = Stream [a] I wanna derive ListLike [a] a automatically, but did not find a solution, I tried deriving instance ListLile (Stream a) a -- does not work Thank you.

2 2

How to select last inserted record from Table Using Database.HSQL.MySQL
by Sergiy Nazarenko 25 Jul '11

25 Jul '11

Hi, everyone! trycon <- connect "mysql" "bigtables" "vasya" "*******" stmt' <- query trycon "INSERT INTO mytable (user,time,host,) VALUES ("Vasya","2011.07.30 11.59","foo")" I am beginner to use HSQL and I have a problem. I need to know row ID after INSERT into table. fetch stmt' returned False What should I do? Cheers!

2 1

Slightly tangential topic about functional programming (specifically, Lambda-Calculus)
by Haskell Lippy 25 Jul '11

25 Jul '11

Hi everybody - I'm just starting to learn Haskell, and I figured it would be productive to first review my Lambda-Calculus that I picked up in college. Actually, we only touched upon it in college, so I'm effective learning it all over again for the first time. Anyway, I'm working my way through a textbook, and questions come up periodically, of course. My question - does anybody here belong to a forum, mailing list, or any other medium through which I might be able to engage some knowledgeable sources on Lambda-Calculus, and functional programming in general? (By the way, been hacking in Haskell for only two weeks and I'm already falling in love with it!) Thanks, and I look forward to 'chatting' with you all on more on-topic subjects in the future! Shaun shaunlippy(a)gmail.com

3 2

Re: [Haskell-cafe] For class Monoid; better names than mempty & mappend might have been: mid (mident) & mbinop
by Thomas Schilling 25 Jul '11

25 Jul '11

> So is the change taking effect? > >> We were approaching consensus for the addition of of: >> infixr 6 <> > >> (<>) :: Monoid m => m -> m -> m >> (<>) = mappend >> and a matching change for (<+>) in the pretty package. > >> It was also suggested to make (<>) a method of Monoid and insert the following default definitions: >> (<>) = mappend >> mappend = (<>) > > > And how about the following: > (<<>>) = mconcat > mconcat = (<<>>) > > And "mempty" could be "id". The problems with this are: - mconcat is not a binary operator, so using <<>> would bring little advantage. You'd always have to use it in its bracketed form, for example. - Changing mempty to id could break a lot of existing code (e.g. due to typeclass ambiguity). This is the main reason. It's also not clear to me that this is a better name (it's just shorter). The current naming of Monoid methods is modelled after list operations, because list is a (the?) free monoid. However, in many cases "zero" or "one" would be an equally good name. I think (<>) is fairly uncontroversial because: 1. It's short 2. It's abstract. i.e., no intended pronunciation and it looks like LaTeX's \diamond operator 3. Changing it would be compatible with most existing libraries. For this reason, I think a larger change would have to come with a larger library re-organization. Johan Tibell suggested something like that a while ago: instead of lots of little cuts (backwards incompatible changes), a working group of activists should redesign a whole new (incompatible) alternative set of core libraries. > > > On Sun, Jul 24, 2011 at 11:39 AM, Thomas Schilling > <nominolo(a)googlemail.com> wrote: >> Yes, this has sort-of been agreed upon in a GHC ticket about a year >> ago: http://hackage.haskell.org/trac/ghc/ticket/3339 >> >> I had a patch in Darcs, but then came the switch to Git. I ported it >> to Git, but didn't iron out all the issues. That was quite a while >> ago so it's currently a bit bitrotten. I don't think it's enough time >> to get it into 7.2, but since that's largely an unstable release, it >> wouldn't hurt until 7.4. I'll probably work on it at CamHac in a few >> weeks. > > > > -- > -- > Regards, > KC > -- Push the envelope. Watch it bend.

6 7

Web application design advice
by Sævar Berg 25 Jul '11

25 Jul '11

Hello, Café. I am really not fond of web development, but being able to do it in my favorite language is interesting, so I've been spending some time taking a look at happstack. I decided to start a concrete project so that I could work towards some goal in my learning process, and I have decided on writing an inventory management system for this small computer workshop I work in as a volunteer. We probably have several metric tonnes of various computer equipment; interntal hardware(RAM, hard drives, graphics card, processors and so on) to peripherals and even non-computer related stuff, and it would be good to be able to catalog it and know what exactly we have and so on. Anyway, my question is about the design itself. My original idea for the database was to create a data type, something like data Hardware = Ram { ramType :: RamType , ramSize :: Int ... } data RamType = SDRAM | DDR | DDR2 | DDR3 .. The obvious advantage to this is type safety and thus having an ORM database, so to speak(Please forgive me if my web dev lingo is off here, this is *really *not my forté). However, a big disadvantage is that we might want to add new 'type' of hardware to the database and this would require me to stop the server, modify the haskell code to add a new type constructor and so on. On top of that, since a graphics card has different attributes than RAM, I will need to dynamically generate the forms required to add new hardware to the database or to search for hardware in the database. Due to this, I had another idea. I would create a state type that would merely represent groups of items using a map of some kind, where the group name would be a string. Maybe something like this: data HardwareGroup = HardwareGroup { groupName :: String -- Valid key values for the map , groupValues :: [String] , groupItems :: [Data.Map String String] } Which means I can create a new group like this: type Hardware = [HardwareGroups] hardwareDatabase :: Hardware hardwareDatabase = [] newGroup = HardwareGroup "RAM" ["ramSize", "ramSpeed", "ramType", "ramName"] Data.Map.empty -- Nothing if some value in map isn't a valid part of addToGroup :: HardwareGroup -> Data.Map String String -> Maybe HardwareGroup addToGroup (HardwareGroup name values items) m = case (any (flip notElem values) $ keys m) of True -> return Nothing _ -> return $ HardwareGroup name values (m : items) addToGroup newGroup (fromList [("ramSize", "512"), ("ramSpeed", "400 Mhz"), ("ramType", "DDR"), ("ramName", "Kingston")]) The code may not be correct. I wrote it in this email and didn't test it, but I assume you guys get what I'm going for here. This will enable me to dynamically generate forms in an easy manner and add to / search in the database, without having to think about some types being strings and some types being ints or something entirely different. The reason I've come here asking this question and not some web design mailing list is because I'm writing this in Haskell, and I was wondering if you guys could see some disadvantages to either design that I may not have foreseen, or even come up with other suggestions. I would just really appreciate any hints, tips, pros or cons to either design. Am I losing something big by sacrificing type safety? Or is the first idea unwieldy enough to justify the sacrifices? Thanks a lot in advance guys.

1 0

Re: [Haskell-cafe] For class Monoid; better names than mempty & mappend might have been: mid (mident) & mbinop
by wren ng thornton 25 Jul '11

25 Jul '11

On 7/24/11 10:09 PM, Sebastian Fischer wrote: >> >> because list is a (the?) free monoid. > > Yes, all free monoids are isomorphic (to lists). > > Sebastian For completeness... The free monoid over a set S is the set of all finite sequences of elements drawn from S. Often this is written with the Kleene star: S^*. Finite lists are a particular representation for the free monoid (namely with all operations associated to the right), though this representation may not be "isomorphic enough" for certain analyses (e.g., algorithmic complexity). Note that the free semigroup over a set S is the set of all finite non-empty sequences of elements drawn from S. We can name this by S^+. Other than the fact that S^+ does not contain the empty sequence, the other important difference is that, while both S^* and S^+ are both closed under the operation, only S^* is co-closed under the operation (i.e., not all elements of S^+ can be decomposed into two elements of S^+ joined by the operator). -- Live well, ~wren

1 0

Re: [Haskell-cafe] For class Monoid; better names than mempty & mappend might have been: mid (mident) & mbinop
by Maciej Wos 25 Jul '11

25 Jul '11

Personally, I have nothing against mempty (although I agree that mid makes more sense), but I don't like mappend at all. I wonder what happened to the idea of using <> instead of mappend (that's what I always do). I think a <> b <> c looks so much better than a `mappend` b `mappend` c and it solves the name problem altogether. -- Maciej On Jul 24, 2011 3:42 AM, "KC" <kc1956(a)gmail.com> wrote:

7 6

Re: [Haskell-cafe] [Haskell-beginners] For class Monoid; better names than mempty & mappend might have been: mid (mident) & mbinop
by wren ng thornton 25 Jul '11

25 Jul '11

On 7/24/11 2:29 PM, Julian Porter wrote: > On 24 Jul 2011, at 19:19, KC wrote: >> A lot of math books use "+" or "x" enclosed in a circle to indicate >> that the usual meaning of "+" nor "x" is intended for the meaning of >> the binary operation. > > Er no. Both symbols have extremely precise meanings. $\oplus$ is the direct sum of two modules and $\otimes$ is their tensor product. Well, they mean that if you're off in module/vector land; but they don't mean that everywhere. Another place they're used frequently is for semirings: with $\oplus$ the associative monoid and $\otimes$ the other monoid. While the tourism board for semirings is less well funded than the one for vectors, it's a beautiful locale with rich history. Natural language processing, graph theory, Boolean algebras, and related logics are nothing to scoff at. -- Live well, ~wren

1 0