caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Markus Mottl <mottl@miss.wu-wien.ac.at>
To: Jan Skibinski <jans@numeric-quest.com>
Cc: OCAML <caml-list@inria.fr>
Subject: Re: Announcement: LACAML
Date: Thu, 25 Jan 2001 13:58:07 +0100	[thread overview]
Message-ID: <20010125135807.A18259@miss.wu-wien.ac.at> (raw)
In-Reply-To: <Pine.LNX.4.21.0101250144290.9468-100000@info.numeric-quest.com>; from jans@numeric-quest.com on Thu, Jan 25, 2001 at 02:21:47 -0500

On Thu, 25 Jan 2001, Jan Skibinski wrote:
> 	But the result was stunningly clear, consise and easy to
> 	understand even by the beginners. 
> 	I do not know whether similar approach would be feasible with
> 	Ocaml objects, but if yes then I would recommend it highly.

I think that default arguments in OCaml are a very fine means to hide the
complexity of function interfaces without sacrificing richness of features
and efficiency. Using objects would also be a solution, but having to call
methods of objects to parameterize them does not seem so natural to me.

Some time ago, when there was a flame war on this list whether labels are
really of any use, I tried several ways of parameterisation (objects,
option lists, default arguments), and I found that default arguments
were both the most elegant and the most efficient solution. Furthermore,
I am somewhat reluctant what concerns using objects, but that's another
story...

> >   * To make things easy for people used to the "real" implementation
> >     in FORTRAN but also for beginners who need detailed documentation,
> >     both function- and argument names have been kept compatible to the
> >     ones used in the BLAS- and LAPACK-documentation. 
> 
> 	I do not see a need for this. The names are probably as awkward
> 	as in NAG. Just consistently refer to the original names in your
> 	documentation and you should be fine.

Funny as it may seem, I find awkward names easier to remember. If names
become too similar, which may happen when there are so many functions
for similar problems, one can easily mix them up. Humans don't seem to
have problems memorizing thousands of foreign words so using "awkward"
names for functions is probably less confusing than requiring people
to lookup different identifiers in documentation. (Btw., there is some
logic behind the naming of BLAS- and LAPACK-functions).

- Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl



  reply	other threads:[~2001-01-26 21:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-25  0:11 Markus Mottl
2001-01-25  7:21 ` Jan Skibinski
2001-01-25 12:58   ` Markus Mottl [this message]
2001-01-25 11:20     ` Jan Skibinski
2001-01-25 16:46       ` Markus Mottl

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=20010125135807.A18259@miss.wu-wien.ac.at \
    --to=mottl@miss.wu-wien.ac.at \
    --cc=caml-list@inria.fr \
    --cc=jans@numeric-quest.com \
    /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).