more elegant,
but I think it makes the semantics clearer.
(Of course, OCaml does not have implicit module arguments,
so ``foo :: (Monad m) => [m a] -> m [a]'' has no direct translation.)
See also ``Named Instances for Haskell Type Classes'':
http://www.cas.mcmast
John Hughes wrote:
>
> Type signatures currently do more than state the type of a variable.
> They potentially (i) enable polymorphic recursion, and (ii) disable the
> monomorphism restriction, thus losing sharing. It would be very strange
> if a type signature *in an export list* were to
Bulat.Ziganshin responded to Claus Reinke:
>
> CR> yes, this would add one constraint on where to place definitions. but
> CR> grouping logically related definitions together is not quite what one
> CR> might think anyway: aren't the definitions making up the interface
> CR> most strongly re
Malcolm.Wallace wrote:
> (But then, how would you guarantee that the first three characters
> in the file must be "{-#" ?)
In particular, what do you propose for literate source?
(I hardly have any .hs files.)
As far as I can see,
it seems to be possible to get LaTeX to work with UTF8;
the (ap
Simon Marlow <[EMAIL PROTECTED]> just wrote:
> How about just adding a couple of new pragmas:
>
> {-# INCLUDE_PRIVATE "foo/bar.h" #-}
> {-# INCLUDE_PACKAGE "foo/bar.h" #-}
>
> both pragmas apply to all the foreign imports in the current module,
> just like the existing INCLUDE pragma.
whether you look in the Haskell report,
or for a definition of the ``functional rewriting strategy''
in the theoretical literature.
To fix exactly this problem was my original goal
when I started developing a family of Pattern Matching Calculi,
see http://www.cas.mcmaster.ca/~kahl/PMC/
Brandon Moore <[EMAIL PROTECTED]> wrote in his answer to my PMC syntax
proposal:
>
> Maybe the '\' could be reiterated to introduce the layout group:
>
> take' = \
> 0 _ -> []
> n \[] -> []
> (x:x) -> x : take (pred n) xs
Definitely not, since the lambda gets us back into expressions,
des
Brandon asked me to forward this --- I already posted a small
clarification.
Wolfram
--- Start of forwarded message ---
Date: Mon, 02 Oct 2006 00:07:17 -0700
From: Brandon Moore <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: haskell-prime@haskell.org
Subject: Re: [Haskell] Replacing and im
Brandon,
> Both of these constructs amount to minor syntactical overloading,
> allowing lambda and "case" constructs in the expression grammar and the
> match grammar with slightly different meanings. This seems to be pretty
> similar to the way we already allow (Constr x y z) as an express
Henning Thielemann (haskell at henning-thielemann dot de) wrote:
>
> Cale Gibbard cgibbard at gmail.com, Sun Oct 22 12:23:18 EDT 2006
>
> > The 'then' and 'else' visually separate the parts of the
> > if-expression, and serve to guide one's eyes when reading code
> > silently, and one's wo
After a particularly bad week in a very busy term
I am just now getting around to have a first look
at Claus Reinke's <[EMAIL PROTECTED]> lambda-match proposal
and at his message from 29 Oct 2006:
>
> - matchings are not first-class expressions in PMC
>
> the only syntactically correct way to
Isaac Dupree <[EMAIL PROTECTED]> wrote:
>
> Adde wrote:
> > tmp <- foo
> > return Bar {
> >barFoo = tmp
> > }
>
> There is a feature being worked on in GHC HEAD that would let you do
>
> do
>tmp <- foo
>return Bar{..}
>
> which captures fields from everything of t
Adrian Hey <[EMAIL PROTECTED]> wrote:
> I would ask for any correct Eq instance something like the law:
>(x==y) = True implies x=y (and vice-versa)
The easiest counterexample are sets (or finite maps)
provided as an abstract data type (i.e., exported without access to the
implementation, in
Conor McBride <[EMAIL PROTECTED]> responded to my comment:
> > (mapMonotonic should of course be removed, too,
> > or specified to fail (preferably in some MonadZero)
> > if the precondition is violated,
> > which should still be implementable in linear time.)
>
> What's wrong with mapMo
Simon Marlow replied to Henning Thielemann:
> Prelude.>>= just doesn't look like an infix operator. The point of
> infix operators is that they are a lightweight notation, but they lose
> that advantage when qualified. The qualified operator proposal gives
> you a nice rule of thumb to r
Don Stewart wrote:
>
> Tom Lokhorst suggests[1]
>
> Haskell'10
>
> [1] http://twitter.com/tomlokhorst/statuses/2539313506
How pessimistic.
Some people expect Haskell and/or Haskell'
not to be around anymore in 2110?
Wolfram
___
Haske
On Tue, Jan 04, 2011 at 02:24:21AM -0800, o...@okmij.org wrote:
>
> I'd like to argue in opposition of making Functor a super-class of
> Monad. I would argue that superclass constraints are not the right
> tool for expressing mathematical relationship such that all monads are
> functors and a
17 matches
Mail list logo
