Hi,
my import lists would look much nicer und could be sorted more easily
if the keyword qualified could be placed before the as keyword
instead of after import.
Therefore I suggest the alternative syntax:
import Data.Map qualified as Map
This should be fairly simple to implement, if more
In case you further want to discuss this, I've re-opened
http://hackage.haskell.org/trac/ghc/ticket/2528#comment:10
So, I'm against your proposal, Cale, but suggest that you revert the
order in your example (if you want to exploit this behavior).
Cheers Christian
Am 08.09.2011 02:07, schrieb
Am 20.09.2011 20:21, schrieb Edward Kmett:
[...]
I would suggest you rephrase this as a formal proposal, then I can
happily vote +1.
Seeing the wonderful interrelation between elem, nub, nubBy and i.e.
unionBy eq xs ys = xs ++ foldl (flip (deleteBy eq)) (nubBy eq ys) xs
intersectBy eq
Looking at the code of nubBy
http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.4.0.0/src/Data-List.html#nubBy
nubBy :: (a - a - Bool) - [a] - [a]
#ifdef USE_REPORT_PRELUDE
nubBy eq [] = []
nubBy eq (x:xs) = x : nubBy eq (filter (\ y - not (eq x
==y || elem x ys
notElem _ []= True
notElem x (y:ys)= x /= y notElem x ys
#endif
So the proposal should be to swap the arguments in x==y and x /= y
(above) which would also fix the nub implementation!
C.
Am 20.09.2011 13:46, schrieb Christian Maeder:
Looking at the old tickets
http
similar in spirit to the -fwarn-tabs warning.
C.
P.S. In the mean time you may use
http://projects.haskell.org/style-scanner/ (Caveat, it crashes on latin1
files when compiled with ghc-6.12 or greater.)
___
Haskell-prime mailing list
Am 07.04.2011 13:09, schrieb Roel van Dijk:
Please take a look at the following file:
http://code.haskell.org/numerals/src/Text/Numeral/Language/ZH.hs
Great, that file made my firefox open infinitely many tabs (so that I
had to close it).
C.
___
Am 07.04.2011 13:09, schrieb Roel van Dijk:
Please take a look at the following file:
http://code.haskell.org/numerals/src/Text/Numeral/Language/ZH.hs
The code would not suffer much if it were pure ASCII. I would prefer
(ascii) haddock links to explain the various code points.
C.
Christian Maeder schrieb:
Ian Lynagh schrieb:
[...]
http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts
I'm for this proposal, although I've got an example where I need this
context, namely for DrIFT to derive a proper context for instances.
DrIFT doesn't know
)
On Tue, Jul 20, 2010 at 10:46, Christian Maeder
christian.mae...@dfki.de mailto:christian.mae...@dfki.de wrote:
Christian Maeder schrieb:
Ian Lynagh schrieb:
[...]
http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts
I'm
Ian Lynagh schrieb:
Hi all,
H98 and H2010 allow a context to be given for datatypes, e.g. the
Eq a in
data Eq a = Foo a = Constr a
I have made a proposal to remove support for that context (ticket #139).
More details are on the proposal wiki page:
) ^ 2.
C.
Atze Dijkstra schrieb:
On 14 Jul, 2010, at 14:22 , Christian Maeder wrote:
Atze Dijkstra schrieb:
Hi,
I prefer the simplicity of
http://hackage.haskell.org/trac/haskell-prime/wiki/NegationBindsTightly
over the more involved proposal.
It's a simple design choice but hard to put
Hi,
the language description contains ~ and @ as reserved:
reservedop → .. | : | :: | = | \ | | | - | - | @ | ~ | =
These operators are only used within patterns.
I see no reason to leave them user-definable and usable within expressions.
The only change in the grammar would be, to disallow
Malcolm Wallace schrieb:
I'm asking for support of:
http://hackage.haskell.org/trac/haskell-prime/wiki/PrefixMinusResolution
Just to note that nhc98 appears to fulfill the outcome of this
resolution algorithm already, with the exception of example x7, which is
parsed as -(4#5).
Because it
Simon Peyton-Jones schrieb:
Yes, I somewhat hacked up the rules for ! in an ad-hoc way. I really wanted
to allow
f !x !y = (x,y)
which meant a bit of fiddling, because LHSs are parsed as terms, so this is
parsed as
(f ! x) ! y
(ie as infix operators) and I have to
.
The difference lies in:
- 1 ^ 2
which is currently (and by my proposal) resolved to - (1 ^ 2) whereas
it would be resolved to (-1) ^ 2 if negation binds tightly.
Christian
Cheers,
Simon
On 12/07/2010 08:40, Christian Maeder wrote:
Hi Simon and other fixity resolution friends
Christian Maeder schrieb:
[...]
Without this restriction polynomials like
- a + - b * x + - c * - x ^ 2
would uniquely resolve to
((- a) + (- (b * x))) + (- (c * (- (x ^ 2
I think hugs handles this correctly!
yes it does this case.
Let us assume a user-defined (non- or) right
Simon Marlow schrieb:
If we changed patterns in the same way as you suggest for expressions
above, then this would become clearer, right?
By this change you would loose the important restriction that - is
only legal to denote negated (integer or float) constants, which would
then move from the
Christian Maeder schrieb:
http://www.haskell.org/~simonmar/haskell-2010-draft-report-2/haskellch10.html#x17-17300010
Fixity resolution also applies to Haskell patterns, but patterns are a
subset of expressions so in what follows we consider only expressions
for simplicity.
I suggest
Simon Marlow schrieb:
The string 1 * - 1 is legal as pattern, but rejected as expression!
Well, it's not a pattern (* is a varop, not a conop), and it's an
illegal funlhs (* has greater precedence than prefix -).
it is legal as funlhs (ghc-6.12.3)!
1 * - 1 = 2
Main 1 Main.* (-1)
2
see
Simon Marlow schrieb:
prefix negation should move to lexp to
be consistent with lpat
prefix negation should not move to lexp, because this would rule out
- 1 ^ 2 as negated infix expression - (1 ^ 2), whereas a negated
infix pattern is impossible. Unary minus is no constructor and cannot be
Simon Marlow schrieb:
[...]
1. - 1 * 1 is accepted as legal pattern, but differently resolved for
expressions! Should one not reject these (rare) patterns, too?
That's the GHC bug, right?
Yes!
2. I would rather allow 1 * - 1 and 1 + - 1 to be legal as
expressions (with its unambiguous
http://www.haskell.org/~simonmar/haskell-2010-draft-report-2/haskellch3.html
infixexp → lexp qop infixexp (infix operator application)
| - infixexp(prefix negation)
| lexp
This grammar rule describes a right associative nesting of (any) infix
operators
http://www.haskell.org/~simonmar/haskell-2010-draft-report-2/haskellch10.html#x17-17300010
Fixity resolution also applies to Haskell patterns, but patterns are a
subset of expressions so in what follows we consider only expressions
for simplicity.
The string 1 * - 1 is legal as pattern, but
Malcolm Wallace schrieb:
In many ways this corresponds to my preferred solution, although I would
rephrase it thus:
* Deprecate use of the base package, (I do not mean to remove base,
just to freeze it, and discourage its general use.)
* Create a new haskell2010 package (for ghc
Nick Bowler schrieb:
*** Idea #2 ***
Similar to #1, except using a generic type instead of Double.
Define a new type, call it FloatConvert, which represents rational plus
other values. Something along the lines of:
data FloatConvert
= FCZero Bool -- Signed zero
|
let me try again to fix the issue. Apologies, if you mind.
Christian Maeder schrieb:
S. Doaitse Swierstra schrieb:
weird :: Int - Int
weird = (if True then 3 else 5+)
is perfectly correct Haskell?
Yes, this is legal according to the grammar
http://haskell.org/onlinereport/syntax-iso.html
S. Doaitse Swierstra schrieb:
weird :: Int - Int
weird = (if True then 3 else 5+)
is perfectly correct Haskell?
Yes, this is legal according to the grammar
http://haskell.org/onlinereport/syntax-iso.html
but rejected by ghc and hugs, because 5+ is illegal.
The problem is to allow let-, if-,
Christian Maeder schrieb:
S. Doaitse Swierstra schrieb:
weird :: Int - Int
weird = (if True then 3 else 5+)
[...]
infixexp - fexp qop infixexp
| exp10
This is no good, because it would exclude:
do ...
++ do
expressions.
It would be even possible to avoid parenthesis
| I imagine it would be something like deleting the production
|
| lexp6- - exp7
The rational for the current choice was the example:
f x = -x^2
| and adding the production
|
| exp10- - fexp
But I would also recommend this change.
It would also make sense to
S. Doaitse Swierstra schrieb:
[..]
\begin{code}
main = do
if True then putStrLn 1;
else putStrLn 2
\end{code}
This does also not work with hugs (; at the end)
This does not work since now you have two ;'s; one because you wrote
one and one because you did not indent the else. Allowing
Hi,
seeing Haskell 2010 and
http://hackage.haskell.org/trac/haskell-prime/wiki/DoAndIfThenElse
saying:
Compiler support ¶
GHC full (no flag)
I wonder why I still get a parse error (possibly incorrect
indentation) for:
\begin{code}
main = do
if True then putStrLn 1
else putStrLn 2
David Virebayre schrieb:
Isn't the proposal about :
\begin{code}
main = do
if True then putStrLn 1
;else putStrLn 2
\end{code}
This should go through, too, but also does not for me according to
http://hackage.haskell.org/trac/haskell-prime/wiki/DoAndIfThenElse
cite
Change the syntax
Stephanie Weirich wrote:
Ok, I've put together a page on EmptyDataDecls:
http://hackage.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls
This reminds me to the related ticket:
http://hackage.haskell.org/trac/ghc/ticket/393
If a dummy definition can be supplied for a function, then also a
Brian Bloniarz wrote:
I got confused by the GHC documentation recently, I was wondering how
it could be improved. From:
http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.html
Seeing the rule
pat ::= !pat
you'll probably want to avoid patterns like: !!pat, ! ! pat, or ~ !
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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
36 matches
Mail list logo
