caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: nystrom@cs.cornell.edu
Cc: caml-list@yquem.inria.fr, andru@cs.cornell.edu
Subject: Re: [Caml-list] Possibility of Nested Classes and Nested Inheritance?
Date: Mon, 27 Dec 2004 11:24:08 +0900 (JST)	[thread overview]
Message-ID: <20041227.112408.18229510.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <CFEDD357-55E4-11D9-9B74-000A958B604C@cs.cornell.edu>

A small complement to my previous post.

From: Nate Nystrom <nystrom@cs.cornell.edu>

> Furthermore, to allow extension, recursion is left open for
> the functions implementing the compiler passes and then closed
> in order to invoke the function on a particular type.  Thus, when a new 
> variant is added, a small amount of code for each open recursive
> function needs to be written to close the recursion with the new type.

This kind of practical problems could be easily solved by syntactic
sugar.
Yet, you can see a direct approach (without sugar) in this code sample
  http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/mixin2.ml.txt
The idea is to use classes like modules with inheritance and
recursion (using lazyness to get a fixpoint). So we get closer to your
approach.
(I've cleaned-up a little, but this code has been at this URL for years.)


Another more general remark, which might seem somehow contradictory,
is that functional programs do not have the same notion of modularity.
In particular, as the typing helps a lot, this is not seen as a
problem to directly modify existing code (which modular extension
prohibits).
So one writes code with the possibility of future modifications in
mind, making it more robust by avoiding ad-hoc defaults. When you have
no default, the type checker can track changes to types, and force you
to modify relevant code.

Jacques Garrigue


  parent reply	other threads:[~2004-12-27  2:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20041217184433.GA1036@balm.cs.cornell.edu>
2004-12-24 19:48 ` Nate Nystrom
2004-12-25  0:26   ` skaller
2004-12-25 10:59   ` Jacques Garrigue
2004-12-27  2:24   ` Jacques Garrigue [this message]
2004-12-16 14:59 Jørgen Hermanrud Fjeld
2004-12-16 21:50 ` [Caml-list] " John Prevost
2004-12-17  1:31 ` Jacques Garrigue

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=20041227.112408.18229510.garrigue@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=andru@cs.cornell.edu \
    --cc=caml-list@yquem.inria.fr \
    --cc=nystrom@cs.cornell.edu \
    /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).