From: "David Allsopp" <dra-news@metastack.com>
To: <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] let rec and polymorphic functions
Date: Wed, 27 Jun 2007 11:24:53 +0100 [thread overview]
Message-ID: <001801c7b8a5$672a2b80$6a7ba8c0@treble> (raw)
In-Reply-To: <20070627100004.9E0DABC73@yquem.inria.fr>
> There are many problems with this. Google for ad-hoc polymorphism,
> polymorphic recursion and generic printing.
>
> On Wednesday 27 June 2007 09:40:31 David Allsopp wrote:
> > out "TEST";
>
> val out : string -> unit
>
> > out "%d" 0;
>
> val out : format -> int -> unit
The type-checker doesn't see that surely? Surely on that expression it sees
out : string -> int -> unit?? Note that changing the sequence to
out "%b" true;
out "%d" 0;
and removing the out "TEST" still causes problems - although O'Caml manages
to infer the [format4] first argument for [out], it fixes the first
parameter of the [format4] as being [bool -> unit] and so prevents [out]
from being used with anything other than a single "%b" argument and hence
gives a type error on the next application.
> As printf is ad-hoc polymorphic, you must supply the format specifier
> immediately and OCaml will generate a custom printer for you. OCaml does
> not use run-time types so you cannot have a generic print function: you
> must specific print functions for each of your (possibly higher-order)
> types.
Yes, except that what's odd to me is that the type-checker doesn't behave as
the manual says it ought to with [let rec]. BUT...
> Also, recursive calls ossify the function to a monomorphic type, so you
> cannot do polymorphic recursion in OCaml. There are workaround using
> recursive modules or objects but I don't think this is what you want here.
That does explain it - which I didn't know. Consider this which is also
broken (and simpler because it has nothing to do with the ad-hoc
polymorphism of printf)
let rec id x = x
and _ = id 0
in
id (); (* *** *)
id 1;;
Gives a type error for *** because id is already inferred as int -> int
because of the monomorphic nature of the recursive definition. This is
over-guarded but I never got an answer on a previous post as to why. The
equivalent SML does type polymorphically:
let fun id x = x
val _ = id 0
in
id ();
id 1
end;
Incidentally, it's lucky that this is polymorphic in SML because all
function definitions are recursive IIRC.
But no-one posted an explanation as to why there's this difference in the
let construct between the two flavours of ML :(
David
next parent reply other threads:[~2007-06-27 10:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070627100004.9E0DABC73@yquem.inria.fr>
2007-06-27 10:24 ` David Allsopp [this message]
2007-06-27 11:12 ` Jeremy Yallop
2007-06-27 11:29 ` David Allsopp
2007-06-27 12:00 ` Virgile Prevosto
2007-06-27 13:00 ` Jeremy Yallop
2007-06-27 13:12 ` Jon Harrop
2007-06-27 8:40 David Allsopp
2007-06-27 9:05 ` [Caml-list] " Jon Harrop
2007-06-27 10:14 ` Arnaud Spiwack
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='001801c7b8a5$672a2b80$6a7ba8c0@treble' \
--to=dra-news@metastack.com \
--cc=caml-list@yquem.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