On 4 Dec 2007 at 22:07, jacob navia wrote:
> CJ wrote:
>> I believe that shows very bad quality of implementation. It's undefined
>> behavior, so your compiler can do what it likes, but I think it's much
>> better to let the program continue (maybe the programmer will check
>> errno for EOVERFLOW, either way I don't think *any* library, including
>> the standard library, has any business in aborting programs without
>> giving the programmer chance to recover).
>>
>
> I haven't spelled out all the details. You can redefine this behavior if
> you add a function called
>
> void _overflow(int linenr, char *functionname);
>
> What I described above is the default action.

Isn't it possible to turn this off completely, so that overflow is
silently ignored by default? Or do you have to write a no-op function
called _overflow? I think having a special function like this is likely
to encourage programmers using your compiler to rely on such special
overflow handling and write non-portable code.

But if you must have it, why not use existing mechanisms, for example,
you could send a signal to the program on overflow, and set a global
variable like _overflow_has_occurred so that if the programmer installs
a handler for the signal then he can know whether it was triggered by
your overflow mechanism or not.

On Tue, 04 Dec 2007 21:46:15 +0100, jacob navia wrote:
> Harald van Dijk wrote:
>> On Tue, 04 Dec 2007 20:08:08 +0100, jacob navia wrote:
>>> For your information:
>>>
>>> lcc-win invoked with the -overflowcheck option will check each
>>> operation that can generate an overflow. Any operation that does
>>> generate one will provoke the end of the program with an error
>>> message.
>>
>> Does it make sure to exclude unsigned wraparound (which isn't
>> overflow)? In other words, does a valid C program such as
>>
>> #include <limits.h>
>> int main(void) {
>> unsigned u;
>> u = UINT_MAX / 2;
>> u++;
>> u = UINT_MAX;
>> u++;
>> return 0;
>> }
>>
>> get accepted and does it run without aborting?
>
> Overflow check will be done for SIGNED types only

The exact program I posted aborts, reporting an overflow, when compiled
with lcc's overflow checking. I was hoping you'd have tried it.

CJ wrote:
> On 4 Dec 2007 at 22:07, jacob navia wrote:
>> CJ wrote:
>>> I believe that shows very bad quality of implementation. It's undefined
>>> behavior, so your compiler can do what it likes, but I think it's much
>>> better to let the program continue (maybe the programmer will check
>>> errno for EOVERFLOW, either way I don't think *any* library, including
>>> the standard library, has any business in aborting programs without
>>> giving the programmer chance to recover).
>>>
>> I haven't spelled out all the details. You can redefine this behavior if
>> you add a function called
>>
>> void _overflow(int linenr, char *functionname);
>>
>> What I described above is the default action.
>
> Isn't it possible to turn this off completely, so that overflow is
> silently ignored by default?

I am ALWAYS wrong with you. As I said in my message
this is only done when lcc-win is invoked with the
-checkoverflow flag!

It is not ON by default.


> Or do you have to write a no-op function
> called _overflow? I think having a special function like this is likely
> to encourage programmers using your compiler to rely on such special
> overflow handling and write non-portable code.
>

???

> But if you must have it, why not use existing mechanisms, for example,
> you could send a signal to the program on overflow, and set a global
> variable like _overflow_has_occurred so that if the programmer installs
> a handler for the signal then he can know whether it was triggered by
> your overflow mechanism or not.
>


Well, this all can be done in YOUR overflow function. Other users
will have other requirements, whatever... This is the most flexible
design.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Richard Harter wrote:
> On Tue, 4 Dec 2007 09:34:31 -0800 (PST), jameskuyper@verizon.net
> wrote:
....
> >That's rather the whole point: there is no such permission granted to
> >the implementation. If you think otherwise, please provide a
> >citation. Computer math differs from theoretical math in that it is,
> >in general, neither associative nor commutative, and the standard
> >nowhere permits implementations to assume that it is.
>
> Cited elsewhere, Harbison &Steele, 1991, p 207, section 7.12,
> Order of evaluation. The section begins:
>
> In general, the compiler can rearrange the order in which an
> expression is evaluated. The rearrangement may consist of
> evaluating only the arguments or the two operands of a binary
> operator, in some particular order other than the obvious
> left-to-right order. The binary ooperators +, *, &, ^, and | are
> assumed to be completely associative and commutiative, and a
> compiler is permitted to exploit this assumption.
>
> Of course Harbison & Steele could be wrong, or the standard may
> have been amended since then, but the text is quite clear. If
> you disagree with the text feel free to point out where it is
> wrong by citing the appropriate section of the standard.

The text you cite from Harbison & Steele is incorrect. The standard is
the authoritative source for this issue, and it disagrees. It's a
little tricky to cite relevant sections from the standard, because
what I need to cite is the absence of any permission for
rearrangement. Since it's absent, it's hard to cite. It's also tricky
demonstrating that the standard requires a particular evaluation
order, not because it's not true, but because it's expressed
indirectly.

Basically, the standard requires that a+b+c be parsed as (a+b)+c;
there's no other way parse it that is consistent with the grammar
given in the standard. As a result, there are precisely two additive
expressions there. The first one has 'a' as it's left operand, and b
as it's right operand. The second additive expression has a+b as its
left operand, and c as it's right operand. The standard requires that
each additive expression have as it's value the sum of it's operands.
It can evaluate a or b in any order (which could be important if a or
b were expressions rather than variable names), but the result of the
second additive expression is the sum of the value of the first
expression and the value of c.

Section 5.1.2.3 p5 has been cited for your attention, which is the
formal version of the as-if rule. The key point is that it allows a
program to produce it's results without using precisely the semantics
specified by the standard, so long as it produces exactly the same
results as if the abstract semantics had been obeyed.

I described the abstract semantics for additive expressions earlier,
and those semantics don't allow for overflows when a+b doesn't
overflow, and (a+b)+c doesn't overflow, even if (a+c) or (b+c) do
overflow. Note that 5.1.2.3 does NOT provide any special exemptions
based upon the associative and commutative properties of mathematical
operators. The standard doesn't provide such an exemption anywhere
else, either. It would be pretty odd if it did, since computer
addition, unlike mathematical addition, is NOT associative. The
standard does mention integer overflow, and that is precisely the
thing that breaks the associativity of computer addition.

jacob navia wrote, On 04/12/07 22:44:

<snip optional overflow checking>

> I am ALWAYS wrong with you. As I said in my message
> this is only done when lcc-win is invoked with the
> -checkoverflow flag!
>
> It is not ON by default.

<snip>

Personally, I would say an option to trap on signed integer overflow is
a good thing. So now you know not everyone here always disagrees with
everything you have implemented.
--
Flash Gordon

Flash Gordon <spam@flash-gordon.me.uk> writes:

> jacob navia wrote, On 04/12/07 22:44:
>
> <snip optional overflow checking>
>
>> I am ALWAYS wrong with you. As I said in my message
>> this is only done when lcc-win is invoked with the
>> -checkoverflow flag!
>>
>> It is not ON by default.
>
> <snip>
>
> Personally, I would say an option to trap on signed integer overflow
> is a good thing.

<off-topic>
In case anyone else is similarly in the dark, I only recently discovered
the very handy -ftrapv option in gcc.
</off-topic>

--
Ben.

CJ said:

> On 4 Dec 2007 at 19:08, jacob navia wrote:
>> lcc-win invoked with the -overflowcheck option will check
>> each operation that can generate an overflow. Any operation that
>> does generate one will provoke the end of the program
>> with an error message.
>
> I believe that shows very bad quality of implementation. It's undefined
> behavior, so your compiler can do what it likes, but I think it's much
> better to let the program continue (maybe the programmer will check
> errno for EOVERFLOW, either way I don't think *any* library, including
> the standard library, has any business in aborting programs without
> giving the programmer chance to recover).

That isn't really a problem, since the behaviour is controlled by a switch
which, presumably, the programmer can choose not to throw. The problem is
not "this switch is bad" so much as "this switch has nothing whatsoever to
do with the topic of this newsgroup". The switch *is*, however, topical in
comp.compilers.lcc, and it would be good for those who wish to discuss it
to do so there, rather than here.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

jacob navia said:

> CJ wrote:
>> On 4 Dec 2007 at 22:07, jacob navia wrote:
>>> CJ wrote:
>>>> I believe that shows very bad quality of implementation. It's
>>>> undefined behavior, so your compiler can do what it likes, but I think
>>>> it's much better to let the program continue (maybe the programmer
>>>> will check errno for EOVERFLOW, either way I don't think *any*
>>>> library, including the standard library, has any business in aborting
>>>> programs without giving the programmer chance to recover).
>>>>
>>> I haven't spelled out all the details. You can redefine this behavior
>>> if you add a function called
>>>
>>> void _overflow(int linenr, char *functionname);
>>>
>>> What I described above is the default action.
>>
>> Isn't it possible to turn this off completely, so that overflow is
>> silently ignored by default?
>
> I am ALWAYS wrong with you. As I said in my message
> this is only done when lcc-win is invoked with the
> -checkoverflow flag!

