++ devils

[Robert Latest]

On 23 May 2006 01:25:28 -0700,

The purpose of writing this is to arrive at some useful
extensions which would be of help to programmers rather than shutting
the door based on the current definition of the language.

OK. Compiler extension. Good. Many compiler extensions exist for many
compilers, many of them exist for good reasons. They are used
frequently, and some even made it into the current C Standard.

A common reason for an extension to exist is that it is useful. Show us
something useful.

Thanks so much.

No. /We/ have to thank /you/ for your suggestions. I sometimes find it
quite enlightening how a complete newbie can shine some fresh light on
an old subject and really open up new directions in which the C language
could evolve in the future.

robert

 

[Nick Keighley]

Indeed. In a language like Algol 60 *each* construct had a precisely
defined meaning, even the silly ones.

I thought even Alogol-60 had holes in its semantics? Wasn't
call-by-name with
nested functions a bit hairy? This is based on a very vague memory...

 

[Vladimir Oka]

Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.

It's quite feasible, it's just not a choice that C made.[/QUOTE]

The C standard is not designed with the expectation that all programs
are conforming; it guarantees the behaviour of conforming programs and
allows other standards to extend it while still letting C be used as
"a better assembler".

Quite so. It was a bad choice of word on my part.

 

[Dik T. Winter]

>
> I thought even Alogol-60 had holes in its semantics? Wasn't
> call-by-name with
> nested functions a bit hairy? This is based on a very vague memory...

It was hairy, but well-defined. The problem was that it was a side-effect
of a strict definition that was not foreseen (and that some people at that
time thought not implementable).

 

[Richard Heathfield]

CBFalconer said:

No it doesn't.

Er, yes, it does. That is, it does *appear* to work like this. The problem
here is that appearance and reality are not always the same thing. The
reality is that the behaviour is undefined, but the /appearance/ is that it
is reproducible. To dispel the appearance would require access to
implementations other than the one being used by the OP, and a willingness
to learn from those implementations and from the wording of the Standard.

 

[Richard Heathfield]

Richard Tobin said:

Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.

It's quite feasible, it's just not a choice that C made.[/QUOTE]

To define every possible behaviour, a programming language would have to be
a formal system. If it is a sufficiently powerful formal system, it is
either incomplete or inconsistent. That is, there will be some behaviours
that cannot be defined. And if it is not a sufficiently powerful formal
system, it loses interest.

 

[pete]

Richard Tobin said:


To define every possible behaviour,
a programming language would have to be
a formal system. If it is a sufficiently powerful formal system,
it is either incomplete or inconsistent.
That is, there will be some behaviours
that cannot be defined.
And if it is not a sufficiently powerful formal
system, it loses interest.

C is a much simpler language with undefined behavior
than it would be without it.

I can fully evaluate these four expressions at a glance:

(1) :- x= ++x + ++x
(2) :- x= ++x + ++x + ++x
(3) :- x = ++x + ++x + ++x + ++x
(4) :- x = ++x + ++x + ++x + ++x + ++x

They're all undefined.

 

[Chris Dollin]

Richard Tobin said:


To define every possible behaviour, a programming language would have to be
a formal system. If it is a sufficiently powerful formal system, it is
either incomplete or inconsistent.

Um ... I don't think that applies in the Goedel sense; (imperative) programs
represent functions (from states to states, roughly), they can't be
inconsistent, any more than a brick or oxygen can.

That is, there will be some behaviours that cannot be defined.

That's true. Some things are uncomputable.

(And some are too expensive, and others are too complicated to write
reliably in Current Preferred Language.)

And if it is not a sufficiently powerful formal
system, it loses interest.

Adding undefined behaviour, C-style, doesn't change that. Unless, I
suppose, the demon that flies out of your nose is also clutching the
answer to your question ...

 

[Richard Heathfield]

Chris Dollin said:

Um ... I don't think that applies in the Goedel sense;

I think it probably does, actually, but this probably isn't the place to
argue the toss about it.

 

[Dik T. Winter]

> Richard Tobin said:
>
>
> To define every possible behaviour, a programming language would have to be
> a formal system.

