Butt ugly

[Rik G.]

Coming from an Assembler/C/C++/C# background I got to say this is butt ugly:

<?php
echo "2 + 2 = " . 2+2; // This will print 4
echo "2 + 2 = " , 2+2; // This will print 2 + 2 = 4
echo "test " . 2+2; // This will print 2
?>

R.

[Jerry Stuckle]

Rik G. wrote:

Coming from an Assembler/C/C++/C# background I got to say this is butt ugly:

<?php
echo "2 + 2 = " . 2+2; // This will print 4
echo "2 + 2 = " , 2+2; // This will print 2 + 2 = 4
echo "test " . 2+2; // This will print 2
?>

R.

Not if you understand precedence. Remember, '.' has a high precedence. The
following all work:
<?php
echo "2 + 2 = " . (2+2); // This will print 2 + 2 = 4
echo "2 + 2 = " , (2+2); // This will print 2 + 2 = 4
echo "test " . (2+2); // This will print test 4
?>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Rik G.]

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:pb********************@comcast.com...

Rik G. wrote:

Coming from an Assembler/C/C++/C# background I got to say this is butt ugly:
<?php
echo "2 + 2 = " . 2+2; // This will print 4
echo "2 + 2 = " , 2+2; // This will print 2 + 2 = 4
echo "test " . 2+2; // This will print 2
?>

R.
Not if you understand precedence. Remember, '.' has a high precedence.

The following all work:
<?php
echo "2 + 2 = " . (2+2); // This will print 2 + 2 = 4
echo "2 + 2 = " , (2+2); // This will print 2 + 2 = 4
echo "test " . (2+2); // This will print test 4
?>

OK, thanks, that looks better but still: why does it eat the strings "2 + 2
= " and "test " in case 1 and 3?

And here's for something even but uglier:

echo "2 + 2 = " . 2+3; // This will print 5
echo "2 + 2 = " , 2+3; // This will print 2 + 2 = 5
echo "test " . 2+3; // This will print 3

[Rik]

Jerry Stuckle wrote:

Rik G. wrote:

Coming from an Assembler/C/C++/C# background I got to say this is
butt ugly:

<?php
echo "2 + 2 = " . 2+2; // This will print 4
echo "2 + 2 = " , 2+2; // This will print 2 + 2 = 4
echo "test " . 2+2; // This will print 2

Not if you understand precedence. Remember, '.' has a high
precedence. The following all work:
<?php
echo "2 + 2 = " . (2+2); // This will print 2 + 2 = 4
echo "2 + 2 = " , (2+2); // This will print 2 + 2 = 4
echo "test " . (2+2); // This will print test 4

Not only precedence, type juggling also plays a major part here.
Detailed:

echo "2 + 2 = " . 2+2; // This will print 4
1. The string "2 + 2 = " becomes "2 + 2 = 2" (indeed precedence).
2. Trying to add a number to this string casts it to 2 (the first number),
and adds 2, so gives 4.
echo "2 + 2 = " , 2+2; // This will print 2 + 2 = 4
The string "2 + 2 = " gets echoed seperately from the integer resulting from
adding 2+2
echo "test " . 2+2; // This will print 2

1. The string "test " becomes "test 2".
2. Trying to add the number 2 to "test 2" casts the string to an integer
(0), and adding 2 gives indeed 2

Variable variables, without strict type, are a blessing in some cases, in
others it's immensely irritating. You just have to keep an eye on it :-).

Reading material:
http://nl3.php.net/manual/en/languag...e-juggling.php
http://nl3.php.net/manual/en/language.operators.php
Table 15-1

When in doubt, cast the piece of code to a certain type by (type) (e.g.
(bool), (string), (int) etc.).

Grtz
--
Rik Wasmus

[Rik G.]

"Rik" <lu************@hotmail.com> wrote in message
news:de***************************@news1.tudelft.n l...

[Snip]

Not only precedence, type juggling also plays a major part here.
Detailed:

echo "2 + 2 = " . 2+2; // This will print 4
1. The string "2 + 2 = " becomes "2 + 2 = 2" (indeed precedence).
2. Trying to add a number to this string casts it to 2 (the first number),
and adds 2, so gives 4.
echo "2 + 2 = " , 2+2; // This will print 2 + 2 = 4
The string "2 + 2 = " gets echoed seperately from the integer resulting from adding 2+2
echo "test " . 2+2; // This will print 2

1. The string "test " becomes "test 2".
2. Trying to add the number 2 to "test 2" casts the string to an integer
(0), and adding 2 gives indeed 2

Variable variables, without strict type, are a blessing in some cases, in
others it's immensely irritating. You just have to keep an eye on it :-).

OK, it's clear now (but still butt ugly).
Thanks for the explanation.

R.

[Rik]

Rik G. wrote:

OK, thanks, that looks better but still: why does it eat the strings
"2 + 2 = " and "test " in case 1 and 3?
See my other post.
And here's for something even but uglier:

echo "2 + 2 = " . 2+3; // This will print 5
1. String "2 + 2 = ".
2. String "2 + 2 = 2".
3. Gets cast to an integer because of +, which results in the first number:
integer "2".
4. Integer 2 + Integer 3 = 5
echo "2 + 2 = " , 2+3; // This will print 2 + 2 = 5
1. String "2 + 2 = " get's echoed seperately.
2. Calculation 2+3 is performed.
3. Integer 5 is echoed seperately (the , operator is way, way down the
precedence list).
echo "test " . 2+3; // This will print 3

1. String "test ".
2. String "test 2".
3. String gets cast to an integer, the first character is not a number or
'-' followed by a number, so gets cast to integer 0.
4. 0+3 = 3

Grtz,
--
Rik Wasmus

[Iván Sánchez Ortega]

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

Rik G. wrote:

Coming from an Assembler/C/C++/C# background I got to say this is butt
ugly:
It's called "operator precedente and automatic type casting":
<?php
echo "2 + 2 = " . 2+2; // This will print 4

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-----

[Bent Stigsen]

Rik G. wrote:

"Rik" <lu************@hotmail.com> wrote in message
news:de***************************@news1.tudelft.n l...

[snip]

echo "test " . 2+2; // This will print 2

1. The string "test " becomes "test 2".
2. Trying to add the number 2 to "test 2" casts the string to an integer
(0), and adding 2 gives indeed 2

Variable variables, without strict type, are a blessing in some cases, in
others it's immensely irritating. You just have to keep an eye on it :-).

OK, it's clear now (but still butt ugly).

It was your choice to write it like that. If you don't want the
freedom to write something so badly, then don't use a language that
lets you do it.

It's like that doctor/patient-joke:

[Patient]: doctor, it hurts when I do this.
[Doctor] : then don't do that.
/Bent

[snip]

[Chung Leong]

Jerry Stuckle wrote:

Not if you understand precedence. Remember, '.' has a high precedence. The
following all work:

The . operator has the same precedence as + and -, the wisdom of which
is debatable. I don't think it's intuitive that

echo 2+2 . ' = 2 + 2';

prints out '4 = 2 + 2' while

echo '2 + 2 = ' . 2+2;

prints out 4.

[Rik]

Chung Leong wrote:

Jerry Stuckle wrote:

Not if you understand precedence. Remember, '.' has a high
precedence. The following all work:

The . operator has the same precedence as + and -, the wisdom of which
is debatable. I don't think it's intuitive that
echo 2+2 . ' = 2 + 2';
prints out '4 = 2 + 2' while
echo '2 + 2 = ' . 2+2;
prints out 4.

The only thing WHY this isn't intuitive is because of the irregular use of
spaces. Why surround the . by spaces, and not the +? You're only making
thinks blurry for yourself.

Typing:
echo 2 + 2 . ' = 2 + 2';
echo '2 + 2 = ' . 2 + 2;
... is a lot clearer.

Further, it's like any Western language: we read from left to right. If
precedence doesn't sort it out, it's processed as you write. Type juggle
necessary for the last operations stands. It seems very logical to me. What
can make it confusing, is the fact that the string contains characters that
could be operators. That could throw you of, just because you expect
something that you know since you were 6.

Let's say $text = "2 + 2 = " or " = 2 + 2"

echo 2 + 2 . $text;
echo $text . 2 + 2;

It just makes sense to me....

Grtz,
--
Rik Wasmus

[Chung Leong]

Rik wrote:

Further, it's like any Western language: we read from left to right. If
precedence doesn't sort it out, it's processed as you write. Type juggle
necessary for the last operations stands. It seems very logical to me. What
can make it confusing, is the fact that the string contains characters that
could be operators. That could throw you of, just because you expect
something that you know since you were 6.
That's sort of my point. Precedence should determine the outcome
instead the order of the operators. Giving operators that are
fundamentally different the same precedence is confusing, because
people tend to group operations they consider similiar together in
their mind. Can you imagine how confusing it would be if + and == has
the same precdence? Quickly, what's the result of the following:

