Re: DSSSL side effect-freeness

["G. Ken Holman" <gkholman@xxxxxxxxxxxxxx>]

At 14:06 98/01/27 +0900, Frank A. Christoph wrote:
>I know we have been over this issue before, but would somebody please
>reiterate the reason that the DSSSL expression language must be side
>effect-free?  

I'll leave it to the language theorists to explain if it *must* be side
effect free, but as a practitioner I have my own reasons why I applaud that
it was chosen to be side effect free.

I'll be the first to confess I found side effect freeness awkward (to say
the least), because I am a second generation "classical" computer
programmer and was "taught on my father's knee" from a young age.  I've
always written computer programs with global variables, and it was only
with DSSSL that I learned that a global variable is a big example of
allowing side effects.  There are other examples of side effects, but this
was what cemented the concept for me.

If I have a global variable, that is, a variable who's scope is included in
the scope of routines other than the routine I am writing (or running),
then my routine has no knowledge of what other routines may do to my global
variable.  My usual example is "ChapNum" ... when I wrote my first DSSSL
script I tried to declare a global variable "ChapNum" which would be
incremented for every chapter and accessed every time I wanted to print a
chapter title.  I think this would be considered the "classical" approach,
and I approached it this way only to find that in DSSSL there is no such
global scope for a variable whose value can be changed.  The concern is,
then, what happens if someone else steps on my chapter number value without
my knowledge, I would then be trusting a global with an incorrect value
(and could end up spending a lot of time debugging what the problem was if
I was lucky enough to see that there was, indeed, a problem of someone
stepping on the value (which may not be obvious)).

The DSSSL way to calculate chapter number is to go the the chapter's
parent's first child and count the present position with the number of
siblings ... and to do it for every chapter without remembering where you
were from the previous chapter.  Fortunately, there are derived procedures
that do this in constant time, not in a time relative to the number of
siblings.

The language *by design* assures programmers that *any* subroutine or
construction rule they write *can never* be impacted by *any other*
subroutine in the entire program (sorry for the excessive emphasis, but
this is the nub of the benefit).  Nor can your program ever adversely
affect other programmers code in the program (not that any of us on this
list ever have buggy programs).

Think of the development cycle .... as soon as a routine is debugged it
will always execute the way we've written it and will never be impacted by
any other routine we write in our program, nor by any routine written by
any other programmer that might be included in our program.

Think of the shared corporate code base of DSSSL subroutines and
construction rules ... a company can create source libraries of DSSSL code
that are *by language design* impervious to the programs that use the
common sources.

This was a revelation to me and I think it is a *better* language for being
side-effect free.  I'll certainly acknowledge it can be a more *difficult*
langauge for being side-effect free.

>It seems very odd to me that a language which has been so
>conscientiously purged of side effects is nevertheless call-by-value.

But wouldn't it be necessary to be call-by-value?  Call-by-reference would
(I think) blatantly allow potential side effects.  If the calling routine
called a subroutine using call-by-reference, then the subroutine could have
incredible side effects on the variable being passed.  There would be no
assurance of the integrity of the returned value.  Of course there is no
assurance of the integrity of the value returned as a result of the
procedure, but the calling program can manage where that returned value is
being used, while it cannot manage the integrity of a value being passed by
call-by-reference since the calling routine may have corrupted the value
therein.  Using call-by-value guarantees that the value being passed cannot
be corrupted.

>I
>have mentioned before that, although DSSSL is side effect-free, it is not
>"read effect-free", since there are procedures whose result depends on the
>context, e.g., current-node, process-children.  

I'm not familiar with the term "read effect-free".  Procedures depending on
context are necessary if the context provides some information needed by
the procedure (I suppose that is a "null" statement).  I don't see any
impact on the side-effect-freeness of the subroutine, nor on the calling
routine.

>Is the CBV behavior
>necessary in some way to allow lazy grove implementations?  What about the
>so-called side effect-freeness?

I'm quite confident call by value is necessary to avoid side effects on
locally scoped variables, but as I said above, I'm not a language theorist,
only a practitioner.

>P.S.: No one has commented on my last (1/22) message concerning possible
>implementions of "continued on next page"... Should I take this to mean that
>_no one_ feels a need for the feature, or that no one wants to venture a
>guess?

I've answered this on my own behalf in a separate reply since it covers
another topic.

............... Ken

--
G. Ken Holman            mailto:gkholman@xxxxxxxxxxxxxx
Crane Softwrights Ltd.  http://www.CraneSoftwrights.com
Box 266,                             V: +1(613)489-0999
Kars, Ontario CANADA K0A-2E0         F: +1(613)489-0995
PGP Privacy: http://www.cyberus.ca/~holman/gkholman.pgp
Training:  http://www.CraneSoftwrights.com/schedule.htm


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist