Groups > comp.lang.java.programmer > #27422

Re: The Assignment Principle

Path	csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From	Jussi Piitulainen <jpiitula@ling.helsinki.fi>
Newsgroups	comp.lang.java.programmer
Subject	Re: The Assignment Principle
Date	29 Jan 2014 16:24:16 +0200
Organization	A noiseless patient Spider
Lines	41
Sender	jpiitula@ruuvi.it.helsinki.fi
Message-ID	<qot7g9ig92n.fsf@ruuvi.it.helsinki.fi> (permalink)
References	<assignment-principle-20140126210852@ram.dialup.fu-berlin.de> <lc4243$fqg$1@dont-email.me> <bknkjeF14acU1@mid.individual.net> <lc6jb6$2ke$1@dont-email.me> <70064b51-a920-4ab8-a2fc-4d3f7eb68026@googlegroups.com>
Mime-Version	1.0
Content-Type	text/plain; charset=us-ascii
Injection-Info	mx05.eternal-september.org; posting-host="da42b2e96e23bc971f06525f495b78b4"; logging-data="29735"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19GLkVuBMTtK5aEFHz3EB2S1EzY1Xz8fBk="
User-Agent	Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Cancel-Lock	sha1:zPdxgQRKjzH9npcrQqvuG1zb1l8=
Xref	csiph.com comp.lang.java.programmer:27422

Show key headers only | View raw

Robert Klemme writes:

> On Monday, January 27, 2014 10:33:25 PM UTC+1, markspace wrote:
> > On 1/27/2014 9:50 AM, Robert Klemme wrote:
> > 
> > > That's why I would disagree calling Math.random() an exception.
> > > So basically the original quoted principle can only reasonably
> > > apply to values (object references and primitive type values).
> > > And there NaN is really an exception.
> > 
> > Too many exceptions mean that the rule is wrong, imo.  I'm going
> > to stick with "non-functional languages have their own set of
> > rules" and not try to shoe-horn Java into a functional mindset and
> > end up with a bunch of exceptions to each and every rule of
> > functional programming.
> 
> I was not under the impression that someone wanted to force a
> functional mindset into Java.  I took the "assignment principle just
> for what was posted.  All I am saying is that if one holds this up
> it cannot be claimed for arbitrary expressions but really only
> values on the right hand side (primitive type values or references).
> That would not make Math.random() one of a few exceptions but _all_
> expressions involving method calls.  Maybe I just misread your
> comment to restrict exception to Math.random().

I'm not quite used to assignment statements in functional programming,
but I think I did learn this rule in terms of expressions: after an
assignment, the value of the variable is the value of the expression
*with the previous value of the variable substituted to the variable
itself*. There may have been an auxiliary variable to hold the value -
probably there was.

// v == v0
v = f(v);
// v == f(v0)

Probably v != f(v0) at this point. Certainly even after c = c + 1; it
is the case that c != c + 1.

This does assume that expressions, including function calls, don't
have side effects that affect their value.

Thread

Re: The Assignment Principle markspace <markspace@nospam.nospam> - 2014-01-26 14:27 -0800
  Re: The Assignment Principle Robert Klemme <shortcutter@googlemail.com> - 2014-01-27 18:50 +0100
    Re: The Assignment Principle markspace <markspace@nospam.nospam> - 2014-01-27 13:33 -0800
      Re: The Assignment Principle Robert Klemme <shortcutter@googlemail.com> - 2014-01-29 06:10 -0800
        Re: The Assignment Principle Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-01-29 16:24 +0200
  Re: The Assignment Principle FredK <fred.l.kleinschmidt@gmail.com> - 2014-01-27 12:04 -0800

csiph-web