Issue 63 in teyjus: Readterm parsing (related to 2 prec issues)

[tey...@googlecode.com]

Status: New
Owner: ----

New issue 63 by uaz...@gmail.com: Readterm parsing (related to 2 prec
issues)
http://code.google.com/p/teyjus/issues/detail?id=63

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.

[tey...@googlecode.com]

Updates:
Status: Started
Owner: fafo...@gmail.com
Cc: dale.a.m...@gmail.com

Comment #1 on issue 63 by fafo...@gmail.com: Readterm parsing (related to
2 prec issues)
https://code.google.com/p/teyjus/issues/detail?id=63

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?

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[tey...@googlecode.com]

Updates:
Cc: gopalan....@gmail.com

Comment #2 on issue 63 by dale.a.m...@gmail.com: Readterm parsing (related

to 2 prec issues)
https://code.google.com/p/teyjus/issues/detail?id=63

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.

[tey...@googlecode.com]

Comment #3 on issue 63 by fafo...@gmail.com: Readterm parsing (related to

2 prec issues)
https://code.google.com/p/teyjus/issues/detail?id=63

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.