[RFC] use of 'dot' notation on untagged types

[sttaft]

RFC on object.op notation being extended to untagged private types, and their completions. Since this was written, there seems to be a growing consensus to extend this to all untagged types.

Link to RFC: https://github.com/sttaft/ada-spark-rfcs/blob/topic/rfc-prefix-untagged/considered/rfc-prefixed-untagged.rst

[setton]

Yes to this! When I first wrote the binding to the cairo library, I introduced tagged types where they weren't needed, so that people could use the library in a way that's familiar to them in many other languages... Then I backtracked, thinking this was not morally right (and also potentially introduced an overhead in a performance-sensitive area). So, will look forward to this.

[mosteo]

This is beating a dead horse, but it also doesn't help with newcomers that synchronized objects are also object.method only.

[sttaft]

For what it is worth, synchronized interfaces and types derived from them can use either Object.Op(...) or Op(Object, ...). In any case, are you supportive of generalizing Object.Op notation to untagged types?

-Tuck

On Mon, Nov 18, 2019 at 11:21 AM Alejandro R Mosteo < notifications@github.com> wrote:

This is beating a dead horse, but it also doesn't help with newcomers that synchronized objects are also object.method only.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AdaCore/ada-spark-rfcs/pull/34?email_source=notifications&email_token=AANZ4FPS2HJ2BISHL5T6DP3QUK6IBA5CNFSM4JOME7QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEELALUA#issuecomment-555091408, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANZ4FJNGPJREH3H4UOAGXLQUK6IBANCNFSM4JOME7QA .

[mosteo]

are you supportive of generalizing Object.Op notation to untagged types?

Totally, within reasonableness. I get lost with the corner cases discussed in the ARG mailing list.

[sttaft]

On Mon, Nov 18, 2019 at 12:42 PM Alejandro R Mosteo < notifications@github.com> wrote:

are you supportive of generalizing Object.Op notation to untagged types?

Totally, within reasonableness. I get lost with the corner cases discussed in the ARG mailing list.

You and me both ... ;-)

-Tuck

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AdaCore/ada-spark-rfcs/pull/34?email_source=notifications&email_token=AANZ4FKI5NL3QTYCMTJVIHDQULHZJA5CNFSM4JOME7QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEELJHGA#issuecomment-555127704, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANZ4FNE5P25WCEZSQGXBUDQULHZJANCNFSM4JOME7QA .

[jere-software]

I'm all for this. I think it should be extended to all types. What problems do you expect from non private untagged types? Can you give some examples with code? The only issue I have been able to come up with this proposal affects both private and non private, so that distinction doesn't help:

Like if you have a private type that has a full view that is an access type, when you do Object.operation is the operation an operation on the access type or the type the access type points to? In my mind, I am ok with saying that Object.Op notation for all non tagged types is available except in the cases where the full view is an access type, then package.operation must be used where appropriate and access_value.operation is the normal.

[sttaft]

It seems the growing consensus is to allow "object.op" in all cases. Access types create some ambiguity, but that is true in other circumstances as well, and disallowing them altogether is awkward without "breaking" privacy (where rules depend on the nature of the full view of a private type), which in general would be significantly worse.

-Tuck

On Wed, Nov 27, 2019 at 9:47 PM Jere notifications@github.com wrote:

I'm all for this. I think it should be extended to all types. What problems do you expect from non private untagged types? Can you give some examples with code? The only issue I have been able to come up with this proposal affects both private and non private, so that distinction doesn't help:

Like if you have a private type that has a full view that is an access type, when you do Object.operation is the operation an operation on the access type or the type the access type points to? In my mind, I am ok with saying that Object.Op notation for all non tagged types is available except in the cases where the full view is an access type, then package.operation must be used where appropriate and access_value.operation is the normal.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AdaCore/ada-spark-rfcs/pull/34?email_source=notifications&email_token=AANZ4FMRTVLMEJHGFT4NHNDQV4WM7A5CNFSM4JOME7QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFLITLY#issuecomment-559319471, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANZ4FJSKCVIAFPSDJKS6N3QV4WM7ANCNFSM4JOME7QA .

[jere-software]

What is the intended method to handle the ambiguity from access types? If the type is visibly an access type, then the "." operation is a dereference and you must use package.operation notation for ambiguous functions, otherwise it is Object.operation notation maybe?

Side Note on breaking privacy: Ada already does that. For example, you can create Implicit_Dereference types, indexing functions, and iterator functions in the private section of a container's package and still use them in the aspects used in the full (public) view and iterate on them (at least in GNAT). I'm not opposed to this (I actually thinks this makes the language safer), but how do we pick and choose when it applies?

It seems the growing consensus is to allow "object.op" in all cases. Access types create some ambiguity, but that is true in other circumstances as well, and disallowing them altogether is awkward without "breaking" privacy (where rules depend on the nature of the full view of a private type), which in general would be significantly worse. … -Tuck On Wed, Nov 27, 2019 at 9:47 PM Jere @.***> wrote: I'm all for this. I think it should be extended to all types. What problems do you expect from non private untagged types? Can you give some examples with code? The only issue I have been able to come up with this proposal affects both private and non private, so that distinction doesn't help: Like if you have a private type that has a full view that is an access type, when you do Object.operation is the operation an operation on the access type or the type the access type points to? In my mind, I am ok with saying that Object.Op notation for all non tagged types is available except in the cases where the full view is an access type, then package.operation must be used where appropriate and access_value.operation is the normal.

[sttaft]

On Wed, Jan 8, 2020 at 11:27 AM Jere notifications@github.com wrote:

It seems the growing consensus is to allow "object.op" in all cases. Access types create some ambiguity, but that is true in other circumstances as well, and disallowing them altogether is awkward without "breaking" privacy (where rules depend on the nature of the full view of a private type), which in general would be significantly worse. … <#m-2447812689092163713> -Tuck ...

What is the intended method to handle the ambiguity from access types? If the type is visibly an access type, then the "." operation is a dereference and you must use package.operation notation for ambiguous functions, otherwise it is Object.operation notation maybe?

There is actually no Ada rule that says "." after an access value always implies an implicit dereference. I would suggest that we shift the rules on selected components (RM 4.1.3) to allow the identifier for a primitive subprogram of the type of the prefix after a "." even if the type (say, T) of the prefix is a named access type, so long as that primitive subprogram has the first parameter being one of the options now allowed for tagged types (parameter of type T or access parameter designating T). This will create some ambiguity if the access type and its designated type have primitives with the same identifiers, but that seems relatively uncommon. We could create a preference, but ambiguity is often better than a mysterious preference. There is already a preference for component names over primitive subprogram names in selected-component notation, and I presume that would still apply.

My justification for this suggestion is that it is annoying if code that works fine when you can see only the private type becomes illegal when you can see the full type. If the full type for a private type is an access type, the above suggestion should avoid this annoyance in most cases.

-Tuck

[sttaft]

Here is an update that allows object.op() notation on any type.

[rfx77]

I would also allow the dot notation on methods of child packages. there is no real reason why this is not possible since child packages cann access the private part of their parent.