Alternative syntax for function definitions?

Alternative syntax for function definitions?

[Yannick Duchêne (Hibou57)]

Hi people,

Just a silly idea I have sometime.

You know the question of having type at the left or at the right of a  
declaration, used to be discussed when comparing Eiffel or Pascal like  
syntax, to C like syntax. One argument is that “I : Integer;” is more  
natural than “int i;” because it do as a dictionary do, putting the  
defined element at the left. I have the feeling the question could  
similarly apply to the syntax used for function definition. I feel  
sometime, being able to write something as below, could be more readable:

     function P return T of (A1, A2, ...);

What's your feeling about such an alternative notation?

I feel it would be the most relevant when having a list of accessors  
functions, like in

    function P1 (A : A_Type) return T1;
    function P2 (A : A_Type) return T2;
    function P3 (A : A_Type) return T3;
    function P4 (A : A_Type) return T4;
    function P5 (A : A_Type) return T5;

Here, the most relevant part is the function names and their return type,  
and the argument is always the same, but it comes between both, and  
pollute the reading process, especially when the `(A : A_Type)` part is  
less short (which is common).

    function P1 return T1 of (A : A_Type);
    function P2 return T2 of (A : A_Type);
    function P3 return T3 of (A : A_Type);
    function P4 return T4 of (A : A_Type);
    function P5 return T5 of (A : A_Type);

The above is more readable I believe, and could be reasonable, as it adds  
no new reserved word does not create potential ambiguity with the existing  
syntax.

Similar comment would not apply to procedure (would not be useful, that's  
relevant with function definitions only).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Alternative syntax for function definitions?

[Dmitry A. Kazakov]

On Sat, 27 Oct 2012 08:30:18 +0200, Yannick Duchêne (Hibou57) wrote:

> Just a silly idea I have sometime.
> 
> You know the question of having type at the left or at the right of a  
> declaration, used to be discussed when comparing Eiffel or Pascal like  
> syntax, to C like syntax. One argument is that “I : Integer;” is more  
> natural than “int i;” because it do as a dictionary do, putting the  
> defined element at the left. I have the feeling the question could  
> similarly apply to the syntax used for function definition. I feel  
> sometime, being able to write something as below, could be more readable:
> 
>      function P return T of (A1, A2, ...);
> 
> What's your feeling about such an alternative notation?

I : Integer; declares an object of type Integer. Function declares an
anonymous function type and a singleton object, so the difference.

> I feel it would be the most relevant when having a list of accessors  
> functions, like in
> 
>     function P1 (A : A_Type) return T1;
>     function P2 (A : A_Type) return T2;
>     function P3 (A : A_Type) return T3;
>     function P4 (A : A_Type) return T4;
>     function P5 (A : A_Type) return T5;

The type A_Type should simply implement a record interface:

   type A_Type is ... and record
      P1 : T1;
      P2 : T2;
      ...
      P5 : T5;
   end record;
   ...
private
   ... -- functions implementing "components" P1..P5

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Alternative syntax for function definitions?

[Yannick Duchêne (Hibou57)]

Le Sat, 27 Oct 2012 09:11:28 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> I feel it would be the most relevant when having a list of accessors
>> functions, like in
>>
>>     function P1 (A : A_Type) return T1;
>>     function P2 (A : A_Type) return T2;
>>     function P3 (A : A_Type) return T3;
>>     function P4 (A : A_Type) return T4;
>>     function P5 (A : A_Type) return T5;
>
> The type A_Type should simply implement a record interface:
>
>    type A_Type is ... and record
>       P1 : T1;
>       P2 : T2;
>       ...
>       P5 : T5;
>    end record;
>    ...
> private
>    ... -- functions implementing "components" P1..P5

You got the point (I was precisely thinking of functions define on private  
type, that is, the record is not exposed), but unless I missed it, there  
is nothing like a function implementing the access to a record component  
in Ada. I agree that would be the best, but less likely to be done (we  
already have dotted notation for function designation, but only for tagged  
types).



-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Alternative syntax for function definitions?

[Dmitry A. Kazakov]

On Sat, 27 Oct 2012 09:49:04 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Sat, 27 Oct 2012 09:11:28 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>>> I feel it would be the most relevant when having a list of accessors
>>> functions, like in
>>>
>>>     function P1 (A : A_Type) return T1;
>>>     function P2 (A : A_Type) return T2;
>>>     function P3 (A : A_Type) return T3;
>>>     function P4 (A : A_Type) return T4;
>>>     function P5 (A : A_Type) return T5;
>>
>> The type A_Type should simply implement a record interface:
>>
>>    type A_Type is ... and record
>>       P1 : T1;
>>       P2 : T2;
>>       ...
>>       P5 : T5;
>>    end record;
>>    ...
>> private
>>    ... -- functions implementing "components" P1..P5
> 
> You got the point (I was precisely thinking of functions define on private  
> type, that is, the record is not exposed), but unless I missed it, there  
> is nothing like a function implementing the access to a record component  
> in Ada.

