From: skaller <skaller@users.sourceforge.net>
To: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
Cc: kremenek@cs.stanford.edu, caml-list@inria.fr
Subject: Re: [Caml-list] Class/prototype-based OO
Date: Thu, 31 Aug 2006 15:18:21 +1000 [thread overview]
Message-ID: <1157001502.6555.12.camel@rosella.wigram> (raw)
In-Reply-To: <20060831.101146.29126305.garrigue@math.nagoya-u.ac.jp>
On Thu, 2006-08-31 at 10:11 +0900, Jacques Garrigue wrote:
> From: Ted Kremenek <kremenek@cs.stanford.edu>
> Since this approach does not modify the compiler, or use any unsafe
> feature, it does not break abstraction in any way.
If you re-read that claim .. you can see that Ocaml is used
for something *other* than programming.
It is used to *prove* the safety of a technique. Such high
level reasoning is only possible because of the rigid adherence
to type safety.
The difference between Jacques 'Hashtable' for downcasts
and system generated RTTI is that the latter would have
to be enshrined in the type system, whereas the former,
whilst potentially performing the same function if used
systematically, exhibits its own typing within the
type system.
So in fact, as is typical of advanced languages, one could
make a claim for the addition of some feature, by demonstrating
it can be done already as sugar .. the demonstration then
proves safety and inspires the implementation .. and in
particular the typing of it.
Most interestingly here .. with campl4 as a standard tool
you can do quite a bit of such sugaring yourself!
> Independently of downcasting, RTTI would also be needed for providing
> more information in the debugger. But there seems not to be much
> demand for that.
I would note it is difficult to judge the utility of a missing
feature :)
Try to tell someone in the C++ community that C++ is severely
constrained because it doesn't have first class lexically
scoped functions, variants, or pattern matching .. even
if you explain what they are they'll just say "Oh, we can
do that this way .. but don't have much call for it".
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
next prev parent reply other threads:[~2006-08-31 5:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-25 7:51 David Baelde
2006-08-25 11:31 ` [Caml-list] " skaller
2006-08-29 3:11 ` Ted Kremenek
2006-08-29 5:53 ` skaller
2006-08-30 23:57 ` brogoff
2006-08-29 12:03 ` Gerd Stolpmann
2006-08-29 17:56 ` Ted Kremenek
2006-08-29 18:13 ` Ted Kremenek
2006-08-31 1:11 ` Jacques Garrigue
2006-08-31 5:18 ` skaller [this message]
2006-08-31 6:36 ` Jacques Garrigue
2006-08-31 7:15 ` skaller
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=1157001502.6555.12.camel@rosella.wigram \
--to=skaller@users.sourceforge.net \
--cc=caml-list@inria.fr \
--cc=garrigue@math.nagoya-u.ac.jp \
--cc=kremenek@cs.stanford.edu \
/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