Re: String filtering

[Jacob Sparre Andersen <sparre@nbi.dk>]

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. - But I'm a mathematician (and physicist), not a
computer scientist.

> 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.  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.

It might be possible to do something similar with a pragma, but I
would prefer to have it more explicit in the declaration of the
function.

Introducing a clear separation of functions in those which can have
side effects and those which can't have side effects, might also allow
us to tighten the current, somewhat lax definition of functions
without side effects.

> 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?

> 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.

> 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.

> P.S. "Side effect" is a pejorative term.  (Some drug cures your
> disease, but makes you nauseous.)  If the effect is intended by the
> programmer, and clear in the code, perhaps we should call it an
> "effect", without the "side".

"Effect" is not quite clear enough.  "Global effect" might be to
exaggerate a bit.  "Modifying function"?

Greetings,

Jacob
-- 
"Three can keep a secret if two of them are dead."