Re: [Haskell-cafe] Can Haskell outperform C++?
On 17/05/2012, at 10:07 PM, Roman Werpachowski wrote: >> No slide deck required. The task is "generating alternating permutations". >> >> Method 1: generate permutations using a backtracking search; >> when a permutation is generated, check if it is alternating. >> >> Method 2: use the same backtracking search, but only allow extensions >> that preserve the property of being an alternating permutation. > > Gregg, > > what makes Method 2 so much harder than Method 1 to implement in C or C++? It was me, not Gregg. There was and is no claim that method 2 is "much harder to implement in C or C++". In fact both methods *were* implemented easily in C. The claim was and remains solely that THE TIME DIFFERENCE BETWEEN *ALGORITHMS* can be bigger than THE TIME DIFFERENCE BETWEEN *LANGUAGES* and is in this particular case. (And that's despite the fact that the C version kept the set of unused elements as a one-native-word bit mask, while the Prolog version kept it as a linked list.) There is also a second claim, which I thought was uncontentious: the relative difficulty of tasks varies with language. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cool tools
Indeed, cabal-install 0.14.0 has been *excellent* for me so far. Thanks Andres! On Thu, May 17, 2012 at 10:05 AM, Chris Dornan wrote: > I have been playing around with the latest cabal-install (0.14.0) and it is > working really nicely. Having unpacked a cabal bundle you can now type > 'cabal install' inside the root and it will work everything out as if you > had asked to install directly from the repo -- very nice. > > I have also noticed that GHC is suggesting alternatives when it encounters > missing identifiers. This gives a strong sense of helpfulness that I think > accurately reflects the long and sustained (decades-long) effort that has > gone into making the GHC diagnostics as useful as possible. > > The tools are so good because the developers have been paying attention to > the gripes. > > But we should sometimes say thank you too... it is much appreciated. > > Chris > > > ___ > 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] Safe Haskell at the export symbol granularity?
On 17 May 2012 23:50, Ryan Newton wrote: > Thanks David. > > I'm glad to see it was discussed in the wiki. (Btw, my 2 cents is that I > like the comment pragmas more than new keywords.) Sure, the proposed syntax wasn't a serious proposal as it has backwards compatibility issues so pragmas are the better choice. It's just a clearer syntax when discussing the semantics of the idea. > > The issue that I think doesn't make it into the wiki is of splitting, not > modules, but type-classes. That's where I think it becomes a more serious > issue. Thanks, I'll keep that in mind. Let me know how Antoine's suggestion works out for you and any other feedback you have please. > > Do you think a symbol-level Safe Haskell would be able to distinguish one > method of a type class as unsafe, while the others are safe? I think so. I'm not very familiar with the type checker in GHC or typechecking in general but looking through the code just then it seems doable. There doesn't seem anything other than maybe some hard engineering work that would prevent this. ~ David > > -Ryan > > P.S. In my two examples -- > There's only one "Acc" type and Accelerate's "fold" can pretty easily be > moved into an .Unsafe module, though it breaks the > one-giant-module-for-the-whole-programming-model thing it has going now. In > the Par example on the other hand type classes are used to abstract over > different implementations, so that's where we run into the safe/unsafe > factoring problem. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
Isaac, I understand. Thank you. I will be more careful about my wording in the future. I really do appreciate your taking the time to point this out to me. I am here to learn and help where I can. Gregg On 5/17/2012 11:25 AM, Isaac Gouy wrote: From: Gregg Lebovitz Sent: Thursday, May 17, 2012 5:50 AMI look forward to Subject: Re: [Haskell-cafe] Can Haskell outperform C++? Isaac, I see your point. Probably I shouldn't have made that assertion given my limited understanding of the benchmarks. I want to thank you for your kind and gentle way of pointing this out to me. I feel very welcomed and encourage. I still plan to work on the performance paper with the help of others on this list. I look forward to your support and constructive feedback. Gregg Gregg, You wrote that you were looking at the benchmarks and then made a definite assertion about what was shown on the website. Unsuspecting readers would assume that you were truthfully reporting what you saw on the website. I cannot explain to them why you made an assertion which could be seen not to be true, simply by looking at the benchmarks game website. best wishes, Isaac ___ 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] Can Haskell outperform C++?
> From: Gregg Lebovitz > Sent: Thursday, May 17, 2012 5:50 AMI look forward to > Subject: Re: [Haskell-cafe] Can Haskell outperform C++? > > Isaac, > > I see your point. Probably I shouldn't have made that assertion given my > limited understanding of the benchmarks. I want to thank you for your > kind and gentle way of pointing this out to me. I feel very welcomed and > encourage. > > I still plan to work on the performance paper with the help of others on > this list. I look forward to your support and constructive feedback. > > Gregg Gregg, You wrote that you were looking at the benchmarks and then made a definite assertion about what was shown on the website. Unsuspecting readers would assume that you were truthfully reporting what you saw on the website. I cannot explain to them why you made an assertion which could be seen not to be true, simply by looking at the benchmarks game website. best wishes, Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Safe Haskell at the export symbol granularity?
Good point, Antoine! I think that does the trick. On Thu, May 17, 2012 at 10:48 AM, Antoine Latter wrote: > On Thu, May 17, 2012 at 8:50 AM, Ryan Newton wrote: > > Thanks David. > > > > I'm glad to see it was discussed in the wiki. (Btw, my 2 cents is that I > > like the comment pragmas more than new keywords.) > > > > The issue that I think doesn't make it into the wiki is of splitting, not > > modules, but type-classes. That's where I think it becomes a more serious > > issue. > > > > Do you think a symbol-level Safe Haskell would be able to distinguish one > > method of a type class as unsafe, while the others are safe? > > > > You can still do this at the module level, with the down-side of > potentially not being able to implement a class with the safe version: > > > module Unsafe where > > > > class MyClass a where > > safeOp :: a -> Int -> IO () > > unsafeOp :: a -> Int -> IO () > > > > instance MyClass A where ... > > > > module Safe > > (MyClass(safeOp)) > > where > > > > import Unsafe > > I think this works. > > Antoine > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Safe Haskell at the export symbol granularity?
On Thu, May 17, 2012 at 8:50 AM, Ryan Newton wrote: > Thanks David. > > I'm glad to see it was discussed in the wiki. (Btw, my 2 cents is that I > like the comment pragmas more than new keywords.) > > The issue that I think doesn't make it into the wiki is of splitting, not > modules, but type-classes. That's where I think it becomes a more serious > issue. > > Do you think a symbol-level Safe Haskell would be able to distinguish one > method of a type class as unsafe, while the others are safe? > You can still do this at the module level, with the down-side of potentially not being able to implement a class with the safe version: > module Unsafe where > > class MyClass a where > safeOp :: a -> Int -> IO () > unsafeOp :: a -> Int -> IO () > > instance MyClass A where ... > module Safe > (MyClass(safeOp)) > where > > import Unsafe I think this works. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data Kinds and superfluous (in my opinion) constraints contexts
Hi, It is quite likely that the error that you are getting with approach 2 is because when you are constructing the `Combinator` value, there is not enough type information to figure out how to solve the constraint (and it sounds like this happens because there is not enough type information to reduce the type function). The fix depends on the concrete program but it might be something as simple as adding a type signature somewhere. Note, again, that it is not sufficient to know that the constraint could be solved for any type of the appropriate kind: we need to actually solve the constraint so that we can determine what the program should do. The difference between the two `data` definitions is that the second one uses a technique called _existential quantification_, which "hides" the type `s`. If this type appears nowhere else in the surrounding expressions and the constraint could not be solved, then the constraint is ambiguous. I could explain that in more detail, if it is unclear please ask. Happy hacking, -Iavor On Thu, May 17, 2012 at 4:18 AM, Serguey Zefirov wrote: > > I can write something like that: > > data Combinator s a where >Combinator :: Class (TypeFamExpr s) => ... -> Combinator s a > > And I cannot write something like that: > data Combinator a where >Combinator :: Class (TypeFamExpr s) => .mentions s.. -> Combinator a > > If my TypeFamExpr does have type variables, I get a wild type error > messages that mentions partially computed TypeFamExpr as an argument > to constraint. > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cool tools
I have been playing around with the latest cabal-install (0.14.0) and it is working really nicely. Having unpacked a cabal bundle you can now type 'cabal install' inside the root and it will work everything out as if you had asked to install directly from the repo -- very nice. I have also noticed that GHC is suggesting alternatives when it encounters missing identifiers. This gives a strong sense of helpfulness that I think accurately reflects the long and sustained (decades-long) effort that has gone into making the GHC diagnostics as useful as possible. The tools are so good because the developers have been paying attention to the gripes. But we should sometimes say thank you too... it is much appreciated. Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Safe Haskell at the export symbol granularity?
Thanks David. I'm glad to see it was discussed in the wiki. (Btw, my 2 cents is that I like the comment pragmas more than new keywords.) The issue that I think doesn't make it into the wiki is of splitting, not modules, but* type-classes*. That's where I think it becomes a more serious issue. Do you think a symbol-level Safe Haskell would be able to distinguish one method of a type class as unsafe, while the others are safe? -Ryan P.S. In my two examples -- There's only one "Acc" type and Accelerate's "fold" can pretty easily be moved into an .Unsafe module, though it breaks the one-giant-module-for-the-whole-programming-model thing it has going now. In the Par example on the other hand type classes are used to abstract over different implementations, so that's where we run into the safe/unsafe factoring problem. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
Isaac, I see your point. Probably I shouldn't have made that assertion given my limited understanding of the benchmarks. I want to thank you for your kind and gentle way of pointing this out to me. I feel very welcomed and encourage. I still plan to work on the performance paper with the help of others on this list. I look forward to your support and constructive feedback. Gregg On 5/16/2012 6:59 PM, Isaac Gouy wrote: -snip- Interesting that you would focus on this one comment in my post and not comment on one on countering the benchmarks with a new criteria for comparing languages. Too obvious to be interesting. Interesting that you haven't said how you know they are "designed to favor imperative languages" ;-) ___ 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] Can Haskell outperform C++?
Roman, I think this question is for Richard. I haven't had a chance to play with these methods. I will try to do that today. Gregg On 5/17/2012 6:07 AM, Roman Werpachowski wrote: From: "Richard O'Keefe" Subject: Re: [Haskell-cafe] Can Haskell outperform C++? To: Haskell Cafe Message-ID:<5f6605a2-dfe0-4aea-9987-3b07def34...@cs.otago.ac.nz> Content-Type: text/plain; charset=us-ascii On 17/05/2012, at 2:04 PM, Gregg Lebovitz wrote: Richard, Thank you. This is an example of what I had in mind when I talked about changing the playing field. Do you have a slide deck for this lecture that you would be willing to share with me? I am very interested in learning more. No slide deck required. The task is "generating alternating permutations". Method 1: generate permutations using a backtracking search; when a permutation is generated, check if it is alternating. Method 2: use the same backtracking search, but only allow extensions that preserve the property of being an alternating permutation. Gregg, what makes Method 2 so much harder than Method 1 to implement in C or C++? Regards, RW ___ 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] AI - machine learning
Hi Miro! I have no useful information for you. Few weeks ago I also checked for any AI (machine learning first of all) related packages exist and found nothing satisfactory except for some quite small packages implementing a single algorithm (like NN-back-propagation). So there is a lot to do :) If you are going to do something in this area please let me know, I'll be glad to collaborate! p.s. Now I'm taking Machine Learning course at Coursera.org and looking forward to apply this knowledge with Haskell. On Tue, May 15, 2012 at 3:02 AM, miro wrote: > Hi All, recently I started to take a look at haskell, especially at AI. I > can see some email addresses of interested people there but not so much of > other activity behind. Does it exist some mailing group especially for AI? > > Basically I'm interested in trying some machine learning algorithms. Start > with reinforcement learning and value-based), and go towards AGI (Artificial > General Intelligence). Does anybody know about some already existing haskell > approaches, or is there anybody working on this? > > Cheers, > m. > > ___ > 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] Data Kinds and superfluous (in my opinion) constraints contexts
2012/5/17 Iavor Diatchki :
> Hello,
>
> The context in your example serves an important purpose: it records the fact
> that the behavior of the function may differ depending on which type it is
> instantiated with. This is quite different from ordinary polymorphic
> functions, such as `const` for example, which work in exactly the same way,
> no matter how you instantiate them. Note that it doesn't matter that we
> can solve the constraint for all types of kind `D`---the constraint is there
> because we can't solve it _uniformly_ for all types.
Oh, it was of great matter to me. Because constraints like that get
through type family expressions and make it hard to conceal state that
should satisfy constraints on type family expressions over the type of
the state.
I can write something like that:
data Combinator s a where
Combinator :: Class (TypeFamExpr s) => ... -> Combinator s a
And I cannot write something like that:
data Combinator a where
Combinator :: Class (TypeFamExpr s) => .mentions s.. -> Combinator a
If my TypeFamExpr does have type variables, I get a wild type error
messages that mentions partially computed TypeFamExpr as an argument
to constraint.
I can make more detailed example, if you wish.
>
> -Iavor
> PS: As an aside, these two forms of polymorphism are sometimes called
> "parametric" (when functions work in the same way for all types), and
> "ad-hoc" (when the behavior depends on which type is being used).
>
>
>
>
> On Sun, May 6, 2012 at 9:48 AM, Serguey Zefirov wrote:
>>
>> I decided to take a look at DataKinds extension, which became
>> available in GHC 7.4.
>>
>> My main concerns is that I cannot close type classes for promoted data
>> types. Even if I fix type class argument to a promoted type, the use
>> of encoding function still requires specification of context. I
>> consider this an omission of potentially very useful feature.
>>
>> Example is below.
>>
>> -
>> {-# LANGUAGE TypeOperators, DataKinds, TemplateHaskell, TypeFamilies,
>> UndecidableInstances #-}
>> {-# LANGUAGE GADTs #-}
>>
>> -- a binary numbers.
>> infixl 5 :*
>> data D =
>> D0
>> | D1
>> | D :* D
>> deriving Show
>>
>> -- encoding for them.
>> data EncD :: D -> * where
>> EncD0 :: EncD D0
>> EncD1 :: EncD D1
>> EncDStar :: EncD (a :: D) -> EncD (b :: D) -> EncD (a :* b)
>>
>> -- decode of values.
>> fromD :: D -> Int
>> fromD D0 = 0
>> fromD D1 = 1
>> fromD (d :* d0) = fromD d * 2 + fromD d0
>>
>> -- decode of encoded values.
>> fromEncD :: EncD d -> Int
>> fromEncD EncD0 = 0
>> fromEncD EncD1 = 1
>> fromEncD (EncDStar a b) = fromEncD a * 2 + fromEncD b
>>
>> -- constructing encoded values from type.
>> -- I've closed possible kinds for class parameter (and GHC
>> successfully compiles it).
>> -- I fully expect an error if I will try to apply mkD to some type
>> that is not D.
>> -- (and, actually, GHC goes great lengths to prevent me from doing that)
>> -- By extension of argument I expect GHC to stop requiring context
>> with MkD a where
>> -- I use mkD "constant function" and it is proven that a :: D.
>> class MkD (a :: D) where
>> mkD :: EncD a
>> instance MkD D0 where
>> mkD = EncD0
>> instance MkD D1 where
>> mkD = EncD1
>> -- But I cannot omit context here...
>> instance (MkD a, MkD b) => MkD (a :* b) where
>> mkD = EncDStar mkD mkD
>>
>> data BV (size :: D) where
>> BV :: EncD size -> Integer -> BV size
>>
>> bvSize :: BV (size :: D) -> Int
>> bvSize (BV size _) = fromEncD size
>>
>> -- ...and here.
>> -- This is bad, because this context will arise in other places, some of
>> which
>> -- are autogenerated and context for them is incomprehensible to human
>> -- reader.
>> -- (they are autogenerated precisely because of that - it is tedious
>> and error prone
>> -- to satisfy type checker.)
>> fromIntgr :: Integer -> BV (size :: D) -- doesn't work, but desired.
>> -- fromIntgr :: MkD size => Integer -> BV (size :: D) -- does work,
>> but is not that useful.
>> fromIntgr int = BV mkD int
>>
>> -
>>
>> ___
>> 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] Can Haskell outperform C++?
> From: "Richard O'Keefe" > Subject: Re: [Haskell-cafe] Can Haskell outperform C++? > To: Haskell Cafe > Message-ID: <5f6605a2-dfe0-4aea-9987-3b07def34...@cs.otago.ac.nz> > Content-Type: text/plain; charset=us-ascii > > On 17/05/2012, at 2:04 PM, Gregg Lebovitz wrote: > >> Richard, >> >> Thank you. This is an example of what I had in mind when I talked about >> changing the playing field. Do you have a slide deck for this lecture that >> you would be willing to share with me? I am very interested in learning more. > > > No slide deck required. The task is "generating alternating permutations". > > Method 1: generate permutations using a backtracking search; > when a permutation is generated, check if it is alternating. > > Method 2: use the same backtracking search, but only allow extensions > that preserve the property of being an alternating permutation. Gregg, what makes Method 2 so much harder than Method 1 to implement in C or C++? Regards, RW ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: Can Haskell outperform C++?
Oops. Forget to reply to all. -- Forwarded message -- From: Colin Adams Date: 17 May 2012 08:43 Subject: Re: [Haskell-cafe] Can Haskell outperform C++? To: Roman Werpachowski On 17 May 2012 07:12, Roman Werpachowski wrote: > > It depends on what you use the code for. If I run an overnight report > for the trading book of my bank in 16 hours, it is > not acceptable and is a disaster. If I run it in 8h, it's OK-ish. In > business settings, you often have strict deadlines and > optimizing the code to be 2x faster can make a huge difference, as you > change from missing the deadline to > meeting a deadline. > > Seconded. I remember once being asked to examine a certain batch program for performance improvements. I spotted an obvious inefficiency, and made a recommendation, which was implemented. It saved something like 10 - 30 minutes on the overnight run (which took hours), so I was disappointed with the result. But the client was delighted, as the run now fitted into the batch window. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
