Is there a standard construct for something of this ilk:
unliftM :: Monad m a -> a
In this case, I need to construct a localised stateful computation
comp :: Int -> Int
comp n = unliftM (do x <- ... return x)
--
Julian Assange|If you want to build a ship, don't drum up people
Simon Peyton-Jones wrote:
>
> I wrote:
> >
> > What's wrong with "ambitious" high-level systems. [snip]
>
> Nothing's wrong with ambitious systems! But there's an ambition/pragmatism
> tradeoff. If there was a consensus about the Right Way to build an
> ambitious (more declarative) system then
Marcin 'Qrczak' Kowalczyk wrote:
[snip]
> It would require to keep bodies of all polymorphic functions in
> a form allowing instantiation in different modules. For example
> ghc already requires too much memory (even a hundred MB for large
> modules), and it leads to code bloat, so in the current
Lennart Augustsson wrote:
>
> Incidentally, this has nothing to do with allowing polymorphic recursion
> on functions in Haskell. It could be done earlier too, but then it had
> to be encoded using a class and instance declaration.
I would argue that methods are in fact polymorphically recursiv
Thomas Johnsson wrote:
> Lennart Augustsson writes:
> > > Simon Peyton Jones' comments about dictionary passing are a red herring,
> > > since they assume a particular form of compiler. Various (MLj, MLton)
> > > ML compilers already inline out all polymorphism.
> > ML is a language where yo
I just tried this example with putStrLn and putStr, and both worked
fine. I am using the latest 4.08.2 GHC under Windows 2000.
-Original Message-
From: Andre W B Furtado [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 19, 2001 6:20 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAI
Simon Peyton-Jones wrote:
> Nothing's wrong with ambitious systems! But there's an
> ambition/pragmatism tradeoff. If there was a consensus about the
> Right Way to build an ambitious (more declarative) system then we
> could all go for it. But there isn't. So let the experiments
> flour
| What's wrong with "ambitious" high-level systems. Is something amiss
| with their basic ideas or is it the nuts and bolts? Are they
| too slow?
| Too big? Too abstract? In short, why is there a need to
| avoid the high
| level and go for "in-the-middle" systems? I am still so new
| to H
Simon Peyton-Jones wrote:
>
> Gentle Haskellers
>
> This message is to invite offers to complete a promising
> port of the Clean Object I/O library to Haskell.
>
> As you know, there are quite a few GUI toolkits for Haskell, but
> none of them has become a de-facto standard. One confusing aspe
Wed, 21 Feb 2001 16:46:48 +0100, George Russell <[EMAIL PROTECTED]> pisze:
> Various (MLj, MLton)
> ML compilers already inline out all polymorphism. Some C++ compilers/linkers
> do it in a rather crude way as well, for templates. If you can do it,
> you can forget about dictiona
Wed, 21 Feb 2001 18:11:22, G Murali <[EMAIL PROTECTED]> pisze:
> makeSet:: (a->Bool)->Set a
There are operations which can be performed on sets constructible in
that way, and there are operations which cannot.
For example you can check if an element belongs to a set, or compute
an intersection
11 matches
Mail list logo