This is more properly a subject for comp.compilers.lcc - but it seems to me
that if overflow checking is only done when -checkoverflow is set, then
setting -overflowcheck (which was what you said last time) is a bit
pointless.

si tacuisses...

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Harter wrote:
> On Tue, 04 Dec 2007 10:40:18 +0000, Philip Potter
> <pgp@doc.ic.ac.uk> wrote:
>> The implementation *can* know that a+c+b may overflow in a case where
>> a+b+c does not. Because a+b+c is what the programmer asked for, the
>> implementation must provided the correct, defined behaviour of a+b+c. If
>> the implementation cannot be sure that a+c+b will always provide the
>> same behaviour as a+b+c whenever the behaviour of a+b+c is defined, then
>> the implementation cannot use a+c+b as its order of addition.
>
> Well, no, that is not my understanding. I'm always open to
> chapter and verse correction from the standard. However here is
> what Harbison (C - A reference Manual) has to say (7.12 Order of
> Evaluation).
>
> The assumption of commutativity and associativity is
> always true for &, ^, and | on unsigned operands...
> It may not be true for * and + because of the possibility
> that the order indicated by the expression as written
> might avoid overflow but another order might not.
> Nevertheless, the compiler is allowed to exploit the
> assumption. In such situations the programmer must use
> assignments to temporary variable to force a particular
> evaluation order:

As stated elsethread, this is untrue.

>> If you argue that the compiler can do as much rearranging as it likes,
>> then where do you stop? a+INT_MAX+b-INT_MAX+c yields the same result in
>> maths, but in C carries a high risk of overflow.
>
>> As a result, a
>> programmer cannot even add two numbers together without invoking
>> undefined behaviour.
>
> This is quite true. To quote myself, the responsibility for
> avoiding overflow rests with the programmer and not with the
> compiler.

When you cannot even add two integers together without avoiding all
possibility of overflow, how do you propose the programmer achieves this?

You give all of the responsibility to the programmer but you do not give
him the tools to fulfill that responsibility.

On Tue, 04 Dec 2007 13:43:35 -0800, Keith Thompson
<kst-u@mib.org> wrote:

>cri@tiac.net (Richard Harter) writes:
>
>> On Tue, 04 Dec 2007 15:08:28 -0500, Eric Sosman
>> <Eric.Sosman@sun.com> wrote:
>>
>>>Richard Harter wrote:
>>>>
>>>> Cited elsewhere, Harbison &Steele, 1991, p 207, section 7.12,
>>>> Order of evaluation. The section begins:
[snip quoted H&S]

Small order of crow ordered and consumed. The section in
question is wrong, or more charitably, was true of some
pre-standard K&R implementations.


>>>
>>> 5.1.2.3, with special attention to paragraph 5.
>>
>> 5.1.2.3 of what? Clearly not Harbison $=& Steele. I'm guessing
>> that it is from some standard, either C89, C90, or C99.
>> Whichever it is, I don't have a copy. Would it possible to
>> actually quote the paragraph in question, or failing that, point
>> to a publicly readable version on the web.
>
>You asked for a citation from the standard, and when presented with a
>section number you're not sure that it refers to the standard?
>
>Yes, it's section 5.1.2.3 of the standard. It could be either C90 or
>C99, since that particular setion has the same number in both.

Let me grumble a bit. Just because one is a programmer doesn't
mean that one is exempt from the ordinary standards of
scholarship. Part of the drill is to include the identification
of references.

>
>The latest post-C99 draft is at
><http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>; portions
>not marked with change bars should be identical to the official C99
>standard.
>
>The section is more than a page long (nearly 4 pages including notes
>and examples), so I'd rather not quote it all here. If you have
>trouble obtaining or reading the PDF, I'll be glad to e-mail you the
>plain text for that section.

Many thanks, much appreciated.
>
>[...]

In this document the only relevant passage in paragraph 5 is a
general statement of the "as if" rule, e.g.:

"At program termination, all data written into files shall be
identical to the result that execution of the program according
to the abstract semantics would have produced."

