GNU bug report logs - #15117
24.3.50; doc of `(forward|backward)-*': state return value

Previous Next

Full log

View this message in rfc822 format

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: 15117 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, Drew Adams <drew.adams <at> oracle.com>
Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value
Date: Tue, 11 Feb 2014 11:52:23 +0100

Am 11.02.2014 05:01, schrieb Stefan Monnier:
>>>> These are NOT side-effect functions.  They modify nothing except
>>>> the cursor position.
>>> How is that not a side-effect?
>> You are clearly arguing for the sake of arguing, now.
>
> Not at all.
>
>> Motion functions are not what is typically meant by a side-effect
>> function.
>
> Says you.  For me (and most definitions of side-effects I've ever seen),
> a side-effecting function is something like a function where the calls
> can't simply be replaced by their return value.
>
>

Can't see a logic link between a possible return value and the notion of side-effect.
It all depends from the purpose of the function.

Avoiding side-effects as a goal tries to avoid complexity.

While asking for (documented) return-values some times ago, being well aware these might constitute side-effects - but must not.
I.e. if a move-function reaches position, the buffer state is changed, but that's not a side effect, as it's the purpose.
If this function returns position for possibly receiving functions, would consider it a side-effect.

So if avoiding complexity is a goal, delivering a smart language is another one.
Not all side-effects are of same severity or same urgence to avoid.

Remains to decide. In case of move-functions, being in favor of returning position reached.

Documenting return-values is another --quite useful-- thing.

Cheers,

Andreas

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.