- Haskell-Cafe - Haskell.org

Lists of Lists
by zell_ffhut 09 Mar '06

09 Mar '06

Just wondering if anyone can help me with a Haskell problem im having. How would I get the value of, lets say, the 9th object in ["4179355"," 567412"] ? (in this case, that should return 6) Any help/adivce would be great :) -- View this message in context: http://www.nabble.com/Lists-of-Lists-t1245394.html#a3297506 Sent from the Haskell - Haskell-Cafe forum at Nabble.com.

10 19

A syntax proposal: data replacements
by ihope 09 Mar '06

09 Mar '06

I'd like to propose more syntactic sugar more Haskell. (A spoonful of syntactic sugar makes the medicine go down...) Put simply, this would provide a smallish bit of pattern matching, and hopefully clarify some things. A simple example should pretty much define the whole thing: fromJust = {Just ->- id; Nothing ->- error "Nothing"} This function takes a single value. If the constructor used to construct it is Just, then the Just is replaced with id. Likewise, if it's given Nothing, it will return (error "Nothing"). Another example: consPair = {(,) ->- (:)} This takes a pair (x,y) and replaces the constructor (,) with (:), yielding (x:y). Now, a final clarification: foldr cons nil = {(:) ->- cons; [] ->- nil} This will *not* work: only the top bit of list will be replaced this way, as data replacements are not recursive. One last example: the function {Left ->- id; Right ->- error} takes an Either a String and either pulls out the a and returns that or uses the String as an error message.

3 2

Re: [Haskell-cafe] |> vs. $ (was: request for code review)
by Shannon -jj Behrens 09 Mar '06

09 Mar '06

By the way, thanks for everyone's comments so far! They're very helpful! > Also, most haskell programs use $ instead of |> > > > -- For convenience: > > currTokType :: ParseContext -> TokenType > > currTokType ctx = ctx |> currTok |> tokenType > > this could be written as: > tokenType $ currTok $ ctx Concerning: -- |> is like a UNIX pipe. infixl 9 |> x |> f = f x I find "ctx |> currTok |> tokenType" to be more readable than "tokenType $ currTok $ ctx" because you're not reading the code in reverse. That's my primary complaint with "." and "$". That's especially the case when I'm spreading the code over multiple lines: -- Translate a C type declaration into English. translate :: String -> String translate s = s |> createParseContext |> readToFirstIdentifier |> dealWithDeclarator |> consolidateOutput I prefer |> for readability, but I understand that it can be bad to spring new constructs on programmers in the middle of a program, and I'm totally in favor of following standard Haskell idioms. Does anyone else have strong opinions one way or the other? It seems like most of my program is centered around pipes of "|>", so it's an important issue. Thanks! -jj

7 14

Re: Library survey results
by John Hughes 09 Mar '06

09 Mar '06

>> 29% Parsec >> 19% wxHaskell >> 16% QuickCheck >> 16% haddock >> 12% Monadic Parser Combinators >> 11% Gtk2Hs >> 9% hs-plugins >> 8% HaXml >> 7% Data.* >> 7% Monad foundation classes >> 6% Arrows >> 6% HOpenGL >> >> The list includes all libraries named by more than 5% of respondents. >> Sure enough, wxHaskell and Gtk2Hs are more popular, but 6% naming >> HOpenGL as among the "most important" libraries is quite respectable. > > Well, I've never said that it is among the "most important" libraries, but > OTOH I really much doubt that the way the survey was done delivers > anything > near reliable results. It heavily biases early entries, and I dare to > speculate that the people taking part in the survey were probably not even > near to a representative group, but a bunch of highly motivated, > experienced > non-Joe-Programmer kind of people who are actively participating on the > mailing lists etc. It wasn't as bad as you think--over 580 replies, with less than a quarter of those from academics (there were actually more replies from people working in industry than from academics!). So I'd dispute that the survey tells us mostly about what the research community in particular wants. I'd guess the survey was pretty representative of KEEN Haskell users. It's a bit unclear who we mean by "Joe Haskell-programmer" anyway--I bet that, apart from students of course, the number of Haskell programmers who are using the language "just because their boss tells them to" can be counted on the fingers of one hand! I'd claim Joe Haskell programmer probably IS keen, highly motivated, experienced and active. In fact, the one group that is obviously underrepresented badly in my survey is just students--I got replies from just under 300, while another survey of teachers shows that at least 5-10,000 were taught Haskell last year. But maybe tools like hoogle SHOULD be aimed at the most active users? You're right that libraries mentioned earlier in the survey received more "votes" as a result, but since I have a record of all responses *in time order* I can see the difference, for each library, between pre- and post- "first mention" behaviour. HOpenGL was mentioned in the 7th response, wxHaskell in the first, and Gtk2Hs in the 17th, so they were in the "previously mentioned" category for almost the entire survey, and the effect you're talking about was not significant for a comparison between those three. Data.*, on the other hand, was first mentioned about half way through the survey, which indicates that around 12% of respondents selected it as among the "most important" libraries, when prompted to do so by seeing its name. However, the proportion who name Data.* spontaneously is below 2%--and that conclusion is statistically significant at the 99% level. 580 replies is enough to say statistically significant things (about the population the survey sampled, anyway). I feel quite inspired--when I have a spare moment, I'll analyse the results more carefully and see what one actually CAN say with a degree of certainty, taking into account when each library was first mentioned. > Furthermore, some of the percentages above are extremely > strange, e.g. how can people use huge GUI toolkits with 30% while staying > largely away from something as fundamental as Data.*? I don't find it so strange, really. Data.* implements lots of useful standard datatypes, but you can import some of them in other ways (import Maybe for example), and in many cases it's not too hard to roll your own. OK, maybe with a worse result, but you're not *forced* to use Data.* -- so if you're used to using something else, there's no 100% compelling reason to change. Rolling your own wxHaskell or Gtk2Hs is prohibitively hard. So I'm not at all surprised that GUI toolkits rated much higher--people's natural conservatism gives them a big advantage, and even Haskell users can be conservative sometimes! Perhaps the most surprising thing here is that only 30% of keen Haskellers think a GUI is important! John

2 1

MUA written in Haskell (was: Getting GHC to print "Done" when it's finished linking?)
by Nils Anders Danielsson 09 Mar '06

09 Mar '06

On Tue, 07 Mar 2006, "Brian Hulley" <brianh(a)metamilk.com> wrote: (Moved from ghc-users.) > Brian Hulley wrote: > (time for a proper email client to be written in Haskell! ;-) ) I had the same thought yesterday, after an Emacs-Lisp session in which I was trying to get Gnus to do exactly what I wanted it to... Out of curiosity, how much work would it take to write an easily configurable, decent MUA in Haskell? I don't know too much about MUAs, but I have a feeling that we already have quite a few libraries that are needed for the job: UIs (including HTML rendering...), plugins, various protocols, encryption... -- /NAD

6 6

haskell-prime traffic
by Ross Paterson 09 Mar '06

09 Mar '06

Just for fun, I've put up some statistics on haskell-prime traffic at http://www.soi.city.ac.uk/~ross/haskell-prime-stats/ I'm not claiming it shows anything, except what a narrow base we have.

2 1

Dropping trailing nulls from a list of list
by Jeff.Harper＠handheld.com 09 Mar '06

09 Mar '06

Today, I reviewed a function I wrote a few months ago. The function, dropTrailNulls, takes a list of lists and drops trailing null lists. For instance: *Main> dropTrailNulls [[1],[2,3],[],[]] [[1],[2,3]] My original implementation was terrible. It was recursive, overly bulky, and difficult to understand. It embarrasses me. I won't post it here. Today, it occurred to me this would do the trick: dropTrailNulls list = reverse (dropWhile null (reverse list)) The problem is 20 years of experience writing efficient imperative programs says to me, "You don't drop things off the end of a structure by reversing the structure, dropping stuff from the beginning, then reversing again." I suspect this imperative bias prevented me from coming up with the simple solution when I first wrote my function. On the other hand, it is conceivable to me that my new implementation may actually be relatively efficient since Haskell uses lazy evaluation, and Haskell lists are constructed from the tail to the beginning. I'm sure there are many problems that are encountered in Haskell where it is necessary to operate on the end of a list. So, I'm wondering if the idiom, reverse, operate, then reverse is something I should add to my toolbox. Or, is there a more efficient idiom for addressing these problems?

7 6

RE: [Haskell-cafe] library sort
by Simon Peyton-Jones 08 Mar '06

08 Mar '06

Strangely, Hoogle isn't easy to find at haskell.org. I'm not sure where the best place to add a link would be: perhaps near the top of the libraries-and-tools page? It's all wikified now, so would someone like to add it somewhere appropriate? Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Radu Grigore | Sent: 17 February 2006 14:11 | To: Haskell Cafe | Subject: Re: [Haskell-cafe] library sort | | On 2/16/06, Jared Updike <jupdike(a)gmail.com> wrote: | > If you need an easier way to search the Haskell APIs, use Hoogle: | | Hoogle is very nice. Thanks to everyone who answered my question about | finding a sort library function. | | -- | regards, | radu | http://rgrig.blogspot.com/

4 8

Re: [Haskell-cafe] library sort
by John Hughes 08 Mar '06

08 Mar '06