To settle the question at hand one needs a definite statement of
the abstract semantics; it turns out that paragraph 14 (Example
6) is a clear statement of the application of the rule. I quote
in part:

"However, on a machine in which overflow silently generates some
value and where positive and negative overflows cancel, the
above expression statement can be rewritten by the implementation
in any of the above ways because the same result will occur."

Again, many thanks for the URL.



Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
The good news is that things could be worse; the bad
news is that things aren't as good as they should be.

On 4 Dec 2007 21:31:05 GMT, Chris Torek <nospam@torek.net> wrote:

>In article <4755858a.405943062@news.sbtc.net>
>Richard Harter <cri@tiac.net> wrote:
>>... here is what Harbison (C - A reference Manual) has to say
>>(7.12 Order of Evaluation).
>>
[snip quote]
>
>H&S is simply wrong here (or, more charitably, they are referring
>to "K&R C", before the original ANSI C Standard, when the
>specification for C was quite loose).
>
[snip interesting discussion]

Many thanks for the clarification.



Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
The good news is that things could be worse; the bad
news is that things aren't as good as they should be.

On Wed, 05 Dec 2007 09:49:25 +0000, Philip Potter
<pgp@doc.ic.ac.uk> wrote:

>Richard Harter wrote:
>> On Tue, 04 Dec 2007 10:40:18 +0000, Philip Potter
>> <pgp@doc.ic.ac.uk> wrote:

[snip]

>> This is quite true. To quote myself, the responsibility for
>> avoiding overflow rests with the programmer and not with the
>> compiler.
>
>When you cannot even add two integers together without avoiding all
>possibility of overflow, how do you propose the programmer achieves this?

The programmer does it by not adding two integers together if
their sum would overflow.

>
>You give all of the responsibility to the programmer but you do not give
>him the tools to fulfill that responsibility.

He has a brain, doesn't he? That's the relevant tool to use.



Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
The good news is that things could be worse; the bad
news is that things aren't as good as they should be.

In data Tue, 04 Dec 2007 17:02:37 GMT, Richard Harter scrisse:
>>As a result, a
>>programmer cannot even add two numbers together without invoking
>>undefined behaviour.
>
>This is quite true. To quote myself, the responsibility for
>avoiding overflow rests with the programmer and not with the
>compiler.

.... and the language data structure

Richard Heathfield wrote, On 05/12/07 06:11:
> CJ said:
>
>> On 4 Dec 2007 at 19:08, jacob navia wrote:
>>> lcc-win invoked with the -overflowcheck option will check
>>> each operation that can generate an overflow. Any operation that
>>> does generate one will provoke the end of the program
>>> with an error message.
>> I believe that shows very bad quality of implementation. It's undefined

<snip>

> That isn't really a problem, since the behaviour is controlled by a switch
> which, presumably, the programmer can choose not to throw. The problem is
> not "this switch is bad" so much as "this switch has nothing whatsoever to
> do with the topic of this newsgroup". The switch *is*, however, topical in
> comp.compilers.lcc, and it would be good for those who wish to discuss it
> to do so there, rather than here.

In my opinion Richard's comment about topicality is true for CJ's post,
but *not* for Jacob's post. Jacob mentioned the switch to provide an
example of an implementation which does overflow checking in a
sub-thread about the impacts of overflow checking on what is "valid" C,
and as such Jacob's post was perfectly reasonable.
--
Flash Gordon

Flash Gordon wrote:
>
> In my opinion Richard's comment about topicality is true for CJ's post,
> but *not* for Jacob's post. Jacob mentioned the switch to provide an
> example of an implementation which does overflow checking in a
> sub-thread about the impacts of overflow checking on what is "valid" C,
> and as such Jacob's post was perfectly reasonable.

Yes, that was what prompted me to answer that.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Richard Harter wrote:
> On Wed, 05 Dec 2007 09:49:25 +0000, Philip Potter
> <pgp@doc.ic.ac.uk> wrote:
>
>> Richard Harter wrote:
>>> On Tue, 04 Dec 2007 10:40:18 +0000, Philip Potter
>>> <pgp@doc.ic.ac.uk> wrote:
>
> [snip]
>
>>> This is quite true. To quote myself, the responsibility for
>>> avoiding overflow rests with the programmer and not with the
>>> compiler.
>> When you cannot even add two integers together without avoiding all
>> possibility of overflow, how do you propose the programmer achieves this?
>
> The programmer does it by not adding two integers together if
> their sum would overflow.