2 + 2 == 1 + 3
Let's say $text = "2 + 2 = " or " = 2 + 2"

echo 2 + 2 . $text;
echo $text . 2 + 2;

It just makes sense to me....

Well, it didn't make sense to the other Rik ;-)

[Norman Peelman]

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:11**********************@j55g2000cwa.googlegr oups.com...

Rik wrote:

Further, it's like any Western language: we read from left to right. If
precedence doesn't sort it out, it's processed as you write. Type juggle
necessary for the last operations stands. It seems very logical to me. What can make it confusing, is the fact that the string contains characters that could be operators. That could throw you of, just because you expect
something that you know since you were 6.

That's sort of my point. Precedence should determine the outcome
instead the order of the operators. Giving operators that are
fundamentally different the same precedence is confusing, because
people tend to group operations they consider similiar together in
their mind. Can you imagine how confusing it would be if + and == has
the same precdence? Quickly, what's the result of the following:

2 + 2 == 1 + 3

Let's say $text = "2 + 2 = " or " = 2 + 2"

echo 2 + 2 . $text;
echo $text . 2 + 2;

It just makes sense to me....

Well, it didn't make sense to the other Rik ;-)

It makes sense because as soon as you try to ADD a number to a 'string'
(or a 'string' to a 'string'), the strings are lost (counted as zero):

echo 'A + B = ' . 'A' + 'B';

will output zero (0)
'A + B = ' . 0 + 0 = 0
0 . 0 = 0
0 = 0

echo 'A + B = ' . 'A' + 'B' + 100;

will output 100 (0 + 100)
'A + B = ' . 0 + 0 + 100 = 100
0 . 0 + 100 = 100
0 + 100 = 100
100 = 100

echo 'A + B = ' . 100;

will output A + B = 100
as the number is converted to string for concatination NOT addition. It's
not really about precidence at all as no math is done within quoted strings
(literals).

....but, you can:

echo 'A + B = ' . ('100' + '200') --> A + B = 300
echo 'A + B = ' . ('100A' + '200B') --> A + B = 300

but not...

echo 'A + B = ' . ('A100' + '200B') --> A + B = 200
'A100' is converted to zero (0)

Norm

[Oli Filth]

Norman Peelman said the following on 28/05/2006 03:45:

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:11**********************@j55g2000cwa.googlegr oups.com...

Rik wrote:

Let's say $text = "2 + 2 = " or " = 2 + 2"

echo 2 + 2 . $text;
echo $text . 2 + 2;

It just makes sense to me.... Well, it didn't make sense to the other Rik ;-)

It makes sense because as soon as you try to ADD a number to a 'string'
(or a 'string' to a 'string'), the strings are lost (counted as zero):

echo 'A + B = ' . 'A' + 'B';

will output zero (0)
'A + B = ' . 0 + 0 = 0
0 . 0 = 0
0 = 0

Actually, that's doing:
'A + B = ' . 'A' + 'B'
'A + B = A' + 'B'
0 + 0
0

(the . is evaluated first, due to left associativity.)

echo 'A + B = ' . 'A' + 'B' + 100;

will output 100 (0 + 100)
'A + B = ' . 0 + 0 + 100 = 100
0 . 0 + 100 = 100
0 + 100 = 100
100 = 100
Similarly for this one.

It's
not really about precidence at all as no math is done within quoted strings
(literals).

It's *all* about precedence (and associativity, indirectly), and that's
the point Chung was making.

The fact that the examples all contain things like "A + B = " is
irrelevant, and just confusing things...

--
Oli

[Chung Leong]

Norman Peelman wrote:

It makes sense because as soon as you try to ADD a number to a 'string'
(or a 'string' to a 'string'), the strings are lost (counted as zero):

You might as well argue that 1 + 2 * 3 should equal 9. "As soon as you
add 2 to 1, you get 3..."

Addition and multiplication are communtative operations. 1 + 6 = 6 + 1
and 2 * 3 = 3 * 2. Thanks to precedence, they maintains their
properties in more complex expression: 1 + 2 * 3 = 1 + 3 * 2 = 3 * 2 +
1.

