From: skaller <skaller@users.sourceforge.net>
To: Brian Hurt <bhurt@spnz.org>
Cc: brogoff <brogoff@speakeasy.net>, caml-list <caml-list@inria.fr>
Subject: Re: Ant: [Caml-list] The "Objective" part of Objective Caml
Date: Wed, 09 Nov 2005 20:00:02 +1100 [thread overview]
Message-ID: <1131526802.13828.76.camel@rosella> (raw)
In-Reply-To: <Pine.LNX.4.63.0511081550440.32476@localhost.localdomain>
On Tue, 2005-11-08 at 16:04 -0600, Brian Hurt wrote:
> Yes. For example, Ocaml will reject this code:
> let f n =
> if (n > 0) && (is_prime (2*n)) then
> "bad idea"
> else
> false
> ;;
>
> despite the fact that "bad idea" will never, ever be returned (given the
> obvious definition of is_prime, anyways).
This is an interesting case, IMHO. A related case arose
in C++ and was discussed by the committee: something like:
int x = 1/0;
The question was: is the compiler allowed to reject the program?
I believe the current answer is: IF the compiler can prove
that this code will necessarily be executed, then the behaviour
of the program is undefined anyhow, and so the compiler is allowed
to reject the program -- but it is NOT required to.
However, IF the compiler cannot prove the code will be executed,
then it must compile the program.
The interesting thing is that 1/0 is a 'constant expression'.
However this is not:
int a = 0; int b = 1;
int c = b/a;
In Felix, certain constructions are *required* to be optimised
at compile time. In particular,
1/0
is a 'constant expression' and MUST be calculated at compile time.
However, as above, the compiler is not allowed to reject the program,
just because a constant expression cannot be calculated -- it has
to generate code that aborts the program or something, in case that
expression is never elaborated (this was a pain to get right,
and probably isn't yet)
In particular this is perfectly legal Felix:
if true then 1 else 1/0 endif
and is REQUIRED to reduce to 1. Similarly:
if true then 1 else "Hello" endif
is perfectly legal. The 'if/then/else/endif' construction
is being reused as a macro processing construction: there
is no type error here.
So .. it all depends on exactly how the language is specified.
BTW: I am not sure I like these preprocessor reduction rules.
The idea was to 'get rid' of #if style conditional compilation.
Without these kinds of rules, constant folding is effectively
impossible.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
next prev parent reply other threads:[~2005-11-09 9:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-04 22:45 Florian Weimer
2005-11-07 21:41 ` Ant: [Caml-list] " Martin Chabr
2005-11-07 21:55 ` Florian Weimer
2005-11-08 1:47 ` skaller
2005-11-08 2:15 ` Brian Hurt
2005-11-08 7:15 ` Daniel Bünzli
2005-11-08 15:02 ` Brian Hurt
2005-11-08 15:39 ` Alexander Fuchs
2005-11-08 15:42 ` Matt Gushee
2005-11-08 15:56 ` Michael Wohlwend
2005-11-08 18:16 ` brogoff
2005-11-08 22:04 ` Brian Hurt
2005-11-08 23:40 ` brogoff
2005-11-09 9:00 ` skaller [this message]
2005-11-11 15:28 ` Florian Weimer
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=1131526802.13828.76.camel@rosella \
--to=skaller@users.sourceforge.net \
--cc=bhurt@spnz.org \
--cc=brogoff@speakeasy.net \
--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