Re: gets ambiguity and enum suggestion

In reply to Jonathan Bachrach's flatulent wordings, 
> Smelly Pooh <[email protected]> writes:
> 
> > Version .146
> > 
> > The gets method returns an empty string "" whether we're at EOF or
> > reading an empty line, 
> 
> gets is defined to return a <str>.  the protocol is set up to require
> that the user call eof? to disambiguate these cases. 

eof? will have to be called on a character returned by either peek or
get.  When peek is fixed it won't be too bad but it feels less elegant
than other languages where gets doesn't need to be mixed with peek and
get calls.

The solutions I've seen are

1) To return the string with the trailing '\n' character, EOF is then
represented by an empty string, this is the way most people seem to be
doing it

2) Return lines with '\n' stripped as goo currently does, raise an <eof>
condition when the end of the file is reached, this is how the
input_line function works in Ocaml
(http://caml.inria.fr/ocaml/htmlman/libref/Pervasives.html)

> > peek never seems to return EOF and I don't want to mix get with gets
> > calls.
> >
> > There also seems to be a bug when calling peek just before and after EOF
> > is returned by get.  Each time peek is called #\ is returned, then
> > calling get on the port also returns #\ instead of EOF
> 
> i'm not sure why this is from looking at the implementation:
> 
>   src/goo/io/port.goo and src/goo/io/%port.c
> 
> it would seem peek should return ``(eof-object)'' based on its
> ``fgetc'' implementation.  it is merely a wrapper for ``fgetc'' and
> ``ungetc''.  are you running on windows or linux?

I'm running on Linux, however I think I've found the problem in %port.c

P YgooSioSportYPpeek (P s) {
  PCHR c = fgetc((FILE*)YPlu(s)); ungetc((int)c, (FILE*)YPlu(s)); return
  (P)(PINT)c;
  }

The above PCHR should be PINT, the type demotion changes EOF from int -1
(common EOF value) to unsigned char 255