provide hooks for semantic highlighting

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

On 2 September 2010 at 09:54 Zef Hemel commented:

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)

On 15 October 2012 at 19:47 Dobes Vandermeer tagged !dobesv

On 8 January 2013 at 16:58 Gabriël Konat tagged coloring

On 11 January 2013 at 20:17 Dobes Vandermeer commented:

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

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

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.

On 13 January 2013 at 11:03 Gabriël Konat tagged !gohla

On 13 January 2013 at 14:35 Gabriël Konat commented:

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.

On 13 January 2013 at 17:53 Vlad Vergu tagged imp

On 13 January 2013 at 17:53 Vlad Vergu tagged eclipse

On 14 April 2014 at 15:08 Daco Harkes commented:

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

On 14 April 2014 at 20:46 Guido Wachsmuth commented:

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.

On 5 June 2015 at 22:43 Jeff Smits tagged !jeffsmits

Log in to post comments