forall and a parse error

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

forall and a parse error

Neil Mitchell
Hi,

I was experimenting with forall and higher rank types briefly, in particular:

x :: [forall a . a]

This is illegal because of:
http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#universal-quantification

Which is fine, however its surprising to compare the error messages:

[forall a . a]
parse error on input `forall'

[(forall a . a)]
    Illegal polymorphic or qualified type: forall a. a
    In the type signature: lst :: [(forall a. a)]

In normal Haskell, I tend to view [x] as equivalent to [(x)] (provided
that x is not a tuple) but in this case it has a different meaning -
albeit both are erronous meanings.

When running the example with Hugs, they both come out as syntax
errors - the first on the forall, the second on the closing square
bracket.

Thanks

Neil
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: forall and a parse error

David House
On 03/07/06, Neil Mitchell <[hidden email]> wrote:
> In normal Haskell, I tend to view [x] as equivalent to [(x)] (provided
> that x is not a tuple) but in this case it has a different meaning -
> albeit both are erronous meanings.

How would tuples make a difference?

--
-David House, [hidden email]
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: forall and a parse error

Neil Mitchell
On 7/3/06, David House <[hidden email]> wrote:
> On 03/07/06, Neil Mitchell <[hidden email]> wrote:
> > In normal Haskell, I tend to view [x] as equivalent to [(x)] (provided
> > that x is not a tuple) but in this case it has a different meaning -
> > albeit both are erronous meanings.
>
> How would tuples make a difference?

[1,2] /= [(1,2)] - the brackets have changed the semantics, because of
the tupling. Haskell has two distinct types of brackets, (x) for
grouping, (x,y) for tupling. For that reason, there is no way to write
the 1 item tuple - despite the fact that some compilers (Yhc/nhc)
define and use it internally.

Thanks

Neil
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: forall and a parse error

Simon Peyton Jones
In reply to this post by Neil Mitchell
It's a parsing infelicity.  (Inside square brackets the parser knows not
to expect a forall, whereas inside round parens it might.)  Perhaps it
should be more accepting in square brackets, and reject later.

Which the current HEAD does -- actually [forall a. a->a] is ok in the
HEAD, see our ICFP06 paper.

Simon

| -----Original Message-----
| From: [hidden email]
[mailto:[hidden email]] On Behalf Of Neil
| Mitchell
| Sent: 03 July 2006 19:44
| To: Haskell Cafe
| Subject: [Haskell-cafe] forall and a parse error
|
| Hi,
|
| I was experimenting with forall and higher rank types briefly, in
particular:
|
| x :: [forall a . a]
|
| This is illegal because of:
|
http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.
html#universal-quantification
|
| Which is fine, however its surprising to compare the error messages:
|
| [forall a . a]
| parse error on input `forall'
|
| [(forall a . a)]
|     Illegal polymorphic or qualified type: forall a. a
|     In the type signature: lst :: [(forall a. a)]
|
| In normal Haskell, I tend to view [x] as equivalent to [(x)] (provided
| that x is not a tuple) but in this case it has a different meaning -
| albeit both are erronous meanings.
|
| When running the example with Hugs, they both come out as syntax
| errors - the first on the forall, the second on the closing square
| bracket.
|
| Thanks
|
| Neil
| _______________________________________________
| Haskell-Cafe mailing list
| [hidden email]
| http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: forall and a parse error

David House
In reply to this post by Neil Mitchell
On 03/07/06, Neil Mitchell <[hidden email]> wrote:
> [1,2] /= [(1,2)]

Ah, I figured we were talking at the type level.

--
-David House, [hidden email]
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: forall and a parse error

Remi Turk
In reply to this post by Simon Peyton Jones
Probably unrelated, but this thread is what triggered it for me.
There is a minor bug in showing impredicative types without
-fglasgow-exts: *hope I got that right*

Prelude> let x = [] :: [forall a. a]

<interactive>:1:23:
    Warning: Accepting non-standard infix type constructor `.'
             Use -fglasgow-exts to avoid this warning
Prelude> :t x
x :: [. (forall a) a]

     ^^^^^^^^^^^^^^^^

When -fglasgow-exts is set it shows what it should:

Prelude> :t x
x :: [forall a. a]

Groetjes, Remi

On Tue, Jul 04, 2006 at 04:55:49PM +0100, Simon Peyton-Jones wrote:

> It's a parsing infelicity.  (Inside square brackets the parser knows not
> to expect a forall, whereas inside round parens it might.)  Perhaps it
> should be more accepting in square brackets, and reject later.
>
> Which the current HEAD does -- actually [forall a. a->a] is ok in the
> HEAD, see our ICFP06 paper.
>
> Simon
>
> | -----Original Message-----
> | From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Neil
> | Mitchell
> | Sent: 03 July 2006 19:44
> | To: Haskell Cafe
> | Subject: [Haskell-cafe] forall and a parse error
> |
> | Hi,
> |
> | I was experimenting with forall and higher rank types briefly, in
> particular:
> |
> | x :: [forall a . a]
> |
> | This is illegal because of:
> |
> http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.
> html#universal-quantification
> |
> | Which is fine, however its surprising to compare the error messages:
> |
> | [forall a . a]
> | parse error on input `forall'
> |
> | [(forall a . a)]
> |     Illegal polymorphic or qualified type: forall a. a
> |     In the type signature: lst :: [(forall a. a)]
> |
> | In normal Haskell, I tend to view [x] as equivalent to [(x)] (provided
> | that x is not a tuple) but in this case it has a different meaning -
> | albeit both are erronous meanings.
> |
> | When running the example with Hugs, they both come out as syntax
> | errors - the first on the forall, the second on the closing square
> | bracket.
> |
> | Thanks
> |
> | Neil
> | _______________________________________________
> | Haskell-Cafe mailing list
> | [hidden email]
> | http://www.haskell.org/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: forall and a parse error

Andres Loeh-2
> Probably unrelated, but this thread is what triggered it for me.
> There is a minor bug in showing impredicative types without
> -fglasgow-exts: *hope I got that right*
>
> Prelude> let x = [] :: [forall a. a]
>
> <interactive>:1:23:
>     Warning: Accepting non-standard infix type constructor `.'
>              Use -fglasgow-exts to avoid this warning
> Prelude> :t x
> x :: [. (forall a) a]
>
>      ^^^^^^^^^^^^^^^^

This is a minor bug, but not the one I think you mean. Look at the
message. GHC says it's accepting the non-standard infix type
constructor called `.' ... So it's really interpreting `.' as an infix
type variable. It is also interpreting `forall' as a type variable, because
without -fglasgow-exts, `forall' is not a keyword, so it's a valid variable
name. So, renaming the `.' to `x' and `forall' to `f', your expression
is equivalent to

Prelude> let x = [] :: [x (f a) a]

and that is type-correct. This is also very close to what GHC prints as
the type, namely

[. (forall a) a]

So GHC decides to put `.' in prefix position, which is ok also for infix
type operators, but you have to put them in parentheses for GHC to re-accept
the type, so the bug is that GHC should really print

[(.) (forall a) a]

as type of `x'.

Cheers,
  Andres
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe