Re: Space removal from the user input

[Karim Belabas <Karim.Belabas@math.u-psud.fr>]

On Wed, 5 Sep 2001, Ilya Zakharevich wrote:

> a1) When GP/PARI reads something, the output is echoed *after* the
>     whitespace is removed.  Is this intentional, or "it just happens
>     this way"?
> 
> a2) Similarly for the readline's history.  (It contains your's input
>     with whitespace removed.)

It was just easier that way. The one important point was that multiline input
should be remembered as a single line (much easier to modify user functions
this way). For memory efficiency reasons (not such a concern nowadays of
course...), the input multiline is never stored as is: a small buffer is
read, filtered, then concatenated to previous input, until the command is
complete. So the obvious thing to store (or output for that matter) was the
filtered string.

It could be rewritten so as to read all input first, then process a possibly
huge string, but store the unprocessed input. That would be much cleaner in
fact, and actually simplify the code in many places [no need to remember
"filtre" state between invocations, removal of duplicate code].

It is not trivial though: the catch is to determine whether input is complete
or not, and this is hard to do without running the filter (e.g nice things
like { "}" /* } */ } and so on...). One would have to separate the
"preprocessor" (removing comments, block delimiters) from the "filter"
(removing spaces).

Of course, it would all be so much cleaner if the parser would actually
output token lists... (the gp2c compiler does that, but it's not exactly
trivial to merge it either:-)

> b)  When processing multiline-input from readline, \n is removed too
>     agressively.  Example: type 
> 
> 		  print(1)  ^V  ^J  print(2)  ENTER
> 
>     (here ^V and ^J are control-chars).  I see:
> 
>   ? print(1)
>   print(2)
>     ***   unused characters: print(1)print(2)
> 
>     i.e., \n in the input is removed, resulting in a "wrong error".
> 
>     Should not filtre() replace '\n' with ';' when in f_READL mode?

I don't know. 1 ^V^J 2 is definitely not the same as 1; 2 [the former
should store the results "1" and "2" in the history, and output them both;
the latter will disregard "1"].

    Karim.

-- 
Karim Belabas                    email: Karim.Belabas@math.u-psud.fr
Dep. de Mathematiques, Bat. 425
Universite Paris-Sud             Tel: (00 33) 1 69 15 57 48
F-91405 Orsay (France)           Fax: (00 33) 1 69 15 60 19
--
PARI/GP Home Page: http://www.parigp-home.de/