Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Brighten Godfrey <pbg@cs.berkeley.edu>
To: Richard Jones <rich@annexia.org>,
	blue storm <bluestorm.dylc@gmail.com>,
	Jon Harrop <jon@ffconsultancy.com>,
	OCaml List <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] Record field label locality
Date: Wed, 13 Aug 2008 02:30:02 -0700	[thread overview]
Message-ID: <C2313826-F452-4ABF-898F-A7253FA3B77F@cs.berkeley.edu> (raw)
In-Reply-To: <20080813081459.GA30690@annexia.org>

On Aug 13, 2008, at 1:14 AM, Richard Jones wrote:

> On Tue, Aug 12, 2008 at 02:03:46PM -0700, Brighten Godfrey wrote:
>> I think I see what you're getting at.  Is it possible to define
>> compositionality as follows?:
>
> I think Jon means that you can copy and paste code around and it still
> works.

(...which is not true for various other reasons (e.g. conflicting  
type annotations, variables with different types, etc.).)

>> "Removing a type annotation from
>> correct OCaml code results in correct OCaml code."
>
> This is mostly correct.  However very occasionally it is necessary to
> help the compiler out by annotating expressions with types.  I believe
> this is because type inference used by OCaml is undecidable.  You'll
> notice this effect more often if you use OCaml's object system.

Yes, I've noticed that.


> You might want to try renaming the Graph module, ie:
>
>   module G = Graph
>
>   ... g.G.nodes ...
>
> Or if you have control over the module itself, you could also try
> renaming the fields to make them unique (eg. g_nodes), at which point
> you can just 'open Graph'.  There are different trade-offs to each
> approach.

On Aug 12, 2008, at 6:51 PM, blue storm wrote:
> It might be a bit off-topic, but if you want to ease the syntaxic  
> pain only, you can use the pa_openin (http://alain.frisch.fr/ 
> soft.html#openin ) camlp4 extension :
>
>   open Graph in { g with nodes = foo }


Thanks to both of you for suggesting these workarounds.  Probably  
renaming the module is the easiest and least likely to cause other  
problems.  I am still curious about the language design question  
though...

Thanks,
~Brighten


      reply	other threads:[~2008-08-13  9:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-10 10:04 Brighten Godfrey
2008-08-10 19:38 ` [Caml-list] " Jon Harrop
2008-08-12 21:03   ` Brighten Godfrey
2008-08-13  0:12     ` Edgar Friendly
2008-08-13  1:17       ` Brighten Godfrey
2008-08-13 12:48         ` Edgar Friendly
2008-08-14  6:38           ` Brighten Godfrey
2008-08-14 10:11             ` David Allsopp
2008-08-13  1:51     ` blue storm
2008-08-13  8:14     ` Richard Jones
2008-08-13  9:30       ` Brighten Godfrey [this message]

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=C2313826-F452-4ABF-898F-A7253FA3B77F@cs.berkeley.edu \
    --to=pbg@cs.berkeley.edu \
    --cc=bluestorm.dylc@gmail.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=jon@ffconsultancy.com \
    --cc=rich@annexia.org \
    /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