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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 5DE9F7F02D for ; Tue, 21 Oct 2014 15:20:25 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of arnaud.spiwack@gmail.com) identity=pra; client-ip=74.125.82.51; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="arnaud.spiwack@gmail.com"; x-sender="arnaud.spiwack@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of arnaud.spiwack@gmail.com designates 74.125.82.51 as permitted sender) identity=mailfrom; client-ip=74.125.82.51; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="arnaud.spiwack@gmail.com"; x-sender="arnaud.spiwack@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wg0-f51.google.com) identity=helo; client-ip=74.125.82.51; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="arnaud.spiwack@gmail.com"; x-sender="postmaster@mail-wg0-f51.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4BAMRIRlRKfVIzm2dsb2JhbABcDoQrBIMC0W0HFgERAQEBAQEGCwsJFC6EAwEBAwESER0BOAEDAQsBBQUEAQYDNAICIhIBBQEcBi4HiAkDCQiiE26LMIUCiQcnDYYuAQsaAQUOk0GBVAEEnVqBMJBxggwYKYFvgnxCOy+CSwEBAQ X-IPAS-Result: At4BAMRIRlRKfVIzm2dsb2JhbABcDoQrBIMC0W0HFgERAQEBAQEGCwsJFC6EAwEBAwESER0BOAEDAQsBBQUEAQYDNAICIhIBBQEcBi4HiAkDCQiiE26LMIUCiQcnDYYuAQsaAQUOk0GBVAEEnVqBMJBxggwYKYFvgnxCOy+CSwEBAQ X-IronPort-AV: E=Sophos;i="5.04,762,1406584800"; d="scan'208";a="84093668" Received: from mail-wg0-f51.google.com ([74.125.82.51]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 21 Oct 2014 15:20:24 +0200 Received: by mail-wg0-f51.google.com with SMTP id b13so1361180wgh.10 for ; Tue, 21 Oct 2014 06:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=xyyUiIAOtVkfR9+crjjCCW+1mMlBXWgj2X3gmnX+3WI=; b=yv/JyaSaAHoAIpQ0L/jh1PkGjAzYGANVE5yj3saoqLZ4Wdn6OYkopMI61uqzpyzuTx AUE/IAkBIChhSgkDLbEbYUEO4jAJ19q/1wwWIscKeB+vcGuhoQ/RTLDivN3e7IZTJ68F CdZWmGK1yOCkaZdK46tABbHH5jtZhRQmVShUEYrssRN8IazrCA8tbz3tLJIIFKYNj9jK 7WWB57kE/Xtge/NtM8mJc2wNU0JlfIxvBNuxDFFVQwkwMAyf6aCf9vvmYju/arRb6w6n 1UjmFMP6PXUf9YqQOiaMDtZ+ISeqqUHvJcULwRlObYDzOrThgUJrKPCMYn6of0CwNvHs g30A== X-Received: by 10.194.76.70 with SMTP id i6mr42993299wjw.13.1413897624337; Tue, 21 Oct 2014 06:20:24 -0700 (PDT) MIME-Version: 1.0 Sender: arnaud.spiwack@gmail.com Received: by 10.216.57.4 with HTTP; Tue, 21 Oct 2014 06:19:44 -0700 (PDT) In-Reply-To: <86y4s9oah2.fsf@cam.ac.uk> References: <8638ahpq1m.fsf@cam.ac.uk> <86y4s9oah2.fsf@cam.ac.uk> From: Arnaud Spiwack Date: Tue, 21 Oct 2014 15:19:44 +0200 X-Google-Sender-Auth: bIhWOTUIUfGZYO9kLXCiOXQ8lhM Message-ID: To: Leo White Cc: OCaML Mailing List Content-Type: multipart/alternative; boundary=047d7bb0401ca5c4fd0505eeb156 X-Validation-by: arnaud@spiwack.net Subject: Re: [Caml-list] Manipulating Modules Modularly --047d7bb0401ca5c4fd0505eeb156 Content-Type: text/plain; charset=UTF-8 > Perhaps this is an acceptable solution for your use cases. > It isn't, I'm afraid. By the way, I'm well aware of the problem with effects and value restriction and such (hence my qualification above, with purity). However, I don't care if it fails from time to time (and I think I remember some check about purity being done somewhere in the module system). For my use-case, I don't care if I need to have access to the original source-code -- I mean to see the concrete definition of the functor rather than its signature -- either (though it seems a limitation in general). Am I weird to run into this issue all the time or is it common? PS: now that there are both applicative functors and generative functors, could applicative functors be restricted to being pure, so that this sort of manipulation become possible in a generic way? --047d7bb0401ca5c4fd0505eeb156 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
Perhaps this is an acceptable solution for y= our use cases.

It isn't, I'm afraid.
By the way, I'm well aware of the problem with effects and value rest= riction and such (hence my qualification above, with purity). However, I do= n't care if it fails from time to time (and I think I remember some che= ck about purity being done somewhere in the module system). For my use-case= , I don't care if I need to have access to the original source-code -- = I mean to see the concrete definition of the functor rather than its signat= ure -- either (though it seems a limitation in general).
Am I weird to run into this issue all the time or is it common?

PS: now that there are both applicative functors and generative functors, = could applicative functors be restricted to being pure, so that this sort o= f manipulation become possible in a generic way?
--047d7bb0401ca5c4fd0505eeb156--