In PHP, because . and + have the same precedence, addition is no longer
communtative: "0." . 7 + 5 yields a different result from "0." . 5 +
7. So if you will, please explain how violating elementary mathematical
principles makes sense.

[the DtTvB]

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

[Rik]

Chung Leong wrote:

Norman Peelman wrote:

It makes sense because as soon as you try to ADD a number to a
'string' (or a 'string' to a 'string'), the strings are lost
(counted as zero):

You might as well argue that 1 + 2 * 3 should equal 9. "As soon as
you add 2 to 1, you get 3..."

Addition and multiplication are communtative operations. 1 + 6 = 6 + 1
and 2 * 3 = 3 * 2. Thanks to precedence, they maintains their
properties in more complex expression: 1 + 2 * 3 = 1 + 3 * 2 = 3 * 2 +
1.

In PHP, because . and + have the same precedence, addition is no
longer communtative: "0." . 7 + 5 yields a different result from
"0." . 5 +
7. So if you will, please explain how violating elementary
mathematical principles makes sense.

Order matters, even in math.
5 - 7 != 7 - 5

Actually, '.' & '+' are kin of the same operator, but for different types.
It adds the piece on the right to the piece on the left. When '.', it
handles it like a string, when '+', it handles it like a number. We're back
to type juggling here, and using "0." as a string here is just making things
blurry.

Your reasoning has another flaw, for instance: in math '-' & '+' have the
same precendence, and you're actually saying:
2 + 2 - 3 (1)
should equal
3 - 2 + 2 (3)
or
2 - 3 + 2 (1)
depending on wether you decide the - or the + has precedence.

Thinking about it some more I think it boils down to this:
People know 'simple' symobls like * / + - form an earl age. Later on, they
will learn some more colpex opertors like log/ln/raising to a power.

For some bizar reason, they are not willing to accept a 'complex' operation
like 'take the literal symbolw of the right-part, and add those symbols to
the right of the left part' to be a dot (.), and they expect some kind of
precedence, while between / and * there is none, and + and - there is none,
and people just read from left to right.

Don't you think it's strange that when handling just strings, there is
little to no confusion, but as soon as number play a part all hell breaks
loose? It's just a lack of abstract thinking IMO.

Grtz,
--
Rik Wasmus

[Norman Peelman]

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:11**********************@j55g2000cwa.googlegr oups.com...

Norman Peelman wrote:

It makes sense because as soon as you try to ADD a number to a 'string' (or a 'string' to a 'string'), the strings are lost (counted as zero):
You might as well argue that 1 + 2 * 3 should equal 9. "As soon as you
add 2 to 1, you get 3..."

....but that's not how the precedence is defined, the '*' multiplication has
higher precedence than '+' addition.

Addition and multiplication are communtative operations. 1 + 6 = 6 + 1
and 2 * 3 = 3 * 2. Thanks to precedence, they maintains their
properties in more complex expression: 1 + 2 * 3 = 1 + 3 * 2 = 3 * 2 +
1.

In PHP, because . and + have the same precedence, addition is no longer
communtative: "0." . 7 + 5 yields a different result from "0." . 5 +
7. So if you will, please explain how violating elementary mathematical
principles makes sense.

Your 'mathematical' examples are correct. Your last example is not... you
are taliking about two different things. The '.' operator is NOT
mathematical addition. The last example provides the correct answers:

"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/languag...ors.precedence

Norm

[Rik]

Hm,

my apologies for the terrible spelling throughout that post.
Once I get excited my english tends to suffer :-)

Grtz,
--
Rik Wasmus

[Norman Peelman]

"Oli Filth" <ca***@olifilth.co.uk> wrote in message
news:8f*****************@newsfe3-gui.ntli.net...

Norman Peelman said the following on 28/05/2006 03:45:

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:11**********************@j55g2000cwa.googlegr oups.com...

Rik wrote:
Let's say $text = "2 + 2 = " or " = 2 + 2"

echo 2 + 2 . $text;
echo $text . 2 + 2;

It just makes sense to me....
Well, it didn't make sense to the other Rik ;-)

It makes sense because as soon as you try to ADD a number to a 'string' (or a 'string' to a 'string'), the strings are lost (counted as zero):

echo 'A + B = ' . 'A' + 'B';

will output zero (0)
'A + B = ' . 0 + 0 = 0
0 . 0 = 0
0 = 0

Actually, that's doing:
'A + B = ' . 'A' + 'B'
'A + B = A' + 'B'
0 + 0
0

