Contextualizing keywords

[Jarrett Billingsley]

On Mon, Aug 3, 2009 at 12:00 AM, Ary Borenszweig<ary at esperanto.org.ar> wrote:
> Jarrett Billingsley escribió:
>>
>> On Sun, Aug 2, 2009 at 9:30 PM, Walter Bright<newshound1 at digitalmars.com>
>> wrote:
>>>
>>> Chad J wrote:
>>>>
>>>> This makes things more difficult for syntax highlighters.  A number of
>>>> them will just not work correctly because they don't actually parse the
>>>> code.
>>>
>>> That's true. Another thing keywords provide are "anchors" that enable
>>> better
>>> error recovery.
>>
>> I've often wondered about how useful parser recovery really is.  Most
>> of the time, parsing errors after the first are complete bull anyway,
>> so the compiler's just filling up my console with garbage.  If you
>> combine that with the fact that recompiles are extremely cheap with D
>> and modern machines, and that D's module organization limits the scope
>> of parsing errors to a single file (instead of with C/C++, where a
>> parsing error in a header can cascade into a number of following
>> headers and the source), I wonder how useful it really is to continue
>> to try to parse after the first error.
>
> At least it's useful in an IDE, because it doesn't break your outline,
> autocompletion can still work, etc. So I'm glad DMD's parser has error
> recovery. :-)

Why would you care about that?  ;)

> What I don't like is that one semantic error leads to five other semantic
> errors, and it's hard to track what the problem really is.

All compiler error recovery is bound to give some (or several) false
positives.  At least with semantic errors, the errors are localized
within a single class, function, brace block, or expression, and it's
much easier to recover from them.  Parsing errors are much more
difficult to recover from, since you can't really make any assumptions
about what comes next when you read some malformed code; and as a
result, the false positive rate on subsequent parsing errors is much
higher.