caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: Kenneth Adam Miller <kennethadammiller@gmail.com>
Cc: caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] Compilation semantics for static garbage collection
Date: Fri, 19 Jun 2015 00:25:20 +0200	[thread overview]
Message-ID: <CAPFanBFr0Ks4gkefhoPOKo1eDdkcvk9p=ermoPYz9XxrJBGT_w@mail.gmail.com> (raw)
In-Reply-To: <CAK7rcp8-tBP1=kGK2fGHWnppUrkRe+U7vSEScRg4nL-qCgtfNg@mail.gmail.com>

You may interested in the Mezzo programming language, a research
language developed with the idea of having a finer-grained type-level
control of mutable memory.
  http://protz.github.io/mezzo/

Many of the ideas that are informal in Rust are formally explicited in
Mezzo. The language is less ambitious than Rust in terms of feature
coverage (and thus less practical for everyday programming), but comes
with a precise semantics (which Rust lacks for now) and soundness
proof. It is a fairly interesting design, which can be presented as
aiming to turn the current research on separation logic into a
relatively usable programming language design.

For a lively discussion of some of Mezzo design choices, what worked
and what did not work so well, see
  "A few lessons from the Mezzo project",
  François Pottier, Jonathan Protzenko, 2015
  http://gallium.inria.fr/~fpottier/publis/fpottier-protzenko-lessons-mezzo.pdf

On Thu, Jun 18, 2015 at 9:44 PM, Kenneth Adam Miller
<kennethadammiller@gmail.com> wrote:
> I was thinking that while rust is new, some of what it is pioneering is
> really interesting, especially with the way it deals with ownership being a
> type. Rust doesn't have a GC, yet it rules out leakage and remains fast. It
> also manages concurrency safety very well.
>
> The stipulations put on types in the ocaml language are pretty strict, and
> the GC is transparent to the user. What is the possibility that there could
> ever be a version of ocaml that makes use of something like ownership or
> some typing mechanism to determine more at compile time, to facilitate the
> removal or reduction of the GC?

  parent reply	other threads:[~2015-06-18 22:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-18 19:44 Kenneth Adam Miller
2015-06-18 21:59 ` Malcolm Matalka
2015-06-18 22:25 ` Gabriel Scherer [this message]
2015-06-19  2:00   ` Kenneth Adam Miller

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='CAPFanBFr0Ks4gkefhoPOKo1eDdkcvk9p=ermoPYz9XxrJBGT_w@mail.gmail.com' \
    --to=gabriel.scherer@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=kennethadammiller@gmail.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).