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
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 ~ !
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
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
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
| 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:
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
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
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
|
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
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
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
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:
[...]
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 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
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
) ^ 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
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:
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
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.
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
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
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
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
36 matches
Mail list logo