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 81C897EE25 for ; Sat, 2 Nov 2013 20:03:58 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of dra-news@metastack.com) identity=pra; client-ip=62.13.148.154; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of dra-news@metastack.com designates 62.13.148.154 as permitted sender) identity=mailfrom; client-ip=62.13.148.154; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.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@outmail148154.authsmtp.co.uk) identity=helo; client-ip=62.13.148.154; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="postmaster@outmail148154.authsmtp.co.uk"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnICAEJLdVI+DZSanGdsb2JhbABYgmZZU799gR0WDgEBAQEBBg0JCRQogiUBAQEEJxNPAgEIGAoUEDIlAgQbh3oDvS+PJziDIIEOA5gKgS+UAIIq X-IPAS-Result: AnICAEJLdVI+DZSanGdsb2JhbABYgmZZU799gR0WDgEBAQEBBg0JCRQogiUBAQEEJxNPAgEIGAoUEDIlAgQbh3oDvS+PJziDIIEOA5gKgS+UAIIq X-IronPort-AV: E=Sophos;i="4.93,623,1378850400"; d="scan'208";a="40415155" Received: from outmail148154.authsmtp.co.uk ([62.13.148.154]) by mail2-smtp-roc.national.inria.fr with ESMTP; 02 Nov 2013 20:03:33 +0100 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt6.authsmtp.com (8.14.2/8.14.2) with ESMTP id rA2J3uV7099849 for ; Sat, 2 Nov 2013 19:03:56 GMT Received: from romulus.metastack.com (cpc1-cmbg5-0-0-cust241.5-4.cable.virginm.net [81.98.252.242]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rA2J3tDw017569 for ; Sat, 2 Nov 2013 19:03:55 GMT Received: from remus.metastack.local (remus.metastack.com [172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id rA2J3sX8001774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 2 Nov 2013 19:03:55 GMT Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.03.0158.001; Sat, 2 Nov 2013 19:03:54 +0000 From: David Allsopp To: caml users Thread-Topic: [Caml-list] Operator for Lazy.force? Thread-Index: AQHO1bQm6a47p7Ynsk6DRWAjPR+4QZoNw/YAgALEiACAAcTcMA== Date: Sat, 2 Nov 2013 19:03:53 +0000 Message-ID: References: <1383167277.75943.YahooMailNeo@web120402.mail.ne1.yahoo.com> <41ECAD85-CC65-41A5-AD6E-21F4B85C932D@inria.fr> In-Reply-To: <41ECAD85-CC65-41A5-AD6E-21F4B85C932D@inria.fr> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [212.183.128.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 172.16.0.20 X-Server-Quench: 8583cd64-43f1-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd1ZAARAlZZVg1f DC4bFwdFRBksPQFF ChxFJgxfNlEAUAAU NkdBMnJSNkcdTBdX QSgLWUsqDxtuW2N0 aBpQZA9dYUBLWkti UVZASkxQEQd2AxgD GRwbTRk8NXREAn00 EQFiX3deWk00d098 SwBcEGUFNjNmbH0b UxZZagJVJQBXLBdF aE1/VHEIaGVWZ380 FlAlBR1jdQZ0ISFR BwUMNk4nCWETEyQ1 WxcYVTsoBwUhTjci aRIhMFURSy4I X-Authentic-SMTP: 61633634383431.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 81.98.252.242/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Subject: RE: [Caml-list] Operator for Lazy.force? Damien Doligez wrote: > On 2013-10-30, at 22:33, Dmitry Grebeniuk wrote: >=20 > > So theirs ( !! ) operator will override Pervasives' one. > > What's the problem? Anyway projects you've mentioned don't use Lazy, > > so there's no chance of "operator clash". >=20 > It cannot be in Pervasives, since that would introduce a circular > dependency with Lazy. It doesn't belong in Pervasives anyway. Out of belligerent curiosity only, is that definitely true? lazy.mli doesn'= t create an opaque type for 'a Lazy.t so wouldn't external ( !! ) : 'a lazy_t -> 'a =3D "%lazy_force" in pervasives.ml/mli work out of the box and to all intents and purposes ha= ve the right effect? Even if you wanted to have the neater type 'a Lazy.t -> 'a, lazy.ml only re= fers to a handful of trivial externals and constants in obj.ml and only req= uires ( <> ) and ( || ) from Pervasives. Isn't it the case that as Pervasiv= es would then only refer to a *type* in Lazy that you wouldn't have the (pr= esumably unwanted) side-effect of even "Hello World" being linked with Lazy? So either with some very minor internal code duplication (or a bit of pre-p= rocessing), is there anything else which means that you couldn't add that d= eclaration to Pervasives without the circular dependency? I agree that it probably doesn't belong there (although I can see the other= side, given that the lazy keyword is, um, "pervasive") - just curious as t= o if it's possible :o) David