[Caml-list] Changing precedence and placement of attributes

[Caml-list] Changing precedence and placement of attributes

[Alain Frisch]

Dear caml-list,

Following a feature request by whitequark and a pull request by Jérémie 
Dimino, we're considering two related changes to attributes:

  - Their precedence on type expressions, so that "int * int [@foo]" is 
parsed as "(int * int) [@foo]" instead of "int * (int [@foo])".

  - Their placement on constructor/field declaration, so that one would 
write "A of int [@foo]" or "a : int [@foo]" instead of "A [@foo] of int" 
or "a [@foo] : int".

References:

  - http://caml.inria.fr/mantis/view.php?id=6612
  - https://github.com/ocaml/ocaml/pull/152

There seems to be a strong support in favor of the change (at least, 
nobody objected to it on principle).  But it can clearly break or change 
the interpretation of existing code.  I'm still in favor of doing the 
change as soon as possible.

So my question is:  would anyone be negatively impacted (or just 
shocked) if the change was done as part of the next bug fix release 
(4.02.2)?


Alain

Re: [Caml-list] Changing precedence and placement of attributes

[Maxence Guesdon]

On Mon, 09 Mar 2015 12:27:19 +0100
Alain Frisch <alain.frisch@lexifi.com> wrote:

> Dear caml-list,

Hello,
> 
> Following a feature request by whitequark and a pull request by Jérémie 
> Dimino, we're considering two related changes to attributes:
> 
>   - Their precedence on type expressions, so that "int * int [@foo]" is 
> parsed as "(int * int) [@foo]" instead of "int * (int [@foo])".
> 
>   - Their placement on constructor/field declaration, so that one would 
> write "A of int [@foo]" or "a : int [@foo]" instead of "A [@foo] of int" 
> or "a [@foo] : int".
> 
> References:
> 
>   - http://caml.inria.fr/mantis/view.php?id=6612
>   - https://github.com/ocaml/ocaml/pull/152
> 
> There seems to be a strong support in favor of the change (at least, 
> nobody objected to it on principle).  But it can clearly break or change 
> the interpretation of existing code.  I'm still in favor of doing the 
> change as soon as possible.
> 
> So my question is:  would anyone be negatively impacted (or just 
> shocked) if the change was done as part of the next bug fix release 
> (4.02.2)?

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.

How would be parsed the following:
  int * int [@foo] * int
?

- m

Re: [Caml-list] Changing precedence and placement of attributes

[Alain Frisch]

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.

Attributes really don't behave as type constructors; for instance,

    (int, int) [@foo]

is not allowed in type expressions.


I'd be more concerned about how attributes behave across various 
syntactic categories for similarly looking fragments.  For instance, in 
expressions

   x * y [@foo]

is already currently parsed as

   (x * y) [@foo]


But
  - "x, y [@foo]" is parsed as "x, (y [@foo])"
  - "x * y [@foo] * z" is accepted as an expression, and parsed as "(x * 
y)[@foo] * z".

> How would be parsed the following:
>    int * int [@foo] * int
> ?

This would be rejected.  Doing the same as for expression would be 
weird, since * is a n-ary construction in types, not a binary operator.

(Note: Jérémie prepared a nice table in his pull request 152 on Github; 
it shows how various forms are interpreted currently and after the change.)


Alain

Re: [Caml-list] Changing precedence and placement of attributes

[Maxence Guesdon]

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.
> 
> Attributes really don't behave as type constructors; for instance,
> 
>     (int, int) [@foo]
> 
> is not allowed in type expressions.

Of course.

> I'd be more concerned about how attributes behave across various 
> syntactic categories for similarly looking fragments.  For instance, in 
> expressions
> 
>    x * y [@foo]
> 
> is already currently parsed as
> 
>    (x * y) [@foo]
> 
> 
> But
>   - "x, y [@foo]" is parsed as "x, (y [@foo])"
>   - "x * y [@foo] * z" is accepted as an expression, and parsed as "(x * 
> 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
> > ?
> 
> This would be rejected.  Doing the same as for expression would be 
> weird, since * is a n-ary construction in types, not a binary operator.

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

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

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

Re: [Caml-list] Changing precedence and placement of attributes

[Leo White]

> If I understand, you mean that
>   type t = int * int [@foo] * int
> would be rejected and we use instead:
>   type t = int * (int [@foo]) * int
>
> Again, it's really not natural to me.

I haven't looked at the patch closely, but it seems roughly consistent
with how "as 'a" is handled. This makes sense to me, since in both
cases you are attaching additional information to the type.

Regards,

Leo

Re: [Caml-list] Changing precedence and placement of attributes

[Ben Millwood]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

I think I share Maxence's concerns insofar as if someone polled me on what
the example expressions should mean, I would intuitively make the opposite
choices from the ones proposed. But whatever happens I won't be profoundly
upset :)

On 9 March 2015 at 14:27, Leo White <leo@lpw25.net> wrote:

> > If I understand, you mean that
> >   type t = int * int [@foo] * int
> > would be rejected and we use instead:
> >   type t = int * (int [@foo]) * int
> >
> > Again, it's really not natural to me.
>
> I haven't looked at the patch closely, but it seems roughly consistent
> with how "as 'a" is handled. This makes sense to me, since in both
> cases you are attaching additional information to the type.
>
> Regards,
>
> Leo
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 1648 bytes --]