Velocity Reviews > 1/2 =?

# 1/2 =?

Robert Maas, see http://tinyurl.com/uh3t
Guest
Posts: n/a

 06-28-2005
> From: http://www.velocityreviews.com/forums/(E-Mail Removed)
> c = (float) a/b;

That's bad style of coding. You have a/b really close together with no
spaces, but you have (float) spaced away from it, so it looks visually
like a/b happens first then the quotient is cast to float.
The correct way to punctuate your third case, to make it clear, is :
c = (float)a / b;

Rather than memorizing operator precedence and often making mistakes, I
suggest always using an extra level of parens whenever you're not sure:
c = (float)(a/b); /* Your second case, as you had it */
c = ((float)a)/b; /* Your third case, made more clear here */
If you have enough parens, you don't need any spaces, but to use spaces also:
c = (float) (a/b);
c = ((float)a) / b;
If you use parens, but also use spaces, but the spaces are in the wrong
places for visual effect consistent with parens, you'll get this clash:
c = (float)(a / b);
c = ((float) a)/b;
Just one glance at that last one shows you something is screwed!

The same problem happens with poorly punctuated:
c = a+b / a-b;
which really means:
c = a + (b/a) + b;
but what was really intended was probably this:
c = (a+b) / (a-b);
where parens are needed to make it work as intended.

The whole mess with operator precedence sucks.
If you dislike it as much as I do, use Lisp instead.

By the way, for a C-like language, I wonder why nobody thought of
the idea of having the number of spaces determine the precedence?
Operations with no spacing would be performed first, then operations
with one space, then two etc. Then the following would be correct per
their visual appearance:
c = a+b / a-b;
v = a * x**2 + b * x + c;

Meanwhile, back in C, it would be nice if the compiler would warn about
spacing that is inconsistent with operator precedence.

akarl
Guest
Posts: n/a

 06-28-2005
Robert Maas, see http://tinyurl.com/uh3t wrote:
>>From: (E-Mail Removed)

>
>
>>c = (float) a/b;

>
>
> That's bad style of coding. You have a/b really close together with no
> spaces, but you have (float) spaced away from it, so it looks visually
> like a/b happens first then the quotient is cast to float.
> The correct way to punctuate your third case, to make it clear, is :
> c = (float)a / b;

I agree, but at least in Java I think the general coding style
recommendation is to insert a space after the cast operator (to make it
look more like a declaration).

> Rather than memorizing operator precedence and often making mistakes, I
> suggest always using an extra level of parens whenever you're not sure:
> c = (float)(a/b); /* Your second case, as you had it */
> c = ((float)a)/b; /* Your third case, made more clear here */
> If you have enough parens, you don't need any spaces, but to use spaces also:
> c = (float) (a/b);
> c = ((float)a) / b;
> If you use parens, but also use spaces, but the spaces are in the wrong
> places for visual effect consistent with parens, you'll get this clash:
> c = (float)(a / b);
> c = ((float) a)/b;
> Just one glance at that last one shows you something is screwed!
>
> The same problem happens with poorly punctuated:
> c = a+b / a-b;
> which really means:
> c = a + (b/a) + b;
> but what was really intended was probably this:
> c = (a+b) / (a-b);
> where parens are needed to make it work as intended.
>
> The whole mess with operator precedence sucks.
> If you dislike it as much as I do, use Lisp instead.

Or Oberon-2. It has only four (!) precedence levels: logical not,
multiplicative operators, additive operators and relational operators.

> By the way, for a C-like language, I wonder why nobody thought of
> the idea of having the number of spaces determine the precedence?
> Operations with no spacing would be performed first, then operations
> with one space, then two etc. Then the following would be correct per
> their visual appearance:
> c = a+b / a-b;
> v = a * x**2 + b * x + c;
>
> Meanwhile, back in C, it would be nice if the compiler would warn about
> spacing that is inconsistent with operator precedence.

This is exactly the reason I don't like Python. It's all too easy to
inadvertently delete some whitespace and mess things up.

-- akarl

Chris Croughton
Guest
Posts: n/a

 06-29-2005
On Tue, 28 Jun 2005 14:02:36 -0700, Robert Maas, see http://tinyurl.com/uh3t
<(E-Mail Removed)> wrote:

> That's bad style of coding. You have a/b really close together with no
> spaces, but you have (float) spaced away from it, so it looks visually
> like a/b happens first then the quotient is cast to float.
> The correct way to punctuate your third case, to make it clear, is :
> c = (float)a / b;

