<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
KC comments the posting of Donn Cave referring to the soundness of
some potential approach of software engineers:
<blockquote
cite="mid:CAMLKXymmj6hzaB10sqeG0PJSkqEFM8tRQmMLBkDAwJZzrfH-tQ@mail.gmail.com"
type="cite">Apparently on such solid ground that you hinder their
critical thinking skills by answering for them</blockquote>
<br>
Monsieur KC, do you want to discuss, or just to be cute?<br>
<br>
In both cases, begin by signing your posts. I will not discuss with
an anonymous, and concerning your question about referential
transparency, I permit myself to send you to some standard
literature. Over.<br>
<br>
==<br>
Chris Smith:<br>
<blockquote>
<pre wrap="">When we're talking about different uses of the word "function" in
programming languages, side effects refer to any effect other than
evaluating to some result when applied to some argument. For example,
in languages like C, printf takes some arguments, and returns an int.
When viewed as just a function, that's all there is to it; functions
exist to take arguments and produce return values. But C extends the
definition of a function to include additional effects, like making
"Hello world" appear on a nearby computer screen.</pre>
</blockquote>
... And here I disagree. If printf, or whatever explodes an atomic
bomb, this is not a "side effect". If a procedure executes such a
statement: "x = x+1", or "a[1]=a[2]", it IS. <br>
And even that, not always !<br>
<br>
In Clean, which is as pure as Haskell, there are "unique access"
variables, and it is possible to write (+/-...)<br>
<br>
# myFile = write myFile "Hello World"<br>
<br>
And the point is that WHATEVER happens to the outer world, and the
computer file system in particular, there are no side effects within
the program. The "#" construction is a "temporal", sequential part
of a purely functional expression, exactly as a monadic chain in
Haskell, disguised as a do block. There are two "distinct" file
objects, the "previous", and the "next" one, which happen to share
the same name, because *the type system* prevents that a computing
block refers to both. Either the old, or the new.<br>
<br>
This is my philosophy. If somebody disagrees, that's alright.<br>
<br>
Jerzy Karczmarczuk<br>
<br>
<br>
<br>
</body>
</html>