From: Patrick M Doane <patrick@watson.org>
To: Jun Furuse <Jun.Furuse@inria.fr>
Cc: caml-list@inria.fr
Subject: Re: "Re: [Caml-list] A G'Caml question" + additional info
Date: Wed, 27 Jun 2001 22:21:29 -0400 (EDT) [thread overview]
Message-ID: <Pine.BSF.3.96.1010627215149.20968A-100000@fledge.watson.org> (raw)
In-Reply-To: <20010625191156X.Jun.Furuse@inria.fr>
On Mon, 25 Jun 2001, Jun Furuse wrote:
> Thus, the generic values are "open" to the others who include them,
> but it is not the open recursion you mentioned; print and print' are
> different values and independent each other.
>
> We do not want to introduce the full open recursion to generic
> values. You could add new type cases easily using the open recursion
> and it should be helpful in some cases. But it can also introduce
> heavy semantic confusion to our programs, since in the open recursion
> the semantics of generic values could not be fixed until all modules
> are linked together.
I agree that this could make programs more difficult to follow, but I
think it is to be expected with generic programming these days.
Also, isn't this kind of semantic confusion already present with using the
object oriented system?
In the following example, writing definitions like MyProgram.print may get
very tedious in practice.
module Int = struct
generic print = case int -> unit => print_int
end
module String = struct
generic print = case string -> unit => print_string
end
module List = struct
generic print =
case $a list -> unit => function [] -> () | x :: xs -> print x; print xs
end
module MyProgram = struct
generic print = case
| include Int.print
| include String.print
| include List.print
(* all other print functions to follow *)
end
Given what is done with Haskell type classes and C++ templates, it seems
more confusing to me to not support open recursion. Any thoughts?
Patrick
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
next prev parent reply other threads:[~2001-06-28 2:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-20 3:16 [Caml-list] A G'Caml question Brian Rogoff
2001-06-25 17:11 ` "Re: [Caml-list] A G'Caml question" + additional info Jun Furuse
2001-06-28 2:21 ` Patrick M Doane [this message]
2001-06-28 4:40 ` Brian Rogoff
[not found] <3B3BB6EC.3DEB6CBF@ozemail.com.au>
2001-06-29 4:18 ` Patrick M Doane
[not found] <3B3D503C.E91DDE34@ozemail.com.au>
2001-06-30 16:01 ` Patrick M Doane
2001-06-30 20:59 ` Brian Rogoff
2001-07-01 5:32 ` Patrick M Doane
2001-07-02 15:55 ` Brian Rogoff
2001-07-10 18:08 ` Patrick M Doane
2001-07-10 18:21 Krishnaswami, Neel
2001-07-11 6:09 ` Sven
2001-07-11 14:30 Krishnaswami, Neel
2001-07-11 16:22 ` Brian Rogoff
2001-07-11 16:35 ` Bruce Hoult
2001-07-11 19:12 ` Markus Mottl
2001-07-12 3:15 ` Patrick M Doane
2001-07-16 18:24 John R Harrison
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=Pine.BSF.3.96.1010627215149.20968A-100000@fledge.watson.org \
--to=patrick@watson.org \
--cc=Jun.Furuse@inria.fr \
--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