Re: [Haskell-cafe] Tutorial: Haskell for the Evil Genius

[Alexander Solla]

On Fri, Sep 14, 2012 at 7:13 PM, Andrew Pennebaker <
andrew.penneba...@gmail.com> wrote:

> Challenge: get someone to have a competition at one of the conferences
>> where students all give their
>> best "five minute monad talk" and try to find the most comprehensible one!
>>
>
> Challenge accepted .
>


What did any of that have to do with monads?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Tutorial: Haskell for the Evil Genius

[Conal Elliott]

On Fri, Sep 14, 2012 at 2:18 PM, Andrew Pennebaker wrote:

> A summary of the changes I've included so far:
> [...]
>
> Another comment:
>
>
>> "As a declarative language, Haskell manipulates expressions, eventually
>> reducing expressions to values."
>
>
>> Huh? In what sense do declarative languages manipulate expressions?
>> Sounds like a classic syntax/semantics confusion, especially when
>> interpreters and/or lazy evaluation (implementation issues, not language
>> properties) are in the mix.
>
>
> Noted and reflected in the new version.
>
> I'm trying to introduce the concept of declarative programming as opposed
> to imperative programming. Declarative programming according to 
> Wikipedia
> :
>
> is a programming paradigm that expresses the logic of a computation
>> without describing its control flow.
>
>
> I believe this is done in Haskell and other declarative languages by
> treating code as manipulable, reducible expressions, where imperative
> languages would use machine instructions.
>

I'm struggling to find anything in this belief/opinion that I can relate
to. How did you come by it? What experiments can you perform to check
whether it's true or false? I second Albert Lai's recommendation to use the
scientific method.

Along these lines, I still see "Haskell manipulates reducible expressions,
eventually reducing them to values" in your tutorial, which again I suspect
comes from confusion between syntax & semantics and/or between meaning and
possible execution strategy.

Regards, - Conal
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Tutorial: Haskell for the Evil Genius

[Joel Burget]

Kris,

Sorry for the confusion, I wasn't directly addressing your post. I was trying 
to correct what I perceived as a misconception in the last paragraph of 
Andrew's message, beginning with "Given that…".

- Joel


On Saturday, September 15, 2012 at 10:24 AM, Kristopher Micinski wrote:

> On Fri, Sep 14, 2012 at 10:08 PM, Joel Burget  (mailto:joelbur...@gmail.com)> wrote:
> > [snip]
> >  
> > Also, Maybe and Either are not "implemented as monads". They are defined
> > using `data` like you suggest:
> >  
> > data Maybe a = Nothing | Just a
> > data Either a b = Left a | Right b
> >  
>  
>  
> That's not my point, or my objection. My objection is to people who
> present monads showing examples that begin with Maybe or Either, or
> these 'trivial monads,' types onto which you can strip monadic
> behavior fairly simply. I'm not saying they're bad as monads, or
> useless, but I think the step from Maybe as a datatype to using it as
> a monad is great enough that explaining monads by way of introducing
> them with Maybe as an example is sort of confusing because it
> trivializes what's actually going on.
>  
> I'm honestly not sure what you mean by Maybe or Either being
> "implemented as monads," versus others. Monad is just a type class,
> there's always an underlying type. Perhaps you mean that people
> actually *care* about things in Maybe outside of it being used as a
> monad, versus other things where you don't touch the underlying type.
>  
> This isn't intended to start an argument, however, and I'd prefer not
> to argue over methodology, I just wanted to throw out there that if
> you say "monads, think about maybe, and add some stuff, then that's it
> is, what's all the fuss about!?" I think the hard part for people
> understanding monads isn't the definition of monads, but rather that
> you are forced to really tackle higher order behavior in a very direct
> way. (For example, say you're new to Haskell, you probably don't know
> about CPS, and you read about Cont in a monad tutorial. Is it the
> monad that makes it hard? No, it's probably the concept of CPS.)
>  
> kris  

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Tutorial: Haskell for the Evil Genius

[Kristopher Micinski]

On Fri, Sep 14, 2012 at 10:08 PM, Joel Burget  wrote:
> [snip]
>
> Also, Maybe and Either are not "implemented as monads". They are defined
> using `data` like you suggest:
>
> data Maybe a = Nothing | Just a
> data Either a b = Left a | Right b
>

That's not my point, or my objection.  My objection is to people who
present monads showing examples that begin with Maybe or Either, or
these 'trivial monads,' types onto which you can strip monadic
behavior fairly simply.  I'm not saying they're bad as monads, or
useless, but I think the step from Maybe as a datatype to using it as
a monad is great enough that explaining monads by way of introducing
them with Maybe as an example is sort of confusing because it
trivializes what's actually going on.

I'm honestly not sure what you mean by Maybe or Either being
"implemented as monads," versus others.  Monad is just a type class,
there's always an underlying type.  Perhaps you mean that people
actually *care* about things in Maybe outside of it being used as a
monad, versus other things where you don't touch the underlying type.

This isn't intended to start an argument, however, and I'd prefer not
to argue over methodology, I just wanted to throw out there that if
you say "monads, think about maybe, and add some stuff, then that's it
is, what's all the fuss about!?"  I think the hard part for people
understanding monads isn't the definition of monads, but rather that
you are forced to really tackle higher order behavior in a very direct
way.  (For example, say you're new to Haskell, you probably don't know
about CPS, and you read about Cont in a monad tutorial.  Is it the
monad that makes it hard?  No, it's probably the concept of CPS.)

kris

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Tutorial: Haskell for the Evil Genius

[Kristopher Micinski]

On Fri, Sep 14, 2012 at 10:13 PM, Andrew Pennebaker
 wrote:
>> Challenge: get someone to have a competition at one of the conferences
>> where students all give their
>> best "five minute monad talk" and try to find the most comprehensible one!
>
>
> Challenge accepted.
>

Great!  Maybe I'll try to write up a post on this challenge and put it
on my blog, and try to solicit responses from others too, perhaps
putting up a wiki page somewhere where people can post their attempts!

(By the way, I consider this hard, I'm not touting myself as having a
good solution for this, I'm genuinely interested in others'
responses!)

kris

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] readable version (ANN: darcsden-1.0, hub.darcs.net)

[Simon Michael]

Email.. advanced alien technology that some day I will master.
Here are more readable versions:

http://hub.darcs.net/simon/darcsden-1.0/browse/ANNOUNCE.md

http://hub.darcs.net/simon/hub.darcs.net-conf/browse/ANNOUNCE.md


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Tutorial: Haskell for the Evil Genius

[Taylor Hedberg]

Joel Burget, Fri 2012-09-14 @ 19:08:29-0700:
> I find the Monad instance for Maybe and Either very useful. You can do
> things like the following (which technically only uses the Applicative
> instance):
> 
> Prelude Control.Applicative> (*3) <$> (+2) <$> Just 1
> Just 9
> Prelude Control.Applicative> (*3) <$> (+2) <$> Nothing
> Nothing
> Prelude Control.Applicative> (*3) <$> (+2) <$> Left "error" :: Either String 
> Int
> Left "error"
> Prelude Control.Applicative> (*3) <$> (+2) <$> Right 1 :: Either String Int
> Right 9

Nitpick: You are using the Functor instances of Maybe and Either here,
not Applicative. (<$>) == fmap; it just happens to be defined in the
Control.Applicative module.


signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Transforming a ADT to a GADT

[oleg]

Florian Lorenzen wrote:
> Now, I'd like to have a function
> > typecheck :: Exp -> Maybe (Term t) 
> > typecheck exp = <...>
> that returns the GADT value corresponding to `exp' if `exp' is type
> correct.

Let us examine that type:
typecheck :: forall t. Exp -> Maybe (Term t) 

Do you really mean that given expression exp, (typecheck exp) should
return a (Maybe (Term t)) value for any t whatsoever? In other words,
you are interested in a type-*checking* problem: given an expression _and_
given a type, return Just (Term t) if the given expression has the given
type. Both expression and the type are the input. Incidentally, this
problem is like `read': we give the read function a string
and we should tell it to which type to parse. If that is what you
mean, then the solution using Typeable will work (although you may
prefer avoiding Typeable -- in which case you should build type
witnesses on your own).


> that returns the GADT value corresponding to `exp' if `exp' is type
> correct.
Your comment suggests that you mean typecheck exp should return
(Just term) just in case `exp' is well-typed, that is, has _some_
type. The English formulation of the problem already points us towards 
an existential. The typechecking function should return (Just term)
and a witness of its type:

typecheck :: Exp -> Sigma (t:Type) (Term t)

Then my
> data TypedTerm = forall ty. (Typ ty) (Term ty)

is an approximation of the Sigma type. As Erik Hesselink rightfully
pointed out, this type does not preclude type transformation
functions. Indeed you have to unpack and then repack. If you 
want to know the concrete type, you can pattern-match on the type
witness (Typ ty), to see if the inferred type is an Int, for example.


Chances are that you wanted the following

typecheck :: {e:Exp} -> Result e
where Result e has the type (Just (Term t)) (with some t dependent on
e) if e is typeable, and Nothing otherwise. But this is a dependent
function type (Pi-type). No wonder we have to go through contortions
like Template Haskell to emulate dependent types in Haskell. Haskell
was not designed to be a dependently-typed language.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe