<br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Wed, Oct 18, 2006 at 04:42:00PM +0100, Simon Marlow wrote:<br>> So you won't be able to colour patterns differently from expressions, that
<br>> doesn't seem any worse than the context vs. type issue. Indeed, I'm not<br>> even sure you can colour types vs. values properly, look at this:<br>><br>> data T = C [Int]<br>><br>> at this point, is C a constructor? What if I continue the declaration like
<br>> this:<br>><br>> data T = C [Int] `F`</blockquote><div><br>Haskell is easier than Java in this type of situation because Haskell's VARID and CONID are the same whereas Java's VARID and CONID are lexically equivalent. Modern Java IDE's color them correctly by doing (at least) two passes of highlighting: one during lexing and one after renaming/typechecking. As a result, they color identifiers based on lots of semantic information including their scope, visibility, and other factors. IntelliJ will even do data flow analsys to color an identifier differently within a single method depending on whether or not the variable can be null at each occurrence.
<br><br>I think that an editor for Haskell would need to use a similar technique to be useful. For example, I want top-level values colored differently than local values, and I want exported, non-exported, imported, and unbound identifiers highlighted differently. And, I want parameters to be highlighted based on their strictness (determined automatically). This cannot generally be done until the entire module (as well as all of the modules it depends on) have been parsed.
<br><br>In summary, I think that doing any syntax highlighting or other analysis of a Haskell module before it has gone through the renaming phase is a dead end.<br><br>Regards,<br>Brian<br></div></div>