Re: Unicode, strings, and Show

2016-03-30 Thread Carter Schonwald 
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 problem?

On Wednesday, March 30, 2016, Brandon Allbery  wrote:

> 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 whose whole life is outside of ASCII
>> (i.e., not anglo-centric people) bothered by this shortcoming? (*)
>>
>> Moreover, the argument on the ticket was that changing the current
>> implementation would go against the standard. Now that I am saying, the
>> current implementation is not conforming to the standard, the standard
>> suddenly doesn’t seem to matter. Personally, I would say, when we wrote
>> that standard, we knew what we were doing.
>>
>
> The standard I am aware of is the Report, which deliberately limited the
> output to the subset which is guaranteed to be usable in all locales. show
> conforms to this; apparently people want it to *not* conform, and in a way
> which requires some locale to become the One True Locale.
>
> isPrint is, as per the language Report, based on what Char is --- which is
> Unicode codepoints. Using it for output --- or for input, for that matter
> --- gets you into locale issues because nobody anywhere guarantees that
> Unicode codepoints that pass isPrint are representable in every locale.
> isPrint is not the place to verify that a character can actually be
> displayed in the current locale.
>
> Or have you decided that ghc should require Unicode locales and nothing
> but Unicode locales from now on? If so, what do you do when the next issue
> comes up, where Unix is UTF8 and Windows is UTF16?
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com 
>  ballb...@sinenomine.net
> 
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unicode, strings, and Show

2016-03-30 Thread Brandon Allbery 
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 whose whole life is outside of ASCII
> (i.e., not anglo-centric people) bothered by this shortcoming? (*)
>
> Moreover, the argument on the ticket was that changing the current
> implementation would go against the standard. Now that I am saying, the
> current implementation is not conforming to the standard, the standard
> suddenly doesn’t seem to matter. Personally, I would say, when we wrote
> that standard, we knew what we were doing.
>

The standard I am aware of is the Report, which deliberately limited the
output to the subset which is guaranteed to be usable in all locales. show
conforms to this; apparently people want it to *not* conform, and in a way
which requires some locale to become the One True Locale.

isPrint is, as per the language Report, based on what Char is --- which is
Unicode codepoints. Using it for output --- or for input, for that matter
--- gets you into locale issues because nobody anywhere guarantees that
Unicode codepoints that pass isPrint are representable in every locale.
isPrint is not the place to verify that a character can actually be
displayed in the current locale.

Or have you decided that ghc should require Unicode locales and nothing but
Unicode locales from now on? If so, what do you do when the next issue
comes up, where Unix is UTF8 and Windows is UTF16?

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unicode, strings, and Show

2016-03-30 Thread Brandon Allbery 
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 in fact not simple at all: with that, the ostensibly pure `show`
now depends on the user's locale and therefore should be in IO (and you
cannot reliably feed it to `read` in a program running in a different
locale)! This is why the ticket was concentrating on ghci, where it's at
least somewhat reasonable to assume a UTF8 environment.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unicode, strings, and Show

2016-03-30 Thread Manuel M T Chakravarty 
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 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
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

2016-03-30 Thread Conal Elliott 
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 "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 freshly
> > git-pulled git clone).
> >
> > Any ideas what's going on and how I can fix it?
> >
> > Thanks.  - Conal
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: singletons stuff in GHC.Generics?

2016-03-30 Thread Carter Schonwald 
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
> > that?
> >
> It's used strictly internally in instances defined in GHC.Generics. For
> instance,
>
> instance (KnownSymbol n, SingI f, SingI r)
> => Constructor ('MetaCons n f r) where
>   conName _ = symbolVal (Proxy :: Proxy n)
>   conFixity   _ = fromSing  (sing  :: Sing f)
>   conIsRecord _ = fromSing  (sing  :: Sing r)
>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: singletons stuff in GHC.Generics?

2016-03-30 Thread Ben Gamari 
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, SingI r)
=> Constructor ('MetaCons n f r) where
  conName _ = symbolVal (Proxy :: Proxy n)
  conFixity   _ = fromSing  (sing  :: Sing f)
  conIsRecord _ = fromSing  (sing  :: Sing r)

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

singletons stuff in GHC.Generics?

2016-03-30 Thread Carter Schonwald 
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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

2016-03-30 Thread Edward Z. Yang 
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 following dependencies are missing:
> Cabal >=1.25 && <1.27
> 
> According to ghc-pkg I have Cabal 1.25.0.0 (compiled from a freshly
> git-pulled git clone).
> 
> Any ideas what's going on and how I can fix it?
> 
> Thanks.  - Conal
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

2016-03-30 Thread Conal Elliott 
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 freshly
git-pulled git clone).

Any ideas what's going on and how I can fix it?

Thanks.  - Conal
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unicode, strings, and Show

2016-03-30 Thread Ben Gamari 
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 ticket.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unicode, strings, and Show

2016-03-30 Thread Thomas Miedema 
> 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
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unicode, strings, and Show

2016-03-30 Thread Ben Gamari 
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 some workarounds, but no one committed to following up on
> a ghci patch.
>
It would be great if someone could create a Trac ticket so we had
someplace persistent to track this discussion. Manuel, perhaps you could
handle this?

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Initial compile time benchmarks

2016-03-30 Thread Simon Peyton Jones 
|  > 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
|  through...

I think that's right. But somehow the code generated by 'deriving' tickles some 
non-linearity (I guess) in the rest of the compiler.  It would be great to know 
what it was.

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Joachim Breitner
|  Sent: 30 March 2016 08:11
|  To: ghc-devs@haskell.org
|  Subject: 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 expect that
|  deriving itself is reasonably cheap, but results in a lot of
|  complicated (e.g. recursive) code that later analyzes have to go
|  through...
|  
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.has
|  kell.org%2ftrac%2fghc%2fticket%2f9557=01%7c01%7csimonpj%40064d.mgd
|  .microsoft.com%7c209ce28b44644d1603d408d3586a7ea2%7c72f988bf86f141af91a
|  b2d7cd011db47%7c1=7NJ%2fd7z98HtnTvPqQvR5o%2bGr5U6RewWBNlRudH4xZvY
|  %3d and tickets linked from there are also relevant. In fact, there is
|  even a keyword for this
|  meta-issue:
|  https://ghc.haskell.org/trac/ghc/query?status=!closed=~derivin
|  g-perf
|  
|  Greetings,
|  Joachim
|  
|  
|  --
|  Joachim “nomeata” Breitner
|    m...@joachim-breitner.de •
|  https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.jo
|  achim-
|  breitner.de%2f=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c209ce2
|  8b44644d1603d408d3586a7ea2%7c72f988bf86f141af91ab2d7cd011db47%7c1
|  =bIiW5fIZ9Wnv2IWkDGjTU3PMuA6nmitgcHmBdY5q31Q%3d
|    XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
|    Debian Developer: nome...@debian.org

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Initial compile time benchmarks

2016-03-30 Thread Joachim Breitner 
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 expect that
deriving itself is reasonably cheap, but results in a lot of
complicated (e.g. recursive) code that later analyzes have to go
through...

http://ghc.haskell.org/trac/ghc/ticket/9557 and tickets linked from
there are also relevant. In fact, there is even a keyword for this
meta-issue:
https://ghc.haskell.org/trac/ghc/query?status=!closed=~deriving-perf

Greetings,
Joachim


-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs