caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Steven Thomson <sthomson@zeta.org.au>
To: caml-list@inria.fr
Subject: Re: Syntax for label, ANOTHER NEW PROPOSAL
Date: Sat, 18 Mar 2000 10:04:22 +1000	[thread overview]
Message-ID: <38D2C806.219E784B@zeta.org.au> (raw)
In-Reply-To: <20000315145830.22463@pauillac.inria.fr>


Pierre Weis wrote: [part of long post omitted]
> 
> $ ocaml
>         Objective Caml version 2.99+10
> 
> # let sum l = List.fold_right ( + ) l 0;;
> val sum : int list -> int = <fun>
> 
> Clearly application is denoted in ML with only one character: a space.
> 
> Now, consider using the so-called ``Modern'' versions of these
> functionals, obtained with the -modern option of the compiler:
> 
> $ ocamlpedantic
>         Objective Caml version 2.99+10
> 
> # let sum l = List.fold_right ( + ) l 0;;
>                               ^^^^^
> This expression has type int -> int -> int but is here used with type 'a list
> 
> Clearly, there is something wrong now! We may remark that the error
> message is not that clear, but this is a minor point, since error
> messages are never clear enough anyway!
> 
> The real problem is that fixing the code makes no good at all to its
> readability (at least that's what I would say):
> 
> # let sum l = List.fold_right fun:begin fun x acc:y -> x + y end acc:0;;
> val sum : 'a -> int list -> int = <fun>
> 
> It seems that, in the ``modern'' mode, application of higher order
> functions is now denoted by a new kind of parens opening by
> ``fun:begin fun'' and ending by ``end''. This is extremely explicit
> but also a bit heavy (in my mind).
> 
> For all these reasons, I would suggest to carefully use labels into
> the standard libraries:
> 
> -- remove labels from higher-order functional

I don't think that merely omitting labels from higher-order functional
arguments really solves the problem.  Consider the following:

  $ ocaml -modern
          Objective Caml version 2.99 (99/12/08)

  # let add' :acc x = acc + x;;
        val add' : acc:int -> int -> int = <fun>
  # let rec fold_left' f accu l =
    match l with
      [] -> accu
    | a::l -> fold_left' f (f accu a) l;;
        val fold_left' : ('a -> 'b -> 'a) -> 'a -> 'b list -> 'a = <fun>
  # let sum' = fold_left' add' 0;;
      Characters 24-28:
  This expression has type acc:int -> int -> int but is here used with
type
    'a -> 'b -> 'a

If the definition of fold_left' does NOT use a label, we still get a
compile error whenever we try to use an argument that DOES have a label.

My proposal is to introduce an operator that can be used to tell the
compiler to ignore labels when type-checking a higher-order functional
argument.  This could be thought of as a pragma which locally switches
the compiler from modern to classic mode.

Some possible variations:

1. A prefix operator, here shown as "~", that causes only the following
expression to be evaluated in classic mode: 

  let sum = List.fold_left fun:~(+) acc:0
  let sum' = fold_left' ~add' 0

2. A bracketing construct, here shown as [~ ~], that causes everything
inside the brackets to be evaluated in classic mode. 

  let sum = List.fold_left fun:[~(+)~] acc:0
  let sum' = fold_left' [~add'~] 0

option 2 is not as visually lightweight, but might be more useful if
there are several arguments that need to be altered:
  let aaa = bbb ccc:~ddd eee:~fff ggg:~hhh ~iii jjj
versus
  let aaa = bbb [~ ccc:ddd eee:fff ggg:hhh iii ~] jjj



  parent reply	other threads:[~2000-03-18 17:55 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-14 16:53 Syntax for label Don Syme
2000-03-14 18:05 ` Pierre Weis
2000-03-15  3:15 ` Syntax for label, NEW PROPOSAL Jacques Garrigue
2000-03-15  6:58   ` Christophe Raffalli
2000-03-15 21:54     ` Julian Assange
2000-03-15 11:56   ` Wolfram Kahl
2000-03-15 13:58   ` Pierre Weis
2000-03-15 15:26     ` Sven LUTHER
2000-03-17  7:44       ` Pierre Weis
2000-03-15 17:04     ` John Prevost
2000-03-17 10:11       ` Jacques Garrigue
2000-03-15 17:06     ` Markus Mottl
2000-03-15 19:11     ` Remi VANICAT
2000-03-17  8:30       ` Pierre Weis
2000-03-17 14:05         ` Jacques Garrigue
2000-03-17 16:08           ` Pierre Weis
2000-03-18 10:32           ` Syntax for label, NEW SOLUTION Christophe Raffalli
2000-03-19  2:29             ` Jacques Garrigue
2000-03-20 18:25               ` Christophe Raffalli
2000-03-22  8:37                 ` Claudio Sacerdoti Coen
2000-03-21 23:29               ` John Max Skaller
2000-03-29  8:42               ` Semantic of label: The best (only ?) solution to merge both mode Christophe Raffalli
2000-03-29  9:53                 ` Christophe Raffalli
2000-03-30  9:49                   ` John Max Skaller
2000-03-30  9:39                 ` John Max Skaller
2000-03-31  4:34                   ` Jacques Garrigue
2000-04-01  1:53                     ` John Max Skaller
2000-04-02 19:24                     ` Christophe Raffalli
2000-04-04  5:50                       ` Jacques Garrigue
2000-04-03  7:57                     ` backward compatibility Christophe Raffalli
2000-03-15 21:30     ` Syntax for label, NEW PROPOSAL John Max Skaller
2000-03-16  2:55     ` Jacques Garrigue
2000-03-17 15:13       ` Pierre Weis
2000-03-17 17:33         ` Wolfram Kahl
2000-03-18 11:59         ` Jacques Garrigue
2000-03-21 16:51       ` Pascal Brisset
2000-03-23 11:14         ` Nicolas barnier
2000-03-24  9:54           ` labels & ocaml 3 & co David Mentré
2000-03-24 12:19             ` David Mentré
2000-03-21 22:22       ` Unsigned integers? John Max Skaller
2000-03-22 16:22         ` Sven LUTHER
2000-03-23  2:08           ` Max Skaller
2000-03-23  7:50             ` Sven LUTHER
2000-03-24  2:50             ` Jacques Garrigue
2000-03-24 15:59               ` Xavier Leroy
2000-03-25  4:03               ` John Max Skaller
2000-03-24 14:50             ` Xavier Leroy
2000-03-22 17:05         ` Jean-Christophe Filliatre
2000-03-22 19:10           ` Markus Mottl
2000-03-23  2:41           ` Max Skaller
2000-03-22 19:47         ` Xavier Leroy
2000-03-23 12:55           ` John Max Skaller
2000-03-16  8:50     ` Syntax for label, NEW PROPOSAL Pascal Brisset
2000-03-17 11:15       ` Sven LUTHER
2000-03-18  0:04     ` Steven Thomson [this message]
2000-03-15 20:39   ` Syntax for label (and more) Xavier Leroy
2000-03-17 10:03     ` Christian RINDERKNECHT
2000-03-17 17:19       ` Christophe Raffalli
2000-03-21  1:29     ` 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=38D2C806.219E784B@zeta.org.au \
    --to=sthomson@zeta.org.au \
    --cc=caml-list@inria.fr \
    /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).