From isaacdupree at charter.net  Tue Aug  7 17:08:57 2007
From: isaacdupree at charter.net (Isaac Dupree)
Date: Tue Aug  7 17:10:38 2007
Subject: default for quotRem in terms of divMod?
Message-ID: <46B8DF69.70103@charter.net>

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
From isaacdupree at charter.net  Wed Aug  8 14:45:05 2007
From: isaacdupree at charter.net (Isaac Dupree)
Date: Wed Aug  8 14:47:05 2007
Subject: default for quotRem in terms of divMod?
Message-ID: <46BA0F31.8000904@charter.net>

(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.

I second that this is a problem.  However, I think that compilers are 
perfectly justified in replacing nontermination with a runtime 
error(i.e. exception - the generalization of a call to "error"), and 
also generating warnings when it's unimplemented class methods, and we 
could solve it that way.  I don't know how hard it is to detect 
automatically that two default definitions produce a useless loop... if 
that's too hard, possibly some explicit annotation in the code could be 
done (Already there is an informal convention of saying exactly what 
methods must be implemented, so that should be formalize-able...).  I 
_think_ that for Eq and my Integral proposal, GHC's strictness analyser 
is quite up to the task.

In general, what do we think about replacing certain nontermination with 
an exception, particularly by the compiler's detection? GHC already does 
it very unreliably with the <<loop>> low-level thunk 
something-or-other....  It might be interesting to see how many spurious 
warnings would be generated, if GHC also generated a warning for each - 
i.e. is nontermination ever intentionally used as a _|_ normally?

Isaac

From isaacdupree at charter.net  Wed Aug 15 18:48:09 2007
From: isaacdupree at charter.net (Isaac Dupree)
Date: Wed Aug 15 18:40:03 2007
Subject: Qualified identifiers opinion
Message-ID: <46C382A9.5010107@charter.net>


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...

Well, that's my humble opinion on what should go into Haskell' on this 
issue.

Isaac
From isaacdupree at charter.net  Fri Aug 17 16:48:18 2007
From: isaacdupree at charter.net (Isaac Dupree)
Date: Fri Aug 17 16:40:32 2007
Subject: Qualified identifiers opinion
In-Reply-To: <46C57E17.5030900@dfki.de>
References: <46C382A9.5010107@charter.net> <46C57E17.5030900@dfki.de>
Message-ID: <46C60992.5010503@charter.net>

Christian Maeder wrote:
> Hi Isaac,
> 
> just to give you a reply at all, see below. I reply
> glasgow-haskell-users@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 
@class, @whatever...).

> 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.)
> 
> 4. However, "Foo.where" should always be rejected and not changed to
> "Foo.wher e"! (Longest matching, aka "maximal munch", must not consider
> keywords!)
> 
> (see end of: http://www.haskell.org/onlinelibrary/lexemes.html#sect2.4)
> 
> I would not mind if a name "F. " is plainly rejected. It only makes
> sense, when a data constructor is the first argument of the composition
> operator "(.)"

I wouldn't mind if that was banned either. That case needs to be 
considered for implementing my lexer. In fact, banning that and 
qualified keywords allows the lexer proper not to know keywords and 
nevertheless ban qualified keywords (a bit of a hack).  But... while I 
wouldn't _recommend_ using qualified keywords, and compilers could give 
a warning even for haskell98 code that uses known 
extension-keyword-names at all, it seems best to me, to _allow_ them, in 
the interests of allowing code to remain fairly stable with the 
potential of extensions being developed (especially thinking of the 
BangPatterns that had an effect on existing definitions of (!) ).

> 
> Maybe "." and "$" as operators should require white spaces on both
> sides, since "$(" also indicates template haskell.

but it's so convenient as it is... plenty of code uses (.) without 
spaces, and I don't like the way template-haskell steals "$(" and "$id" 
(from the point of view of a person who has never tried to use 
template-haskell).

I think haskell is more stable by allowing existing code e.g.
(f = fix (\rec -> .... rec ....) --'rec' is arrow-sugar keyword
than banning some bunch of new keyword names.  And allowing interim 
interoperability with old code that exports those names, like the 
unfortunate (!) or (.) (I know, those aren't exactly ever keywords/syms) 
seems like a good idea when it removes complexity rather than adding it. 
    I don't want Haskell98 to become a language that has difficulty 
interoperating with libraries and using-applications that use newer 
Haskells.

from other comments:
>> What's wrong with the status quo?  Our current lexical rules *seem*
>> complicated to newbies, but just like everything else in Haskell it carries
>> a deep simplicity; having only one rule (maximal-munch) gives a certain
>> elegance that the proposals all lack.
>> 
>> I'd hate to see Haskell become complex all the way down just to fix a few
>> corner cases; I see this pattern of simplicity degerating through
>> well-intentioned attempts to fix things all over the language...
> 
> I agree with Stefan, for the reasons he stated and for one additional
> reason:  There would be a multitude of unintended behavior changes.

Well, GHC doesn't implement aforementioned maximal-munch re: keywords. I 
don't think it's good (compositional?) design for the set of keywords to 
be part of the lexer rather than a pass after it, when keywords behave 
so similarly to other words, and also when there are non-keywords like 
"as" and "qualified" and sometimes "forall" (whose non-reserved status I 
support).
lex --> keywords --> layout --> parse
Besides, I don't think any of the above proposals will generate behavior 
changes in real code. Some cause more errors (adding more keywords; 
banning adjacent '.' or '$') and some allow a few more things that were 
errors before.
f = Just.let x = x in id  --a.k.a. f = Just
would break in my proposal, but it also breaks according to Haskell98...


Isaac
From isaacdupree at charter.net  Sat Aug 18 07:00:10 2007
From: isaacdupree at charter.net (Isaac Dupree)
Date: Sat Aug 18 06:52:31 2007
Subject: Qualified identifiers opinion
In-Reply-To: <46C57E17.5030900@dfki.de>
References: <46C382A9.5010107@charter.net> <46C57E17.5030900@dfki.de>
Message-ID: <46C6D13A.5030409@charter.net>

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.

Either "f" here works fine, because ":SpecialSyntax" in this module did 
not import "mdo":

 > f = mdo
 > f = B.mdo

Whereas the possibilities with "foreign"...

 > g = foreign --error, ambiguous!!!!
 > foreign import ccall ........ --error, ambiguous!!!!
 > g = A.foreign --okay, unambiguous
 > ":SpecialSyntax".foreign import ccall .... -- can't write in Haskell!

Now, if we want to avoid the understandably undesirable matter of 
imports interfering with keywords (after all, keywords can appear before 
the import list is finished, such as "module" "where" and "import"), we 
could tweak the import-conflict rules for this special case. In this 
module where "foreign" is imported from ":SpecialSyntax", the mere 
phrase "import A" could raise an error, as if all imported syntax were 
used (unqualified, as always) in the module.  Whereas, "import qualified 
A" would not.  (and what about "import A hiding ..."?)




By the way, we are lucky that pragmas have their own namespace {-# NAME 
arguments #-}.  But as I mentioned, we lack a namespace for extensions 
that have a semantic impact on the annotated code.  Certain 
preprocessors invent things like {-! !-} ... or add template-haskell 
syntax, or some arbitrary other keywords syntax like "proc...do"... or 
even steal large portions of existing comment syntax (Haddock, which 
isn't even a semantic impact on the code!)

BTW #2: The simpler and less variable the lexer is, the easier it is to 
scan for LANGUAGE pragmas.  That search doesn't need to deal with 
keywords at all. (although it may be popular not to use the usual lexer 
in order to search for those pragmas, I don't know)


Isaac
From isaacdupree at charter.net  Mon Aug 20 07:13:44 2007
From: isaacdupree at charter.net (Isaac Dupree)
Date: Mon Aug 20 07:06:22 2007
Subject: Qualified identifiers opinion
In-Reply-To: <46C96A85.8030403@gmail.com>
References: <46C382A9.5010107@charter.net>
	<46C57E17.5030900@dfki.de>	<20070817184439.GA3189@localhost.localdomain>
	<46C96A85.8030403@gmail.com>
Message-ID: <46C97768.8010806@charter.net>

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
From Christian.Maeder at dfki.de  Fri Aug 24 11:11:49 2007
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Fri Aug 24 11:15:24 2007
Subject: template haskell syntax
Message-ID: <46CEF535.8090108@dfki.de>

Hi,

for haskell prime I suggest to change the stolen syntax
 "[e|", "[p|", "[d|", "[t|"

to [|<letter>| in order to avoid the confusion with list comprehensions.

Cheers Christian
From benjamin.franksen at bessy.de  Fri Aug 24 12:36:45 2007
From: benjamin.franksen at bessy.de (Benjamin Franksen)
Date: Fri Aug 24 12:31:12 2007
Subject: Remember the future
References: <46C5F84F.8020404@btinternet.com>
	<625b74080708171510p19b3c2d1j5722d07dee367d94@mail.gmail.com>
	<625b74080708171543g3945b0cag3bf62ae610e8b016@mail.gmail.com>
	<46C6B6E4.2060704@btinternet.com> <fa6vth$ltc$1@sea.gmane.org>
	<DCA83D5F3861C941808187D4D38787501298ABF98C@EA-EXMSG-C312.europe.corp.microsoft.com>
Message-ID: <fan1eu$ark$1@sea.gmane.org>

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

From tigre11 at bigpond.com  Thu Aug 30 11:19:41 2007
From: tigre11 at bigpond.com (Tim- tigre11)
Date: Wed Aug 29 18:08:41 2007
Subject: hello 
Message-ID: <007d01c7eb19$4eef64d0$0100000a@TimHome>

hello thanks for my new subscription, do I need to pay a fee or is it free to join ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20070830/65cdbbb7/attachment.htm
From ndmitchell at gmail.com  Wed Aug 29 19:34:55 2007
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Wed Aug 29 19:25:43 2007
Subject: hello
In-Reply-To: <007d01c7eb19$4eef64d0$0100000a@TimHome>
References: <007d01c7eb19$4eef64d0$0100000a@TimHome>
Message-ID: <404396ef0708291634q204bcad6o10fffe3c3749453c@mail.gmail.com>

Hi

> hello thanks for my new subscription, do I need to pay a fee or is it free
> to join ?

This is a mailing list. Its totally free, and for the purpose of
discussing future improvements to the Haskell standard. If you just
wait, you'll find interesting discussions flowing into your inbox.  If
you would rather just have general Haskell discussions, then the
haskell-cafe mailing list might be a more appropriate venue.

Thanks

Neil