Re: Space removal from the user input

[Bill Allombert <allomber@math.u-bordeaux.fr>]

On Sat, Sep 15, 2001 at 12:19:39PM +0000, Karim Belabas wrote:
> 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"?
> > 
> 
> 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:-)

Well it is trivial to do, and even to make GP to evaluate syntax tree in place of text
(much faster) but unfortunately,  in the current state of my parser I cannot parse
all GP construct, so it will not be 100% compatible.

For example, I cannot parse automatic concatenation, nested functions definition, etc...


> 
> > 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?

It should not. The GP grammar include a special self-destructing "end of line token" that is
very different from ';',because it ends functions definitions.

? f(x)=print(x)
print(2)

You mean really
{
  f(x)=print(x)
  print(2)
}
and not
{
  f(x)=print(x);print(2)
}
But there is no way after filtering to represent this invisible token...
(it is one of the thing that make the gp2c parser so messy.)

> 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.
>