But this is something different. The language of a universal turing machine
can be very simple and still be powerful. And there are such with only
two symbols and 18 states. So the behaviour of every program for that
machine in its language is well-defined, what is however impossible is to
predict the outcome of every program.

 

[Richard Tobin]

It's quite feasible, it's just not a choice that C made.

[/QUOTE]

To define every possible behaviour, a programming language would have to be
a formal system. If it is a sufficiently powerful formal system, it is
either incomplete or inconsistent. That is, there will be some behaviours
that cannot be defined. And if it is not a sufficiently powerful formal
system, it loses interest.

At a pinch, I could make do with a programming language that was only
as well-defined as integer arithmetic.

-- Richard

 

[Al Balmer]

This is a behavior observed in MSVC and this is predictable. The
compiler is going to give me the same result whenever I execute this
code. This is predictable.

Are you prepared to debug and rewrite your code when MS releases a new
version of the compiler?

What do you mean by undefined when I am able
to define it. Do not write such irresponsible mails based on your
limitations and based on loose statements like "undefined".

Undefined is well defined ;-) Obviously you are not familiar with the
C standard. In this group, we deal with Standard C. If you want to
talk about the peculiarities of MSVC, there are a number of forums
where it's on topic.

I do not
care what is undefined as long as it works the way it is expected to
for a specific compiler.

Don't express such opinions in a job interview On second thought,
go ahead - it might prevent an employer from making a costly mistake.

 

[SM Ryan]

# > Dik T. Winter wrote:
# ...
# > > > It's quite feasible, it's just not a choice that C made.
# > >
# > > Indeed. In a language like Algol 60 *each* construct had a precisely
# > > defined meaning, even the silly ones.
# >
# > I thought even Alogol-60 had holes in its semantics? Wasn't
# > call-by-name with
# > nested functions a bit hairy? This is based on a very vague memory...
#
# It was hairy, but well-defined. The problem was that it was a side-effect
# of a strict definition that was not foreseen (and that some people at that
# time thought not implementable).

45 years later and Algol-60 remains an improvement on its successors.

 

[Keith Thompson]

Thanks for your response. I am fully aware of the problems associated
with using such constructs. What I am trying to say is that, if we can
find out useful applications for expressions such as these, then it
makes sense for compiler writer to include this as a part of the
definition. Of course, there would still be many expressions which are
left out by compiler writers, but then a useful extension has been
made. The purpose of writing this is to arrive at some useful
extensions which would be of help to programmers rather than shutting
the door based on the current definition of the language.

Please don't top-post. Your response goes below, or interspersed with,
any quoted material (which should be trimmed to just what's relevant
to your response). See <http://www.caliburn.nl/topposting.html>.

Yes, extensions can be very useful, and some extensions can take the
form of the compiler defining behavior that is not defined by the
standard. This is explicitly allowed by the standard; C99 4p6 says:

A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.

Part of the problem is that you've picked a poor example to make the
case. The particular example we've been discussing is

x = x++ + ++x;

There's no real benefit in defining the behavior of something that
ugly; whatever it happens to do, there's a much clearer way to do
exactly the same thing, perhaps this:

x = 2 * x + 3;

But that's assuming that we're just talking about this specific case.
If you want to make a more general point, one possible extension would
be to define the order of evaluation for all expressions (say,
strictly left-to-right). A compiler that implements such an extension
would provide predictable results for some expressions that invoke
undefined behavior in standard C. The drawbacks would be that (1)
expression evaluation would likely be less efficient in some cases,
because some optimizations would be disallowed, and (2) any code that
depends on this extension would be non-portable, and would very likely
break on another implementation.

 

[John F]

Chris Dollin said:


I think it probably does, actually, but this probably isn't the
place
to argue the toss about it.

Well. One can define a complete and consistent set of rules that
describe a system accurately. You can design the set in a way that the
inconsistency in beyond the scope of the problem you are trying to
solve. (I mean you can still "add" numbers without worrying the Goedel
paradoxon)

I think that this is what a programming language should do.

--
Johannes
=============
You can have it:

Quick.
Accurate.
Inexpensive.

Pick two.

 

[Walter Roberson]

