Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Maybe and Just (emacstheviking)
2. Re: Maybe and Just (Corentin Dupont)
3. ap = liftM2 id (martin)
4. Re: ap = liftM2 id (Andres L?h)
5. Re: Maybe and Just (martin)
----------------------------------------------------------------------
Message: 1
Date: Thu, 26 Mar 2015 16:25:28 +0000
From: emacstheviking <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Maybe and Just
Message-ID:
<CAEiEuU+tx8zQ2zm=hhlgjaf+0rrbtrjj4anwvgvwbszz+so...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
For what its worth I wrote this a while back, a hopeless attempt to do
something "monad like" in PHP but reading it again..... well, it's no
wonder I like Haskell more than I like having to use PHP!
http://objitsu.blogspot.co.uk/2013/01/php-and-maybe-miserable-monads.html
On 26 March 2015 at 10:26, Michael Alan Dorman <[email protected]>
wrote:
> Shishir Srivastava <[email protected]> writes:
> > After reading and re-reading the haskell tutorials I don't happen to
> > see a very convincing or appealing reason for having these data
> > types.
>
> To be clear: Maybe is the data *type*. Just and Nothing are its data
> *constructors*.
>
> > Can anyone please explain where Maybe and Just provide the sort of
> > functionality that cannot be achieved in other languages which don't
> > have these kind.
>
> The functionality can be achieved in other languages, certainly. The
> question is whether the clarity and safety is also achieved.
>
> When I see (as a totally contrived example):
>
> fopen :: Maybe FileHandle
>
> I know that that function may not be able to return a FileHandle value
> all the time. The compiler will, in fact, nag me if I do not write the
> code that calls it in such a way that it acknowledges that possibility.
>
> When I see:
>
> FILE * fopen ( const char * filename, const char * mode );
>
> It is not immediately clear whether that can fail. Sure, we can make
> that inference, based on what we know about filesystems, etc., but the
> compiler is never going to complain if I ignore the possibility.
>
> In my experience, programmers in many languages end up resorting to
> convention to try and work around these sorts of ambiguities. Large
> projects have strategies for naming functions that try to pass along
> information out of band, or languages have a pervasive culture of "lint"
> tools that try to use heuristics to make up for what the type system
> doesn't make simple.
>
> That said, I know that doing Maybe sorts of things in languages that
> don't have, say, pattern matching, or the idea of a "failure monad",
> gets to be a drag very quickly---manually unwrapping things is at best
> awkward, having to re-wrap them just to unwrap them again in a sequence
> of computations quickly leads one to believe "it's just not worth
> it"---or you resort to exception handling, which has its own challenges
> to do well.
>
> Mike.
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150326/229f12d5/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 26 Mar 2015 18:31:34 +0100
From: Corentin Dupont <[email protected]>
To: Shishir Srivastava <[email protected]>, The
Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Maybe and Just
Message-ID:
<caeyhvmowushsx9mv9hsngqtcy_ws_0-rusphn7e9ge96z3k...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Not really, when you define the type "Maybe a":
data Maybe a = Just a | Nothing
Haskell is creating automatically two functions for you:
Just :: a -> Maybe a
Nothing :: Maybe a
In the first case, you can think of "Just" and "Nothing" as a sort of tag
identifying which element of the sum you have.
It the second case it's a function, with the same name.
A more informed person than me could say if they are indeed separated of if
they are the same thing in GHC...
On Thu, Mar 26, 2015 at 5:34 PM, Shishir Srivastava <
[email protected]> wrote:
> isn't that then cyclic dependency between 'Maybe' and 'Just' ...where the
> first one is defined in terms of second and vice-versa...?
>
> Shishir
>
>
> On Thu, Mar 26, 2015 at 3:48 PM, Corentin Dupont <
> [email protected]> wrote:
>
>> Hi Shishir,
>> I think that's a legitimate question.
>>
>> By writing
>>
>> data Maybe a = a | Nothing
>>
>> you are saying that the type of the left hand side of the = is the same
>> that right hand side (you are defining a type basically).
>> Also you can only sum things of the same type.
>> So you are saying:
>> type "Maybe a" = type "a"
>> Which is wrong.
>> That's why "a" should be wrapped into something:
>> type of "Just a" is indeed "Maybe a".
>>
>> "Just" is a type constructor:
>> Just :: a -> Maybe a
>> It allows you to build the Maybe.
>>
>> Said that, "Just" is a vocabulary choice.
>> Personally I prefer the name choices of OCaml, Rust, Scala etc.: Option
>> a = None | Some a
>>
>>
>>
>> On Thu, Mar 26, 2015 at 4:26 PM, Shishir Srivastava <
>> [email protected]> wrote:
>>
>>> ok..but what's with using the keyword 'Just' ? why cannot 'Maybe' be
>>> defined like this
>>>
>>> data Maybe a = a | Nothing
>>>
>>> what's the point in having 'Just' keyword ?
>>>
>>> Shishir
>>>
>>>
>>> On Thu, Mar 26, 2015 at 10:26 AM, Michael Alan Dorman <
>>> [email protected]> wrote:
>>>
>>>> Shishir Srivastava <[email protected]> writes:
>>>> > After reading and re-reading the haskell tutorials I don't happen to
>>>> > see a very convincing or appealing reason for having these data
>>>> > types.
>>>>
>>>> To be clear: Maybe is the data *type*. Just and Nothing are its data
>>>> *constructors*.
>>>>
>>>> > Can anyone please explain where Maybe and Just provide the sort of
>>>> > functionality that cannot be achieved in other languages which don't
>>>> > have these kind.
>>>>
>>>> The functionality can be achieved in other languages, certainly. The
>>>> question is whether the clarity and safety is also achieved.
>>>>
>>>> When I see (as a totally contrived example):
>>>>
>>>> fopen :: Maybe FileHandle
>>>>
>>>> I know that that function may not be able to return a FileHandle value
>>>> all the time. The compiler will, in fact, nag me if I do not write the
>>>> code that calls it in such a way that it acknowledges that possibility.
>>>>
>>>> When I see:
>>>>
>>>> FILE * fopen ( const char * filename, const char * mode );
>>>>
>>>> It is not immediately clear whether that can fail. Sure, we can make
>>>> that inference, based on what we know about filesystems, etc., but the
>>>> compiler is never going to complain if I ignore the possibility.
>>>>
>>>> In my experience, programmers in many languages end up resorting to
>>>> convention to try and work around these sorts of ambiguities. Large
>>>> projects have strategies for naming functions that try to pass along
>>>> information out of band, or languages have a pervasive culture of "lint"
>>>> tools that try to use heuristics to make up for what the type system
>>>> doesn't make simple.
>>>>
>>>> That said, I know that doing Maybe sorts of things in languages that
>>>> don't have, say, pattern matching, or the idea of a "failure monad",
>>>> gets to be a drag very quickly---manually unwrapping things is at best
>>>> awkward, having to re-wrap them just to unwrap them again in a sequence
>>>> of computations quickly leads one to believe "it's just not worth
>>>> it"---or you resort to exception handling, which has its own challenges
>>>> to do well.
>>>>
>>>> Mike.
>>>>
>>>
>>>
>>> _______________________________________________
>>> Beginners mailing list
>>> [email protected]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150326/ee19fe82/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 26 Mar 2015 21:18:37 +0100
From: martin <[email protected]>
To: beginners <[email protected]>
Subject: [Haskell-beginners] ap = liftM2 id
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hello all,
can someone explain
ap = liftM2 id
to me? liftM2 wants a binary funcation
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
but id is unary. How does this work?
------------------------------
Message: 4
Date: Thu, 26 Mar 2015 21:33:46 +0100
From: Andres L?h <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] ap = liftM2 id
Message-ID:
<caljd_v4ewhdxem+wvqbzbeuyrm1nqgmju_h8yk9sqq5ltql...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
There's no such thing as a fixed arity of a function in Haskell. The
type of id is
> id :: a -> a
If you instantiate "a" with "b -> c", then it becomes
> id :: (b -> c) -> b -> c
and it suddenly takes two arguments. In fact, it then behaves like
function application. Try
> id not True
or
> not `id` True
and you'll see that it works as if you had used function application
or $ instead. So ap lifts function application, and if it helps, you
can think of it as instead being defined as
> ap = liftM2 ($)
Cheers,
Andres
On Thu, Mar 26, 2015 at 9:18 PM, martin <[email protected]> wrote:
> Hello all,
>
> can someone explain
>
> ap = liftM2 id
>
> to me? liftM2 wants a binary funcation
>
> liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
>
> but id is unary. How does this work?
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
--
Andres L?h, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com
Registered in England & Wales, OC335890
250 Ice Wharf, 17 New Wharf Road, London N1 9RF, England
------------------------------
Message: 5
Date: Thu, 26 Mar 2015 22:04:47 +0100
From: martin <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Maybe and Just
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Am 03/26/2015 um 11:06 AM schrieb Shishir Srivastava:
> Hi,
>
> After reading and re-reading the haskell tutorials I don't happen to see a
> very convincing or appealing reason for
> having these data types.
>
> Can anyone please explain where Maybe and Just provide the sort of
> functionality that cannot be achieved in other
> languages which don't have these kind.
My intuition goes like that:
"Maybe" is like "nullable" (which doesn't really exist, but you sure can
imagine what it means). In many programming
languages a variable of any type can contain "null", i.e. every type is
nullable. This means that any function accepting
one of these types as a parameter must be prepared to see a null. You end up
with many checks like
if (x==null) {return null;}
Not so in haskell. An Int is really an Int and Ints cannot be null. Functions
accepting Ints don't have to check for null.
But you can beef up any datatype to be nullable. You can create a TYPE
"nullable Int" which would be called "Maybe Int"
in Haskell. Just like "nullable" alone, Maybe itself is not a type, but an
up-beefer of another type. There are no
values of type Maybe, but only of Maybe Int, Maybe String etc. In that respect
maybe is like "List". There are no values
of type "List", but only of List of Int, List of String. List is an up-beefer
too (written as [] in Haskell)
Obviously there needs to be a distinct VALUE for "null". In Haskell this value
is called "Nothing".
For the non-null VALUES you could think about writing them verbatim, like
"42". But from just looking at 42, you
couldn't tell what type it is. It could be an Int or a Maybe Int. This problem
is somewhat akin to writing 42.0 when you
want to make sure it is a float (in imperative languages), or 42L to indicate
it is a long.
So in the same vein, you distinguish an Int (42) from a Maybe Int (Just 42).
Just 42 is a value of type Maybe Int, which
just (sic!) happens not to be null, but it is still not a plain Int, but a
Maybe Int. Like 42.0 is a float which happens
not to have any digits after the decimal point but also is not a plain Int but
a float.
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 81, Issue 65
*****************************************