>Am Samstag, 4. März 2006 21:30 schrieb Neil Mitchell: > > >>>And a related question is: Which packages are searchable by Hoogle? >>> >>> >>The best answer to that is "some". I intentionally excluded OpenGL and >>other graphics ones because they have a large interface and yet are >>not used by most people using Haskell. [...] >> >> > >Well, this a bold assumption IMHO, and I'm not particularly happy with that, >as you can probably imagine. For my part, I would assume that Joe Programmer >is much more likely to use some multimedia packages than TH or Data.Graph.* >etc., but this is a bold assumption on *my* side... > >... > >>Well, this a bold assumption IMHO, and I'm not particularly >>happy with that, as you can probably imagine. >> >> > >I would also imagine that Joe Programmer is more likely to use >wxHaskell or Gtk2Hs than those - however because those are outside the >standard tree they don't make it in. I don't think much of TH made it >in either (not becuase of deliberate exclusions, but because of >technical limitations in the tool). > > > When I surveyed Haskell users, I asked respondents to name the most important tools and libraries they use. (Caveat: respondents saw the list of tools and libraries already named, and could include these just by selecting them, so tools mentioned early in the survey were more likely to be named by subsequent respondents). Here are a few relevant entries, where the percentage is the proportion of respondents who named the tool: 29% Parsec 19% wxHaskell 16% QuickCheck 16% haddock 12% Monadic Parser Combinators 11% Gtk2Hs 9% hs-plugins 8% HaXml 7% Data.* 7% Monad foundation classes 6% Arrows 6% HOpenGL The list includes all libraries named by more than 5% of respondents. Sure enough, wxHaskell and Gtk2Hs are more popular, but 6% naming HOpenGL as among the "most important" libraries is quite respectable. John

3 2

Web application frameworks (was: [Haskell] Re: Trying On Learn Haskell Web Server)
by Graham Klyne 08 Mar '06

08 Mar '06

