Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #27403 > unrolled thread

Re: The Assignment Principle

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#27403 — Re: The Assignment Principle

On 1/26/2014 12:17 PM, Stefan Ram wrote:
>    Also, it is
>    about values and not expressions, so that
>
> v = java.lang.Math.random();


Well, most often it is about expressions:

   a = 2;
   b = 1;
   v = a * a + b;
   System.out.println( v == 5 );

Had darn well better print 'true';

Math.random() is kind of an exception, as well as NaN, which has its own 
semantics for comparisons.

It's fair to point out that objects have states, and method invocation 
often returns different values based on their internal state.

   InputStream in = ...
   v = in.read();

Is going to return a different value for each invocation, generally 
speaking.

We're getting into the difference between traditional languages, which 
do have state, and functional languages, which try to avoid mutable 
state whenever possible.  Functional languages try to mimic the behavior 
of algebra and mathematics, so that's why they look a lot closer the 
mathematical formulas and properties you are used to from that field.

But Java isn't functional programming, and those properties you learned 
for algebra aren't going to always work here.  Thus, learning Java 
involves learning a new set of rules, not trying to make Java work like 
the other set of rules.

[toc] | [next] | [standalone]

#27408

On 26.01.2014 23:27, markspace wrote:

> Math.random() is kind of an exception, as well as NaN, which has its own
> semantics for comparisons.
>
> It's fair to point out that objects have states, and method invocation
> often returns different values based on their internal state.
>
>    InputStream in = ...
>    v = in.read();
>
> Is going to return a different value for each invocation, generally
> speaking.

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.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#27410

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.

[toc] | [prev] | [next] | [standalone]

#27421

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().

Kind regards

robert

[toc] | [prev] | [next] | [standalone]

#27422

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.

[toc] | [prev] | [next] | [standalone]

#27409

On Sunday, January 26, 2014 2:27:13 PM UTC-8, markspace wrote:
> On 1/26/2014 12:17 PM, Stefan Ram wrote:
> 
> >    Also, it is
> 
> >    about values and not expressions, so that
> 
> >
> 
> > v = java.lang.Math.random();
> 
> 
> 
> 
> 
> Well, most often it is about expressions:
> 
> 
> 
>    a = 2;
> 
>    b = 1;
> 
>    v = a * a + b;
> 
>    System.out.println( v == 5 );
> 
> 
> 
> Had darn well better print 'true';
> 
> 

I don't think this fits the definition. "5" is not the assigned value.
The test should be
   v == (a * a + b)

Consider
 double a = 2.3;
 double b = 1.1;
 double c = a + b;

Then the test
  c == 3.4
may or may not be true.
However, the test
  c == (a+b)
should be true.

-- 
Fred K



(snip)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web