Re: Ada standard and maximum line lengths

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 28 Jan 2013 02:02:54 -0800 (PST), Maciej Sobczak wrote:

> W dniu poniedzia�ek, 28 stycznia 2013 09:18:43 UTC+1 u�ytkownik Dmitry A. Kazakov napisa�:
> 
>>> I was reading the Ada 2012 standard and found this, I was just wondering
>>> why there is a maximum line length, it's not like we parse the language a
>>> line at a time.
>> 
>> It is. I always accumulate a whole line before parsing it.
> 
> But it is an implementation detail of your particular parser.

As much as the reverse would be. [I answered because the OP presumed that
no parser does it this way. At least one (mine) does.]

> There is nothing in the concept of parsing itself that would require it.

Actually there is something. It is the backtracking/look-ahead, which
determines how much of the source need to be cached by the parser. One
stream element is usually not enough, at least not sufficient to generate
reasonable error messages. Lines are most natural to determine the
boundaries of backtracking/look-ahead.

>>> Why not just accept it as a stream of tokens and if there
>>> are line breaks, ignore?
>> 
>> For multiple reasons. Specifically regarding Ada, the language has syntax
>> elements bound by the line end, e.g. comments etc.
> 
> There is no problem reading the stream until some token (newline) is
> found. Especially if the whole purpose of reading is to ignore the input,
> as is the case with comments.

That would not ignore line breaks as the OP suggested.

> I do not see anything that would prevent the implementation that accepts
> potentially indefinite line lengths, while still putting arbitrary limits
> on identifiers.

+ limits on the string literal length.

Otherwise, yes, it would be possible to do, though useless. Because other
tools depend on sane line lengths even more than the parser does e.g.
editors, debuggers, documenting, addr2line after all.

> I would not be surprised if the permission to limit is a leftover from the
> ice age of line printers, without any real association with today's
> systems.

Rather the opposite. If lines are the ice arge then unget is Permian.

[ A parser like mine ensures that each lexical element in the focus is
cached. This allows to avoid secondary caches and related overhead. E.g. an
identifier or string literal is not accumulated during parsing. Rather its
starting and end positions are determined and passed further. It is all
in-place until stored. ]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de