I updated the code on the wiki page: the previous version didn't handle
prefix negation - did you implement that yourself in HLint?
No, I didn't implement prefix negation in HLint - it never came up as
an issue. Perhaps the underlying HSE library dealt with it for me -
Niklas would know.
In
Hi all,
Per request I've made a ticket and proposal page for adding
ExplicitForall to Haskell'2010:
http://hackage.haskell.org/trac/haskell-prime/ticket/133
http://hackage.haskell.org/trac/haskell-prime/wiki/ExplicitForall
Cheers,
/Niklas
___
Discussion period: 2 weeks
Returning to this discussion, I'm surprised that so few people have
actually commented yea or nay. Seems to me though that...
* Some people are clearly in favor of a move in this direction, as
seen both by their replies here and discussion over other channels.
* Others
Alright, let's set an actual discussion period of 2 weeks for
ExplicitForall. If there is no opposition by then, we can add
ExplicitForall to the registered extensions in cabal as a first step.
Slightly more than two weeks later, there has been no voices against
and at least a few in favor.
In other words, in your 2x3 grid of syntactic x expressiveness, I want
the two points corresponding to classic syntax x {existential
quantification, GADTs} to be removed from the language. My second
semi-proposal also makes each of the three points corresponding to the
new cool syntax a
What you suggest would be fine with me. Presumably ExplicitForall would be
implied by RankNTypes and the other extensions?
Yes, that's the idea. Rank2Types, RankNTypes, PolymorphicComponents,
ScopedTypeVariables and LiberalTypeSynonyms would all imply
ExplicitForall.
There is a danger of
Hi all,
(I'm writing this to several lists since it involves GHC
(implementation of extensions), cabal (registration of extensions) and
some future Haskell standard (formalisation of extensions).)
In my quest to implement all known syntactic extensions to Haskell in
my haskell-src-exts package,
I don't think it makes sense to make a special case for requiring spaces
around $, as TH won't be in H'.
I agree, there's absolutely no need to treat $ differently in H'. The
situation will already be better than it is now, since by the special
treatment of . (and - and !, which I also agree
When I first saw this thread, my gut response was Aw gawds no, don't
touch my $ !! I love $, I use it all the time, it really helps making
code more readable and more nicely structured. I would really hate for
someone to take that away from me.
So when I came across this:
This wouldn't work,
An interesting question. What is the goal of Haskell'? Is it to, like
Python 3000, fix warts in the language in an (somewhat) incompatible
way or is it to just standardize current practice? I think we need
both, I just don't know which of the two Haskell' is.
I would hope it is both. Some
it's not refactoring! it's just adding more features - exception
handler, progress indicator, memory pool and so on. actually, code
blocks used as a sort of RAII for Haskell. are you wanna change all
those ';' when you add new variable to your C++ code?
bracketCtrlBreak
I'm very suspicious about the power/weight ratio of this change.
Normally, for simple value-level stuff like this, provide both options:
mapM / forM. = =
So how about, rather than break things, just provide an alternative to ($).
Alright, I'm not sure what the proper channel for doing
On 2/28/06, Ben Rudiak-Gould [EMAIL PROTECTED] wrote:
Simon Peyton-Jones wrote:
- A program that type checks can have its meaning changed by adding an
instance declaration
- Similarly adding import M() can change the meaning of a program (by
changing which instances are visible
-
Claus Reinke wrote:
most of us would be happy if instance contexts
would be required to uniquely determine the instance to be
chosen, a rather conservative extension of current practice.
I'm not so sure about the most of us, as you note yourself the
defaulting pattern is quite popular (and
14 matches
Mail list logo
