Readline read_history and write_history addition

Alexander Dunlap alexander.dunlap at gmail.com
Tue Jan 22 00:17:05 EST 2008


On Jan 21, 2008 9:15 PM, Alexander Dunlap <alexander.dunlap at gmail.com> wrote:
>
> On Jan 21, 2008 9:00 PM, Sterling Clover <s.clover at gmail.com> wrote:
> > It seems to me that the proper solution would be to throw the proper
> > exception for the errno, warning of such an exception clearly in the
> > documentation. If the user of the library wants to swallow the
> > exception themselves and continue with a catch or bracket statement,
> > they should have that option, but they should also have the
> > flexibility to handle exceptions in a particular way, should they
> > need that functionality. There's no reason a library binding should
> > conceal any potentially useful functionality of the underlying
> > library. If the errors that were returned were unique, Either String
> > Bool might be an option, but as we've got a built-in standard for
> > handling precisely the sorts of IO errors that are returned, it seems
> > silly not to use it.
> >
> > --S
> >
> > On Jan 21, 2008, at 11:34 PM, Alexander Dunlap wrote:
> >
> > > On Jan 21, 2008 10:27 AM, Judah Jacobson <judah.jacobson at gmail.com>
> > > wrote:
> > >>
> >
> > >> One more suggestion, from Robert Dockins (author of the Shellac and
> > >> Shellac-readline packages):
> > >>
> > >>> The only concern I have is that this patch doesn't seem to
> > >>> be handling errors properly.  read_history and write_history
> > >>> should return
> > >>> errno, but this binding has them returning ().  These functions
> > >>> do file
> > >>> operations and therefore can fail; we want (be able) to know when
> > >>> that
> > >>> happens.
> > >>
> > >> I think we should just throw an error if those functions return a
> > >> nonzero value; for example, we already do that in the functions
> > >> readInitFile and parseAndBind.
> > >>
> > >> Thanks,
> > >> -Judah
> > >>
> > >
> > > I'm reluctant to use the throw an error solution because these
> > > functions failing does not have to be the end of the world (or even
> > > necessarily handled by the application). If the history file can't be
> > > found, the user just doesn't get their history restored (in fact, this
> > > may not even be a problem: if the user hasn't used the application
> > > before, readHistory will fail silently on the first run and then work
> > > fine after the history has been saved at the end of the first
> > > session). Similarly, writing or appending to the history file is
> > > generally not an essential task and can fail without terminating the
> > > program. (I know there's catch, but I don't think the programmer even
> > > has to worry about it that much.) I think that just returning a value
> > > for success and a value for failure would be appropriate.
> > >
> > > However, I'm not sure how we would implement it without using error.
> > > The usual Haskell solution would be to use Maybe, but what would we
> > > have Just of, since the functions don't return real values? Is Just ()
> > > an accepted idiom? (I've never seen it, but I haven't seen all the
> > > Haskell there is to see, either.)
> > >
> > > Thanks.
> > > Alex
> > > _______________________________________________
> > > Libraries mailing list
> > > Libraries at haskell.org
> > > http://www.haskell.org/mailman/listinfo/libraries
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >
>
> Okay, I was unaware that that was the accepted way to handle errors
> for IO operations. If that's the standard, I guess we ought to follow
> it. Attached is a revised patch, including the requested
> historyMaxEntries function and a couple others for completeness.
>
> Alex

Sorry. I forgot to attach the patch. Here it is.

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: readline-2053-history-4.patch
Type: application/octet-stream
Size: 9415 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/libraries/attachments/20080121/4010fe58/readline-2053-history-4-0001.obj


More information about the Libraries mailing list