Mon, 23 Jul 2001 11:23:30 -0700, Mark P Jones [EMAIL PROTECTED] pisze:
I guess the intention here is that:
symbol - ascSymbol | uniSymbol_special | _ | : | | '
Right.
In fact, since all the characters in ascSymbol are either
punctuation or symbols in Unicode, the inclusion of
From: Dylan Thurston [EMAIL PROTECTED]
Date: Mon, 23 Jul 2001 19:57:54 -0400
On Mon, Jul 23, 2001 at 06:30:30AM -0700, Simon Peyton-Jones wrote:
Someone else, quoted by Simon, attribution elided by Dylan, wrote:
| 2.2. Identifiers can use small and large Unicode letters.
| What about
3. A precedence table says that case (rightwards) has higher
precedence
than operators and right associativity. If it's meaningful to talk
about precedence of such syntactic constructs as case at all,
it should
probably be told to have a lower precedence, so case x+1 of ...
is valid as
Marcin
Thanks for your careful read. Many of your suggestions I will
implement.
I'll send separate email about any others.
[Haskell mailing list folk: I hope you'll forgive email about the
minutae of the Haskell Report. But I don't want to let changes, or
even clarifications, go by without
Folks
Marcin is right about this. It is inconsistent as it stands.
I propose to delete the sentence The Preldue module
is always available as a qualified import... in the first
para of 5.6.1.
The situation will then be:
if you don't import Prelude explicitly, you implicitly get
| 3. A precedence table says that case (rightwards) has higher
| precedence than operators and right associativity. If it's
| meaningful to talk about precedence of such syntactic
| constructs as case at all, it should probably be told to have
| a lower precedence, so case x+1 of ... is valid
| 2.2. Identifiers can use small and large Unicode letters.
| What about caseless scripts where letters are neither small
| nor large? The description of module Char says: For the
| purposes of Haskell, any alphabetic character which is not
| lower case is treated as upper case (Unicode
Unfortunately both the old and the new situation are not so nice.
Both don't allow a simple translation of Haskell into the Haskell
kernel,
e.g. you cannot translate [1..] into Prelude.enumFrom 1, because the
latter may be ambiguous.
The following remark at the beginning of Section 3 is
Mon, 23 Jul 2001 15:11:32 +0100, Olaf Chitil [EMAIL PROTECTED] pisze:
Both don't allow a simple translation of Haskell into the Haskell
kernel,
e.g. you cannot translate [1..] into Prelude.enumFrom 1, because the
latter may be ambiguous.
That's why I was proposing that importing another
| Unfortunately both the old and the new situation are not so
| nice. Both don't allow a simple translation of Haskell into
| the Haskell kernel, e.g. you cannot translate [1..] into
| Prelude.enumFrom 1, because the latter may be ambiguous.
|
| The following remark at the beginning of
The report is vainly trying to say that, regardless of what is
lexically in scope, the builtin syntax refers to Prelude entities.
Perhaps I should reword the offending paragraph to say:
Free variables and constructors used in these translations
refer to entities defined by the
| 2.2. Identifiers can use small and large Unicode letters ...
If we're picking on the report's handling of Unicode, here's
another minor quibble to add to the list. In describing the
lexical syntax of operator symbols, the report uses:
varsym- (symbol {symbol | :})_reservedop
symbol
On Mon, Jul 23, 2001 at 06:30:30AM -0700, Simon Peyton-Jones wrote:
| 2.2. Identifiers can use small and large Unicode letters.
| What about caseless scripts where letters are neither small
| nor large? The description of module Char says: For the
| purposes of Haskell, any alphabetic
13 matches
Mail list logo