caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Ohad Rodeh" <ORODEH@il.ibm.com>
To: caml-list@inria.fr, Michael Vanier <mvanier@cs.caltech.edu>
Subject: Re: [Caml-list] Namespace proposal
Date: Thu, 15 Aug 2002 12:43:58 +0300	[thread overview]
Message-ID: <OFC20CC119.93D8C98E-ONC2256C16.0034ECE9@telaviv.ibm.com> (raw)


I liked the "ocaml forever" bit :-).

My personal experience has been that all the <reasonable> modifications
I've requested from the Caml folk were carried out. On the other hand, I
can
easily think of some <non-reasonable> language modifications. As long
as the core developers are willing to listen to the community, I don't
think
there is a big problem.

By the way, I do think we need some kind of package/namespace approach.
My personal contribution was the "emrg" mini-tool, adapted from the
Ensemble
distribution. Also, the Caml team was convinced enough that namespaces were
an issue to add the "-pack" option to v3.05.

Just my two cents,
      Ohad.

-----------------------------------------------------------------------------------

Ohad Rodeh
tel: +972-3-6401641
IBM Haifa, storage research


                                                                                                                                            
                      Michael Vanier                                                                                                        
                      <mvanier@cs.caltech.ed        To:       yrashk@openeas.org                                                            
                      u>                            cc:       caml-list@inria.fr                                                            
                      Sent by:                      Subject:  Re: [Caml-list] Namespace proposal                                            
                      owner-caml-list@pauill                                                                                                
                      ac.inria.fr                                                                                                           
                                                                                                                                            
                                                                                                                                            
                      12/08/2002 20:31                                                                                                      
                                                                                                                                            
                                                                                                                                            




The namespace proposal brings up a related issue.  Is there any interest in
having a more formal process for making requests for enhancements to the
ocaml language analogous to (e.g.) the Python Enhancement Proposals (PEPs)
for python (http://www.python.org/peps) or similar processes for perl,
ruby, and java?  I can see advantages and disadvantages to this approach.
The advantage is that there is an organized record of proposals, commentary
on proposals, etc.  The disadvantage is that I suspect that a lot of
feature requests might be unimplementable or require a huge amount of
research to see if they're implementable (e.g. generically overloaded
operators), as opposed to PEPs, which are generally fairly trivial.  What
do people think?

Ocaml forever,

Mike
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives:
http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


             reply	other threads:[~2002-08-15  9:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-15  9:43 Ohad Rodeh [this message]
2002-08-15 13:27 ` Vitaly Lugovsky
2002-08-15 14:23   ` Yurii A. Rashkovskii
2002-08-15 15:53     ` Vitaly Lugovsky
  -- strict thread matches above, loose matches on Subject: below --
2002-08-15 20:42 Gurr, David (MED, self)
2002-08-16  9:19 ` Vitaly Lugovsky
2002-08-15 20:42 Gurr, David (MED, self)
2002-08-15 17:13 Gurr, David (MED, self)
2002-08-15 17:18 ` Vitaly Lugovsky
2002-08-15 17:53   ` Yurii A. Rashkovskii
2002-08-16  8:52   ` M E Leypold @ labnet
2002-08-16  9:22     ` Vitaly Lugovsky
2002-08-16 10:20       ` Yurii A. Rashkovskii
2002-08-15 17:46 ` Fernando Alegre
2002-08-15 16:21 Gurr, David (MED, self)
2002-08-15 17:00 ` Vitaly Lugovsky
2002-08-18 17:05 ` John Max Skaller
2002-08-12 20:40 Yurii A. Rashkovskii
2002-08-12 14:19 Yurii A. Rashkovskii
2002-08-12 17:31 ` Michael Vanier

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=OFC20CC119.93D8C98E-ONC2256C16.0034ECE9@telaviv.ibm.com \
    --to=orodeh@il.ibm.com \
    --cc=caml-list@inria.fr \
    --cc=mvanier@cs.caltech.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).