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
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 s
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 when
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. I
Anyway, if the idea is to ultimately wrap every value in an expression
like ([1,2]+[3,4]) in a 'run' application, that doesn't sound very
useful. Program structure might be improved, but it would be bloated
out by these calls. Also, I don't know what would happen to the
readability of type checker
On Thu, Sep 08, 2005 at 09:34:33AM +0100, Keean Schupke wrote:
> Can't you do automatic lifting with a "Runnable" class:
>
> class Runnable x y where
>run :: x -> y
>
> instance Runnable (m a) (m a) where
> run = id
>
> instance Runnable (s -> m a) (s -> m a) where
>
SPACE 2006
Third workshop on
SEMANTICS, PROGRAM ANALYSIS, AND
COMPUTING ENVIRONMENTS FOR MEMORY MANAGEMENT
January 14, 2006
Charleston, South Carolina
Sponsored by ACM/SIGPLAN
http://www.itu.dk/research/plt/space2006/
-
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] w
On 9/9/05, Keean Schupke <[EMAIL PROTECTED]> wrote:
> Just noticed the 1+[1,2] case... I am not certain whether this is
> possible - it is outside the
> scope of the formal definiton of Haskell and may rely on implementation
> details of the compiler/interpreter.
While this is outside the scope o
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 value is monadic.
Just noticed the 1+[1,2] case... I am no
Malcolm Wallace wrote:
Wolfgang Jeltsch <[EMAIL PROTECTED]> writes:
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 value is
To mark the end of Paolo Martini’s project to add support for the cairo
vector graphics library (cairographics.org) we are pleased to announce a
special “tech preview” release of Gtk2Hs including Paolo’s
contributions.
Here’s a screenshot from a demo program Paolo and others wrote to show
off the
Wolfgang Jeltsch <[EMAIL PROTECTED]> writes:
> > 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 value is monadic.
>
>
Am Donnerstag, 8. September 2005 22:30 schrieb Frederik Eaton:
> Hi Chad,
>
> 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 v
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 be
15 matches
Mail list logo