Where did that proviso come from? In the text you snipped:

>>If you argue that the compiler can do as much rearranging as it likes,
>>then where do you stop? a+INT_MAX+b-INT_MAX+c yields the same result
>>in maths, but in C carries a high risk of overflow.

>>As a result, a
>>programmer cannot even add two numbers together without invoking
>>undefined behaviour.

>This is quite true. To quote myself, the responsibility for
>avoiding overflow rests with the programmer and not with the
>compiler.

There is no "if their sum would overflow" proviso. Once a proviso
becomes "if their sum or any partial sum in any possible reordering
would overflow"

The point I am making is that your application of the as-if rule, taken
to its logical conclusion, results in /no/ summation at all having
defined behaviour, because

a+b

can be evaluated as

a+INT_MAX+b-INT_MAX

I was saying this to get an idea from you of where the line was drawn.
(To be honest, looking back on it it's not that relevant to what you
were saying. What was I thinking when I wrote it?)

>> You give all of the responsibility to the programmer but you do not give
>> him the tools to fulfill that responsibility.
>
> He has a brain, doesn't he? That's the relevant tool to use.

In order to speak Polish, it's not enough to simply be clever. One must
also know Polish.

In order to use C, it's not enough to simply be clever. One must also
know C. The C standard states that if an expression has defined
behaviour, the compiler must implement that defined behaviour, even if a
similar-looking expression which a compiler may be tempted to transform
it to does not have defined behaviour.

cri@tiac.net (Richard Harter) writes:
> On Tue, 04 Dec 2007 13:43:35 -0800, Keith Thompson
> <kst-u@mib.org> wrote:
>
>>cri@tiac.net (Richard Harter) writes:
>>
>>> On Tue, 04 Dec 2007 15:08:28 -0500, Eric Sosman
>>> <Eric.Sosman@sun.com> wrote:
[...]
>>>>
>>>> 5.1.2.3, with special attention to paragraph 5.
>>>
>>> 5.1.2.3 of what? Clearly not Harbison $=& Steele. I'm guessing
>>> that it is from some standard, either C89, C90, or C99.
>>> Whichever it is, I don't have a copy. Would it possible to
>>> actually quote the paragraph in question, or failing that, point
>>> to a publicly readable version on the web.
>>
>>You asked for a citation from the standard, and when presented with a
>>section number you're not sure that it refers to the standard?
>>
>>Yes, it's section 5.1.2.3 of the standard. It could be either C90 or
>>C99, since that particular setion has the same number in both.
>
> Let me grumble a bit. Just because one is a programmer doesn't
> mean that one is exempt from the ordinary standards of
> scholarship. Part of the drill is to include the identification
> of references.
[...]

Not to beat a dead horse, but the reference was already identified.
Let's look at the context:

Richard Harter wrote:
[...]
| Of course Harbison & Steele could be wrong, or the standard may
| have been amended since then, but the text is quite clear. If
| you disagree with the text feel free to point out where it is
| wrong by citing the appropriate section of the standard.

Eric Sosman replied:
| 5.1.2.3, with special attention to paragraph 5.

