Go versus Brand X

[Robert Kern]

On 2009-11-23 14:47 PM, Antoine Pitrou wrote:
> Le Mon, 23 Nov 2009 11:54:19 -0600, Robert Kern a écrit :
>>
>> Not really. The idea was to make the language easily parsed and lexed
>> and analyzed by *other* tools, not written in Go, that may have limited
>> capabilities.
>
> Well, if Go doesn't allow you to write libraries usable from other low-
> level languages I'm not sure it is a good systems programming language.
> One point of C is that you can bridge it with everything.

That doesn't help tools that are already built with their own capabilities. I 
don't link Python into my editor to get Python syntax highlighting. The easier 
it is to write *a* parser/analyzer for the language in any other programming 
language, the more tools you will get for a broader range of runtime 
environments, particularly constrained environments like editors that may not be 
extensible at all.

>> Vim isn't written in Go and won't be able to use their
>> API, for example.
>
> Syntax highlighting doesn't require a full-blown parser.

Most of the time. FORTRAN does require a full-blown parser if you want to be 
accurate. And the more regular a language is, the more interesting things one 
can do with just the tools that are usually available for syntax highlighting. 
FORTRAN and Go represent two opposite sides of that spectrum.

> You probably
> want to handle three types of events:
> - comments (and docstrings and the like for languages which have them)
> - keywords
> - delimiters of basic syntactical blocks (which most of the time is
> simply matching pairs of parens / square brackets / curly brackets)
 >
> That is, you need a very small part of the information a complete parser
> would give you.
> In particular, you don't need to know about operator precedence. You
> don't need to know about what kind of block you are inside (function,
> method, class...). You don't need to know whether an identifier is a
> local variable, a global variable, a type, etc. You don't even need to
> know the different operators. You only need to recognize the basic
> lexemes and that's all.

You can get away with just that and have something people recognize as syntax 
highlighting, yes. But if it is possible to highlight local variables, globals, 
and types differently, that *is* useful. And you will even see some syntax 
highlighters doing more advanced things like that even for Python (though mostly 
with heuristics).

But note that the more regular the language is, the less you need to rely on a 
full parser, and the more interesting things you can do with just lexing and 
other simpler approaches. That's what they are going for. If I were designing a 
language, that wouldn't be the tradeoff I would make, but they have their own needs.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco