caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Mattias Waldau" <mattias.waldau@tacton.se>
To: "Dave Berry" <dave@kal.com>, "Chris Hecker" <checker@d6.com>,
	"Mattias Waldau" <mattias.waldau@abc.se>,
	"Caml-List" <caml-list@inria.fr>
Subject: RE: Same label in different types, how do people solve this?
Date: Wed, 13 Dec 2000 15:31:53 +0100	[thread overview]
Message-ID: <HDEEKOMJILGEIHIMAPCDAEPHDLAA.mattias.waldau@tacton.se> (raw)
In-Reply-To: <3145774E67D8D111BE6E00C0DF418B6638D1C9@nt.kal.com>

My problems isn't the restriction as such. If I know about the restriction,
I can code around it.

The problem is that this particular restriction is very unusual, and
therefor I need to be informed about this. Now it is in the faq, but why not
put it into the error message "two fields in different types in the same
file/module cannot have the same name."

/mattias

-----Original Message-----
From: Dave Berry [mailto:dave@kal.com]
Sent: Wednesday, December 13, 2000 2:17 PM
To: Chris Hecker; Mattias Waldau; Caml-List
Subject: RE: Same label in different types, how do people solve this?


The same issue arises with variant types -- a constructor defined in one
type cannot be defined in a later type.  Do you find this to be a problem as
well?  One could make an argument that languages should be consistent in how
they treat these two cases.  OCaml was consistent until it added polymorphic
variants.  SML is not consistent, because it forbids redefinition of
constructors but permits fields to be used in different record types.
(Technically, SML record types are types in their own right, unlike CAML
record types which must be named).

Also, I'm curious as to why the module approach doesn't meet your
requirements.  Do you really need to use different types with the same label
in the same module?

Dave.


-----Original Message-----
From: Chris Hecker [mailto:checker@d6.com]
Sent: Monday, December 11, 2000 18:24
To: Mattias Waldau; Caml-List
Subject: RE: Same label in different types, how do people solve this?



>I understand that all you functional experts thinks this restriction is
>obvious, but for me it is more like a bug/misfeature. So this 'misfeature'
>should actually be stated for all us who aren't interested how types are
>infered in functional programming.

I'm with Mattias on this one.  I'm practical above theoretical.  All of the
workarounds for this problem seem like they generate way more tedious work
for the programmer, and they still don't quite accomplish the goal 100%.
This characteristic of doing more work and only asymptotically approaching
your goal is a bad taste I associate with C++.

Anyway, my "vote" would be to allow specification, with : if it's possible
since it's the obvious syntax, but even with @@ if necessary (even though I
think it's really ugly).

Chris



  reply	other threads:[~2000-12-14 18:25 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-13 13:17 Dave Berry
2000-12-13 14:31 ` Mattias Waldau [this message]
2000-12-15 10:01   ` John Max Skaller
  -- strict thread matches above, loose matches on Subject: below --
2000-12-10 14:57 Ohad Rodeh
2000-12-06 21:22 Mattias Waldau
2000-12-07 16:49 ` John Max Skaller
2000-12-07 18:34 ` Maxence Guesdon
2000-12-07 23:02 ` Gerd Stolpmann
2000-12-08  1:22 ` Jacques Garrigue
2000-12-08  9:31   ` Sven LUTHER
2000-12-08  9:36     ` Pierre Weis
2000-12-08  9:48       ` Sven LUTHER
2000-12-08 18:41       ` John Max Skaller
2000-12-08  9:40     ` Nicolas barnier
2000-12-08 16:36 ` Brian Rogoff
2000-12-11 17:19   ` Pierre Weis
2000-12-10 12:49 ` Mattias Waldau
2000-12-11 18:23   ` Chris Hecker
2000-12-11 19:17     ` Pierre Weis
2000-12-12 10:02       ` Sven LUTHER
2000-12-12  3:25     ` Chet Murthy
2000-12-12 17:43       ` John Max Skaller
2000-12-15 21:51         ` Bruce Hoult
2000-12-12 17:19   ` John Max 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=HDEEKOMJILGEIHIMAPCDAEPHDLAA.mattias.waldau@tacton.se \
    --to=mattias.waldau@tacton.se \
    --cc=caml-list@inria.fr \
    --cc=checker@d6.com \
    --cc=dave@kal.com \
    --cc=mattias.waldau@abc.se \
    /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).