Re: [Haskell-cafe] Why superclass' instances are bad idea?

Thanks a lot! This makes clear. I haven't noticed before that OverlappingInstances don't look at constraint! John Lato-2 wrote > This line > > instance Monad m => Applicative m where > > tells the compiler "Every type (of the appropriate kind) is an instance of > Applicative. And it needs

Re: [Haskell-cafe] Why superclass' instances are bad idea?

This line instance Monad m => Applicative m where tells the compiler "Every type (of the appropriate kind) is an instance of Applicative. And it needs to have a Monad instance as well." That's what Edward means when he said that it means "every Applicative is a Monad". Theoretically the st

[Haskell-cafe] Why superclass' instances are bad idea?

I suggest to add superclass' instances into libraries. http://ghc.haskell.org/trac/ghc/ticket/8348 In brief, we could write next: >{-# LANGUAGE FlexibleInstances #-} >{-# LANGUAGE UndecidableInstances #-} > >instance Monad m => Applicative m where >pure = return >(<*>) = ap > >i

Re: [Haskell-cafe] Why are field selectors functions?

Wouldn't the implementation hiding feature of the *newtype *idiom be broken, if field selectors were not first class functions? For instance, the following code (taken shamelessly from Ch. 10 of *Real World Haskell*): module Parse ( runParser ) where data ParseState = ParseState { string

Re: [Haskell-cafe] Why are field selectors functions?

AntC writes: > No! This isn't more bikeshedding about notation. > > It's a bit of Haskell archaeology. > >> On Sun, Jun 30, 2013 at 2:59 AM, Judah Jacobson wrote: > [This isn't exactly what Judah wrote.] >> ... >> >> Instead of `x f` (to access field x of record f), >> maybe we could write `f{x}`

Re: [Haskell-cafe] Why GHC is written in Happy and not a monadic parser library?

* Malcolm Wallace [2013-08-04 09:33:22+0100] > > On 3 Aug 2013, at 21:03, Jason Dagit wrote: > > > Another con of using parsec that I forgot to mention in my previous > > email is that with Parsec you need to be explicit about backtracking > > (use of try). Reasoning about the correct places to

Re: [Haskell-cafe] Why GHC is written in Happy and not a monadic parser library?

On 3 Aug 2013, at 21:03, Jason Dagit wrote: > Another con of using parsec that I forgot to mention in my previous > email is that with Parsec you need to be explicit about backtracking > (use of try). Reasoning about the correct places to put try is not > always easy and parsec doesn't help you w

Re: [Haskell-cafe] Why GHC is written in Happy and not a monadic parser library?

On Sat, Aug 3, 2013 at 3:36 AM, Malcolm Wallace wrote: > > On 3 Aug 2013, at 02:20, Jason Dagit wrote: > >>> Hi! >>> Is there any specific reason why GHC is written in a parser GENERATOR >>> (Happy) and not in MONADIC PARSER COMBINATOR (like parsec)? >>> >>> Is Happy faster / handles better errors

Re: [Haskell-cafe] Why GHC is written in Happy and not a monadic parser library?

On 3 Aug 2013, at 02:20, Jason Dagit wrote: >> Hi! >> Is there any specific reason why GHC is written in a parser GENERATOR >> (Happy) and not in MONADIC PARSER COMBINATOR (like parsec)? >> >> Is Happy faster / handles better errors / hase some great features or >> anything else? > > One reason

Re: [Haskell-cafe] Why GHC is written in Happy and not a monadic parser library?

On Fri, Aug 2, 2013 at 5:49 PM, blackbox.dev.ml wrote: > Hi! > Is there any specific reason why GHC is written in a parser GENERATOR > (Happy) and not in MONADIC PARSER COMBINATOR (like parsec)? > > Is Happy faster / handles better errors / hase some great features or > anything else? One reason

Re: [Haskell-cafe] Why GHC is written in Happy and not a monadic parser library?

On Fri, Aug 2, 2013 at 8:49 PM, blackbox.dev.ml wrote: > Is there any specific reason why GHC is written in a parser GENERATOR > (Happy) and not in MONADIC PARSER COMBINATOR (like parsec)? > > Is Happy faster / handles better errors / hase some great features or > anything else? > Most probably b

[Haskell-cafe] Why GHC is written in Happy and not a monadic parser library?

Hi! Is there any specific reason why GHC is written in a parser GENERATOR (Happy) and not in MONADIC PARSER COMBINATOR (like parsec)? Is Happy faster / handles better errors / hase some great features or anything else? thank you :) ___ Haskell-Cafe mail

[Haskell-cafe] Why are field selectors functions? [was: ghc-users A possible alternative to dot notation for record access]

No! This isn't more bikeshedding about notation. It's a bit of Haskell archaeology. > On Sun, Jun 30, 2013 at 2:59 AM, Judah Jacobson wrote: [This isn't exactly what Judah wrote.] > ... > > Instead of `x f` (to access field x of record f), > maybe we could write `f{x}` as the record selection.

Re: [Haskell-cafe] Why isn't ArrowChoice a parent of of ArrowApply?

On Thu, Jun 20, 2013 at 09:02:48AM +0200, Petr Pudlák wrote: > In Control.Arrow we have: > > leftApp :: ArrowApply a => a b c -> a (Either b d) (Either c d) > > Any instance of ArrowApply can be made into an instance of ArrowChoice by > defining left = leftApp. > > So why isn't Arrow

[Haskell-cafe] Why isn't ArrowChoice a parent of of ArrowApply?

In Control.Arrow we have: |leftApp ::ArrowApply a => a b c -> a (Either b d) (Either c d)| Any instance of |ArrowApply| can be made into an instance of |ArrowChoice| by defining |left = leftApp|. So why isn't |ArrowChoice| a parent of |ArrowApply|? Best regards, Petr

Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?

I agree that preprocessing code shouldn't be hsc2hs specific. I prefer c2hs myself. But hsc2hs is distributed with ghc, which makes it as official as a good many other parts of "modern Haskell". I also agree that making cabal-ghci work nicely would be ideal, but I don't think it can be done with

Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?

While hsc2hs is a popular FFI preprocessor, it is not the only one. There is also greencard and a few others. While hsc2hs can usually get the job done -- it's not clear that it is really the best choice. I think the Haskell FFI got to the point that it was 'just good enough' and then people lost

Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?

On Wed, Jun 5, 2013 at 3:56 PM, Roman Cheplyaka wrote: > * Ivan Lazar Miljenovic [2013-06-05 > 17:47:40+1000] > > On 5 June 2013 17:34, Roman Cheplyaka wrote: > > > * Jason Dagit [2013-06-04 21:00:25-0700] > > >> > My preferred solution would be to have ghc/ghci automatically run > hsc2hs > >

Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?

Hi, Roman Cheplyaka wrote: My preferred solution would be to have ghc/ghci automatically run hsc2hs [...] when necessary. How about having a `ghci` command for cabal? I don't think cabal can provide that. Let's say you're inside a 'cabal ghci' session. If you modify the hsc file and reload i

Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?

* Ivan Lazar Miljenovic [2013-06-05 17:47:40+1000] > On 5 June 2013 17:34, Roman Cheplyaka wrote: > > * Jason Dagit [2013-06-04 21:00:25-0700] > >> > My preferred solution would be to have ghc/ghci automatically run hsc2hs > >> > (support c2hs also?) when necessary. But so long as it's handled

Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?

On 5 June 2013 17:34, Roman Cheplyaka wrote: > * Jason Dagit [2013-06-04 21:00:25-0700] >> > My preferred solution would be to have ghc/ghci automatically run hsc2hs >> > (support c2hs also?) when necessary. But so long as it's handled >> > automatically, I wouldn't be particularly bothered by t

Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?

* Jason Dagit [2013-06-04 21:00:25-0700] > > My preferred solution would be to have ghc/ghci automatically run hsc2hs > > (support c2hs also?) when necessary. But so long as it's handled > > automatically, I wouldn't be particularly bothered by the implementation. > > How about having a `ghci` c

Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?

cabal-dev ghci does work with hsc2hs, but only because it doesn't interpret your source. Rather, cabal-dev ghci loads ghci using the sandbox install of your package, which is less useful for a variety of reasons. Aside from that detail, I wouldn't gain any benefit from having this feature built i

Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?

On Tue, Jun 4, 2013 at 8:45 PM, John Lato wrote: > On Wed, Jun 5, 2013 at 10:15 AM, Ivan Lazar Miljenovic > wrote: >> >> On 5 June 2013 12:02, silly wrote: >> > I was wondering today, why hasn't hsc2hs been merged with ghc so that >> > it would be possible to add a >> > >> > {-# LANGUAGE For

Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?

On Wed, Jun 5, 2013 at 10:15 AM, Ivan Lazar Miljenovic < ivan.miljeno...@gmail.com> wrote: > On 5 June 2013 12:02, silly wrote: > > I was wondering today, why hasn't hsc2hs been merged with ghc so that > > it would be possible to add a > > > > {-# LANGUAGE ForeignFunctionInterface #-} > > > >

Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?

On Tue, Jun 4, 2013 at 10:15 PM, Ivan Lazar Miljenovic wrote: > > Isn't this done automatically when you have files with the .hsc extension? > No, it is not. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo

Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?

On 5 June 2013 12:02, silly wrote: > I was wondering today, why hasn't hsc2hs been merged with ghc so that > it would be possible to add a > > {-# LANGUAGE ForeignFunctionInterface #-} > > at the top of a source file and then load it with ghci or compile it, > without the intermediate step of

[Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?

I was wondering today, why hasn't hsc2hs been merged with ghc so that it would be possible to add a {-# LANGUAGE ForeignFunctionInterface #-} at the top of a source file and then load it with ghci or compile it, without the intermediate step of calling hsc2hs? This would be exactly like the CPP e

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

On Sun, Apr 28, 2013 at 10:55 AM, gs wrote: > Alexander Solla gmail.com> writes: > > > I do not support that criterion. We use theory to ENSURE that no > real-world code will break. > > By theoretical example, I meant something which you would never expect to > find in use. Perhaps it was a poo

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

Alexander Solla gmail.com> writes: > I do not support that criterion.  We use theory to ENSURE that no real-world code will break. By theoretical example, I meant something which you would never expect to find in use. Perhaps it was a poor choice of wording in an academically orientated forum :-

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

On Sun, Apr 28, 2013 at 10:29 AM, gs wrote: > Brandon Allbery gmail.com> writes: > > > ... which means that implementers should be free to "fix" data type > contexts > > however they like, as they are now complier extensions which won't > conflict > > with standard Haskell. > > > > Except that p

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

Brandon Allbery gmail.com> writes: > ... which means that implementers should be free to "fix" data type contexts > however they like, as they are now complier extensions which won't conflict > with standard Haskell. > > Except that people do build older programs with newer Haskell compilers, an

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

On Sun, Apr 28, 2013 at 3:59 AM, harry wrote: > Dan Doel gmail.com> writes: > > > However, another thing to consider is that getting rid of data type > contexts was accepted into the language standard. > > ... which means that implementers should be free to "fix" data type > contexts > however t

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

Dan Doel gmail.com> writes: > However, another thing to consider is that getting rid of data type contexts was accepted into the language standard. ... which means that implementers should be free to "fix" data type contexts however they like, as they are now complier extensions which won't conf

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

That is because every other language conflates the notion of a class with a vtable smashed into every inhabitant of the class where everything has to be defined together in one monolithic definition. You also can't write sensible Monads in those languages (Where does return go?) or retroactively d

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

Dan Doel wrote: I don't really think they're worth saving in general, though. I haven't missed them, at least. Maybe you haven't :-) My code is cluttered with redundant type contexts - I can't think of a similar redundancy in any other language. __

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

2013-04-26 04:31, wren ng thornton skrev: On 4/25/13 9:49 PM, Dan Doel wrote: I don't really think they're worth saving in general, though. I haven't missed them, at least. The thing I've missed them for (and what I believe they were originally designed for) is adding constraints to derived in

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

On 4/25/13 9:49 PM, Dan Doel wrote: > I don't really think they're worth saving in general, though. I haven't > missed them, at least. The thing I've missed them for (and what I believe they were originally designed for) is adding constraints to derived instances. That is, if I have: data Bar

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

I can't think of any at the moment that are still in force. However, one that might have been relevant at the time is: data C a => Foo a = Foo a a foo :: Foo a -> (a, a) foo ~(Foo x y) = (x, y) Irrefutable matches used to be disallowed for GADT-like things, which would break the abov

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

Good point, again. Is that the only problem with it? On Thu, Apr 25, 2013 at 5:57 PM, Dan Doel wrote: > It is not completely backwards compatible, because (for instance) the > declaration: > > newtype C a => Foo a = Foo a > > was allowed, but: > > newtype Foo a where > Foo :: C a =

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

It is not completely backwards compatible, because (for instance) the declaration: newtype C a => Foo a = Foo a was allowed, but: newtype Foo a where Foo :: C a => a -> Foo a is an illegal definition. It can only be translated to a non-newtype data declaration, which changes the s

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

Brandon Allbery gmail.com> writes: > As I understand it, it's because fixing them involves passing around a dictionary along with the data, and you can't do that with a standard declaration (it amounts to an extra chunk of data that's only *sometimes* wanted, and that "sometimes" complicates thin

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

I've wondered this too. What would have been wrong with a simple source-to-source translation, where a constraint on the datatype itself translates to the same constraint on each of its constructors? Perhaps it would be unintuitive that you would have to pattern match before gaining access to the c

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

On Thu, Apr 25, 2013 at 6:38 AM, harry wrote: > If I understand correctly, the problem with datatype contexts is that if we > have e.g. > data Eq a => Foo a = Foo a > the constraint Eq a is thrown away after a Foo is constructed, and any > method using Foos must repeat Eq a in its type signatur

[Haskell-cafe] Why the `-ghc7.4.2' suffix on *.SO base names?

In trying to compile a 2 year old, previously working project on a new machine with a fresh Haskell Platform installation, I bumped into this: ghc -o libami.so -shared -package parsec -lHSrts -lm -lffi -lrt AMIParse.o AMIModel.o ami_model.o ExmplUsrModel.o Filter.o /usr/bin/ld: /usr/lib/ghc-7.4.2/

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

Kim-Ee Yeoh atamo.com> writes: > data Foo a where >   Foo :: Eq a => a -> Foo a > > is equivalent to > > data Foo a = Eq a => Foo a > > but is different from > > data Eq a => Foo a = Foo a ... and nothing in GADTs does what one would naively expect the last declaration to do. _

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

On Thu, Apr 25, 2013 at 6:36 PM, Joe Quinn wrote: > data Foo a where > Foo :: Eq a => a -> Foo a > is equivalent to data Foo a = Eq a => Foo a but is different from data Eq a => Foo a = Foo a (Yup, tripped up a few of us already!) -- Kim-Ee ___ H

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

From what I have heard, they are completely subsumed by GADTs, which is a stable enough extension that it was considered unimportant to save. Your Foo would be something like this: data Foo a where Foo :: Eq a => a -> Foo a On 4/25/2013 6:38 AM, harry wrote: If I understand correctly, the

[Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?

If I understand correctly, the problem with datatype contexts is that if we have e.g. data Eq a => Foo a = Foo a the constraint Eq a is thrown away after a Foo is constructed, and any method using Foos must repeat Eq a in its type signature. Why were these contexts removed from the language, ins

[Haskell-cafe] Why are QuasiQuotes allowed in SafeHaskell?

In GHC User's Guide, the reason to disable TemplateHaskell is as follows: > TemplateHaskell — Is particularly dangerous, as it can cause side > effects even at compilation time and can be used to access > constructors of abstract data types. Doesn't the same apply to quasi-quotes? __

Re: [Haskell-cafe] Why is "Cont" out of scope?

On Tue, Apr 2, 2013 at 8:37 PM, Daryoush Mehrtash wrote: > I am trying to use the Cont in Control.Monad.Cont but it seems to be > missing > > Prelude> import Control.Monad.Cont > Prelude Control.Monad.Cont> :t Cont > > It's gone; try "cont" (lowercase). mtl2 replaced the old standalone monads wit

[Haskell-cafe] Why is "Cont" out of scope?

I am trying to use the Cont in Control.Monad.Cont but it seems to be missing Prelude> import Control.Monad.Cont Prelude Control.Monad.Cont> :t Cont :1:1: Not in scope: data constructor `Cont' Perhaps you meant `ContT' (imported from Control.Monad.Cont) Prelude Control.Monad.Cont> :t runCo

Re: [Haskell-cafe] Why isn't "Program Derivation" a first class citizen?

Hi, Am Dienstag, den 12.02.2013, 17:47 -0500 schrieb Nehal Patel: > To me, it seems that something like this should be possible -- am i > being naive? does it already exist? have people tried and given up? > is it just around the corner? can you help me make sense of all of > this? a related pr

Re: [Haskell-cafe] Why isn't "Program Derivation" a first class citizen?

Rustom Mody writes: > On Wed, Feb 13, 2013 at 4:17 AM, Nehal Patel wrote: >> >> Why isn't "Program Derivation" a first class citizen? >> --- > I am stating these things from somewhat foggy memory (dont have any > lambda-calculus texts handy) and so will welcome corrections from those who >

Re: [Haskell-cafe] Why isn't "Program Derivation" a first class citizen?

On Wed, Feb 13, 2013 at 4:17 AM, Nehal Patel wrote: > A few months ago I took the Haskell plunge, and all goes well... -- but I > really want to understand the paradigms as fully as possible, and as it > stands, I find myself with three or four questions for which I've yet to > find suitable answ

Re: [Haskell-cafe] Why isn't "Program Derivation" a first class citizen?

On Tue, Feb 12, 2013 at 4:47 PM, Nehal Patel wrote: > > A few months ago I took the Haskell plunge, and all goes well... > ... snip ... > And so my question is, that in 2013, why isn't this process a full fledged > part of the language? I imagine I just don't know what I'm talking about, so > co

Re: [Haskell-cafe] Why isn't "Program Derivation" a first class citizen?

On 2/12/13 5:47 PM, Nehal Patel wrote: And so my question is, that in 2013, why isn't this process a full fledged part of the language? I imagine I just don't know what I'm talking about, so correct me if I'm wrong, but this is how I understand the workflow used in practice with program deriva

Re: [Haskell-cafe] Why isn't "Program Derivation" a first class citizen?

> To me, it seems that something like this should be possible -- am i being > naive? does it already exist? During the compilation process GHC optimizes the code by performing successive transformations of the program. These transformations are known to preserve meaning of the program - they a

[Haskell-cafe] Why isn't "Program Derivation" a first class citizen?

A few months ago I took the Haskell plunge, and all goes well... -- but I really want to understand the paradigms as fully as possible, and as it stands, I find myself with three or four questions for which I've yet to find suitable answers. I've picked one to ask the cafe -- like my other ques

Re: [Haskell-cafe] why GHC cannot infer type in this case?

That is great! I worked through the paper and played a lot with your code - I must admit that I like this approach much more. I even added to my DSL user-defined types in a type safe way, that I could not do with original GADT-based design. Thank you! Dmitry On Fri, Feb 1, 2013 at 12:09 PM, wro

Re: [Haskell-cafe] Why does not zipWith' exist

> Right, I'm not arguing that it's impossible to produce a difference, > but I think that if you're defining the sequence of fibs, the most > likely scenario might be that you're actually interested in a prefix, > and more importantly, you can still, from the outside, force the > prefix even if you

Re: [Haskell-cafe] Why does not zipWith' exist

Hi, > zipWith' would [I haven't tested, but I'm rather confident] make a difference > if > you benchmarked > > bench "name" (whnf (fibs !!) 10) > > etc. Yes. fibs is slow if used with "!!". --Kazu ___ Haskell-Cafe mailing list Haskell-Cafe

Re: [Haskell-cafe] Why does not zipWith' exist

I recently asked a similar question about strict scans (e.g. scanl') and got the same response to use a strictify function. Although I would argue that fun' is syntactically more convenient than (strictList . fun), I'd agree that composition is good. Maybe it would make sense to add to have tha

Re: [Haskell-cafe] Why does not zipWith' exist

On Friday 01 February 2013, 13:43:59, Andres Löh wrote: > > Right, I'm not arguing that it's impossible to produce a difference, > but I think that if you're defining the sequence of fibs, the most > likely scenario might be that you're actually interested in a prefix, Right. If you only want one

Re: [Haskell-cafe] Why does not zipWith' exist

> Well, it took a little bit of persuasion to let GHC not cache the list(s), but > with > > > fibs :: Int -> Integer > fibs k = igo i !! k > where > i | k < 100 = 1 > | otherwise = 2 > igo :: Integer -> [Integer] > igo i = let go = 0 : i : zipWith (+) go (tail go) in go >

Re: [Haskell-cafe] Why does not zipWith' exist

On Friday 01 February 2013, 13:06:09, Daniel Fischer wrote: > > zipWith' would [I haven't tested, but I'm rather confident] make a > difference if you benchmarked > > bench "name" (whnf (fibs !!) 10) > > etc. Well, it took a little bit of persuasion to let GHC not cache the list(s), but

Re: [Haskell-cafe] Why does not zipWith' exist

On Friday 01 February 2013, 12:50:18, Andres Löh wrote: > Hi Kazu. > > I'd be surprised if zipWith' yields significant improvements. In the > case of foldl', the strictness affects an internal value (the > accumulator). However, in the case of zipWith', you're just forcing > the result a bit more,

Re: [Haskell-cafe] Why does not zipWith' exist

Hi Kazu. I'd be surprised if zipWith' yields significant improvements. In the case of foldl', the strictness affects an internal value (the accumulator). However, in the case of zipWith', you're just forcing the result a bit more, but I guess the "normal" use pattern of fibs is that you want to se

[Haskell-cafe] why GHC cannot infer type in this case?

Dmitry Kulagin wrote: > I try to implement little typed DSL with functions, but there is a problem: > compiler is unable to infer type for my "functions". One way to avoid the problem is to start with the tagless final representation. It imposes fewer requirements on the type system, and is a qu

[Haskell-cafe] Why does not zipWith' exist

Hello, Many texts explain the following Fibonacci code: fibs :: [Integer] fibs = 0 : 1 : zipWith (+) fibs (tail fibs) But this code is very slow because evaluation of (+) is done lazily. If we have the following strict zipWith', the code above becomes much faster. zipWith' f (a:as) (b:bs) = x `

Re: [Haskell-cafe] why GHC cannot infer type in this case?

Andres, thank you! Your response is really helpful. I will try to adopt your suggestion. Thank again! Dmitry On Thu, Jan 31, 2013 at 7:27 PM, Andres Löh wrote: > Hi Dmitry. > > > I try to implement little typed DSL with functions, but there is a > problem: > > compiler is unable to infer type

Re: [Haskell-cafe] why GHC cannot infer type in this case?

Hi Dmitry. > I try to implement little typed DSL with functions, but there is a problem: > compiler is unable to infer type for my "functions". It seems that context > is clear, but still GHC complains "Could not deduce...". > It is sad because without type inference the DSL will be very difficult

[Haskell-cafe] why GHC cannot infer type in this case?

Hi Cafe, I try to implement little typed DSL with functions, but there is a problem: compiler is unable to infer type for my "functions". It seems that context is clear, but still GHC complains "Could not deduce...". It is sad because without type inference the DSL will be very difficult to use. C

Re: [Haskell-cafe] why no replace function in our regular expression libs ?

On 13-01-25 02:06 PM, Simon Michael wrote: People have put a lot of work into regular expression libraries on haskell. Yet it seems very few of them provide a replace/substitute function - just regex-compat and regepr as far as I know. Why is that ? [...] Secondly, as of today what do y'all do

Re: [Haskell-cafe] why no replace function in our regular expression libs ?

I've needed this recently, too. End result: I wrote an "Attoparsec.Parser Text", and ran the text through that. A regex would have been much nicer... - Clark On Fri, Jan 25, 2013 at 2:06 PM, Simon Michael wrote: > People have put a lot of work into regular expression libraries on > haskell

[Haskell-cafe] why no replace function in our regular expression libs ?

People have put a lot of work into regular expression libraries on haskell. Yet it seems very few of them provide a replace/substitute function - just regex-compat and regepr as far as I know. Why is that ? #haskell says: iirc its because that's a really mutatey operation in the underlying c libs

Re: [Haskell-cafe] Why should we write "a `par` b `pseq` (f a b)" instead of "a `par` b `par` (f a b)"?

Petr P gmail.com> writes: > Is there any reason to use >   a `par` b `pseq` (a + b) > instead of >   a `par` b `par` (a + b) (better ask this on parallel-haskell?) > It seems to me that the second variant would work as well: > The main thread would block on one of the sparked computations, I

[Haskell-cafe] Why should we write "a `par` b `pseq` (f a b)" instead of "a `par` b `par` (f a b)"?

Dear Haskellers, I've been playing with par and pseq, and I wonder: Is there any reason to use a `par` b `pseq` (a + b) instead of a `par` b `par` (a + b) except that the second version sparks twice instead of just once (which probably degrades performance a bit)? It seems to me that the sec

Re: [Haskell-cafe] Why is boxed mutable array so slow?

Wow, now performance is on par with Java ;)So slow division was main problem, that and GC . Thanks! > From: daniel.is.fisc...@googlemail.com > To: haskell-cafe@haskell.org > CC: bm...@hotmail.com > Subject: Re: [Haskell-cafe] Why is boxed mutable array so slow? > Date: Sat, 1 De

Re: [Haskell-cafe] Why is boxed mutable array so slow?

On Samstag, 1. Dezember 2012, 16:09:05, Branimir Maksimovic wrote: > All in all even unboxed array is about 10 times slower than Java version. > I don't understand why is even unboxed array so slow. It's not the unboxed arrays that are slow. Your code has a couple of weak spots, and GHC's native

Re: [Haskell-cafe] Why is boxed mutable array so slow?

Thanks! I have downloaded tool and playing with it.I will use boxed vectors in the future ;) > Date: Sat, 1 Dec 2012 13:22:47 -0500 > Subject: Re: [Haskell-cafe] Why is boxed mutable array so slow? > From: don...@gmail.com > To: bm...@hotmail.com > CC: haskell-cafe@haskell.org

Re: [Haskell-cafe] Why is boxed mutable array so slow?

Regarding when to use mutable arrays versus vectors, I would always use vectors -- they optimize better, and have a better interface. Also, I have updated and released a new version of the tool mentioned below. You can get it on Hackage, updated to ghc 7 series. http://hackage.haskell.org/pac

Re: [Haskell-cafe] Why is boxed mutable array so slow?

262486571 seconds 0.908unboxed vectorlast 262486571 seconds 0.720 real0m3.805suser0m3.428ssys 0m0.372s > Date: Sat, 1 Dec 2012 12:20:37 -0500 > Subject: Re: [Haskell-cafe] Why is boxed mutable array so slow? > From: don...@gmail.com > To: bm...@hotmail.com > CC: haskell-c

Re: [Haskell-cafe] Why is boxed mutable array so slow?

The obvious difference between boxed and unboxed arrays is that the boxed arrays are full of pointers to heap allocated objects. This means you pay indirection to access the values, much more time in GC spent chasing pointers (though card marking helps), and generally do more allocation. Compare t

Re: [Haskell-cafe] Why is boxed mutable array so slow?

Boxed arrays have a wrapper (extra layer of indirection) to allow for a fully evaluated value, an unevaluated thunk, or the special value bottom (a value that can contain bottom is referred to as lifted). Unboxed arrays always have some value; that is, they cannot represent a thunk nor bottom. O

[Haskell-cafe] Why is boxed mutable array so slow?

I have made benchmark test inspired by http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/ What surprised me is that unboxed array is much faster than boxed array.Actually boxed array performance is on par with standard Haskell listwhich is very slow.All in all even unboxed array is about

Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?

Ben, > Now, on to Bind: the standard finite structure example for Bind is most probably the substitution thingy ... Danger of conflating a bunch of things here: (1) the substitution monadic effect is always also applicative and always also unital/pointed because monads are always applicative and

Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?

Gershom Bazerman wrote: > On 11/30/12 10:44 AM, Dan Doel wrote: >> >> Lists! The finite kind. >> >> This could mean Seq for instance. >> >> On Nov 30, 2012 9:53 AM, "Brent Yorgey" > > wrote: >> >> >> Any data type which admits structures of arbitrary but *only fin

Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?

On 11/30/12 10:44 AM, Dan Doel wrote: Lists! The finite kind. This could mean Seq for instance. On Nov 30, 2012 9:53 AM, "Brent Yorgey" > wrote: Any data type which admits structures of arbitrary but *only finite* size has a natural "zippy" Apply insta

Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?

Lists! The finite kind. This could mean Seq for instance. On Nov 30, 2012 9:53 AM, "Brent Yorgey" wrote: > On Fri, Nov 30, 2012 at 02:33:54AM +0100, Ben Franksen wrote: > > Brent Yorgey wrote: > > > On Thu, Nov 29, 2012 at 03:52:58AM +0100, Ben Franksen wrote: > > >> Tony Morris wrote: > > >> >

Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?

On Fri, Nov 30, 2012 at 02:33:54AM +0100, Ben Franksen wrote: > Brent Yorgey wrote: > > On Thu, Nov 29, 2012 at 03:52:58AM +0100, Ben Franksen wrote: > >> Tony Morris wrote: > >> > As a side note, I think a direct superclass of Functor for Monad is not > >> > a good idea, just sayin' > >> > > >> >

Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?

Brent Yorgey wrote: > On Thu, Nov 29, 2012 at 03:52:58AM +0100, Ben Franksen wrote: >> Tony Morris wrote: >> > As a side note, I think a direct superclass of Functor for Monad is not >> > a good idea, just sayin' >> > >> > class Functor f where >> > fmap :: (a -> b) -> f a -> f b >> > >> > clas

Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?

On Thu, Nov 29, 2012 at 03:52:58AM +0100, Ben Franksen wrote: > Tony Morris wrote: > > As a side note, I think a direct superclass of Functor for Monad is not > > a good idea, just sayin' > > > > class Functor f where > > fmap :: (a -> b) -> f a -> f b > > > > class Functor f => Apply f where >

Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?

Dan Doel wrote: > On Tue, Oct 16, 2012 at 10:37 AM, AUGER Cédric wrote: >> join IS the most important from the categorical point of view. >> In a way it is natural to define 'bind' from 'join', but in Haskell, it >> is not always possible (see the Monad/Functor problem). >> >> As I said, from the

Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?

Tony Morris wrote: > As a side note, I think a direct superclass of Functor for Monad is not > a good idea, just sayin' > > class Functor f where > fmap :: (a -> b) -> f a -> f b > > class Functor f => Apply f where > (<*>) :: f (a -> b) -> f a -> f b > > class Apply f => Bind f where > (=

Re: [Haskell-cafe] Why doesn't GHC optimize recursive functions by converting them into `let`?

Hi Carter, 2012/11/8 Carter Schonwald > I imagine that one issue that would make it not a default activity by GHC > is that this sort of strategy has the following implications: > > 1) ghc in general doesn't always want to inline in general, inlining > increases the size of code! and depend

Re: [Haskell-cafe] Why doesn't GHC optimize recursive functions by converting them into `let`?

Hey Petr, interesting post! (and links) I imagine that one issue that would make it not a default activity by GHC is that this sort of strategy has the following implications: 1) ghc in general doesn't always want to inline in general, inlining increases the size of code! and depending on how

[Haskell-cafe] Why doesn't GHC optimize recursive functions by converting them into `let`?

Hi, recently I found out that some recursive functions can be greatly optimized just by rewriting them using `let` so that they're not recursive themselves any more (only the inner let is). To give an example: > fix :: (a -> a) -> a > fix f = f (fix f) isn't optimized, because it's a recursive

Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?

The particular case from which the former is a generalization: *instance Monad m => Monoid (a -> a) where* *mappend = (.)* *mempty = id* * * Here the monoid is defined for the functions within the set of values of type a. There are no null elements. 2012/10/24 Alberto G. Corona > W

Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?

What hiders according with my experience, the understanding of this generalization are some mistakes. two typical mistakes from my side was to consider an arrow as a function, and the consideration of m as a kind of container, which it is not from the point of view of category theory. a -> m b

  1   2   3   4   5   6   7   8   9   10   >