[Switching to haskell-cafe] Niklas Broberg wrote: > Ehum, shameless plug. :) > Pretty much what I was fishing for... > On 3/6/06, Graham Klyne <GK(a)ninebynine.org> wrote: >> Cale Gibbard wrote: >>> Ah, neat, I knew about WASH, but somehow I'd missed the fact that >>> there was a server there :) >> Interesting... at a casual glance, this looks as if it could be coming close to >> being a "full stack web application framework" for Haskell, looking to occupy >> the same kind of territory as systems like Java/Servlets+JSP+the rest, >> Ruby/Rails or Python/Turbogears (the last a package I'm currently using). > > Have you looked at HSP [1]? This is exactly what the HSP project aims > for, although there is quite some ways to go yet. I've noticed it, but haven't yet taken a closer look. Currently, I'm pretty busy with non-Haskell activities, but I'd love to find a sufficiently mature tool to migrate some of my work to Haskell. >> I think see: >> The web server >> CGI process dispatching >> Web page templating >> Relational database access > > All of these are present in HSP. I noticed that WASH makes some mention of HSP. My main concern with a *SP approach, and a reason I haven't delved more deeply, is that they are, AFAICT, heavily dependent on code embedded in HTML, when I really want to separate the code and markup as much as possible. >> Additional features of a full-stack web application framework that may or may >> not be present are: >> >> - Support for longer-running web processes (implemented in haskell, of course) > > HSP has that. Ah, OK... I wasn't aware of that. >> - An easy way to map incoming URIs to specific functions (hmm.. or to monadic >> values, I think) > > I don't think I understand what you're after exactly, but I'm sure > it's interesting, care to explain a bit further? :-) I'll try and explain using Turbogears as example. Actually, I think that Turbogears would make a good model for building a Haskell Web application framework, since many of the key integration points are implemented using higher order functions. It makes heavy use of Python 2.4 "decorators", which are a (constrained) form of functional composition for class member functions. The web server/controller component of Turbogears is CherryPy. Roughly, a class maps to a web server "directory" in URI space, with a declared class (conventionally "root") corresponding to path / for a server. Member variables use used to create subdirectories. here's an example from soemthign I'm working on: [[ class Root(controllers.Root): panel = PanelRenderer() ### Note 1 webbrick = WebBrickAccess() itunes = ITunesAccess() @turbogears.expose(html="templates.welcome") ### Note 2 def index(self): return dict(now=time.ctime()) @turbogears.expose(html="templates.listpanels") ### Note 2 def panels(self): def selectPanelName((_,nam)): return nam[:-4] pattern = re.compile( r'^.+\.xml$' ) c = CollectFiles("../resources/paneldef/",pattern,recursive=False) return { 'baseuri' : turbogears.url("/")+"panel/", ### Note 3 'panels' : map(selectPanelName,c) } ]] Notes: 1. These assignments create sub-pages of the root page for http://.../panel/, http://.../webbrick/, http://.../itunes/. 2. This is the Python decorator syntax, that defines a class method as a composition of the decorator function (turbogears.expose) and the function definition that follows. The turbogears.expose decorator performs two functions here: (a) it causes the function to be exposed as a web page; e.g. http://.../index or http://.../panels, (b) it uses the output from the defined function as input to a templating system to format and return an HTML web page. 3. The templating system uses a Python "dictionary" type to accept values that are included in the constructed web page. You will note that this code is completely independent of the details of the templating syst actually used. Indeed, Turbogears can be used with more than one templating system, and (in principle), I think the decorator system would allow miore than one such system to be used within a single application - not that I advocate this ;). I think all of this could be converted quite easily to appropriate Haskell idioms. >> - Easy mapping from Haskell data structures to underlying SQL - what would be >> called an Object-Relational Mapper (ORM) in OO languages > > Some of our students are working on bringing the power of Ruby/Rails > to HSP, with emphasis on smooth database interfacing. Not sure exactly > what this entails though, I've never used Rails... :-) IMO, Rails suffers in this respect by being too-tightly integrated with its ORM system. It's fine if you want, as Bruce Tate says, to "babysit a relational database". By in my application, I actually want to "babysit" a collection of web-connected devices. Turbogears, by contrast, leaves the controller/model interface completely in the open: there is no presumtpion that the supplied ORM code will be used. This means I can simply call my own (web client library) code instead of the ORM code, and everything just works. With rails, on brief examination, I felt that IK wpould need to unpick the ORM interface and then implement my own "model" code behind that interface -- just the kind of complexification and dependency I'm trying to get away from. >> - Handling of interaction with a browser-side Javascript library for smoother >> AJAX support > > This is not currently present in HSP, but they are surely on the > conceptual todo-list. There is a design for a crude JavaScript > support, but we'd certainly need more. In turbogears, this mostly amounts to validation of form results coming back from Ajax-enabled forms, as far as I can tell. It's not a feature I've used yet. BTW, the Mochikit Ajax library (component of Turbogears) is an interesting example of functional idioms used in Javascript. >> - Options to run the whole thing behind Apache to leverage its security and web >> space management capabilities > > Lemmih has implemented a HSP/FastCGI binding for Apache. I also know > that work is being done on building a direct HSP/Apache binding. All > work in progress though. Yes, I was aware of a fastCGI for Haskell. Didn't Bjorn Bringert (also) implement one? I tend to think of CGI programs as run-to-completion-then-exit, even when a fastCGI interface allows a persistent wrapper program to speed startup. But I could easily be missing something here. >> I think that continuation-based web session state management, ala >> Smalltalk/Seaside, would be a very natural fit for a Haskell framework -- all >> handled by a "Web session monad", maybe. (Or maybe I just don't know what I'm >> talking about ;) > > This is by far the biggest drawback of HSP today. There is no > high-level support for continuations (other than explicitly defined > continuations at top level). This is something that I assume would not necessarily be (too) tightly integrated into the rest of the framework. This is only a very vague sketch, and I might be talking rubbish as I haven't studied this are in any depth, but I imagine using something a monad to maintain the state of a web session, with each incoming request corresponding to a bind operation, updating the session state and returning a value to the client. I'm not sure how closely this follows technically the idea of using continuations, but I think the end result is similar: cleaner and well-isolated management of session state and web transaction progress. >> How far are we from having such a framework for Haskell? > > Depends on how many people would be willing to invest time in it. > Right now we have students at Chalmers working on a project that aims > towards such a framework, but they can only do so much in the time > they have. We would surely welcome any help we could get. :-) Well, it's the sort of project I'd love to work on, but right now I also lack time. I've felt for a long time that Haskell would be a great language for building Web applications, and my work with Turbogears is showing me how it might actually all come together. Part of the problem is finding someone who is prepared to sponsor such work, as I've already taken a year or so working on my own projects, and not ready to take the financial hit again. > (ps. Going on vacation for 2 weeks in a few hours, so I'm not likely > to respond for a while... ;-)) Have fun! #g -- PS: I just spotted this in HWN: [[ * Haskell as a markup language. Oleg Kiselyov [4]writes on using Haskell to represent semi-structured documents and the rules of their processing. [5]SXML is embedded directly in Haskell, with an open and extensible set of `tags'. The benefit of this is of course in static type guarantees, such as prohibiting an H1 element to appear in the character content of other elements. 4. http://www.haskell.org/pipermail/haskell/2006-March/017656.html 5. http://ssax.sourceforge.net ]] I think this really should be in the toolkit, possibly at the heart of the templating system. I think this kind of capability is exactly why Haskell could be so good as a web application language. -- Graham Klyne For email: http://www.ninebynine.org/#Contact

2 2