To define every possible behaviour, a programming language would have to be
a formal system. If it is a sufficiently powerful formal system, it is
either incomplete or inconsistent. That is, there will be some behaviours
that cannot be defined. And if it is not a sufficiently powerful formal
system, it loses interest.

Richard, you are conflating the Goedel Incompleteness Theorem
and the Church-Rosser Theorem.

Goedel Incompleteness is only applicable to indefinitely large
(i.e., infinite) systems: if one is not working with an indefinitely large
system then there is no certainty that one is going to be able to
construct the unprovable statement under the Goedel system.

The Church-Rosser Theorem is more easily applied to bounded systems
[such as actual implementations], as you can take the jog into
Turing Machine emulation with a Universal Turing Machine, and then
use the theorem that shows that every UTM has the same size
to within a constant (that is dependant on the underlying implementation.)
That puts on upper bound on the size of the UTM, and allows one to draw
upon the body of works about Turing Computability subject to resource
restrictions.

Goedel Incompleteness, on the other hand, has no established upper
bound on the size of the unprovable statement: the theorem just
establishes that at least one such unprovable statement *exists*, and
does not establish that one can compute it with any particular limited
resource set.


For each finite resource [including output] deterministic computing
system, it would be possible [in a vastly larger system!] to write a
total state function that enumerated EVERY state transition --
every possible combination of values stored in memory and what the
result of each of the operations would be. The state table would be
complete and consistant... and vast, but finite. I don't think you
mean to say that the only computer systems of interest are those
which are non-deterministic or of [literally] infinite capacity.

 

[Mark McIntyre]

This is a behavior observed in MSVC and this is predictable. The
compiler is going to give me the same result whenever I execute this
code.

Sure about that? What about when MS ship a patch that changes the
behaviour, or you upgrade to the latest vesion, or you turn on a
different optimising mode. Believe me, I've experienced changes of
this nature.

This is predictable. What do you mean by undefined when I am able
to define it.

Maybe, but thats not the definition of "undefined" in use in CLC.
Here, undefined means behaviour on which the C standard imposes no
requirements.

Do not write such irresponsible mails based on your
limitations and based on loose statements like "undefined". I do not
care what is undefined as long as it works the way it is expected to
for a specific compiler.

You can't guarantee this.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Heathfield]

Walter Roberson said:

Richard, you are conflating the Goedel Incompleteness Theorem
and the Church-Rosser Theorem.

But at least I was doing so in a complete and consistent manner.

 

[Dik T. Winter]

> # > > Indeed. In a language like Algol 60 *each* construct had a precisely
> # > > defined meaning, even the silly ones.
> # >
> # > I thought even Alogol-60 had holes in its semantics? Wasn't
> # > call-by-name with
> # > nested functions a bit hairy? This is based on a very vague memory...
> #
> # It was hairy, but well-defined. The problem was that it was a side-effect
> # of a strict definition that was not foreseen (and that some people at that
> # time thought not implementable).
>
> 45 years later and Algol-60 remains an improvement on its successors.

I think that is not true. Algol-68 was again a vast improvement (although
it did not have call by name). But again, it was ahead of its time. Many
people thought it not implementable, and some even did not understand the
way the syntax was written. For instance in:
'real' r;
'int' i;
i := r;
r := i;
has a syntax error on the third line (the type mismatch is not resolved by
the syntax), but not on the fourth line (here the syntax resolves the type
mismatch and also tells you what does happen in this case).

One of the biggest problem with Algol-60 was that you could use an integer
constant as an argument to a function (procedure) that could either be an
actual integer constant or a label, and the compiler would not be able to
determine what it was.

But although both Algol-60 and Algol-68 were thought to be not implementable,
I have used full implementations of both (yes, it did compile a program with
the problem above correctly, the argument was passed both as integer and as
label).

 

[Nick Keighley]

Richard Tobin said:


To define every possible behaviour, a programming language would have to be
a formal system. If it is a sufficiently powerful formal system, it is
either incomplete or inconsistent. That is, there will be some behaviours
that cannot be defined. And if it is not a sufficiently powerful formal
system, it loses interest.

so Alogol-68 was uninteresting...