Future of "Text.Show.Functions" module

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Future of "Text.Show.Functions" module

Herbert Valerio Riedel
Hello *,

I noticed the following module (trimmed for brevitiy) hiding in `base`:


  -- This module deliberately declares orphan instances:
  {-# OPTIONS_GHC -fno-warn-orphans #-}
 
  -- | Optional instance of 'Text.Show.Show' for functions:
  --
  -- > instance Show (a -> b) where
  -- >    showsPrec _ _ = showString \"\<function\>\"
  --
  -----------------------------------------------------------------------------
   
  module Text.Show.Functions () where
   
  instance Show (a -> b) where
          showsPrec _ _ = showString "<function>"


However, I consider this a questionable module to be in `base` due to
its deliberate use of orphan instances.  Should this module be
deprecated, removed, alternatively, should the `Show` instance be made a
non-orphan (e.g. by importing it by the `Prelude` module), or shall this
curiousity be just left untouched in `base` in its current form?

Cheers,
  hvr
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [core libraries] Future of "Text.Show.Functions" module

Michael Snoyman


On Sun, Oct 19, 2014 at 1:20 PM, Herbert Valerio Riedel <[hidden email]> wrote:
Hello *,

I noticed the following module (trimmed for brevitiy) hiding in `base`:


  -- This module deliberately declares orphan instances:
  {-# OPTIONS_GHC -fno-warn-orphans #-}

  -- | Optional instance of 'Text.Show.Show' for functions:
  --
  -- > instance Show (a -> b) where
  -- >    showsPrec _ _ = showString \"\<function\>\"
  --
  -----------------------------------------------------------------------------

  module Text.Show.Functions () where

  instance Show (a -> b) where
          showsPrec _ _ = showString "<function>"


However, I consider this a questionable module to be in `base` due to
its deliberate use of orphan instances.  Should this module be
deprecated, removed, alternatively, should the `Show` instance be made a
non-orphan (e.g. by importing it by the `Prelude` module), or shall this
curiousity be just left untouched in `base` in its current form?

Cheers,
  hvr

--

I think this really brings up the question of what `Show` should be used for. If the goal is to be simple serialization with `Read` as the inverse[1], then this is clearly a nonsense instance and shouldn't be included. If, on the other hand, we consider `Show` to be simple debug output, this makes perfect sense. Similarly, rendering `IO a` as "<IO action>" or something like that makes sense too.

An example where this came up recently was adding a Show instance to the Request type in WAI[2]. The goal there is explicitly debugging, and displaying some uninteresting string for any IO actions is very useful. Having such an instance built into base would have been convenient for auto-deriving of this Show instance.

Overall, the problem is that we've overloaded Show in (at least) three different ways:

* Textual serialization
* Debugging
* User-friendly display of data

I think I give a +0.5 to re-exporting this instance from Prelude/making it non-orphan, since:

1. I agree that orphans in base are a bad idea.
2. Removing the instance will possibly cause breakage for someone.
3. I *do* personally lean towards using Show instances for debugging purposes, and in that context, the Show instance is a good one.

Michael

[1] I believe the correct term is actually a retraction.
[2] https://github.com/yesodweb/wai/issues/290

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Future of "Text.Show.Functions" module

Herbert Valerio Riedel
In reply to this post by Herbert Valerio Riedel
On 2014-10-19 at 12:20:23 +0200, Herbert Valerio Riedel wrote:

[...]

>   instance Show (a -> b) where
>           showsPrec _ _ = showString "<function>"

PS: An effect of having this instance made default in Prelude is that
    GHCi would show a somewhat different result in some cases (not sure
    though if this a good or bad thing):


      GHCi, version 7.8.3: http://www.haskell.org/ghc/  :? for help
      Loading package ghc-prim ... linking ... done.
      Loading package integer-gmp ... linking ... done.
      Loading package base ... linking ... done.
      λ:2> id
       
      <interactive>:2:1:
          No instance for (Show (a0 -> a0)) arising from a use of ‘print’
          In a stmt of an interactive GHCi command: print it
      λ:3> import Text.Show.Functions
      λ:4> id
      <function>
      it :: a -> a


Cheers,
  hvr
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [core libraries] Future of "Text.Show.Functions" module

Henning Thielemann
In reply to this post by Michael Snoyman

On Sun, 19 Oct 2014, Michael Snoyman wrote:

> Overall, the problem is that we've overloaded Show in (at least) three different ways:
>
> * Textual serialization
> * Debugging
> * User-friendly display of data

Unfortunately, the Show class is not used consistently, with the different
uses you have listed.

The automatically derived Show instances show valid Haskell expressions,
that you can enter into GHCi in order to get back the shown value. I think
we should stick to that meaning.

Strictly conforming to this rule would also mean that using 'show' for
formatting numbers is not precisely correct, because we cannot expect that
other tools can parse all ways of writing number literals in Haskell.
Maybe printf is better here, but it is unfortunately not total.

Following the above rule for functions would mean, that 'show' should emit
an expression that represents the function, e.g. something like

Prelude> show ((\x->x*x) :: Int -> Int)
fromJust . flip lookup [(0,0), (1,1), (-1,1), (2,4), (-2,4), ...
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [core libraries] Future of "Text.Show.Functions" module

Herbert Valerio Riedel
On 2014-10-19 at 15:19:42 +0200, Henning Thielemann wrote:

[...]

> Prelude> show ((\x->x*x) :: Int -> Int)
> fromJust . flip lookup [(0,0), (1,1), (-1,1), (2,4), (-2,4), ...

That scheme only works for enumerable input-types though, as
computing something like 'show fmap' would be quite a challenge :-)
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Future of "Text.Show.Functions" module

Reid Barton-2
In reply to this post by Herbert Valerio Riedel
On Sun, Oct 19, 2014 at 9:18 AM, Herbert Valerio Riedel <[hidden email]> wrote:
On 2014-10-19 at 12:20:23 +0200, Herbert Valerio Riedel wrote:

[...]

>   instance Show (a -> b) where
>           showsPrec _ _ = showString "<function>"

PS: An effect of having this instance made default in Prelude is that
    GHCi would show a somewhat different result in some cases (not sure
    though if this a good or bad thing):


      GHCi, version 7.8.3: http://www.haskell.org/ghc/  :? for help
      Loading package ghc-prim ... linking ... done.
      Loading package integer-gmp ... linking ... done.
      Loading package base ... linking ... done.
      λ:2> id

      <interactive>:2:1:
          No instance for (Show (a0 -> a0)) arising from a use of ‘print’
          In a stmt of an interactive GHCi command: print it
      λ:3> import Text.Show.Functions
      λ:4> id
      <function>
      it :: a -> a

You seem to have ":set +t" on (show types), which isn't the default unless it changed in HEAD very recently.

I'm -1 for reasons including

* Worse usability in ghci by default. If I see "No instance for (Show (IOMode -> IO Handle))", I can figure out that I omitted an argument of type IOMode, but if I see "<function>" I only know that I omitted some argument, and I have to redo the command with :t to learn more.

* Precludes other instances Show (a -> b), some of which already exist in the wild, e.g. lambdabot's that uses Typeable to produce a string like "<Char -> Int>" (but breaks down in the presence of polymorphism), or the 'countable' package's (Show a,Finite a,Show b) => Show (a -> b).

* I don't see what we gain by forcing this instance on everybody rather than letting people opt in with "import Text.Show.Functions". When was the last time you encountered an error because two of your imports exported different Show (a -> b) instances? Orphan instances are bad in general, but for debugging hacks I think they're fine.

I'm neutral on whether to remove Text.Show.Functions or leave it as is. FWIW, I was unaware of its existence before your email.

Regards,
Reid Barton

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Future of "Text.Show.Functions" module

Malcolm Wallace-2
In reply to this post by Herbert Valerio Riedel

On 19 Oct 2014, at 11:20, Herbert Valerio Riedel wrote:

>  -- This module deliberately declares orphan instances:
>  {-# OPTIONS_GHC -fno-warn-orphans #-}
>
>  -- | Optional instance of 'Text.Show.Show' for functions:
>  --
>  -- > instance Show (a -> b) where
>  -- >    showsPrec _ _ = showString \"\<function\>\"
>  --
>  -----------------------------------------------------------------------------
> Should this module be
> deprecated, removed, alternatively, should the `Show` instance be made a
> non-orphan (e.g. by importing it by the `Prelude` module), or shall this
> curiousity be just left untouched in `base` in its current form?


Under no circumstances should this instance ever be visible from the Prelude.

It was deliberately made an orphan because the instance is non-conformant to the intended semantics of the Show class.  Having a default instance of Show for functions would be a disaster, by causing static type error messages that indicate an arity problem, to become erratic runtime behaviours instead (without even throwing an exception).

Nevertheless, it was found many years ago that lots of people defined this instance as a convenience, or a debugging aid.  And once it accidentally gets into two different released libraries, the orphans conflict, and the libraries become unusable together.  This is why a single "standard" orphan was thought preferable to multiple conflicting orphans.

In summary, if you want this instance, you should know that it is problematic, and that you need to import it explicitly.

Regards,
    Malcolm
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Future of "Text.Show.Functions" module

Henning Thielemann

On Sun, 19 Oct 2014, Malcolm Wallace wrote:

> Nevertheless, it was found many years ago that lots of people defined
> this instance as a convenience, or a debugging aid.

If its only purpose is debugging, how about moving it under the Debug
directory in the module hierarchy?
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [core libraries] Future of "Text.Show.Functions" module

Brandon Allbery
In reply to this post by Michael Snoyman
On Sun, Oct 19, 2014 at 8:59 AM, Michael Snoyman <[hidden email]> wrote:
I think this really brings up the question of what `Show` should be used for. If the goal is to be simple serialization with `Read` as the inverse[1], then this is clearly a nonsense instance and shouldn't be included.

I think I've said before that it would be nice if we had a specific class for debugging displays, given that Read/Show are generally oriented toward serialization. Sadly, this would end up requiring a lot of repetition, since you couldn't sanely fall back on a default Show instance to get a notional Gist (or whatever) instance.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Future of "Text.Show.Functions" module

Michael Snoyman
In reply to this post by Malcolm Wallace-2


On Sun, Oct 19, 2014 at 4:55 PM, Malcolm Wallace <[hidden email]> wrote:

On 19 Oct 2014, at 11:20, Herbert Valerio Riedel wrote:

>  -- This module deliberately declares orphan instances:
>  {-# OPTIONS_GHC -fno-warn-orphans #-}
>
>  -- | Optional instance of 'Text.Show.Show' for functions:
>  --
>  -- > instance Show (a -> b) where
>  -- >    showsPrec _ _ = showString \"\<function\>\"
>  --
>  -----------------------------------------------------------------------------
> Should this module be
> deprecated, removed, alternatively, should the `Show` instance be made a
> non-orphan (e.g. by importing it by the `Prelude` module), or shall this
> curiousity be just left untouched in `base` in its current form?


Under no circumstances should this instance ever be visible from the Prelude.

It was deliberately made an orphan because the instance is non-conformant to the intended semantics of the Show class.  Having a default instance of Show for functions would be a disaster, by causing static type error messages that indicate an arity problem, to become erratic runtime behaviours instead (without even throwing an exception).


While I'm sensitive to this position (thus my very reluctant +0.5 on merging into Prelude), I don't see the "disaster" you're referring to. The only case I can picture where this might happen is when you have a value that you are *only* ever displaying, not using in any other way. But won't it become painfully obvious very quickly that you messed up?

Can you describe concretely a scenario where the presence of this instance in Prelude would cause a disaster?

And if the instance is really as bad as that, I think having it in base at all is a mistake. All it takes it one library upstream from you to import that module, and you've been infected.

Michael

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Future of "Text.Show.Functions" module

Brandon Allbery
On Sun, Oct 19, 2014 at 3:00 PM, Michael Snoyman <[hidden email]> wrote:
And if the instance is really as bad as that, I think having it in base at all is a mistake. All it takes it one library upstream from you to import that module, and you've been infected.

It's useful in ghci.

Which suggests a possible solution: perhaps things like this that are mostly useful from ghci should go into a GHC.Interactive hierarchy.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [core libraries] Re: Future of "Text.Show.Functions" module

Michael Snoyman


On Sun, Oct 19, 2014 at 10:03 PM, Brandon Allbery <[hidden email]> wrote:
On Sun, Oct 19, 2014 at 3:00 PM, Michael Snoyman <[hidden email]> wrote:
And if the instance is really as bad as that, I think having it in base at all is a mistake. All it takes it one library upstream from you to import that module, and you've been infected.

It's useful in ghci.

Which suggests a possible solution: perhaps things like this that are mostly useful from ghci should go into a GHC.Interactive hierarchy.



Based on this thread, I thought it was specifically in GHCi when it was *not* considered helpful. Without the instance:

Prelude> print concat

<interactive>:2:1:
    No instance for (Show ([[a0]] -> [a0]))
      arising from a use of ‘print’
    In the expression: print concat
    In an equation for ‘it’: it = print concat

at least tells me what I'm looking at, whereas:

Prelude> import Text.Show.Functions
Prelude Text.Show.Functions> print concat
<function>

gives no important info. However, if this is all for GHCi's sake, isn't it really a moot point:

Prelude Text.Show.Functions> :t concat
concat :: [[a]] -> [a]

I'd consider this instance useful for the case of:

data Foo = Foo { foo1 :: Int, foo2 :: Double, foo3 :: Char -> Bool }
    deriving Show

Michael

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Future of "Text.Show.Functions" module

Edward Kmett-2
In reply to this post by Malcolm Wallace-2
Malcolm's reasoning matches mine perfectly here.

The instance should not be standard.

It should never go into Prelude.

It standardizes on one of many viable choices.

However, it is one of those things that folks, rightly or wrongly, define fairly often and removing it would increase conflicts among orphans doing the same thing.

I'd strongly advocate holding your nose and leaving it there.

Sent from my iPhone

> On Oct 19, 2014, at 9:55 AM, Malcolm Wallace <[hidden email]> wrote:
>
>
>> On 19 Oct 2014, at 11:20, Herbert Valerio Riedel wrote:
>>
>> -- This module deliberately declares orphan instances:
>> {-# OPTIONS_GHC -fno-warn-orphans #-}
>>
>> -- | Optional instance of 'Text.Show.Show' for functions:
>> --
>> -- > instance Show (a -> b) where
>> -- >    showsPrec _ _ = showString \"\<function\>\"
>> --
>> -----------------------------------------------------------------------------
>> Should this module be
>> deprecated, removed, alternatively, should the `Show` instance be made a
>> non-orphan (e.g. by importing it by the `Prelude` module), or shall this
>> curiousity be just left untouched in `base` in its current form?
>
>
> Under no circumstances should this instance ever be visible from the Prelude.
>
> It was deliberately made an orphan because the instance is non-conformant to the intended semantics of the Show class.  Having a default instance of Show for functions would be a disaster, by causing static type error messages that indicate an arity problem, to become erratic runtime behaviours instead (without even throwing an exception).
>
> Nevertheless, it was found many years ago that lots of people defined this instance as a convenience, or a debugging aid.  And once it accidentally gets into two different released libraries, the orphans conflict, and the libraries become unusable together.  This is why a single "standard" orphan was thought preferable to multiple conflicting orphans.
>
> In summary, if you want this instance, you should know that it is problematic, and that you need to import it explicitly.
>
> Regards,
>    Malcolm
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Future of "Text.Show.Functions" module

Roman Cheplyaka-2
In reply to this post by Michael Snoyman
On 19/10/14 22:00, Michael Snoyman wrote:

> On Sun, Oct 19, 2014 at 4:55 PM, Malcolm Wallace <[hidden email]>
> wrote:
>
>>
>> On 19 Oct 2014, at 11:20, Herbert Valerio Riedel wrote:
>>
>>>  -- This module deliberately declares orphan instances:
>>>  {-# OPTIONS_GHC -fno-warn-orphans #-}
>>>
>>>  -- | Optional instance of 'Text.Show.Show' for functions:
>>>  --
>>>  -- > instance Show (a -> b) where
>>>  -- >    showsPrec _ _ = showString \"\<function\>\"
>>>  --
>>>
>> -----------------------------------------------------------------------------
>>> Should this module be
>>> deprecated, removed, alternatively, should the `Show` instance be made a
>>> non-orphan (e.g. by importing it by the `Prelude` module), or shall this
>>> curiousity be just left untouched in `base` in its current form?
>>
>>
>> Under no circumstances should this instance ever be visible from the
>> Prelude.
>>
>> It was deliberately made an orphan because the instance is non-conformant
>> to the intended semantics of the Show class.  Having a default instance of
>> Show for functions would be a disaster, by causing static type error
>> messages that indicate an arity problem, to become erratic runtime
>> behaviours instead (without even throwing an exception).
>>
>>
> While I'm sensitive to this position (thus my very reluctant +0.5 on
> merging into Prelude), I don't see the "disaster" you're referring to. The
> only case I can picture where this might happen is when you have a value
> that you are *only* ever displaying, not using in any other way. But won't
> it become painfully obvious very quickly that you messed up?

A simple example would be using show to produce debug output like this:

  debug $ show $ f x1 x2 ...

where you missed some of the arguments for f.

For the record, I agree with Malcolm's reasoning and would like the
instance to be left as it is now.

Roman
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Future of "Text.Show.Functions" module

Herbert Valerio Riedel
In reply to this post by Edward Kmett-2
On 2014-10-19 at 23:24:25 +0200, Edward Kmett wrote:

> Malcolm's reasoning matches mine perfectly here.
>
> The instance should not be standard.
>
> It should never go into Prelude.
>
> It standardizes on one of many viable choices.
>
> However, it is one of those things that folks, rightly or wrongly,
> define fairly often and removing it would increase conflicts among
> orphans doing the same thing.
>
> I'd strongly advocate holding your nose and leaving it there.

Fair enough. But what about adding a WARNING pragma such as
(modulo wording):


  module Text.Show.Functions {-# WARNING "Here Be Dragons, RTFM!" -# } where


and adding a bit more documentation pointing out the dos and donts of
using that module (like explaining it is not be advisable import that
module in a public library package to be placed on Hackage due to the
global namespace issue of such instances)

Cheers,
  hvr
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Future of "Text.Show.Functions" module

Edward Kmett-2
I'd have no objection to a well-worded warning.

On Mon, Oct 20, 2014 at 4:57 AM, Herbert Valerio Riedel <[hidden email]> wrote:
On 2014-10-19 at 23:24:25 +0200, Edward Kmett wrote:
> Malcolm's reasoning matches mine perfectly here.
>
> The instance should not be standard.
>
> It should never go into Prelude.
>
> It standardizes on one of many viable choices.
>
> However, it is one of those things that folks, rightly or wrongly,
> define fairly often and removing it would increase conflicts among
> orphans doing the same thing.
>
> I'd strongly advocate holding your nose and leaving it there.

Fair enough. But what about adding a WARNING pragma such as
(modulo wording):


  module Text.Show.Functions {-# WARNING "Here Be Dragons, RTFM!" -# } where


and adding a bit more documentation pointing out the dos and donts of
using that module (like explaining it is not be advisable import that
module in a public library package to be placed on Hackage due to the
global namespace issue of such instances)

Cheers,
  hvr


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [core libraries] Future of "Text.Show.Functions" module

Andreas Abel
In reply to this post by Brandon Allbery
Strongly +1 for Show printing valid Haskell.

I'd implement showing for functions as

   data Function = Function

   instance Show (a -> b) where
     show f = "Function"

(I would not assume Haskellers expect a Show-ed function to be Read-able.)

For simple user-friendly display we should add a class to Text.PrettyPrint

   class Pretty a where
     pretty     :: a -> Doc
     pretty     = text . prettyShow

     prettyShow :: a -> String
     prettyShow = render . pretty

This class should become standard for implementing simple pretty
printing (instead of the abuse of Show).

Cheers,
Andreas


On 19.10.2014 17:36, Brandon Allbery wrote:

> On Sun, Oct 19, 2014 at 8:59 AM, Michael Snoyman <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I think this really brings up the question of what `Show` should be
>     used for. If the goal is to be simple serialization with `Read` as
>     the inverse[1], then this is clearly a nonsense instance and
>     shouldn't be included.
>
>
> I think I've said before that it would be nice if we had a specific
> class for debugging displays, given that Read/Show are generally
> oriented toward serialization. Sadly, this would end up requiring a lot
> of repetition, since you couldn't sanely fall back on a default Show
> instance to get a notional Gist (or whatever) instance.



--
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [core libraries] Future of "Text.Show.Functions" module

Ganesh Sittampalam
What's the benefit of this implementation of Show (a -> b)? Even if it
causes the output to be parseable, it's unlikely to typecheck.

On 20/10/2014 22:00, Andreas Abel wrote:

> Strongly +1 for Show printing valid Haskell.
>
> I'd implement showing for functions as
>
>   data Function = Function
>
>   instance Show (a -> b) where
>     show f = "Function"
>
> (I would not assume Haskellers expect a Show-ed function to be Read-able.)
>
> For simple user-friendly display we should add a class to Text.PrettyPrint
>
>   class Pretty a where
>     pretty     :: a -> Doc
>     pretty     = text . prettyShow
>
>     prettyShow :: a -> String
>     prettyShow = render . pretty
>
> This class should become standard for implementing simple pretty
> printing (instead of the abuse of Show).
>
> Cheers,
> Andreas
>
>
> On 19.10.2014 17:36, Brandon Allbery wrote:
>> On Sun, Oct 19, 2014 at 8:59 AM, Michael Snoyman <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     I think this really brings up the question of what `Show` should be
>>     used for. If the goal is to be simple serialization with `Read` as
>>     the inverse[1], then this is clearly a nonsense instance and
>>     shouldn't be included.
>>
>>
>> I think I've said before that it would be nice if we had a specific
>> class for debugging displays, given that Read/Show are generally
>> oriented toward serialization. Sadly, this would end up requiring a lot
>> of repetition, since you couldn't sanely fall back on a default Show
>> instance to get a notional Gist (or whatever) instance.
>
>
>

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [core libraries] Future of "Text.Show.Functions" module

Carter Schonwald
agreed, i'm strongly  -1 on forcing a generic catchall a->b instance,
especially since things like   Show a =>  Show (Bool -> a) , are pretty useful!

On Wed, Oct 22, 2014 at 4:46 PM, Ganesh Sittampalam <[hidden email]> wrote:
What's the benefit of this implementation of Show (a -> b)? Even if it
causes the output to be parseable, it's unlikely to typecheck.

On 20/10/2014 22:00, Andreas Abel wrote:
> Strongly +1 for Show printing valid Haskell.
>
> I'd implement showing for functions as
>
>   data Function = Function
>
>   instance Show (a -> b) where
>     show f = "Function"
>
> (I would not assume Haskellers expect a Show-ed function to be Read-able.)
>
> For simple user-friendly display we should add a class to Text.PrettyPrint
>
>   class Pretty a where
>     pretty     :: a -> Doc
>     pretty     = text . prettyShow
>
>     prettyShow :: a -> String
>     prettyShow = render . pretty
>
> This class should become standard for implementing simple pretty
> printing (instead of the abuse of Show).
>
> Cheers,
> Andreas
>
>
> On 19.10.2014 17:36, Brandon Allbery wrote:
>> On Sun, Oct 19, 2014 at 8:59 AM, Michael Snoyman <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     I think this really brings up the question of what `Show` should be
>>     used for. If the goal is to be simple serialization with `Read` as
>>     the inverse[1], then this is clearly a nonsense instance and
>>     shouldn't be included.
>>
>>
>> I think I've said before that it would be nice if we had a specific
>> class for debugging displays, given that Read/Show are generally
>> oriented toward serialization. Sadly, this would end up requiring a lot
>> of repetition, since you couldn't sanely fall back on a default Show
>> instance to get a notional Gist (or whatever) instance.
>
>
>

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries