From: skaller <skaller@users.sourceforge.net>
To: Pierre Weis <pierre.weis@inria.fr>
Cc: Jon Harrop <postmaster@jdh30.plus.com>, caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] kprintf with user formatters
Date: 23 Jul 2004 08:42:05 +1000 [thread overview]
Message-ID: <1090536125.5870.150.camel@pelican.wigram> (raw)
In-Reply-To: <20040722173901.A18239@pauillac.inria.fr>
On Fri, 2004-07-23 at 01:39, Pierre Weis wrote:
> For instance, you would have a hard time to persuade a
> matematician that
>
> 0 * ln (0)
>
> is well-defined and evaluates to 0, ``because ln (0) has not to be
> considered at all given the left operand''.
Actually, this IS the case in many languages such as C.
0 is not in the domain of ln. Therefore, the result is undefined
when you apply ln to 0 because you're applying a function to a value
outside its domain. In language standards it is sometimes
said that the result is undefined in such cases, which means
that the compiler can generate code to do anything it wants
in such cases.
In particular it can return 0 and remain conforming
and therefore it can apply the shortcut evaluation.
This is NOT the case if the language standard specifies
an exception must be thrown, or NaN or +Inf returned,
which is generally a very bad idea precisely because it
makes the semantics determinate and thus defeats the
optimisation which could otherwise be obtained by
using the usual mathematical law 0 * x = 0.
C is very careful to leave lots of things undefined.
This issue actually arose directly on the C++ Standards
Committee, except the function was division not ln.
The question was whether a compiler was allowed and/or
required to issue a diagnostic error message given:
main() { return 1/0; }
Note that it is possible to prove IN THIS CASE
that the program will always fail by dividing by zero.
However, it isn't always so obvious -- so you simply cannot
require a diagnostic. Indeed, one can argue -- and
someone DID argue -- that even if the program always
fails when executed .. who knows if it is executed?
The code must be generated, C compiler can issue a warning
but it is NOT allowed to reject the program. It must
actually generated code which can be executed .. even though
that code can do anything (Aas far as I can remember that
was the interpretation..)
--
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850,
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net
-------------------
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:[~2004-07-22 22:42 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-30 16:32 Damien
2004-07-14 21:10 ` Pierre Weis
2004-07-15 0:17 ` Markus Mottl
2004-07-15 7:30 ` David MENTRE
2004-07-15 7:59 ` Jean-Christophe Filliatre
2004-07-15 23:35 ` henri dubois-ferriere
2004-07-15 7:39 ` Damien
2004-07-15 12:19 ` Markus Mottl
2004-07-15 12:42 ` Basile Starynkevitch [local]
2004-07-15 13:45 ` Markus Mottl
2004-07-15 14:22 ` Basile Starynkevitch [local]
2004-07-15 14:57 ` Markus Mottl
2004-07-16 6:47 ` Pierre Weis
2004-07-16 7:13 ` Jean-Christophe Filliatre
2004-07-16 7:23 ` henri dubois-ferriere
2004-07-16 7:44 ` Jean-Christophe Filliatre
2004-07-16 17:56 ` Markus Mottl
2004-07-19 9:17 ` Pierre Weis
2004-07-19 9:32 ` Jean-Christophe Filliatre
2004-07-16 7:21 ` henri dubois-ferriere
2004-07-16 17:44 ` Markus Mottl
2004-07-19 10:10 ` Pierre Weis
2004-07-19 10:43 ` Jon Harrop
2004-07-21 15:52 ` Pierre Weis
2004-07-21 17:43 ` lazyness in ocaml (was : [Caml-list] kprintf with user formatters) Daniel Bünzli
2004-07-22 16:28 ` Pierre Weis
2004-07-22 17:03 ` William Lovas
2004-07-22 23:00 ` skaller
2004-07-23 3:32 ` William Lovas
2004-07-28 7:26 ` Pierre Weis
2004-07-28 8:06 ` skaller
2004-07-28 8:29 ` Daniel Bünzli
2004-07-28 9:13 ` Pierre Weis
2004-07-28 9:36 ` skaller
2004-07-28 9:38 ` skaller
2004-07-28 10:17 ` Jason Smith
2004-07-28 12:31 ` skaller
2004-07-21 20:41 ` [Caml-list] kprintf with user formatters Jon Harrop
2004-07-22 15:39 ` Pierre Weis
2004-07-22 22:16 ` [Caml-list] lazy evaluation: [Was: kprintf with user formatters] skaller
2004-07-22 22:42 ` skaller [this message]
2004-07-22 8:05 ` [Caml-list] wait instruction lehalle@miriad
2004-07-22 8:40 ` Olivier Andrieu
2004-07-22 10:35 ` lehalle@miriad
2004-07-22 10:33 ` Vitaly Lugovsky
2004-07-16 6:17 ` [Caml-list] kprintf with user formatters Pierre Weis
2004-07-16 17:14 ` Markus Mottl
2004-07-19 10:00 ` Pierre Weis
2004-07-16 6:02 ` Pierre Weis
2004-07-16 8:42 ` Damien
2004-07-19 9:00 ` Pierre Weis
2004-07-16 16:52 ` Markus Mottl
2004-07-19 9:28 ` Pierre Weis
2004-07-15 22:20 ` Pierre Weis
2004-07-15 23:01 ` Markus Mottl
2004-07-16 16:17 ` james woodyatt
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=1090536125.5870.150.camel@pelican.wigram \
--to=skaller@users.sourceforge.net \
--cc=caml-list@inria.fr \
--cc=pierre.weis@inria.fr \
--cc=postmaster@jdh30.plus.com \
/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