[Haskell-cafe] 'let' keyword optional in do notation?
Hi cafe, For a while now, I've been wondering why the 'let' keyword in a do block isn't optional. So instead of do ... let x = exp1 y = exp2 z - exp3 ... you could simply write do ... x = exp1 y = exp2 z - exp3 ... Where each sequence of let-less bindings is put in a separate binding group. I'm no parsing wizard, but I couldn't come up with any situations in which this would cause ambiguity. To me, the let-less version is easier on the eyes, more consistent with - bindings, and also makes it less of a hassle to move stuff around. The above probably also holds for list/monad comprehensions, but the explicit let has never really bothered me there. Cheers, Martijn Schrage -- Oblomov Systems (http://www.oblomov.com) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'let' keyword optional in do notation?
2012/8/8 Martijn Schrage mart...@oblomov.com: Hi cafe, For a while now, I've been wondering why the 'let' keyword in a do block isn't optional. So instead of do ... let x = exp1 y = exp2 z - exp3 ... you could simply write do ... x = exp1 y = exp2 z - exp3 ... Where each sequence of let-less bindings is put in a separate binding group. I'm no parsing wizard, but I couldn't come up with any situations in which this would cause ambiguity. To me, the let-less version is easier on the eyes, more consistent with - bindings, and also makes it less of a hassle to move stuff around. The above probably also holds for list/monad comprehensions, but the explicit let has never really bothered me there. Hi, This is not a parsing problem, but a scoping one: try to run this program: main = do let x = y y = 5 let a = b let b = 6 print (x, y, a, b) Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'let' keyword optional in do notation?
Vo Minh Thu not...@gmail.com wrote: This is not a parsing problem, but a scoping one: try to run this program: main = do let x = y y = 5 let a = b let b = 6 print (x, y, a, b) Cheers, Thu Martijn has actually covered this question: Where each sequence of let-less bindings is put in a separate binding group. I'm no parsing wizard, but I couldn't come up with any situations in which this would cause ambiguity. To me, the let-less version is easier on the eyes, more consistent with - bindings, and also makes it less of a hassle to move stuff around. The suggestion seems sound to me, and the additional 'let' can really be annoying in cases where you have a lot of 'let' bindings among very few monadic actions. My current way to deal with this is to move the stuff to separate computations, but it's certainly not a nice solution: myComp = c = f where f x = ... where a = ... b = ... Greets Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'let' keyword optional in do notation?
On 08-08-12 17:27, Ertugrul Söylemez wrote: Vo Minh Thu not...@gmail.com wrote: This is not a parsing problem, but a scoping one: try to run this program: main = do let x = y y = 5 let a = b let b = 6 print (x, y, a, b) Cheers, Thu Martijn has actually covered this question: Where each sequence of let-less bindings is put in a separate binding group. I'm no parsing wizard, but I couldn't come up with any situations in which this would cause ambiguity. To me, the let-less version is easier on the eyes, more consistent with - bindings, and also makes it less of a hassle to move stuff around. To make it more clear, this is the transformation I propose: do ...-- not a let-less binding x1 = exp1 -- \ .. -- only let-less bindings xn = expn -- / ...-- not a let-less binding becomes do ... let x1 = exp1 .. xn = expn ... So main = do x = y y = 5 a = b b = 6 print (x, y, a, b) would put everything in the same binding group and compile successfully. To get Thu's example, you would write main = do x = y y = 5 let a = b let b = 6 print (x, y, a, b) The last let could even be left out. Cheers, Martijn The suggestion seems sound to me, and the additional 'let' can really be annoying in cases where you have a lot of 'let' bindings among very few monadic actions. My current way to deal with this is to move the stuff to separate computations, but it's certainly not a nice solution: myComp = c = f where f x = ... where a = ... b = ... Greets Ertugrul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: 'let' keyword optional in do notation?
-- Forwarded message -- From: David Feuer david.fe...@gmail.com Date: Wed, Aug 8, 2012 at 12:22 PM Subject: Re: [Haskell-cafe] 'let' keyword optional in do notation? To: Martijn Schrage mart...@oblomov.com Changing scoping rules based on whether things are right next to each other? No thanks. On Wed, Aug 8, 2012 at 11:44 AM, Martijn Schrage mart...@oblomov.com wrote: On 08-08-12 17:27, Ertugrul Söylemez wrote: Vo Minh Thu not...@gmail.com wrote: This is not a parsing problem, but a scoping one: try to run this program: main = do let x = y y = 5 let a = b let b = 6 print (x, y, a, b) Cheers, Thu Martijn has actually covered this question: Where each sequence of let-less bindings is put in a separate binding group. I'm no parsing wizard, but I couldn't come up with any situations in which this would cause ambiguity. To me, the let-less version is easier on the eyes, more consistent with - bindings, and also makes it less of a hassle to move stuff around. To make it more clear, this is the transformation I propose: do ...-- not a let-less binding x1 = exp1 -- \ .. -- only let-less bindings xn = expn -- / ...-- not a let-less binding becomes do ... let x1 = exp1 .. xn = expn ... So main = do x = y y = 5 a = b b = 6 print (x, y, a, b) would put everything in the same binding group and compile successfully. To get Thu's example, you would write main = do x = y y = 5 let a = b let b = 6 print (x, y, a, b) The last let could even be left out. Cheers, Martijn The suggestion seems sound to me, and the additional 'let' can really be annoying in cases where you have a lot of 'let' bindings among very few monadic actions. My current way to deal with this is to move the stuff to separate computations, but it's certainly not a nice solution: myComp = c = f where f x = ... where a = ... b = ... Greets Ertugrul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] 3 level hierarchy of Haskell objects
Gast [1] describes a 3 level hierarchy of Haskell objects using elementOf from set theory:value *elementOf* type *elementOf* classQuestionIf we include super-classes would the following be an appropriate mathematical representation?value *elementOf* type *elementOf* class *subSet* super-classMaybe instantiated classes would make more sense in the hierarchy?My thinking is that values and types and instances are concrete whereas classes are not.Regards,Pat[1] bib.informatik.uni-tuebingen.de/files/wsi-berichte/wsi-99-5.ps.gz Tá an teachtaireacht seo scanta ó thaobh ábhar agus víreas ag Seirbhís Scanta Ríomhphost de chuid Seirbhísí Faisnéise, ITBÁC agus meastar í a bheith slán. http://www.dit.ie This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: 'let' keyword optional in do notation?
On Wed, Aug 08, 2012 at 12:22:39PM -0400, David Feuer wrote: Changing scoping rules based on whether things are right next to each other? No thanks. Would expanding each let-less binding to a separate let feel more sound to you? Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 3 level hierarchy of Haskell objects
Patrick Browne patrick.bro...@dit.ie wrote: Gast [1] describes a 3 level hierarchy of Haskell objects using elementOf from set theory: value *elementOf* type *elementOf* class This hierarchy is pretty arbitrary and quickly runs into problems with some type system extensions. You can find out whether the barber of Seville shaves himself. A better hierarchial model is related to universes and uses type relations (assuming a right-associative ':'): value : type : kind : sort : ... value : type : universe 0 : universe 1 : universe 2 : ... A value is of a type. A type is of the first universe (kind). An n-th universe is of the (n+1)-th universe. Type classes can be modelled as implicit arguments. If we include super-classes would the following be an appropriate mathematical representation? What is a superclass? What are the semantics? Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: 'let' keyword optional in do notation?
On 08-08-12 19:01, Simon Hengel wrote: On Wed, Aug 08, 2012 at 12:22:39PM -0400, David Feuer wrote: Changing scoping rules based on whether things are right next to each other? No thanks. Would expanding each let-less binding to a separate let feel more sound to you? That was actually my first idea, but then two declarations at the same level will not be in the same binding group, so do x = y y = 1 would not compile. This would create a difference with all the other places where bindings may appear. However, having scope depend on things being next to each other (or rather, not having anything in between) is not new. Template Haskell declaration splices already cause separate binding groups for top-level declarations. Moreover, the new scope rule only holds for let-less bindings. If you use explicit lets nothing changes. -- Martijn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 3 level hierarchy of Haskell objects
On 08/08/12, Ertugrul Söylemez e...@ertes.de wrote: If we include super-classes would the following be an appropriate mathematical representation?What is a superclass? What are the semantics?I assume that like a normal class a super-class *defines* a set operations for types, but it is not *a set* of types.A sub-class can use the signature and default methods of its super-class.I have no particular super-class in mind.Rather I am trying to make sense of how these Haskell objects are mathematically related.Regards,Pat Tá an teachtaireacht seo scanta ó thaobh ábhar agus víreas ag Seirbhís Scanta Ríomhphost de chuid Seirbhísí Faisnéise, ITBÁC agus meastar í a bheith slán. http://www.dit.ie This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: 'let' keyword optional in do notation?
Is it really so bad to use an explicit let when you need mutually recursive bindings? On Aug 8, 2012 1:51 PM, Martijn Schrage mart...@oblomov.com wrote: On 08-08-12 19:01, Simon Hengel wrote: On Wed, Aug 08, 2012 at 12:22:39PM -0400, David Feuer wrote: Changing scoping rules based on whether things are right next to each other? No thanks. Would expanding each let-less binding to a separate let feel more sound to you? That was actually my first idea, but then two declarations at the same level will not be in the same binding group, so do x = y y = 1 would not compile. This would create a difference with all the other places where bindings may appear. However, having scope depend on things being next to each other (or rather, not having anything in between) is not new. Template Haskell declaration splices already cause separate binding groups for top-level declarations. Moreover, the new scope rule only holds for let-less bindings. If you use explicit lets nothing changes. -- Martijn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 3 level hierarchy of Haskell objects
Patrick Browne patrick.bro...@dit.ie wrote: If we include super-classes would the following be an appropriate mathematical representation? What is a superclass? What are the semantics? I assume that like a normal class a super-class *defines* a set operations for types, but it is not *a set* of types. A sub-class can use the signature and default methods of its super-class. I have no particular super-class in mind. So you basically just mean class (Functor f) = Applicative f where Functor is a superclass of Applicative? There is really nothing special about that. Notice that type classes are a language feature that is translated to a core language, which is essentially an extended System F_omega. See below. Rather I am trying to make sense of how these Haskell objects are mathematically related. They are mainly related by logic, in particular type theory. You may be interested in System F_omega [1]. [1]: http://en.wikipedia.org/wiki/System_F#System_F.CF.89 Greets, Ertugrul -- Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 Keysrv: hkp://subkeys.pgp.net/ signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] parsec: parserFail multiple error messages
I am trying to create a parsec parser that parses an integer and then checks if that integer has the right size. If not, it generates an error. I tried the following: 8--- import Text.Parsec import Text.Parsec.String integer :: Parser Int integer = do s - many1 digit let n = read s if n 65535 then parserFail integer overflow else return n 8--- The problem is that when I try this parse integer 7 I get the following error: Left (line 1, column 6): unexpected end of input expecting digit integer overflow ie there are three error messages but I only want the last one. Is there something I can do about this? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 3 level hierarchy of Haskell objects
On 08/08/12, Ertugrul Söylemez e...@ertes.de wrote:So you basically just mean class (Functor f) = Applicative fYes, but I want to know if there is a simple mathematical relation between the classes and/or their typesBut from your emails the original hierarchy seems to have been superseded, and my expectation of a simple set-theoretic relation is a bit naive.Thanks,Pat Tá an teachtaireacht seo scanta ó thaobh ábhar agus víreas ag Seirbhís Scanta Ríomhphost de chuid Seirbhísí Faisnéise, ITBÁC agus meastar í a bheith slán. http://www.dit.ie This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] parsec: parserFail multiple error messages
I found a similar question asked in June 2009 on the haskell-beginners archives, titled Clearing Parsec error messages. A hack that was proposed (http://www.haskell.org/pipermail/beginners/2009-June/001809.html) was to insert a dummy character into the stream, consume it, and then fail. Still, I'd like to see if there is a cleaner way to modify the error state in the Parsec monad. NIck On Wednesday, August 08, 2012 03:24:31 PM silly wrote: I am trying to create a parsec parser that parses an integer and then checks if that integer has the right size. If not, it generates an error. I tried the following: 8--- import Text.Parsec import Text.Parsec.String integer :: Parser Int integer = do s - many1 digit let n = read s if n 65535 then parserFail integer overflow else return n 8--- The problem is that when I try this parse integer 7 I get the following error: Left (line 1, column 6): unexpected end of input expecting digit integer overflow ie there are three error messages but I only want the last one. Is there something I can do about this? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] foreign import and gmp
Hi all, There have been rumors that recent versions of GHC may allow foreign imports of objects that link against gmp without interfering with the gmp imports in integer-gmp. What is the current state of that issue? What is the currently recommended way to deal with that problem? Thanks, Lars ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] foreign import and gmp
You need to build GHC using the integer-simple library (instead of the 'integer-gmp' library). From the 6.12.1 release notes: It is now possible to build GHC with a simple, BSD-licensed Haskell implementation of Integer, instead of the implementation on top of GMP. To do so, set INTEGER_LIBRARY to integer-simple in mk/build.mk. In addition, some libraries depend on integer-gmp (sadly). This is usually part of an optimization and when I see it I tend to send in a patch adding an integer-simple flag so you can cabal install it by including -finteger-simple on the command line (text is an example of one such library). And that's it! Your integer operations will run slower but you should get stable operation even when using the GMP library. Cheers, Thomas On Wed, Aug 8, 2012 at 2:45 PM, Lars Kuhtz hask...@kuhtz.eu wrote: Hi all, There have been rumors that recent versions of GHC may allow foreign imports of objects that link against gmp without interfering with the gmp imports in integer-gmp. What is the current state of that issue? What is the currently recommended way to deal with that problem? Thanks, Lars ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] foreign import and gmp
On 8/8/12 2:55 PM, Thomas DuBuisson wrote: You need to build GHC using the integer-simple library (instead of the 'integer-gmp' library). From the 6.12.1 release notes: It is now possible to build GHC with a simple, BSD-licensed Haskell implementation of Integer, instead of the implementation on top of GMP. To do so, set INTEGER_LIBRARY to integer-simple in mk/build.mk. How to I build the Haskell platform in this case? Is it enough to just use a GHC that was build with INTEGER_LIBRARY=integer-simple in the build of the platform, or do I need to somehow configure the platform build to prevent packages from importing integer-gmp? In addition, some libraries depend on integer-gmp (sadly). This is usually part of an optimization and when I see it I tend to send in a patch adding an integer-simple flag so you can cabal install it by including -finteger-simple on the command line (text is an example of one such library). Does this mean that text does already support this flag? And that's it! Your integer operations will run slower but you should get stable operation even when using the GMP library. What about operations on Integers with small values? Are they still efficient, i.e. directly mapped to operations on native int? I suppose that Integers with big values are not very common in the runtime and the base packages. Thanks, Lars ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] foreign import and gmp
On Wed, Aug 8, 2012 at 3:24 PM, Lars Kuhtz hask...@kuhtz.eu wrote: On 8/8/12 2:55 PM, Thomas DuBuisson wrote: You need to build GHC using the integer-simple library (instead of the 'integer-gmp' library). From the 6.12.1 release notes: It is now possible to build GHC with a simple, BSD-licensed Haskell implementation of Integer, instead of the implementation on top of GMP. To do so, set INTEGER_LIBRARY to integer-simple in mk/build.mk. How to I build the Haskell platform in this case? Is it enough to just use a GHC that was build with INTEGER_LIBRARY=integer-simple in the build of the platform, or do I need to somehow configure the platform build to prevent packages from importing integer-gmp? I don't understand this question largely because I don't understand the need to consider an entity called the Haskell Platform. You can build and install individual libraries. Some of those libraries will not build and install the trivial way (cabal install BLAH) but will build and install when given a flag (cabal install -f integer-simple BLAH). I hope (but have not put in any effort) for the HP community to push for a single solution that includes tivial compile-time detection of the integer support, thus making flags unnecessary. In addition, some libraries depend on integer-gmp (sadly). This is usually part of an optimization and when I see it I tend to send in a patch adding an integer-simple flag so you can cabal install it by including -finteger-simple on the command line (text is an example of one such library). Does this mean that text does already support this flag? Yes: http://hackage.haskell.org/packages/archive/text/0.11.2.2/text.cabal And that's it! Your integer operations will run slower but you should get stable operation even when using the GMP library. What about operations on Integers with small values? Are they still efficient, i.e. directly mapped to operations on native int? For that you'll have to look at the integer-simple package, perform some benchmarks, or wait another five minutes for someone besides me to answer. Even small Int's are represented via a slightly more involved ADT so I expect there will be more pointers and measurably more overhead. Cheers, Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 3 level hierarchy of Haskell objects
On 8/8/12 3:36 PM, Patrick Browne wrote:
On 08/08/12, *Ertugrul Söylemez *e...@ertes.de wrote:
So you basically just mean
class (Functor f) = Applicative f
Yes, but I want to know if there is a simple mathematical relation between the
classes and/or their types
Let us introduce the notion of sorts. A sort is, essentially, a
syntactic class for defining a (logical) language. Sorts cannot, in
general, be discussed within the language being described; though the
language may have some proxy for referring to them (e.g., the Set,
Type, and Prop keywords in Coq). We will discuss three sorts: Type,
Kind, and Context.
The sort Kind is a set of all the syntactic expressions denoting
traditional kinds; i.e.,
Kind = {*, *-*-*, (*-*)-*,...}
The sort Type is the set of all traditional types[1]; i.e.,
Type = { t : k | k \in Kind }
A type class is a relation on Type. Notably, a type class instantiated
with all its arguments is not itself a type! That is, Functor f does
not belong to Type, it belongs to Context. Indeed, the only constructors
of Context are (1) type classes, and (2) the ~ for type equality
constraints.
The simplest relation is a unary relation, which is isomorphic to a set.
Thus, if one were so inclined, one could think of Functor as being a
set of types[2], namely a set of types of kind *-*. And each instance
Functor f is a proof that f belongs to the set Functor.
However, once you move outside of H98, the idea of type classes as sets
of types breaks down. In particular, once you have multi-parameter type
classes you must admit that type classes are actually relations on types.
The = arrow in type signatures is an implication in the logic that
Haskell corresponds to. In particular, it takes multiple antecedents of
sort Context, a single consequent of sort S \in {Type, Context}, and
produces an expression of sort S. This is different from the - arrow
which is also implication, but which takes a single antecedent of sort
Type (namely a type of kind *) and a single consequent of sort Type
(namely a type of kind *), and produces an expression of sort Type
(namely a type of kind *). And naturally the - on Type should be
distinguished from the - on Kind: which takes a single antecedent of
sort Kind, a single consequent of sort Kind, and produces an expression
of sort Kind. Just as Kind exists to let us typecheck expressions in
Type, we should also consider a sort ContextKind which exists to let us
typecheck the expressions in Context. And, to handle the fact that type
classes have arguments of different kinds, ContextKind must have it's
own arrow, just as Kind does.
[1] Note that for this discussion, Type includes both proper types
(i.e., types of kind *) as well as type constructors.
[2] This must not be confused with the sense in which kinds can be
considered to be sets of types. These two different notions of sets of
types belong to different sorts. A kind is a set of types which lives
in Kind; a unary type-class constraint is a set of types which lives in
Context.
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 3 level hierarchy of Haskell objects
On 9/08/2012, at 11:11 AM, wren ng thornton wrote: Notably, a type class instantiated with all its arguments is not itself a type! All the comparisons of Haskell typeclasses with Java classes answered in one brief lucid sentence. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 239
Welcome to issue 239 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers the week of July 29 to August 4, 2012. Quotes of the Week * romm: i thought i knew programming. this is like discovering a new continent. * edwardk: i think the comonads are warm fuzzy, and the monads are warm sticky. its easy to get out of a comonad, its soft and you like wearing it. monads on the other hand stick to you and are icky Top Reddit Stories * Update on GHC's new code generator Domain: hackage.haskell.org, Score: 70, Comments: 39 On Reddit: [1] http://goo.gl/NkmqH Original: [2] http://goo.gl/4bUw1 * The first video in my new series of free Haskell live coding videos Domain: youtube.com, Score: 64, Comments: 61 On Reddit: [3] http://goo.gl/f1tmg Original: [4] http://goo.gl/ihwze * hbro, Haskell based browser, ideologically similar to uzbl Domain: github.com, Score: 48, Comments: 18 On Reddit: [5] http://goo.gl/apILX Original: [6] http://goo.gl/STSwc * Thinking Functionally with Haskell | PragProg Domain: pragprog.com, Score: 32, Comments: 6 On Reddit: [7] http://goo.gl/yL4Qj Original: [8] http://goo.gl/mHss0 * Two ways of representing perfect binary trees : Inside 374 Domain: blog.ezyang.com, Score: 30, Comments: 1 On Reddit: [9] http://goo.gl/1GfdH Original: [10] http://goo.gl/JJAl1 * Hoogle: from the command line Domain: self.haskell, Score: 28, Comments: 8 On Reddit: [11] http://goo.gl/Ob9Mw Original: [12] http://goo.gl/Ob9Mw * Free monad transformers Domain: haskellforall.com, Score: 27, Comments: 11 On Reddit: [13] http://goo.gl/XbQAj Original: [14] http://goo.gl/bJfrK * If someone asked you why Haskell?, what would you say? Domain: self.haskell, Score: 26, Comments: 73 On Reddit: [15] http://goo.gl/LQUUh Original: [16] http://goo.gl/LQUUh * Feedback from someone who learnt Haskell as his first language Domain: blog.raynes.me, Score: 25, Comments: 50 On Reddit: [17] http://goo.gl/QsnfZ Original: [18] http://goo.gl/wFOLN * Why isn't `length` part of `Foldable`? Domain: self.haskell, Score: 23, Comments: 19 On Reddit: [19] http://goo.gl/L0WWX Original: [20] http://goo.gl/L0WWX Top StackOverflow Questions * Monoidal parsing — what is it? votes: 19, answers: 2 Read on SO: [21] http://goo.gl/bVGBo * Applying multiple functions to the same value point-free style in Haskell votes: 7, answers: 4 Read on SO: [22] http://goo.gl/PifBz * How do I get consistent criterion benchmarks, or interpret results across runs? votes: 7, answers: 1 Read on SO: [23] http://goo.gl/qwT5c * Why is this prime test so slow? votes: 7, answers: 4 Read on SO: [24] http://goo.gl/QehSC * Is there a theory that combines category theory/abstract algebra and computational complexity? votes: 7, answers: 1 Read on SO: [25] http://goo.gl/CeAFw * Haskell Polymorphic Tree Sum votes: 7, answers: 1 Read on SO: [26] http://goo.gl/NqYQW * reasonably efficient pure-functional matrix product in Haskell? votes: 7, answers: 3 Read on SO: [27] http://goo.gl/8H6o9 * Is access to internal strucutre of a monad required for monad transformer? votes: 7, answers: 1 Read on SO: [28] http://goo.gl/Yln18 * Haskell sub-typeclass requires UndecidableInstances? votes: 6, answers: 2 Read on SO: [29] http://goo.gl/u9FQh * Haskell Data.List.Class and syntax votes: 6, answers: 1 Read on SO: [30] http://goo.gl/wvKEk Until next time, Daniel Santa Cruz References 1. http://hackage.haskell.org/trac/ghc/blog/newcg-update 2. http://www.reddit.com/r/haskell/comments/xmfes/update_on_ghcs_new_code_generator/ 3. http://www.youtube.com/watch?v=ScS8Q32lMxA 4. http://www.reddit.com/r/haskell/comments/xfcmk/the_first_video_in_my_new_series_of_free_haskell/ 5. https://github.com/k0ral/hbro 6. http://www.reddit.com/r/haskell/comments/xe0w3/hbro_haskell_based_browser_ideologically_similar/ 7. http://pragprog.com/magazines/2012-08/thinking-functionally-with-haskell 8. http://www.reddit.com/r/haskell/comments/xmip7/thinking_functionally_with_haskell_pragprog/ 9. http://blog.ezyang.com/2012/08/statically-checked-perfect-binary-trees/ 10. http://www.reddit.com/r/haskell/comments/xov6n/two_ways_of_representing_perfect_binary_trees/ 11. http://www.reddit.com/r/haskell/comments/xijsb/hoogle_from_the_command_line/ 12. http://www.reddit.com/r/haskell/comments/xijsb/hoogle_from_the_command_line/ 13. http://www.haskellforall.com/2012/07/free-monad-transformers.html 14. http://www.reddit.com/r/haskell/comments/xg75g/free_monad_transformers/ 15. http://www.reddit.com/r/haskell/comments/xlb1g/if_someone_asked_you_why_haskell_what_would_you/ 16.
Re: [Haskell-cafe] parsec: parserFail multiple error messages
Inserting a character into the stream can be expensive if for example the stream is a ByteString. I tried the following crazy solution and it seems that it works: succeed :: Parser () succeed = mkPT $ \st - return $ Consumed $ return $ Ok () st $ unknownError st succeed is a parser that always succeeds without really consuming any input but it also resets the error state. I really have no understating of how mkPT works. Can someone tell me if this is a bad idea? On Wed, Aug 8, 2012 at 4:09 PM, Nick Vanderweit nick.vanderw...@gmail.com wrote: I found a similar question asked in June 2009 on the haskell-beginners archives, titled Clearing Parsec error messages. A hack that was proposed (http://www.haskell.org/pipermail/beginners/2009-June/001809.html) was to insert a dummy character into the stream, consume it, and then fail. Still, I'd like to see if there is a cleaner way to modify the error state in the Parsec monad. NIck On Wednesday, August 08, 2012 03:24:31 PM silly wrote: I am trying to create a parsec parser that parses an integer and then checks if that integer has the right size. If not, it generates an error. I tried the following: 8--- import Text.Parsec import Text.Parsec.String integer :: Parser Int integer = do s - many1 digit let n = read s if n 65535 then parserFail integer overflow else return n 8--- The problem is that when I try this parse integer 7 I get the following error: Left (line 1, column 6): unexpected end of input expecting digit integer overflow ie there are three error messages but I only want the last one. Is there something I can do about this? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 3 level hierarchy of Haskell objects
On Wed, 8 Aug 2012, Ertugrul S??ylemez e...@ertes.de wrote: Patrick Browne patrick.bro...@dit.ie wrote: Gast [1] describes a 3 level hierarchy of Haskell objects using elementOf from set theory: value?? *elementOf*?? type?? *elementOf*?? class This hierarchy is pretty arbitrary and quickly runs into problems with some type system extensions. You can find out whether the barber of Seville shaves himself. A better hierarchial model is related to universes and uses type relations (assuming a right-associative ':'): value : type : kind : sort : ... value : type : universe 0 : universe 1 : universe 2 : ... A value is of a type. A type is of the first universe (kind). An n-th universe is of the (n+1)-th universe. Type classes can be modelled as implicit arguments. If we include super-classes would the following be an appropriate mathematical representation? What is a superclass? What are the semantics? Greets, Ertugrul I know no Haskell, so my first reactions are likely to fail to grip. There is a type theory from one generation, or perhaps two or three, before our time's New Crazed Type Theory. This is the type theory of the Lower Predicate Calculus and of Universal Algebra, style of Birkhoff's Theorem on Varieties. An introduction to this type theory is presented here: http://en.wikipedia.org/wiki/Signature_%28logic%29 [page was last modified on 27 March 2011 at 16:54] Haskell's type classes look to me to be a provision for declaring a signature in the sense of the above article. An instance of type t which belongs to a type class tc is guaranteed to have certain attendant structures, just as the underlying set of a group is automatically equipped with attendant, indeed defining, operations of 1, *, and ^-1. 1 is a zeroary operation with codomain the set of group elements, * is a binary operation that is, has type g x g - g, and ^-1 has type g - g, where g is the type of group elements of our particular group. That this particular group is indeed an instance of the general concept group requires that t be of a type class which guarantees the attendant three group operations 1, *, and ^-1, with types as shown. Note that the usual definition of group has further requirements. These further requirements are called associativity of *, 1 is an identity for *, and ^-1 is an inverse for *. I think that in Haskell today these requirements must, in many cases, be handled by the programmer by hand, and are not automatically handled by the type system of Haskell. Though, as pointed out in an earlier post, in some cases one can use certain constructions, constructions convenient in Haskell, to guarantee that operations so defined meet the requirements. Here we are close to the distinction between a class of objects which satisfy a condition vs objects with added structure, for which see: http://math.ucr.edu/home/baez/qg-spring2004/discussion.html http://ncatlab.org/nlab/show/stuff,+structure,+property oo--JS. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] parsec: parserFail multiple error messages
On Wed, Aug 8, 2012 at 8:26 PM, silly silly8...@gmail.com wrote: Inserting a character into the stream can be expensive if for example the stream is a ByteString. I tried the following crazy solution and it seems that it works: succeed :: Parser () succeed = mkPT $ \st - return $ Consumed $ return $ Ok () st $ unknownError st succeed is a parser that always succeeds without really consuming any input but it also resets the error state. Because you're using the 'Consumed' constructor, you're also telling parsec not the back-track if there any errors following this parsers. This means that 'succeed failingParser' won't backtrack, even if 'failingParser' doesn't consume input. Are you using your original parser within a larger parser? Are the error messages also not great? Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] mutable arrays of tuples
So I was thinking about a mutable array of tuples, but to avoid allocating tuples to modify their fields, I guess I really want an immutable array of tuples of STRefs. Just how much less efficient is this than a plain mutable array? might it even make sense to use parallel mutable arrays? The thought of that is disgusting to me, but at least one of the arrays could likely be made unboxed... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
