Re: "Errors" in PreludeText

[Joe Fasel <jhf@chaco.c3.lanl.gov>]

Original-Via: uk.ac.nsf; Mon, 4 Mar 91 17:46:44 GMT
Date: Mon, 4 Mar 91 10:26:14 MST
From: Joe Fasel <jhf@chaco.c3.lanl.gov>
To: haskell@edu.yale.cs
Subject: Re: "Errors" in PreludeText
Cc: E.Ireland@massey.ac.nz
Original-Sender: jhf <jhf%gov.lanl.c3.chaco@yale.edu>
Sender: haskell-request@cs.glasgow.ac.uk

Last week, Evan Ireland pointed out a bug in PreludeText:  Although
read  is supposed to be a total function, returning an empty list
if it can't parse its string argument, it calls  lex , which can
fail if there is a bad lexeme.  Thanks, Evan.

We discussed this on the Haskell committee list. (This should be the
last time we do this, by the way, since we've now agreed henceforth
to carry on all technical discussions on the haskell list.)  I identified
three ways to fix the bug:

	1)  Change the type of lex to  String -> [(String,String)] .

	2)  Leave lex's type as it is, but but redefine the function
	    so that  lex s  evaluates to  ("",s)  when  s  begins with
	    a bad lexeme.

	3)  Make  lex  a proper lexical analyzer of type
	    String -> (Lexeme,String) where  Lexeme  is an algebraic
	    type whose constructors indicate the different classes
	    of lexemes, including  BadLexeme .

And proposed going with (2), since it seemed to be the minimal change
to the current definitions.  Phil Wadler, however, gave a strong
reason for going with (1):

| I vote for (1) rather than (2).
| This is consistent with the read functions, and makes it easy
| to use the comprehension idiom to deal with possible error returns
| from lex, e.g.,
|
| 	[ ((x,y), s'') | (x,s') <- lex s, (y,s'') <- lex s' ]
|
| to parse two adjacent lexemes.  This is trickier with either
| options (2) or (3).  -- Phil

Since it's probably a bit early in the game to be overly constrained
by upward compatibility, and since most likely most of the uses of
lex  are in the standard prelude anyway, we'll go with (1).  Phil's
argument, by the way, convinces me that even if we should later
consider a more elaborate  lex  like (3), we should not include a 
BadLexeme constructor, but rather, make the type of  lex
String -> [(Lexeme,String)] .

Thanks again, Evan, for noticing the problem.

--Joe