caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Ville-Pertti Keinonen <will@exomi.com>
Cc: skaller@users.sourceforge.net,
	Nicolas Cannasse <warplayer@free.fr>,
	"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl>,
	caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Function forward declaration?
Date: 08 Apr 2004 01:12:47 +1000	[thread overview]
Message-ID: <1081350767.19232.638.camel@pelican> (raw)
In-Reply-To: <3B300570-889F-11D8-A3FA-000393863F70@exomi.com>

On Thu, 2004-04-08 at 00:24, Ville-Pertti Keinonen wrote:
> On Apr 7, 2004, at 4:52 PM, skaller wrote:

> Minor nit - you probably mean "idle thread"...and it really isn't 
> currently common in the above form, since most modern CPUs 

That may be true, but 99% of all real time code is executed
on archaic processors because of the price tag (we're talking
instrumentation and device control and $1 parts here .. )

> I'd expect (but haven't attempted to prove) detecting uninitialized 
> values to be equivalent to the halting problem, so there would 
> inevitably be cases that would need to be rejected, detected at 
> run-time or result in unsound programs.

I suspect you are right for a totally unconstrained
language, whatever that means.

However clearly, this isn't the case for
a constrained language: uninitialised values are impossible
in Ocaml as it stands and any fault is detected immediately
by the parser :D

I don't know the exact algorithm, but Java allows a variable
to be declared without an initialiser, provided it 
is 'manifestly assigned before use'. That condition is
reputedly easy to check by both machine and human.

Of course, Charity guarrantees termination, so with
the constraints it imposes the halting problem itself
is easily solved (it isn't Turing complete).

Perhaps then, your observation needs to be inverted
to a question: what is a reasonable balance between
expressiveness and error trapping?

The Ocaml solution is least expressive, and its STILL
fails to catch all errors because sometimes programs
have to 'cheat' the system by using the wrong type
for a variable, or a wrong value to initialise it,
or even Obj.magic (eg: variable length array cannot
be defined in Ocaml without cheating).

Still, I personally find most code can be organised
so the number of initialisation tricks is quite small
and not too offensive: there is just one I'm aware
of in Felix. 

That particular case isn't a result of the Ocaml language
per se, but its compilation model.

There is a record containing the build number, 
which changes every compilation,
the record is compiled last to avoid full recompile every time,
and so can't be accessed by the rest of the system. 
So an 'uninitialised variable' is used which is compiled first, 
and the last initialisation the program does is to store 
the build number constant into the variable.

That build number is used when Marshalling data,
to allow a check the same version of the binary
creates and reads the data: I don't do any marshalling
during "initialisation" .. :D

-- 
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


  reply	other threads:[~2004-04-07 15:13 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-06 12:14 Timo.Tapiola
2004-04-06 12:20 ` Andrew Birkett
2004-04-06 12:37 ` Remi Vanicat
2004-04-06 13:00   ` Issac Trotts
2004-04-06 12:53 ` Correnson Loïc
2004-04-06 15:14   ` skaller
2004-04-06 17:39   ` brogoff
2004-04-06 17:53     ` Richard Jones
2004-04-06 19:28       ` Marcin 'Qrczak' Kowalczyk
2004-04-06 22:37         ` Jon Harrop
2004-04-07  2:18         ` skaller
2004-04-07  6:01         ` Nicolas Cannasse
2004-04-07  7:31           ` Marcin 'Qrczak' Kowalczyk
2004-04-07 16:40             ` brogoff
2004-04-07 13:52           ` skaller
2004-04-07 14:15             ` Richard Jones
2002-01-03 15:21               ` Issac Trotts
2004-04-07 15:51               ` skaller
2004-04-07 16:41                 ` Richard Jones
2004-04-07 17:31                   ` Remi Vanicat
2004-04-07 17:36                     ` Richard Jones
2004-04-07 17:54                       ` Marcin 'Qrczak' Kowalczyk
2004-04-07 19:27                     ` skaller
2004-04-07 20:24                       ` Christopher Dutchyn
2004-04-07 18:04                   ` Benjamin Geer
2004-04-07 19:21                   ` skaller
2004-04-07 16:52               ` Shawn Wagner
2004-04-07 17:26               ` Basile Starynkevitch
2004-04-07 17:46                 ` Marcin 'Qrczak' Kowalczyk
2004-04-07 18:03                   ` Kenneth Knowles
2004-04-07 18:44                 ` Christopher Dutchyn
2004-04-07 14:24             ` Ville-Pertti Keinonen
2004-04-07 15:12               ` skaller [this message]
2004-04-06 12:58 ` Jean-Christophe Filliatre
2004-04-06 17:26 ` Christopher Dutchyn

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=1081350767.19232.638.camel@pelican \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=qrczak@knm.org.pl \
    --cc=warplayer@free.fr \
    --cc=will@exomi.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;
as well as URLs for NNTP newsgroup(s).