"Huw Collingbourne" <huw / DELTHISBITdarkneon.com> writes:

> Can you clarify what you mean by semantic highlighting? I'd be interested to 
> see a concrete example of Ruby code to show how this might be useful.
>
> As for the ideal that Ruby code should be short and sweet. I am very much of 
> that opinion too. In fact, however, if you look through many of the widely 
> used libraries used with Ruby you'll find that this ideal is rarely 
> achieved. Single methods taking tens or hundreds of lines of code are 
> commonplace. Contrast the Smalltalk class library (average method length 7 
> lines).
>
> We are working on some ideas which should assist Ruby programmers to 
> structure their code into smaller blocks at the moment. Semantic 
> highlighting has not, thusfar, been an idea we've considered. But if it 
> seems useful, please help me to understand why ;-)
>

I'll try to clarify what I mean. However, from the start I should clearly state
I'm very much a ruby novice. I've been looking at the language for the past
couple of months and really like it. However, to date, all I've done is some
fairly simple scripts to analyse some fairly large log files. 

The comments I made were mainly general rather than specific to ruby, so its
difficult to show some concrete examples, but I have seen some posts to this
list from people having problems getting code to work which I think would
benefit from semantic highlighting. 

I use syntactic highlighting and really appreciate it. I'm a blind user and use
emacs together with a package called emacspeak, which provides speech feedback
(text-to-speech). One of the unique things about this setup compared to
standard screen readers is that it uses 'voice-locking', which is a
voice/speech equivalent to syntax highlighting. Different syntactic elements
are spoken in different voices or with different pitch etc. The system also
uses tones to indicate indent levels and 'auditory icons' to indicate other
aspects of the code or operations being performed to provide more
clues/feedback. This has given me an increased awareness of the benefits of
other forms of clues/feedback regarding what is going on. (I've only been a
blind programmer for about 11 years - prior to that I used VI and was only just
beginning to take advantage of things like syntax highlighting).

The main languages I program in are perl, lisp (CL and elisp), plsql, java, Tcl
and C (but rarely these days!) and now, when I have time to do so, some ruby.  

Probably the most obvious benefit of semantic highlighting is the ability to
highlight code to show scope information. I've seen a couple of posts to this
list where people have had problems with getting their code to work because the
variable they are assigning to is not in the scope they thought it was. Syntax
highlighting only tells you if the bit of code is syntactically correct, it
knows nothing about scope. In a simlar vain, I've seen posts where users have
been concerned about performance and the solution was to modify the code to
prevent large objects or variables from being re-created each iteration through
a loop etc. I'm not sure how we would do the highlighting to indicate such
things as this, possibly greying out items that are not in scope relative to
the current cursor position or something similar. Likewise with complex
conditional tests - users seem to often get confused and introduce subtle bugs
because the logic of their tests is not what they think it is. Again, how to
represent this with highlighting or other techniques would take some thought
and probably trial and error. 

The way I see it is that semantic analysis has started to add additional help
for programmers by doing things like providing symbol lookup that only lists
symbols that are valid at that point in the code (rather than the less
sophisticated 'tag' style approach which lists all known symbols, regardless of
whether they are valid at that point in the code). So, we now have environments
that can warn us about incorrect syntax and provide quick lookups for valid
symbols. The next ogical step would be to provide more feedback concerning the
interpretation of the code - what is in scope, operator precedence, possibly
visual representation of data structure/object relationships and where the
current values are in relation to each other at the current point in the source
etc. 

The problem I see with this kind of support, apart from the basic mechanics of
how to adequately provide meaningful visual clues, is that you wold need at
least a parser for each language you use in the IDE. Furthermore, this parsing
would need to be quite fast and some scheme would be needed to work out when to
parse and how to parse only partially completed constructs without going off
the rails etc. Its a non-trivial problem, but one I think we will see mature as
we look for better development environments that will make us more productive. 

Tim
-- 
tcross (at) rapttech dot com dot au