Function name problem

Function name problem

[Harald Schmidt]

Hi,

I want to declare two function, but the 2nd is not
allowed by GNAT3.12. Could someone tell me why?
Here are the two declarations:

package bla is
    type Object is tagged limited private;
    function "=" (Left, Right: in Object�Class) return Boolean;
    function "==" (Left, Right: in Object�Class) return Boolean;
private
    type Object is tagged limited null record;
end bla;

Thanks for any info,

    Harald

Re: Function name problem

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 742 bytes --]


Harald Schmidt a �crit dans le message ...

>package bla is
>    type Object is tagged limited private;
>    function "=" (Left, Right: in Object�Class) return Boolean;
>    function "==" (Left, Right: in Object�Class) return Boolean;


In fact this is not right. "==" is not an Ada operator. In Ada you can
only give your own implementation for standard Ada operator.

Pascal.


--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://ourworld.compuserve.com/homepages/pascal_obry
--|
--| "The best way to travel is by means of imagination"

Re: Function name problem

[Jeff Carter]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

In article <B4A633AE.3FF3%Harald.Schmidt@tomcat.de>,
  Harald Schmidt <Harald.Schmidt@tomcat.de> wrote:
> Hi,
>
> I want to declare two function, but the 2nd is not
> allowed by GNAT3.12. Could someone tell me why?
> Here are the two declarations:
>
> package bla is
>     type Object is tagged limited private;
>     function "=" (Left, Right: in Object�Class) return Boolean;
>     function "==" (Left, Right: in Object�Class) return Boolean;
> private
>     type Object is tagged limited null record;
> end bla;

A function declaration with the function designator (name) in quotation
marks (such as "=") defines an operator. The set of operator symbols is
fixed in Ada. While you can define operators for your types, as you did
with "=", you cannot create new operator symbols, as you tried to do
with "==". See ARM 4.5, 6.1, and 6.6.

--
Jeff Carter
"Now go away or I shall taunt you a second time."
-- Monty Python and the Holy Grail


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Function name problem

[Harald Schmidt]

in article 85qecu$24r$1@nnrp1.deja.com, Jeff Carter at
jrcarter001@my-deja.com wrote on 15.01.2000 19:30:

> In article <B4A633AE.3FF3%Harald.Schmidt@tomcat.de>,
> Harald Schmidt <Harald.Schmidt@tomcat.de> wrote:
>> Hi,
>> 
>> I want to declare two function, but the 2nd is not
>> allowed by GNAT3.12. Could someone tell me why?
>> Here are the two declarations:
>> 
>> package bla is
>> type Object is tagged limited private;
>> function "=" (Left, Right: in Object�Class) return Boolean;
>> function "==" (Left, Right: in Object�Class) return Boolean;
>> private
>> type Object is tagged limited null record;
>> end bla;
> 
> A function declaration with the function designator (name) in quotation
> marks (such as "=") defines an operator. The set of operator symbols is
> fixed in Ada. While you can define operators for your types, as you did
> with "=", you cannot create new operator symbols, as you tried to do
> with "==". See ARM 4.5, 6.1, and 6.6.
> 
> --
> Jeff Carter
> "Now go away or I shall taunt you a second time."
> -- Monty Python and the Holy Grail
> 
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Thank you very much for this info. But can someone
explain why this restriction exists?

Harald

Re: Function name problem

[Matthew Heaney]

In article <B4A76C00.4583%Harald.Schmidt@tomcat.de> , Harald Schmidt 
<Harald.Schmidt@tomcat.de>  wrote:

> But can someone
> explain why this restriction exists?

The operator symbol "=" to mean equality has a long history, dating to
1577, when it was used by Robert Recorde:

"Today, Recorde's =, the only symbol he introduced, is universally
embraced.  Equality is one of our most important concepts, and it
deserves a unique symbol.  The use of = for assignment in Fortran has
only caused confusion, as has the use of = for assignment and == for
equality in C."

Quoted from p. 16 of
A Logical Approach to Discrete Math
Gries, Schneider


The use of the == operator in C to mean equality is a flaw in the design
of that language.

Not providing an "==" operator in Ada is a deliberate feature of the
language, and is therefore not a restriction at all.  Were it allowed,
"==" would only vitiate the language, just as it did in C.