Or better

c = (float)a / (float)b;

rather than depend on the implicit conversions. For instance:

c = (float)a / (b/c);

forgetting to convert either b or c to float as well.

> The same problem happens with poorly punctuated:
> c = a+b / a-b;
> which really means:
> c = a + (b/a) + b;
> but what was really intended was probably this:
> c = (a+b) / (a-b);
> where parens are needed to make it work as intended.

Yes, that's standard algebra.

> The whole mess with operator precedence sucks.
> If you dislike it as much as I do, use Lisp instead.

Where it won't be readable at all.

> By the way, for a C-like language, I wonder why nobody thought of
> the idea of having the number of spaces determine the precedence?
> Operations with no spacing would be performed first, then operations
> with one space, then two etc. Then the following would be correct per
> their visual appearance:
> c = a+b / a-b;
> v = a * x**2 + b * x + c;

And what would happen if you edited it to:

v = a * x**2 +b * x + c;

The compiler would have fits.

It may work with simple names like a, b, c etc., but with more complex
ones it would quickly get unwieldy. And its far easier to get wrong
than having a fixed precedence which follows the normal rules of algebra
(apart from things which aren't in normal algebra at all like bit
operators).

> Meanwhile, back in C, it would be nice if the compiler would warn about
> spacing that is inconsistent with operator precedence.

There may be a version of lint which would do it. Every programmer I
know would kill such a warning with extreme prejudice...

Chris C

Walter Roberson
Guest
Posts: n/a

 06-30-2005
In article <(E-Mail Removed)>,
Robert Maas, see http://tinyurl.com/uh3t <(E-Mail Removed)> wrote:
>By the way, for a C-like language, I wonder why nobody thought of
>the idea of having the number of spaces determine the precedence?
>Operations with no spacing would be performed first, then operations
>with one space, then two etc.

The rules for macro expansion would have to change, as would

For example, if in the below, _ represents a space (just for
readability, as trailing spaces are not normally visible)

then at current, leading and trailing spaces on the expansion are
trimmed, making this equivilent to

trailing spaces would become important.

Similarily, the current rule is that a comment is replaces by exactly
one space. Consider

"abc"/*some random comment*/-3

under current rules this is "abc" -3
and that space would become important. But if the rule were
changed so that comments were replaced with no space, then

instead of 3 + 3 +
--
Look out, there are llamas!

CBFalconer
Guest
Posts: n/a

 06-30-2005
Walter Roberson wrote:
>

.... snip ...
>
> Similarily, the current rule is that a comment is replaces by
> exactly one space. Consider
>
> "abc"/*some random comment*/-3
>
> under current rules this is "abc" -3
> and that space would become important. But if the rule were
> changed so that comments were replaced with no space, then
>
>
> instead of 3 + 3 +

That is the way some pre-ansi K&R style compilers worked, and some
took advantage to make a poor mans non-portable ## operator.
Luckily pretty well stamped out.

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.

Robert Maas, see http://tinyurl.com/uh3t
Guest
Posts: n/a

 07-27-2005
> From: akarl <(E-Mail Removed)>
> Or Oberon-2. It has only four (!) precedence levels: logical not,
> multiplicative operators, additive operators and relational operators.

No parentheses and no assignment?? Are you sure?
Does it have any token-level syntax such as string literals etc.?

In any case, Lisp has it beat out, with ony token-level syntax and
parens, no other syntax at all.

Forth has Lisp beat out, not even parens, but that makes Forth code
impossible to visually parse. You know the story of Goldilocks and the
three bears? Lisp is "just right".

akarl
Guest
Posts: n/a

 07-27-2005
Robert Maas, see http://tinyurl.com/uh3t wrote:
>>From: akarl <(E-Mail Removed)>
>>Or Oberon-2. It has only four (!) precedence levels: logical not,
>>multiplicative operators, additive operators and relational operators.

>
> No parentheses and no assignment?? Are you sure?
> Does it have any token-level syntax such as string literals etc.?

Sure, it has all you mention, but assignment is not an operator, it's
part of an assignment statement. Of course, parenthesized expressions
are evaluated first, but that's obvious and not something you have to
remember.

> In any case, Lisp has it beat out, with ony token-level syntax and
> parens, no other syntax at all.

Since this is comp.lang.c I mentioned the simplest *procedural*
language, Oberon-2.

> Forth has Lisp beat out, not even parens, but that makes Forth code
> impossible to visually parse. You know the story of Goldilocks and the
> three bears? Lisp is "just right".

