On Friday, June 5, 2015 at 3:46:47 AM UTC+5:30, Steven D'Aprano wrote: > On Fri, 5 Jun 2015 03:26 am, random832 wrote: > > If the value really were 23, the "is vs ==" problem wouldn't exist. > > What "problem"? "is versus ==" is not a problem, it is a feature. The two > operators do two different things. > > But I am *astonished* that you think that the value of x after x = 23 is not > 23. If it's not 23, then what is it? > > (Actually, I'm not that astonished. There are some kinds of foolishness that > only really smart people can fall for.)
Yeah some rather smart people... http://en.wikipedia.org/wiki/BLISS#Language_description [See the part on 'reference to a variable'] In C in x = y x is l-value y is r-value and the choice of which attribute to select is context-sensitive. In this regimen it is uniform and straightforward, variable only ever means l-value. r-value is obtained with a dot-operator '.x' So the usual C's x = y in Bliss is x = .y [BTW the lead to the wikipedia article describes Bliss as the best known system programming language till C made its debut] Also I believe Algol-68 similarly uniformed variable refs but in the opposite direction [if I understand it right] C's x = y becomes in Algol-68 ref x := y [Admittedly the Algol-68 docs are too dense for me so I may be misunderstanding] In any case my points 1. C's context sensitive variables is quite strange. Even if (in 2015) its the universally acceptped norm there were more intelligent/intelligible times... 2. If you think is vs == is not a problem, you are not paying attention to the repeated arguments/confusions around that subject [The cognoscenti argue, the ignoramuses are confused. Its probably the other way round -- the ignorants' displayed confusion probably indicates the cognoscenti's real confusion 3. Functional programming choice to throw the baby out with the bathwater -- no assignment, no mutation -- is extreme but not unfounded -- https://mail.python.org/mailman/listinfo/python-list
