From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <Maxence.Guesdon@inria.fr>
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 6695F7EF10
	for <caml-list@sympa.inria.fr>; Mon,  9 Mar 2015 14:57:30 +0100 (CET)
X-IronPort-AV: E=Sophos;i="5.11,368,1422918000"; 
   d="scan'208";a="125043795"
Received: from vl21-pfc1.u-bourgogne.fr (HELO alcazar2) ([193.52.245.13])
  by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 09 Mar 2015 14:57:30 +0100
Date: Mon, 9 Mar 2015 14:57:29 +0100
From: Maxence Guesdon <Maxence.Guesdon@inria.fr>
To: Alain Frisch <alain.frisch@lexifi.com>
Cc: caml-list@inria.fr
Message-ID: <20150309145729.6e5d0cf0@alcazar2>
In-Reply-To: <54FDA20D.1000503@lexifi.com>
References: <54FD8397.2060002@lexifi.com>
	<20150309141625.0da29f2b@alcazar2>
	<54FDA20D.1000503@lexifi.com>
Organization: INRIA
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Caml-list] Changing precedence and placement of attributes

On Mon, 09 Mar 2015 14:37:17 +0100
Alain Frisch <alain.frisch@lexifi.com> wrote:

> On 03/09/2015 02:16 PM, Maxence Guesdon wrote:
> > I'm quite "shocked" as it becomes inconsistent with other precedences
> > in type definitions. By now
> >    int * int list
> > is parsed as
> >    int * (int list)
> > and not as
> >    (int * int) list
> >
> > I would expect attributes to be associated the same way.
>=20
> Attributes really don't behave as type constructors; for instance,
>=20
>     (int, int) [@foo]
>=20
> is not allowed in type expressions.

Of course.

> I'd be more concerned about how attributes behave across various=20
> syntactic categories for similarly looking fragments.  For instance, in=20
> expressions
>=20
>    x * y [@foo]
>=20
> is already currently parsed as
>=20
>    (x * y) [@foo]
>=20
>=20
> But
>   - "x, y [@foo]" is parsed as "x, (y [@foo])"
>   - "x * y [@foo] * z" is accepted as an expression, and parsed as "(x *=
=20
> y)[@foo] * z".

This looks more intuitive/natural to me and more consistent with the
rest of the language.

I'm thinking about newcomers, when I'll have to explain them that rather
than writing "int * int list", they'll need parentheses in "(int * int)
list" to talk about list of pairs, but when it comes to attributes it's
the contrary. Sure, the language was not complicated enough :) Even if
attributes are not type constructors, one would expect some consistent
"feeling".

> > How would be parsed the following:
> >    int * int [@foo] * int
> > ?
>=20
> This would be rejected.  Doing the same as for expression would be=20
> weird, since * is a n-ary construction in types, not a binary operator.

If I understand, you mean that
  type t =3D int * int [@foo] * int
would be rejected and we use instead:
  type t =3D int * (int [@foo]) * int

Again, it's really not natural to me.
- m

> (Note: J=C3=A9r=C3=A9mie prepared a nice table in his pull request 152 on=
 Github;=20
> it shows how various forms are interpreted currently and after the change=
.)
>=20
>=20
> Alain