Allow type applications to specify type of SPECIALISE pragma

[bgamari]

This describes an extension to the syntax of SPECIALISABLE pragmas, allowing use of type applications instead of an explicit type signature for specifying the specialised type.

Rendered

[bgamari]

Sadly it seems that the .. productionlist directive isn't recognized by GitHub's renderer.

[phadej]

updae

[bgamari]

Thanks!

[phadej]

can we write

foo :: forall a b. (Ord a, Ord b) => Foo a -> Bar b
{-# SPECIALISE forall a. foo @a @a #-}

[bgamari]

Yes, I believe that should be fine. The only question is whether we want to allow the introduction of new constraints, I believe. That being said, I haven't thought terribly hard about what subtleties the forall syntax might introduce.

[goldfirere]

I think @phadej 's forall a. foo @a @a example is quite interesting. When reading the initial proposal, I thought the forall syntax was overkill, instead preferring just to use @_ to indicate unspecialized parameters. I still think @_ should be allowed, but the forall prefix allows more expressiveness, as I now understand.

[Ericson2314]

I might be jumping the gun on https://ghc.haskell.org/trac/ghc/ticket/11350, but doesn't

{-# SPECIALISE \@m -> foldsAndParser @m @() #-}

make more sense? (i.e. [capital] Lambda instead of forall)

[bgamari]

John Ericson notifications@github.com writes:

I might be jumping the gun on https://ghc.haskell.org/trac/ghc/ticket/11350, but doesn't

{-# SPECIALISE \@m -> foldsAndParser @m @() #-}
``
make more sense? (i.e. the Capital Lambda instead of forall) 

Other than the fact that lambda-bound type variables aren't allowed in
normal GHC/Haskell syntax, I suppose this does make a bit more sense.

[rrnewton]

Looks like this sentence is incomplete -- unfinished section?

[rrnewton]

This seems like an interesting proposal. My only concern is this: are specialize pragmas used widely enough, in enough places by enough people, to warrant this improvement in concision?

The counterargument to this objection, IMHO, is that making a little-used feature more complicated only affects users of that feature. People who never write specialize pragmas shouldn't need to know whether this proposal is accepted or not....

[nomeata]

Not much happening here recently. Is this soon going to be put up for discussion, Ben?

[treeowl]

We should carefully consider how this interacts with the idea of value argument specialization, which I know has been discussed somewhere (i.e., specializing to the case where the function is applied to a particular argument). Explicit type lambdas seem to make sense in that regard.

[nomeata]

Due to lack of activity, I am marking this proposal as dormant.

[nomeata]

This has been dormant for a long time. @bgamari, is this abandonned? In that case, please consider closing it.

[nomeata]

Closing due to inactivity, but it can of course be reactivated any time.

[bakhtiyarneyman]

This would come in handy in the presence of AllowAmbiguousTypes extension.

f :: forall a. C a => Int

Using Proxy/Proxy# is a workaround.

[nomeata]

Heh, I just found myself in a situation editing big SPECIALIZE pragmas, and thought “type application would be nice? wasn’t there a proposal? surely it must have gotten accepted, I wonder which version of GHC has it”. Guess were are not there yet.

[Boarders]

I think this would be a nice quality of life improvement and it is worth re-visiting.

[dbeacham]

I'd also love to see this.

Particularly with big SPECIALISE pragmas they're:

1. annoying/error prone to create
2. somewhat obfuscate what I'm wanting to achieve
3. make code incredibly noisy when I want to specialise at multiple types

EDIT: Appears to be a special case of #493 ?

[simonpj]

EDIT: Appears to be a special case of #493 ?

Yes! I'm enthusiastic about #493, but it just needs someone to drive it forward.