December 2007 - Haskell-Cafe

Re: [Haskell-cafe] IO is a bad example for Monads
by Hans van Thiel 12 Dec '07

12 Dec '07

On Wed, 2007-12-12 at 16:27 +0100, Hans van Thiel wrote: > [snip] > > > > I fear those people can do vast amounts of damage. :( > > > > When inept programming yields the wrong result, it is clear (even to the > > inept) that the program is bad. > > > > When the result is correct but there are egregious time or space leaks, > > it is "clear" to everyone but the Haskell guru that it "must" be the > > programming language that is deficient, and will be duly flamed far and > > wide. This perception will be impossible to reverse when it gains > > traction (and nothing ever goes away on the Internet). > > > > Seeming "deus ex machina" code changes (perhaps helpfully offered on > > haskell-cafe) to minimize or correct the undesirable runtime behavior > > appear even to many Haskellites to be black magic, accompanied by the > > runes of profile dumps (like knowing what generation 0 and generation 1 > > garbage collection is). > I see your point, but maybe there should be better analyzing tools then, > as well as tutorials which explain that problem. > > > > >> Haskell is not a quick-and-dirty language but quite the opposite. Haskell’s > > >> unique selling propositions are features like type classes, higher order > > >> functions and lazy evaluation which make life easier in the long term. The > > >> downside of these features is that they might make life harder in the short > > >> term. > > > I don't know. In a sense Haskell is easier than, for example, C, because > > > the concept of a function definition is more natural that that of > > > assignments and loops. The idea that x = 5; x = x + 7 makes sense > > > requires a complete new way of thinking. OK, once you've been doing it > > > for a few years switching back to x = 5 + 7 is hard. > > > > I would limit that to say that *denotational* semantic intuition is easy > > to wield in Haskell. Operational semantic intuition is Haskell is very > > non-obvious to the imperative (and many functional) programmers. > > > > Making matters worse, the first is an advantage well-hyped by > > functionistas, the second hurdle is rarely admitted to. > I admit I don't understand this. > > > > >> That said, I definitely think that we should make learning the language as > > >> easy as possible. But our ultimate goal should be to primarily show > > >> newcomers the Haskell way of problem solving, not how to emulate Python or > > >> Java programming in Haskell. > > > Again, is there a danger of that happening? > > > > Yes. Those absent the necessary humility to approach haskell-cafe with > > open mind and flame-retardant dialog will fall back on what they know: > > transliterated Java/Python with a morass of do blocks and IO monads, > > then (rightly) bash how "ugly" Haskell syntax is when used in this way. > > > > This type of programmer looking to use Haskell casually should sign a > > "benefit of the doubt" contract whereby they assume that any runtime > > suboptimalities derive from their own coding and not from Haskell's > > defects. This is the innate assumption of the curious, the > > self-motivated, the clever. This is not typically the starting > > assumption of the "I'm an expert at Joe-imperative language" hacker who > > took 10 years to perfect his Java skills and expects thereby to jump to > > at least year 5 of Haskell without effort. > But that person will be used to all the help he's gotten from the Java > and/or Eclipse, with tutorials and reference implementations. Now he has > to depend on dissertations and JFP articles for anything that's less > than 10 years old, and a few helpful experts (much appreciated, I want > to add) who are willing to spend the time to answer questions. > > > > I do strongly believe in stimulating the curiosity of all comers, just > > not in giving the false impression that a quick read-through of a few > > tutorials will let you write lightning-fast code, or know when to > > abandon [Char] for something more clever, or where to insert those bangs > > and fold left instead of right, and how ad hoc and parametric > > polymorphism differ, and what Rank-n and existential means (and why you > > can just pickle any object in Python but need to know a half dozen > > abstract things including who Peano was to do the same in Haskell), and > > what the heck an infinite type is, and on and on. > It's possible, IMO, that Haskell requires a higher skill level in > information science that the imperative languages. Many working > programmers come from different backgrounds and are not experts in > computer science. But, like a skyscraper is not built just by the > architects, maybe those 'lower' skills have their place too. Maybe not, > or not in Haskell. Could be, though I don't think so, myself. > > Haskell has definitely been teaching me some serious humility! Possibly > > it is best that those not ready for that lesson might better stick with > > Python. > If they read this, I'm sure they will. > > Best Regards, > > Hans van Thiel > >

1 0

ANNOUNCE: dataenc-0.10.1
by Magnus Therning 12 Dec '07

12 Dec '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yesterday I uploaded a small update to the dataenc library: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dataenc-0.10.1 Dependencies base License LGPL Copyright Magnus Therning, 2007 Author Magnus Therning Maintainer magnus(a)therning.org Exposed modules Codec.Binary.DataEncoding, Codec.Binary.Base16, Codec.Binary.Base32Hex, Codec.Binary.Base32, Codec.Binary.Uu, Codec.Binary.Base64Url, Codec.Binary.Base64 The visible change is the addition of a function, decode', that allows lazier decoding by shifting some responisility to the user. /M -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHX9G+iMWTaatN+6QRAqclAKC6/BM7/e9jRAjVCMYYAZd7D/fAPACfe0sd EfPoHw4HW7snU3RilejfIIY= =XPUb -----END PGP SIGNATURE-----

1 0

do
by PR Stanley 11 Dec '07

11 Dec '07

Hi I've probably asked about the do construct, if that's the right label. Unfortunately I'm still not quite sure of its role and more specifically its syntax. Something to do with generators perhaps? A description plus some examples would be most gratefully received. Thanks, Paul

26 52

Re: [Haskell-cafe] class default method proposal
by David Menendez 11 Dec '07

11 Dec '07

On Dec 11, 2007 1:29 PM, apfelmus <apfelmus(a)quantentunnel.de> wrote: > Without the automatic search, this is already possible > > class Functor f where > fmap :: (a -> b) -> f a -> f b > > class Functor m => Monad m where > return :: a -> m a > (>>=) :: m a -> (a -> m b) -> m b > > -- aka liftM > fmapDefault :: Monad m => (a -> b) -> m a -> m b > fmapDefault f m = m >>= (return . f) > > instance Monad [] where > return x = [x] > (>>=) = flip concatMap > > instance Functor [] where > fmap = fmapDefault > > fmap is already written for you, the instance declaration is only > boilerplate. I first saw this in Data.Traversable . > This is pretty much how I define Functor and Applicative instances for my monads. It is admittedly irritating to have to write out the boilerplate, but it doesn't seem irritating enough to require a language extension to eliminate. -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/>

2 1

unsubscribe
by Tim- tigre11 11 Dec '07

11 Dec '07

Very suspicious extension of attachment Sender: "Gwern Branwen" <gwern0(a)gmail.com> Recipient: haskell-cafe(a)haskell.org Subject: [Haskell-cafe] Software Tools in Haskell --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 071210-0, 10/12/2007 Tested on: 12/12/2007 9:33:52 AM avast! - copyright (c) 1988-2007 ALWIL Software. http://www.avast.com

2 1

grammars and generics
by Greg Meredith 11 Dec '07

11 Dec '07

Haskellians, Here is an idea so obvious that someone else must have already thought of it and worked it all out. Consider the following grammar. N0 ::= T0 N1 | T1 N1 N0 | T2 N0 N0 N1 ::= T3 N0 where Ti (0 <= i < 4) are understood to be terminals. Using generics we can translate each production independently of the others. Like so: [| N0 ::= T0 N1 | T1 N1 N0 | T2 N0 N0 |] = data N0 n1 = T0 n1 | T1 n1 (N0 n1) | T2 (N0 n1) (N0 n1) deriving (Eq, Show) [| N1 ::= T3 N0 |] = data N1 n0 = T3 n0 deriving (Eq, Show) Then, we can compose the types to get the recursive grammar. data G = N0 (N1 G) deriving (Eq, Show) This approach has the apparent advantage of treating each production independently and yet being compositional. Now, let me de-obfuscate the grammar above. The first production should be very familiar. Term ::= Var Name | Abstraction Name Term | Application Term Term The generics-based translation of this grammar yields something we already know: we can use lots of different types to work as identifiers. This is something that the nominal of Gabbay, Pitts, et al, have factored out nicely. The second production can be treated independently, but composes well with the first. Name ::= Quote Term This illustrates that a particularly interesting class of names is one that requires we look no further than our original (parametric) data type. So, my question is this. Does anyone have a reference for this approach to translation of grammars? Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 505 N 72nd St Seattle, WA 98103 +1 206.650.3740 http://biosimilarity.blogspot.com

2 1

Re: [Haskell-cafe] grammars and generics
by Greg Meredith 11 Dec '07

11 Dec '07

Dusan, Excellent point. To close it off, you need to add an "empty" alternative. Thus, the corrected form would be N0 ::= TEmpty | T0 N1 | T1 N1 N0 | T2 N0 N0 N1 ::= T3 N0 In the lambda calculus, this would show up as a constant term, say 0, that would have to be treated in the operational semantics. See my ltu posting<http://lambda-the-ultimate.org/node/1930>of a year ago. Best wishes, --greg On Dec 11, 2007 11:33 AM, Dušan Kolář <kolar(a)fit.vutbr.cz> wrote: > Hello, > > I can't help you with the Haskell question as I'm not really in that > much. Nevertheless, your grammar is non-generating one - that means, it > cannot generate any sentence. If the starting non-terminal is N0 then > there is no production generating a string of terminals, thus, both > non-terminals (even if reachable from the staring one) are so called > non-generating ones (they can be freely removed from the grammar and all > involved productions too). > Thus, you get empty grammar. Isn't that the problem? Shouldn't the > grammar be like: > > N0 ::= T0 N1 | T1 N1 N0 | T2 N0 N0 > N1 ::= T3 T4 > > ? > > Best regards > > Dusan > > > Greg Meredith wrote: > > Haskellians, > > > > Here is an idea so obvious that someone else must have already thought > > of it and worked it all out. Consider the following grammar. > > > > N0 ::= T0 N1 | T1 N1 N0 | T2 N0 N0 > > N1 ::= T3 N0 > > > > where Ti (0 <= i < 4) are understood to be terminals. > > > > Using generics we can translate each production independently of the > > others. Like so: > > > > [| N0 ::= T0 N1 | T1 N1 N0 | T2 N0 N0 |] > > = > > data N0 n1 = T0 n1 | T1 n1 (N0 n1) | T2 (N0 n1) (N0 n1) deriving (Eq, > > Show) > > > > [| N1 ::= T3 N0 |] > > = > > data N1 n0 = T3 n0 deriving (Eq, Show) > > > > Then, we can compose the types to get the recursive grammar. > > > > data G = N0 (N1 G) deriving (Eq, Show) > > > > This approach has the apparent advantage of treating each production > > independently and yet being compositional. > > > > Now, let me de-obfuscate the grammar above. The first production > > should be very familiar. > > > > Term ::= Var Name | Abstraction Name Term | Application Term Term > > > > The generics-based translation of this grammar yields something we > > already know: we can use lots of different types to work as > > identifiers. This is something that the nominal of Gabbay, Pitts, et > > al, have factored out nicely. > > > > The second production can be treated independently, but composes well > > with the first. > > > > Name ::= Quote Term > > > > This illustrates that a particularly interesting class of names is one > > that requires we look no further than our original (parametric) data > > type. > > > > So, my question is this. Does anyone have a reference for this > > approach to translation of grammars? > > > > Best wishes, > > > > --greg > > > > > > -- > > L.G. Meredith > > Managing Partner > > Biosimilarity LLC > > 505 N 72nd St > > Seattle, WA 98103 > > > > +1 206.650.3740 > > > > http://biosimilarity.blogspot.com > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > -- > > Dusan Kolar tel: +420 54 114 1238 > UIFS FIT VUT Brno fax: +420 54 114 1270 > Bozetechova 2 e-mail: kolar(a)fit.vutbr.cz > Brno 612 66 > Czech Republic > > -- > > -- L.G. Meredith Managing Partner Biosimilarity LLC 505 N 72nd St Seattle, WA 98103 +1 206.650.3740 http://biosimilarity.blogspot.com

1 0

c2hs and cabal
by Stefan Kersten 11 Dec '07

11 Dec '07

hi, i'm looking for a way to integrate c2hs (single .chs file) in a cabal build setup; can anybody give me some hints? thanks, <sk>

3 3

FFI: "foreign label" declaration
by Ricardo Herrmann 11 Dec '07

11 Dec '07

Hi everyone, I'm trying to get HBDD compiled under GHC 6.8.1 and now I'm stuck with a .chs file which uses a "foreign label" syntax, which seems deprecated, since the parser can't even recognize it: foreign label "bdd_reorder_stable_window3" bdd_reorder_stable_window3 :: FunPtr (BDDManager -> IO ()) Is there new syntax for this ? Or is it a deprecated functionality ? Thanks in advance, -- Ricardo Guimarães Herrmann "In a concurrent world, imperative is the wrong default!" -- Tim Sweeney (Epic Games) -- View this message in context: http://www.nabble.com/FFI%3A-%22foreign-label%22-declaration-tp14279625p142… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

2 2

Re: distinguish functions from non-functions in a class/instances
by oleg＠pobox.com 11 Dec '07

11 Dec '07

Philipp N. wrote: > i'm trying to wrap functions (a -> b -> ... -> z) of any arity to functions > of type ([String] -> y), where list of strings replaces the typed arguments. > the problem is, that you cannot distinguish type (x->y) from z, so these > instances are overlapping. to which apfelmus replied > Exactly. What you want to do is most likely impossible, In fact, that distinction is possible. The following article How to write an instance for not-a-function http://okmij.org/ftp/Haskell/typecast.html#is-function-type specifically describes a method of writing an instance which is selected only when the type in question is NOT a function. The method is quite general and has been extensively used (for example, to implement deep monadic join).

8 18