Re: not X'Length

[Manuel Collado <m.collado@fi.upm.es>]

Adam Beneschan escribi�:
> On May 15, 1:48 pm, Georg Bauhaus <see.reply...@maps.futureapps.de>
> wrote:
>> christoph.gr...@eurocopter.com wrote:
>>> From RM 4.4 follows that this is equivalent to

>>> if (not X'Length) in Positive then

>>> Now Universal_Integer (X'Length is of this type) has no operators, so
>>> it has to be converted to an appropriate type. This is Integer (or, to
>>> be very precise, the type of Integer) in this case. But then there is
>>> no "not" defined for this type. So the compiler is correct.

>> While the compilers are correct, on the programmer's part the
>> issue is not that easy to understand in general.
>> You have demonstrated why this is so. Hence my original
>> question about programmer expectations regarding improved
>> compiler's diagnostics in this case.
> 
> You may be right that a better diagnostic would help in this specific
> case.  But a programmer cannot expect a compiler to be a mind-reader.
> And a compiler writer can't really go through every possible weird
> combination of things to figure out what sorts of accidental trouble a
> programmer could get themselves into---there are just too many
> possibilities.  About all a compiler writer can do is respond to
> particular situations when they get noticed.

Perhaps the compiler could state how the expression is parsed, so the 
diagnostic message can be better understood:

    if not X'Length in Positive then
                    |
    >>> incompatible types: parsed as
    >>> if (not X'Length) in Positive then

Just my 2c.
-- 
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado