* Alternative syntax for function definitions? @ 2012-10-27 6:30 Yannick Duchêne (Hibou57) 2012-10-27 7:11 ` Dmitry A. Kazakov 0 siblings, 1 reply; 9+ messages in thread From: Yannick Duchêne (Hibou57) @ 2012-10-27 6:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Alternative syntax for function definitions? 2012-10-27 6:30 Alternative syntax for function definitions? Yannick Duchêne (Hibou57) @ 2012-10-27 7:11 ` Dmitry A. Kazakov 2012-10-27 7:49 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 9+ messages in thread From: Dmitry A. Kazakov @ 2012-10-27 7:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Alternative syntax for function definitions? 2012-10-27 7:11 ` Dmitry A. Kazakov @ 2012-10-27 7:49 ` Yannick Duchêne (Hibou57) 2012-10-27 8:37 ` Dmitry A. Kazakov 0 siblings, 1 reply; 9+ messages in thread From: Yannick Duchêne (Hibou57) @ 2012-10-27 7:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Alternative syntax for function definitions? 2012-10-27 7:49 ` Yannick Duchêne (Hibou57) @ 2012-10-27 8:37 ` Dmitry A. Kazakov 2012-10-27 9:02 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 9+ messages in thread From: Dmitry A. Kazakov @ 2012-10-27 8:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Alternative syntax for function definitions? 2012-10-27 8:37 ` Dmitry A. Kazakov @ 2012-10-27 9:02 ` Yannick Duchêne (Hibou57) 2012-10-27 9:38 ` Bill Findlay 2012-10-27 9:50 ` Dmitry A. Kazakov 0 siblings, 2 replies; 9+ messages in thread From: Yannick Duchêne (Hibou57) @ 2012-10-27 9:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Alternative syntax for function definitions? 2012-10-27 9:02 ` Yannick Duchêne (Hibou57) @ 2012-10-27 9:38 ` Bill Findlay 2012-10-27 11:13 ` Yannick Duchêne (Hibou57) 2012-10-27 9:50 ` Dmitry A. Kazakov 1 sibling, 1 reply; 9+ messages in thread From: Bill Findlay @ 2012-10-27 9:38 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Alternative syntax for function definitions? 2012-10-27 9:38 ` Bill Findlay @ 2012-10-27 11:13 ` Yannick Duchêne (Hibou57) 2012-10-27 23:46 ` Bill Findlay 0 siblings, 1 reply; 9+ messages in thread From: Yannick Duchêne (Hibou57) @ 2012-10-27 11:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Alternative syntax for function definitions? 2012-10-27 11:13 ` Yannick Duchêne (Hibou57) @ 2012-10-27 23:46 ` Bill Findlay 0 siblings, 0 replies; 9+ messages in thread From: Bill Findlay @ 2012-10-27 23:46 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Alternative syntax for function definitions? 2012-10-27 9:02 ` Yannick Duchêne (Hibou57) 2012-10-27 9:38 ` Bill Findlay @ 2012-10-27 9:50 ` Dmitry A. Kazakov 1 sibling, 0 replies; 9+ messages in thread From: Dmitry A. Kazakov @ 2012-10-27 9:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-10-29 2:39 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-10-27 6:30 Alternative syntax for function definitions? Yannick Duchêne (Hibou57) 2012-10-27 7:11 ` Dmitry A. Kazakov 2012-10-27 7:49 ` Yannick Duchêne (Hibou57) 2012-10-27 8:37 ` Dmitry A. Kazakov 2012-10-27 9:02 ` Yannick Duchêne (Hibou57) 2012-10-27 9:38 ` Bill Findlay 2012-10-27 11:13 ` Yannick Duchêne (Hibou57) 2012-10-27 23:46 ` Bill Findlay 2012-10-27 9:50 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox