Ben Millwood wrote:
No-one's yet argued against OverloadedStrings. I think there /is/ an
argument to be made, that it introduces ambiguity and could break
existing programs (probably we can extend defaulting to take care of
this, but I think there are people who'd be happier if we killed
Moving this to the haskell-prime list, where perhaps someone
will notice it.
Serge D. Mechveliani wrote:
Looking into the on-line Haskell-2010 definition,
I see in the Library definition
20.4.3 ...
iteratef (instead of iterate f),
repeatx (instead of repeat x).
Ben Millwood wrote:
So we don't actually specify the content or API of the library itself,
merely state its existence? If we specify the API we make those
decisions, if we don't I don't see what exactly you are asking for...
So why are you proposing that it be different from a Hackage package
Hi Neil,
Neil Mitchell wrote:
There is nothing to stop an library author doing exactly this, and it
might even be useful for some people (personally I'm going to stick to
haskell-src-exts, because it's a brilliant library).
Yes, it is.
I am not proposing changing in any way how we
develop
Ben Millwood wrote:
But if we make the official parser usable for AST manipulation, we
have to rule on the design issues I raised above: whether to make
efforts to stop invalid lambdas being constructed, how to name the
types and constructors, etc.
No we don't. With regard to its inclusion as
I propose that the haskell-src package be renamed
haskell20nn-src for each revision Haskell 20nn of
the standard, and be made an official machine-readable
component of the standard.
This has the following advantages:
1. It would require almost no extra work, because
haskell-src already exists,
The trick of controlling allocation of external
resources by using NOINLINE, unsafePerfromIO,
and IORef to create global variables has become
an indispensable technique in Haskell. It seems to
work well enough with most current compilers.
However, it is well known that the semantics of
NOINLINE
Hi Bulat,
You wrote:
there is common proposal that i support. example of its use:
i :: IORef Int
i - newIORef 1
with a semantics equivalent to current use of usafePerformIO+INLINE in GHC
Are the details of this posted anywhere? Is there a ticket
for this?
I assume you mean that this will
Donald Bruce Stewart [EMAIL PROTECTED] wrote:
The joy of pattern guards
reveals once you have more conditions.
I wrote:
Of course, this is not really the joy of
pattern guards. It is the joy of monads,
with perhaps a few character strokes
saved by a confusing overloading of (-).
Philippa
Philippa Cowderoy wrote:
This is what I get for replying straight away!
Oh, no, I'm happy that you responded quickly.
I think my point is that I'm not aware of many people
who actually think this is a problem or get confused.
Well, I don't mean that this is something that experienced
I wrote:
...the main monad at work here is the Exit monad.
Ross Paterson wrote:
...if we define
exitMaybe :: Exit e () - Maybe e
exitMaybe (Continue _) = Nothing
exitMaybe (Exit e) = Just e
then we have
runExit m = fromJust (exitMaybe m)
exitMaybe (x
The need for supplemental condition testing and
splitting the pattern matching among the where
clause and the boolean guards is considered
very cumbersome by some.
Yes, it is. But that was only an artificial construction,
meant to work in general. I wouldn't do it that way
really. When an
Thanks for all the responses. I get the digest,
and I was off-line for a day, so I only saw most
of them now. Also, for the same reason, my
apologies that I am connecting this message to the
wrong spot in the thread.
First of all, I still maintain that any expression
written using pattern
Conor McBride wrote:
Claus Reinke wrote:
...the results of the translation are rather
more awkward but -and this is the important
point- pattern guards do not add new
functionality.
Well, neither do Boolean guards nor even basic
pattern matching... one simply should not need
to clutter a
I would like to suggest a correction to ticket #56,
Pattern Guards.
It is easy to show that every expression written
using pattern guards can also be written in
Haskell 98 in a way that is essentially
equivalent in simplicity. (Proof below.)
In my opinion, the Haskell 98 version below is
more
15 matches
Mail list logo
