* Help: Binary operator "=" @ 1997-05-20 0:00 Adrian B.Y. Hoe 1997-05-21 0:00 ` Robert Dewar 1997-05-21 0:00 ` Jeff Carter 0 siblings, 2 replies; 6+ messages in thread From: Adrian B.Y. Hoe @ 1997-05-20 0:00 UTC (permalink / raw) I have errors compiling the following code using ObjectAda 7.0.232 function InitInstance(Hinstance : Windef.HINSTANCE; ...) return Win32.BOOL is HWND : Windef.HWND; wu_Ps : aliased Winuser.PAINTSTRUCT; begin -- Create a main window for this application instance. HWND := WinUser.CreateWindow (LpClassName => SZAPPNAME, -- Line 452 LpWindowName => SZTITLE, DwStyle => WinUser.WS_OVERLAPPEDWINDOW or WinUser.WS_CLIPCHILDREN, X => WinUser.CW_USEDEFAULT, Y => WinUser.CW_USEDEFAULT, NWidth => WinUser.CW_USEDEFAULT, NHeight => WinUser.CW_USEDEFAULT, HWndParent => null, HMenu => null, HInstance => HInstance, LpParam => null); if HWND = Windef.HWND'(null) then -- Line 467 return Win32.FALSE; end if; ... end InitInstance; The compiler says: Line 467: Binary operator "=" not directly visible, use clause might be needed. Line 452: Parameter mismatch. Could someone enlighten me? Thank you in advance. -- B.Y. lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll Adrian, B.Y. Hoe byHoe@quantum.pc.my \/ Business Development, VP \/ \/ \/ \/ \/ Phone : +60 3 495 4048 \/ \/ Lexical Integration (M) Sdn Bhd Fax : +60 3 495 4037 \/ 13-B Jalan Pandan Indah 4/2, Pandan Indah, 55100 Kuala Lumpur-Malaysia lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll member of Team-Ada in Malaysia ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Help: Binary operator "=" 1997-05-20 0:00 Help: Binary operator "=" Adrian B.Y. Hoe @ 1997-05-21 0:00 ` Robert Dewar [not found] ` <33932325.6E38@lmtas.lmco.com> 1997-05-21 0:00 ` Jeff Carter 1 sibling, 1 reply; 6+ messages in thread From: Robert Dewar @ 1997-05-21 0:00 UTC (permalink / raw) Adrian says <<The compiler says: Line 467: Binary operator "=" not directly visible, use clause might be needed.>> The error message seems pretty clear. You are using the operator "=" without qualifying it, you need to write packagename."="(x,y) If you are allergic to all use clauses, then this is the only solution (well you can introduce a local renaming so that you only need to do the qualification once in the usual manner). For reasons that have never been clear to me, folks who absolutely insist on dotting stuff in general so that they know where it is don't want to write dots on ooperators. To help out these folks, the use type clause is introduced in Ada 95, which allows you to use the operators without using anything else. ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <33932325.6E38@lmtas.lmco.com>]
* Re: Help: Binary operator "=" [not found] ` <33932325.6E38@lmtas.lmco.com> @ 1997-06-07 0:00 ` Robert Dewar 1997-06-08 0:00 ` Ken Garlington 0 siblings, 1 reply; 6+ messages in thread From: Robert Dewar @ 1997-06-07 0:00 UTC (permalink / raw) Ken says <<Because infix operators don't read as nice when fully qualified, of course... Some_Stack_Type.Push(Value => A_Thing.Object, Onto => A_Stack.Object); -- nice if Some_Stack_Type.Is_Empty(A_Stack.Object) ... -- OK if Some_Stack_Type."="(A_Stack.Object, Another_Stack.Object) then ... -- not nearly as nice as if A_Stack.Object = Another_Stack.Object then ... Surely the increased readability is intuitively obvious! :) >> Oh most certainly it is to me, getting rid of the silly Some_Stack_Type prefix on "=" and deciding that you can use other means to figure out where "=" comes from makes excellent sense to me. The only trouble is, I would apply the same reasoning to the annoying Some_Stack_Type. prefix on the Is_Empty call. Indeed I don't see the difference between the two cases. Either it is a problem to have to find out where things are, necessitating the verbose prefixs, or it is not, and the situation seems the same in both cases to me :-) :-) (the smileys are because this is an old discussion, hardlly worth repeating unless someone has something new to say :-) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Help: Binary operator "=" 1997-06-07 0:00 ` Robert Dewar @ 1997-06-08 0:00 ` Ken Garlington 1997-06-10 0:00 ` Robert Dewar 0 siblings, 1 reply; 6+ messages in thread From: Ken Garlington @ 1997-06-08 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Ken says > > <<Because infix operators don't read as nice when fully qualified, of > course... > > Some_Stack_Type.Push(Value => A_Thing.Object, Onto => A_Stack.Object); > -- nice > > if Some_Stack_Type.Is_Empty(A_Stack.Object) ... -- OK > > if Some_Stack_Type."="(A_Stack.Object, Another_Stack.Object) then ... > -- not nearly as nice as > if A_Stack.Object = Another_Stack.Object then ... > > Surely the increased readability is intuitively obvious! :) > >> > > Oh most certainly it is to me, getting rid of the silly Some_Stack_Type > prefix on "=" and deciding that you can use other means to figure out > where "=" comes from makes excellent sense to me. > > The only trouble is, I would apply the same reasoning to the annoying > Some_Stack_Type. prefix on the Is_Empty call. Indeed I don't see the > difference between the two cases. Either it is a problem to have to > find out where things are, necessitating the verbose prefixs, or it is > not, and the situation seems the same in both cases to me :-) :-) Which is why I characterized it as "OK" vs. "nice" in my comments. The (admittedly thin) distinction you could draw is as follows: Infix operators should be extremely obvious as to their definition (at least if written correctly). This is why it's probably OK to use some terse notation like "+" rather than Add. Non-infix operators are slightly less obvious, so having some additional information (like the type of stack on which they operate) might be useful. It's not so much being able to trace the location of their definition as providing useful information about the operation. I would say that, in the second case, either leaving on the name or taking it off would probably be all right. The second case actually reads better if the stacks are created from a generic abstract data object, instead of from an abstract data type, but then other problems (like how to define "=") become a problem... > > (the smileys are because this is an old discussion, hardlly worth repeating > unless someone has something new to say :-) It's not particularly new, but I find the whole idea of Ada style interesting. For a language that promotes readability, I think style should be a central issue. If Ada were used more, I would eventually expect a certain standard style to appear over time (a la "Elements of Style" for English). -- LMTAS - The Fighter Enterprise - "Our Brand Means Quality" Who uses Ada? See http://www.lmasc.lmco.com/f22 For job listings, other info: http://www.lmtas.com or http://www.lmco.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Help: Binary operator "=" 1997-06-08 0:00 ` Ken Garlington @ 1997-06-10 0:00 ` Robert Dewar 0 siblings, 0 replies; 6+ messages in thread From: Robert Dewar @ 1997-06-10 0:00 UTC (permalink / raw) Ken says <<Which is why I characterized it as "OK" vs. "nice" in my comments. The (admittedly thin) distinction you could draw is as follows: Infix operators should be extremely obvious as to their definition (at least if written correctly). This is why it's probably OK to use some terse notation like "+" rather than Add. Non-infix operators are slightly less obvious, so having some additional information (like the type of stack on which they operate) might be useful. It's not so much being able to trace the location of their definition as providing useful information about the operation. I would say that, in the second case, either leaving on the name or taking it off would probably be all right.>> Which in fact leads to a different criterion entirely. Instead of having an absolute "never-use-use" rule, you are really suggesting a rule that says, use qualification when it is helpful, and not otherwise. That sounds like an entirely reasonable rule to me. For example, in the case of GNAT, we generally expect that those looking seriously at the GNAT compiler sources get to know where things are pretty quickly, since there is a rather systematic placement of functionality (for example, you know that Analyze_Subprogram_Body will be in Sem_Ch6, since analysis is to do with semantics, and subprogram bodies are in chapter 6 of the RM). On the other hand, the runtime library is hundreds of interlinked units, and it is definitely helpful to use qualification extensively in this context, particularly in the specs. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Help: Binary operator "=" 1997-05-20 0:00 Help: Binary operator "=" Adrian B.Y. Hoe 1997-05-21 0:00 ` Robert Dewar @ 1997-05-21 0:00 ` Jeff Carter 1 sibling, 0 replies; 6+ messages in thread From: Jeff Carter @ 1997-05-21 0:00 UTC (permalink / raw) Adrian B.Y. Hoe wrote: ... > The compiler says: Line 467: Binary operator "=" not directly visible, use > clause > might be needed. > > Line 452: Parameter mismatch. ... These seem straightforward: 467 says that function Windef."=" (Left, Right : Windef.HWND) return Boolean; is not visible. You need to use dot notation, rename it, or "use type Windef.HWND;". 452 says that SZAPPNAME, whatever it is, is not of the correct type for parameter LpClassName of Winuser.Createwindow. -- Jeff Carter PGP:1024/440FBE21 Auntie-spam reply-to; try ( carter @ innocon . com ) "Now go away, or I shall taunt you a second time." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1997-06-10 0:00 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-05-20 0:00 Help: Binary operator "=" Adrian B.Y. Hoe 1997-05-21 0:00 ` Robert Dewar [not found] ` <33932325.6E38@lmtas.lmco.com> 1997-06-07 0:00 ` Robert Dewar 1997-06-08 0:00 ` Ken Garlington 1997-06-10 0:00 ` Robert Dewar 1997-05-21 0:00 ` Jeff Carter
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox