provide hooks for semantic highlighting

Submitted by Danny Groenewegen on 5 August 2010 at 17:01

One possible way to implement this is to do it similar to error, note and warning markers: except putting a curly red line underneath it, you give it a different color. The API from the developer end can be similar to constraint-errors:

semantic-highlight :
   t@Call(qid, _) -> (t, Color("darkgreen"))
   where not(is-sync)

This paper has a bit of a case for semantic highlighting vs purely syntactic highlighting:

http://www.cs.cmu.edu/~pane/ftp/CMU-CS-96-132.pdf

4-1. Use Signalling to Highlight Important Information

Typographic signalling is a secondary notation that uses color or typographic styles to emphasize
certain ideas or to clarify the organization of the program. Signalling improves comprehension of
the signalled material, at the expense of non-signalled material. [Fitter 1979] cites the principles
of redundant recoding and relevance in good notational schemes: in addition to symbolic information there are perceptual cues, thus both perceptual and symbolic characteristics highlight
important information; but only information that is actually useful to the user is highlighted.

Many environments automatically signal keywords of the language, even though this may not be
the most important information that the reader needs [Baecker 1986]. Instead, the environment
should signal semantically important information, or facilitate the signalling of those items that
the user feels are important [Gellenbeck 1991a]. Secondary notation should be used to improve
access to information that is needed but obscured [Green 1990b]. The user should be informed in
advance about the meaning of the signals. Of course, these signals should be correct and not misleading.

Context of Use: Environment, notation

Justified by: Empirical studies, expert opinion

Examples: Many environments highlight syntactic structures of the language, such as
keywords.

An intelligent environment could use color to highlight semantic information about the program that is less obvious in the syntactic structure, such
as the bindings of identifiers.

In visual languages, all visible symbols are interpreted by the user as relevant, even if they are incidental [Green 1991].
[Baecker 1986] and [Baecker 1990] describe an elaborate automated system that uses graphic design principles to enhance text in C program printouts, in an attempt to make them more readable, understandable, appealing, memorable and maintainable. This system highlights information that the
authors judged to be fundamental, such as: the relationships between comments and the code they discuss; certain tokens such as identifiers; the correct parsing of complex expressions and statements; use of global
variables, which are a frequent source of errors; and unusual flow of control. This system improved readability as measured by performance on a
comprehension test.

Name binding information can be used to do semantic highlighting. For example, the Visual Assist X addin for Visual Studio highlights local variables as bold and stable symbols (definitions from the C++ standard library or .NET class library) as italics. This provides some extra semantic information about the code by just looking at the highlighting. So there definitely are use cases.

Proposed syntax for errors in TS that are not type errors (use annotations, like in the outliner for icons):

Attribute(a, a-ty, a-mu, Derivation(e, derivationType)) :-
  where e : e-ty
	and e-ty == a-ty else error $[Type mismatch: expected [a-ty] got [e-ty] in Derivation] on e //red underline
		
Attribute(a, a-ty, a-mu, Derivation(e, derivationType)) :-
  where e has multiplicity e-mu
	and or a-mu == e-mu else error $[Multiplicity mismatch: expected [a-mu] got [e-mu] in Derivation]{"blue"} on e //blue underline

Functionality first, declarative description next. I would prefer error terms, which could be styled individually, including error messages, colours, etc.

... else error TypeMismatch(a-ty, e-ty) on e
... else error MultiplicityMismatch(a-mu, e-mu) on e

error-message: TypeMismatch(a-ty, e-ty) -> $[Type mismatch: expected [a-ty] got [e-ty] in Derivation]

In general, any kind of highlighting should be customisable by the language user, based on classes of highlightable language elements, specified by the language engineer.