[Haskell-cafe] Re: A better syntax for qualified operators?

Brian Smith brianlsmith at gmail.com
Thu Oct 19 09:51:31 EDT 2006

> On Wed, Oct 18, 2006 at 04:42:00PM +0100, Simon Marlow wrote:
> > So you won't be able to colour patterns differently from expressions,
> that
> > doesn't seem any worse than the context vs. type issue.  Indeed, I'm not
> > even sure you can colour types vs. values properly, look at this:
> >
> >   data T = C [Int]
> >
> > at this point, is C a constructor?  What if I continue the declaration
> like
> > this:
> >
> >   data T = C [Int] `F`

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.

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20061019/21776c5e/attachment.htm

More information about the Haskell-Cafe mailing list