> Forgot to mention this in my last email. I find myself writing a lot
> of if-then-elses in do notation, and most often the else branch is "return ()".
> This gets a bit cumbersome to write and messes up the code.
There's also the Monad library http://haskell.org/onlinelibrary/monad.html
that co
Hello Haskell friends:
I am looking for anybody that has information on Haskell WebServers.
Currently I understand that Simon Marlow has built a 1500 line Web Server
that does extremely well.
My question is has anybody else out there built a web server ? and if so does
it contain similar Ja
On 29-Jan-2002, Andre W B Furtado <[EMAIL PROTECTED]> wrote:
> In the following code, will "other things" be executed or the "return ()"
> will end function f? I guess the answer is yes ("other things" WILL be
> executed anyway), but I'd like to understand why won't the "return ()" be
> the [state
Hi again,
Forgot to mention this in my last email. I find myself writing a lot
of if-then-elses in do notation, and most often the else branch is "return ()".
This gets a bit cumbersome to write and messes up the code.
So now I tend to use:
doIf :: Monad a => Bool -> [a b] -> a ()
doIf b
> In the following code, will "other things" be executed or the "return ()"
> will end function f? I guess the answer is yes ("other things" WILL be
> executed anyway), but I'd like to understand why won't the "return ()" be
> the [state change/result produced] created by f.
>
> f :: IO ()
> f =
How do I find the implementation of the module ST?
In the GHC documentation, I can only find the signatures of the
functions.
In the following code, will "other things" be executed or the "return ()"
will end function f? I guess the answer is yes ("other things" WILL be
executed anyway), but I'd like to understand why won't the "return ()" be
the [state change/result produced] created by f.
f :: IO ()
f = do
-- lots
Simon Peyton-Jones wrote:
> | Hugs "demands Integral" because that's what it was told to do
> | to follow the report. So in that sense, yes, the code
> | depends on having only one class. But it would be easy for
> | someone to change that.
> |
> | Then again, if we're following the rules of mi
Well, it was a deliberate decision to limit the n+k pattern to class Integral
because people at that time felt that n+k was something that should
only be used with integers. So it's not a fluke, it was quite deliberate.
I kind of like Integral for this (as much as I can like anything about n+k :)
| Hugs "demands Integral" because that's what it was told to do
| to follow the report. So in that sense, yes, the code
| depends on having only one class. But it would be easy for
| someone to change that.
|
| Then again, if we're following the rules of minimal change
| for Haskell 98, the
| On Tue, Jan 29, 2002 at 07:36:56AM -0800, Simon Peyton-Jones wrote:
| > The Haskell Report says of n+k patterns:
| >
| > "A n+k pattern can only be matched against a value in
| > the class Integral."
| >
| > This seems far too strong. All that is needed are Ord (for the >=)
| > and Num (for
| Btw., in 3.17.2 Informal Semantics of Pattern Matching
| the end of the following sentence should be changed:
Actually I've changed the entire wording of that section
in consultation with Ross who has read it rather carefully.
You can find the current draft of the expressions chapter at
> In any case, I propose to change "Integral" to "Ord and Num".
I agree. And nhc98 seems to actually implement this.
Nonetheless I find using n+k patterns for floating point numbers pretty
horrible. And it raises the question why k cannot be a rational ...
But then n+k patterns are a wart anywa
On Tue, Jan 29, 2002 at 07:36:56AM -0800, Simon Peyton-Jones wrote:
> The Haskell Report says of n+k patterns:
>
> "A n+k pattern can only be matched against a value in
> the class Integral."
>
> This seems far too strong. All that is needed are Ord (for the >=)
> and Num (for - and fromInteg
Folks
The Haskell Report says of n+k patterns:
"A n+k pattern can only be matched against a value in
the class Integral."
This seems far too strong. All that is needed are Ord (for the >= and
-)
and Num (for fromInteger), and indeed that's what GHC requires.
Do Hugs or nhc actually require
| Just before Section D.1 there is the sentence
|
| When inferring the context for the derived instances, type
| synonyms must be expanded out first.
|
| I don't understand it. Which type synonyms need expansion?
Consider
type Foo a = [a]
data T a = MkT (Foo a) deriving( Eq )
16 matches
Mail list logo
