* renaming Interfaces.Java.Ada_To_Java_String to the + operator @ 1998-01-11 0:00 Terry J. Westley 1998-01-10 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 40+ messages in thread From: Terry J. Westley @ 1998-01-11 0:00 UTC (permalink / raw) Does anyone know who's idea it was to rename the Interfaces.Java.Ada_To_Java_String function to the "+" operator in the Intermetrics Java bindings? I'm using the Aonix ObjectAda translator but assume that the Java class library came from Intermetrics. Thanks much for this clever little idea. IMHO, it really improves ease of use and code readability. Does this idea originate with the Java work at Intermetrics or does it predate it? I find the inverse of + useful as well: function "-" (s : String_Ptr) return String renames Interfaces.Java.Java_To_Ada_String; Does anyone think this is a misuse of operator overloading? -- Terry J. Westley, Principal Engineer Calspan SRL Corp, P.O. Box 400, Buffalo, NY 14225 westley@calspan.com http://www.calspan.com/ ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-11 0:00 renaming Interfaces.Java.Ada_To_Java_String to the + operator Terry J. Westley @ 1998-01-10 0:00 ` Robert Dewar 1998-01-10 0:00 ` Matthew Heaney 1998-01-11 0:00 ` Chris Morgan 1998-01-11 0:00 ` Nick Roberts 1998-01-12 0:00 ` Tucker Taft 2 siblings, 2 replies; 40+ messages in thread From: Robert Dewar @ 1998-01-10 0:00 UTC (permalink / raw) Terry asks <<Does anyone know who's idea it was to rename the Interfaces.Java.Ada_To_Java_String function to the "+" operator in the Intermetrics Java bindings? I'm using the Aonix ObjectAda translator but assume that the Java class library came from Intermetrics. >> This is an old, old idea (the use of unary + as a reasonably un-noisy conversion operator). Jean Ichbiah was always a fan of this idea, which I think was firmly in mind at the time of the original Ada design. During the Ada95 revision, Jean suggested (and I supported) the idea of a new unary operator (the currency conversion character, a small square with inward curved sides is a nice choice) that would be undefined, but available for user definition, with the specific idea that it be used for this kind of conversion operator. However, the idea did not catch many other people's imagination so it died. Terry suggests using the "-" for the conversion in the other direction, but I think that is a mistake. The use of "+" is reasonable because this is a seldom used operator, since it has sort of "null" semantics, which in a sense is just right for conversion. The negation operator has much stronger semantics in typical use. Also in a typical situation there is no real reason to think of conversion in one direction being in any way non-symmetrical with conversion in the other direction. The normal technique (for those who like the unary plus technique, be aware that there are some people who *really* dislike this usage) is to simply use "+" for both directions. The overloading resolution figures out which one you are talking about. Robert Dewar ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-10 0:00 ` Robert Dewar @ 1998-01-10 0:00 ` Matthew Heaney 1998-01-13 0:00 ` Tom Moran 1998-01-11 0:00 ` Chris Morgan 1 sibling, 1 reply; 40+ messages in thread From: Matthew Heaney @ 1998-01-10 0:00 UTC (permalink / raw) In article <dewar.884489205@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >Also in a typical situation there is no real reason to think of conversion >in one direction being in any way non-symmetrical with conversion in the >other direction. The normal technique (for those who like the unary plus >technique, be aware that there are some people who *really* dislike this >usage) is to simply use "+" for both directions. The overloading resolution >figures out which one you are talking about. I like this use of "+" as a conversion operation too. I often use it bounded strings: subtype VString_Length_Range is Natural range 0 .. 80; type VSTring (Length : VSTring_Length_Range := 0) is record S : String (1 .. Length); end record; function "+" (S : String) return VString is begin return VString'(S'Length, S); end; function "+" (VS : String) return String is begin return VS.S; end; This way you can simulate something close to what you can do in C: declare Table : constant VString_Array := (+"this is a first element", +"second", +"yet another", +"this is the very last string I promise"); begin ... If you meet someone who dislikes this use of "+", then tell them how it's refered to in the RM: as the "identity" operator. It has just the sort of benign semantics Robert was refering to, which makes it ideal for this kind of thing. It's a more or less definitionless operator that the programmer can define herself, to have the semantics she wants. Perhaps the RM should have made this more clear. I think I read somewhere how Stroustrup thought that the identity operator was basically useless, as it has no useful semantics. That may be true in C++, because the programmer can define conversion operators that get invoked automatically. But in Ada, what you see is what you get (except for Controlled types), and so some constructor has to be called explicitly. The identity operator has just the syntactic lightness we're looking for here. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-10 0:00 ` Matthew Heaney @ 1998-01-13 0:00 ` Tom Moran 1998-01-13 0:00 ` Stephen Leake ` (3 more replies) 0 siblings, 4 replies; 40+ messages in thread From: Tom Moran @ 1998-01-13 0:00 UTC (permalink / raw) What does +"abc"&"xyz" mean, and, more importantly, how many people know without having to look it up? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-13 0:00 ` Tom Moran @ 1998-01-13 0:00 ` Stephen Leake 1998-01-13 0:00 ` Nick Roberts 1998-01-13 0:00 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 1 reply; 40+ messages in thread From: Stephen Leake @ 1998-01-13 0:00 UTC (permalink / raw) Tom Moran wrote: > > What does > +"abc"&"xyz" > mean, and, more importantly, how many people know without having to > look it up? Oops, I forgot to think about operator precedence in my first post (I see now that is the point of Tom's post :(. This means: convert "abc" to some other type, then concatenate "xyz" The responsible package author will overload "&" as well as "+", to handle this correctly, as the reader's first impulse expects :). -- - Stephe ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-13 0:00 ` Stephen Leake @ 1998-01-13 0:00 ` Nick Roberts 0 siblings, 0 replies; 40+ messages in thread From: Nick Roberts @ 1998-01-13 0:00 UTC (permalink / raw) No he won't Stephe. Operator precedence is fixed in Ada. This is (cited as) one of Ada's design features. +"abc"&"xyz" means "+"("abc")&"xyz" always. (You need to modify your impulses ;-) -- Nick Roberts Croydon, UK Proprietor, ThoughtWing Software; Independent Software Development Consultant * Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 * *** Eats three shredded spams every morning for breakfast *** Stephen Leake <Stephen.Leake@gsfc.nasa.gov> wrote in article <34BBBB88.DDE@gsfc.nasa.gov>... > Tom Moran wrote: > > > > What does > > +"abc"&"xyz" > > mean, and, more importantly, how many people know without having to > > look it up? > > Oops, I forgot to think about operator precedence in my first post (I > see now that is the point of Tom's post :(. > > This means: > > convert "abc" to some other type, then concatenate "xyz" > > The responsible package author will overload "&" as well as "+", to > handle this correctly, as the reader's first impulse expects :). > > -- > - Stephe > ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-13 0:00 ` Tom Moran 1998-01-13 0:00 ` Stephen Leake @ 1998-01-13 0:00 ` Robert Dewar 1998-01-13 0:00 ` Stephen Leake [not found] ` <En3Cxz.7HD@world.std.com> 3 siblings, 0 replies; 40+ messages in thread From: Robert Dewar @ 1998-01-13 0:00 UTC (permalink / raw) Tom Moran said <<What does +"abc"&"xyz" mean, and, more importantly, how many people know without having to look it up? >> Presumably in the context you intend the "+" to be a unary conversion operator. This conversion operator would then apply to "abc", since & is an adding operator. Now I would not expect everyone to know the relative precedence of these operators (I am too close to the compiler in this regard, I even know what the value of -5/3 is, careful that's a trick question :-) So if you had to write this, I would think a responsible programmer would write: (+"abc") & "xyz" to emphasize the meaning, although perhaps one might decide that the normal spacing around binary operators is enough (such spacing is a standard part of the GNAT lexical conventions, spaces for binary operators, but not for unary operators) +"abc" & "xyz" However, in real practice this is a somewhat unlikely piece of program code in any case. Why? Because normally one would create a set of coherent abstractions in which there was an & operator that did the conversion automatically. It is only when a term appears on its own that the use of "+" is really necessary. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-13 0:00 ` Tom Moran 1998-01-13 0:00 ` Stephen Leake 1998-01-13 0:00 ` Robert Dewar @ 1998-01-13 0:00 ` Stephen Leake [not found] ` <En3Cxz.7HD@world.std.com> 3 siblings, 0 replies; 40+ messages in thread From: Stephen Leake @ 1998-01-13 0:00 UTC (permalink / raw) Tom Moran wrote: > > What does > +"abc"&"xyz" > mean, and, more importantly, how many people know without having to > look it up? A) concatenate "abc" and "xyz", getting "abczyz". Then convert to some other string type. B) me for one :) Note that if "+" is defined to take String, it should also be defined to take Wide_String. (Does Java support Unicode?) -- - Stephe ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <En3Cxz.7HD@world.std.com>]
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator [not found] ` <En3Cxz.7HD@world.std.com> @ 1998-01-20 0:00 ` Robert Dewar 1998-01-21 0:00 ` Stephen Leake 1998-01-22 0:00 ` Robert Dewar 0 siblings, 2 replies; 40+ messages in thread From: Robert Dewar @ 1998-01-20 0:00 UTC (permalink / raw) <<is syntactically illegal, without looking it up (and without feeding it to a compiler)? GNAT complains "missing operand" pointing to the second plus, which isn't the most helpful error message I've ever seen. Rational's compiler complains about a missing expression before the second plus, which is no better. >> [This was for the illegal use of unary plus and minus as in x & + b it is always hard to know what might be the "most helpful" message, since of course this involves telephathy. I wonder if we changed this to "unary plus[minus] requires parenthesization in this context" or somesuch, would this be an overall improvement, maybe, it is a tossup. The problem is that one or the other is correct but it is hard to tell which. Yes, if you got fancy you could use type information to tell, but that's reallyu *awfully* heavy in implementation complexity. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-20 0:00 ` Robert Dewar @ 1998-01-21 0:00 ` Stephen Leake 1998-01-22 0:00 ` Robert Dewar 1 sibling, 0 replies; 40+ messages in thread From: Stephen Leake @ 1998-01-21 0:00 UTC (permalink / raw) Robert Dewar wrote: > > <<is syntactically illegal, without looking it up (and without feeding it > to a compiler)? GNAT complains "missing operand" pointing to the second > plus, which isn't the most helpful error message I've ever seen. > Rational's compiler complains about a missing expression before the > second plus, which is no better. > >> > > [This was for the illegal use of unary plus and minus as in > > x & + b > > it is always hard to know what might be the "most helpful" message, since > of course this involves telephathy. I wonder if we changed this to > "unary plus[minus] requires parenthesization in this context" > > or somesuch, would this be an overall improvement, maybe, it is a tossup. > The problem is that one or the other is correct but it is hard to tell > which. Perhaps you can just print both error messages; let the user figure it out. When there are only two choices, this isn't bad. In places where there are lots of choices, maybe you could have a "verbose error" compiler option. > > Yes, if you got fancy you could use type information to tell, but that's > reallyu *awfully* heavy in implementation complexity. -- - Stephe ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-20 0:00 ` Robert Dewar 1998-01-21 0:00 ` Stephen Leake @ 1998-01-22 0:00 ` Robert Dewar 1998-01-22 0:00 ` Anonymous ` (2 more replies) 1 sibling, 3 replies; 40+ messages in thread From: Robert Dewar @ 1998-01-22 0:00 UTC (permalink / raw) I asked: <<is syntactically illegal, without looking it up (and without feeding it to a compiler)? GNAT complains "missing operand" pointing to the second plus, which isn't the most helpful error message I've ever seen. Rational's compiler complains about a missing expression before the second plus, which is no better. >> [This was for the illegal use of unary plus and minus as in x & + b it is always hard to know what might be the "most helpful" message, since of course this involves telephathy. I wonder if we changed this to "unary plus[minus] requires parenthesization in this context" or somesuch, would this be an overall improvement, maybe, it is a tossup. The problem is that one or the other is correct but it is hard to tell which. >> But was disappointed to get almost no response (Stephe thanks!) The one response suggests giving both messages, but I think it is better generally to choose just one. The trouble with giving two is that then you are absolutely SURE you have generated at least one junk message, which seems unforutnate. But I really would like some more input on this (surely we still have *some* Ada folks around the newsgroup, and not just cross-posting trollers :-) It is really useful to have lots of input on error message things, since they are so subjective. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-22 0:00 ` Robert Dewar @ 1998-01-22 0:00 ` Anonymous [not found] ` <dewar.885498969@merv> 1998-01-23 0:00 ` Anonymous 1998-01-24 0:00 ` Tucker Taft 2 siblings, 1 reply; 40+ messages in thread From: Anonymous @ 1998-01-22 0:00 UTC (permalink / raw) <01bd1e34$1632c2c0$24326489@Westley-PC.calspan.com> <dewar.884489205@merv> <mheaney-ya023680001001982248520001@news.ni.net> <34bba5a1.224459@SantaClara01.news.InterNex.Net> <En3Cxz.7HD@world.std.com> <dewar.885328875@merv> On 22 Jan 1998 01:18:36 -0500, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > > > x & + b asking for comments about the error message that a compiler should put out when it encounters this kind of construct. The writer intended to use unary "+", but forgot to surround "+b" with parentheses. I frequently don't see postings to this newsgroup, or see them out of order. This is the first I've seen of Dewar's request about this. If I'd seen it earlier, I might have replied earlier. "X & + B" might be "X & Y + B", where the writer didn't hit the Y key hard enough and didn't notice it, or it might be "X & (+ B)" without parentheses. If it's the former, the compiler should put out an error message about missing the left operand for binary "+"; if the latter, about needing parentheses for unary "+" in this context. Is it possible for the compiler to tell the difference? In real Ada, we're more likely to see "Xenia & +Bernard" than "X & + B" (spaces significant). It this likely to be a typo for "Xenia & Yakob + Bernard"? I think not. Therefore, I think the error message should generally be about unary "+". Also, unary "+" and "-" generally don't have following spaces (though I've seen pretty-printed code where they did), so the spacing could give a clue as to what was intended. That's my valeur de deux centimes. Jeff Carter PGP:1024/440FBE21 My real e-mail address: ( carter @ innocon . com ) "Now go away or I shall taunt you a second time." Monty Python & the Holy Grail Posted with Spam Hater - see http://www.compulink.co.uk/~net-services/spam/ ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <dewar.885498969@merv>]
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator [not found] ` <dewar.885498969@merv> @ 1998-01-23 0:00 ` Geert Bosch 1998-01-23 0:00 ` Tom Moran 1 sibling, 0 replies; 40+ messages in thread From: Geert Bosch @ 1998-01-23 0:00 UTC (permalink / raw) Robert Dewar wrote: How universal is the convention of no space after unary operators? Depends on the operator of course ;-). Operators like "not" and "abs" will be followed by a space usually, but a space after a unary "+" or "-" would be very confusing (at least to me). Code like A := + 3; makes me think an A was forgotten after the ":=". I'd think for error recovery purposes it is safe to assume that unary plus/minus is not followed by a space. So plus/minus followed by space is binary and "missing operand" is correct diagnosis, otherwise operator may be unary or binary and the longer message should be given. Regards, Geert ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator [not found] ` <dewar.885498969@merv> 1998-01-23 0:00 ` Geert Bosch @ 1998-01-23 0:00 ` Tom Moran 1 sibling, 0 replies; 40+ messages in thread From: Tom Moran @ 1998-01-23 0:00 UTC (permalink / raw) >How universal is the convention of no space after unary operators? In scanning the 60 or so software components on the Walnut Creek CDROM I found 26 uses of unary "+", none followed by a space. (TARTE has 14, all in machine code calls and MATPACK has 12, all but one in Assert calls Perhaps it would be more useful, though, to scan some programs using the Intermetrics Ada -> Java binding. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-22 0:00 ` Robert Dewar 1998-01-22 0:00 ` Anonymous @ 1998-01-23 0:00 ` Anonymous 1998-01-24 0:00 ` Tucker Taft 2 siblings, 0 replies; 40+ messages in thread From: Anonymous @ 1998-01-23 0:00 UTC (permalink / raw) <199801221427.PAA05971@basement.replay.com> On 22 Jan 1998 15:00:06 -0500, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > > How universal is the convention of no space after unary operators? > > GNAT quite often uses spacing as a clue for messages. FOr example > > a := b > c; > > generates a missing semicolon flagged right after the b, but > > a := b c; > > generates a missing operator message flagged between the b and the c. > > So this is a definite possible way of making the distinction if it seems > statistically right to do so. > > Of course the double barrelled error message > > missing operand or missing parentheses around unary "+" > > is not too long, so that's a possibility with two votes so far ... > Yeah, that one's OK. I've never seen hand-written code with a space after unary "+" or "-". (Hand-written code always has a space after "abs", which is a unary operator. Henceforth, I'm only talking about unary "+" and "-".) However, I have seen code formatters that put a space between them and the operand (Rational Apex is one, if I'm not mistaken). As for statistics about spacing and unary operators, what are the statistics from your several MSLOC regression test suite + ACVC + DEC tests? That's probably as representative a sample as anyone has access to. Jeff Carter PGP:1024/440FBE21 My real e-mail address: ( carter @ innocon . com ) "Perfidious English mouse-dropping hoarders." Monty Python & the Holy Grail Posted with Spam Hater - see http://www.compulink.co.uk/~net-services/spam/ ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-22 0:00 ` Robert Dewar 1998-01-22 0:00 ` Anonymous 1998-01-23 0:00 ` Anonymous @ 1998-01-24 0:00 ` Tucker Taft 2 siblings, 0 replies; 40+ messages in thread From: Tucker Taft @ 1998-01-24 0:00 UTC (permalink / raw) Robert Dewar (dewar@merv.cs.nyu.edu) wrote: : ... : But I really would like some more input on this (surely we still have : *some* Ada folks around the newsgroup, and not just cross-posting : trollers :-) : It is really useful to have lots of input on error message things, since : they are so subjective. For what it is worth, this is what our AdaMagic front end produces for an illegal <binary op> <unary op> sequence: Source file: unary_plus.ada.bad Sat Jan 24 11:05:19 1998 1 procedure unary_plus is 2 x : Integer; 3 begin 4 x := x - + x; * *****Error: LRM:4.5(8) Badly formed expression; possibly missing '(', skipping ***** to next separator 5 end; -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-10 0:00 ` Robert Dewar 1998-01-10 0:00 ` Matthew Heaney @ 1998-01-11 0:00 ` Chris Morgan 1998-01-11 0:00 ` Robert Dewar 1 sibling, 1 reply; 40+ messages in thread From: Chris Morgan @ 1998-01-11 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: > > Terry asks > > <<Does anyone know who's idea it was to rename the > Interfaces.Java.Ada_To_Java_String function to the "+" > operator in the Intermetrics Java bindings? I'm > using the Aonix ObjectAda translator but assume that > the Java class library came from Intermetrics. > >> > > This is an old, old idea (the use of unary + as a reasonably un-noisy > conversion operator). Jean Ichbiah was always a fan of this idea, which > I think was firmly in mind at the time of the original Ada design. > In the Intermetrics X11 and Motif bindings there is a generic & operator which is used to approximate the variable argument list C functions in the original interface, allowing you to write stuff like this : Button1 := Xt.Intrinsic.XtVaCreateManagedWidget( "redraw", Motif.Pushb.xmPushButtonWidgetClass_obj, Form , Stdarg.Empty & Motif.xmstrdefs.XmNlabelString & label & Motif.Xmstrdefs.Xmntopattachment & Motif.Xm.Xmattach_Form & Motif.Xmstrdefs.Xmntopoffset & 2 & Motif.Xmstrdefs.Xmnleftattachment & Motif.Xm.Xmattach_Form & Motif.Xmstrdefs.Xmnleftoffset & 2 & Nulst); Whilst I'm not complaining this is elegant it reads close enough to the C that it's reasonably comprehensible to experience C/Motif programmers. Once I got the hang of it was fine. I thought Mitch did a good job with this. Chris -- Chris Morgan <mihalis at ix.netcom.com> "I'm considering throwing myself out of the window. It wouldn't do me much damage because we're on the ground floor, but it might make for a bit of variety." - Lizzy Bryant ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-11 0:00 ` Chris Morgan @ 1998-01-11 0:00 ` Robert Dewar 1998-01-11 0:00 ` Chris Morgan 0 siblings, 1 reply; 40+ messages in thread From: Robert Dewar @ 1998-01-11 0:00 UTC (permalink / raw) Chris said <<In the Intermetrics X11 and Motif bindings there is a generic & operator which is used to approximate the variable argument list C functions in the original interface, allowing you to write stuff like this : >> The other way of handling variable length lists is to use an aggregate subprogname ((arg1, arg2, arg3, arg4, ....)); that is definitely neater than &. Furthermore, if you use the & approach you have to be very careful not to introduce quadratic processing (which is often quite tricky to do, if the target is really an array (*)) If you need heterogenous typing, then you define an appropriate union type, and convert to it: subprogname ((+arg1, +arg2, +arg3, +arg4, ....)) which still retains linear processing time. If Chris' example is anywhere near realistic (where many operands were joined with &), then I think the use of & was probably not such a good choice as using aggregates. (*) the problem of aggregated operators, concatenation on strings is a canonical example, is an interesting one. No language in common use tries to address the issue of converting A & B & C & D ... into what is wanted, which is Concat ((A,B,C,D ...)) I can certainly imagine a pragma that would have this effect: pragma Collect_Operation (Operation => name, Subprogram => name); where the parameters designate the dyadic operator to be treated, which needs to have the profile (typ X typ => typ), and the corresponding subprogram, which needs to have the profile (row-of-typ => typ). To use this for the builtin concatenation (many compilers special case this, we just added this kind of special casing to GNAT), you also need to deal with rowing of elements, i.e. if the operand typ is itself row-of-component, then you allow components in the list with automatic rowing operations. P.S. the above uses ALgol-68 notation and terminology, which is highly convenient in a case like this: row-of-x is a type that is a single dimension array whose component type is x rowing is the coercion that takes type x to type row-of-x ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-11 0:00 ` Robert Dewar @ 1998-01-11 0:00 ` Chris Morgan 1998-01-11 0:00 ` Robert Dewar 0 siblings, 1 reply; 40+ messages in thread From: Chris Morgan @ 1998-01-11 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: > which still retains linear processing time. If Chris' example is anywhere > near realistic (where many operands were joined with &), then I think the > use of & was probably not such a good choice as using aggregates. > Your concern being compilation time and efficiency whereas I was thinking of my ability to transfer my C/Motif skills over to the Ada lobe of my brain :-) Certainly my example was from real code, but as it was my code I can't say if it was realistic for others. Was there a review of the bindings or where they just commisioned and produced? One interesting feature of them is that almost none of the examples of X and Motif programming given in the literature work with a simple translation of C to Ada since the type safety of Ada is so much stronger (the C examples relying on unportable assumptions and silent coercions). Chris -- Chris Morgan <mihalis at ix.netcom.com> "I'm considering throwing myself out of the window. It wouldn't do me much damage because we're on the ground floor, but it might make for a bit of variety." - Lizzy Bryant ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-11 0:00 ` Chris Morgan @ 1998-01-11 0:00 ` Robert Dewar 1998-01-11 0:00 ` Chris Morgan 0 siblings, 1 reply; 40+ messages in thread From: Robert Dewar @ 1998-01-11 0:00 UTC (permalink / raw) Chris said <<Your concern being compilation time and efficiency whereas I was thinking of my ability to transfer my C/Motif skills over to the Ada lobe of my brain :-) >> That's a very legitimate concern and indeed is one of the major arguments in favor of thin bindings. However, it is still reasonable to worry about execution time efficiency! (I don't understand your comment about compilation time here, I don't see that as an issue at all). From my point of view (a,b,c,d,e,f,g) is as reasonable translation of a,b,c,d,e,f,g as a & b & c & d & e & f & g actually, I think it is MORE reasonable. Now of course we can have & take care of the conversions if they are needed automatically, in which case the fair comparison is with (+a,+c,+c,+d,+e,+f,+g) but still that's fairly reasonable, and I don't think any of these conventions will intefere with inter-lobel transfer of knowledge. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-11 0:00 ` Robert Dewar @ 1998-01-11 0:00 ` Chris Morgan 1998-01-11 0:00 ` Robert Dewar 0 siblings, 1 reply; 40+ messages in thread From: Chris Morgan @ 1998-01-11 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: > That's a very legitimate concern and indeed is one of the major arguments > in favor of thin bindings. However, it is still reasonable to worry > about execution time efficiency! (I don't understand your comment about > compilation time here, I don't see that as an issue at all). For some reason your mention of quadratic time made me think of parsing the line of code I gave (no idea what order parsing actually would be) but I did mention efficiency as well by which I meant the run-time behaviour - I am aware for instance that text_io.put(a & b & c .... ); used to be very unpleasantly slow with at least one Ada83 compiler. > > From my point of view > > (a,b,c,d,e,f,g) > > is as reasonable translation of > > a,b,c,d,e,f,g > > as > > a & b & c & d & e & f & g > > actually, I think it is MORE reasonable. Now of course we can have & take > care of the conversions if they are needed automatically, in which case > the fair comparison is with > > (+a,+c,+c,+d,+e,+f,+g) > > but still that's fairly reasonable, and I don't think any of these > conventions will intefere with inter-lobel transfer of knowledge. I think all those would be fine. I was just saying it was nice that someone had offered something to allow an approximation of the varargs C functions rather than the previous approach of saying "sorry, Ada doesn't do varargs so you will have to use the non-varargs versions instead" which wouldn't have fitted in with my accustomed style of Motif programming. Chris -- Chris Morgan <mihalis at ix.netcom.com> "I'm considering throwing myself out of the window. It wouldn't do me much damage because we're on the ground floor, but it might make for a bit of variety." - Lizzy Bryant ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-11 0:00 ` Chris Morgan @ 1998-01-11 0:00 ` Robert Dewar 0 siblings, 0 replies; 40+ messages in thread From: Robert Dewar @ 1998-01-11 0:00 UTC (permalink / raw) Chris said <<I think all those would be fine. I was just saying it was nice that someone had offered something to allow an approximation of the varargs C functions rather than the previous approach of saying "sorry, Ada doesn't do varargs so you will have to use the non-varargs versions instead" which wouldn't have fitted in with my accustomed style of Motif programming. >> Well I am surprised that anyone would have taken this "previous" approach. Certainly the possibility of using array aggregates in this way is the reason that you don't need varargs type support in a language like Ada (this is not a new idea, this usage is completely familiar from Algol-68). So this is not some kind of "neat discovered trick" in the language, it is an important part of the intended design! Regarding the quadratic behavior, and your mention of efficiency in Ada 83, in fact if you think about a & b & c & d the natural implementation will definitely be quadratic, since this really means ((a & b) & c) & d) and in the general case, e.g. with user defined concatenation, must be done in three separate operations. A compiler can specially recognize this case, but it is not a trivial optimization (I just put it into GNAT, and it took a full day of work to get it right). ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-11 0:00 renaming Interfaces.Java.Ada_To_Java_String to the + operator Terry J. Westley 1998-01-10 0:00 ` Robert Dewar @ 1998-01-11 0:00 ` Nick Roberts 1998-01-11 0:00 ` Robert Dewar 1998-01-11 0:00 ` Brian Rogoff 1998-01-12 0:00 ` Tucker Taft 2 siblings, 2 replies; 40+ messages in thread From: Nick Roberts @ 1998-01-11 0:00 UTC (permalink / raw) I dislike this usage, in commercial programming situations, usually. The reason is well known: that it can often be confusing (or, at least, less obvious) for programmers new to the library environment or project. I think it's fair to say, also, that this sort of notation can be so 'quiet' as to be overlooked, and thus a source of mistakes (which would have been avoided with a 'louder' notation). Given that the only reason (tell me if I'm wrong) is to abbreviate an identifier, essentially, I feel it is rarely justifiable. If the programmer feels that an identifier is too long ("Ada_To_Java_String" perhaps), it can always be renamed (or subtyped or whatever) to a shorter, but still meaningful, identifier ("A2Jstr" possibly). One of the real practical strengths of Ada is its lack of obscure notation. I'm a real fan (as you can tell :-) of this clarity. -- Nick Roberts Croydon, UK Proprietor, ThoughtWing Software; Independent Software Development Consultant * Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 * *** Eats three shredded spams every morning for breakfast *** Terry J. Westley <westley@calspan.com> wrote in article <01bd1e34$1632c2c0$24326489@Westley-PC.calspan.com>... > Does anyone know who's idea it was to rename the > Interfaces.Java.Ada_To_Java_String function to the "+" > operator in the Intermetrics Java bindings? I'm > using the Aonix ObjectAda translator but assume that > the Java class library came from Intermetrics. > > Thanks much for this clever little idea. IMHO, it > really improves ease of use and code readability. > > Does this idea originate with the Java work at > Intermetrics or does it predate it? > > I find the inverse of + useful as well: > > function "-" (s : String_Ptr) return String > renames Interfaces.Java.Java_To_Ada_String; > > Does anyone think this is a misuse of operator > overloading? > > -- > Terry J. Westley, Principal Engineer > Calspan SRL Corp, P.O. Box 400, Buffalo, NY 14225 > westley@calspan.com http://www.calspan.com/ ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-11 0:00 ` Nick Roberts @ 1998-01-11 0:00 ` Robert Dewar 1998-01-14 0:00 ` Anonymous 1998-01-11 0:00 ` Brian Rogoff 1 sibling, 1 reply; 40+ messages in thread From: Robert Dewar @ 1998-01-11 0:00 UTC (permalink / raw) Nick says <<I dislike this usage, in commercial programming situations, usually. The reason is well known: that it can often be confusing (or, at least, less obvious) for programmers new to the library environment or project. I think it's fair to say, also, that this sort of notation can be so 'quiet' as to be overlooked, and thus a source of mistakes (which would have been avoided with a 'louder' notation). Given that the only reason (tell me if I'm wrong) is to abbreviate an identifier, essentially, I feel it is rarely justifiable. If the programmer feels that an identifier is too long ("Ada_To_Java_String" perhaps), it can always be renamed (or subtyped or whatever) to a shorter, but still meaningful, identifier ("A2Jstr" possibly). >> Everyone agrees with this general principle, but the fact of the matter is that identifiers with associated parentheses can obfuscate code, and at some level most people agree. Witness for example, the big fuss about adding "use type", which is basically so that even people who are use- allergic can still use nice infix notation for operators, as in x * b + c instead of Pkg1."+" (Pkg1."*" (x, b), c) hands up anyone who thinks the second line will prove clearer to the maintenance programmers :-) In fact many languages are happy to have *ZERO* syntactic overhead for conversions (e.g. C++). I think the use of unary "+" for this purpose is a quite reasonable compromise. Note that of course it should only be used when conceptually there is very little abstract difference between the input and output, as for example the case of a character treated as a one character string, or an integer treated as a real. If we are talking about two string types, then this is definitely a case where there is little or no abstract difference, and I would far rather see: User_Name := +"Robert Dewar"; than User_Name := A2Jstr ("Robert Dewar"); the extra characters in the latter line add no enlightenment to the reader of significance. (and personally I find this habit of making local abbreviations very annoying, since all too often these abbreviations are totally uncontrolled, and different programmers choose different abbreviations in different places, UGH! For my taste, if an abbreviation is clear, then use it universally, and name this package by its abbreviated name in the first place. I understand and appreciate the position that abbreviations should be avoided. I understand and appreciate the position (and it is my own position) that abbreviations are often quite reasonable. I find the use of global lengthy names and local abbreviations a horrible compromise that gets the worst of both worlds. Yes, I know it is a very standard convention, and indeed no rule is absolute for me, so occaisionally it makes sense (have a look at the GNAT runtime specs to get a feel for when I feel it is OK), but I find many programs very much overuse this technique. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-11 0:00 ` Robert Dewar @ 1998-01-14 0:00 ` Anonymous 1998-01-14 0:00 ` Robert Dewar 0 siblings, 1 reply; 40+ messages in thread From: Anonymous @ 1998-01-14 0:00 UTC (permalink / raw) <01bd1e34$1632c2c0$24326489@Westley-PC.calspan.com> <01bd1ebc$3bb2cb20$20f382c1@xhv46.dial.pipex.com> Robert Dewar presents some good reasons to use "+" for conversion operators, and my experience with large systems presents some good reasons not to. I'm still undecided, and welcome further arguments from either side (or the middle). What I would like to see is the ability to use the type name for conversion operations. I realize I did not submit a revision request for this, so I have only myself to blame. Then user-defined conversions would be the same as predefined conversions: I : Integer := Get; F : Float := Float (I); -- Predefined conversion uses type name type George is ...; type Martha is ...; function George (Value : Martha) return George; M : Martha := Get; G : George := George (Martha); Jeff Carter PGP:1024/440FBE21 My real e-mail address: ( carter @ innocon . com ) "I blow my nose on you." Monty Python & the Holy Grail Posted with Spam Hater - see http://www.compulink.co.uk/~net-services/spam/ ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-14 0:00 ` Anonymous @ 1998-01-14 0:00 ` Robert Dewar 0 siblings, 0 replies; 40+ messages in thread From: Robert Dewar @ 1998-01-14 0:00 UTC (permalink / raw) <<Robert Dewar presents some good reasons to use "+" for conversion operators, and my experience with large systems presents some good reasons not to. I'm still undecided, and welcome further arguments from either side (or the middle). >> Don't misread what I said, I never said that "+" *should* be used, or that it should *not* be. Why do people always look for simple minded rules (don't answer I know the answer :-) The proper rule is use "+" when it is a good idea to use "+", and don't use it when it does not help readability. Sorry, I can't tell you objectively how to make this decision! As for using the type name, well yes, you could add this, but to me I find it quite reasonable to do type Node is ... function To_Node (X : blabla) return Node ... Seems to read fine to me! ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-11 0:00 ` Nick Roberts 1998-01-11 0:00 ` Robert Dewar @ 1998-01-11 0:00 ` Brian Rogoff 1998-01-13 0:00 ` Terry J. Westley 1 sibling, 1 reply; 40+ messages in thread From: Brian Rogoff @ 1998-01-11 0:00 UTC (permalink / raw) On 11 Jan 1998, Nick Roberts wrote: > I dislike this usage, in commercial programming situations, usually. The > reason is well known: that it can often be confusing (or, at least, less > obvious) for programmers new to the library environment or project. I think > it's fair to say, also, that this sort of notation can be so 'quiet' as to > be overlooked, and thus a source of mistakes (which would have been avoided > with a 'louder' notation). Would your discomfort be less if Ada allowed user defined unary and infix operators, so that some new notation could be invented? Or is it the use of *any* unary operator rather than a named conversion function distasteful? Personally, I rather like the "+" as a converter notation; I saw it early in my Ada education and thought it was a fairly standard idiom. As was pointed out elsewhere it can be used bidirectionally because of Ada's overloading. > Given that the only reason (tell me if I'm wrong) is to abbreviate an > identifier, essentially, I feel it is rarely justifiable. Why? I thought the goal was readability. Sometimes compact code is more readable. > One of the real practical strengths of Ada is its lack of obscure notation. > I'm a real fan (as you can tell :-) of this clarity. Well, when I was doing a lot of numerical linear algebra and signal processing work, I really wished that I could invent my own unary and infix operators rather than being forced to use function call syntax for everything. While I'm sure that someone could use that to write really ugly code, there are situations where that notation (obscure to an outsider) could have made code much nicer. -- Brian ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-11 0:00 ` Brian Rogoff @ 1998-01-13 0:00 ` Terry J. Westley 1998-01-14 0:00 ` Robert Dewar 0 siblings, 1 reply; 40+ messages in thread From: Terry J. Westley @ 1998-01-13 0:00 UTC (permalink / raw) Brian Rogoff <bpr@shell5.ba.best.com> wrote in article > Well, when I was doing a lot of numerical linear algebra and signal > processing work, I really wished that I could invent my own unary and > infix operators rather than being forced to use function call syntax > for everything. While I'm sure that someone could use that to write really > ugly code, there are situations where that notation (obscure to an > outsider) could have made code much nicer. This is precisely the sort of thing: A = B + C which made FORTRAN so popular. The programmer couldn't invent his/her own operators of course, but it was a big improvement over: LD B ADD C STO A for readability. In the same way, use of the + operator can make a program more readable, not less. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-13 0:00 ` Terry J. Westley @ 1998-01-14 0:00 ` Robert Dewar 1998-01-15 0:00 ` Nick Roberts 0 siblings, 1 reply; 40+ messages in thread From: Robert Dewar @ 1998-01-14 0:00 UTC (permalink / raw) Terry says <<for readability. In the same way, use of the + operator can make a program more readable, not less. >> Absolutely! And the same can be said of absolutely all features in the language use of xxx can make a program more readable, not less But on the other hand it is also true that use of xxx can make a program less readable, not more And both statements are true for all xxx. I know people desparately want simple rules that somehow guarantee readability, but the fact of the matter is that judgment is called for in most cases, and having the skill to make the judgment correctly is one of the important skills that programmers need to have or acquire. Yes, sets of official guidelines and rules can help, but they are not a susbtitute for good judgment! ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-14 0:00 ` Robert Dewar @ 1998-01-15 0:00 ` Nick Roberts 1998-01-15 0:00 ` Robert Dewar 1998-01-16 0:00 ` Michael F Brenner 0 siblings, 2 replies; 40+ messages in thread From: Nick Roberts @ 1998-01-15 0:00 UTC (permalink / raw) Robert's comment [below] is surely a valuable one in a topic which threatened to get too general. I have to say, however, I would still assert that something like File_Name_1_In_Java := To_Java_String(File_Name_1); is better than File_Name_1_In_Java := +File_Name_1; in the vast majority of cases. I hope this example is not felt to be unfair by those who disagree with me. My point is this: what is truly gained by the second version? Unary + as a string translator is not a generally idiomatic form, although I admit it could become one, and its use is far from obscure already. I still think that the first form should be encouraged in commercial and industrial practice, simply because it is more explicit. In how many cases is the fact that it is a little longer going to really matter? Even with a case such as File_Name_List := (To_Java_String(Comment_File_Name), To_Java_String(Keyword_File_Name), To_Java_String(Command_File_Name), To_Java_String(Function_File_Name), To_Java_String(Movename_File_Name), To_Java_String(Oldname_File_Name), To_Java_String(Dictionary_List_File_Name), To_Java_String(Thesaurus_List_File_Name), To_Java_String(Grammar_Rule_File_Name)); could this be considered so much less preferable to, say File_Name_List := (+Comment_File_Name, +Keyword_File_Name, +Command_File_Name, +Function_File_Name, +Movename_File_Name, +Oldname_File_Name, +Dictionary_List_File_Name, +Thesaurus_List_File_Name, +Grammar_Rule_File_Name); where, again, I hope this example is felt to be fair. I would suggest that the latter form, while a little 'cleaner', could still be confusing to a reader who didn't already know that unary + had been defined to convert strings, whereas such a reader would be likely to correctly surmise what is going on from the first form. I would assert that this advantage tells over the advantage of slightly cleaner or shorter code in almost all cases. Am I missing the point? -- Nick Roberts Croydon, UK Proprietor, ThoughtWing Software; Independent Software Development Consultant * Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 * *** Eats three shredded spams every morning for breakfast *** Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article <dewar.884801478@merv>... > I know people desparately want simple rules that somehow guarantee readability, > but the fact of the matter is that judgment is called for in most cases, and > having the skill to make the judgment correctly is one of the important > skills that programmers need to have or acquire. > > Yes, sets of official guidelines and rules can help, but they are not a > susbtitute for good judgment! ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-15 0:00 ` Nick Roberts @ 1998-01-15 0:00 ` Robert Dewar 1998-01-16 0:00 ` Michael F Brenner 1 sibling, 0 replies; 40+ messages in thread From: Robert Dewar @ 1998-01-15 0:00 UTC (permalink / raw) Nick says <<I have to say, however, I would still assert that something like File_Name_1_In_Java := To_Java_String(File_Name_1); is better than File_Name_1_In_Java := +File_Name_1; in the vast majority of cases. I hope this example is not felt to be unfair by those who disagree with me. My point is this: what is truly gained by the second version? >> Well anyone can assert anything! The point is that we cannot tell from your example which is clearer. The issue is whether it is important at the appropriate level of abstraction to emphasize that there are two types involved here. If yes, then the top line is preferable, if no, then the bottom line is preferable, since the "To_Java_String" is irrelevant noise. Note that when you say A := B; you are quite happy with this even though A and B have different subtypes. Now if in fact A is of subtype Integer range 1 .. 10 and B is of subtype Integer, and a major function of the assignment statement is the range check, then it would not come amiss to say A := Restricted_Integer_Range_Type (B); but normally this is NOT a major semantic component of what is going on (even though the check might be there), and we are very happy to not be forced to write the type name for this kind of subtype conversion check. Now in the case where two separate types are involved, the conversion between them may or may not be significant. I can easily imagine a situation where you are using two packages, each of which instantiates a copy of bounded string for 100 character strings. You are stuck with these two types because that's the way the packages came, but as far as you are concerned it would have been better if they had been the same type, and the type conversions are entirely artifacts and have zero semantic significance. In such a case the + is appropriate (and in fact a bit too noisy, since implicit conversion would be fine in this case, but + is not too bad as an approximation of nothing :-) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-15 0:00 ` Nick Roberts 1998-01-15 0:00 ` Robert Dewar @ 1998-01-16 0:00 ` Michael F Brenner 1998-01-16 0:00 ` Robert Dewar 1998-01-16 0:00 ` Nick Roberts 1 sibling, 2 replies; 40+ messages in thread From: Michael F Brenner @ 1998-01-16 0:00 UTC (permalink / raw) (discussing using a prefix + operator to change types) > .. in what cases will the extra length really matter .. Using a function call (say, about 10 characters long) versus using a single character (+) to represent the type change is more readable on a single instance of the conversion. The place where the extra length really matters is when you have a lot of input to do, say 10000 lines, then you are saving 100000 key strokes, which could be a lot of data input money. This almost suggests a compromise that unary operators should have a corresponding function name. Use the function name for small numbers (say 10 or fewer) instances. Use the prefix operator when doing large amounts of stuff, like defining large finite state machines, filling in giant arrays, making test cases, defining test scenarios for a package body, etc. Mike Brenner ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-16 0:00 ` Michael F Brenner @ 1998-01-16 0:00 ` Robert Dewar 1998-01-16 0:00 ` Nick Roberts 1 sibling, 0 replies; 40+ messages in thread From: Robert Dewar @ 1998-01-16 0:00 UTC (permalink / raw) Mike says <<The place where the extra length really matters is when you have a lot of input to do, say 10000 lines, then you are saving 100000 key strokes, which could be a lot of data input money. This almost suggests a compromise that unary operators should have a corresponding function name. Use the function name for small numbers (say 10 or fewer) instances. Use the prefix operator when doing large amounts of stuff, like defining large finite state machines, filling in giant arrays, making test cases, defining test scenarios for a package body, etc. >> I strongly disagree with the above. Which of the two forms is preferable is a matter of semantic levels of discourse, and if one form is clearer if used once it is clearer if used 1000 times. The idea that one should take into account the effort of the writer is entirely wrong-headed. In the Ada world, we always favor the reader over the writer. So arguments should always be framed in terms of what will be easier to read. If you indeed think that in the case of a single instance, the long name is always clearer, then I cannot see how this does not apply to the multiple occurrence case. Of course I do not agree with this premise, for reasons I have explained in detail previously. P.S. I will tell you an amazing technique for saving those 100000 key strokes. Type them in using +, and then use the amazing global replace technology found in all editors for the last 30 years, and replace the plus signs with what ever long name you want (well you will have to fiddle with parens too, but this is also easy enough to automate :-) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-16 0:00 ` Michael F Brenner 1998-01-16 0:00 ` Robert Dewar @ 1998-01-16 0:00 ` Nick Roberts 1998-01-16 0:00 ` Robert Dewar 1 sibling, 1 reply; 40+ messages in thread From: Nick Roberts @ 1998-01-16 0:00 UTC (permalink / raw) Precisely right, Mikey babe, You've more or less listed precisely those rare cases that I was banging on about. I know, I know, I know, you yourself use lots and lots of FSTs; but I would suggest, in the great scheme of things, that large FSTs, giant arrays, etc. constitute rare cases. (No? :-) To use this spot to answer Robert Dewar also (ever conscious of bandwidth, signal to noise ratios etc.), Robert argues that the use of explicit conversions or not depends on the level of abstraction, which I wholeheartedly agree with. He then says that in cases where the level of abstraction does not suit an explicit conversion, use of the unary + operator approximates to an implicit conversion (which Ada does not support generally). Well, true, it's nearer than a great long identifier and brackets; but it's still not an implicit conversion, and it's appearance will (probably) worry a programmer who doesn't already know what it means, whereas the explicit identifier (probably) won't. What I'm saying is that it is actually slightly more pragmatic to use the explicit identifier, except in those (rare!) cases such as large FSTs, giant arrays, etc. where reducing bulk would actually matter (and, indeed, improve readability). -- Nick Roberts Croydon, UK Proprietor, ThoughtWing Software; Independent Software Development Consultant * Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 * *** Eats three shredded spams every morning for breakfast *** Michael F Brenner <mfb@mbunix.mitre.org> wrote in article <69ntk6$qj8@top.mitre.org>... > Using a function call (say, about 10 characters long) versus > using a single character (+) to represent the type change > is more readable on a single instance of the conversion. > > The place where the extra length really matters is when you > have a lot of input to do, say 10000 lines, then you are saving > 100000 key strokes, which could be a lot of data input money. > > This almost suggests a compromise that unary operators should > have a corresponding function name. Use the function name > for small numbers (say 10 or fewer) instances. > > Use the prefix operator when doing large amounts of stuff, like > defining large finite state machines, filling in giant arrays, > making test cases, defining test scenarios for a package body, etc. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-16 0:00 ` Nick Roberts @ 1998-01-16 0:00 ` Robert Dewar 1998-01-17 0:00 ` miniscences Nick Roberts 1998-01-19 0:00 ` renaming Interfaces.Java.Ada_To_Java_String to the + operator Anonymous 0 siblings, 2 replies; 40+ messages in thread From: Robert Dewar @ 1998-01-16 0:00 UTC (permalink / raw) Nick Roberts says <<To use this spot to answer Robert Dewar also (ever conscious of bandwidth, signal to noise ratios etc.), Robert argues that the use of explicit conversions or not depends on the level of abstraction, which I wholeheartedly agree with. He then says that in cases where the level of abstraction does not suit an explicit conversion, use of the unary + operator approximates to an implicit conversion (which Ada does not support generally). Well, true, it's nearer than a great long identifier and brackets; but it's still not an implicit conversion, and it's appearance will (probably) worry a programmer who doesn't already know what it means, whereas the explicit identifier (probably) won't. >> Indeed the use of the "+" notation assumes that programmers are familiar with this idiom. It is an old one which was well understood at the time of the original design, and I would have thought it was pretty universally known. Certainly it is something that all Ada programmers should be familiar with. Even if you don't like to use it yourself, you are highly likely to run into code that does use this convention. I certainly agree that the use of idioms like this is often quite dependent on familiarity. Of course in this particular case, it seems to me that a programmer who was unfamiliar with this notation would quickly find out what was going on. You encounter the operator +, and in the normal manner, seek out its definition (using whatever special tools ytou have to help with this). Then the spec of this "+" will of course have comments explaining the use. Anyway, it is clear that one benefit of this thread is that at least the current readers of CLA are now familiar with this very standard idiom, whether or not they choose to use it themselves :-) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: miniscences 1998-01-16 0:00 ` Robert Dewar @ 1998-01-17 0:00 ` Nick Roberts 1998-01-17 0:00 ` miniscences Robert Dewar 1998-01-19 0:00 ` renaming Interfaces.Java.Ada_To_Java_String to the + operator Anonymous 1 sibling, 1 reply; 40+ messages in thread From: Nick Roberts @ 1998-01-17 0:00 UTC (permalink / raw) I do a lot of training of Ada programmers (no more jokes about the blind leading the blind, please :-}. I shall have to add this one to the list (it gets longer and longer :-| You say this is an old idiom: how old? [Uncle Nicky nearly goes back to when the only things programmed were programmed with pins in boards] I remember the days when it wowed us when we could put MID$ on the left. And when Crystal (remember them?) had got their BASIC into a 6K ROM. [Here we go...] I remember the days [pillow hits head] who threw that? Oooh yes, I was once the proud owner of the original Sinclair computer (can't even remember what it was called now). You know, the one with 1K of RAM, of which three-quarters was needed for displaying a screenful of info? Ah, those were the days. None your unary operators then. Those days it was lone operators. Ever tried getting a real BASIC program into 300-400 bytes? Ah yes, you had to be a _man_ to program those days. Ah, yes [another pillow] who threw that? [Etc...] -- Nick Roberts Croydon, UK Proprietor, ThoughtWing Software; Independent Software Development Consultant * Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 * *** Eats three shredded spams every morning for breakfast *** Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article <dewar.884996680@merv>... > Indeed the use of the "+" notation assumes that programmers are familiar > with this idiom. It is an old one which was well understood at the time of > the original design, and I would have thought it was pretty universally > known. Certainly it is something that all Ada programmers should be familiar > with. Even if you don't like to use it yourself, you are highly likely to > run into code that does use this convention. > > I certainly agree that the use of idioms like this is often quite dependent > on familiarity. > > Of course in this particular case, it seems to me that a programmer > who was unfamiliar with this notation would quickly find out what was > going on. You encounter the operator +, and in the normal manner, seek > out its definition (using whatever special tools ytou have to help with > this). Then the spec of this "+" will of course have comments explaining > the use. > > Anyway, it is clear that one benefit of this thread is that at least the > current readers of CLA are now familiar with this very standard idiom, > whether or not they choose to use it themselves :-) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: miniscences 1998-01-17 0:00 ` miniscences Nick Roberts @ 1998-01-17 0:00 ` Robert Dewar 0 siblings, 0 replies; 40+ messages in thread From: Robert Dewar @ 1998-01-17 0:00 UTC (permalink / raw) Nick asks <<I do a lot of training of Ada programmers (no more jokes about the blind leading the blind, please :-}. I shall have to add this one to the list (it gets longer and longer :-| You say this is an old idiom: how old? >> As old as the Ada design. During the Green design effort (i.e. late 70's), the issue of whether to have implicit conversions was discussed, and at that time Jean felt, and others generally agreed, that the use of the "+" operator in this way meant that you have the possibility of making the conversion pretty close to silent from a reading point of view, and that therefore it was not necessary to introduce implicit convresions. After all, look at the number of people who find even the + too silent, and would prefer to see a full identifier here. Imagine the situation in a langyuage like C++ with implicit conversions where you can have a lot going on behind the scenes with no syntactic hint at all. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-16 0:00 ` Robert Dewar 1998-01-17 0:00 ` miniscences Nick Roberts @ 1998-01-19 0:00 ` Anonymous 1998-01-25 0:00 ` Matthew Heaney 1 sibling, 1 reply; 40+ messages in thread From: Anonymous @ 1998-01-19 0:00 UTC (permalink / raw) <01bd1e34$1632c2c0$24326489@Westley-PC.calspan.com> <01bd1fc9$99302a00$24326489@Westley-PC.calspan.com> <dewar.884801478@merv> <01bd21ff$7f85e3a0$95fc82c1@xhv46.dial.pipex.com> <69ntk6$qj8@top.mitre.org> <01bd22bd$0b69fa60$5cfd82c1@xhv46.dial.pipex.com> On 16 Jan 1998 19:29:43 -0500, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > ... > > Indeed the use of the "+" notation assumes that programmers are familiar > with this idiom. It is an old one which was well understood at the time of > the original design, and I would have thought it was pretty universally > known. Certainly it is something that all Ada programmers should be familiar > with. Even if you don't like to use it yourself, you are highly likely to > run into code that does use this convention. > I've been developing software professionally since 1975, and using Ada since 1984, and I only recently encountered this "old idiom" by reading about it here. Perhaps it is familiar only to those involved in the language design and implementation. I know I never encountered it in 14 years of reading the ARM, Ada texts, and Ada-related articles. Jeff Carter PGP:1024/440FBE21 My real e-mail address: ( carter @ innocon . com ) "English bed-wetting types." Monty Python & the Holy Grail Posted with Spam Hater - see http://www.compulink.co.uk/~net-services/spam/ ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-19 0:00 ` renaming Interfaces.Java.Ada_To_Java_String to the + operator Anonymous @ 1998-01-25 0:00 ` Matthew Heaney 0 siblings, 0 replies; 40+ messages in thread From: Matthew Heaney @ 1998-01-25 0:00 UTC (permalink / raw) In article <199801191436.PAA25860@basement.replay.com>, nobody@REPLAY.COM (Anonymous) wrote: >I've been developing software professionally since 1975, and using Ada >since 1984, and I only recently encountered this "old idiom" by reading >about it here. Perhaps it is familiar only to those involved in the >language design and implementation. I know I never encountered it in 14 >years of reading the ARM, Ada texts, and Ada-related articles. This technique was discussed in John Barnes' book, Programming In Ada. He used it to construct a ragged array of strings. Actually, that turns out to be a popular use of the identity operator, to populate an array: declare Aardvark : aliased constant String := "aardvark"; ... Elephant : aliased constant String := "elephant"; ... Zebra : aliased constant String := "zebra"; type String_Access_Constant is access constant String; type String_Array is array (Positive range <>) of String_Access_Constant; Animals : constant String_Array := (Aardvark'Access, ... Elephant'Access, ... Zebra'Access); begin This is more or less the example in John's book. (His Ada 83 example put the strings on the heap, using the identity operator to hide to allocator invokation.) -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator 1998-01-11 0:00 renaming Interfaces.Java.Ada_To_Java_String to the + operator Terry J. Westley 1998-01-10 0:00 ` Robert Dewar 1998-01-11 0:00 ` Nick Roberts @ 1998-01-12 0:00 ` Tucker Taft 2 siblings, 0 replies; 40+ messages in thread From: Tucker Taft @ 1998-01-12 0:00 UTC (permalink / raw) Terry J. Westley (westley@calspan.com) wrote: : Does anyone know who's idea it was to rename the : Interfaces.Java.Ada_To_Java_String function to the "+" : operator in the Intermetrics Java bindings? I'm : using the Aonix ObjectAda translator but assume that : the Java class library came from Intermetrics. : Thanks much for this clever little idea. IMHO, it : really improves ease of use and code readability. : Does this idea originate with the Java work at : Intermetrics or does it predate it? This idea has been around for quite a while. : I find the inverse of + useful as well: : function "-" (s : String_Ptr) return String : renames Interfaces.Java.Java_To_Ada_String; : Does anyone think this is a misuse of operator : overloading? As with Robert Dewar, I prefer using "+" for such conversions, independent of direction. Overloading figures it out. I wouldn't want to see "+" used all over the place, but it certainly comes in handy for relatively "trivial" conversions that have to be used in many contexts. : -- : Terry J. Westley, Principal Engineer : Calspan SRL Corp, P.O. Box 400, Buffalo, NY 14225 : westley@calspan.com http://www.calspan.com/ -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~1998-01-25 0:00 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-01-11 0:00 renaming Interfaces.Java.Ada_To_Java_String to the + operator Terry J. Westley 1998-01-10 0:00 ` Robert Dewar 1998-01-10 0:00 ` Matthew Heaney 1998-01-13 0:00 ` Tom Moran 1998-01-13 0:00 ` Stephen Leake 1998-01-13 0:00 ` Nick Roberts 1998-01-13 0:00 ` Robert Dewar 1998-01-13 0:00 ` Stephen Leake [not found] ` <En3Cxz.7HD@world.std.com> 1998-01-20 0:00 ` Robert Dewar 1998-01-21 0:00 ` Stephen Leake 1998-01-22 0:00 ` Robert Dewar 1998-01-22 0:00 ` Anonymous [not found] ` <dewar.885498969@merv> 1998-01-23 0:00 ` Geert Bosch 1998-01-23 0:00 ` Tom Moran 1998-01-23 0:00 ` Anonymous 1998-01-24 0:00 ` Tucker Taft 1998-01-11 0:00 ` Chris Morgan 1998-01-11 0:00 ` Robert Dewar 1998-01-11 0:00 ` Chris Morgan 1998-01-11 0:00 ` Robert Dewar 1998-01-11 0:00 ` Chris Morgan 1998-01-11 0:00 ` Robert Dewar 1998-01-11 0:00 ` Nick Roberts 1998-01-11 0:00 ` Robert Dewar 1998-01-14 0:00 ` Anonymous 1998-01-14 0:00 ` Robert Dewar 1998-01-11 0:00 ` Brian Rogoff 1998-01-13 0:00 ` Terry J. Westley 1998-01-14 0:00 ` Robert Dewar 1998-01-15 0:00 ` Nick Roberts 1998-01-15 0:00 ` Robert Dewar 1998-01-16 0:00 ` Michael F Brenner 1998-01-16 0:00 ` Robert Dewar 1998-01-16 0:00 ` Nick Roberts 1998-01-16 0:00 ` Robert Dewar 1998-01-17 0:00 ` miniscences Nick Roberts 1998-01-17 0:00 ` miniscences Robert Dewar 1998-01-19 0:00 ` renaming Interfaces.Java.Ada_To_Java_String to the + operator Anonymous 1998-01-25 0:00 ` Matthew Heaney 1998-01-12 0:00 ` Tucker Taft
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox