From: art yerkes <ayerkes@speakeasy.net>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Using -dtypes output in conjunction with a preprocessor
Date: Fri, 22 Aug 2003 09:27:33 -0500 [thread overview]
Message-ID: <20030822092733.612218c9.ayerkes@speakeasy.net> (raw)
In-Reply-To: <20030822090518.GA4616@roke.freak>
On Fri, 22 Aug 2003 11:05:18 +0200
Michal Moskal <malekith@pld-linux.org> wrote:
>
> How about:
>
> let f x y = foo x y
>
> and:
>
> let g x y =
> let baz = foo x y in
> let qux = foo baz baz in
> x + 1
Yes, I know that it's not always possible for caml to predict the type, but
the user can resolve such a case with a type annotation. Alternately, I can
write in the 'default' case that leaves the data unmarshalled. In either
case it's just as much an error to try to have the language guess what types
C++ needs as it would be in C++.
In addition, I have done several experiments which show that Ocaml does
correctly type polymorphic applications that have no other possible types.
If you examine the -dtypes output for this code fragment, you'll notice that
the expression at character 78 (as recokoned by -dtypes) is correctly typed,
even though the real type is unspecified:
external ___swig___make_point1 : 'a -> 'b -> 'c = "make_point"
let _ = match ___swig___make_point1 3 3 with
(a,b) -> print_endline ((string_of_int a) ^ "," ^ (string_of_int b))
| _ -> ()
If it interests you, here is how Ocaml's type inference *actually* works:
"typefoo.ml" 3 64 78 "typefoo.ml" 3 64 99
type(
int -> int -> int * int
)
The reason why Ocaml can do this, in my recokoning is that any other
signature given for this expression would be an error. As far as I can
tell, Ocaml will always place a concrete type on an unambiguous expression.
Perhaps Mr. Leroy or one of the other gurus can set me straight, however.
My goal is not necessarily any philosophical purity. I know that some cases
do fail to unify, and I believe thats OK. What I'm fighting is a basic
disconnect between the notion of a statically typed overloaded application
in C++, and the Ocaml rule that a certain named value has exactly one type.
I've looked at gcaml for this same reason, B.T.W, but since I'm trying to
balance practical with not, I believe that making the most of the standard
Ocaml is best.
--
"Should array indices start at 0 or 1? My compromise of 0.5 was rejected
without, I thought, proper consideration."
- S. Kelly-Bootle
-------------------
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:[~2003-08-22 14:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-22 7:39 art yerkes
2003-08-22 9:05 ` Michal Moskal
2003-08-22 14:27 ` art yerkes [this message]
2003-08-24 15:14 ` [Caml-list] GlSurf 2.0 Christophe Raffalli
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=20030822092733.612218c9.ayerkes@speakeasy.net \
--to=ayerkes@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