On Mon, 4 Aug 2003 23:51:59 +0000 (UTC), A.Sloman@cs.bham.ac.uk wrote:
>On Mon, 4 Aug 2003, Jonathan L Cunningham wrote:
>One problem with the very notion of syntax colouring in pop11 is that
>it's a language with no syntax.
That's not strictly true ...
>To be more precise: the use of macros and syntax words allow almost any
>syntax to be accepted by the compiler (including, of course, the syntax
... that's better: the syntax can be extended. The worst effect of
this is that it is impossible to tell what a piece of code means
without looking at all the other code that has already been compiled.
This is NOT a good thing. It's a feature (as in "this is not a bug,
it's a feature").
>of objectclass, or common lisp, of prolog, of PML, and, modestly,
>poprulebase). It's even more extendable than Common Lisp, which only has
>macros.
Macros are, IMO, to be used sparingly. In Common Lisp, there
are functions for expanding macros. This makes life much easier for
code-manipulation programs. Thinking about it, I realise that you
could defeat this by writing macros with side effects which changed
how the macros got expanded. But that would almost certainly be a
stupid thing to do. It's much easier to write useful macros in pop11
which make life hard for code analysers. This is not an advantage.
I think I'll add that to my "pop11 notes" file -- remove macros from
the language and replace them with something more structured. (I
may get around to it before the end of the millenium. *This*
millennium.)
>That means that hoping for an editor to do syntax checking is hoping for
>the moon, except for toy programs.
I'm forced to agree, except I would rephrase that last bit to "except
for real programs".
However (as Chris Dollin points out in another post) the syntax
colouring does need to be rule driven.
Chris:
Teach the colouring engine the current syntax. It's going to be
rule-driven anyway, right? [For some notion of "rule".]
I would also argue that if you are going to define a new language,
or language extensions, you should do it in a way which is consistent
with the rest of the language.
If you define a new piece of syntax, for example, such that
lvars foo;
is no longer a variable declaration, then you are doing something
bad. If you are defining a new language, in which
lvars foo;
is not legal syntax, then of course you'll break the syntax
colouring, just as if I look at pop11 code in an editor using C++
colouring (or HTML colouring) it won't make sense. Why should it?
>But I accept that something like syntax colouring could be useful
>for novices.
It's useful for non-novices too. It woudl be parcitularly useful
for poeple with midl dyslexia, if for xeample they tyepd a
proceedure like this:
define rhubarb();
lvars my_pointy_hat = "foo";
rhubarb_and_custard();
things_and_stuff(my_pionty_hat);
endefine;
They would (a) see that the argument to things_and_stuff is not
declared in the scope of the procedure (my version of a syntax
colourer keeps track of variable declarations) and (b) show that
they had mistyped the "enddefine" at the end.
If you spotted *both* of those instantly, then you've trained your
visual system to do a lot of the work, and would take a while to
relax enough to concentrate on the code, instead of the syntax, if
you had syntax colouring.
Note: with syntax colouring you would *see* the errors *even if you
didn't read the example*!
>Here is a trivial way to do it which will work just as well for
>colour-blind people as for those with normal sight, and just as well no
>inverse video as normal video:
>
>(a) define upper-case synonyms for all the main syntax words, e.g.
>IF THEN ELSE DEFINE UNLESS FOR BY FROM etc. and all the closing
>brackets.
I think this could be a useful option. It would be interesting to
experiment with it.
>A utility for decapitating all the syntax words could be provided.
You'd then need to define decapitated upper-case synonyms too, so
you probably want utilities to decapitalise as well. I suppose a
decapitated 8 would look like an o.
>The only problem that leaves is detecting whether you are in a list, or
>vector expression, or string, or quoted word, and in that case deciding
>whether to capitalise or not.
It needs to be done "properly" for some value of properly. Essentially
the whole file needs to be parsed. However, combining some of the
ideas already posted (cacheing, making it an extensible rule-driven
system, accessing compiler state (e.g. looking at the item_chartype,
rather than duplicating this in the colourer's lexical analyser etc.)
make this doable.
And make it doable, on modern machines, fast enough to be done every
keystroke.
>It's impossible to tell if you are in a string expression without going
>all the way back to the beginning of the file!
So? Is that a problem?
Note also that we are not compiling code. It doesn't *matter* if the
syntax colouring is sometimes "wrong" -- e.g. you have an autoloadable
syntax word in a library you haven't loaded yet -- because it doesn't
affect anything else. (It might encourage you to load the relevant
library, but I don't regard that as a show-stopping problem.)
Jonathan
--
(To e-mail me, replace spam by jlc in the e-ddress)
|