C and Lisp are languages from completely different families.

August

Robert Maas, see http://tinyurl.com/uh3t
Guest
Posts: n/a

 07-29-2005
> From: akarl <(E-Mail Removed)>
> assignment is not an operator

It is in C and C++ and Java and Algol and Basic, or didn't you know
that? It is in Lisp too, but I'm sure you didn't know that because you
don't seem to know much about Lisp.

An assignment expression can even return a value which can be passed as
a rhs to another assignment or even inside a calculation expression. Or
didn't you know that either? Note below the operator precedence whereby
= is looser than +, for example 2 is added to (x=1) and *then* the
result of that is assigned to y:

% more x1.c
main() {
int x; int y; int z;
z = (y = (x = 1) + 2) + 4;
printf("%d %d %d\n", x,y,z);
}
% cc x1.c
% ./a.out
1 3 7

> > In any case, Lisp has it beat out, with ony token-level syntax and
> > parens, no other syntax at all.

> Since this is comp.lang.c I mentioned the simplest *procedural*
> language, Oberon-2.

Are you claiming that Lisp isn't procedural? It most certainly is!
To put this issue to test, you tell me which of the following langauges
are procedural and which are not:
txt html php sh perl python lisp awk f77 c c++ java
Then you write a short (4-7 line) program that can be converted
line-for-line into each of the languages you claim is procedural but
which can *not* be translated line-for-line into Lisp, thereby alleging
that Lisp is not procedural.

> C and Lisp are languages from completely different families.

Here's another exercise for you: Tell me which of the languages I
listed above are in which "families", i.e. partition those languages on
a per-family basis. Once it's clear what you mean by that word, we can
continue this discussion meaningfully.

akarl
Guest
Posts: n/a

 07-30-2005
Robert Maas, see http://tinyurl.com/uh3t wrote:
>>From: akarl <(E-Mail Removed)>
>>assignment is not an operator

>
> It is in C and C++ and Java and Algol and Basic, or didn't you know
> that? It is in Lisp too, but I'm sure you didn't know that because you
> don't seem to know much about Lisp.

Are you referring to Common Lisp, Scheme, Elisp...? The Lisp languages
are mainly functional and in a purely functional language, such as
Haskell, assignment is not even a part of the language.

When I say that "assignment is not an operator in Oberon-2" I mean that
it's not an expression operator; it doesn't return a value.

> An assignment expression can even return a value which can be passed as
> a rhs to another assignment or even inside a calculation expression. Or
> didn't you know that either? Note below the operator precedence whereby
> = is looser than +, for example 2 is added to (x=1) and *then* the
> result of that is assigned to y:
>
> % more x1.c
> main() {
> int x; int y; int z;
> z = (y = (x = 1) + 2) + 4;
> printf("%d %d %d\n", x,y,z);
> }
> % cc x1.c
> % ./a.out
> 1 3 7

Yes this is all true when assignment is an expression operator.

>>>In any case, Lisp has it beat out, with ony token-level syntax and
>>>parens, no other syntax at all.

>>
>>Since this is comp.lang.c I mentioned the simplest *procedural*
>>language, Oberon-2.

>
>
> Are you claiming that Lisp isn't procedural? It most certainly is!
> To put this issue to test, you tell me which of the following langauges
> are procedural and which are not:
> txt html php sh perl python lisp awk f77 c c++ java
> Then you write a short (4-7 line) program that can be converted
> line-for-line into each of the languages you claim is procedural but
> which can *not* be translated line-for-line into Lisp, thereby alleging
> that Lisp is not procedural.
>
>
>>C and Lisp are languages from completely different families.

>
>
> Here's another exercise for you: Tell me which of the languages I
> listed above are in which "families", i.e. partition those languages on
> a per-family basis. Once it's clear what you mean by that word, we can
> continue this discussion meaningfully.

C is a procedural and statically typed language and the Lisp family of
languages are dynamically typed and "mostly" functional.

August

Dik T. Winter
Guest
Posts: n/a

 07-31-2005
In article <(E-Mail Removed)> (E-Mail Removed) (Robert Maas, see http://tinyurl.com/uh3t) writes:
> > From: akarl <(E-Mail Removed)>
> > assignment is not an operator

>
> It is in C and C++ and Java and Algol and Basic, or didn't you know
> that?

Assignment is not an operator in either Algol 60 or Algol 68, or didn't
you know that?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/