I know. The point is that there are underlying concepts Ada's type system
fails to capture. The language was already suffered dearly from plastic
surgeries to get another one.

> I agree that would be the best, but less likely to be done (we  
> already have dotted notation for function designation, but only for tagged  
> types).

That is no problem. All types should have classes anyway. The dotted
notation itself is an implementation of some record interface.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Alternative syntax for function definitions?

[Yannick Duchêne (Hibou57)]

Le Sat, 27 Oct 2012 10:37:11 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> That is no problem. All types should have classes anyway. The dotted
> notation itself is an implementation of some record interface.
To talk about that point, I'm thinking of always using tagged types  
instead of legacy records, so as to be able to hide or expose the type  
definition without consequences on the client side, or even just change  
the layout. That's more resilient: if you have three properties A, B, C,  
where one is derived from the two other, say C is derived from A and B,  
and then decide later that instead C will be stored and B derived from A  
and C, you can do that without breaking client, if you use tagged records  
(you can't with legacy record). But I expect generalisation of use of  
tagged types to impact efficiency with most compilers (although I'm  
actually using only one).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Alternative syntax for function definitions?

[Bill Findlay]

On 27/10/2012 10:02, in article op.wmtx2nxkule2fv@cardamome, "Yannick
Duch�ne   (Hibou57)" <yannick_duchene@yahoo.fr> wrote:

> Le Sat, 27 Oct 2012 10:37:11 +0200, Dmitry A. Kazakov
> <mailbox@dmitry-kazakov.de> a �crit:
>> That is no problem. All types should have classes anyway. The dotted
>> notation itself is an implementation of some record interface.
> To talk about that point, I'm thinking of always using tagged types
> instead of legacy records, so as to be able to hide or expose the type
> definition without consequences on the client side, or even just change
> the layout. That's more resilient: if you have three properties A, B, C,
> where one is derived from the two other, say C is derived from A and B,
> and then decide later that instead C will be stored and B derived from A
> and C, you can do that without breaking client, if you use tagged records

How?

> (you can't with legacy record).

Why not?

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Alternative syntax for function definitions?

[Yannick Duchêne (Hibou57)]

Le Sat, 27 Oct 2012 11:38:06 +0200, Bill Findlay  
<yaldnif.w@blueyonder.co.uk> a écrit:

> On 27/10/2012 10:02, in article op.wmtx2nxkule2fv@cardamome, "Yannick
> Duchêne   (Hibou57)" <yannick_duchene@yahoo.fr> wrote:
>
>> Le Sat, 27 Oct 2012 10:37:11 +0200, Dmitry A. Kazakov
>> <mailbox@dmitry-kazakov.de> a écrit:
>>> That is no problem. All types should have classes anyway. The dotted
>>> notation itself is an implementation of some record interface.
>> To talk about that point, I'm thinking of always using tagged types
>> instead of legacy records, so as to be able to hide or expose the type
>> definition without consequences on the client side, or even just change
>> the layout. That's more resilient: if you have three properties A, B, C,
>> where one is derived from the two other, say C is derived from A and B,
>> and then decide later that instead C will be stored and B derived from A
>> and C, you can do that without breaking client, if you use tagged  
>> records
>
> How?
>
>> (you can't with legacy record).
>
> Why not?
>

Shifting from the initial topic, but let's go for that new one.

A dirty practical case will tell the story better.


     type T is ...;

     type R
        is record
           A : T;
           B : T;
           C : T;
        end record;

Say the above is OK.

Later (maintenance and re-factoring always happens, sooner or later),  
someone notice C is a function of A and B, and should not be stored in the  
(legacy) record, but derived from A and B.


     type T is ...;

     type R
        is record
           A : T;
           B : T;
        end record;

     function C (A : R) return Natural is (...);

Looks fine, but somewhere else:

     X : R;
     Y : Natural := X.C;

Ouch, does not compile any more, while the program logic is still the  
same, and no name has changed.

Some one say: hey, you are using an old legacy record, use a tagged record  
instead!

     type T is new Natural;

     type R
        is tagged record
           A : Natural;
           B : Natural;
        end record;

    function C (A : R'Class) return Natural is (0);

Looks as much fine, but somewhere else, it's fine too (better):

     X : R;
     Y : Natural := X.C;


Just does not work with procedure, though. Thus

     X.C := Y

Will still be broken, even with a tagged record, which does not solve that  
case.


Honestly, there is another way, which is to never expose record fields in  
public part, and always use function/procedure. But that tends to produce  
the same issue has the one which was solved with the introduction of the  
“use type” clause. When I do “X.C”, I see it as the same as what “use  
type” do.

I can't make my mind between these two strategy. Using records to expose  
interface works fine only with tagged records (and only for functions to  
read, not procedures to write); using function/procedure to expose  
interfaces is often noisy (that's why I was thinking about this syntax  
variation, in the initial post, among other things, I did not tell).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Alternative syntax for function definitions?

[Bill Findlay]

On 27/10/2012 12:13, in article op.wmt35luxule2fv@cardamome, "Yannick
Duch�ne   (Hibou57)" <yannick_duchene@yahoo.fr> wrote:

> A dirty practical case will tell the story better.
> 
> 
>      type T is ...;
> 
>      type R
>         is record
>            A : T;
>            B : T;
>            C : T;
>         end record;
> 
> Say the above is OK.
> 
> Later ...
> 
> 
>      type T is ...;
> 
>      type R
>         is record
>            A : T;
>            B : T;
>         end record;
> 
>      function C (A : R) return Natural is (...);
> 
> Looks fine, but somewhere else:
> 
>      X : R;
>      Y : Natural := X.C;
> 
> Ouch, does not compile any more, while the program logic is still the
> same, and no name has changed.
...
> Some one say: hey, you are using an old legacy record, use a tagged record
> instead!
> 
>      type T is new Natural;
> 
>      type R
>         is tagged record
>            A : Natural;
>            B : Natural;
>         end record;
> 
>     function C (A : R'Class) return Natural is (0);
> 
> Looks as much fine, but somewhere else, it's fine too (better):
> 
>      X : R;
>      Y : Natural := X.C;
> 
> 
> Just does not work with procedure, though. Thus
> 
>      X.C := Y
> 
> Will still be broken, even with a tagged record, which does not solve that
> case.

OK.

> Honestly, there is another way, which is to never expose record fields in
> public part, and always use function/procedure. But that tends to produce
> the same issue has the one which was solved with the introduction of the
> �use type� clause. When I do �X.C�, I see it as the same as what �use
> type� do.

You lose me there.

> I can't make my mind between these two strategy. Using records to expose
> interface works fine only with tagged records (and only for functions to
> read, not procedures to write); using function/procedure to expose
> interfaces is often noisy (that's why I was thinking about this syntax
> variation, in the initial post, among other things, I did not tell).

I think we are groping back to the 'uniform referent' idea: that the syntax
of an access should not vary according to its implementation.  Ada has
always made nods in that direction, and makes more with Ada 2102; but I dare
say yet further improvements could be made.

In the absence of these ameliorations, I use all three techniques: public
record types, private record types, and tagged types; chosen according to
the semantic circumstances, likely future needs, and anticipated performance
issues.  Getting that right(ish) is not a matter of following rules or
adhering to a dogma.  It is a matter of experience and good judgement.
No linguistic technology can substitute for these qualities, although it can
certainly help.  And if the record really is 'legacy', foisted on you be a
predecessor, your own better judgement is not much help. I symapathize. 8-)

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Alternative syntax for function definitions?

[Dmitry A. Kazakov]

On Sat, 27 Oct 2012 11:02:37 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Sat, 27 Oct 2012 10:37:11 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>> That is no problem. All types should have classes anyway. The dotted
>> notation itself is an implementation of some record interface.
> To talk about that point, I'm thinking of always using tagged types  
> instead of legacy records, so as to be able to hide or expose the type  
> definition without consequences on the client side, or even just change  
> the layout. That's more resilient: if you have three properties A, B, C,  
> where one is derived from the two other, say C is derived from A and B,  
> and then decide later that instead C will be stored and B derived from A  
> and C, you can do that without breaking client, if you use tagged records  
> (you can't with legacy record). But I expect generalisation of use of  
> tagged types to impact efficiency with most compilers (although I'm  
> actually using only one).

The problem is conflation of the interface and implementation. Ada 83
record types are both interface and implementation. Which is OK only in the
private part of the package. In public interfaces it is a fragile design
the language unfortunately encourages.

This separation has nothing to do with tagged types, classes and
inheritance. It has no impact on efficiency other that different
implementations of the same interface could perform differently.

People are confusing these issues all the time.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de