Re: Valued procedures

[adam@irvine.com]

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