On Sun, Sep 11, 2005 at 01:48:16AM -0400, Cale Gibbard wrote:
On 10/09/05, Frederik Eaton [EMAIL PROTECTED] wrote:
These are good arguments, and I think this is a good direction for the
discussion, should it continue.
Despite having a fairly mathematical background, I don't really care
It appears to me that:
* Many people don't like having to extract values from a monad on a
separate line, but would like to be able to mix monadic return values
into pure expressions, on the way to calculating a monadic result.
* Some people want to fix this by doing an implicit lifting
These are good arguments, and I think this is a good direction for the
discussion, should it continue.
Despite having a fairly mathematical background, I don't really care
for the proposed syntax.
myList :: [[Integer]]
myList = return [1,2,3,4]
I'm assuming you mean
myList :: [[Integer]]
I heartily agree with everything Cale wrote
on this topic.
In addition, I hereby apologize to Claus for
being too lazy to participate in the survey.
Regards,
Yitz
Cale Gibbard wrote:
Despite having a fairly mathematical background, I don't really care
for the proposed syntax.
myList ::
Am Freitag, 9. September 2005 23:56 schrieb Frederik Eaton:
[...]
Would it mean treating the 'Monad' class specially? Perhaps, but I
don't think this is a reason to avoid it.
As far as I can see, your approach would make Haskell a kind of imperative
programming language. Side-effects would
Am Samstag, 10. September 2005 05:12 schrieb Aaron Denney:
[...]
Well, monads are already treated specially -- the whole do syntax.
But the do syntax isn't a very drastic special treatment of monads. There is
a relatively simple syntax-based transformation into code without do
expressions.
On 10/09/05, Frederik Eaton [EMAIL PROTECTED] wrote:
These are good arguments, and I think this is a good direction for the
discussion, should it continue.
Despite having a fairly mathematical background, I don't really care
for the proposed syntax.
myList :: [[Integer]]
myList =
On 2005-09-08, John Meacham [EMAIL PROTECTED] wrote:
of course, we can't do this because Num has Ord and Show as superclasses
when it really doesn't need to. (we would have to create a separate
class for 'pattern matchable nums' if we got rid of those, but that is
no problem other than being
On 2005-09-09, Keean Schupke [EMAIL PROTECTED] wrote:
Keean Schupke wrote:
I'm not sure exactly what you have in mind. Obviously I want something
that applies to all functions, with any number of arguments, and not
just (+). Furthermore, it should handle cases like 1+[2,3] where only
one
By the way, I thought it would be obvious, but a lot of people seem to
be missing the fact that I'm not (as Sean, I believe, isn't)
requesting limited support for 1 or 2 or 3 argument functions or
certain type classes to be applied to monads, or for certain
operations to defined on certain types.
Despite having a fairly mathematical background, I don't really care
for the proposed syntax.
myList :: [[Integer]]
myList = return [1,2,3,4]
Is myList equal to [[1,2,3,4]] or [[1],[2],[3],[4]]? Either
interpretation is possible if there is automatic lifting about. If the
lifting only occurs
life is funny, isn't it? so many people so eagerly discussing conversion
between non-monadic and monadic code, yet when we asked for your
opinions and suggestions on this very topic only a short while ago,
we got a total of 4 (four) replies - all quite useful, mind you, so we were
grateful, but
On 2005-09-09, Frederik Eaton [EMAIL PROTECTED] wrote:
I thought the easy answer would be to inject non-monadic values into the
monad (assuming one already rejiggered things to do automatic lifting).
I don't know if this is the right way of looking at it. Do you have an
example?
In a do
13 matches
Mail list logo
