July 2011 - Haskell-Cafe

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 24 Jul '11

24 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 24 Jul '11

24 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 24 Jul '11

24 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

Re: [Haskell-cafe] ANNOUNCE: Haskell in the Cloud (http://quid2.org)
by Pasqualino "Titto" Assini 24 Jul '11

24 Jul '11

Hi David, no there is no direct relationship to distributed haskell. Quid2's focus is not so much on extending Haskell itself and its runtime to work in a distributed fashion but rather to provide a global naming system for functional values. Very similar to the Web, whose main innovation is to provides a global naming system for all kind of resources that previously had only local names (/dir/myfile versus http://ww.myserver.com/myfile) A description of Quid2 architecture will soon be available and it will be clearer how is meant to work. It will be far from complete, a working functional web will only emerge if many different ideas converge in a coherent whole. Best, titto > On 22 July 2011 15:57, David Barbour <dmbarbour(a)gmail.com> wrote: >> Any relationship to distributed haskell? >> http://www.macs.hw.ac.uk/~dsg/gdh/ >> >> On Fri, Jul 22, 2011 at 3:00 AM, Pasqualino "Titto" Assini >> <tittoassini(a)gmail.com> wrote: >>> >>> Fellow Haskeller, >>> >>> Has your strongly typed, quick checked, formally verified, Oleg blessed, >>> higher order monadic code become a little bit too predictable? >>> >>> Are you feeling a bit bored, emotionally drained and disillusioned with >>> perfection? >>> >>> Longing for the days when Men were Men (and Women were Women for that >>> matter) and squashed bugs out of Assembler code with just their bare hands >>> and a line editor? >>> >>> Enter Quid2 [1]: the half baked, barely tested, totally unsafe and >>> spectacularly unoptimised Haskell in the Cloud system. >>> >>> A delightful blend of Haskell crispiness and JavaScript fluffiness, Quid2 >>> guarantees hours and hours of guilt free hacking enjoyment. >>> >>> Let a soft lamb(a)da rhythm [2] take you over as you gingerly step onto >>> the Haskell Cloud, it's time to party as if it were 1991 all over again! >>> >>> Yours truly, >>> >>> titto >>> >>> [1] http://quid2.org >>> >>> [2] http://www.youtube.com/watch?v=i8mz9uOvFQA >>> >>> -- >>> Dr. Pasqualino "Titto" Assini >>> http://quid2.org/ >>> >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> > > > > -- > Dr. Pasqualino "Titto" Assini > http://quid2.org/ > -- Dr. Pasqualino "Titto" Assini http://quid2.org/

1 0

ANNOUNCE: Haskell in the Cloud (http://quid2.org)
by Pasqualino "Titto" Assini 24 Jul '11

24 Jul '11

Fellow Haskeller, Has your strongly typed, quick checked, formally verified, Oleg blessed, higher order monadic code become a little bit too predictable? Are you feeling a bit bored, emotionally drained and disillusioned with perfection? Longing for the days when Men were Men (and Women were Women for that matter) and squashed bugs out of Assembler code with just their bare hands and a line editor? Enter Quid2 <http://quid2.org> [1]: the half baked, barely tested, totally unsafe and spectacularly unoptimised Haskell in the Cloud system. A delightful blend of Haskell crispiness and JavaScript fluffiness, Quid2 guarantees hours and hours of guilt free hacking enjoyment. Let a soft lamb(a)da rhythm <http://www.youtube.com/watch?v=i8mz9uOvFQA> [2] take you over as you gingerly step onto the Haskell Cloud, it's time to party as if it were 1991 all over again! Yours truly, titto [1] http://quid2.org [2] http://www.youtube.com/watch?v=i8mz9uOvFQA -- Dr. Pasqualino "Titto" Assini http://quid2.org/

3 3