Re: String filtering

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 03 Oct 2005 09:44:10 +0200, Jacob Sparre Andersen wrote:

> Robert A Duff wrote:
>> Steve Whalen wrote:
> 
>>> I seem to have been brainwashed into thinking that functions with
>>> side effects of any kind were a "bad thing", especially in a
>>> language like Ada.
>>
>> I think that side effects in functions are usually a bad idea.
>> But not always.
> 
> My whole understanding of the concept "a function" is that it doesn't
> have side effects.

What is a side effect? Reading a hardware register out is one? Consuming
CPU cycles? Cache manipulation? Heating the mainboard? There is no anything
without side effects. The whole program execution is just one big side
effect. You should specify what you wish to abstract away as unimportant
for the program. If the language allows to do this in a consistent way,
then there is no reason to care about side effects.

>> I think the programmer, not the language designer, should make such
>> decisions.  I like restrictive rules that prevent me (as a
>> programmer) from doing bad things by accident.  But I don't like
>> restrictive rules that try to prevent me from doing things I
>> deliberately choose to do.
> 
> The problem is then to introduce a way to make it clear if you want a
> function to have side effects or not.

IMO the source of confusion is in mixing three independent concepts:

1. Parameter modes (in, in out, out)
2. Distinguished parameters
3. Purity

> Just coding a function with
> side effects isn't the most clear way to do it (although using an "in
> out" parameter is pretty close).  Would it be to go too far to have to
> specify functions as either:
> 
>    function Name (...) return Subtype;
> 
> or:
> 
>    function Name with side effects (...) Subtype;
> 
> I know that new keywords aren't exactly popular, but I hope the basic
> idea still is clear.

No. There could be pure procedures as well. Clearly it should be the pragma
Pure allowed for subprograms. Purity requirement makes sense as an
implementation detail. I'm not sure if it does as a part of the contract,
which a keyword would imply.

Perhaps, Pure should have a second parameter to specify the purity context,
which might be useful for recursive subprograms and other cases of relative
purity.

>> We can solve this in Ada by adding various levels of indirection,
>> which is rather a pain.  For example, the "Rosen trick".
> 
> Would it be possible to tighten the rules for functions without side
> effects to prevent the "Rosen trick"?  Or will that workaround
> effectively always be possible?

But Rosen trick applies to objects! You can either:

1. Prohibit passing such objects in in-mode - a very bad idea, IMO.

2. Change the access type to a constant access type if the object is passed
as in. This probably could have some sense. One could use "renames" instead
of "access":

type Rosen is ... record
   Unsafe_Self : access Rosen'Class := Rosen'Access;
      -- This is in-out [new Ada 2005 syntax]
   Safe_Self : Rosen'Class renames Rosen'Class;
      -- This becomes constant in in-mode
   ...
end record;

>> Another example of side effects that I think are OK is when you're
>> getting items from a stream.
> 
> Agreed.  But I wouldn't mind being forced to document that the
> function had side effects.

What for? The contract is - you call it and it does the job. How it does
this is up to implementation. Much more important is how to deal with:

Get_Token (Stream) & Get_Token (Stream)
   -- What would be the result?

It would be nice if the compiler would reject the above when Get_Token were
impure and & did not specify any evaluation order. But that again brings
back the issue of what is the contract and what is an implementation
detail. Clearly a balance need to be found.

>> Both 'out' and 'in out' should be allowed.  If I ran the circus, I
>> would also require some sort of syntactic indication on the _call_
>> for '[in] out' parameters.  For both procedures and functions.
> 
> That might make more sense than just indicating it in the declaration.

I see no reason why. Consider changing a constant to variable somewhere in
the program. That could require massive changes throughout the sources.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de