On Jan 21, 2008 9:15 PM, Alexander Dunlap wrote:

On Jan 21, 2008 9:00 PM, Sterling Clover 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 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@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