[Haskell-cafe] Fw: Bikeshedding request for GHCi's :type

[Takenobu Tani]

Dear cafe,

I'm forwarding mail from ghc-devs ML [1].

I think `:type` command is very important for beginners and middle users.

Please feedback your opinion to them ;)

[1]: https://mail.haskell.org/pipermail/ghc-devs/2016-April/011933.html

> 2016-04-26 22:08 GMT+09:00 Richard Eisenberg <e...@cis.upenn.edu>:

> Hi devs,

> 

> Over the weekend, I was pondering the Haskell course I will be teaching next year and shuddered at having to teach Foldable at the same time as `length`. So I implemented feature request #10963 (https://ghc.haskell.org/trac/ghc/ticket/10963), which allows for a way for a user to request a specialization of a type. It all works wonderfully, but there is a real user-facing design issue here around the default behavior of :type and whether or not to add new :type-y like commands. I have outlined the situation here: https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type

> 

> I'd love some broad input on this issue. If you've got a stake in how this all works, please skim that wiki page and comment on #10963.

> 

> Thanks!

> Richard

Cheers,

Takenobu

[Anton Felix Lorenzen]

As a middle user, I often depend on `:type` when learning a library.
I don't have strong preferences over one proposal or the other,
but I would like to add, that there should always be
`:type` in its current form (renamed or not).

I wouldn't like getting lots of for me irrelevant information,
like examples, when I only want a one-line type signature.

That said, I like the general idea, although I don't know,
whether a beginner would like having to learn the type signatures again,
when getting to a more advanced level.

- Anton Lorenzen


_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

[Daniel Díaz]

I like the flag idea mentioned by Eric Seidel:

> Perhaps instead of changing the default behavior of :type or adding new

commands, we could add a flag to enhance :type's output.

Would it be overkill to have two flags, one that enabled showing the full type + specializations, and a "newbie mode" flag that only showed a few specializations?

Daniel.

[Matt]

It seems that we really want is something like Idris's `:doc` command:

Idris> :doc map
Prelude.Functor.map : Functor f => (m : a -> b) -> f a -> f b
    Apply a function across everything of type 'a' in a
    parameterised type
    
    The function is Total

 

Idris> :doc length
Prelude.List.length : List a -> Nat
    Compute the length of a list.
    
    Runs in linear time
    
    The function is Total
Prelude.Strings.length : String -> Nat
    Returns the length of the string.
    
        > length ""
        0
    
        > length "ABC"
        3
    
    The function is Total

I don't like the idea of making `:type` more complicated, and I think this would satisfy the need for understanding much more effectively.

Matt Parsons

[Richard Eisenberg]

I have collected feedback gleaned here, on the ticket, and on reddit and summarized here: https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type#Summaryoffeedbackaboutthisissue

That summary includes this concrete proposal:
1. Ask for concrete suggestions about names for the new commands.
2. Use these names on my current implementation (which prints out only one specialization)
3. Post a feature request looking for more specializations.

I simply don't have time to specify a design or implement an algorithm for printing out multiple specializations. Furthermore, my current implementation meets all specifications proffered for printing out multiple specializations, for all values of "multiple" that equal 1. It is easy to extend later.

Separately, there is a groundswell of support for :doc, but that's beyond the scope of my work on this point. (I personally would love :doc, too.)

So, what shall we name the two new commands?

1. A new command that specializes a type. (Currently with one specialization, but perhaps more examples in the future.)

2. A new command that preserves specialized type variables so that users of TypeApplications know what type parameters to pass in next.

I have suggested :type-def for (1) and :type-spec for (2). I don't strongly like either. :examples and :inst have been suggested for (1). Any other ideas?

Thanks!
Richard

On Apr 26, 2016, at 9:08 AM, Richard Eisenberg <e...@cis.upenn.edu> wrote:

> Hi devs,
>
> Over the weekend, I was pondering the Haskell course I will be teaching next year and shuddered at having to teach Foldable at the same time as `length`. So I implemented feature request #10963 (https://ghc.haskell.org/trac/ghc/ticket/10963), which allows for a way for a user to request a specialization of a type. It all works wonderfully, but there is a real user-facing design issue here around the default behavior of :type and whether or not to add new :type-y like commands. I have outlined the situation here: https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type
>
> I'd love some broad input on this issue. If you've got a stake in how this all works, please skim that wiki page and comment on #10963.
>
> Thanks!
> Richard

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

[Eric Seidel]

On Mon, May 2, 2016, at 13:10, Richard Eisenberg wrote:
> So, what shall we name the two new commands?
>
> 1. A new command that specializes a type. (Currently with one
> specialization, but perhaps more examples in the future.)
>
> 2. A new command that preserves specialized type variables so that users
> of TypeApplications know what type parameters to pass in next.
>
> I have suggested :type-def for (1) and :type-spec for (2). I don't
> strongly like either. :examples and :inst have been suggested for (1).
> Any other ideas?

