ts of `Control.Applicative.(<$>)` only if
> `Prelude.(<$>)` were also in scope.
>
One obvious solution I haven't seen mentioned is the ability to add
nonexistent identifier to a hiding clause (these identifiers might
presumably exist in some other version of the import):
import Prelude hiding ((<$>))
I can see the argument for marking such imports with a pragma, though it
gets a bit ugly.
-Jan-Willem Maessen
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
transitive
closure of all the existing operators. As another message in this
discussion (from Simon M?) mentioned, you might want to be able to
specify the relationship between operators imported from different
modules, because you *do* know that a well-known relationship exists.
-Jan-Wil
On Apr 12, 2006, at 4:25 PM, John Meacham wrote:
On Wed, Apr 12, 2006 at 09:21:10AM -0400, Jan-Willem Maessen wrote:
Though, to be fair, an awful lot of Prelude code didn't work in pH
unless it was re-written to vary slightly from the specification. So
the assumption of laziness was
c was
willing to acknowledge.
-Jan-Willem Maessen
-- Lennart
Simon Peyton-Jones wrote:
| Well, my worry was partly about the suggested version of deepSeq
that
| would not diverge on circular structures (since circular structures
| are just one way to implement "infinite"
thanks for your thoughts on this, it's greatly
appreciated.
On 31 March 2006 18:49, Jan-Willem Maessen wrote:
John -
You are, in effect, proposing a memory model for MVars and IORefs.
The high-level model for programmers is "In order to communicate data
between threads, you *must* use an
o choose a model that is conceptually
simple now, at the cost of imposing a few constraints on
implementors, rather than a complex specification which permits
maximum implementation flexibility but is utterly opaque.
Realistically, the machines which are likely to be built will make it
easy to c
n-standard ways.
-Jan-Willem Maessen
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
bility to coerce to Dynamic?
It would be a special source of amusement to me if such a class were
called All or Forall... :-) (though a moment's thought will tell you
it's Wrong.)
-Jan-Willem Maessen
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
e places where mathematical notation
actually obscures rather than clarifying. Continuing the error in ML
was a mistake. Fundamentally, I *like* that the k-tuple type in
Haskell looks like a k-tuple, and not some randomly-associated infix
binary operator.
-Jan-Willem Maessen
((a,b),c) a
dzipK [] rbs = dzipT as
where dzipT ys@(_:yt) = zipWith f ys rbs ++ dzipT yt
dzipT [] = []
-Jan-Willem Maessen
Jón
--
Jón Fairbairn Jon.Fairbairn at
cl.cam.ac.uk
___
Haskell-p
d benefit from a library function for the
list-numbering idiom. (Plus, such a library would play nicely with
any evaluation strategy you care to name...) This would eliminate
more than half the uses of "zip" in comprehension generators.
I was surprised to see that phc would have be
On Feb 3, 2006, at 8:16 PM, Brian Hulley wrote:
Jan-Willem Maessen wrote:
I pointed out some problems with strict Haskell in a recent talk, but
I think it'd be worth underscoring them here in this forum.
Is the text of this talk or points raised in it available online
anywhere?
12 matches
Mail list logo
