comp.lang.ada
 help / color / mirror / Atom feed
From: yale.edu!spool.mu.edu!umn.edu!sctc.com!stachour@yale-bulldog.arpa  (Paul
Subject: Re: Procedure/function specification/declarations
Date: 27 Apr 92 15:58:47 GMT	[thread overview]
Message-ID: <1992Apr27.155847.5333@sctc.com> (raw)

svh@verdix.com (Steven Hovater) writes:

>In article <21295@hacgate.UUCP> hayes%bh_ddemo3@hac2arpa.hac.com writes:
>>I'm a beginner to Ada...
>>
>>
>>I've noticed that it is possible to specify a procedure 
>>or function without parameters without using a 
>>null parameter list specification.  What was the thinking
>>behind this or why is this method superior?
>>
>>For example, in ANSI C a function prototype might be
>>   boolean empty (void);
>>In Ada, a corresponding specification would be
>>   function empty return boolean;
>>

  I think that the C style comes from the PL/I style.
I don't know where PL/I got the style.

  The need is to distinguish between passing a function
and calling a function.  For exmple, if I write in PL/I,
  [My PL/I is rusty, this might not be 100% right]

      DCL EMPTY_F ENTRY () RETUNRS ( ENTRY () );

and then call P, which expects to take as its first argument
a entry with no parameters, then I need to distinguish between

  1:    A = P ( EMPTY_F(), ... )
and
  2:    A = P ( EMPTY_F, ... )

In case 1, the function returned by EMPTY_F is being passed,
in case 2, EMPTY_F is being passed.

Note that any well-defined language that allows entries to be passed
as arguments needs some way of making that distinction. [No, I don't
consider C as a well-defined language, but C does allow entries
to be passed as arguments and Ada doesn't.  That's good in some
contexts and bad in others.  It's my opinion that the requirements
for Ada forbid the definition of entries being passed as arguments
based upon the horrors that were present in FORTRAN and Assembly and
... code of that day; these horrors are often also present in
poorly-designed C programs.  They are not present in poorly designed
Ada programs because they aren't possible.]


-- 
Paul Stachour          SCTC, 1210 West County Rd E, Suite 100           
stachour@sctc.com          Arden Hills, MN  55112-3739
                             [1]-(612) 482-7467

             reply	other threads:[~1992-04-27 15:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1992-04-27 15:58 yale.edu!spool.mu.edu!umn.edu!sctc.com!stachour [this message]
  -- strict thread matches above, loose matches on Subject: below --
1992-04-27 10:59 Procedure/function specification/declarations Steven Hovater
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox