From: Berke Durak <berke.durak@exalead.com>
To: DooMeeR <d@doomeer.com>
Cc: mfmorss@aep.com, caml-list caml-list <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] different records, same field name?
Date: Tue, 04 Mar 2008 10:52:55 +0100 [thread overview]
Message-ID: <47CD1BF7.7060100@exalead.com> (raw)
In-Reply-To: <47CC4765.2080309@doomeer.com>
DooMeeR a écrit :
> mfmorss@aep.com a écrit :
>> I have not used OCaml, just done some reading about it and toyed with
>> the toplevel to see if it might be a useful tool here. I have
>> "Practical OCaml," which unfortunately is a rather wretched reference.
>>
>> In any case, is it possible to define and use different types of
>> records, which nevertheless share some field names? I have had
>> difficulty doing this in the toplevel.
>
> Sharing names for record labels, as well as for variant tags, is not a
> good idea. Indeed, only the last name is remembered (as for everything
> in OCaml), so the type system will infer the last type which has this
> label.
>
> One way to separate names is to use modules, for instance:
>
> module People = struct
> type t = {
> name: string;
> age: int;
> }
> end;;
>
> Then you can use labels People.name and People.age, for instance:
>
> let x = {
> People.name = "x";
> age = 69;
> };;
>
> Notice how, when defining this variant, you don't have to use "People."
> for every label.
>
> x.People.name
>
> The toplevel gives you:
> - : string = "x"
>
> If you know you won't have any name clash, you can open module People
> and you won't have to use "People." everytime:
>
> open People;;
>
> let x = {
> name = "x";
> age = 69;
> };;
>
That's one instance were Alain's openin extension shows its usefulness.
http://alain.frisch.fr/soft.html#openin
let sprint_time () t =
open Unix in
sprintf "%04d-%02d-%02d" t.tm_year t.(tm_mon+1) t.tm_day
Here's one thing we could do as part of the OSR. Define a list of
"standard" syntax extensions and libraries.
I would certainly vote for openin to be included by default.
Then let the fine Debian Ocaml maintainers write a wrapper scripts
around the ocaml compiler that will use those extensions and have those
libraries accessible by default; name the resulting binaries in a consistent way,
such as by appending an "s" (for "standard") at the end of command names,
as in "ocamlcs", "ocamlopts". Put those in a package called "ocaml-osr".
Tell people new to Ocaml to use those instead; the existing users will be told
to just add an "s".
ocamlcs, ocamlopts would expand to
ocamlc -I +pcre -I +lablgtk -I +extlib -I +whatever... -pp camlp4o -pp pa_openin ..
possibly depending on installed packages.
--
Berke DURAK
next prev parent reply other threads:[~2008-03-04 9:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-03 16:51 mfmorss
2008-03-03 16:53 ` [Caml-list] " Jon Harrop
2008-03-03 16:55 ` Basile STARYNKEVITCH
2008-03-03 19:32 ` Kuba Ober
2008-03-03 21:04 ` Michael Wohlwend
2008-03-03 22:29 ` Jon Harrop
2008-03-03 18:45 ` DooMeeR
2008-03-04 9:52 ` Berke Durak [this message]
2008-03-04 10:25 ` David Teller
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=47CD1BF7.7060100@exalead.com \
--to=berke.durak@exalead.com \
--cc=caml-list@yquem.inria.fr \
--cc=d@doomeer.com \
--cc=mfmorss@aep.com \
/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).