From: Samuel Lacas <Samuel.Lacas@trusted-logic.fr>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Some/None
Date: Wed, 24 Apr 2002 17:43:53 +0200 [thread overview]
Message-ID: <20020424174353.A29676@ouessant.trusted-logic.fr> (raw)
In-Reply-To: <Pine.LNX.3.95.1020424161406.846D-100000@first.in-berlin.de>
Oliver Bandel a écrit 1.8K le Wed, Apr 24, 2002 at 04:23:34PM +0200:
#
# OK, In had typed it into the toplevel and as
# expected, it does not give back a pure type
# (like int's or strings).
# It gives back
# None
# or
# Some 8
# or
# Some "hello"
Naturally. The type ('int option) is not the same as the type "int",
because you have the "None" value.
# Is this really a common way of programming?
I suppose so.
# If I work on a list of integers or a list of
# strings, does it really have advantages to
# use such a type?
Yes: it allows you to manage an error case for a function supposed to
return a value of type a, but which may sometimes return nothing. It's
lighter than exceptions (I think) and much more safe than having a
"null" pointer-style ugly coding (or other twisted way such as saying
"return -1" if not found).
# Pattern match itself is not functional.
Don't know, but without much thinking, no imperative language having a
similar mechanism built-in comes to my mind. Don't trust me, though :)
# How can such things be expressed in a functional
# way? (Maybe I have to try it in Haskell, it's
# constraints to be functional are much stronger;
# when using Ocaml it seems to be that very often
# the imperative style creeps in - even unconsciously).
Haskell preludes contains:
-- Maybe type
data Maybe a = Nothing | Just a deriving (Eq, Ord, Read, Show)
which serves exactly the same. Replace Maybe by option, Nothing by
None, and Just by Some. No "unconscious" imperative creeping here :)
sL
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next prev parent reply other threads:[~2002-04-24 15:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-24 12:48 Oliver Bandel
2002-04-24 13:31 ` Michal Moskal
2002-04-24 14:23 ` Oliver Bandel
2002-04-24 15:43 ` Samuel Lacas [this message]
2002-04-24 13:41 ` Markus Mottl
2002-04-24 15:59 ` Oliver Bandel
2002-04-24 13:50 ` Oliver Bandel
2002-04-24 14:08 ` Xavier Leroy
2002-04-24 19:19 ` Oliver Bandel
2002-04-24 14:28 ` Remi VANICAT
2002-04-24 14:55 ` John Max Skaller
2002-04-24 16:49 ` Oliver Bandel
2002-04-25 1:46 ` John Max Skaller
2002-04-25 12:13 ` Oliver Bandel
2002-04-25 12:34 ` Markus Mottl
2002-04-25 12:53 ` Jérôme Marant
2002-04-25 13:13 ` Markus Mottl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020424174353.A29676@ouessant.trusted-logic.fr \
--to=samuel.lacas@trusted-logic.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox