Re: TextRider bug on last token

["Eric W. Nikitin" <enikitin@apk.net>]

Michael van Acken <KK120y2@mail.lvr.de> wrote:
> Attached is an updated copy of TextRider.Mod, together with its test
> files.  Please check if it fixes your problem.

I didn't seem to have the same problem that Ian did (although I don't know
why).  I've tested the updated TextRider, and haven't found any problems
with it (so far).

>     Only remaining problem: InOutTest reports that it processed 4
> lines
>     from ScanTest.dat, although MG's reference file reported 5 lines.
>     Because the last line of the input file has no end of line
> character,
>     this is somehow correct from the point of view of the module's
> code.
> 
> The last point is a little bit annoying.  Questions to the original
> author of TextRider: Mike, what is the definition of the field
> `Scanner.lines'?  Is the current behaviour correct?  If not, could
> you
> look into this and try to fix it?  


This is correct according to the OOC RM.  From section `Class Scanner
(TextRider)':

    Field: lines-: `LONGINT'
          Total number of lines (i.e., end-of-line characters) that
          have been scanned.  This number is updated by `Scan', or by
          the `SkipSpaces' method when skipping whitespace.


However, this definition may have come about simply because that's how our
Scanners behaved.  OberonF defined this as "Number of lines (line
characters) ... passed by the scanner since being connected," which seems
consistent with OOC's usage.  But, Reiser and Wirth define a `line' field
for Scanner as "the line number of the scanned symbol."  Do we want to
change our current definition?

When testing MvA's changes, I've been trying to make sure that the behavior
matches the descriptions from the RM.  

Ian, this might be something you want to watch for when working on your
portable text i/o library.  Does the OOC RM accurately describe the behavior
of the I/O subsystem?  If not, then one or both of them should be changed.

Eric