Valued procedures

Valued procedures

[dmitry6243]

Hi All!

I do not want to restart this weary thread again. Just a question: was the
following alternative (which seems to be a good compromise with rigouristic
point of view) ever considered:

Let's allow, for instance:

    procedure SideEffect (X: in out State) return Boolean;  -- Valid

but

    function SideEffect (X: in out State) return Boolean;   -- Invalid

Further, I believe it should be possible to ignore the result of a procedure.
(Using Ada bindings would be much less painful and produce clearer code if you
were not forced to declare tonns of dummy variables just to ignore various
unused results.) So that either

(a) SideEffect (TheState);

    would be valid, or

(b) the null statement could have a form:

    null <any-expression>;    -- The result is explicitly ignored

Regards,
Dmitry Kazakov

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Valued procedures

[dennison]

In article <786pfu$1vb$1@nnrp1.dejanews.com>,
  dmitry6243@my-dejanews.com wrote:

> Further, I believe it should be possible to ignore the result of a procedure.
> (Using Ada bindings would be much less painful and produce clearer code if you
> were not forced to declare tonns of dummy variables just to ignore various
> unused results.) So that either

The Ada way to handle this is to overload the procedure with a version that
does not return those results, and in its body call the first (full) routine.
This does add an extra layer to your bindings, but bindings to another
language are almost *always* awkward to use in Ada without adding another
layer. That's what's meant by "thick" bindings.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Valued procedures

[robert_dewar]

In article <787gb8$kp2$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> This does add an extra layer to your bindings, but
> bindings to another language are almost *always* awkward
> to use in Ada without adding another
> layer. That's what's meant by "thick" bindings.


Wrong on both counts. Thin bindings routinely provide a
procedure and function version for such interfaces.

Second, thick bindings are (hopefully!) about far more than
little trivial issues like this, they are about raising
the entire semantic level of the interface to a more
strongly typed, more abstract level. POSIX/Ada is a good
example of such a binding.

Incidentally allowing people to routinely ignore the
results of a call to a C function where the result is
the error code in Ada is truly horrible -- a systematic
way of importing into Ada one of the nastiest features of
C :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Valued procedures

[dennison]

In article <787poa$toc$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:
> In article <787gb8$kp2$1@nnrp1.dejanews.com>,
>   dennison@telepath.com wrote:
> > This does add an extra layer to your bindings, but
> > bindings to another language are almost *always* awkward
> > to use in Ada without adding another
> > layer. That's what's meant by "thick" bindings.
>
> Wrong on both counts. Thin bindings routinely provide a
> procedure and function version for such interfaces.

Yikes! There's a trick I had forgotten about. You would still need procedures
like I described if you want to leave out optional output *parameters* (other
than ones at the end). But I don't think that's what Dmitry was getting at.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Valued procedures

[dmitry6243]

adam@irvine.com wrote:

> ...                                                  If you have a
> function that searches a large binary tree for a key and returns a
> value, it might make sense in some applications for the function to
> store the key and value in a global variable, so that if the next
> search uses the same key, the tree doesn't have to be searched again.
> This principle was discussed in Meyer's _Object-oriented Software
> Construction_.)

Now imagine that instead of burying the search state in invisible globals you
would like to expose it as an IN OUT parameter ...

I agree that in a carefully designed program procedures with return values
would be rare. As well as gotos which are allowed.

I agree that they are clumsy (in most cases), but the alternative is pointers,
which are much more worse.

Regards,
Dmitry Kazakov

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Valued procedures

[robert_dewar]

In article <78hddd$8in$1@nnrp1.dejanews.com>,
  dmitry6243@my-dejanews.com wrote:
> adam@irvine.com wrote:
> Now imagine that instead of burying the search state in
> invisible globals you would like to expose it as an IN
> OUT parameter ...
>
> I agree that in a carefully designed program procedures
> with return values would be rare. As well as gotos which
> are allowed.
>
> I agree that they are clumsy (in most cases), but the
> alternative is pointers, which are much more worse.
>
> Regards,
> Dmitry Kazakov

Dmitry, you should really go and look at the archives for
previous threads here. This is a subject that has been
discussed to death, and it is unlikely you have anything
new to say (so far you don't!)

By the way I agree with your position, but this is a well
discussed issue, and absent new arguments, nothing will
change in this area.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Valued procedures

[robert_dewar]

In article <786pfu$1vb$1@nnrp1.dejanews.com>,
  dmitry6243@my-dejanews.com wrote:
>
> Further, I believe it should be possible to ignore the
> result of a procedure.

Anyone can believe anything they like :-)

But this proposal is clearly at odds with the design goals
of Ada and would not have a ghost's chance of winning
approval!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Valued procedures

[robert_dewar]

In article <786pfu$1vb$1@nnrp1.dejanews.com>,
  dmitry6243@my-dejanews.com wrote:
> Hi All!
>
> I do not want to restart this weary thread again. Just a
> question: was the following alternative (which seems to
> be a good compromise with rigouristic
> point of view) ever considered:

If you don't want to restart a weary thread, first go to
the dejanews archives and thoroughly research the old ones
first :-).

Yes of course something like this was considered, and no it
does not work for many reasons, see the old thread to
understand why not!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Valued procedures

[Tom Moran]

>Using Ada bindings would be much less painful and produce clearer code if you
>were not forced to declare tonns of dummy variables just to ignore various
>unused results.
If the result is unused, why are the routines declared as function,
rather than procedures?  That sounds like an error in the binding.

Re: Valued procedures

[adam]

In article <786pfu$1vb$1@nnrp1.dejanews.com>,
  dmitry6243@my-dejanews.com wrote:
> Hi All!
>
> I do not want to restart this weary thread again. Just a question: was the
> following alternative (which seems to be a good compromise with rigouristic
> point of view) ever considered:
>
> Let's allow, for instance:
>
>     procedure SideEffect (X: in out State) return Boolean;  -- Valid
>
> but
>
>     function SideEffect (X: in out State) return Boolean;   -- Invalid

To answer your question: yes, it was considered.  In fact, I recall seeing
essentially your proposal in early drafts of the Ada language (around 1980 or
1981), before the standard was finalized.  I don't know why this feature was
removed in the final version---perhaps someone can enlighten us?  (I'm not
saying I miss this feature; I prefer not to have variables buried in the
middle of an expression changing their values, but that's just my personal
preference.)

				-- Adam

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Valued procedures

[Tucker Taft]

adam@irvine.com wrote:

: >     function SideEffect (X: in out State) return Boolean;   -- Invalid

: To answer your question: yes, it was considered.  In fact, I recall seeing
: essentially your proposal in early drafts of the Ada language (around 1980 or
: 1981), before the standard was finalized.  I don't know why this feature was
: removed in the final version---perhaps someone can enlighten us?  (I'm not
: saying I miss this feature; I prefer not to have variables buried in the
: middle of an expression changing their values, but that's just my personal
: preference.)

You answered your own question.  Many people "prefer not to have
variables buried in the middle of an expression change their values."

Ada has consistently favored readability/understandability over saving
a few keystrokes.  That characteristic certainly can be annoying at 
times, though, but it tends to be pretty pleasant a week or two after 
you write the code, and you are trying to remember how it works ;-)

: 				-- Adam

--
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Valued procedures

[adam]

In article <F5yzEt.5xB.0.-s@inmet.camb.inmet.com>
stt@houdini.camb.inmet.com (Tucker Taft) writes:
>
> adam@irvine.com wrote:
>
> : >     function SideEffect (X: in out State) return Boolean;   -- Invalid

To be precise, the feature in the early drafts was *procedures* that
returned values.  (But of course we have a religious war every now and then
about IN OUT parameters to functions.)

> : To answer your question: yes, it was considered.  In fact, I
> : recall seeing essentially your proposal in early drafts of the Ada
> : language (around 1980 or 1981), before the standard was finalized.
> : I don't know why this feature was removed in the final
> : version---perhaps someone can enlighten us?  (I'm not saying I
> : miss this feature; I prefer not to have variables buried in the
> : middle of an expression changing their values, but that's just my
> : personal preference.)
>
> You answered your own question.  Many people "prefer not to have
> variables buried in the middle of an expression change their values."
>
> Ada has consistently favored readability/understandability over saving
> a few keystrokes.  That characteristic certainly can be annoying at
> times, though, but it tends to be pretty pleasant a week or two after
> you write the code, and you are trying to remember how it works ;-)

There's another factor that I just remembered this morning.  In the
early version that I recall, Ada had both functions and
value-returning procedures; but functions were not allowed to have any
side effects at all.  I don't remember all the details, but I assume
this means that, among other things, a function couldn't modify a
global variable, nor could it call a procedure that could modify a
global variable.  I suppose this was part of the reason for providing
value-returning procedures---to have something that behaves like a
function but is allowed to have side effects.  Fortunately, people
realized that the no-side-effect rule for functions would be way too
difficult to enforce, and was a bad idea besides.  (Even if a function
call appears "pure" to the outside world, it's useful for a function
to be able to change the internal state for efficiency.  If you have a
function that searches a large binary tree for a key and returns a
value, it might make sense in some applications for the function to
store the key and value in a global variable, so that if the next
search uses the same key, the tree doesn't have to be searched again.
This principle was discussed in Meyer's _Object-oriented Software
Construction_.)

Anyway, if the no-side-effect rule for functions had to be dropped,
then probably there was a lot less need for value-returning
procedures.  Just my guess as to one of the reasons why this feature
was eliminated.

                                -- Adam

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own