Re: [Caml-list] Future of labels, and ideas for library labelling

[guttman@mitre.org (Joshua D. Guttman)]

I'm very grateful to Xavier Leroy for his posting.  I've been
listening to the labels discussion with increasing anxiety.  

I think we should make sure it remains possible to read and write Caml
code without added syntactic tangles; those tildes remind me of
whiskers.  More seriously, I find the syntax of Caml already fairly
obtrusive (versus Lisp and Scheme), and labels seem to me to make it a
good deal clumsier.  Why obstruct the fact that lots of code in a
language like OCaml is simply applying functions to arguments?  That's
the way it should be in a functional language.

Jacques Garrigue contrasts 

>   List.fold_right (List.fold_right IntSet.add) lists IntSet.empty

with 

>   
>      List.fold_left lists ~init:IntSet.empty
>        ~f:(fun set l ->
>              List.fold_left l ~init:set ~f:(fun set x -> IntSet.add x set))

and 

>      List.fold_left lists ~acc:IntSet.empty
>        ~f:(List.fold_left ~f:(fun ~acc item -> IntSet.add acc ~item))

To my eye, the original looks clean and compact.  The altered
versions?  They're not appealing to me.  

What are the arguments in favor of imposing labels on the rest of us?

1.  Optional arguments:  Well, this is occasionally useful, but I
    think not that often, at least in the kinds of programs I write.
    So the thing to achieve, in my opinion, is there should be no
    additional syntactic complication for writing or calling
    procedures that don't use them.

2.  Default values:  The Lisp-style solution to this was dynamic
    binding.  The default is stored in some mutable location; callers
    that want a different value store a new value and restore the
    original on return.  The language then provides some syntactic
    sugar (a macro) to make the alteration and restoration appear
    atomic, and to ensure that the default value is restored even in
    the case of non-local exit.  For instance, in the Yale dialect of
    Scheme, called T, there was a construct "bind".  I remember the
    manual saying, "Bind is syntactically similar to let but
    semantically very different."  The non-local exits were handled,
    within the "bind" macro definition, using unwind-protect, which
    was a primitive that would stipulate code to be run if the stack
    was unwound past the call site.

    I don't often need default values, but I expect that the
    equivalent could be rather easily implemented using exception
    handlers.  This would not affect any other aspect of the language.

3.  Documentation.  Why force every caller of a procedure to
    re-document the interface to the procedure?  That's what you're
    enforcing if the user has to write the labels.

    When it comes to documentation, there's no substitute for using
    the documentation itself.  Consider Emacs, the original
    self-documenting programming language (and it also contains a
    handy text editor :-).  Here the convention is that you document
    individual function definitions at a particular place; the
    "run-time system" then arranges for it to be very easy for users
    to access the documentation for every function (via C-h f).
    There's even completion if you type part of the name and want to
    see what function symbols start that way.  

    The etags program also provides a lot of support for people
    writing in other programming languages.  By the way, whatever
    happened to the OCaml mletags program?  I think it's been defunct
    since Ocaml 1.

    We could invent ways that people could get some of the benefit of
    the Emacs help system for Ocaml definitions documented in the
    manual.  I've been tinkering with an Emacs procedure that calls
    grep to find occurrences of a name in the manual, and W3 to
    display the corresponding HTML within Emacs.

    But the point here is to make documentation easily accessible, or
    to make it easy to find the site of definition for a procedure.
    It's wrong in my opinion to make the user repeat the documentation
    in the form of tilded labels at every use.  

4.  Commuting arguments.  This has to be a pretty specialized need,
    especially assuming programmers have easy access to documentation
    to find the intended order.  You're going to clutter a whole
    language to support this peripheral need?  


This language is complicated already.  It's extremely good, and I'm
doing my best to convert others to be followers of the cult too.  But
it's complicated, and we'll fight more losing battles to teach people
to use it if it becomes syntactically more cluttered.  Whether it's a
question of students (as in Benjamin Pierce's case) or colleagues (as
in mine), let's not block access to the really good (but subtle) ideas
in the language by complicating the way that it's written.

So my vote:  Please ensure that the programmer will not have to use
labels, except perhaps when using specialized libraries (e.g. for
GUIs).  

But to all participants, I'd like to say once more:  It's a splendid
language, the product of enormous intelligence and hard work, and I
appreciate being able to use it.

        Joshua 
-- 
	Joshua D. Guttman		<guttman@mitre.org> 
	MITRE, Mail Stop S119 
	202 Burlington Rd.		Tel:	+1 781 271 2654
	Bedford, MA 01730-1420 USA	Fax:	+1 781 271 3816

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