Re: Unicode, strings, and Show

> Brandon Allbery : > > On Wed, Mar 30, 2016 at 9:50 PM, Manuel M T Chakravarty > wrote: > Firstly, we have > > isPrint :: Char -> Bool > > Are you saying that this type is wrong? > > Secondly, how often do you feed the output of ’show’ to ’read’ in another > lo

nix build haskell.compiler.ghcHEAD

Hi GHC Devs, Refer https://github.com/NixOS/nixpkgs/issues/14333 for a problem I was having when building with nix. The interesting part is that if I add an extra flag -optl-lpthread manually, the error goes away and the build succeeds. My question is why the build system didn't add the -optl-lpth

Re: Unicode, strings, and Show

On Wed, Mar 30, 2016 at 11:03 PM, Carter Schonwald < carter.schonw...@gmail.com> wrote: > One point in the design space that the swift language does, which seems > intersting at least to me, is to have the notion of a character be backed > by a Unicode grapheme cluster, which is a character like s

Re: Unicode, strings, and Show

One point in the design space that the swift language does, which seems intersting at least to me, is to have the notion of a character be backed by a Unicode grapheme cluster, which is a character like sequence of Unicode code points. Would library support for this at all help this discussion or

Re: Unicode, strings, and Show

On Wed, Mar 30, 2016 at 9:50 PM, Manuel M T Chakravarty < c...@justtesting.org> wrote: > Firstly, we have > > isPrint :: Char -> Bool > > Are you saying that this type is wrong? > > Secondly, how often do you feed the output of ’show’ to ’read’ in another > locale versus how often is everybody w

Re: Unicode, strings, and Show

Firstly, we have isPrint :: Char -> Bool Are you saying that this type is wrong? Secondly, how often do you feed the output of ’show’ to ’read’ in another locale versus how often is everybody whose whole life is outside of ASCII (i.e., not anglo-centric people) bothered by this shortcoming?

Re: Unicode, strings, and Show

On Wed, Mar 30, 2016 at 9:16 PM, Manuel M T Chakravarty < c...@justtesting.org> wrote: > Thank you for all the replies and especially pointing to this ticket. > > I think, the discussion on this ticket is actually misleading and there is > a simple solution, which I added as a comment. > That is

Re: Unicode, strings, and Show

Thank you for all the replies and especially pointing to this ticket. I think, the discussion on this ticket is actually misleading and there is a simple solution, which I added as a comment. Manuel > Thomas Miedema : > > > It would be great if someone could create a Trac ticket > > Existing

Re: GHC HEAD compile failure at ghctags: "missing: Cabal >=1.25 && <1.27"

Oh, yeah. Thanks! - Conal On Wed, Mar 30, 2016 at 10:54 AM, Edward Z. Yang wrote: > Don't forget to "git submodule update" > > Edward > > Excerpts from Conal Elliott's message of 2016-03-30 10:02:20 -0700: > > I'm trying to recompile GHC (via GHC 7.10.3) from freshly git-pulled > HEAD, > > and

Re: singletons stuff in GHC.Generics?

GOTCHA, thanks, i was being a bit myopic in looking around, :) On Wed, Mar 30, 2016 at 3:46 PM, Ben Gamari wrote: > Carter Schonwald writes: > > > Hey All, i just noticed that theres some Singletons code in the > > GHC.Generics module thats defined but not exported, whats the context on > > tha

Re: singletons stuff in GHC.Generics?

Carter Schonwald writes: > Hey All, i just noticed that theres some Singletons code in the > GHC.Generics module thats defined but not exported, whats the context on > that? > It's used strictly internally in instances defined in GHC.Generics. For instance, instance (KnownSymbol n, SingI f,

singletons stuff in GHC.Generics?

Hey All, i just noticed that theres some Singletons code in the GHC.Generics module thats defined but not exported, whats the context on that? https://ghc.haskell.org/trac/ghc/ticket/11775#ticket is the ticket i created to track / ask for clarificaiton:) _Carter ___

Re: GHC HEAD compile failure at ghctags: "missing: Cabal >=1.25 && <1.27"

Don't forget to "git submodule update" Edward Excerpts from Conal Elliott's message of 2016-03-30 10:02:20 -0700: > I'm trying to recompile GHC (via GHC 7.10.3) from freshly git-pulled HEAD, > and "make" keeps dying at ghctags: > > Configuring ghctags-0.1... > ghc-cabal: At least the fol

GHC HEAD compile failure at ghctags: "missing: Cabal >=1.25 && <1.27"

I'm trying to recompile GHC (via GHC 7.10.3) from freshly git-pulled HEAD, and "make" keeps dying at ghctags: Configuring ghctags-0.1... ghc-cabal: At least the following dependencies are missing: Cabal >=1.25 && <1.27 According to ghc-pkg I have Cabal 1.25.0.0 (compiled from a freshl

Re: Unicode, strings, and Show

Thomas Miedema writes: >> It would be great if someone could create a Trac ticket > > > Existing ticket: https://ghc.haskell.org/trac/ghc/ticket/11529 ("Show > instance of Char should print literals for non-ascii printable charcters") Thanks Thomas! I've added a reference to this thread on the t

Re: Unicode, strings, and Show

> It would be great if someone could create a Trac ticket Existing ticket: https://ghc.haskell.org/trac/ghc/ticket/11529 ("Show instance of Char should print literals for non-ascii printable charcters") ___ ghc-devs mailing list ghc-devs@haskell.org htt

Re: Unicode, strings, and Show

Evan Laforge writes: > There was recently a discussion about it, search for subject "Can we > improve Show instance for non-ascii charcters?" > > You can read for yourself but my impression was that people were > generally favorable, but had some backward compatibility worries, and > came up with

RE: Initial compile time benchmarks

| > Deriving costs a lot and we just need someone to figure out what's | > going on. | | are you sure that deriving itself costs a lot? I would expect that | deriving itself is reasonably cheap, but results in a lot of | complicated (e.g. recursive) code that later analyzes have to go | thr

Re: Initial compile time benchmarks

Hi, Am Dienstag, den 29.03.2016, 15:29 -0700 schrieb Edward Z. Yang: > This ticket may be of interest: > > https://ghc.haskell.org/trac/ghc/ticket/9630 > > Deriving costs a lot and we just need someone to figure out what's > going on. are you sure that deriving itself costs a lot? I would expec