<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 21, 2017, at 12:45 PM, Gracjan Polak <<a href="mailto:gracjanpolak@gmail.com" class="">gracjanpolak@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi all,<div class=""><br class=""></div><div class="">I was thinking about implementing <a href="https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#visible-type-application" class="">@Type syntax</a> highlight for <a href="https://github.com/haskell/haskell-mode" class="">haskell-mode</a> and noticed a rule about spacing required before @-sign.</div></div></div></blockquote><div><br class=""></div><div>Thanks for looking into this!</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">I do not understand where does this rule come from and what does it buy us.</div><div class=""><br class=""></div><div class="">Experimentation shows that @-patterns do not care about spaces at all:</div></div></div></blockquote><div><br class=""></div><div>Quite true.</div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><font face="monospace, monospace" class=""><br class=""></font>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."</div><div class=""><br class=""></div><div class="">As I understand pattern and expression contexts are always separate in Haskell so the part just after 'of course' is not clear to me.</div></div></div></blockquote><div><br class=""></div><div>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:</div><div><br class=""></div><div>foo = do</div><div>  Just x</div><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Can I get an example for "we want to allow type patterns within expression patterns”?</div></div></div></blockquote><div><br class=""></div><div>This is to allow for future expansion of the @Type syntax, to allow usage in patterns. For example we might want</div><div><br class=""></div><div>id :: a -> a</div><div>id @b x = (x :: b)</div><div><br class=""></div><div>where the @b brings b, a scoped type variable, into scope.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">I understand the part "expressions and patterns use the same parser" but then I'd rather file a bug report about this one.</div><div class=""><br class=""></div><div class="">Rationale: I'd rather limit usage for horizontal space to separate tokens on the lexer level.</div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> 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.</div></div></div></blockquote><div><br class=""></div><div>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!</div><div><br class=""></div><div>Richard</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">-- </div><div class="">Gracjan</div><div class=""><br class=""></div></div>
_______________________________________________<br class="">ghc-devs mailing list<br class=""><a href="mailto:ghc-devs@haskell.org" class="">ghc-devs@haskell.org</a><br class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<br class=""></div></blockquote></div><br class=""></body></html>