--
Evolution is as well documented as any phenomenon in science, as
strongly as the earth's revolution around the sun rather than vice
versa.

Stephen Jay Gould, Time, 23 Aug 1999

Re: Function name problem

[Harald Schmidt]

in article 01qg4.3200$%Y3.193028@newsread2.prod.itd.earthlink.net, Matthew
Heaney at matthew_heaney@acm.org wrote on 16.01.2000 21:40:

> In article <B4A76C00.4583%Harald.Schmidt@tomcat.de> , Harald Schmidt
> <Harald.Schmidt@tomcat.de>  wrote:
> 
>> But can someone
>> explain why this restriction exists?
> 
> The operator symbol "=" to mean equality has a long history, dating to
> 1577, when it was used by Robert Recorde:
> 
> "Today, Recorde's =, the only symbol he introduced, is universally
> embraced.  Equality is one of our most important concepts, and it
> deserves a unique symbol.  The use of = for assignment in Fortran has
> only caused confusion, as has the use of = for assignment and == for
> equality in C."
> 
> Quoted from p. 16 of
> A Logical Approach to Discrete Math
> Gries, Schneider
> 
> 
> The use of the == operator in C to mean equality is a flaw in the design
> of that language.
> 
> Not providing an "==" operator in Ada is a deliberate feature of the
> language, and is therefore not a restriction at all.  Were it allowed,
> "==" would only vitiate the language, just as it did in C.
> 

...my intenstion was not to implement a functional operator
equivalent to C/C++. My primary business is Smalltalk, and
I was trying to implement the equal method "=", means
equality of any attribute of two given objects. The second
method "==" (basis for this discussion) is a identity
method comparing the identity of two given objects.

Harald

Re: Function name problem

[Gautier]

> ...my intenstion was not to implement a functional operator
> equivalent to C/C++. My primary business is Smalltalk, and
> I was trying to implement the equal method "=", means
> equality of any attribute of two given objects. The second
> method "==" (basis for this discussion) is a identity
> method comparing the identity of two given objects.

Anyway for exported software I'd prefer to use a more
explicit name to avoid any confusion (e.g. for comparing
2 polynomials, fractions or multi-precision integers) with the
`raw', built-in "=" ...

-- 
Gautier

_____\\________________\_______\
http://members.xoom.com/gdemont/

Re: Function name problem

[Matthew Heaney]

In article <B4A7F12A.45EC%Harald.Schmidt@tomcat.de> , Harald Schmidt 
<Harald.Schmidt@tomcat.de>  wrote:

> ...my intenstion was not to implement a functional operator
> equivalent to C/C++. My primary business is Smalltalk, and
> I was trying to implement the equal method "=", means
> equality of any attribute of two given objects. The second
> method "==" (basis for this discussion) is a identity
> method comparing the identity of two given objects.

OK.

Smalltalk has reference semantics.  To implement a by-reference type in
Ada(95), use access types.  "Comparing identity" in Ada95 means
comparing access objects.

package P is

  type T (<>) is abstract tagged limited null record;

  type TA is access all T'Class;

  function "=" (L, R : T) return Boolean is abstract;

  procedure Op (O : access T) is abstract;

end P;

package P.C is

  type NT is new T with private;

  function New_NT return TA;

  procedure Op (O : access NT);

  function "=" (L, R : NT) return Boolean;

private

  type NT is new T with record ...;

  ...

end P.C;


A client of a by-reference abstraction declares an access object, and
then calls the constructor for the type:

declare
  O1, O2 : TA := New_NT;
begin
  ...
  if O1.all = O2.all then   -- compare values

  if O1 = O2 then           -- compare identities


In neither case do you require an "==" operator.


--
"I do not feel obliged to believe that the same God who has endowed us
with sense, reason, and intellect has intended us to forgo their use."

Galileo Galilei

Re: Function name problem

[Florian Weimer]

"Matthew Heaney" <matthew_heaney@acm.org> writes:

> The operator symbol "=" to mean equality has a long history, dating to
> 1577, when it was used by Robert Recorde:

``And to auiode the tediouse repetition of these woordes: is equal to:
I will sette as I doe often in woorke use, a paire of parallelees, or
Gemowe lines of one lengthe, thus: =, bicause noe .2. thynges, can be
moare equalle.'' (Robert Recorde, The Whetstone of Witte.  London, 1557.)

(Cited by Knuth/Graham/Patashnik in `Concrete Mathematics' when they
give reason for overloading the `=' symbol as part of the O notatition.)

Re: Function name problem

[David Starner]

On Sun, 16 Jan 2000 12:37:21 +0100, Harald Schmidt <Harald.Schmidt@tomcat.de> wrote:
>in article 85qecu$24r$1@nnrp1.deja.com, Jeff Carter at
>jrcarter001@my-deja.com wrote on 15.01.2000 19:30:
>
>> A function declaration with the function designator (name) in quotation
>> marks (such as "=") defines an operator. The set of operator symbols is
>> fixed in Ada. While you can define operators for your types, as you did
>> with "=", you cannot create new operator symbols, as you tried to do
>> with "==". See ARM 4.5, 6.1, and 6.6.
>
>Thank you very much for this info. But can someone
>explain why this restriction exists?

Because it's a pain to implement, and it rarely improves readability.

(1) Where do you put the new operator? Any fixed place will be wrong
much of the time, and a flexible place will kill the parsing speed,
cause much pain for parser writers, and make the program hard to read.
f := a % b && c == d; could have almost any precedence, and since 
builtin precedence is already enough of a readibility problem . . .

(2) What do you gain from it? "==" is an example of why not to have it;
Writing C in Ada is a sure way to annoy and confuse anyone else reading
it. If I could use Unicode in writing programs, I can see a few places
where mathematical symbols would make nice operators, but still, 
a {dot symbol} b and a {cross symbol} b aren't superior enough to
Dot(a,b) and Cross (a, b) to make the precidence and readibility
problems worth it.

I will also note that POP-11(?) and ML allow this, but most other modern
languages found it too much trouble. (Java doens't allow operator overloading,
the Modula 3 people probably found it took too many pages in the standard, etc.)To be vague, I'd like to point out that Stroustroup had a commentary on why not
for C++ somewhere - Design and Evolution of C++, maybe?

-- 
David Starner - dstarner98@aasaa.ofe.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: Function name problem

[David C. Hoos, Sr.]

David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:85stib$a2g1@news.cis.okstate.edu...
> On Sun, 16 Jan 2000 12:37:21 +0100, Harald Schmidt
<Harald.Schmidt@tomcat.de> wrote:
> >in article 85qecu$24r$1@nnrp1.deja.com, Jeff Carter at
> >jrcarter001@my-deja.com wrote on 15.01.2000 19:30:
> >
<snip>
> it. If I could use Unicode in writing programs, I can see a few places
> where mathematical symbols would make nice operators, but still,
> a {dot symbol} b and a {cross symbol} b aren't superior enough to
> Dot(a,b) and Cross (a, b) to make the precidence and readibility
> problems worth it.
Beside which, the parameter/return type profiles of dot product and
cross product are unique, so you can just use the "*" operator
for these.
<snip>

Re: Function name problem

[David Starner]

On Sun, 16 Jan 2000 20:47:41 GMT, David C. Hoos, Sr. <david.c.hoos.sr@ada95.com> wrote:
>
>David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
>news:85stib$a2g1@news.cis.okstate.edu...
>> it. If I could use Unicode in writing programs, I can see a few places
>> where mathematical symbols would make nice operators, but still,
>> a {dot symbol} b and a {cross symbol} b aren't superior enough to
>> Dot(a,b) and Cross (a, b) to make the precidence and readibility
>> problems worth it.
>Beside which, the parameter/return type profiles of dot product and
>cross product are unique, so you can just use the "*" operator
>for these.

I wouldn't. Target typing is a feature that's prone to abuse, and 
overloading * for the dot product _and_ the cross product seems
like it could cause confusion. a := b * c; would mean dramatically
different things based on whether a was vector or scalar.

(Target typing is something unnerved me when coming from C++, because
it seems wrong not to be able to decide the type of an expression
without the context. I now understand why it's much more necessary in
Ada than C++ or Modula-3, because of the variety of distinct builtin 
types in Ada and lack of conversions, but it's still not one of my
favorite features.)

-- 
David Starner - dstarner98@aasaa.ofe.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: Function name problem

[Howard W. LUDWIG]

"David C. Hoos, Sr." wrote:
> 
> David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
> news:85stib$a2g1@news.cis.okstate.edu...
> > On Sun, 16 Jan 2000 12:37:21 +0100, Harald Schmidt
> <Harald.Schmidt@tomcat.de> wrote:
> > >in article 85qecu$24r$1@nnrp1.deja.com, Jeff Carter at
> > >jrcarter001@my-deja.com wrote on 15.01.2000 19:30:
> > >
> <snip>
> > it. If I could use Unicode in writing programs, I can see a few places
> > where mathematical symbols would make nice operators, but still,
> > a {dot symbol} b and a {cross symbol} b aren't superior enough to
> > Dot(a,b) and Cross (a, b) to make the precidence and readibility
> > problems worth it.
> Beside which, the parameter/return type profiles of dot product and
> cross product are unique, so you can just use the "*" operator
> for these.
> <snip>

For some applications this is acceptable.  However, I never use the "*" 
operator any more for vector-on-vector operators because there are too 
many applications I encounter where there is ambiguity, and it's easier 
to be consistent and always write the operation as a function with a 
spelled-out name.  (I do still use "*" for multiplying a scalar times a 
vector, though.)

The problems arise when one wants to do anything more than 
  S := U * W;
and
  V := U * W;
There are numerous other products of vectors important in various 
applications.  One example is the scalar triple product:
  S := Dot(U, Cross(V, W));
which one might like to write as 
  S := U * (V * W);
but is very confusing to compilers.  An ironic fact is that the mathematics 
enable one to shorten the notation to (U V W), meaning that a vector 
product of any two cyclically consecutive vectors followed by a scalar 
product of the remaining vector yields the same result.  Thus, if one 
were to write U * V * W, it would not matter (ignoring numerical analysis 
issues) which multiply was regarded as the cross product and which as the 
scalar product, as long as the vector product is done first--the compiler 
would go nuts (or at least claim you were nuts) when it wouldn't need to.  
(Note:  I am not advocating the dropping of parentheses in mathematics nor 
Ada for these sorts of expressions--precedence is important and ambiguity 
needs to be removed; the cross product is NOT associative, for example.)

Howard W. LUDWIG

Re: Function name problem

[David A. Cobb]

David Starner wrote:
> (1) Where do you put the new operator? Any fixed place will be wrong
> much of the time, and a flexible place will kill the parsing speed,
> cause much pain for parser writers, and make the program hard to read.
> f := a % b && c == d; could have almost any precedence, and since
> builtin precedence is already enough of a readibility problem . . .
> 

Those of us with gray beards and long if flaky memories may remember
"Algol '8x" (I don't recall the x).  An over-ambitious work by theorists
that was still around when Ada was being designed.  Had a lot of
symbology about user defined operators.  I could never read any of it. 
'C' is hard enough to read.

Re: Function name problem

[David Starner]

On Sun, 16 Jan 2000 22:48:51 GMT, David A. Cobb <superbiskit@home.com> wrote:
>Those of us with gray beards and long if flaky memories may remember
>"Algol '8x" (I don't recall the x).  An over-ambitious work by theorists
>that was still around when Ada was being designed.  Had a lot of
>symbology about user defined operators.  I could never read any of it. 
>'C' is hard enough to read.

Do you mean Algol 68? Sounds like a description of that language, and 
it would be "still around" when Ada was being designed (late 70's-early
80's). comp.lang.misc had someone pushing it as the alpha and omega
of languages recently (to be fair, it was no more radically than many
of us push Ada or the Perl people push Perl - it was only the language
that made it memberable.)

-- 
David Starner - dstarner98@aasaa.ofe.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: Function name problem

[David A. Cobb]

David Starner wrote:
> 
> On Sun, 16 Jan 2000 22:48:51 GMT, David A. Cobb <superbiskit@home.com> wrote:
> >Those of us with gray beards and long if flaky memories may remember
> >"Algol '8x" (I don't recall the x).  An over-ambitious work by theorists
> >that was still around when Ada was being designed.  Had a lot of
> >symbology about user defined operators.  I could never read any of it.
> >'C' is hard enough to read.
> 
> Do you mean Algol 68? Sounds like a description of that language, and
> it would be "still around" when Ada was being designed (late 70's-early
> 80's). comp.lang.misc had someone pushing it as the alpha and omega
> of languages recently (to be fair, it was no more radically than many
> of us push Ada or the Perl people push Perl - it was only the language
> that made it memberable.)
> 
> --
> David Starner - dstarner98@aasaa.ofe.org
> If you wish to strive for peace of soul then believe;
> if you wish to be a devotee of truth, then inquire.
>    -- Friedrich Nietzsche

Actually, David, I did mean '83(?).  I doubt there was ever a compiler
for that one: I don't think it got beyond the pages of CACM.  Algol'68
was a pretty close ancestor of the Pascal/Ada family of syntax's.  As I
said, the 1980's attempt to update it seemed to get pretty bogged down
in just how radical it could be - with very formal semantics.

Since even the unsuccessful branches are part of any evolutionary tree,
it wouldn't surprise me if some of the lessons from that influenced the
Ada design team.  Algol was also more popular in Europe than in the US,
and the designers could have been closely familiar with the work.

Re: Function name problem

[David Starner]

On Mon, 17 Jan 2000 00:31:38 GMT, David A. Cobb <superbiskit@home.com> wrote:
>Actually, David, I did mean '83(?).  I doubt there was ever a compiler
>for that one: I don't think it got beyond the pages of CACM.  Algol'68
>was a pretty close ancestor of the Pascal/Ada family of syntax's.  As I
>said, the 1980's attempt to update it seemed to get pretty bogged down
>in just how radical it could be - with very formal semantics.

I'm not sure I'd describe Algol 68 as a close ancestor of Pascal/Ada. 
Pascal was not derived from it, though it may have been affected by
Wirth's dislike of that language. From everything I've read, radical,
with very formal semantics, describes also Algol 68.

>Since even the unsuccessful branches are part of any evolutionary tree,
>it wouldn't surprise me if some of the lessons from that influenced the
>Ada design team.  Algol was also more popular in Europe than in the US,
>and the designers could have been closely familiar with the work.

It would suprise me. The Algol 83 work would have been completed at the
same time Ada 83 was, and generally failed works don't provide much 
inspiration until they've failed and you can do a decent post-mortem.

-- 
David Starner - dstarner98@aasaa.ofe.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: Function name problem

[Jeff Carter]

The Ada design team was certainly familiar with Algol 68, which does
allow user-defined operator symbols. It's one of the reasons user-
defined operator symbols are not part of Ada.

FWIW, Bjarne's favorite language before he designed C++ was Algol 68.
--
Jeff Carter
"Now go away or I shall taunt you a second time."
-- Monty Python and the Holy Grail


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Function name problem

[Matthew Heaney]

In article <B4A633AE.3FF3%Harald.Schmidt@tomcat.de> , Harald Schmidt 
<Harald.Schmidt@tomcat.de>  wrote:

> I want to declare two function, but the 2nd is not
> allowed by GNAT3.12. Could someone tell me why?
> Here are the two declarations:
>
> package bla is
>     type Object is tagged limited private;
>     function "=" (Left, Right: in Object�Class) return Boolean;
>     function "==" (Left, Right: in Object�Class) return Boolean;
> private
>     type Object is tagged limited null record;
> end bla;

There is no "==" operator in Ada.

In Ada, "=" means "equality" (not assignment).

If you want to override assignment for a type, you must declare the type
as nonlimited and derive from Controlled:

with Ada.Finalization;
package P is

  type T is private;

  function "=" (L, R : T) return Boolean;  -- equality

  <other ops>

private

  type T is new Ada.Finalization.Controlled with record
    ...
  end record;

  procedure Adjust (O : in out T);

  procedure Finalize (O : in out T);

end P;


You don't have the assignment operator for limited types.  In that case,
declare an explicity Copy operation.


--
You cannot think without abstractions; accordingly, it is of the utmost
importance to be vigilant in critically revising your modes of
abstraction.  It is here that philosophy finds its niche as essential to
the healthy progress of society.  It is the critic of abstractions.

Alfred North Whitehead