caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Brian Rogoff <bpr@best.com>
To: Markus Mottl <mottl@miss.wu-wien.ac.at>
Cc: Hendrik Tews <tews@tcs.inf.tu-dresden.de>, OCAML <caml-list@inria.fr>
Subject: Re: [Caml-list] recursive modules redux, & interface files
Date: Thu, 22 Mar 2001 08:56:25 -0800 (PST)	[thread overview]
Message-ID: <Pine.BSF.4.21.0103220834270.28285-100000@shell5.ba.best.com> (raw)
In-Reply-To: <20010322140157.A7070@miss.wu-wien.ac.at>

On Thu, 22 Mar 2001, Markus Mottl wrote:
> Hendrik Tews schrieb am Thursday, den 22. March 2001:
> > I would like to vote for solutions that work for the common case
> > when writing large programs, even if they are hacks, considered
> > from a theoretical point of view.
> 
> I am not so fond of sacrificing theoretical beauty: it usually seems
> to be the case that there are working solutions that are also elegant -
> it's only a matter of thinking about them long enough. You might speed
> up development a bit by allowing hacks if you cannot immediately find
> a sound solution, but IMHO it is hardly ever a good idea in the long run.

I agree with this general principle, and to be honest, I haven't found in
my own programming a compelling case where module spanning mutually
recursive function definitions were an issue. Is it possible to produce a 
reasonably sized example, Hendrik (or Chris)? I'm annoyed by the inability
to have a mutually recursive *type* definition and functor instantiation,
and that problem can be solved with recursive modules (Claudio Russo says 
it works in a development version of Mosml), but I haven't had this
problem with functions yet. 

As an aside, Claudio mentioned that it would be easy to extend OCaml to 
support this feature: are there any plans to do so? If not, maybe I'll 
push for it when the Consortium is set up. 

> > Cross module recursion of functions is soo useful, that it
> > should be made to work --- even if the solution seems stupid with
> > respect to the example above.

I agree that the workaround is a tiny bit ugly, but I'm not convinced that
the problem is so great that it justifies any kind of new kludge. Convince 
me! My mind is open (or include'ed :) 

> Nearly everytime I had thought "now I need recursive modules", I found
> other, even elegant ways to do it. 

How about the case I mention above? I think that there are a few cases
where some extensions are necessary, however...

> If we really want them, please let's don't put aside theory but take
> existing clean solutions (e.g. see Claudio Russo's thesis).

Yes. Let's have the extensions be clean, well founded ones. Even some
people in industry realize that this is the right way to go. :-)

I've snipped the module inclusion stuff because I think that while the 
need for a workaround is unfortunate, I think that there are bigger fish
to fry.

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr


  reply	other threads:[~2001-03-22 16:56 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-18 23:05 Chris Hecker
2001-03-19  0:01 ` Brian Rogoff
2001-03-19 11:04 ` John Max Skaller
2001-03-19 11:41   ` Chris Hecker
2001-03-20 17:43     ` John Max Skaller
2001-03-21  4:03       ` Chris Hecker
2001-03-21  5:10         ` Patrick M Doane
2001-03-21  9:27           ` Chris Hecker
2001-03-21 18:20           ` John Max Skaller
2001-03-22  0:03             ` Patrick M Doane
2001-03-22  0:22               ` Brian Rogoff
2001-03-22 10:26                 ` [Caml-list] duplication implementation/interface Judicael Courant
2001-03-22 11:16                   ` [Caml-list] about typedefs... (was: duplication implementation/interface) Olivier Andrieu
2001-03-22 17:14                   ` [Caml-list] duplication implementation/interface Brian Rogoff
2001-03-22  9:11               ` [Caml-list] recursive modules redux, & interface files Francois Pottier
2001-03-21 23:24           ` John Prevost
2001-03-22  0:00             ` Patrick M Doane
2001-03-21 18:18         ` John Max Skaller
2001-03-21 18:19         ` John Max Skaller
2001-03-22 11:40   ` Markus Mottl
2001-03-21 18:41 ` Xavier Leroy
2001-03-22  0:23   ` Patrick M Doane
2001-03-22 12:02   ` Hendrik Tews
2001-03-22 13:01     ` Markus Mottl
2001-03-22 16:56       ` Brian Rogoff [this message]
2001-03-22 17:13         ` Daniel de Rauglaudre
2001-03-23 17:30         ` Fergus Henderson
2001-03-23 18:04           ` Brian Rogoff
2001-03-23 20:35             ` [Caml-list] Why People Aren't Using OCAML? (was Haskell) Mattias Waldau
2001-03-26  2:29             ` [Caml-list] recursive modules redux, & interface files Fergus Henderson
2001-03-27 22:11         ` John Max Skaller
2001-03-28  4:30           ` Brian Rogoff
2001-04-05 17:07             ` John Max Skaller
2001-03-27  8:21       ` Hendrik Tews
2001-03-30 10:27   ` [Caml-list] parser combinators Kevin Backhouse
2001-04-08 18:28     ` Daniel de Rauglaudre
2001-03-22 11:55 [Caml-list] recursive modules redux, & interface files Dave Berry
2001-03-22 12:01 ` Markus Mottl
2001-03-27  6:29 ` John Max Skaller
2001-03-22 18:04 Dave Berry
2001-03-23  7:54 ` Tom Hirschowitz
2001-03-23 12:18   ` Fabrice Le Fessant
2001-03-27  8:49   ` Hendrik Tews
2001-03-23 10:33 Dave Berry
2001-03-23 20:33 Don Syme
2001-03-27  9:00 ` Xavier Leroy
2001-03-27 14:38 Don Syme
2001-03-27 17:05 Manuel Fahndrich

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.4.21.0103220834270.28285-100000@shell5.ba.best.com \
    --to=bpr@best.com \
    --cc=caml-list@inria.fr \
    --cc=mottl@miss.wu-wien.ac.at \
    --cc=tews@tcs.inf.tu-dresden.de \
    /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).