This might be overly pedantic of me, but :type-def seems way too similar
to typedef, which means something entirely different in common parlance
(even though we don't use that word in Haskell-land). We should at least
call it :type-default; GHCi should be able to disambiguate the shorter
:type-def.

Also, I'd suggest making (1) and (2) optional flags for :type rather
than new top-level commands. The shared prefix already suggests a common
purpose, printing out the type of something, so why not make it even
clearer that (1) and (2) are just specializations (heh) of :type?

Eric

[Richard Eisenberg]

On May 2, 2016, at 4:36 PM, Eric Seidel <er...@seidel.io> wrote:

> Also, I'd suggest making (1) and (2) optional flags for :type rather
> than new top-level commands. The shared prefix already suggests a common
> purpose, printing out the type of something, so why not make it even
> clearer that (1) and (2) are just specializations (heh) of :type?

Others have echoed this and I'm open to the idea. But I, personally, dislike this. All three commands are useful, and I expect I'll want to frequently interleave which one I want during a GHCi session. Controlling via a flag makes this awkward.

But that's just my 2¢.

[Jack Henahan]

What about :type for the normal behavior and :type! for specializations? With the notion that it could be extended to provide multiple specializations, I could also see :types (both meaning "display multiple example types" and serving as a mnemonic for :types[pecialization]) being viable.

[Eric Seidel]

On Mon, May 2, 2016, at 13:39, Richard Eisenberg wrote:
>
> On May 2, 2016, at 4:36 PM, Eric Seidel <er...@seidel.io> wrote:
>
> > Also, I'd suggest making (1) and (2) optional flags for :type rather
> > than new top-level commands. The shared prefix already suggests a common
> > purpose, printing out the type of something, so why not make it even
> > clearer that (1) and (2) are just specializations (heh) of :type?
>
> Others have echoed this and I'm open to the idea. But I, personally,
> dislike this. All three commands are useful, and I expect I'll want to
> frequently interleave which one I want during a GHCi session. Controlling
> via a flag makes this awkward.
>
> But that's just my 2¢.

Ah, I was talking about a different kind of flag this time.

Instead of a GHCi-level flag (or maybe in addition to..), I was thinking
about a flag specifically associated with an invocation of :type, e.g.

ghci> :type length
Foldable t => t a -> Int
ghci> :type -default length
[a] -> Int

It's very nitpicky, I know, but I think the added grouping would be
nice, in particular w.r.t. the output of :help.

[William Yager]

+1 to ":types". Easy to remember as well: "Do I want one type, or multiple types?".

[Carter Schonwald]

I'm inclined to agree with Richard on this.  Flag based behavior pushes more

Complexity into the meaning of a command. Zero config is best config, and thusly having easy way to distinguish these (using the power of names!) is something I personally agree with 

Perhaps just as importantly: ~/.ghci files are a thing, so it'd be easy for folks to define custom short hands if they like.  And we literally don't know yet how instructional use will help refine what the end state should be :)

[Rémi Vion]

Hello, thanks for this feature !

2 things:

1.

> Herbert has reminded us to make sure that any changes do not invalidate common existing workflows, like typing :ty<TAB> foo into GHCi.

if you use :types, then ":ty<tab>" will expand to ":type" (no space after the 'e'), so it will break slightly his workflow, because he'll have to type :ty<TAB><space>foo

In comparaison, as of now, ":ty<tab>" expand to ":type " (with a space after the 'e'), so he can just type :ty<TAB>foo

2.

ghci-ng has :

> :type-at <loc>           show the type of expression at <loc>

> :loc-at <loc>             return the location of the identifier at <loc> 

> :all-types                  return a list of all types in the project including

with <loc> = <filename> <line> <col> <end-line> <end-col> <text>

 

Are those functions also part of the coming ghci ? (with some different names ? (according to 1))

if so, are those function properly giving the type of the smallest enclosing code expression

like that: (grey is <loc>, blue is closest enclosing expression)

Best,

[Takenobu Tani]

Hi Richard,

I like your decision and plan.

Thank you a lot of work, for community.

About new command name for (1): 

Most users, perhaps, have entered the `:t` rather than `:type`.

  ghci> :t  length

In the same way, how about a full name and abbreviation name for (1).

For example, we prepare `:type-default` and `:td`.

  ghci> :td  length

So they don't misunderstand that it is "typedef".

I also like `:type!` and `:types` with Jack :)

  ghci> :t!  length

Regards,

Takenobu