On 12 July 2012 14:41, Jens Petersen wrote:
> ghc-7.4.2 should also build fine on Fedora 17 ARM.
Well, at least with Karel's armhfp patch...
> Just "yum install ghc llvm" first.
I tested building RC1 on Fedora ARM, and this is basically
the same srpm (src rpm package) for 7.4.2 including that p
On 13/07/2012 3:08 AM, Cale Gibbard wrote:
Personally I don't see why everyone appears to prefer the syntax with
\ in it over just the obvious case section syntax which was originally
proposed.
case of { ... }
looks much better to me than
\case of { ... }
and the former makes sense to me as a
On 07/10/2012 12:51 PM, malcolm.wallace wrote:
> Also, it is more likely to be a buggy instance of Eq, than a real loss
> of referential transparency.
>
Speaking of which... would it be remiss of me to mention the elephant in
the room, namely the Eq instance for Float?
AFAICT there is no possibl
On 2012-07-12 23:48, Bulat Ziganshin wrote:
another interesting feature may be ruby-style matching defined by
execution of special function `match` instead of pattern matching:
switch var of
1+1 -> print "var==2"
[5..10] -> print "var in [5..10]"
(>20) -> print "var>20"
where (va
Hello wagnerdm,
Thursday, July 5, 2012, 7:22:38 PM, you wrote:
>> After 21 months of occasional arguing the lambda-case proposal(s) is
this reminded me old joke about PL/I: camel is the horse created by committee
i propose to return back and summarize all the requirements we have in
this area.
There are of course already lots of ways to create functions which
don't involve \
I mentioned sections (like (+1) desugaring to (\x -> x + 1)) already,
and of course, one can partially apply or compose and transform other
functions without explicit lambdas.
We're not exactly talking about functi
On Thu, Jul 12, 2012 at 01:38:56PM -0400, Cale Gibbard wrote:
> Personally I don't see why everyone appears to prefer the syntax with
> \ in it over just the obvious case section syntax which was originally
> proposed.
I don't think that the 'case section syntax' is obvious, because I don't
see t
On Thu, Jul 12, 2012 at 11:29 AM, Favonia wrote:
> I see. Thanks for the response! Perhaps it is better for the pretty
> printer to print out "U(S)" instead?
>
> Regards,
> Favonia
I'd love to see a cheat sheet documenting the strictness output. It
confuses me every time, even when I make the eff
I see. Thanks for the response! Perhaps it is better for the pretty
printer to print out "U(S)" instead?
Regards,
Favonia
On Tue, Jul 10, 2012 at 3:57 AM, Simon Marlow wrote:
>
> This is fine - it means the CDouble is unpacked into its unboxed Double#
> component. An unboxed value is always rep
Personally I don't see why everyone appears to prefer the syntax with
\ in it over just the obvious case section syntax which was originally
proposed.
case of { ... }
looks much better to me than
\case of { ... }
and the former makes sense to me as a simple extension of operator
sections to ano
The error message is unhelpful. HEAD reports this:
Could not deduce (Monoid w) arising from a use of `g'
from the context (Monad (WriterT w Identity))
bound by the RULE "f->g" at Foo.hs:14:3-14
Possible fix: add (Monoid w) to the context of the RULE "f->g"
In the expression:
Hi Bas,
On Thu, Jul 12, 2012 at 11:27 AM, Bas van Dijk wrote:
> Hi,
>
> I'm hitting on an issue when deriving Generic for an associated data type:
>
> ...
>
> The GHC trac seems to be down. Is this a known issue?
>
Yes, and it's supposed to be fixed in HEAD. Can you try it with HEAD?
Thanks,
Hi Bas.
> I'm hitting on an issue when deriving Generic for an associated data type:
[...]
Your example compiles for me with HEAD (but fails with 7.4.1 and
7.4.2, yes). I've not tested if it also "works".
Cheers,
Andres
--
Andres Löh, Haskell Consultant
Well-Typed LLP, http://www.well-typed
Hi,
I'm hitting on an issue when deriving Generic for an associated data type:
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE DeriveGeneric #-}
import GHC.Generics
class Foo a where
data T a :: *
instance Foo Int where
data T Int = Bla deriving Generic
Couldn't match type `Rep (T Int)' wi
On 07/12/2012 04:27 AM, Iavor Diatchki wrote:
Hello,
I am late to the discussion and this is not entirely on topic, for which
I apologize, but I like the multi-branch case syntax someone mentioned
earlier:
Writing:
> case
> | p1 -> e1
> | p2 -> e2
> | ...
desugars to:
> case () of
Karel Gardas wrote:
> Last note: GHC/ARM depends on GHC's specific calling convention support
> in LLVM. Unfortunately for ARM platform it was merged into LLVM 3.0, but
> not into LLVM HEAD (at that time), so LLVM 3.1 doesn't support GHC/ARM
> at all. I'm trying to resubmit the support for incl
16 matches
Mail list logo