(the . is evaluated first, due to left associativity.)

You are correct, and that was my intention to show that basically the 'A' +
'B' (right side of = sign) evaluated to 0 at some point; 'B' = 0...

It's
not really about precidence at all as no math is done within quoted strings (literals).

It's *all* about precedence (and associativity, indirectly), and that's
the point Chung was making.

The fact that the examples all contain things like "A + B = " is
irrelevant, and just confusing things...

True!

The big problem I think is that Chung is comparing apples to oranges. The
'+' function causes non-number strings to be evaluated as zero (0) and the
'.' function causes type conversion. The solution is to pay attention to
what the desired result is and use the '( )' parentheses to force the proper
precedence. See my post to Chung...

Norm

[Oli Filth]

Rik said the following on 28/05/2006 12:22:

Chung Leong wrote:

In PHP, because . and + have the same precedence, addition is no
longer communtative: "0." . 7 + 5 yields a different result from
"0." . 5 +
7. So if you will, please explain how violating elementary
mathematical principles makes sense.
Order matters, even in math.
5 - 7 != 7 - 5

Actually, '.' & '+' are kin of the same operator, but for different types.
It adds the piece on the right to the piece on the left. When '.', it
handles it like a string, when '+', it handles it like a number.

Not sure about that. IMO, it's rather abstract to describe addition and
concatenation as related; they're not really doing the same thing at
all. Not least because concatenation is clearly not commutative.

By this logic, you could say that bitwise-OR is related, and therefore
deserved equal precedence.

We're back
to type juggling here, and using "0." as a string here is just making things
blurry.
I agree with this.

A better example is:

5 * 6 . "Blah" => "30Blah"
"Blah" . 5 * 6 => "Blah30"
but:

5 + 6 . "Blah" => "11Blah"
"Blah" . 5 + 6 => 6

This discrepancy is (more or less) the issue in question.

Thinking about it some more I think it boils down to this:
People know 'simple' symobls like * / + - form an earl age. Later on, they
will learn some more colpex opertors like log/ln/raising to a power.

For some bizar reason, they are not willing to accept a 'complex' operation
like 'take the literal symbolw of the right-part, and add those symbols to
the right of the left part' to be a dot (.), and they expect some kind of
precedence, while between / and * there is none, and + and - there is none,
and people just read from left to right.

Yes, but {+,-} are "related" operations, so you would perhaps expect
them to have similar precedence. Equally, {*,/} are "related", but are
"unrelated" to {+,-}. If {+,-,*,/} all had the same precedence, things
would get messy and unintuitive. Similarly, as {.} is unrelated to any
of them, you would expect it to have a different precedence, but instead
it's given the same precedence as {+,-}.

Personally, I don't find it a problem in practice, as I
instinctively/automatically parenthesise anything where the precedence
is hazy or unclear. However, I'd still be interested to know why the
PHP developers thought that this choice of precedence made sense.

--
Oli

[Norman Peelman]

Second reply...

Norman Peelman said the following on 28/05/2006 03:45:

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:11**********************@j55g2000cwa.googlegr oups.com...

Rik wrote:
Let's say $text = "2 + 2 = " or " = 2 + 2"

echo 2 + 2 . $text;
echo $text . 2 + 2;

It just makes sense to me....
Well, it didn't make sense to the other Rik ;-)

It makes sense because as soon as you try to ADD a number to a 'string' (or a 'string' to a 'string'), the strings are lost (counted as zero):

echo 'A + B = ' . 'A' + 'B';

will output zero (0)
'A + B = ' . 0 + 0 = 0
0 . 0 = 0
0 = 0

Actually, that's doing:
'A + B = ' . 'A' + 'B'
'A + B = A' + 'B'
0 + 0
0

(the . is evaluated first, due to left associativity.)

echo 'A + B = ' . 'A' + 'B' + 100;

will output 100 (0 + 100)
'A + B = ' . 0 + 0 + 100 = 100
0 . 0 + 100 = 100
0 + 100 = 100
100 = 100

Similarly for this one.

It's
not really about precidence at all as no math is done within quoted strings (literals).

It's *all* about precedence (and associativity, indirectly), and that's
the point Chung was making.

The fact that the examples all contain things like "A + B = " is
irrelevant, and just confusing things...

....second reply, not to mention that the original posters example:

