XTypeApplication and @spaces
rae at cs.brynmawr.edu
Tue Feb 21 18:55:05 UTC 2017
> On Feb 21, 2017, at 12:45 PM, Gracjan Polak <gracjanpolak at gmail.com> wrote:
> Hi all,
> I was thinking about implementing @Type syntax <https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#visible-type-application> highlight for haskell-mode <https://github.com/haskell/haskell-mode> and noticed a rule about spacing required before @-sign.
Thanks for looking into this!
> I do not understand where does this rule come from and what does it buy us.
> Experimentation shows that @-patterns do not care about spaces at all:
> Comment next to implementation says: "This, of course, conflicts with as-patterns. The conflict arises because expressions and patterns use the same parser, and also because we want to allow type patterns within expression patterns."
> As I understand pattern and expression contexts are always separate in Haskell so the part just after 'of course' is not clear to me.
Sadly, this is not true. We don’t always know whether we’re parsing an expression or a pattern. Specifically, imagine this prefix of a Haskell definition:
foo = do
Is `Just x` the result of `foo`? If so, then `Just x` is an expression. Or is this the beginning of `Just x <- blargh`. If so, then `Just x` is a pattern. We don’t know until we see either a semicolon (possibly inserted by layout rules) or an arrow, which could be arbitrarily far away. So we must have a combined expression/pattern parser.
> Can I get an example for "we want to allow type patterns within expression patterns”?
This is to allow for future expansion of the @Type syntax, to allow usage in patterns. For example we might want
id :: a -> a
id @b x = (x :: b)
where the @b brings b, a scoped type variable, into scope.
> I understand the part "expressions and patterns use the same parser" but then I'd rather file a bug report about this one.
> Rationale: I'd rather limit usage for horizontal space to separate tokens on the lexer level.
With -XTypeApplications, GHC lexes ‘ @‘ and ‘@‘ separately. (Actually, the ‘ @‘ lexeme doesn’t require a space there -- just something that cannot appear in an identifier). As-patterns require the ‘@‘ lexeme, while type applications require the ’ @‘ lexeme. When -XTypeApplications is not turned on, this change in lexer behavior is not enabled.
> This looks like it tries to promote space to separate things on parser level, which is rather hard to get right in crude parsers that we have for syntax highligh, indentation, completion and the like.
This is a really good point, and something we should keep in mind as we continue to tinker with syntax. Perhaps the ghc-proposals process will bring such problems to light sooner. I’m sorry our design decisions here have caused trouble!
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs