🚀 go-pugleaf

In article <2884@igloo.scum.com> nevin@igloo.scum.com (Nevin Liber) writes:
> In article <5088@uqcspe.cs.uq.oz.au> brendan@batserver.cs.uq.oz.au 
writes:
> >The percieved need for
> >side-effects in terms is merely a by-product of the poor state of 
language
> >design, and would not be missed at all in better languages.
> 
> I disagree.  This would throw out all functions which maintain their
> own state (eg: i/o).

It would throw out *all* output, with or without internally readable state 
information.  Setting a certain pixel to a certain color is a side effect, 
as is making a UART spit out a character, as is sending a packet out over 
the net.

There are good reasons to limit the kinds of side effects and their scope 
and to provide protections from unwanted interactions, but to say "no side 
effects" is absurd.  People do more with programs than prove them correct. 
 Occasionally they actually run them on physical machines, and it's 
sometimes kind of fun to have them produce output of some sort.

Eric Pepke                                    INTERNET: pepke@gw.scri.fsu.edu
Supercomputer Computations Research Institute MFENET:   pepke@fsu
Florida State University                      SPAN:     scri::pepke
Tallahassee, FL 32306-4052                    BITNET:   pepke@fsu

Disclaimer: My employers seldom even LISTEN to my opinions.
Meta-disclaimer: Any society that needs disclaimers has too many lawyers.