Readterm parsing (related to 2 prec issues)

[GoogleCodeExporter]

readterm generates an error when reading a \n or a space. 

reading 
term (X). 
with a space after the dot generates an error.
reading 

term (X).

term (X2).

With a \n between the two also generates an error.

Original issue reported on code.google.com by uaz...@gmail.com on 4 Jul 2012 at 7:58

[GoogleCodeExporter]

Hi!

I'm currently working on this issue and would like your opinion.

The first issues with space is clearly a bug with one simple answer.
However for the \n problem, it's not possible to just skip any blank (space, 
tab, newline) because we want to be able to read this kind of things:
========
this my first term
term(X).

this is my second term
term(Y).
===================
In this case you would like to alternate between input_line and readterm and 
you don't want readterm to do too much.

My proposition for the behavior of readterm is the following:
If readterm meets a dot and there are only spaces and tabs followed by a 
newline, then place the cursor to the beginning of the next line.
Otherwise, don't move it. That would allow to read several terms on the same 
line separated by spaces. In this case, spaces would be consumed befored 
reading the term.

What do you think? Is it simple and flexible enough?

Original comment by fafounet@gmail.com on 29 Jan 2015 at 1:53

• Changed state: Started

[GoogleCodeExporter]

Responding to you proposal:

"My proposition for the behavior of readterm is the following: If readterm 
meets a dot and there are only spaces and tabs followed by a newline, then 
place the cursor to the beginning of the next line.  Otherwise, don't move it. 
That would allow to read several terms on the same line separated by spaces. In 
this case, spaces would be consumed before reading the term."

Under this proposal, the following two files would yield the same readterm 
series of results:
==================
a1. a2. a3.
a4.
==================
a1.
a2.
a3.
a4.
==================
I think that this is a good solution.  I note, however, that this is a change 
to the current behavior (that is, this is not just a bug fix).  Consider the 
following exchange with tjsim:

[toplevel] ?- readterm std_in X, readterm std_in Y.
 1. 2. 
3.

The answer substitution:
Y = 3
X = 1

That is, the "2." is dropped.

Frankly, I'm fine with this proposed change.  I would be good to also hear from 
Gopalan.

Original comment by dale.a.m...@gmail.com on 29 Jan 2015 at 2:43

[GoogleCodeExporter]

I agree this is a change and behavior has to be well described. However, unless 
your data were represented as in your example (which would be weird to do so 
since Teyjus ignored everything after the first dot), all existing programs 
should behave in a similar way.

Original comment by fafounet@gmail.com on 29 Jan 2015 at 5:23