# Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

Date: 24 Jun 2005 22:02:43 -0700

Message-ID: <1119675763.210232.82680_at_o13g2000cwo.googlegroups.com>

VC wrote:

> "Marshall Spight" <marshall.spight_at_gmail.com> wrote in message

*> >
**> > If you want to expand the definition of function such that its outputs
**> > include the state of all global variables and all output streams,
**> > then it would no longer meet the definition, but you'd have to then
**> > say that the definition of f() is "append X to the printer stream and
**> > return 2*a."
**>
**> I do not need "to expand the definition of function". Including side effect
**> treatment is a commonly accepted is a standard approach and has been such
**> for many years. One *must* include the notion of state because that's
**> exactly what a function with side effects does, changes the state.
*

I see: you're saying "everyone agrees with me so I must be right."

I went through a big round-and-round on this on comp.lang.functional a few years back. You're right in that it is "commonly accepted" to lump both input and output together as things that break RT, but in fact, only input breaks it, by definition.

> >I don't think such a definition would be very useful,

*>
**> Au contraire, ignoring side effects in a hypothetical computational model
**> would be extremely strange, to say the least. I do not wish to discuss the
**> subject of side effects and referential transparency in general any further
**> since it's been hashed and rehashed many times . One can consult any decent
**> book on FP or denotational semantics for further info.
*

I didn't say we ignore them, but neither did I say we consider write-only global state changes to be included in the return value of a function. Why do they call them "side" effects, do you think?

> > The further problem then comes with the fact that your program

*> > can't know whether it's running on a virtual machine of some
**> > kind, and perhaps that virtual machine calls a print function
**> > each time a method is called. With the expanded definition of
**> > function, it is impossible to know what the outputs of a function
**> > are without considering not only the function but the machine
**> > it is running on. Of course, *that* machine could be running on
**> > a virtual machine, so you have to talk that into account as well.
**>
**> So what's you point re. the virtual machine ? We do not need to anything of
**> the kind you describe. There are several ways to handle side effects in FLs
**> including monads, continuation passing , the notion of the "unique world"
**> in Clean, etc.).
*

You're missing my point, which has nothing to do with monads or even FP.

Consider: your claim is that if a function does output, it is
necessarily

not referentially transparent. I say, give me any function you care to,
and I'll run it on a machine that does output as it executes the
function.

Therefore, any function you give me is not RT. RAA.

Marshall Received on Sat Jun 25 2005 - 07:02:43 CEST