You specifically asked for a citation *of the standard*, and that
context was visible in Eric's followup. It might have been nice if
Eric had written "C99 5.1.2.3", but it was perfectly clear to me what
he was citing. (As for C90 vs. C99, the section number happens to be
the same in both, and I don't think there were any relevant changes.)

--
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Wed, 05 Dec 2007 22:58:18 +0000, Philip Potter
<pgp@doc.ic.ac.uk> wrote:

>Richard Harter wrote:
>> On Wed, 05 Dec 2007 09:49:25 +0000, Philip Potter
>> <pgp@doc.ic.ac.uk> wrote:
>>
>>> Richard Harter wrote:
>>>> On Tue, 04 Dec 2007 10:40:18 +0000, Philip Potter
>>>> <pgp@doc.ic.ac.uk> wrote:
>>
>> [snip]
>>
>>>> This is quite true. To quote myself, the responsibility for
>>>> avoiding overflow rests with the programmer and not with the
>>>> compiler.
>>> When you cannot even add two integers together without avoiding all
>>> possibility of overflow, how do you propose the programmer achieves this?
>>
>> The programmer does it by not adding two integers together if
>> their sum would overflow.
>
>Where did that proviso come from? In the text you snipped:
>
> >>If you argue that the compiler can do as much rearranging as it likes,
> >>then where do you stop? a+INT_MAX+b-INT_MAX+c yields the same result
> >>in maths, but in C carries a high risk of overflow.
>
> >>As a result, a
> >>programmer cannot even add two numbers together without invoking
> >>undefined behaviour.
>
> >This is quite true. To quote myself, the responsibility for
> >avoiding overflow rests with the programmer and not with the
> >compiler.
>
>There is no "if their sum would overflow" proviso. Once a proviso
>becomes "if their sum or any partial sum in any possible reordering
>would overflow"
>
>The point I am making is that your application of the as-if rule, taken
>to its logical conclusion, results in /no/ summation at all having
>defined behaviour, because
>
>a+b
>
>can be evaluated as
>
>a+INT_MAX+b-INT_MAX
>
>I was saying this to get an idea from you of where the line was drawn.
>(To be honest, looking back on it it's not that relevant to what you
>were saying. What was I thinking when I wrote it?)

I dunno. My mind reader is on the blink

>
>>> You give all of the responsibility to the programmer but you do not give
>>> him the tools to fulfill that responsibility.
>>
>> He has a brain, doesn't he? That's the relevant tool to use.
>
>In order to speak Polish, it's not enough to simply be clever. One must
>also know Polish.
>
>In order to use C, it's not enough to simply be clever. One must also
>know C. The C standard states that if an expression has defined
>behaviour, the compiler must implement that defined behaviour, even if a
>similar-looking expression which a compiler may be tempted to transform
>it to does not have defined behaviour.

While I was wrong about what the rules were. However things are
not quite as you think. Harbison (op. cit.) said that the
compiler was free to reorder arithmetic expressions as though
they had the relevant mathematical properties. That would be
consistent with the as-if rule provided the semantics were
changed accordingly; the rule would be that the behaviour would
be undefined if the behaviour of any consistent reordering had
undefined behaviour.

Can one program with that rule? Of course one can; all that
would really mean is that in certain situations one should do
some defensive programming. In K&R C days it was something you
had better do; compilers really were free to reorder.

Having "things are executed left to right as they are written"
makes understanding what a program might or might not do easier.
Of course C is not terribly consistent about observing that
principle, but that is another matter, which doesn't matter
because C is what it is.




Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
The good news is that things could be worse; the bad
news is that things aren't as good as they should be.

On Thu, 29 Nov 2007 08:45:06 -0500, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote:
<snip Lisp example>
> There's a wide family of languages that imitate a formula
> notation (C,FORTRAN, Algol, Pascal, ...), but examples of
> "non-formulaic" languages are not hard to find. Lisp is one,
> assemblers usually focus on the operations rather than on

Assemblers generally write separately each instruction making up the
program being, er, written, but at least since very early days most
allow within instruction operands expressions which are evaluable at
translation time, i.e. 'constant' expressions in C terminology. E.g.

LOAD R1, BUFBASE + 3*SIZE_OF_ELEMENT + LEN_PART1

> formulas, what little I saw of COBOL looked like formulas
> transliterated into pidgin English, and somewhere in the high

COBOL has both the formula way and the nearly-English way.
Some perhaps many of its users and supporters emphasise the latter as
a unique advantage; the 'unique' part is unarguable.

> holy Himalayas of ratiocination you'll find the monasteries
> wherein dwell the lamas who can actually read APL.
>
APL does use infix and prefix operator syntax but NOT precedence and
associativity rules like all other formula langauges I know; except
for parens it 'binds' strictly right to left.

> Let's not poke too much fun at Lisp, by the way. It's
> challenging to read (although one gets better with practice),
> but there are *no* rules of precedence or associativity (or
> their formal-grammar counterparts) to confuse newbies, the
> "operator overloading" diatribes never erupt, and indeed it's
> trivial to introduce brand-new "operators" at need. That's
> a lot of power; the obfuscation may be a worthwhile price.

(Nearly-consistent) postfix like FORTH (already mentioned) and
PostScript is similarly simple at the syntax level. (Without thereby
limiting semantics, as already noted at least once.)

- formerly david.thompson1 || achar(64) || worldnet.att.net

On Thu, 29 Nov 2007 13:43:33 +0000, Philip Potter <pgp@doc.ic.ac.uk>
wrote:

> James Kuyper wrote:
> > Philip Potter wrote:

> >> One thing which hasn't been mentioned so far is operators which change
> >> the values of their operands. For example, it is impossible in C to
> >> write a function:
> >> int increment(int x);
> >> which has the same effect as x++ (or ++x). [because pass by value]

and similarly = += etc.

But the C family is unusual in considering assignment and
implicit-assignment (like increment) as operators at all. Most(?)
other 3GLs make assignment(s) instead a statement form, so the
assignment can only occur at 'top level' not in a subexpression, and
doesn't yield a value (or in C++ often lvalue); Ada and now Fortran do
allow assignment to be overridden/customized for user-defined types,
but as a nonvalued procedure resp. subroutine, which both those
languages distinguish from a valued function.

> >> [OT: In C++ this problem is solved by introducing reference types which
> >> allow a pass-by-reference mechanism. Then 'int increment (int &x)
> >
and in (most?) other 3GLs by having reference parameters, either
implicitly or as a modifier, without making them a quasitype
applicable to other things such as locals and classmembers as in C++.

> > C++'s reference types are merely syntactic sugar for something that can
> > be done in a slightly more cumbersome fashion in C:
> >
> > int increment(int *px) { return (*px)++;}
>
> In the context of replacing operators with functions, it's not the same
> thing at all. Firstly, it requires you to replace x++ with increment(&x)
> rather than increment(x) - so at best you can replace an operator with a
> function call and another operator. Secondly, even increment(&x) doesn't
> work everywhere x++ does: [snip: register storageclass is c.v.]
> Having said that, I'm not sure if you can initialize a reference type
> with a register lvalue in C++. <snip>

You can, but also &reg is fine in C++, not a c.v. as in C.

- formerly david.thompson1 || achar(64) || worldnet.att.net

David Thompson <dave.thompson2@verizon.net> writes:

> APL does use infix and prefix operator syntax but NOT precedence and
> associativity rules like all other formula langauges I know; except
> for parens it 'binds' strictly right to left.

Smalltalk is another language that lacks conventional precedence
and associativity rules for the standard arithmetic operators:
all binary operators are left associative and evaluated in
left-to-right order.
--
Ben Pfaff
http://benpfaff.org

David Thompson wrote:
> On Thu, 29 Nov 2007 13:43:33 +0000, Philip Potter <pgp@doc.ic.ac.uk>
> wrote:
>> In the context of replacing operators with functions, it's not the same
>> thing at all. Firstly, it requires you to replace x++ with increment(&x)
>> rather than increment(x) - so at best you can replace an operator with a
>> function call and another operator. Secondly, even increment(&x) doesn't
>> work everywhere x++ does: [snip: register storageclass is c.v.]
>> Having said that, I'm not sure if you can initialize a reference type
>> with a register lvalue in C++. <snip>
>
> You can, but also &reg is fine in C++, not a c.v. as in C.

(I take it c.v. means "Constraint Violation?")

I did not know that. The mind boggles at the number of subtle
differences between C and C++.

On Mon, 10 Dec 2007 12:49:42 +0000, Philip Potter <pgp@doc.ic.ac.uk>
wrote:

> David Thompson wrote:
> > On Thu, 29 Nov 2007 13:43:33 +0000, Philip Potter <pgp@doc.ic.ac.uk>
> > wrote:
> >> In the context of replacing operators with functions, it's not the same
> >> thing at all. Firstly, it requires you to replace x++ with increment(&x)
> >> rather than increment(x) - so at best you can replace an operator with a
> >> function call and another operator. Secondly, even increment(&x) doesn't
> >> work everywhere x++ does: [snip: register storageclass is c.v.]
> >> Having said that, I'm not sure if you can initialize a reference type
> >> with a register lvalue in C++. <snip>
> >
> > You can, but also &reg is fine in C++, not a c.v. as in C.
>
> (I take it c.v. means "Constraint Violation?")
>
Yes. I probably should have capitalized it, as the usual practice here
is UB or occasionally U.B. for Undefined Behavior.

> I did not know that. The mind boggles at the number of subtle
> differences between C and C++.

Yep. See C++98 Annex C, and I'm not sure even that was entirely
complete -- and of course it doesn't consider the changes created by
C99 (though that did remove the differences for doubleslash comments,
and implicit int and implicit function declaration) and what appear to
me to be fairly significant changes made or proposed in C++ since '98.

- formerly david.thompson1 || achar(64) || worldnet.att.net