<?php
echo "2 + 2 = " . 2+2; // This will print 4
echo "2 + 2 = " , 2+2; // This will print 2 + 2 = 4
echo "test " . 2+2; // This will print 2
?>

provides correct results as:

#1 "2 + 2 = " . 2 + 2
= "2 + 2 = 2" + 2
= 2 + 2 <- type conversion causes the string to be evaluated as a
number thereby truncating '+ 2 = 2' leaving the first 2 in the string
= 4

#2 "2 + 2" , 2 + 2
is actaully two separate arguments to the echo function (use of ','), there
is no math or string concatination involed other than the appearance of the
final output

#3 "test" . 2 + 2
= "test2" + 2
= 0 + 2 <- "test2" is assumed to not be a number as the string does not
begin with a number
= 2

Norm

[Norman Peelman]

"Rik" <lu************@hotmail.com> wrote in message
news:99**************************@news1.tudelft.nl ...

Chung Leong wrote:

Norman Peelman wrote:

It makes sense because as soon as you try to ADD a number to a
'string' (or a 'string' to a 'string'), the strings are lost
(counted as zero):
You might as well argue that 1 + 2 * 3 should equal 9. "As soon as
you add 2 to 1, you get 3..."

Addition and multiplication are communtative operations. 1 + 6 = 6 + 1
and 2 * 3 = 3 * 2. Thanks to precedence, they maintains their
properties in more complex expression: 1 + 2 * 3 = 1 + 3 * 2 = 3 * 2 +
1.

In PHP, because . and + have the same precedence, addition is no
longer communtative: "0." . 7 + 5 yields a different result from
"0." . 5 +
7. So if you will, please explain how violating elementary
mathematical principles makes sense.

Order matters, even in math.
5 - 7 != 7 - 5

Actually, '.' & '+' are kin of the same operator, but for different types.
It adds the piece on the right to the piece on the left. When '.', it
handles it like a string, when '+', it handles it like a number. We're

back to type juggling here, and using "0." as a string here is just making things blurry.

But allowed in PHP, a loosely typed language giving great flexibility to the
programmer

Your reasoning has another flaw, for instance: in math '-' & '+' have the
same precendence, and you're actually saying:
2 + 2 - 3 (1)
should equal
3 - 2 + 2 (3)
or
2 - 3 + 2 (1)
depending on wether you decide the - or the + has precedence.

....there are two levels to the precedence rules and basically stated: when
to operators have equal precedence then left to right rules apply unless
otherwise noted.
see:
http://us3.php.net/manual/en/languag...ors.precedence

Thinking about it some more I think it boils down to this:
People know 'simple' symobls like * / + - form an earl age. Later on, they
will learn some more colpex opertors like log/ln/raising to a power.

For some bizar reason, they are not willing to accept a 'complex' operation like 'take the literal symbolw of the right-part, and add those symbols to
the right of the left part' to be a dot (.), and they expect some kind of
precedence, while between / and * there is none, and + and - there is none, and people just read from left to right.

Don't you think it's strange that when handling just strings, there is
little to no confusion, but as soon as number play a part all hell breaks
loose? It's just a lack of abstract thinking IMO.

Grtz,
--
Rik Wasmus

[Rik]

Norman Peelman wrote:

We're back
to type juggling here, and using "0." as a string here is just making
things blurry.

But allowed in PHP, a loosely typed language giving great flexibility
to the programmer

I'm not saying it cannot be done, I'm saying that when you're talking about
abstract standards, using this example only makes it harder to see the
logic. The fact that it can be done in PHP saves the programmer a terrible
amount of coding. A blessing in most cases, sometimes an unwanted effect.

Your reasoning has another flaw, for instance: in math '-' & '+'
have the
same precendence, and you're actually saying:
2 + 2 - 3 (1)
should equal
3 - 2 + 2 (3)
or
2 - 3 + 2 (1)
depending on wether you decide the - or the + has precedence.

...there are two levels to the precedence rules and basically stated:
when
to operators have equal precedence then left to right rules apply
unless otherwise noted.
see:

http://us3.php.net/manual/en/languag...ors.precedence

I know, like I stated earlier:

Further, it's like any Western language: we read from left to right.
If precedence doesn't sort it out, it's processed as you write.

Grtz,
--
Rik Wasmus

[Rik]

Oli Filth wrote:

