- Haskell-Cafe - Haskell.org

ANN: #haskell-in-depth IRC channel
by Philippa Cowderoy 04 Feb '09

04 Feb '09

Hi folks. As I've been daft enough to get a few things rolling, it looks like it's fallen on me to announce the new IRC channel, #haskell-in-depth. #haskell has been a roaring success over the last few years, as Don has repeatedly pointed out. Unfortunately that roar is starting to make it hard for some to participate - there's so much traffic that it can be difficult to fit an additional conversation in. We're starting to hit the limits as to how far one channel can take us, and that means we need to explore ways to divide up traffic. Actually, this isn't entirely new - a number of years ago now, #haskell-blah was formed as a space for off-topic (and sometimes less-than-worksafe) conversation among #haskell regulars. We also created #haskell-overflow, but it doesn't see much use except among some of the cabal implementors because it's hard to know when to take the conversation you're currently in to -overflow. We need channels that people start their conversations in, not ones to send people to! So we're trying a space for in-depth discussion. The new channel is open to everyone, just like #haskell. But just as we're hoping for certain kinds of discussion, there're others we want to avoid. If you need to know how to use monads so you can do IO, #haskell-in-depth isn't the place. On the other hand, if you want to discuss how Haskell's monads compare to the category theory or what the category theory can tell us about how individual monads relate to the language as a whole, -in-depth is a good place! In particular, we're hoping that the kind of category theory discussions that give the mistaken impression you actually need to know CT will increasingly live in #haskell-in-depth. We're not after a theory channel though - architectural discussion, compiler implementation, possible type system extensions, library design, all are good subjects. Anyway, I shouldn't ramble on for too long here - #haskell-in-depth is open for business and we look forward to seeing you there! -- Philippa Cowderoy <flippa(a)flippac.org>

6 6

circular dependencies in cabal
by Valentyn Kamyshenko 04 Feb '09

04 Feb '09

Hello all, when I tried to install plugins package with cabal, I've got the following error: # sudo cabal install plugins --global Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0 It looks like both versions of process package are currently required: # ghc-pkg unregister process-1.0.1.0 ghc-pkg: unregistering process-1.0.1.0 would break the following packages: haddock-2.3.0 ghc-6.10.1 Cabal-1.6.0.1 gnuplot-0.2 pandoc-1.0.0.1 Graphalyze-0.5 haddock-2.4.1 kibro-0.4.2 panda-2008.11.7 (use --force to override) # ghc-pkg unregister process-1.0.1.1 ghc-pkg: unregistering process-1.0.1.1 would break the following packages: haddock-2.3.0 ghc-6.10.1 haskell-src-1.0.1.3 polyparse-1.1 Graphalyze-0.5 cpphs-1.6 hscolour-1.10.1 haddock-2.4.1 HaXml-1.19.4 hcheat-2008.11.6 rss-3000.1.0 kibro-0.4.2 panda-2008.11.7 haskell98-1.0.1.0 hxt-8.2.0 hcheat-2008.11.14 hxt-filter-8.2.0 xml- parsec-1.0.3 graphviz-2008.9.20 readline-1.0.1.0 uulib-0.9.5 derive-0.1.4 hslogger-1.0.6 MissingH-1.0.2.1 HStringTemplateHelpers-0.0.3 HSHHelpers-0.17 haskell-src-exts-0.4.4 haskell-src-exts-0.4.4.1 haskell-src-exts-0.4.5 ConfigFile-1.0.4 HStringTemplateHelpers-0.0.4 haskell-src-exts-0.4.6 kibro-0.4.3 panda-2008.12.16 HStringTemplateHelpers-0.0.6 SybWidget-0.4.0 wxcore-0.10.5 wx-0.10.5 xtc-1.0 HStringTemplateHelpers-0.0.8 wxcore-0.10.7 wx-0.10.6 HNM-0.1 HNM-0.1.1 wxcore-0.10.12 wxcore-0.11.0 wx-0.11.0 HSHHelpers-0.18 haskell-src-exts-0.4.8 darcs-2.2.0 hslogger-1.0.7 MissingH-1.0.3 HSH-1.2.6 HStringTemplateHelpers-0.0.10 HSHHelpers-0.19 hscolour-1.11 HNM-0.1.2 pandoc-1.1 mps-2008.11.6 hcheat-2008.11.25 panda-2009.1.20 testpack-1.0.0 convertible-1.0.1 gnuplot-0.3 HDBC-2.0.0 HDBC-2.0.1 HDBC-sqlite3-2.0.0.0 HDBC- postgresql-2.0.0.0 (use --force to override) Any suggestions? -- Valentyn

5 11

type metaphysics
by Gregg Reynolds 04 Feb '09

04 Feb '09

Hi, The concept of "type" seems to be a little like porno: I know it when I see it, but I can't define it (apologies to Justice Stewart). I've picked through lots of documents that discuss types in various ways, but I have yet to find one that actually says what a type "really" is. For example, definitions of the typed lambda calculus usually define some type symbols and rules like "a : T means a is of type T", and then reasoning ensues without discussion of what "type" means. The only discussion I've found that addresses this is at the Stanford Encyclopedia of Philosophy, article "Types and Tokens" [1]. It's all very philosophical, but there is one point there that I think has relevance to Haskell. It's in section 4.1, discussing the distinction between types and sets: "Another closely related problem also stems from the fact that sets, or classes, are defined extensionally, in terms of their members. The set of natural numbers without the number 17 is a distinct set from the set of natural numbers. One way to put this is that classes have their members essentially. Not so the species homo sapiens, the word 'the', nor Beethoven's Symphony No. 9. The set of specimens of homo sapiens without George W. Bush is a different set from the set of specimens of homo sapiens with him, but the species would be the same even if George W. Bush did not exist. That is, it is false that had George W. Bush never existed, the species homo sapiens would not have existed. The same species might have had different members; it does not depend for its existence on the existence of all its members as sets do." So it appears that one can think of a type as a predicate; any token (value?) that satisfies the predicate is a token (member?) of that type. This gives a very interesting way of looking at Haskell type constructors: a value of (say) Tcon Int is anything that satisfies "isA Tcon Int". The tokens/values of Tcon Int may or may not constitute a set, but even if they, we have no way of describing the set's extension. My hunch is that it /cannot/ be a set, although I'm not mathematician enough to prove it. My reasoning is that we can define an infinite number of data constructors for it, including at least all possible polynomials (by which I mean data constructors of any arity taking args of any type). To my naive mind this sounds suspiciously like the set of all sets, so it's too big to be a set. In any case, Tcon Int does not depend on any particular constructor, just as homo sapiens does not depend on any particular man. So it can't be a set because it doesn't have its members essentially. (I suspect this leads to DeepThink about classical v. constructivist mathematics, but that's a subject for a different discussion.) I'm not sure that works technically, but it seems kinda cool. My question for the list: is the collection of e.g. Tcon Int values a set, or not? If it is, how big is it? Thanks, gregg [1] http://plato.stanford.edu/entries/types-tokens/

21 43

Converting Lists to Sets
by rodrigo.bonifacio 04 Feb '09

04 Feb '09

Hi all, I'm trying to use the Funsat library. One of its data types is CNF: data CNF = CNF { numVars :: Int numClauses :: Int clauses :: Set Clause } I have a list of clauses, but I'm getting an error when converting such a list to a Set. Using the fromList function, the ghc compiler reports that the fromList function is not applicable to literals. type Clause = [Lit] newtype Lit = L { unLit :: Int } So, my question is: How can I solve this problem? Thanks in advance, Rodrigo.

4 3

Re: [Haskell-cafe] Elegant & powerful replacement for CSS
by Patai Gergely 03 Feb '09

03 Feb '09

> I've been wondering for a while now what a well-designed alternative > to CSS could be, where well-designed would mean consistent, composable, > orthogonal, functional, based on an elegantly compelling semantic model > (denotational). Well, if you think about CSS as in webpage styling, it's simply a way to override some attributes in the DOM tree. If you will, you can easily relate CSS selectors to your semantic editor combinators, since a concrete stylesheet makes explicit references to the structure of the document/interface it is associated with. One important difference is that in the case of CSS you don't need to mention all the intermediate nodes explicitly, which can make selectors shorter as well as "non-deterministic", i.e. they can match different structural patterns at the same time. Also, you can perform a kind of pattern matching (filtering by class/id names) besides just blindly walking down the tree along the type structure. I'd say these two features make it a direct generalisation of the SEC concept. Gergely -- http://www.fastmail.fm - The way an email service should be

2 1

Bytestrings vs String?
by Marc Weber 03 Feb '09

03 Feb '09

A lot of people are suggesting using Bytestrings for performance, strictness whatsoever reasons. However how well do they talk to other libraries? One I've in mind is hslogger right now. Should hslogger be implemented using Strings or Bytestrings ? Should there be two versions? hslogger-bytestring and hslogger-string? Or would it be better to implement one String class which can cope with everthing (performance will drop, won't it?) I feel it would make sense to talk about how to provide this? In the future I'd like to explore using haskell for web developement. So speed does matter. And I don't want my server to convert from Bytestrings to Strings and back multiple times.. So is the best we could do compile the same library twice using different flags ? One providing a Bytestring API, the other using Strings? Cluttering up code by from to Bytestring conversions doesn't look compelling to me. Thoughts? Marc Weber

4 6

Why binding to existing widget toolkits doesn't make any sense
by Achim Schneider 03 Feb '09

03 Feb '09

Hacking away on bindings to (http://libagar.org) specifically (http://libagar.org/mdoc.cgi?man=AG_Object.3) I was suddenly swept away by a general crisis of purpose: I was spending time on figuring out how to create agar objects, implemented in Haskell, on the fly, to enable me to write a high-level interface, instead of spending time on designing The FRUI API To Obsolete Them All. The reason for this are means of composability: What use is a nice interface to a button and an isomorphic interface to a textbox, if I can't compose them properly? Users might want to use standard widgets in indefinitely many combinations of type, with an equal amount of distinct wirings and external interfaces. As some of you might have noticed [1][2], constructing foreign objects is painful, specifying custom classes even more so... in case it's not infeasible hard to support in the first place. In agar's case it's certainly possible, by the virtue of being implemented in plain C. So we _could_ expose the whole generality of a TK's means of composing to the user. Which is most likely not what he wants, he wants to use the whole generality of Haskell to compose UI's. In Agar's case, the user won't care much about generating N checkboxes for a bitfield integer, he'd rather use [Event Bool]. Summing up, there's a lot of plumbing to be done, in the end still amounting to a lot of dead, unused code in the TK, BECAUSE TOOLKITS ARE DESIGNED TO BE USED IN THE LANGUAGE THEY WERE BLEEDING WRITTEN IN AND PROVIDE CUSTOM ABSTRACTIONS TAILORED TO THAT LANGUAGE. This is basically the Saphir-Worph hypothesis adapted to programs. So what's left of those TK's if we don't use their abstractions and replace them with Haskell? Drawing and layouting, that's what's left[3]. Both, IMNSHO, do not justify carrying around bloaty external dependencies, they're too trivial. They certainly don't justify using unsafePerformIO to hide foreign side effects and the headaches associated with it. So, if you don't mind, I'm going to stop trying to fit cubes into round holes and gonna use reactive and fieldtrip[4] to do things. [1]http://softbase.org/hqk/qoo/qoo.pdf [2]http://haskell.org/gtk2hs/docs/devel/System-Glib-GObject.html#v%3AmakeNew… [3]Somewhat disregarding using OS widgets, but that's unimportant since native look+feel is vastly overrated. I've got enough asbestos to defend that against alt.politics. [4]Gotta get rid of glut, though. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

21 71

Re: Why binding to existing widget toolkits doesn't make any sense
by John A. De Goes 03 Feb '09

03 Feb '09

CSS is purely declarative in nature and entirely deterministic. Moreover, it's expressive power is such that you can completely and radically alter the look of a website with modifications to CSS alone (see Zen Garden). The grammar and semantics are relatively simple and can be interpreted and generated by tools, which means that a designer can work with CSS files without knowing anything about CSS. Is it perfect? No. But it's a lot better than trying to encode everything in a single language that only a software developer can safely work with. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Feb 3, 2009, at 10:09 AM, Peter Verswyvelen wrote: > On Tue, Feb 3, 2009 at 5:49 PM, John A. De Goes <john(a)n-brain.net> > wrote: > I never said, "CSS", I said "like CSS". > > Oh, I missed the "like" word! What do you mean with that? What > aspects of CSS do you prefer to? In WPF a "style" is basically just > a bunch of attribute key/value pairs. > > > Layout combinators in the spirit of TeX or Lout are more > flexible while being simpler. In any case, a simple primitive > > grid :: [[Rect a]] -> Rect a > > that arranges widgets in a rectangular grid should be enough for GUIs. > > > Spoken like a true programmer who knows nothing about usability. :-) > > Yes, layout must be very versatile and user definable. > > > > Regards, > > John A. De Goes > N-BRAIN, Inc. > The Evolution of Collaboration > > http://www.n-brain.net | 877-376-2724 x 101 > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

[Colin Paul Adams] Re: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O
by Colin Paul Adams 03 Feb '09

03 Feb '09

>>>>> "John" == John Goerzen <jgoerzen(a)complete.org> writes: >> latin1, utf8, utf16, utf16le, utf16be, utf32, utf32le, utf32be, >> localeEncoding, John> Will there also be something to handle the UTF-16 BOM John> marker? I'm not sure what the best API for that is, since John> it may or may not be present, but it should be considered -- John> and could perhaps help autodetect encoding. Not really. The UTF-16 BOM is only allowed for utf16. Utf16le and utf16be do not have a BOM. What it does is alloww you to auto-detect the endianness if utf16 has been requested as the encoding (if it is not present the big-endian is assumed). Ditto for utf32/utf32be/utf32le. A BOM is thesedays allowed (but deprecated - it should never have been allowed and originally wasn't) for utf8 also. But it has no value other than to introduce ambiguity. :-( -- Colin Adams Preston Lancashire

2 2

Verifying Haskell Programs
by Paulo J. Matos 03 Feb '09

03 Feb '09

Hi all, Much is talked that Haskell, since it is purely functional is easier to be verified. However, most of the research I have seen in software verification (either through model checking or theorem proving) targets C/C++ or subsets of these. What's the state of the art of automatically verifying properties of programs written in Haskell? Cheers, -- Paulo Jorge Matos - pocmatos at gmail.com Webpage: http://www.personal.soton.ac.uk/pocm

7 10