"Errors" in PreludeText

[E.Ireland@massey.ac.nz]

Original-Via: uk.ac.nsf; Fri, 15 Feb 91 00:40:15 GMT
Date: Fri, 15 Feb 91 12:40:22 NZD
From: E.Ireland@massey.ac.nz
To: haskell@cs.glasgow.ac.uk
Subject: "Errors" in PreludeText
Sender: haskell-request@cs.glasgow.ac.uk

Hi,

I am somewhat concerned with the "read" functions in PreludeText, in
that there appears to be no mechanism for recognising and/or
recovering from bad lexemes.  The problem is that I might want to
prompt a user to enter a value in (using Haskell lexeme syntax), and
then use the standard functions in PreludeText to parse the value.  If
the user makes, say, a typographical error, my program will probably
be terminated with an error condition.

Some (not all) of the error conditions I refer to are described below:

    function    condition
    --------    ---------
    lex         '\'':u = t match may fail
                also may explicitly generate error "bad character"
    lexDigits   pattern match may fail
    lexEsc      pattern match may fail

If I want to avoid this problem, I must essentially duplicate the code
in PreludeText, with different function names, this time allowing for
recognition of bad lexemes.  I will also have to hand code read
functions which I would like the compiler to have automatically
derived.

******************* Suggested solutions (for Haskell 2) ***********************

(1) Add manipulable error values to the language.  This is my second
    best suggestion.

(2) Define a new type constructor, Read (and pardon the overloaded
    identifier, I think ReadError is already used):

        data Read a = Read a | ReadError String

    Change type ReadS:

        type ReadS a = String -> [(Read a, String)]

    Change quite a few of the "read" functions:

        Returning (Read x, s) indicates that x was successfully read and
        s is the unparsed text following.  Currently (x, s) would be used.

        Returning (ReadError x, s) indicates that lexical error "x"
        was detected, and s is the unparsed text following.

    The function named "read" could then be rewritten as:

	read s = x where [x] = [x | (Read x, t) <- reads s ...

    That is, you could use read when you don't care about the error
    conditions, and use reads when you want to play it safe.

*******************************************************************************

Comments please!  This is a serious suggestion.

-------------------------------------------------------------------------------
E.Ireland@massey.ac.nz          Evan Ireland, School of Information Sciences,
  (063) 69-099 x8541          Massey University, Palmerston North, New Zealand.