Rob Turner writes:
> Having just learnt about the use of irrefutable patterns for I/O, I
> wish my suspicions about them being a bolted on addition to the
> language for pragmatic reasons to be dispelled. Do irrefutable
> patterns cause any problems mathematically? Does the ability to reason
> (relatively) easily about functional programs disappear when they are
> used?
>
> Rob
Another question: are irrefutable patterns really necessary/good?
IMHO, I can more clearly write my I/O functions without them:
withTildes ^((Str userInput) : ^(Success : _)) =
[ ReadChan stdin,
AppendChan stdout output ]
where
output = someFunction userInput
or, more clearly:
withoutTildes responses =
[ ReadChan stdin,
AppendChan stdout output ]
where
((Str userInput) : resps2) = responses
(Success : _) = resps2
output = someFunction userInput
Reasons why the second version is more clear:
- I don't have to use ^-patterns.
- for a Dialogue function, I can read the function from top to bottom and
see the requests *followed* by the responses, which is normally how I
think about I/O.
- the expected response to a given request is easier to find (especially
if there are many requests).
- in a robust program, the ^-pattern won't contain literal responses like
^(Success : _) since failures have to be handled. Error-handling code
will likely be in the where-clause, so the extraction of the response
might as well be there too.
Using ^-patterns for I/O makes it seem as if I/O is special. In fact,
the following two definitions would suffice quite nicely to describe
how the request- and response-lists are related:
requests = mainUserFunction responses
responses = haskellKernel requests
I wonder if interaction with the system would be easier if a program
could directly use a `haskellKernel' identifier rather than being
restricted to the above relationship.
-- Scott
Scott M. King Thinkage Ltd. Kitchener, Ontario, Canada
[EMAIL PROTECTED] [EMAIL PROTECTED] uunet!thinkage!smking
