caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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


  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;
as well as URLs for NNTP newsgroup(s).