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 9001D7EEBF for ; Mon, 3 Aug 2015 20:00:09 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of octa@polychoron.fr) identity=pra; client-ip=217.70.183.197; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="octa@polychoron.fr"; x-sender="octa@polychoron.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of octa@polychoron.fr) identity=mailfrom; client-ip=217.70.183.197; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="octa@polychoron.fr"; x-sender="octa@polychoron.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@relay5-d.mail.gandi.net) identity=helo; client-ip=217.70.183.197; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="octa@polychoron.fr"; x-sender="postmaster@relay5-d.mail.gandi.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B4AwAAq79Vh8W3RtlbGQEBg1NpBoMdpGWBLQEBBpUbhgECgTRMAQEBAQEBEgEBAQgNCQcjLkEFg14BAQEDEhFVARALBB0WCwICCQMCAQIBRQYNCAEBFweICgYDqkiKJJV2AQEIAQEBAR6GH4UwhQgHgmmBQwWUeYE/hh6NSJBtAheEDm2BSIEEAQEB X-IPAS-Result: A0B4AwAAq79Vh8W3RtlbGQEBg1NpBoMdpGWBLQEBBpUbhgECgTRMAQEBAQEBEgEBAQgNCQcjLkEFg14BAQEDEhFVARALBB0WCwICCQMCAQIBRQYNCAEBFweICgYDqkiKJJV2AQEIAQEBAR6GH4UwhQgHgmmBQwWUeYE/hh6NSJBtAheEDm2BSIEEAQEB X-IronPort-AV: E=Sophos;i="5.15,602,1432591200"; d="scan'208,217";a="172549272" Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 03 Aug 2015 20:00:09 +0200 Received: from mfilter42-d.gandi.net (mfilter42-d.gandi.net [217.70.178.172]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id C058741C05D; Mon, 3 Aug 2015 20:00:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter42-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter42-d.gandi.net (mfilter42-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id XdnB05541hjB; Mon, 3 Aug 2015 20:00:07 +0200 (CEST) X-Originating-IP: 105.250.50.187 Received: from [192.168.42.219] (vc-cpt-105-250-50-187.umts.vodacom.co.za [105.250.50.187]) (Authenticated sender: octa@polychoron.fr) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 1192C41C05C; Mon, 3 Aug 2015 20:00:05 +0200 (CEST) To: =?UTF-8?Q?Daniel_B=c3=bcnzli?= References: <55BF6F1C.3050705@bioquant.uni-heidelberg.de> <55BF75F6.1040006@bioquant.uni-heidelberg.de> <8E1A640CE3374EB492981ADB0A2DA5C6@erratique.ch> <55BF8451.3060408@polychoron.fr> <55BF9314.70904@polychoron.fr> <2C582E7B7CD34029998882AA66299107@erratique.ch> Cc: Nils Becker , Caml-list From: octachron Message-ID: <55BFAC17.3050406@polychoron.fr> Date: Mon, 3 Aug 2015 19:59:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <2C582E7B7CD34029998882AA66299107@erratique.ch> Content-Type: multipart/alternative; boundary="------------070705000508000908020208" Subject: Re: [Caml-list] destructive local opens This is a multi-part message in MIME format. --------------070705000508000908020208 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 08/03/15 18:51, Daniel B=C3=BCnzli a =C3=A9crit : > 1. Given a M.( * ) without warning the * may be the one of M or the one i= n scope. Ambiguous, can't be resolved locally. > > 2. Given a M.( id ) without warning, if [id] is in scope I*know* this [i= d] is being used. If it's not I know M.id is being used. No ambiguity, can = be resolved locally. > > If you allow each identifier in a module to sport an @shadow annotation y= ou lose 2. which I find a very valuable property. Without it, given that i= dentifiers are much more widespread than operators, we get a much more ambi= guous language. It is a very valid point. However, I would argue that 1. and 2. are=20 transformed to 1. Given a M.( [edsl_keyword] ) is the one of M. If I know the EDSL=20 keywords, there is no ambiguity. 2. Given a M.( non_keyword ) without warning, if [non_keyword] is in=20 scope then [non_keyword] is being used. Otherwise, [M.non_keyword] is being used. No global ambiguity. This approach, contrarily to yours, has a major disadvantage: its relies=20 on a tacit agreement on the EDSL keywords. At the same time, it allows EDSL authors to tailor the=20 warnings to the EDSL context. If the keyword list is small/sensible enough, it might result=20 in better warnings. But yes, implicit agreements are clearly more brittle than broad rules.=20 A (over?)complicated solution might be to add module alias annotation in order to modify=20 shadow annotations locally (e.g. " module N =3D M [@@only_shadow "+"] "). Regards, octachron. --------------070705000508000908020208 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Le 08/03/15 18:51, Daniel B=C3=BCnzli a =C3=A9crit=C2=A0:
1. Given a M.( * ) without warning the * may be the on=
e of M or the one in scope. Ambiguous, can't be resolved locally.

2. Given a M.( id ) without warning, if [id] is in scope I *know* this [id] is being used. If it's not I know M.id is being u=
sed. No ambiguity, can be resolved locally.

If you allow each identifier in a module to sport an @shadow annotation you=
 lose 2. which I find a  very valuable property. Without it, given that ide=
ntifiers are much more widespread than operators, we get a much more ambigu=
ous language.
It is a very valid point. However, I would argue that 1. and 2. are transformed to

1. Given a M.( [edsl_keyword] ) is the one of M. If I know the EDSL keywords, there is no ambiguity.

2. Given a M.( non_keyword ) without warning, if [non_keyword] is in scope then [non_keyword] is
being used. Otherwise, [M.non_keyword] is being used. No global ambiguity.

This approach, contrarily to yours, has a major disadvantage: its relies on a tacit agreement on the
EDSL keywords. At the same time, it allows EDSL authors to tailor the warnings to the EDSL
context. If the keyword list is small/sensible enough, it might result in better warnings.

But yes, implicit agreements are clearly more brittle than broad rules. A (over?)complicated
solution might be to add module alias annotation in order to modify shadow annotations locally
(e.g. " module N =3D M [@@only_shadow "+"] ").

Regards,
octachron.

--------------070705000508000908020208--