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: Something like pydoc? (Mike Meyer)
2. Re: Maybe and Just (Shishir Srivastava)
3. Re: Maybe and Just (Brandon Allbery)
4. Re: Maybe and Just (Corentin Dupont)
----------------------------------------------------------------------
Message: 1
Date: Thu, 26 Mar 2015 09:27:13 -0500
From: Mike Meyer <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Something like pydoc?
Message-ID:
<CAD=7U2D+qWRtd54cDKyfBgF0szdqSMO3r=gwpv1vdp3u4y-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Thu, Mar 26, 2015 at 8:44 AM, David McBride <[email protected]> wrote:
> There is a hoogle command: https://hackage.haskell.org/package/hoogle.
>
> I don't use it, but I imagine you would have to set documention: True in
> cabal.config, so you get documentation for any packages you have, and then
> either use your browser, or put an alias in your .ghci to query it in your
> repl, or just use the executable.
>
The appropriate entries for .ghci are:
:def hoogle \x -> return $ ":!hoogle \"" ++ x ++ "\""
:def doc \x -> return $ ":!hoogle --info \"" ++ x ++ "\""
That's actually close enough. However, the python & clojure commands use
the current search path, not a database build from the online docs. I
suspect this means I want a cabal command.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150326/fbb7fa30/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 26 Mar 2015 15:26:40 +0000
From: Shishir Srivastava <[email protected]>
To: beginners <[email protected]>
Subject: Re: [Haskell-beginners] Maybe and Just
Message-ID:
<CALe5RTtSst=tuog4ef5pratd-a8pat2xf+bhda71ku_bb1i...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150326/f3792e14/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 26 Mar 2015 11:46:45 -0400
From: Brandon Allbery <[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:
<CAKFCL4U=EuZ+3ojXwGe+9jSBLsT+nHvGv=-phh+tlrr8x1o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Thu, Mar 26, 2015 at 11:26 AM, 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
>
Because type inference won't work if you don't have a distinction between
an a and a Maybe a. Also, you end up back where you started --- there's a
distinguished (non)value that appears to be a value of the type, which
leaves you no better off than with C's NULL or Perl's undef, losing the
type safety of "this can't fail" vs. "this may fail and you must deal with
the failure somehow".
--
brandon s allbery kf8nh sine nomine associates
[email protected] [email protected]
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150326/e6dbc786/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 26 Mar 2015 16:48:31 +0100
From: Corentin Dupont <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>,
Shishir Srivastava <[email protected]>
Subject: Re: [Haskell-beginners] Maybe and Just
Message-ID:
<caeyhvmrzcdrrhcvwvz7t7i_nwr1brt1tke2yw7mq2d2mgpa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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/a09cd3c1/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 81, Issue 64
*****************************************
