Re: [Kidbasic-devel] Fwd: File access?

[Ian L. <dr...@gm...>]

Ferry,

I've added the file access from your branch with the following changes:

- Removed "mode" support.  I think this will be confusing for kids.
Files are all open read/write.

- Removed error return code.  File errors halt execution with an error
in the text output window.  EOF's returns a blank string, so you can
check for end of file conditions that way.

- All writes are appended to the end of the file, after which file
position is returned to the previous position for reading.  This way
data isn't ever overwritten, but reads still occur sequentially, which
I think will be the most intuitive for new programmers.

I think this will be the easiest method for file I/O for kids.  We
might want to consider a fileClear function to wipe a file clean, so
new data can be written.

I'll be making a new release soon with these new features.  Thanks to
all for the excellent work.  I really appreciate the help with this,
and it's coming along much faster and better than I could do myself.

-Ian



On 11/19/06, Ferry Hendrikx <fer...@gm...> wrote:
> All done and committed to the repository (rev 134). We now have 4 file
> operations:
>
> - int open(string name, string mode)
>   - mode can be one of "read" or "write", defaulting to "read".
>
> - string read()
>   - read one token from the file
>
> - int write(string token)
>   - write one token to the file
>
> - int close()
>   - close the file
>
> Cheers
>
> /Ferry
>
>
> On 11/17/06, Ian Larsen <dr...@gm...> wrote:
> > Let's start with those four, and see if we get requests for others.
> >
> > We can probably just use open, read, write, and close, instead of
> > prepending an "f," since I don't forsee implementing READ and DATA in
> > basic256.
> >
> > -Ian
> >
> >
> >
> > On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> > > I agree, keeping it simple is best.
> > >
> > > We therefore have at least 4 new functions:
> > >
> > >   error = fopen( filename )
> > >   - open the file (for read and write? or separate them out?)
> > >   - return simple true or false
> > >
> > >   token = fread()
> > >   - return the next token in the file
> > >   - ignore line breaks?
> > >
> > >   fwrite( token )
> > >   - write the token to the end of the file
> > >
> > >   fclose()
> > >   - close the file
> > >
> > > Are these 4 enough or do we need any further functions?
> > >
> > > For example:
> > >
> > >   feof  ??
> > >   - way to tell when we've reached the end of the file
> > >
> > >   fseek  ??
> > >   - seek into the file
> > >
> > > Cheers
> > >
> > > /Ferry
> > >
> > >
> > > On 11/17/06, Ian Larsen <dr...@gm...> wrote:
> > >
> > > > I think supporting one open file (at a time) would be plenty for our
> > > > purposes, and would make implementation a bit easier.
> > > >
> > > > Instead of reading characters though, I think the default function of
> > > > a file read command should be to emulate the input statement, and read
> > > > entire tokens.  That way a kid could type in a file:
> > > >
> > > > 1  aString  2.23  -3  10
> > > > 11  24  Ian  34
> > > >
> > > > and calling read would return 1, then "aString", and so forth.
> > > > We could have the data type default to string for simplicity, counting
> > > > on the programmer to change it to the type he wants with int(), for
> > > > example, or we could attempt to decide what the type is based on the
> > > > token.
> > > >
> > > > My inclination is to return strings only, to keep things simple and predictable.
> > > >
> > > > -Ian
> > > >
> > > >
> > > >
> > > > On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> > > > > I definitely agree that we want to avoid the classic basic approach.
> > > > >
> > > > > The FOPEN (and others) approach is reasonable and we should probably
> > > > > be working at the character level, as dealing with UTF-8 etc would be
> > > > > a real pain...
> > > > >
> > > > > We could take a C-like approach and have a gets(number) function? e.g.
> > > > > returns <number> characters in a string from the currently open file
> > > > > (until end of line?)
> > > > >
> > > > > Hmm.. also, do we want to support one open file or more than one?
> > > > >
> > > > > Cheers
> > > > >
> > > > > /Ferry
> > > > >
> > > > >
> > > > > On 11/17/06, Ian Larsen <dr...@gm...> wrote:
> > > > > > Actually, I haven't given it much thought, but you're right, it would
> > > > > > be good to have that.
> > > > > >
> > > > > > We could have an FOPEN, FREAD, and FWRITE command.  I'm just unsure of
> > > > > > whether they should work at the byte or character level.
> > > > > >
> > > > > > What I usually do is write an example program or tutorial first, and
> > > > > > then code the commands.  It helps to focus on what is actually
> > > > > > necessary to teach kids.
> > > > > >
> > > > > > Traditionally BASIC used READ and DATA statements for data input, but
> > > > > > personally I was never crazy about that approach, most importantly
> > > > > > because I think data should be a separate entity from the program that
> > > > > > reads/alters it.
> > > > > >
> > > > > > The approach that LISP takes for file input is nice.  You can use the
> > > > > > lisp read command on an open file to read a token, or read-line to
> > > > > > read a line.  There's also read-char and read-byte.  This might be the
> > > > > > best way to handle it, so kids can have a text file of data separated
> > > > > > by white space and just read each token in one at a time.
> > > > > >
> > > > > > -Ian
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> > > > > > > Has anyone given any thought to file access? It would be useful to be
> > > > > > > able to open, read and write text files...
> > > > > > >
> > > > > > > Cheers
> > > > > > >
> > > > > > > /Ferry
> > > > > > >
> > > > >
> > >
> >
>