- Haskell-Cafe - Haskell.org

Minimal complete definitions
by George Pollard 16 Dec '08

16 Dec '08

Good afternoon Café, I've written a little bit of code to calculate minimal complete definitions for a class given which of its functions use which other functions. As an example: doDependencies ord = ([],[["<="],["compare"]]) doDependencies num = (["plus","times","abs","signum","fromInteger"],[["minus"],["negate"]]) The first part of the pair is those functions which must *always* be implemented, the second part is a list of possible minimal complete definitions available for the provided list. This can help catch mistakes; a comment in the GHC source for GHC.Classes notes that compare must be implemented using (<=) and not (<) in order to give the minimal complete definition (<= OR compare). If we use the incorrect (<) then my code calculates the MCD as: doDependencies wrongOrd = ([],[["<"],["<","<=","compare"],["compare"]]) That is, the MCD is (< OR (< AND <= AND compare) OR compare). Now I have two questions: 1) Is my code correct? ;) 2) Could this be incorporated into GHC in order to detect when someone hasn't provided a sufficient definition for a class? As an example, it could detect this: > ~$ cat test2.hs > data Die d = Die d > instance Eq (Die d) where > main = do > let i = Die "stack overflow" > print (i == i) > ~$ ghc -Wall test2.hs --make > ~$ ./test2 > Stack space overflow: current size 8388608 bytes. > Use `+RTS -Ksize' to increase it. Given the following: doDependencies [("==", Just ["/="]),("/=", Just ["=="])] = ([],[["/="],["=="]]) GHC could warn that either (==) or (/=) must be implemented. Thanks, - George

1 2

Re: Re: [Haskell-cafe] Multi-parameter type class woes
by Mario Blažević 16 Dec '08

16 Dec '08

> I'll take a swing at this one: > > instance Container (Maybe x) [x] where > wrapper = isNothing > . . . > > That isn't a sensible definition of 'wrapper', but I believe without > trying to compile it is completely legal. Which wrapper do you use? > > You /don't/ have a different matching Container instance, but without the > functional dependency you /might/, and ghc barfs. But liftWrap doesn't require any particular instance, it's a generic function accepting any pair of types for which there is an instance of Container. Instance selection (as I understand it) shouldn't come into play until one applies liftWrap to a particular type, and indeed it does cause problems there: note the type annotations on the last line. That part I understand and accept, or at least have learned to live with. > On Sun, 14 Dec 2008, Mario Bla?evi? wrote: > >> I have, for a change, a relatively simple problem with >> type classes. Can somebody explain to me, or point me to an explanation of >> the behaviour I see? >> >> Here is a short and useless example: >> >> {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} >> >> import Data.Maybe >> >> class Container x y where >> wrapper :: x -> Bool >> unwrap :: x -> y >> rewrap :: y -> x >> >> liftWrap :: Container x y => (y -> y) -> (x -> x) >> liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x >> >> instance Container (Maybe x) x where >> wrapper = isJust >> unwrap = fromJust >> rewrap = Just >> >> main = print (liftWrap (succ :: Int -> Int) (Just 1 :: Maybe Int)) >> >> GHC 6.10.1 refuses to typecheck the 'wrapper' function >> in definition of 'liftWrap', with the following error message: >> >> Could not deduce (Container x y) from the context (Container x y1) >> arising from a use of `wrapper' at Test.hs:11:22-30 >> Possible fix: >> add (Container x y) to the context of >> the type signature for `liftWrap' >> In the expression: wrapper x >> In the expression: >> (if wrapper x then rewrap . f . unwrap else id) x >> In the definition of `liftWrap': >> liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x >> >> Let me clarify that I'm aware that in this particular >> example a functional dependecy should be used. Also, I can think of a few >> workarounds for my actual problem, so I'm not asking for any solutions. I'm >> looking for an explanation. It bugs me that my intuition of how this type >> class should have worked is completely wrong. The error message does not >> help, to put it mildly. Where should I go, what should I read? >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >>

5 6

Re: [Haskell-cafe] Re: haskell compiler never comes back
by Greg Meredith 15 Dec '08

15 Dec '08

George, Thanks for the response. If i take out the AllowUndecidableInstances i get no complaints and the compiler hangs. See this<http://paste.pocoo.org/show/95523/>. Thus, i can find no observable difference for this flag in this particular code sample. Best wishes, --greg On Mon, Dec 15, 2008 at 2:34 PM, George Pollard <porges(a)porg.es> wrote: > This is precisely what AllowUndecidableInstances allows; the type > checking becomes possibly non-terminating. It should *eventually* > terminate because the stack depth is restricted. > > - George > -- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com

2 1

Data.List.Split
by Brent Yorgey 15 Dec '08

15 Dec '08

Today yet another newbie in #haskell asked about a 'split' function for lists, and I got fed up with saying 'no one can agree on the right interface so it doesn't exist, just write it yourself', because it's a really dumb answer, even if it's true. Instead of trying to get a 'split' function added to Data.List (which will never ever happen), I thought, why not create a module Data.List.Split which contains implementations of every conceivable way to split a list? Of course, people will probably still argue over what should go in such a module, what to name the various functions, etc., but hopefully we can converge on something useful. I've created a Data.List.Split page on the wiki: http://haskell.org/haskellwiki/Data.List.Split Please add code to it! Once something useful is hashed out we can upload it to hackage. Perhaps eventually some of it can be folded into the standard libraries, but this seems like a much more lightweight way to get started. -Brent

6 9

Re: [Haskell-cafe] Time for a new logo?
by Brettschneider, Matthias 15 Dec '08

15 Dec '08

If there is someone interested in playing around with the logo Don posted, I made a gimp-version out of it. http://frosch03.de/haskell/Haskell.xcf http://frosch03.de/haskell/Haskell.png -- Matthias

1 0

ICFP09 Call for Papers
by Matthew Fluet (ICFP Publicity Chair) 15 Dec '08

15 Dec '08

Call for Papers ICFP 2009: International Conference on Functional Programming Edinburgh, Scotland, 31 August - 2 September 2009 http://www.cs.nott.ac.uk/~gmh/icfp09.html ** Submission deadline: 2 March 2009 ** (submission deadline is earlier than usual) ICFP 2009 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects or concurrency. Particular topics of interest include * Language Design: type systems; concurrency and distribution; modules; components and composition; metaprogramming; relations to object-oriented or logic programming; interoperability * Implementation: abstract machines; compilation; compile-time and run-time optimization; memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components or low-level machine resources * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling * Foundations: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects * Transformation and Analysis: abstract interpretation; partial evaluation; program transformation; program calculation; program proof * Applications and Domain-Specific Languages: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia programming; scripting; system administration; security; education * Functional Pearls: elegant, instructive, and fun essays on functional programming The conference also solicits Experience Reports, which are short papers that provide evidence that functional programming really works or describe obstacles that have kept it from working in a particular application. What's different this year? ~~~~~~~~~~~~~~~~~~~~~~~~~~~ * The conference dates and the submission deadline are about one month earlier than usual. * Special 'Call for Experience Reports' page, suitable as a target for posts on blogs and social networks to reach practitioners who wouldn't normally think about submitting to a conference. If you have a blog, etc., please help by pointing your readers to: http://web.cecs.pdx.edu/~apt/icfp09_cfer.html Instructions for authors ~~~~~~~~~~~~~~~~~~~~~~~~ By Monday, 2 March 2009, 20:00 UTC, submit an abstract of at most 300 words and a full paper of at most 12 pages (4 pages for an Experience Report), including bibliography and figures. The deadline will be strictly enforced and papers exceeding the page limits will be summarily rejected. Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. A submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are below. Each submission must adhere to SIGPLAN's republication policy, as explained on the web. Violation risks summary rejection of the offending submission. Proceedings will be published by ACM Press. Authors of accepted submissions are expected to transfer the copyright to ACM. Presentations will be videotaped and released online if the presenter consents by signing an additional permission form at the time of the presentation. Released videos will be included along with the conference proceedings in the ACM Digital Library and may also be placed on a host such as YouTube or Google Video. Formatting: ~~~~~~~~~~~ Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. If this requirement is a hardship, make contact with the program chair at least one week before the deadline. ICFP proceedings are printed in black and white. It is permissible to include color in a submission, but you risk annoying reviewers who will have to decide if your final paper will be understandable without it. Papers must adhere to the standard ACM conference format: two columns, nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). A suitable document template for LaTeX is available from SIGPLAN. Submission: ~~~~~~~~~~~ Submissions will be accepted electronically at a URL to be named later. The deadline is set in Coordinated Universal Time. The world clock (http://www.timeanddate.com/worldclock/fixedtime.html?month=3&day=2&year=200…) can give you the equivalent in your local time, e.g., Noon Monday in Seattle, 3:00 PM Monday in New York, 8:00 PM Monday in London, 5:00 AM Tuesday in Tokyo. Citation: ~~~~~~~~~ We recommend (but do not require) that you put your citations into author-date form. This procedure makes your paper easier to review. For example, if you cite a result on testing as ``(Claessen and Hughes 2000)'', many reviewers will recognize the result instantly. On the other hand, if you cite it as ``[4]'', even the best-informed reviewer has to page through your paper to find the reference. By using author-date form, you enable a knowledgeable reviewer to focus on content, not arbitrary numbering of references. LaTeX users can simply use the natbib package along with the plainnat bibliography style. In practice, this means putting \usepackage{natbib} \bibpunct();A{}, \let\cite=\citep in your LaTeX preamble, and \bibliographystyle{plainnat} in your document. For most citations you will use the \cite command; if you want a citation like ``Claessen and Hughes (2000) showed that...'' you should use something like ``\citet{claessen:quickcheck} showed...'' Alternatively, the McBride bibliography style, which adheres to the Chicago manual of style ``Documentation Two'' specifications and which fixes some perceived deficiencies of natbib, may be used. The style file along with instructions for using it is available on the McBride web site. Author response: ~~~~~~~~~~~~~~~~ Authors will have a 48-hour period, starting at 20:00 UTC on 21 April 2009, to read and respond to reviews. Special categories of papers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In addition to research papers, ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers, and Experience Reports, which are limited to four pages. Authors submitting such papers may wish to consider the following advice. Functional Pearls ~~~~~~~~~~~~~~~~~ A Functional Pearl is an elegant essay about something related to functional programming. It might offer: * a new and thought-provoking way of looking at an old idea * an instructive example of program calculation or proof * a nifty presentation of an old or new data structure * an interesting application of functional programming techniques * a novel use or exposition of functional programming in the classroom Functional Pearls are not restricted to the above varieties, however. While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. Functional Pearls are valued as highly and judged as rigorously as ordinary papers, but using somewhat different criteria. In particular, a pearl is not required to report original research. However, it should be concise, instructive, and entertaining. Your pearl is likely to be rejected if your readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing. A submission you wish to have treated as a pearl must be marked as such on the submission web page, and should contain the words ``Functional Pearl'' somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. However, pearls will be combined with ordinary papers for the purpose of computing the conference's acceptance rate. Experience Reports ~~~~~~~~~~~~~~~~~~ The purpose of an Experience Report is to help create a body of published, refereed, citable evidence that functional programming really works---or to describe what obstacles prevent it from working. Possible topics for an Experience Report include, but are not limited to: * insights gained from real-world projects using functional programming * comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum * project-management, business, or legal issues encountered when using functional programming in a real-world project * curricular issues encountered when using functional programming in education * real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general An Experience Report is distinguished from a normal ICFP paper by its title, by its length, and by the criteria used to evaluate it. * Both in the proceedings and in any citations, the title of each accepted Experience Report must begin with the words ``Experience Report'' followed by a colon. The acceptance rate for Experience Reports will be computed and reported separately from the rate for ordinary papers. * An Experience Report is at most 4 pages long. Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience reports may be asked to give shorter talks. * Because the purpose of Experience Reports is to enable our community to accumulate a body of evidence about the efficacy of functional programming, an acceptable Experience Report need not add to the body of knowledge of the functional-programming community by presenting novel results or conclusions. It is sufficient if the Report states a clear thesis and provides supporting evidence. The thesis must be relevant to ICFP, but it need not be novel. The program committee will accept or reject Experience Reports based on whether they judge the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. Typically, more convincing evidence is obtained from papers which show how functional programming was used than from papers which only say that functional programming was used. The most convincing evidence often includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. An Experience Report should be short and to the point: make a claim about how well functional programming worked on your project and why, and produce evidence to substantiate your claim. If functional programming worked for you in the same ways it has worked for others, you need only to summarize the results---the main part of your paper should discuss how well it worked and in what context. Most readers will not want to know all the details of your project and its implementation, but please characterize your project and its context well enough so that readers can judge to what degree your experience is relevant to their own projects. Be especially careful to highlight any unusual aspects of your project. Also keep in mind that specifics about your project are more valuable than generalities about functional programming; for example, it is more valuable to say that your team delivered its software a month ahead of schedule than it is to say that functional programming made your team more productive. If your paper not only describes experience but also presents new technical results, or if your experience refutes cherished beliefs of the functional-programming community, you may be better off submitting it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. If you are unsure in which category to submit, the program chair will be happy to help you decide. Other information ~~~~~~~~~~~~~~~~~ Conference Chair ~~~~~~~~~~~~~~~~ Graham Hutton (University of Nottingham) Program Chair ~~~~~~~~~~~~~ Andrew Tolmach Department of Computer Science Portland State University P.O. Box 751, Portland, OR 97207 USA Email: apt(a)cs.pdx.edu Phone: +1 503 725 5492 Fax: +1 503 725 3211 Mail sent to the address above is filtered for spam. If you send mail and do not receive a prompt response, particularly if the deadline is looming, feel free to telephone. Program Committee ~~~~~~~~~~~~~~~~~ Amal Ahmed (Toyota Technological Institute, Chicago) Maria Alpuente (Technical University of Valencia (UPV)) Lennart Augustsson (Standard Chartered Bank) Lars Birkedal (IT University of Copenhagen) Manuel Chakravarty (University of New South Wales) Koen Claessen (Chalmers University of Technology) Marc Feeley (Universite de Montreal) Andrzej Filinski (University of Copenhagen) Daan Leijen (Microsoft Research) Xavier Leroy (INRIA Paris-Rocquencourt) Conor McBride (University of Strathclyde) Matthew Might (University of Utah) Shin-Cheng Mu (Academia Sinica) Atsushi Ohori (Tohoku University) Kristoffer Rose (IBM Thomas J. Watson Research Center) Important Dates (at 20:00 UTC) ~~~~~~~~~~~~~~~ Submission: 2 March 2009 Author response: 21-23 April 2009 Notification: 5 May 2009 Final papers due: 8 June 2009 ICFP 2009 Web Site ~~~~~~~~~~~~~~~~~~ http://www.cs.nott.ac.uk/~gmh/icfp09.html Special Journal Issue ~~~~~~~~~~~~~~~~~~~~~ There will be a special issue of the Journal of Functional Programming with papers from ICFP 2009. The program committee will invite the authors of select accepted papers to submit a journal version to this issue.

1 0

Missing comment highlighting in vim syntax script
by Ori Avtalion 15 Dec '08

15 Dec '08

Hi all, The Haskell syntax script for vim mentions this mailing list as the maintainer. Perhaps one of you could fix this bug. Comments on the same line as import declarations don't get highlighted: import A -- This comment isn't highlighted import B {- Neither is this -} import C {- and this -} I'm using this version of the syntax file: (the only version) http://vim.svn.sourceforge.net/viewvc/vim/vim7/runtime/syntax/haskell.vim?r… Thanks, Ori

4 3

Re: [Haskell] Re: Help : A problem with IO
by wman 15 Dec '08

15 Dec '08

you probably got it pointed out in haskell-beginners, but in case not: On Thu, Nov 27, 2008 at 7:10 PM, abdullah abdul Khadir < abdullah.ak2002(a)gmail.com> wrote: > a) I need to put a do after else for more than one instruction (?) No, the do thingy is a syntactic sugar for chaining "warm, fuzzy" (the "preffered" wannabe-joke-term for the presumably scary term monads/monadic) operations. it allows you to write in "classical" imperative/sequential style instead of chaining operations manually (using the >> and >>= operators, which the do notation translates into anyway). lookup some monad tutorials/docs. you are right in that if there is only one operation, no transformation is needed, so the do is unnecessary.

1 0

Problem with haddock 2.3.0 (again)
by Leonidas Fegaras 15 Dec '08

15 Dec '08

Sorry for the previous message. I am sending it again. Dear fellow haskell programmers, I tried to install a package in hackageDB and got a strange error from haddock: haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing Here is the complete log: http://hackage.haskell.org/packages/archive/HXQ/0.10.0/logs/failure/ghc-6.8 When I build it using Cabal 1.6.0.1 and haddock 2.2.2 using 'runhaskell Setup.lhs haddock', it works fine (I get warnings but no errors). Also haddock 2.3.0 is not available in hackageDB so I can't test it myself. Where I can find haddock 2.3.0? Thank you for your help, Leonidas Fegaras _________________________________________________________________ Stay organized with simple drag and drop from Windows Live Hotmail. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_102008

7 29

Parsec and type level numerals
by Nathan Bloomfield 15 Dec '08

15 Dec '08

Hello all. I've got a puzzling Parsec problem. Perhaps the collective wisdom of haskell-cafe can point me in the right direction. I want to be able to parse a string of digits to a type level numeral as described in the Number parameterized types<http://okmij.org/ftp/papers/number-parameterized-types.pdf>paper. After fiddling with the problem for a while, I'm not convinced it's possible- it seems as though one would need to know the type of the result before parsing, but then we wouldn't need to parse in the first place. :) My first (simplified) approximation is as follows: > data Zero = Zero > data Succ a = Succ a > class Card t > instance Card Zero > instance (Card a) => Card (Succ a) > parseP :: (Card a) => Parser a > parseP = do { char '1' > ; rest <- parseP > ; return $ Succ rest > } > <|> return Zero I'd like for this to parse, for example, "111" into Succ Succ Succ Zero. Of course this doesn't work because parseP is ill-typed, but I'm not sure how to fix it. It seems that what I'm asking for is a function whose type is forall a. (Card a) => String -> a, which is problematic. Has anyone tried this before? I'm new to using Parsec and to parsing in general, so I apologize if this is a silly question. (Parsec is very impressive, by the way.) Thanks- Nathan Bloomfield University of Arkansas, Fayetteville

5 4