From: Jon Harrop <jon@ffconsultancy.com>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Re: Parameter evaluation order
Date: Wed, 24 Aug 2005 21:53:37 +0100 [thread overview]
Message-ID: <200508242153.37933.jon@ffconsultancy.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0508241317560.30848@shell2.speakeasy.net>
On Wednesday 24 August 2005 21:25, brogoff wrote:
> > I would prefer square bracket for constructor application, mandatory
> > even for unary constructor (and maybe also constant constructor then you
> > can lift the restriction about capital letter)
It would be nice if variant constructors were functions (as they are in SML,
IIRC). So you could do this:
# type num = Int of int | Float of float;;
type num = Int of int | Float of float
# List.map Int [1; 2; 3];;
- : num list = [Int 1; Int 2; Int 3]
Rather than having to do "List.map (fun i -> Int i) ...". That wouldn't work
with polymophic variants though, at least not trivially.
If variant constructors always accepted a single, tuple argument could it not
be optimised away in most cases? Also, could constructors be curried instead
of using tuples (or syntax that looks like tuples)?
> The examples that bother me most are record constructors, where I want to
> read structured data from a file into a record. And of course :: (which is
> just sugar) too.
Yes. It would be nice if (fun h t -> h::t) could be written infix as ( :: ),
as operators are. In fact, couldn't that be added without breaking backward
compatibility?
> It's a fun topic to chat about, but if you were allowed one change in the
> language, surely this wouldn't be it? :-)
Good question. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
next prev parent reply other threads:[~2005-08-24 20:56 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-19 22:21 "Márk S. Zoltán"
2005-08-20 9:12 ` [Caml-list] " Alain Frisch
2005-08-26 17:53 ` "Márk S. Zoltán"
2005-08-22 16:50 ` Damien Doligez
2005-08-23 7:12 ` skaller
2005-08-23 11:29 ` Damien Doligez
2005-08-23 13:34 ` Igor Pechtchanski
2005-08-23 19:52 ` Damien Doligez
2005-08-24 1:24 ` Hao-yang Wang
2005-08-24 11:33 ` [Caml-list] " Damien Doligez
2005-08-24 14:39 ` Christophe Raffalli
2005-08-24 15:47 ` Berkeley DB Joel Reymont
2005-08-24 16:08 ` [Caml-list] Re: Parameter evaluation order brogoff
2005-08-24 20:05 ` Christophe Raffalli
2005-08-24 20:25 ` brogoff
2005-08-24 20:53 ` Jon Harrop [this message]
[not found] ` <430CE193.9000805@univ-savoie.fr>
2005-08-26 9:53 ` Christophe Raffalli
2005-08-26 10:10 ` Jon Harrop
2005-08-26 12:09 ` Christophe Raffalli
2005-08-26 12:26 ` Diego Olivier Fernandez Pons
2005-08-26 16:48 ` Christophe Raffalli
2005-08-27 15:33 ` Christophe TROESTLER
2005-08-26 12:36 ` Ville-Pertti Keinonen
2005-08-26 14:17 ` Fernando Alegre
2005-08-26 17:00 ` Christophe Raffalli
2005-08-26 22:58 ` skaller
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=200508242153.37933.jon@ffconsultancy.com \
--to=jon@ffconsultancy.com \
--cc=caml-list@yquem.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