In PHP, because . and + have the same precedence, addition is no
longer communtative: "0." . 7 + 5 yields a different result from
"0." . 5 +
7. So if you will, please explain how violating elementary
mathematical principles makes sense.
Order matters, even in math.
5 - 7 != 7 - 5

Actually, '.' & '+' are kin of the same operator, but for different
types. It adds the piece on the right to the piece on the left. When
'.', it handles it like a string, when '+', it handles it like a
number.

Not sure about that. IMO, it's rather abstract to describe addition
and concatenation as related; they're not really doing the same thing
at
all. Not least because concatenation is clearly not commutative.

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....
Yes, but {+,-} are "related" operations, so you would perhaps expect
them to have similar precedence. Equally, {*,/} are "related", but
are "unrelated" to {+,-}. If {+,-,*,/} all had the same precedence,
things would get messy and unintuitive. Similarly, as {.} is
unrelated to any
of them, you would expect it to have a different precedence, but
instead
it's given the same precedence as {+,-}.
"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
talking about.

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.
Personally, I don't find it a problem in practice, as I
instinctively/automatically parenthesise anything where the precedence
is hazy or unclear.

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

[Chung Leong]

Rik wrote:

Order matters, even in math.
5 - 7 != 7 - 5
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

1. Addition is communtative
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.
Actually, '.' & '+' are kin of the same operator, but for different types.
It adds the piece on the right to the piece on the left. When '.', it
handles it like a string, when '+', it handles it like a number. We're back
to type juggling here, and using "0." as a string here is just making things
blurry.
String concatenation is not communtative and it's not associative with
addition.
Your reasoning has another flaw, for instance: in math '-' & '+' have the
same precendence, and you're actually saying:
2 + 2 - 3 (1)
should equal
3 - 2 + 2 (3)
or
2 - 3 + 2 (1)
depending on wether you decide the - or the + has precedence.

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."

[Oli Filth]

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

Oli Filth wrote:

Yes, but {+,-} are "related" operations, so you would perhaps expect
them to have similar precedence. Equally, {*,/} are "related", but
are "unrelated" to {+,-}. If {+,-,*,/} all had the same precedence,
things would get messy and unintuitive. Similarly, as {.} is
unrelated to any
of them, you would expect it to have a different precedence, but
instead
it's given the same precedence as {+,-}.
"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
talking about.

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.

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.

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

Personally, I don't find it a problem in practice, as I
instinctively/automatically parenthesise anything where the precedence
is hazy or unclear.

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 + & -?

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

[Chung Leong]

Oli Filth wrote:

Yes, but {+,-} are "related" operations, so you would perhaps expect
them to have similar precedence. Equally, {*,/} are "related", but are
"unrelated" to {+,-}. If {+,-,*,/} all had the same precedence, things
would get messy and unintuitive. Similarly, as {.} is unrelated to any
of them, you would expect it to have a different precedence, but instead
it's given the same precedence as {+,-}.
"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.
Personally, I don't find it a problem in practice, as I
instinctively/automatically parenthesise anything where the precedence
is hazy or unclear. However, I'd still be interested to know why the
PHP developers thought that this choice of precedence made sense.

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?

[Rik]

Chung Leong wrote:

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."

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

[Chung Leong]

Norman Peelman wrote:

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:

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.

[Norman Peelman]

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:11**********************@i40g2000cwc.googlegr oups.com...

Norman Peelman wrote:

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:

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.

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
experienced/advanced programmers to use the language to their advantage.

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

[Oli Filth]

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

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:11**********************@i40g2000cwc.googlegr oups.com...

Norman Peelman wrote:

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: 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.

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.

Who has suggested anything of the sort?

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.
Says who?

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

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.

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);

However, we're not talking about operator overloading. What we're
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

[Chung Leong]

Norman Peelman wrote:

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.

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?

[Rik]

Norman Peelman wrote:

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.

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

[Norman Peelman]

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:11**********************@y43g2000cwc.googlegr oups.com...

Norman Peelman wrote:

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.

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?

I got it...

Norm

[Norman Peelman]

"Oli Filth" <ca***@olifilth.co.uk> wrote in message
news:5q*****************@newsfe1-gui.ntli.net...

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

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:11**********************@i40g2000cwc.googlegr oups.com...

Norman Peelman wrote:
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:
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.

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.

Who has suggested anything of the sort?

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.

Says who?

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

So normally there would be no ambiguity.

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

true...

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.

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);

However, we're not talking about operator overloading. What we're
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;

Got it...

Norm