Extending C syntax

[john]

Eric Sosman wrote: [...]

On 5/12/2010 6:44 PM, john wrote:
[... arithmetic operators with two pointer operands ...] For
example, if / was average then this would lead to simpler code like
johns_search(int *first, int *last)
{
int *mid = first / last;
... [snip]
In "fairy C" you can define anything any way you like, of course,
but I can't see any mnemonic connection between the two expressions.
Perhaps if you suggested `(first + last) / 2' a case could be made,
but `first / last'? Why should that be understood as "the midpoint
between first and last?" It's not, for example, how you calculate the
midpoint between two ordinary numbers: 1/10 is 0 or 0.1 depending on
types, but the midpoint between 1 and 10 is nowhere near either. To my
eye, your suggestion seems arbitrary -- which may just mean I'm too
dense to discern the underlying logic, but sqrt(first * last) looks
equally sensible to me.

I think you are being deliberately obtuse here.

The point is that at present, if p and q are pointers, then p / q has
no meaning, so you lose nothing and gain some brevity by giving it a
meaning. I chose as an example defining "p / q" to be the average of p
and q, i.e. q - (q - p) / 2. You could instead define p & q to be the
average and p / q to be the minimum of p and q - whatever you wanted,
or whatever the standards body finds most mnemonic if you like.

As long as it was standardized, everyone would be on the same page.

That's (at least) the second time today you've accused someone of being
"deliberately obtuse" because they disagreed with you.

Yes, your proposal of adding multiple built-in overloaded operators for
pointers would be compatible with the current language; it wouldn't
break existing code. But using "/" for pointer average would be
confusing and would, in my opinion not provide enough benefit to justify
the costs. It's used rarely enough that, even if it were standardized,
typical programmers would likely not recognize it. And even if it were
added to the C201X standard, we'd have to wait at least a decade before
we could confidently write code that depends on it.

I'm disappointed that people here don't appear willing to engage
positively with my suggestions for improving the language. I know C is a
"traditional" language mainly favored by older, perhaps more conservative
programmers, but it would be a shame if it faded into obscurity because
of the reluctance of its practitioners to embrace new features.

Just my $0.02.

 

[Seebs]

I'm disappointed that people here don't appear willing to engage
positively with my suggestions for improving the language.

Well, let's see. You started by proposing something that seemed crazy,
then revised your proposal to be a suggestion that we should, as a major
new change, adopt something that's been true for twenty years. Then you
accused everyone who disagreed with you of being "deliberately obtuse".

I know C is a
"traditional" language mainly favored by older, perhaps more conservative
programmers, but it would be a shame if it faded into obscurity because
of the reluctance of its practitioners to embrace new features.

I don't think I'd have any worries about that. Many of us are quite
enthusiastic about talking about or embracing new features, given some mix
of the following key characteristics:

1. The person advancing them has made, and demonstrated, some kind of
reasonable effort to understand the existing state of the art, and
has thought about at least some of the most obvious possible objections.
2. The feature addresses a serious lack which is currently experienced
by practitioners of the language.
3. The person advancing them is basically polite and doesn't immediately
run to picking fights or name-calling when people express lack of total
endorsement.

You're 0 for 3. You've made it clear that you don't understand the current
state of the language, you've addressed non-existent issues that don't seem
to be affecting anyone but you, and you've been a jerk to people who pointed
out possible shortcomings of your proposals.

-s

 

[Willem]

john wrote:
) I'm disappointed that people here don't appear willing to engage
) positively with my suggestions for improving the language. I know C is a
) "traditional" language mainly favored by older, perhaps more conservative
) programmers, but it would be a shame if it faded into obscurity because
) of the reluctance of its practitioners to embrace new features.

Straw man argument.

The reason that people are unwilling to engage positively with
your suggestions is because they are very very bad suggestions.

Furthermore, your sugestions *have* been tried before, in C++,
so they're not even remotely original.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Keith Thompson]

Keith Thompson wrote: [...]

That's (at least) the second time today you've accused someone of being
"deliberately obtuse" because they disagreed with you.

Yes, your proposal of adding multiple built-in overloaded operators for
pointers would be compatible with the current language; it wouldn't
break existing code. But using "/" for pointer average would be
confusing and would, in my opinion not provide enough benefit to justify
the costs. It's used rarely enough that, even if it were standardized,
typical programmers would likely not recognize it. And even if it were
added to the C201X standard, we'd have to wait at least a decade before
we could confidently write code that depends on it.

I'm disappointed that people here don't appear willing to engage
positively with my suggestions for improving the language. I know C is a
"traditional" language mainly favored by older, perhaps more conservative
programmers, but it would be a shame if it faded into obscurity because
of the reluctance of its practitioners to embrace new features.

Just my $0.02.

We've engaged with your suggestions. We've explained at considerable
length why we think they would not be a net improvement to the
language.

