From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA23789; Tue, 3 Apr 2001 15:43:51 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA23647 for ; Tue, 3 Apr 2001 15:43:50 +0200 (MET DST) Received: from mail.cs.uu.nl (sunset.cs.uu.nl [131.211.80.32]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f33DhnP09677 for ; Tue, 3 Apr 2001 15:43:49 +0200 (MET DST) Received: from silvester.cs.uu.nl (silvester.cs.uu.nl [131.211.80.119]) by mail.cs.uu.nl (Postfix) with SMTP id 39618451C for ; Tue, 3 Apr 2001 15:43:49 +0200 (MET DST) Received: by silvester.cs.uu.nl (sSMTP sendmail emulation); Tue, 3 Apr 2001 15:43:49 +0200 Date: Tue, 3 Apr 2001 15:43:48 +0200 From: Frank Atanassow To: caml-list@inria.fr Subject: Re: [Caml-list] Future of labels, and ideas for library labelling Message-ID: <20010403154348.A17049@cs.uu.nl> References: <20010403093527G.garrigue@kurims.kyoto-u.ac.jp> <20010403125314Q.garrigue@kurims.kyoto-u.ac.jp> <20010403105212.A15700@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010403105212.A15700@pauillac.inria.fr>; from Xavier.Leroy@inria.fr on Tue, Apr 03, 2001 at 10:52:12AM +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk I'm neutral on the future of labels; I'll use Ocaml in whatever form it takes. But I just want to make some observations. First, I think there is a tension on a larger scale between: * using labels in a library to distinguish arguments of functions with many arguments, and * refactoring a library to use a combinator-style approach as you often see in Haskell programs, for example with parsers, pretty-printers and GUI libraries. Personally, I think the combinator-style libraries are more flexible and more interesting than the more conventional monolithic approach, but in Ocaml I feel there is a bias towards more traditional approaches to library development which makes labels useful in practice. Also, even when, like me, you prefer the combinator style, interfaces to foreign programs---which all inevitably adopt the monolithic approach---are usually arranged in two layers, the lower being a thin layer which just makes the foreign functions directly available in the Ocaml language, and the upper being a thick layer which decomposes monolithic operations into combinators, and for writing the thin layer labels are still clearly a boon. Second, in practice my biggest complaint about labels is the need to eta-expand arguments of higher-order functions. I find it truly annoying. Really. It just feels wrong that I have to relabel a function argument, even if I'm not passing it any parameters. To me, this suggests that labels do not belong in the type of a function, and rather that labels should really only be an elaboration of the function application syntax. (So, instead of one syntactic construct for application, namely juxtaposition, you have an infinite number, one for each sequence of labels.) But that is a much more fundamental issue, and is outside the scope of this discussion... Lastly, I just have a small syntax suggestion. Xavier Leroy wrote (on 03-04-01 10:52 +0200): > (One consequence of this requirement is the ~label:arg syntax, because > the label:arg syntax of OLabl and OCaml 2.99 was causing syntax > ambiguities with type constraints ident:type and thus breaking > backward compatibility.) Patrick complained about the ~label:arg syntax. I think it is tiresome too. An alternative is to force labels to be uppercase identifiers and get rid of the leading tilde. This is not 100% backwards compatible, but I think it only overlaps with the case where you provide a type constraint for a nullary data constructor, which is quite uncommon. It also ensures there is no overlap between keywords and labels, and looks quite suggestive for folds: List.foldr xs Cons:(+) Nil:0 Oh yeah, and I do think structural folds should be labeled by the constructors of the datatype you are deconstructing. It is more meaningful than using names like ~f: or ~funct:, which does not scale to the general initial algebra case anyway. I have no suggestion for treating foldl-type things. -- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-3261 Fax +31 (030) 251-379 ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr