In class Integral, divMod has a default in terms of quotRem. (quot,rem,div,mod all have defaults as the both-function they're part of.) I'm sure divMod is more natural than quotRem to implement for some types... so why doesn't quotRem have a default in terms of divMod? it has no default! Then the "minimal to implement" will change from (toInteger and quotRem) to (toInteger and (quotRem or divMod)). Isaac
(something very odd was going on with that reply-to! trying to send this in a sensible way...) Christian Maeder wrote: > > > Isaac Dupree wrote: >> In class Integral, divMod has a default in terms of quotRem. >> (quot,rem,div,mod all have defaults as the both-function they're part >> of.) I'm sure divMod is more natural than quotRem to implement for some >> types... so why doesn't quotRem have a default in terms of divMod? it >> has no default! Then the "minimal to implement" will change from >> (toInteger and quotRem) to (toInteger and (quotRem or divMod)). >> >> Isaac > > while I don't care if quotRem or divMod should be implemented. I oppose > to give both default implementations in terms of the other. > > Already for the class Eq either == or /= must be defined, with the > unpleasant effect that an empty instance like: > > instance Eq T > > leads to a loop (when == or /= is called on elements of type T). > > The empty instance does not even raise a warning about unimplemented > methods (since the default definition is used). > > I'd rather prefer to remove /= as method of Eq.(Continue reading)
Especially after writing a partial lexer for Haskell, I opine that this
should be all legal:
module Foo where
--in case you didn't know, this is legal syntax:
Foo.f = undefined
Foo.mdo = undefined
Foo.where = undefined
x Foo.! y = undefined
x Foo... y = undefined --remember ".." is reserved id, e.g. [2..5]
{-# LANGUAGE RecursiveDo, BangPatterns #-} module Bar where
import Foo
hello !x = mdo { y <- Foo.mdo Foo... ({-Foo.-}f x y); return y }
{- Haskell 98 -} module Baz where
import Foo
goodbye x = x ! 12
(Foo.where) lexing as (Foo.wher e) or (Foo . where) does not make me
happy. (being a lexer error is a little less bad...) Especially not
when the set of keywords is flexible. I don't see any good reason to
forbid declaring keywords as identifiers/operators, since it is
completely unambiguous, removes an extension-dependence from the lexer
and simplifies it (at least the mental lexer); Also I hear that the
Haskell98 lexing is (Foo.wher e), which I'm sure no one relies on...
(Continue reading)
Christian Maeder wrote: > Hi Isaac, > > just to give you a reply at all, see below. I reply > glasgow-haskell-users <at> haskell.org since I'm not subscribed to > haskell-prime. And I don't want to subscribe, because I'm more > interested that Haskell becomes more stable (and standard). Then maybe you can join haskell-prime and provide the energy that rounds up all the little fixes and tries to actually produce the thing! Drastic changes are not intended to go in. Haskell' should bring more stability and standardness (as long as it doesn't diverge too much from Haskell98, which would decrease stability and standardness) > So here is > my opinion: > > 1. The lexer should recognize keywords. > > 2. I would not mind if Haskel98 rejected all keywords that are also > rejected by extensions, so that the lexer is extension independent. > (Starting with Haskell98, removing conflicting identifiers as soon as I > switch on valuable extensions does not make sense.) Trouble is, extensions are just that: extensions, and more with their own keywords may be added in the future! unless we want an internet-standard-like "x-keywordname" - but that doesn't solve this problem: standardized new keyword names clogging up the general namespace, as long as they don't have a symbol (like Objective-C has <at> class, <at> whatever...).(Continue reading)
Christian Maeder wrote:
| 3. I'm against qualified identifiers, with the unqualified part being a
| keyword like "Foo.where". (The choice of qualification should be left to
| the user, usually one is not forced to used qualified names.)
Okay, here's a thought experiment... one may follow along, and agree or
not as one likes (I'm not sure how much I agree with it myself, though
it might be an interesting way to structure a compiler)
> {-# LANGUAGE ForeignFunctionInterface #-}
> module Foo where
Suppose all modules have an implicit, unavoidable
> import ":SpecialSyntax" (module, where, let, [], -- ...
> , foreign --because that extension is enabled
> )
Now let's import some imaginary already-existing modules that use "keywords"
> import A (foreign)
> import B (mdo)
This turns up a problem already: explicitly naming things in an import
or export list might not work unambiguously, because keywords are
sometimes used to mean special things there. Going on... maybe we
imported the whole modules.
According to standard Haskell import rules, there is no conflict until
the ambiguous word is used.
(Continue reading)
Simon Marlow wrote: > I believe the solution we adopted for GHC 6.8.1 (and I proposed for > Haskell') strikes the right balance. > > M.where is lexed as an identifier. This doesn't require adding any > exceptions or corner cases to either the implementation or the > specification of the grammar. It is much easier to implement than the > existing Haskell 98 rule (I deleted 30 lines of code from GHC's lexer to > implement it). It's easy to understand. It removes an opportunity for > obfuscation. It must be the right thing! Now I've found the h'-wiki page http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedIdentifiers I _think_ the change to lexical syntax on that page is the one Simon mentions? and is also the same as what I am supporting? (I am terribly confused about "Foo.f = " though, since I thought I _used_ some code that qualified its definitions that way, and thought it was odd. Maybe it was just referring to the things it defined by e.g. Foo.f (without importing itself), and I was confused, and further confused that definitions then COULDN'T be qualified that way? oh dear...) Isaac
Simon Peyton-Jones wrote: > | It is unfortunate that the [ghc] manual does not give the translation rules, or at > | least the translation for the given example. > > Hmm. OK. I've improved the manual with a URL to the main paper > http://citeseer.ist.psu.edu/erk02recursive.html > which is highly readable. And I've given the translation for the example as you suggest Cool, thanks. BTW, the Haskell' wiki says its adoption status is 'probably no' which I find unfortunate. IMHO recursive do is a /very/ useful and practical feature and the cons listed on http://hackage.haskell.org/trac/haskell-prime/wiki/RecursiveDo don't weigh enough against that. Ok, just my (relatively uninformed) 2 cents. Cheers Ben
Benjamin Franksen wrote: > Simon Peyton-Jones wrote: >> | It is unfortunate that the [ghc] manual does not give the translation > rules, or at >> | least the translation for the given example. >> >> Hmm. OK. I've improved the manual with a URL to the main paper >> http://citeseer.ist.psu.edu/erk02recursive.html >> which is highly readable. And I've given the translation for the example > as you suggest > > Cool, thanks. > > BTW, the Haskell' wiki says its adoption status is 'probably no' which I > find unfortunate. IMHO recursive do is a /very/ useful and practical > feature and the cons listed on > http://hackage.haskell.org/trac/haskell-prime/wiki/RecursiveDo don't weigh > enough against that. Ok, just my (relatively uninformed) 2 cents. > > Cheers > Ben I will assume that the current compilers will keep the current "mdo" desugaring. It is incredibly valuable, and I use it in two different monad stacks in the regex-tdfa package I released. It has been an implemented extension for quite several version of GHC, and with the separate "mdo" keyword it does not interfere with other code. Why have a lazy language with added monad "do" sugaring support and balk at(Continue reading)
_______________________________________________ Haskell-prime mailing list Haskell-prime@... http://www.haskell.org/mailman/listinfo/haskell-prime
RSS Feed31 | |
|---|---|
11 | |
1 | |
21 | |
1 | |
20 | |
14 | |
18 | |
2 | |
10 | |
14 | |
7 | |
8 | |
4 | |
132 | |
34 | |
3 | |
1 | |
11 | |
4 | |
8 | |
65 | |
19 | |
34 | |
19 | |
37 | |
5 | |
25 | |
1 | |
13 | |
1 | |
60 | |
4 | |
19 | |
10 | |
7 | |
74 | |
2 | |
7 | |
19 | |
18 | |
22 | |
55 | |
147 | |
23 | |
2 | |
52 | |
8 | |
22 | |
4 | |
11 | |
12 | |
2 | |
24 | |
1 | |
11 | |
37 | |
224 | |
48 | |
10 | |
5 | |
12 | |
6 | |
11 | |
32 | |
23 | |
40 | |
16 | |
41 | |
85 | |
69 | |
43 | |
113 | |
129 | |
56 | |
67 | |
12 | |
69 | |
304 | |
371 | |
598 | |
218 |
