Bernard James wrote:
In section 4.4.3 "Function and Pattern Bindings" of the Haskell 98 Report, it gives the following translation:
[ the pattern lambda construction to case expression conversion from the Report]
What does it mean by "semantically equivalent". A rough approximation is "has the same meaning", but that depends on how you define the "meaning".
In the context of code execution, it all boils down to one unique meaning: the result of the execution, i.e., two code fragments inflicting the same environmental (informally "identifier -> variable -> value" mapping and I/O) change are considered semantically equivalent. This is called "operational semantics". One of the (many) advantages of Haskell, being a purely declarative language, is that one can use a more tractable approach: constructs are operationally equivalent if and only if they are substitutable (after proper renaming of variables to avoid incidental name clashes), and can even use a simple calculus in the kernel language (after the compilation you mentioned).
For example:
foo x = show x versus foo = \x -> show x
And, why not the simplest version: "foo = show"... If we call these three versions "foo1", "foo2" and "foo3", then they are semantically equivalent because, besides having the same type, one can substitute one with anyone of the others; if we have the definition g = foo1 "Hello" we can replace "foo1" with either "foo2" or "foo3" and get the exact same behavior (or operational semantics, if you prefer): g = foo2 "Hello"
I think the answer to the question is something like: this rule is intended to translate Haskell into the kernel, but it is not an equivalence that the programmer may (always) use in their own program (ie it is applicable only after type checking).
Semantic equivalence does not necessitate syntactical equivalence (although the opposite implication trivially holds...), if that was your worry. And, no, the programmers need not to worry about this equivalence in most cases, since the transformation is done for us by our friendly Haskell compiler/interpreter. Actually, the Haskell compiler/interpreter does not need to do the conversion at all, as long as the behavior is AS IF the conversion has been done. There are often more efficient ways to do things than to translate into the Haskell kernel language. Semantics (almost) always ignore efficiency issues :-)
I'm not sure where this rule fits into the definition of the language.
And I am not sure I understood your worries, so forgive me if my explanation was out-of-bounds, or trivial. Regards, David