Re: What evil would happen?

["Chad R. Meiners" <crmeiners@hotmail.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:o9s4hvofb2mtn8ga9ahf7uu530pfacald8@4ax.com...
> On Sun, 13 Jul 2003 13:28:54 -0400, "Chad R. Meiners"
> <crmeiners@hotmail.com> wrote:
>
> >"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
> >news:5ad0dd8a.0307130417.41548778@posting.google.com...
> >> Preben Randhol <randhol+abuse@pvv.org> wrote in message
> >news:<slrnbh02sj.4kj.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> >>
> >> > Well then functions with side effects should be more resonable
> >>
> >> "Functions" with side effects can only inject their side effect into
> >> where they have been hardcoded to.
> >This is wrong.  Function have the capability to randomly introduce side
> >effects just like any other section of code.
>
> So what is the point?

The point is that the statement was wrong.  It was a statement of fact.

> >>This is a serious limitation.
> >If it were true, I doubt it.  In my experience, functions are more useful
> >when they are pure.  Sure there are times when a function cannot be pure,
> >but sub-routine with a side-effect should be made a procedure in most
cases.
>
> It is also my view. But I see rather other consecuences from this:
>
> 1. All functions are pure. So no access parameters allowed, no access
> to global data from the body is allowed etc.
>
> 2. But procedures are allowed to have a result.
>
> This would be perfectly consistent and as safe as possible.

I prefer SPARK's rules on functions, but I think that we should just allow
in out parameters for our unpure functions since passing access parameters
can be ugly.  I really do not see the harm in allowing unpure functions
because good modularity usually nudges the programmer towards writing pure
functions.  However, when an exception is needed being able to write unpure
function should be straight forward and easy to detect at the specification
level.

> >In mathematics, functions only return single elements, which may be a
> >composite of some sort.
>
> In mathematics you can encapsulate all side effects in objects of
> unlimited complexity. It is not the case for programming languages.
> Especially ones with weak type inference capability.
True, I was only stating inspiration for using records to return multiple
values.

> ---
> Regards,
> Dmitry Kazakov
> www.dmitry-kazakov.de
-CRM