Re: gets ambiguity and enum suggestion

[Jonathan Bachrach <jrb@xxxxxxxxxx>]

Smelly Pooh <plop+goo@redbrick.dcu.ie> writes:

> In reply to Jonathan Bachrach's flatulent wordings, 
> > Smelly Pooh <plop+goo@redbrick.dcu.ie> 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

smelly,

i agree with you.  i'm open to changing this...

it seems like multiple values is a better version of this.  i'm not
sure goo's tuple version of this makes this a bunch more convenient.
this is where the eof value should be an optional return value.

putting the newline in the string will work out half the time,
depending on whether it's needed for the consumer.  i'm wondering what
people usually find.  perhaps this is the best solution.

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

i like this a bit better, although perhaps another solution is to
offer multiple interfaces.  for example, i offer ``elt'' or ``elt-or''
for collection access, where one raises a condition and the other
provides a default value to return when a key is not found.

this all rather nicely parallels your comments on enumerators.  i'll
get to responding to that next.

i must think about this more and hopefully other people will voice
their opinions.

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

good eye.  i'll fix this now.

jonathan