Coming up with ideas that actually improve a language is really
hard, and I don't want to discourage you from trying. Every new
feature has a real cost. It makes the language more complex,
which means more work for the standard committee, more development
time for compiler writers and more learning time for programmers.
Sometimes that price is worth paying. For example, function
prototypes, introduced by the ANSI C89 standard, were a great
improvement on what came before, and were enthusiastically adopted.

If C does fade into obscurity, I suggest that it won't be because
it lacks a "/" operator that computes the average of two pointers.
You haven't demonstrated that it would be used often enough to pay
for itself, or that "/" is a good choice of symbol when an averaging
operator would make at least as much sense for arithmetic types.

If you can improve your proposal in response to the constructive
criticism you've been getting, you might have something useful.

Please understand the difference between not wanting to change
the language, and not wanting to make the particular changes that
you advocate.

 

[Walter Banks]

I'm disappointed that people here don't appear willing to engage
positively with my suggestions for improving the language. I know C is a
"traditional" language mainly favored by older, perhaps more conservative
programmers, but it would be a shame if it faded into obscurity because
of the reluctance of its practitioners to embrace new features.

Language ideas go though many stages. Start with a good idea that
can withstand criticism by your peers and then survives a test
implementation followed by recognition of its usefulness in actual
practice. At this point it becomes idea worth presenting to a
standards committee where its merits are promoted and debated. There
are thousands of ideas out there some get implemented and a few make
it into the standards.

It is a long process to find both good ideas and workable solutions to
real problems. Looking for a short cut to promote an idea is missing
some essential steps used in idea evaluation.

If the idea is that good follow through and it will be accepted. Anyone
who has been though the process in this newsgroup will tell you that
all the steps are needed and worth it.

Regards,

w..

 

[bart.c]

This is most unintuitive.
int *mid = first |-><-| last;
would more express what the operation is doing. Except for some
types of sorting, or binary search, when would you use such a
thing?

What is the result of the pointer midpoint operation if first and
last point to adjacent characters in a character array? What is
the result of the pointer midpoint operation if first and last point
to adjacent structures (or an odd number of structures apart) in a
structure array?

I think this is well-defined. The result is rounded down. It will always
point to the start of a struct, never in the middle. No different to
averaging two indices into an array.

If the result isn't something sensible, you can't
safely use it in a search or sort without a lot of extra code to
check the result.

What if one or both operands are NULL?

That would be one advantage of using such an operator; it can be made to
take care of that (by having a NULL result for example).

The main problem with the proposal is that it's just not very useful and not
very exciting. (I'd originally thought first/last would average out all the
values pointed to from *first to *last, but even that is not so interesting,
except in being expected to work for any numeric pointers.)

 

[Keith Thompson]

We know that C has been through several revisions since it was first
created by Kernigan and Richie. One thing I don't understand is why some
of the opportunities for expansion present in the original C
specification have not been taken up in these subsequent revisions.

Here are two examples.

1. C does not have a ||= operator (or for that matter a &&= operator).
This is extremely useful and elegant in Perl for specifying default
values and it could work just the same way in C.

The semantics of Perl's || and && operators differ significantly from
C's, so let's discuss this in C terms.

Presumably they'd have the same short-circuit behavior, so that
x ||= y
would be equivalent to
x = x || y
except that x is evaluated only once (and y would be evaluated 0 or 1
time depending on the value of x).

I don't see any real problem with that. I don't think it's a necessary
change, but I wouldn't object to it.

Can you provide a concrete C (not Perl) example where this would be
particularly useful? An example involving default values would be
good. Think about the fact that 0 is a valid default value.

2. There are lots of operations that we often need to perform on pointers
to the same block of memory, e.g. find the max or min, or the average of
them, and many others. There are also lots of arithmetic operations that
are not currently defined for pointers, in fact only minus (ptrdiff_t) is
defined. So why not extend the syntax so that unused operators like +,
*, /, %, ^, &, etc would implement these useful operations.

For example, if / was average then this would lead to simpler code like
johns_search(int *first, int *last)
{
int *mid = first / last;
...

instead of a complicated expression with lots of terms.

A lot of the discussion has focused on this single example. The
main objection is that "/" isn't particularly mnemonic.

I'm guessing that
first / last
would be equivalent to
first + (last - first) / 2
except that first is evaluated only once. This implies, among other
things, that the behavior is undefined if either pointer is null,
or if they don't point into the same array or just past its end.
Is that correct?

Note that the specific examples you gave (min, max, and average)
make at least as much sense for arithmetic types as for pointers
-- and all those operators already have well defined meanings for
arithmetic types. Providing a min operator for pointers but not
for integers would, IMHO, be ugly.

Since this is your proposal, I suggest that it's up to you to flesh
it out. What operations do you think are needed, and what operators
would you assign to each one?

Can you separate the list of operations from the use of operator
symbols? How about a family of named functions that perform useful
operations on (void*?) pointers?

In my opinion, the fact that not all operator symbols can be applied
to pointer values is not a flaw. C looks enough like line noise
as it is.

And whatever changes you propose, expect us to shoot holes in your
proposal, and don't take it personally. To be honest, I don't
really expect anything practical to come out of this, but I'll
be glad to be surprised.