Re: gets ambiguity and enum suggestion

I don't think its a good idea to throw an exception to indicate the end of a file or an iterator.

k
At 06:12 PM 11/17/2002, Jonathan Bachrach wrote:
>Smelly Pooh <[email protected]> writes:
>
>> 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
>
>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