Hello again.
> Since type signature declarations for functions are generally considered good
> practice, those who use "<- getArgs" would actually need to type two extra
> characters. And those who do not use getArgs typically (which may or may not
> be the case in general), would type an extra 1
On Tue, Mar 23, 2004 at 10:29:26AM -0500, Sean E. Russell wrote:
> Here's my base case:
>
> someFunc :: String -> IO [a]
> ...
> ax <- someFunc a
> bx <- someFunc b
> assertBool "fail" $ length ax == length bx
>
> <...>What I'd much rather have
On 24/03/2004, at 9:54 AM, Sean E. Russell wrote:
We'd all love to make the lifting implicit, but no one knows how to
do it
without breaking the whole language.
I've heard people talk about the functional "purity" of Haskell --
you'd have
to break this purity to add implicit lifting?
I don't thi
On Tue, 2004-03-23 at 15:29, Sean E. Russell wrote:
> Here's my base case:
>
> someFunc :: String -> IO [a]
> ...
> ax <- someFunc a
> bx <- someFunc b
> assertBool "fail" $ length ax == length bx
>
> I don't like the assignments; the typing
On Tuesday 23 March 2004 17:04, you wrote:
> * Memory management (allocation and deallocation) is effortless.
>
> * Creating lexical closures is very easy.
>
> * You don't have to declare the types of all your functions and local
> bindings, because the implementation can figure them out
On Tue, 23 Mar 2004, Sean E. Russell wrote:
> The standard explaination about why monads are so troublesome always sounds
> like an excuse to me. We have monads, because they allow side-effects. Ok.
> If programs that used side effects were uncommon, I'd be fine with them being
> troublesome
At 12:55 23/03/04 -0500, Sean E. Russell wrote:
On Tuesday 23 March 2004 11:36, Graham Klyne wrote:
> I think you're a rather stuck with the "temporary variables" (which they'=
re
> not really), but it might be possible to hide some of the untidiness in an
> auxiliary monadic function.
That seems t
hi,
at some level you are right that some more syntactic sugar
and stuff could make monads more atracitve. for the time
being here is how i'd write what you want bellow:
f # m = liftM f m
mx === my = liftM2 (==) m1 m2
assertBool "fail" $ (length # someFunc a) === (length # someFunc b)
a
On Tuesday 23 March 2004 11:36, Graham Klyne wrote:
> I think you're a rather stuck with the "temporary variables" (which they're
> not really), but it might be possible to hide some of the untidiness in an
> auxiliary monadic function.
That seems to be the common suggestion: write my own visitors
David Sankel <[EMAIL PROTECTED]> writes:
> Since type signature declarations for functions are generally considered
> good practice, those who use "<- getArgs" would actually need to type two
> extra characters. And those who do not use getArgs typically (which may or
> may not be the case in gen
--- Steffen Mazanek <[EMAIL PROTECTED]> wrote:
> I think this would simplify everyday-programming a lot. Or are there
> any severe theoretical (semantical) problems (main is running in the IO
> monad either way)?
The type signature of main currently is:
main :: IO()
and the new type signature
I think you're a rather stuck with the "temporary variables" (which they're
not really), but it might be possible to hide some of the untidiness in an
auxiliary monadic function.
Assuming this function is given:
assertBool :: String -> Bool -> IO ()
...
My first stab would be:
assertBool1 ::
Hello,
I posted this question to comp.lang.functional, and someone suggested that I
try this group instead.
I'm struggling with monads. Well, not monads themselves, but mixing them with
non-monadic functions.
Here's my base case:
someFunc :: String -> IO [a]
...
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> We would happily support it, but we don't have the resources. It'll be
> supported if someone steps up to take on the responsiblity - the
> advantage would be that you would get your name in lights on
>
> http://www.haskell.org/ghc/contributors.html
Am Dienstag, 23. März 2004 12:31 schrieben Sie:
> Op zo 21-03-2004, om 18:54 schreef Wolfgang Jeltsch:
> > Hello,
> >
> > I'm trying to use GHC's deriving mechanism for newtypes in the following
> > way: class C a b
> > instance C [a] Char
> > newtype T = T Char deriving C [a]
> > Unfortuna
15 matches
Mail list logo