# Butt ugly - Page 2

•  Subject
• Author
• Posted on

## Re: Butt ugly

Oli Filth wrote:

I admit I should have read more precise. I have now looked up the word
commutative in the dictionary (damned english), and you can scratch most of
the above remark....

"related" is rather undefined here. I could make a case either way why + and
* are related, and why they are not, depending on what relation you're

If one oversimplifies things, one could say adding (concating) strings is a
lot like adding numbers. Intuitively, you'd think that "hello" + "world" =
"helloworld" (which in some languages, it is). Because of PHP's ability to
cast variables on the fly there had to be another operator, so the operation
either used numerical value or strings. That might be the reason for the
same precedence. I'm not saying they are the same.

It's just a simple fact of knowing/learning that the . has the same
precedence. Once, when we were little, we learned + & - had the same in
math, en / & * also the same. How hard is it to learn that . has the same
precedence as + & -?

And like I said earlier: when either getting confused, or wanting to
increase readability, brackets are the way to go. They don't HAVE to be
necessary to use them.

Grtz,
--
Rik Wasmus

## Re: Butt ugly

Rik said the following on 28/05/2006 15:58:

Well, are intrinsically related as follows:
Adopting mathematical notation here, if we define:
f(x,c) = x + c
g(x,c) = x - c
then clearly:
f(,c) = g(,c)^-1
i.e. they're inverse operations.

A similar intrinsic relationship holds for .

No such magic exists for as far as I know.

To be honest, this is the only reason I can think of as well, that
concatenation is "a bit like" addition.  Except it's not really, due to
the issue of commutativity, and the fact that there's no inverse
operation.  Also, this logic implies that is related to , which
clearly isn't the case...

I'm not saying it's hard to learn; what I'm saying is that it's
unintuitive, because IMO the choice of its precedence is arbitrary.  For
example, the code in my previous post leads to completely unintuitive
behaviour, IMO.

--
Oli

## Re: Butt ugly

Oli Filth wrote:

"Related" is a loose term. The logical operators are sort of related
too, but they are have different precedence. One way to look at it is
that we want to preserve linearity at a given precedence level. Say we
have the express 1 + 3 - 5 + 7. We can think of it as the transform
(+3), (-5), and (+7) on the vector (1). These transforms can be applied
at any order. Likewise when we have 5 * 6 / 10, we can do either the
multiplication or the division first without affecting the result. Now
if we look at 0 & 0 | 1. Performing (&0) first yields 1, while doing
(|1) first yields 0.

Probably has something to do with + being overloaded for strings in
PHP's early days. I don't see any harm though in splitting . out to its
own level. Who in their right mind would do a string concatenation only
to have the result destroyed by the math operation?

## Re: Butt ugly

Rik wrote:

Well, I didn't say - or / is communtative. Substraction and division
are derived from addition and multiplication. The latters are
fundamental operation and you want to preserve their properties since
they underpin everything else.

It's been ages since I took linear algebra, but I remember correctly,
you have a proper vector space only if

2. There is a zero vector such that A + 0 = A
3. Multiplication is communtative
4. There is a unity vector such that 1 x A  = A

If addition is not communtative, you end up with non-linear math.

String concatenation is not communtative and it's not associative with

No, you're saying it. Unless we've entered an alternative universe
where logic doesn't matter, the statement "addition is communtative"
does not imply "substraction is communtative."

## Re: Butt ugly

Chung Leong wrote:

My humble apologies, I should have taken out the english dictionary a bit
sooner in this discussion, allthough mine states it should be commutative,
not communtative.

Grtz,
--
Rik Wasmus

## Re: Butt ugly

'string'

...but that's not how the precedence is defined, the '*' multiplication has

are taliking about two different things.  The '.' operator is NOT

"0." . 7 + 5 =
"0.7" + 5 =
5.7

since in this example the '.' is encountered first it must act on what it
knows and it knows what is to the immediate left and immediate right and
that is a 'string' and a number.  The number 7 is converted to a string and
CONCATED to "0." making "0.7", then the '+' is encountered and it applies
itself to "0.7" and 5 resulting in a number whos value is 5.7 because the
string contains no leading alpha characters is converted to a number
(float/double) for the ADDITION process resulting in .7 + 5 = 5.7

...if you want the same answer then you must tell PHP how to handle the
precedence, so in this case you want to separate the math from the string
concatination:

".0" . (7 + 5) = "0.12"

(7 + 5) will always be computed as a single unit.

The bottom line is this... precedence can only 'guess' so much as to what
you the programmer wants and it normally does a great job.  But when you
start mixing two different functions ('.' and '+') it has to make
assumptions, and those assumptions are to work on what is immediately known
and that is what is to the immediate left and right:

\$str = 'C' . 'A' . 'T';

is computed/concated by:

\$str = 'C' . 'A' . 'T';
\$str = 'CA' . 'T';
\$str = 'CAT';

and...

\$str = 'C' . 'A' . 'T' + 100;
\$str = 'CA' . 'T' + 100;
\$str = 'CAT' + 100;
\$str = 0 + 100;
\$str = 100;

... the '+' ADDition function causes non-numeric strings to be zero (0)

and...

\$str = 'C' . 'A' . 'T' . 100;
\$str = 'CA' . 'T' . 100;
\$str = 'CAT' . 100;
\$str = 'CAT100';

... the '.' CONCATination function causes type conversion

http://us3.php.net/manual/en/language.operators.php#language.operators.precedence

Norm

## Re: Butt ugly

Norman Peelman wrote:

I'm sorry but you're missing the entire point of the discussion. The
point is that the ambiguity is illogical and should not exist. To use
your terminology, apples are apples, oranges are oranges. Putting them
all in one bin and then guess at what you've got is stupid.

## Re: Butt ugly

what
known

So, what would you want to happen?  Should the parser go through each
entire string looking for math equations first then string everything
together after.  I'm thinking that the problem is probably the loose type
casting of the language.  I'm thinking that under normal circumstances math
is not normally done within a string.

Normally: (oldskool, no mistake as to what is expected)

\$sum = 7 + 7;
\$str = 'sum = ';
echo \$str , \$sum;

outputs:

sum = 14

...so there you have it, no ambiguity.  Ambiguity only comes into play when
programmers use tricky/bad programming practices because PHP will 'attempt'
to give them what they want.  Ambiguity comes into play when new programmers
who haven't rtfm/googled/etc. rely on code snippets found here and there to
piece together something they barely understand to begin with.  PHP is meant
to be learned easily (but not meant to teach programming knowledge/habits)
by allowing leeway in programming style.  This leeway allows

The bottom line is that '.' and '+' are/were not really meant to be used at
the same time as one works with strings and one works with mathematics. So
normally there would be no ambiguity. Type casting 'allows' it to be done so
that someone who has an understanding of what's going on can proceed without
having to use/write functions to convert strings and numbers back and forth.

If you want:

\$a = 'If you multiply ' + 2 + 5 + 3 + ' by ' + 2 * 5 + ' you get ' + 10 *
10;

then you're asking too much of one operator let alone the parser.

---
Norm

## Re: Butt ugly

Norman Peelman said the following on 29/05/2006 00:05:

Who has suggested anything of the sort?

Says who?

There's no ambiguity; the behaviour is well-defined.  However, there
*is* unintuitive behaviour.

Assuming you mean "overload to do both string concatenation and
addition", then you may well be right, it probably wouldn't be possible
to come up with a sensible precedence scheme so that the above example
gave the same result as:

\$a = 'If you multiply ' . (2 + 5 + 3) . ' by ' . (2 * 5) . ' you get ' .
(10 * 10);

talking about is the operator precedence in PHP being unintuitive.  If
there were an "intuitive" operator precedence (with lower than
), then the code below would give the same result:

\$a = 'If you multiply ' . 2 + 5 + 3 . ' by ' . 2 * 5 . ' you get ' . 10
* 10;

--
Oli

## Re: Butt ugly

you
at

Doesn't the fact that there are two different functions suggest that?

true...

*

Got it...

Norm

## Re: Butt ugly

Norman Peelman wrote:

I have been saying the same thing and you keep missing it: the concat
operator should have its own precedence, lower than that of addition
and subtraction. What it involves is changing the line in the parser
definition from

%left '+' '-' '.'

to

%left '.'
%left '+' '-'

Now when the parser encounters "two plus two makes" . 2 + 2, it'll see
that the plus sign has higher precedence than the period (it's lower in
the definition) and will thus process it first.

Got it?

type
math

I got it...

Norm

## Re: Butt ugly

Norman Peelman wrote:

I think that's the major point here:
typecasting vs. clear operations

One excludes the other in may occasions. PHP is very forgiving, allowing
floats, expontentials etc, but eval()ing strings using some mathmetical
parser before mathmatical equasions is to much to ask.

If one wants a pure, clear language, the parser should break at the
operations stated eralier, issuing a warning that 'something' isn't an
number (float, integer etc.), or 'something' isn't a string.

That would have a purity I can appreciate, allthough always casting posted,
get, database queried, filtered, or however one gets data, to a number will
be such a big pain, I do think PHP has it right with introducing some
leniency. The distance that leniency goes is the programmers responsibility
to learn, the consequences of that leniency are the programmers choice.

Grtz,
--
Rik Wasmus

## Re: Butt ugly

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rik G. wrote:

It's called "operator precedente and automatic type casting":

Explicit operator precedence:

echo ("2 + 2 = " . 2) + 2;
echo ("2 + 2 = 2") + 2;

Wait, there is a sum operator over there, both operands must be
scalar-typed:

echo ( (int) "2 + 2 =2") + 2;

And, if you RTFM about casting a string to integer:

echo ( 2 ) + 2;

- --
- ----------------------------------
Iván Sánchez Ortega -i-punto-sanchez--arroba-mirame-punto-net

http://acm.asoc.fi.upm.es/~mr/
Proudly running Debian Linux with 2.6.15-1-686 kernel, KDE3.5.0, and PHP
5.1.2-1+b1 generating this signature.
Uptime: 14:47:44 up 30 min,  1 user,  load average: 0.88, 1.55, 1.32

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEeEsj3jcQ2mg3Pc8RAncbAKCAGbEAAgvBM/kyWYPN09nsptoozgCfZLMF
nGAewVd/7NJZGPbHLwUSWhQ=
=B+Vj
-----END PGP SIGNATURE-----

## Re: Butt ugly

I use ( and )
And yeah, it's confusing when I use PHP with JavaScript.