Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: "Stefan Monnier" <monnier+lists/caml/news/@tequila.cs.yale.edu>
To: caml-list@inria.fr
Subject: Re: convincing management to switch to Ocaml
Date: 31 Aug 1999 15:03:31 -0400	[thread overview]
Message-ID: <5lwvubixh8.fsf@tequila.cs.yale.edu> (raw)
In-Reply-To: <3.0.6.32.19990831053557.0096ea40@mail.triode.net.au>

>>>>> "John" == John Skaller <skaller@maxtal.com.au> writes:
> When I write ocaml, I often do the following to get brackets right:
> I put the brackets in first:
> 	print_endline ()
> 	print_endline (x ^ ())
> 	print_endline (x ^ (string_of_int x))
> because I cannot count :-) This is a pain, because I have to
> keep backspacing. Even worse is: I have a string,

Emacs is your friend.  It will count the parens for you and you
can use Meta-( to introduce a pair of parens (putting the cursor
in the middle).

> The second problem I have is with the constructions that
> are like 'prefix/infix' operators, for example
> 	if .. then .. else ...
> 	try .. with ...
> 	match .. with | .. -> .. | .. -> ..
> Sudies were done in the 70's showing this is not as readable as
> constructions bounded lexically at both ends.

I don't know about studies, but as the maintainer of the SML
mode for Emacs I totally agree:  it's just a pain the rear.

> A general rule for a good syntax would be that augmentation
> of some term of a construction only required local editing.
> This means:
> 	terminators, not separators
> 	mandatory begin/end keywords

Caml (like SML and Pascal and C and ...) has taken the point of view
that begin/end entities should not be made mandatory if they are
unambiguously unneeded.  I can only agree with that point of view:
why should I say
	
	if a then (1) else (2)

?  Of course, it leads to subtle problems when you change one
of the arms without first adding the delimiters, but then the
indentation of your editor might help you.

> defensively: I put the brackets in to be sure of the semantics.
> This is useful for readers who are also not experts in the
> language as well.

You could also try to rely on your programming environment to
help you.  My latest SML mode (sorry, but I happen to use SML
rather than O'Caml.  Hopefully the Emacs support modes for the
two languages can be somewhat merged at some point, given the
amount of similarity) for example (maybe caml-mode does the same)
tries to allow the user to jump over expressions in a precedence-aware
way.  Once you get used to the way it works, you can use it
to check what goes to verify your understanding of precedence
(I also always get it wrong).

> 	(fun x -> print_endline ..)
> is ugly compared to:
> 	begin fun x -> print_endline .. end

Aesthetics is in the eye of the beholder.  It's much harder to visually match
`begin' to `end' than ( to ).  And similarly, it's harder for your text editor
to match them (Emacs for example has excellent built-in support for matching
parenthesis, but lousy support for matching keywords).

> but the ideal would be
> 	fun x is print_endline .. efun

Plop!  Yet another reserved keyword!
Syntax is one of those things that you just can't get right.


	Stefan




  parent reply	other threads:[~1999-09-01  7:57 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-07-28 14:47 STARYNKEVITCH Basile
1999-07-30  9:00 ` Markus Mottl
1999-08-13 10:32   ` John Skaller
1999-08-25  1:51     ` Frank A. Christoph
1999-08-25  3:50       ` John Skaller
1999-08-25  6:34         ` Frank A. Christoph
1999-08-26 18:36         ` Stefan Monnier
1999-08-29  6:08           ` John Skaller
1999-08-27 10:00         ` Andreas Rossberg
1999-08-28  6:24           ` John Skaller
1999-08-30 15:59             ` Sylvain BOULM'E
1999-08-31  5:50             ` Brian Rogoff
1999-08-28 19:51           ` Dave Mason
1999-08-30 19:05             ` Xavier Leroy
1999-08-30  8:02           ` Pierre Weis
1999-08-30 19:35             ` John Skaller
1999-08-31 17:10               ` Pierre Weis
1999-09-03  6:56                 ` John Skaller
1999-08-31 19:03               ` Stefan Monnier [this message]
1999-09-03  7:28                 ` John Skaller
1999-08-31  0:13             ` John Prevost
1999-08-31  5:19               ` John Skaller
1999-08-31  6:35                 ` John Prevost
1999-09-03  5:42                   ` John Skaller
1999-08-31 16:24           ` Gerard Huet
1999-07-30 14:42 ` John Skaller
1999-07-30 18:49 ` Gerd Stolpmann
1999-07-30 21:30 ` Francois Rouaix
1999-08-12 10:36 ` Reply to: " Jens Olsson
1999-08-16 18:33   ` Chris Tilt
1999-08-12 12:15 ` Frank A. Christoph
1999-08-15  8:14   ` Friedman Roy
  -- strict thread matches above, loose matches on Subject: below --
1999-09-07  7:24 TommyHallgren
     [not found] <John Skaller's message of "Tue, 31 Aug 1999 15:19:48 +1000">

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=5lwvubixh8.fsf@tequila.cs.yale.edu \
    --to=monnier+lists/caml/news/@tequila.cs.yale.edu \
    --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