Re: Rosen Trick [List container strawman]

[dewar@gnat.com (Robert Dewar)]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message news:<9s230d$107b5a$2@ID-25716.news.dfncis.de>...

> PS: Why? Because functions should not have side-effects (in a language like
> Ada).

You present this as a kind of obvious ab initio fact, but
it is nothing of the kind.

Here are the facts:

Ada permits functions to have side effects, and does not
attempt to prohibit side effects in functions (an odd and
inconsistent exception is functions in protected types,
and that was indeed a major discussion point in the design)

There was some attept early on to consider trying to stop
functions from having side effects, and indeed I think one
published early version of Ada distinguished functions and
value returning procedures, or at least that was discussed.

But such attempts were firmly rejected, and the decision
was that there are situations where it makes perfectly good
sense for functions to have side effects, and an absolute
rule prohibiting them is in the same not-well-thought-out
category as absolute rules against use clauses, goto statements,
unchecked conversion, and various other very
useful features of Ada. Useful does not mean that they should be used
all the time, or misused, just that they
have some legitimate use.

Another important factor is that other languages agree with
Ada that functions should be allowed to have side effects.
In particular C takes this viewpoint, and side effects in
functions are common in C, including side effects in calls
to standard functions in the C library.

Now in Ada, the rule for functions is a bit odd:

  Side effects from access to global variables - permitted
  Side effects from modifying access type args - permitted
  Side effects from in out parameters - prohibited

I have never understood the rationale for this inconsistent
design. When I talk to someone like Tuck, who basically supports the
prohibition, it seems to come from a general
feeling that functions should not have side effects. OK,
but that's some other language than Ada, where functions
are permitted to have side effects.

Most annoyingly, the natural translation of a * arg in a
C function, e.g. *int, is to translate it to an IN OUT
parameter, but that is arbitrarily not allowed. It is of
course allowed to translate it to an access-to-int parameter, since
there is no restriction on the use of
such parameters for functions, even though they are obviously
logically equivalent from an expressive point
of view.

The trouble is that although in-out parameters and access-type-to-foo
parameters are equivalent from a logical
point of view, they are very different syntactically, and
we are left with the following unpleasant alternatives in
interfacing to C functions:

  1. Interface as procedures. This either requires a 
     wrapper or something like the Valued_Procedure
     interface available in GNAT. The trouble with 
     this is that the calls get really ugly. Yes, in
     the case where the result is just an error code
     it's acceptable, but that's by no means always
     the case.

  2. Interface using named access types. The calls are
     somewhat better here, but you get a plague of aliased
     variables appearing, and the access types need 
     defining which is messy.

  3. Use a wrapper with global variables for the missing
     parameters. But this is nasty anyway, and gets too
     far from the C form.

To me, the arguments for allowing IN OUT parameters, at
least for interfaced functions, are very strong, but
unfortunately, this is an argument that cannot be won.
There seem to be three kinds of people:

1. Those who are adamantly opposed to IN OUT parameters
on basically religeous (i.e. belief based) grounds without
very strong technical justification in many cases, or with
the technical justification being inconsistent with the
general permission for functions to have side effects in
Ada. This is a surprisingly large group.

2. Those who really don't like functions with side effects
much, but would tolerate IN OUT parameters if they had to,
but are certainly not going to fight for them, and would
vote no or abstain. I think I correctly label Tuck and the
design team in this second group, which is also fairly large.

3. Those who really find this restriction annoying, and have fought to
get it lifted. They are a large group, but
somewhat less than a working majority.

I don't see anything that would put group 3 in a position
to fix this annoying restriction in the near future, so it
to me is just a minor defect in the language that will stay
uncorrected, but we can live with it, it's not fatal, just
very annoying.