caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Hendrik Tews <tews@tcs.inf.tu-dresden.de>
To: OCAML <caml-list@inria.fr>
Subject: Re: [Caml-list] recursive modules redux, & interface files
Date: Tue, 27 Mar 2001 10:21:23 +0200	[thread overview]
Message-ID: <E14hojD-0006jU-00@ithif51> (raw)
In-Reply-To: <20010322140157.A7070@miss.wu-wien.ac.at>

Hi,

Markus Mottl writes:
   From: Markus Mottl <mottl@miss.wu-wien.ac.at>
   Date: Thu, 22 Mar 2001 14:01:57 +0100
   Subject: Re: [Caml-list] recursive modules redux, & interface files
   
   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.
   
[As an aside: In principle I do not agree that usually there
 exist elegant solutions. This would imply that for most problems
 there are elegant solutions, whereas the attribute elegant can
 only apply to a small subset of all solutions (unless everything
 is elegant).
]

But for the main problem of mutual recursion: I would also
appreciate a theoretically nice solution. But ocaml and its
predecessors have been around now for long time, so it seems that
it is not that easy to find a good solution for mutal recursion
between modules. So instead of waiting another three years I
would prefer a solution now, even if it is intermediate and not
so clean.

   If there is a problem with expressiveness or
   else, it seems to be better to first try harder to find a solution with
   the existing system before crying for a hacky extension. And if this
   doesn't work, let's try to find a more expressive theory rather than
   abandoning theory completely.
   
I agree, don't let's abandoning theory. But let's make a few
compromises, where a good solution is not available in the near
future. 

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

I know, with some effort you can put every system in a linear
structure and avoid module spanning recursion. But I do not want
to restructure the whole project, only because I need some
recursive functions. The more important point is that in a
project with several people the overall complexity of the system
structure must stay below a certain limit. If you create a system
structure that is above this limit, then the project will fail.

   
   >    [duplications in signatures and structures]
   
   The solution to put the whole signature into a separate .ml-file requires
   hardly any work and solves this problem neatly. Why introduce a kludge
   if there are reasonable ways to do it?
   
I have the same argument here. Keeping three files instead of two
is more complex. As a programmer you have to pay for this
complexity and it doesn't buy you anything. The result is that
people do not write interfaces because they do not like the
additional effort it requires. 


Bye,

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


  parent reply	other threads:[~2001-03-27  8:21 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
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 [this message]
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=E14hojD-0006jU-00@ithif51 \
    --to=tews@tcs.inf.tu-dresden.de \
    --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).