From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 4184F7EEBF for ; Thu, 18 Jun 2015 21:53:48 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of kennethadammiller@gmail.com) identity=pra; client-ip=209.85.214.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of kennethadammiller@gmail.com designates 209.85.214.178 as permitted sender) identity=mailfrom; client-ip=209.85.214.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ob0-f178.google.com) identity=helo; client-ip=209.85.214.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-ob0-f178.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B6BAAuIYNVlLLWVdFchEMGgxiqE4YPkh4CgTcHTAEBAQEBARIBAQEBBwsLCR8whBkKAQEEEhEdARseAwwGCAEHNwICIgERAQUBHAY1h3cBAxKkAT4xiz+Ba4J5iykKGScNV4UIAQEBBwEBAQEBFwEFDpBEgmiBQwWTPjKLS5ZcEiOBDAmEOyIxgkgBAQE X-IPAS-Result: A0B6BAAuIYNVlLLWVdFchEMGgxiqE4YPkh4CgTcHTAEBAQEBARIBAQEBBwsLCR8whBkKAQEEEhEdARseAwwGCAEHNwICIgERAQUBHAY1h3cBAxKkAT4xiz+Ba4J5iykKGScNV4UIAQEBBwEBAQEBFwEFDpBEgmiBQwWTPjKLS5ZcEiOBDAmEOyIxgkgBAQE X-IronPort-AV: E=Sophos;i="5.13,640,1427752800"; d="scan'208";a="166093278" Received: from mail-ob0-f178.google.com ([209.85.214.178]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 18 Jun 2015 21:53:47 +0200 Received: by obbsn1 with SMTP id sn1so61175037obb.1 for ; Thu, 18 Jun 2015 12:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zr61bcy8fi086qaJVGxarhhCv/tYIr43ni0ARywTShM=; b=RluH/YKrZ9i7pl0Yy3N7lnT4PjKvrNk5WyGPA0Axuweze1WjX/qoNBSLoPUzfSST4q uYV28uAZqSAsmWL7wNfgQSWYOAmfLXe0pu9AYZ+3alAWBXJ+uqE8Btd2DHCTgS/X/Rb5 HodNmQ3/xtGNAWyFDfCzpSgHgiB3EVph0p5//RQkpDeUw8czOSch0v+GfIH7HMQHnS7L f2ej67Su4afSpeCkB8qqmbuAN1MzBtfobonQakjHWl8/Ap4oXr8Vagk1uoseNUKgDc1N 75hKUtyWtg0TmUNHDQTCLVzNhr51LmTyz/Jl36G+jp6qn8X947IJC8RuNyXGdvh7Pnpt xtdQ== MIME-Version: 1.0 X-Received: by 10.60.35.8 with SMTP id d8mr10520033oej.37.1434657226196; Thu, 18 Jun 2015 12:53:46 -0700 (PDT) Received: by 10.202.191.8 with HTTP; Thu, 18 Jun 2015 12:53:46 -0700 (PDT) Received: by 10.202.191.8 with HTTP; Thu, 18 Jun 2015 12:53:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Jun 2015 15:53:46 -0400 Message-ID: From: Kenneth Adam Miller To: caml users Content-Type: multipart/alternative; boundary=089e013cc154578c440518d02a29 Subject: [Caml-list] Parallelism in newer versions of ocaml --089e013cc154578c440518d02a29 Content-Type: text/plain; charset=UTF-8 Its my personal gathering that the development of ocaml has always been driven with the conviction that things should be done with a mathematical foundation that supports doing things well over just getting them done sooner. Quality over quantity kind of thing. I was wondering what kinds of typing rules or new language constructs or otherwise judicious restrictions might be put in place for the facilitation of doing concurrency very well in ocaml, or if there are even any. Possibly it is just the code that the compiler produces that just now will actually resolve a thread creation function call? My thinking is the GC wasn't written with concurrent accesses in mind, but at the same time, the pi calculus would seem close to home with respect to the ocaml philosophy. Can any body comment on any of this? --089e013cc154578c440518d02a29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Its my personal gathering that the development of ocaml has = always been driven with the conviction that things should be done with a ma= thematical foundation that supports doing things well over just getting the= m done sooner. Quality over quantity kind of thing.

I was wondering what kinds of typing rules or new language c= onstructs or otherwise judicious restrictions might be put in place for the= facilitation of doing concurrency very well in ocaml, or if there are even= any. Possibly it is just the code that the compiler produces that just now= will actually resolve a thread creation function call? My thinking is the = GC wasn't written with concurrent accesses in mind, but at the same tim= e, the pi calculus would seem close to home with respect to the ocaml philo= sophy.

Can any body comment on any of this?

--089e013cc154578c440518d02a29--