A New Revealation: Semi-Permeable Membranes

Marc Stiegler marcs@skyhunter.com
Wed, 27 Oct 1999 12:50:02 -0700


> >Markm, unlike you, my visceral sense of the frequency with which I wind
up
> >having
> >void methods is pretty high (though I suppose it makes sense to look at
> >Edesk and see what really happens if we need to argue this to the ground
:-)
>
> [+] It would be good to check.

Random inspection of pages of Edesk (not the whole thing) suggests that
indeed almost half my methods return no value. As a tiny example of the
trend, there's the vowsMonitor:
    the vowsMonitorMaker returns a value (the vowsMonitor),
    add(promise) is void,
    promiseFinish() returns a value (the promise of finishing), and
    finishAll is void (it communicates its result by resolving the
finish-promise).

I hypothesize that promise-laden programs might often have pairs of methods
in which one method returns a promise and the other method does not because
it resolves the promise. In another amusing anecdote of void methods, the
objects for doing file copies (which have the most complex logic of the
system) don't return values: the relationships of the objects are complex
enough, returned values don't cut it--they give each other capabilities to
themselves at the outset and just tell each other what to do.

In addition, the NavigatorWindow methods are virtually all void, setting
internal state which is reflected in the GUI for the user. In the
NavigatorWindow requiring the ": void" is a real, uh, pain--lots of syntax
for little payoff. It makes me urge you once again to make void the default,
though I am not hysterical on the issue.


> Why should functions have any less access to mutable state than objects?
How does having 1-run-method vs multiple methods effect what state they
have?  For an example of a stateful void-revealing function, look at the
"cancel" function inside the smart contract for the covered call option at
http://www.erights.org/elib/capability/ode/ode-bearer.html .

Huffy, huffy :-) I'm probably using the terms "function" and "object"
slightly differently, and surely wrongly :-) Think of an object as a thing
created with the objectMaker pattern: in this situation, the object has a
place to store state that is local to the object itself (or at least local
to the objectMaker). A pure function has no local place to store state, it
depends on its environment for state. So function state tends to be more
global than object state, which leads me to be more uncomfortable about
function state than object state. This in turn would in theory lead me to
use state less often with functions.

Feeling that I have just won the theory side of this argument decisively
(hey, we all have our illusions), I find in practice, examining Edesk, that
about half my functions, like half my methods, return no value. Some are,
like your cancel function, functions embedded in objects and use the
object's state; some are functions whose sole job is to twiddle other
objects' state (for example, in my UIToolkit, many methods just fiddle the
internal parameters of gui widgets created elsewhere).

> [-] No, but I may be programming in a more side-effect-free fashion.

Of course you are, markm, otherwise you wouldn't be markm :-) It would be
amusing to see Edesk written from scratch by you, as a compare and contrast
teaching tool. But it's already too late--I told you about some of the
patterns I invented along the way, they tend to use state, it would damage
your independence :-)

> I expect an initial explanation for the novice may say merely
>
>      Write ": any" when you want to reveal a value and ": void" when you
don't.
>      We'll explain later.
>
> but you're the explanation expert.  What should we say?

I'd recommend,

     Write ": any" when you want to return a value and ": void" when you
don't.
     We'll explain later how to optionally use this for type checking.

Note the use of the term "return", which is more familiar, if you can bring
yourself to tolerate it; in this context it really doesn't seem harmful to
me. And we mention the opportunity for optional type checking, which will
please the Pascal people (since it's possible) and won't upset the Perl
people (since it's optional).

--marcs

PS: one last thing, below--

> [-] Say what!  Write "Lambda Abstraction" on the wall 100 times.

"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
"Lambda Abstraction" "Lambda Abstraction" "Lambda Abstraction" "Lambda
Abstraction"
>