Operators for min/max, or min/max-assignment operators?

[Rick C. Hodgin]

Is there a native operator for min and max in C or C++?

// Traditional way
#define min(a, b) ((a <= b) ? a : b)
#define max(a, b) ((a >= b) ? a : b)

int a, b, c, d;

a = 5;
b = 8;

// Assign min and max:
c = min(a, b); d = max(a, b);

Is there an operator for this? Like /\ for max, \/ for min?

// Assign min and max using operators:
c = a \/ b; d = a /\ b;

Or min/max-assignment operators?

// Min of b and a is assigned to b
b \/= a; // Equivalent of b = min(b, a)

// Max of b and a is assigned to b
b /\= a; // Equivalent of b = max(b, a)

--
Rick C. Hodgin

[Bart]

On 18/06/2018 19:54, Rick C. Hodgin wrote:
> Is there a native operator for min and max in C or C++?

Not in C. (In C++ the answer to any such question is apparently always
Yes. If it doesn't have it already, you can implement it.)

>     // Traditional way
>     #define min(a, b) ((a <= b) ? a : b)
>     #define max(a, b) ((a >= b) ? a : b)
>
>     int a, b, c, d;
>
>     a = 5;
>     b = 8;
>
>     // Assign min and max:
>     c = min(a, b);    d = max(a, b);
>
> Is there an operator for this?  Like /\ for max, \/ for min?

Why not just call then max and min? Then everyone will immediately
understand what they do.

Anyway /\ and \/ won't work for obvious reasons.

--
bart

[David Brown]

On 18/06/18 20:54, Rick C. Hodgin wrote:
> Is there a native operator for min and max in C or C++?
>
>     // Traditional way
>     #define min(a, b) ((a <= b) ? a : b)
>     #define max(a, b) ((a >= b) ? a : b)
>

Traditional C would be:

#define MIN(a, b) (((a) <= (b)) ? (a) : (b))
#define MAX(a, b) (((a) >= (b)) ? (a) : (b))


In C++, you'd be better with a template. That would let you avoid the
"min(a++, b++)" problem.

If you are a gcc extension fan, you might also like their suggestion
using "typeof":

<https://gcc.gnu.org/onlinedocs/gcc/Typeof.html>

>     int a, b, c, d;
>
>     a = 5;
>     b = 8;
>
>     // Assign min and max:
>     c = min(a, b);    d = max(a, b);
>
> Is there an operator for this?  Like /\ for max, \/ for min?
>
>     // Assign min and max using operators:
>     c = a \/ b;       d = a /\ b;
>
> Or min/max-assignment operators?
>
>     // Min of b and a is assigned to b
>     b \/= a;    // Equivalent of b = min(b, a)
>
>     // Max of b and a is assigned to b
>     b /\= a;    // Equivalent of b = max(b, a)
>

gcc used to have "a <? b" as min(a, b) and "a >? b" as max(a, b), as an
extension. They dropped it a good while ago. I don't know exactly why,
but I expect it was very rarely used.

[Rick C. Hodgin]

On 6/18/2018 3:03 PM, Bart wrote:
> On 18/06/2018 19:54, Rick C. Hodgin wrote:
>>      // Assign min and max:
>>      c = min(a, b);    d = max(a, b);
>>
>> Is there an operator for this?  Like /\ for max, \/ for min?

> Anyway /\ and \/ won't work for obvious reasons.

Why wouldn't those character combinations work?

--
Rick C. Hodgin

[Scott Lurndal]

David Brown <david...@hesbynett.no> writes:
>On 18/06/18 20:54, Rick C. Hodgin wrote:
>> Is there a native operator for min and max in C or C++?
>>
>>     // Traditional way
>>     #define min(a, b) ((a <= b) ? a : b)
>>     #define max(a, b) ((a >= b) ? a : b)
>>
>
>Traditional C would be:
>
>#define MIN(a, b) (((a) <= (b)) ? (a) : (b))
>#define MAX(a, b) (((a) >= (b)) ? (a) : (b))
>
>
>In C++, you'd be better with a template. That would let you avoid the
>"min(a++, b++)" problem.

like std::min and std::max?

[Scott Lurndal]

What is the meaning and purpose of the '\' character in C?

[Bart]

Because \ is usually involved with line continuation. There would be
ambiguities.

--
bart

[Ben Bacarisse]

The cross post to comp.lang.c++ looks like a recipe for an unproductive
back and forth, so I've removed it in his reply which is about C only.

"Rick C. Hodgin" <rick.c...@gmail.com> writes:

> // Traditional way

No, I think the traditional way is safer. Let's not start unsafe
traditions.

> #define min(a, b) ((a <= b) ? a : b)
> #define max(a, b) ((a >= b) ? a : b)

You have redundant parentheses and missing parentheses. You should
write:

#define min(a, b) ((a) <= (b) ? (a) : (b))
#define max(a, b) ((a) >= (b) ? (a) : (b))

though adding extras is not a problem. In this case they are not all
needed, but it's simpler to remember the rule: put the whole expansion
in ()s as well as every instance of a macro parameter name.

--
Ben.

[Rick C. Hodgin]

On 6/18/2018 4:29 PM, Ben Bacarisse wrote:
> The cross post to comp.lang.c++ looks like a recipe for an unproductive
> back and forth, so I've removed it in his reply which is about C only.
>
> "Rick C. Hodgin" <rick.c...@gmail.com> writes:
>
>> // Traditional way
>
> No, I think the traditional way is safer. Let's not start unsafe
> traditions.
>
>> #define min(a, b) ((a <= b) ? a : b)
>> #define max(a, b) ((a >= b) ? a : b)

See below.

> You have redundant parentheses and missing parentheses. You should
> write:
>
> #define min(a, b) ((a) <= (b) ? (a) : (b))
> #define max(a, b) ((a) >= (b) ? (a) : (b))

That method works great for most people, but when my dyslexia brain tries
to read what you've written, it's a jumbled mass of confusion which all
runs together. It's hard to break out where one thing stops and another
starts because they all look the same.

The extra parentheses enable me to see the differentiating parts more
easily in source code.

> though adding extras is not a problem. In this case they are not all
> needed, but it's simpler to remember the rule: put the whole expansion
> in ()s as well as every instance of a macro parameter name.

I've never had a case where I've needed the extra parenthesis you and
David have inserted in a min/max macro. I'm open to see a real-world
example where it would be too ambiguous and the extra parentheses would
actually be required.

--
Rick C. Hodgin

[red floyd]

Not to mention that the "correct" way to do the "traditional" way is
#define min(a,b) (((a) <= (b)) ? (a) : (b))
#define max(a,b) (((a) >= (b)) ? (a) : (b))

[Ben Bacarisse]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:

> On 6/18/2018 4:29 PM, Ben Bacarisse wrote:
>> The cross post to comp.lang.c++ looks like a recipe for an unproductive
>> back and forth, so I've removed it in his reply which is about C only.
>>
>> "Rick C. Hodgin" <rick.c...@gmail.com> writes:
>>
>>> // Traditional way
>>
>> No, I think the traditional way is safer. Let's not start unsafe
>> traditions.
>>
>>> #define min(a, b) ((a <= b) ? a : b)
>>> #define max(a, b) ((a >= b) ? a : b)
>
> See below.
>
>> You have redundant parentheses and missing parentheses. You should
>> write:
>>
>> #define min(a, b) ((a) <= (b) ? (a) : (b))
>> #define max(a, b) ((a) >= (b) ? (a) : (b))
>
> That method works great for most people, but when my dyslexia brain tries
> to read what you've written, it's a jumbled mass of confusion which all
> runs together. It's hard to break out where one thing stops and another
> starts because they all look the same.

My dyslexic brain is fine with it. I have problems with words, but
symbols come very naturally to me. I imagine that a wide range of
differences in symbolic perception are lumped together in the term.

> The extra parentheses enable me to see the differentiating parts more
> easily in source code.

I wasn't suggesting you remove any that you'd like to have, only that if
you want to show the traditional way of doing things you should apply
the traditional rule for safer use of macro arguments.

>> though adding extras is not a problem. In this case they are not all
>> needed, but it's simpler to remember the rule: put the whole expansion
>> in ()s as well as every instance of a macro parameter name.
>
> I've never had a case where I've needed the extra parenthesis you and
> David have inserted in a min/max macro. I'm open to see a real-world
> example where it would be too ambiguous and the extra parentheses would
> actually be required.

I've never been sure what the real-world is. I'm sure you know (or at
least you know how to find out) exactly what argument expressions will
be problematic. If none of these will ever occur in what you call the
real world, then the macros are fine for your use.

But they are not the traditional way to write min and max. That was the
main point I was making.

--
Ben.

[Steve Carroll]

The content is a bunch of randomized Larry 'The Moron' Washington-like crap. We know there are only a few people who do that.

My uptime is almost forty-one weeks and them the facts, Jack!

Nobody is being controlled by a corporation.



-
Puppy Videos
https://www.reddit.com/r/linux/comments/6sfkup/what_desktop_tasks_does_linux_handle_better_than/=
https://groups.google.com/forum/#!topic/comp.os.linux.advocacy/tzMH39QmAmU
http://www.5z8.info/lemon-party-redux_v1o7pm_nakedgrandmas.jpg
Jonas Eklundh Communication

[Christian Gollwitzer]

Am 18.06.18 um 22:19 schrieb Bart:

I don't see that. Even now, the \ character does lie continuation only
if it is immediately foloowed by a newline character. In case somebody
necessarily wants to break the expresssion over multiple lines, a space
can be inserted:

a /\<newline> -> line continuation

a /\<space><newline> -> /\ operator followed by newline

At least the pure \ character works flawlessly in other languages like
Matlab as an operator, it means "matrix left divide". I've done a
similar language, here is the PEG grammar:

https://github.com/auriocus/VecTcl/blob/master/generic/vexpr.peg#L66

As you can see in line 66, \ followed by newline is parsed as
"whitespace". Line 58 defines the backslash as a multiplicative operator.

Christian

[David Brown]

It is usually as an escape character, for writing characters like \n or
\t - I'd say line continuation was a good deal less common. But in
either case you'd risk ambiguities or complications. Using \ as part of
an operator would mean changing details of the C parsing. I'd expect it
to be doable, however.

[David Brown]

Yes, just like that :-)

[David Brown]

On 18/06/18 22:59, Rick C. Hodgin wrote:
> On 6/18/2018 4:29 PM, Ben Bacarisse wrote:
>> The cross post to comp.lang.c++ looks like a recipe for an unproductive
>> back and forth, so I've removed it in his reply which is about C only.
>>
>> "Rick C. Hodgin" <rick.c...@gmail.com> writes:
>>
>>> // Traditional way
>>
>> No, I think the traditional way is safer. Let's not start unsafe
>> traditions.
>>
>>> #define min(a, b) ((a <= b) ? a : b)
>>> #define max(a, b) ((a >= b) ? a : b)
>
> See below.
>
>> You have redundant parentheses and missing parentheses. You should
>> write:
>>
>> #define min(a, b) ((a) <= (b) ? (a) : (b))
>> #define max(a, b) ((a) >= (b) ? (a) : (b))
>
> That method works great for most people, but when my dyslexia brain tries
> to read what you've written, it's a jumbled mass of confusion which all
> runs together. It's hard to break out where one thing stops and another
> starts because they all look the same.
>
> The extra parentheses enable me to see the differentiating parts more
> easily in source code.
>

I also like to have an extra parenthesis around the condition for ?. My
own dyslexia is very mild (the main symptoms are appalling spelling and
handwriting), but I too prefer a little extra parenthesis in some cases.

But while those ones are up to you, the ones around "a" and "b" are
traditional because they are often very useful.

>> though adding extras is not a problem. In this case they are not all
>> needed, but it's simpler to remember the rule: put the whole expansion
>> in ()s as well as every instance of a macro parameter name.
>
> I've never had a case where I've needed the extra parenthesis you and
> David have inserted in a min/max macro. I'm open to see a real-world
> example where it would be too ambiguous and the extra parentheses would
> actually be required.
>

They are not going to be a big issue here as the ternary operator has
such low precedence, as does the comparison. And once you start using
lower precedence operators like "+=" in the arguments, you get more
problems to complicate matters.

So let's take a simpler example:

#define square(x) (x * x)

That's fine when you write:

y = square(a);

But what about:

y = square(a + b);

That expands to:

y = (a + b * a + b);

If you had:

#define square(x) ((x) * (x))

you'd get:

y = ((a + b) * (a + b));

which is what you want.


Thus the tradition for function-like macros is that you always put
parenthesis around the arguments, and you always put extra parenthesis
around the final result. And especially if the macro is not safe for
arguments with side-effects or not safe in an "if" statement, use
capitals in its name as a warning.

[Juha Nieminen]

In comp.lang.c++ red floyd <dont....@its.invalid> wrote:
> Not to mention that the "correct" way to do the "traditional" way is
> #define min(a,b) (((a) <= (b)) ? (a) : (b))
> #define max(a,b) (((a) >= (b)) ? (a) : (b))

Which is very bad because a or b will be evaluated twice, which can be
bad for many reasons. For starters, if they are very heavy to evaluate
(eg. they are function calls that perform some heavy calculations),
it will take twice as long as necessary. More damningly, if either a
or b have any side-effects, those side-effects will be applied twice,
which may break things. (Side effects don't always necessarily
affect the variable itself, like in min(a++, b++), but can affect
other things somewhere else.)

[Louis Krupp]

In my experience, the backslash has *always* been an escape
character, and I would expect using it for anything else to be a
well-intentioned but unpopular and ultimately disastrous effort.

Off the top of my head -- and based on absolutely no relevant
experience -- I would expect the addition of a new digraph or trigraph
to be almost as unpopular but with a better chance at success.

Louis

[David Brown]

Of course. That is why the traditional way is to call these MIN and
MAX, not min and max, as a warning to users that they are macros and you
should not "call" them with arguments with side-effects.

[Chris Vine]

All macro systems for languages with side effects and eager evaluation
run into the problem of side-effectful arguments, and the normal way
around that when writing a macro for such languages is to assign the
value of each argument to a local variable at the beginning of the macro
definition. The problem with that in the case of C and C++ is that
pre-processor macros are unhygienic and inject local variable names
into the call site[1].

The way around that in C and C++ is to put every macro definition with
local variables within its own statement block. But then you have the
problem that in C++ statement blocks are not expressions (they cannot
return values). So you end up having to pass in an additional argument
as an out parameter.

So you could have something like this as a mostly hygienic version of
MAX:

#define MAX(a, b, res) {auto aa = a; auto bb = b; res = (((aa) >= (bb)) ? (aa) : (bb));}

Yuck. As you have said, for something simple like 'max' and 'min',
template functions are much to be preferred in C++. They also have the
advantage that they can be made variadic.

Chris

[1] Less problematically, pre-processor macros also resolve external
identifier names used in the macro (in particular, function and operator
names) from the macro's call site and not from its definition site.
Hygienic macro systems do not do this.

[Rick C. Hodgin]

On 6/18/2018 7:05 PM, Ben Bacarisse wrote:
> I'm sure you know (or at
> least you know how to find out) exactly what argument expressions will
> be problematic.

Turns out it's a moot point. I looked in my code and I do use the extra
parenthesis you indicate, along with the extra parenthesis around the
test part of the expression.

Lines 375-380 as of the time of this writing:

http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/source/vjr/source/vjr_const.h

#ifndef max

#define max(a,b) (((a) >= (b)) ? (a) : (b))

#endif
#ifndef min

#define min(a,b) (((a) <= (b)) ? (a) : (b))

#endif

I think you all are wearing off on me. So ... time to double my efforts
on CAlive before I'm totally corrupted. :-)

--
Rick C. Hodgin

[Rick C. Hodgin]

On 6/19/2018 8:21 AM, Stefan Ram wrote:

> Louis Krupp <lkr...@nospam.pssw.com.invalid> writes:
>> Off the top of my head -- and based on absolutely no relevant
>> experience -- I would expect the addition of a new digraph or trigraph
>> to be almost as unpopular but with a better chance at success.
>

> On could use "⊤" for "max" and "⊥" for "min" akin to
> their usage in lattice theory.
>
> 2 ⊥ 8 == 2
> 2 ⊤ 8 == 8


That's not a standard character. How would you propose it be input
into the text editor by people seeking to use it?

--
Rick C. Hodgin

[David Brown]

The way around this, whenever possible, is to use inline functions
rather than function-like macros. In C++, templates let you generalise
such functions - in C, C11 generics give you a more limited and
cumbersome solution, but enough to write safe min or max macros.

And some compilers (gcc and clang, maybe others) recognised this
limitation long ago and introduced an extension to give you statement
blocks with expression values. Whether or not you want to use such
extensions, is another matter.

>
> So you could have something like this as a mostly hygienic version of
> MAX:
>
> #define MAX(a, b, res) {auto aa = a; auto bb = b; res = (((aa) >= (bb)) ? (aa) : (bb));}
>
> Yuck. As you have said, for something simple like 'max' and 'min',
> template functions are much to be preferred in C++. They also have the
> advantage that they can be made variadic.
>

With enough effort, you can get a variadic hygienic polymorphic min and
max macro in C11. But it is not nearly as neat as with C++ templates,
or, even better, C++ concepts:

auto max(auto a, auto b) {
return (a >= b) ? a : b;
}

It's hard to get neater than that!

(With concepts, you could add addition constraints that would improve
compile-time errors.)

[David Brown]

They are standard unicode characters, but I don't think they are
standard for maximum or minimum. In lattice theory, they are symbols
for "top" and "bottom" - the maximum of all elements, and the minimum of
all elements. You would normally use ∨ or ∧ for maximum and minimum -
or \/ and /\, or v and ^, if you are restricted to ASCII. Another
alternative would be ⊔ and ⊓.

That reminds me - in maths, "a ∨ b" is the /maximum/ and "a ∧ b" is the
minimum, while you wanted to use the opposite symbols. I believe you
are familiar with boolean logic - "a ∨ b" is a way to write "a inclusive
or b", which is the maximum of two boolean values. If you like
axiomatic set theory and the Peano integers, then "maximum" is the same
as set union ∪, and "minimum" is set intersection ∩.

All these symbols have the disadvantage that they are difficult to type
with normal keyboard layouts - you need a character map applet, ugly
unicode-by-number input, or you would have to tweak your keyboard layout
files or compose key files (easy enough on *nix if you know what you are
doing, a good deal more difficult on Windows AFAIK). On my keyboard, I
can easily type ↓ and ↑, which would be an option - but that will not
apply to everyone.

[Rick C. Hodgin]

I don't think so. While it's theoretically possible to break existing
code, it would have to be a very specific form, and it would be easy
to generate a diagnostic on /\ when it's declared as the last thing on
a line, that there may be ambiguity.

I look at additions like this to the language as a new thing, such that
it would introduce new processing logic to the compiler, and therefore
comments like "...won't work for obvious reasons" are rendered of none
effect (due to the enhancements to the compiler's parsing engineb).

--
Rick C. Hodgin

[Rick C. Hodgin]

On 6/19/2018 9:14 AM, David Brown wrote:
> On 19/06/18 14:31, Rick C. Hodgin wrote:
> That reminds me - in maths, "a ∨ b" is the /maximum/ and "a ∧ b" is the
> minimum, while you wanted to use the opposite symbols. I believe you
> are familiar with boolean logic - "a ∨ b" is a way to write "a inclusive
> or b", which is the maximum of two boolean values. If you like
> axiomatic set theory and the Peano integers, then "maximum" is the same
> as set union ∪, and "minimum" is set intersection ∩.

Never heard of it. I think "a ∨ b" is confusing as a maximum, and
likewise "a ∧ b" is confusing as a minimum. I like the idea of the
arrow pointing up or down for max or min.

> All these symbols have the disadvantage that they are difficult to type
> with normal keyboard layouts - you need a character map applet, ugly
> unicode-by-number input, or you would have to tweak your keyboard layout
> files or compose key files (easy enough on *nix if you know what you are
> doing, a good deal more difficult on Windows AFAIK). On my keyboard, I
> can easily type ↓ and ↑, which would be an option - but that will not
> apply to everyone.

CAlive will use /\ for max, and \/ for min, and /\= for max assignment,
and \/= for min assignment. Other languages are free to use whatever
other syntaxes they choose.

You can always add this to CAlive to make it work otherwise:

#define ∨ /\
#define ∧ \/

Or:

#define ↑ /\
#define ↓ \/

And then you're good to go.

--
Rick C. Hodgin

[Ben Bacarisse]

Wildly off-topic now...

David Brown <david...@hesbynett.no> writes:
<snip>

> That reminds me - in maths, "a ∨ b" is the /maximum/ and "a ∧ b" is the
> minimum, while you wanted to use the opposite symbols. I believe you
> are familiar with boolean logic - "a ∨ b" is a way to write "a inclusive
> or b", which is the maximum of two boolean values. If you like
> axiomatic set theory and the Peano integers, then "maximum" is the same
> as set union ∪, and "minimum" is set intersection ∩.

Peano's axioms don't define numbers as sets. You are thinking of von
Neumann's construction of the naturals as sets. They can be used to
build a model of Peano arithmetic that has the property you state. But
other constructions are possible (such a Zermelo's or Frege's) which
give rise to models that don't have that property.

<snip>
--
Ben.

[supe...@casperkitty.com]

On Tuesday, June 19, 2018 at 5:28:25 AM UTC-5, Chris Vine wrote:
> The way around that in C and C++ is to put every macro definition with
> local variables within its own statement block. But then you have the
> problem that in C++ statement blocks are not expressions (they cannot
> return values). So you end up having to pass in an additional argument
> as an out parameter.

A problem which gcc managed to solve even before the C89 Standard was
published, quashing such innovation.

[Chris Vine]

On Tue, 19 Jun 2018 14:43:22 +0200
David Brown <david...@hesbynett.no> wrote:
[snip]

> With enough effort, you can get a variadic hygienic polymorphic min and
> max macro in C11.

Do you know enough about C11 macros to show how that is done? (I would
be interested for that matter in how you get a non-variadic hygienic
macro in C, if that is by using a different technique from the one I
mentioned. I am still stuck on C89/90 as far as C pre-processors are
concerned.)

[David Brown]

Yes, it was the von Neumann construction I was thinking of. It's quite
a number of years since I studied this stuff!

[David Brown]

On 19/06/18 15:27, Rick C. Hodgin wrote:
> On 6/19/2018 9:14 AM, David Brown wrote:
>> On 19/06/18 14:31, Rick C. Hodgin wrote:
>> That reminds me - in maths, "a ∨ b" is the /maximum/ and "a ∧ b" is the
>> minimum, while you wanted to use the opposite symbols. I believe you
>> are familiar with boolean logic - "a ∨ b" is a way to write "a inclusive
>> or b", which is the maximum of two boolean values. If you like
>> axiomatic set theory and the Peano integers, then "maximum" is the same
>> as set union ∪, and "minimum" is set intersection ∩.
>
> Never heard of it. I think "a ∨ b" is confusing as a maximum, and
> likewise "a ∧ b" is confusing as a minimum. I like the idea of the
> arrow pointing up or down for max or min.
>

Whether or not /you/ find it confusing, this is how it is used in
mathematics. You can decide that your language will never be of
interest to mathematicians or people who know about boolean logic, and
pick symbols that are the direct opposite of the standard. In the same
way, you can decide that your booleans will use "oui" for false and
"non" for true on the basis that you don't know French and don't care
about confusing Frenchmen.

Maximum and minimum are not so common operations that they need an
operator. Few programming languages have them as operators - many have
them as built-in functions named "max" and "min". That would seem to me
to be the best approach, avoiding confusing anyone.

It's your language. Listen to the advice you are given, or make the
decisions on your own - it's up to you. But remember that every step
you take that is against the flow limits the likelihood of anyone other
than you ever using the language.

[Rick C. Hodgin]

On 6/19/2018 11:08 AM, David Brown wrote:
> On 19/06/18 15:27, Rick C. Hodgin wrote:
>> On 6/19/2018 9:14 AM, David Brown wrote:
>>> On 19/06/18 14:31, Rick C. Hodgin wrote:
>>> That reminds me - in maths, "a ∨ b" is the /maximum/ and "a ∧ b" is the
>>> minimum, while you wanted to use the opposite symbols. I believe you
>>> are familiar with boolean logic - "a ∨ b" is a way to write "a inclusive
>>> or b", which is the maximum of two boolean values. If you like
>>> axiomatic set theory and the Peano integers, then "maximum" is the same
>>> as set union ∪, and "minimum" is set intersection ∩.
>>
>> Never heard of it. I think "a ∨ b" is confusing as a maximum, and
>> likewise "a ∧ b" is confusing as a minimum. I like the idea of the
>> arrow pointing up or down for max or min.
>>
>
> Whether or not /you/ find it confusing, this is how it is used in
> mathematics. You can decide that your language will never be of
> interest to mathematicians or people who know about boolean logic, and
> pick symbols that are the direct opposite of the standard.

I think very few people will use CAlive, David. I think those who do
will be of a particular mindset and it will work for them. It's been
demonstrated below how to fix it up for those who have need.

>> CAlive will use /\ for max, and \/ for min, and /\= for max assignment,
>> and \/= for min assignment. Other languages are free to use whatever
>> other syntaxes they choose.
>>
>> You can always add this to CAlive to make it work otherwise:
>>
>> #define ∨ /\
>> #define ∧ \/
>>
>> Or:
>>
>> #define ↑ /\
>> #define ↓ \/
>>
>> And then you're good to go.

I would like to see these operators and operator assignments added to
the C programming language, as well as C++. If they choose to use the
opposite direction then CAlive will support it.

--
Rick C. Hodgin

[Steve Carroll]

Troll Killer Snit pwns Jonas Eklundh in every way possible.

"You are never up to anything good" said Jonas Eklundh's boyfriend.

You saying something is so does not make it true.



--
Get Rich Slow!
http://www.5z8.info/horse-slaughter_w8c4en_launchexe
Jonas Eklundh Communication AB

[Rick C. Hodgin]

On 6/19/2018 11:08 AM, David Brown wrote:

> ...remember that every step

> you take that is against the flow limits the likelihood of anyone other
> than you ever using the language.

These are new features, David. They don't have to be used.

-----
I wouldn't waste my time worrying about anything related to me or CAlive.
The language and my offering of its abilities will be given to people.
It will either be received or not, but my effort is in the giving, not in
its success. I seek to give people the best tool with the most features
available, and I am going the extra mile to make it be compatible with C,
and some of C++. This is my offering to the Lord first, and people second.

If I get it completed before leave this world, it will be given to people
for free, unencumbered, source code and all, in a variant of the public
domain license (where each person who receives it is asked to use it in a
proper manner, giving their changes and enhancements to people as they also
received it, but I don't force it by man's legal authority, but only leave
it between them and God to voluntarily follow that guidance).

But regardless, each person can choose what to do with these skills the
Lord first gave me that I have, in return, given back to Him first, and
to each of you second.

-----
When it's released, use it, don't use it. It won't bother me. I am
doing the best I can for my Lord. I am not receiving help in the form
of productive work on the project. Nobody's written a line of source
code on it. The entire creation is my authoring, my doing. And I am
proceeding despite receiving only constant criticism on the choices I
make.

At some point you'll have to realize I'm not doing this for you, David,
or anyone else who is critical of my work. I'm doing it for the Lord,
and for those who will receive it.

It is the same thing Jesus offers people with salvation. He will not
save those who reject Him, but for all who come to Him, He gives them
forgiveness and eternal life.

CAlive is my best offering along those lines. I give it freely to
people, and they will choose to receive it or reject it, but my offer-
ing will tie back explicitly to my giving the Lord the best of what He
first gave me.

As I say, I wouldn't waste my time worrying about anything related to me
or CAlive, David. Life's too short. Let it go.

--
Rick C. Hodgin

[Keith Thompson]

David Brown <david...@hesbynett.no> writes:
[...]

> It is usually as an escape character, for writing characters like \n or
> \t - I'd say line continuation was a good deal less common. But in
> either case you'd risk ambiguities or complications. Using \ as part of
> an operator would mean changing details of the C parsing. I'd expect it
> to be doable, however.

It would require changing translation phase 2, which is where line
splicing occurs.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Which is why it's traditional to write macro names in all-caps (MIN()
and MAX()) so the reader is reminded that they're macros and can have
odd interactions with side effects.

[Steve Carroll]

Too much glue for you, Gluehead.

Linux offers the least of everything to the average user.

For others I'd just think it is suspicious. However, given that it's Chris Ahlstrom I would skip that doubt and go straight to 'drug-induced delusion' because that's most of what he does. It is faster to assume it is a lie until proved otherwise. Pro tip: You can not go into a social event, gulp down all the rotgut, violate all the chicks, help oneself to the bibles, and lose your lunch in the loo without being mocked. I think the point is not 100% to get Jonas Eklundh to listen to him. The point is likely to piss Jonas Eklundh off for trolling outside groups he knows I frequent. What Bash looks like is irrelevant and not tied to its functionality, especially if it's hackable.

--
Puppy Videos
http://www.5z8.info/trojan_p4g1zy_how-to-skin-a-gerbil
Jonas Eklundh Communication AB

[Keith Thompson]

David Brown <david...@hesbynett.no> writes:
[...]

> That reminds me - in maths, "a ∨ b" is the /maximum/ and "a ∧ b" is the
> minimum, while you wanted to use the opposite symbols. I believe you
> are familiar with boolean logic - "a ∨ b" is a way to write "a inclusive
> or b", which is the maximum of two boolean values. If you like
> axiomatic set theory and the Peano integers, then "maximum" is the same
> as set union ∪, and "minimum" is set intersection ∩.

I would oppose defining either "a ∨ b" or "a \/ b" as max(a, b)
because most readers (myself included) are going to assume the
symbol means "min".

I would oppose defining either "a ∨ b" or "a \/ b" as min(a, b)
because it's apparently the opposite of mathematical usage.

I'm not at all convinced that min and max operators, with whatever
syntax, are worth adding to the language at all. If they were to be
added, agreeing on a syntax would be difficult.

[Steve Carroll]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Gee, no on saw more forgeries coming. LOL!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.28
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWJpfjAAoJEC03b6bOr/+drC0P/RZBxcLK8eFZ7QUKjlqJRqfj
66udasAYnovhi+C1bpBxXZIm8Xxg2+JDdVoMfw/d+5R8+KpEXpxK+4y9GB8NuBBz
98+LuNNIus0cXJ6goCyKZj5FUajHYIhgoEAb+O8F0pYMcqv08R39IddgVEQCasDZ
9QPXlQco0QOSD49BArlDa7qgwi17Rs2zkYnw27jEIVEuYlfhqj2T7Mcirwby4JD3
+1Geq5kCdeCtMG+z6gAdth0akrSMlYLAnixbYolEFm6wtg7DW2BrwVo7NTY8Zuy1
UjRrn8JAoHrCec82HulrBBEXC/dhti2SIszDnt1GnZSTB33p1plQgklUmmqN8Qvu
To/TAz07YWAeUHcYSyHzmJuVbL0r9emcQD/AfB8CxAhh+p5F5kc2hfwAOmJ4cGpV
+kIqUp7N1UXqSOXnFyxYz4HJv9/c0UPNXSY2QDPmaWd7AFrB80BcOw2yVS30jQwo
QhBtvoj2t/FJi/G7KnIpGYl3ZFy7QxtNL6PnPW5y46EjzDbNEnMbETTxAzI24QGw
x5xgyhdiyRnpCvyHFd21d09bYOrBHH6qe3NMVTRBPjh1MUaw1E8WhQo916Zvk4jz
pD23EIt9uk79a2aD+EbC/vZHLPGTqlbI1bmYV5KlzJusIO2i939Cs/AhYcdM8mEQ
WqdC0S1YIC7GfYk7riFe
=F3OP
-----END PGP SIGNATURE-----

--
Get Rich Slow
http://alt.conspiracy.narkive.com/QcWYJ4Px/the-mentally-ill-mark-s-bilk
https://groups.google.com/forum/#!topic/alt.os.linux/BVpdH5KOc6s
https://youtu.be/dNhvVfD4zu4
Jonas Eklundh Communication AB

[Rick C. Hodgin]

On 6/19/2018 12:32 PM, james...@alumni.caltech.edu wrote:

> On Monday, June 18, 2018 at 2:54:55 PM UTC-4, Rick C. Hodgin wrote:
>> Is there a native operator for min and max in C or C++?
>>
>> // Traditional way

>> #define min(a, b) ((a <= b) ? a : b)
>> #define max(a, b) ((a >= b) ? a : b)
>>

>> int a, b, c, d;
>>
>> a = 5;
>> b = 8;

>>
>> // Assign min and max:
>> c = min(a, b); d = max(a, b);
>>
>> Is there an operator for this? Like /\ for max, \/ for min?
>>

>> // Assign min and max using operators:
>> c = a \/ b; d = a /\ b;
>>
>> Or min/max-assignment operators?
>>
>> // Min of b and a is assigned to b
>> b \/= a; // Equivalent of b = min(b, a)
>>
>> // Max of b and a is assigned to b
>> b /\= a; // Equivalent of b = max(b, a)
>
> In IDL, "a < b" gives the minimum of a or b, and "a > b" gives the
> maximum. This can be particularly useful when either operand is an
> array. "a lt b" and "a gt b" are how you do the equivalent of C's
> "a < b" and "a > g". Most IDL newbies get burned with this at least once
> before learning that distinction.

I've tried to come up with a single-character operator for this. I
like Stefan's idea of the T-like character, and the inverted T-like
character, but they can't easily be typed. I suppose using T and !T
might work.

If anyone has better ideas, I'm all for them. So far, I like the
/\ max and \/ min combos. They can be rendered graphically in the
editor into some other character.

--
Rick C. Hodgin

[Mr Flibble]

You like them? So what? They would never make it into C++ and we don't
care about your kooky god bothering custom language.

--
"Suppose it’s all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I’d say, bone cancer in children? What’s that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It’s not right, it’s utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That’s what I would say."

[David Brown]

On 19/06/18 17:47, Rick C. Hodgin wrote:

> As I say, I wouldn't waste my time worrying about anything related to me
> or CAlive, David.  Life's too short.  Let it go.
>

I am not worrying about you or CAlive. I'm just giving general advice
to people who post in groups I follow. Perhaps my posts will help
people, perhaps they will lead to discussions, perhaps I will learn from
other posts. That's my motivation. Whether you agree with what I write
or not is up to you - I really don't mind one way or the other.

[Rick C. Hodgin]

On 6/19/2018 2:18 PM, David Brown wrote:
> I am not worrying about you or CAlive.

Good to hear.

--
Rick C. Hodgin

[David Brown]

On 19/06/18 18:18, Keith Thompson wrote:
> David Brown <david...@hesbynett.no> writes:
> [...]
>> That reminds me - in maths, "a ∨ b" is the /maximum/ and "a ∧ b" is the
>> minimum, while you wanted to use the opposite symbols. I believe you
>> are familiar with boolean logic - "a ∨ b" is a way to write "a inclusive
>> or b", which is the maximum of two boolean values. If you like
>> axiomatic set theory and the Peano integers, then "maximum" is the same
>> as set union ∪, and "minimum" is set intersection ∩.
>
> I would oppose defining either "a ∨ b" or "a \/ b" as max(a, b)
> because most readers (myself included) are going to assume the
> symbol means "min".
>

Agreed.

> I would oppose defining either "a ∨ b" or "a \/ b" as min(a, b)
> because it's apparently the opposite of mathematical usage.

Agreed.

>
> I'm not at all convinced that min and max operators, with whatever
> syntax, are worth adding to the language at all. If they were to be
> added, agreeing on a syntax would be difficult.
>

Agreed.

The mathematical usage of these symbols can be surprising to people not
familiar with these fields. And even those that know them - for
example, in boolean logic - may not have considered them as maximum and
minimum operators. But I would be opposed to having symbol choices that
are a direct opposite of the mathematical ones.

So /if/ I were adding such operators to a language (and I almost
certainly would not), I'd be inclined to look at something different -
such as the old gcc <? and >? operators. Perhaps APL's maximum and
minimum operators a⌈b and a⌊b would be an option with existing practice,
but which would be equally unknown to almost everyone.

[David Brown]

On 19/06/18 18:01, Keith Thompson wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
>> In comp.lang.c++ red floyd <dont....@its.invalid> wrote:
>>> Not to mention that the "correct" way to do the "traditional" way is
>>> #define min(a,b) (((a) <= (b)) ? (a) : (b))
>>> #define max(a,b) (((a) >= (b)) ? (a) : (b))
>>
>> Which is very bad because a or b will be evaluated twice, which can be
>> bad for many reasons. For starters, if they are very heavy to evaluate
>> (eg. they are function calls that perform some heavy calculations),
>> it will take twice as long as necessary. More damningly, if either a
>> or b have any side-effects, those side-effects will be applied twice,
>> which may break things. (Side effects don't always necessarily
>> affect the variable itself, like in min(a++, b++), but can affect
>> other things somewhere else.)
>
> Which is why it's traditional to write macro names in all-caps (MIN()
> and MAX()) so the reader is reminded that they're macros and can have
> odd interactions with side effects.
>

Personally, I am not a fan of all-caps macro names in general. But I
think they help in cases like this, where they indicate that you have to
avoid side-effects (or be /really/ sure you know what you are doing!).
If a function-like macro is as safe as a function - perhaps using gcc's
extensions here - then I prefer a small letter name.

[Robert Wessel]

On Tue, 19 Jun 2018 20:26:31 +0200, David Brown
<david...@hesbynett.no> wrote:

>On 19/06/18 18:18, Keith Thompson wrote:
>> David Brown <david...@hesbynett.no> writes:
>> [...]

>>> That reminds me - in maths, "a ? b" is the /maximum/ and "a ? b" is the

>>> minimum, while you wanted to use the opposite symbols. I believe you

>>> are familiar with boolean logic - "a ? b" is a way to write "a inclusive

>>> or b", which is the maximum of two boolean values. If you like
>>> axiomatic set theory and the Peano integers, then "maximum" is the same

>>> as set union ?, and "minimum" is set intersection ?.
>>
>> I would oppose defining either "a ? b" or "a \/ b" as max(a, b)

>> because most readers (myself included) are going to assume the
>> symbol means "min".
>>
>
>Agreed.
>

>> I would oppose defining either "a ? b" or "a \/ b" as min(a, b)

>> because it's apparently the opposite of mathematical usage.
>
>Agreed.
>
>>
>> I'm not at all convinced that min and max operators, with whatever
>> syntax, are worth adding to the language at all. If they were to be
>> added, agreeing on a syntax would be difficult.
>>
>
>Agreed.
>
>The mathematical usage of these symbols can be surprising to people not
>familiar with these fields. And even those that know them - for
>example, in boolean logic - may not have considered them as maximum and
>minimum operators. But I would be opposed to having symbol choices that
>are a direct opposite of the mathematical ones.
>
>So /if/ I were adding such operators to a language (and I almost
>certainly would not), I'd be inclined to look at something different -
>such as the old gcc <? and >? operators. Perhaps APL's maximum and

>minimum operators a?b and a?b would be an option with existing practice,

>but which would be equally unknown to almost everyone.

Old HP-2000 BASIC just used MIN and MAX as the binary infix operators.
I also remember another language, which I can't remember right now,
that also had binary infix MIN and MAX operators, but used them in the
reverse sense (a MAX 10) would be interpreted as use A, but with a
maximum value of 10, so in effect it was what was more commonly MIN
IIRC, it also had more conventional MIN() and MAX() functions.
Presumably I remember that because it bit me on the posterior.

Probably not very applicable to C.

[David Brown]

#define make_max(name, type) \
static inline type max_ ## name (type a, type b) { return a > b ? a
: b; }

make_max(char, char)
make_max(uchar, unsigned char)
make_max(schar, signed char)
make_max(short, short)
make_max(ushort, unsigned short)
make_max(int, int)
make_max(uint, unsigned int)
make_max(long, long)
make_max(ulong, unsigned long)
make_max(llong, long long)
make_max(ullong, unsigned long long)
make_max(float, float)
make_max(double, double)
make_max(ldouble, long double)


#define max(a, b) _Generic((a), \
char : max_char, unsigned char : max_uchar, signed char : max_schar, \
short : max_short, unsigned short : max_ushort, \
int : max_int, unsigned int : max_int, \
long : max_long, unsigned long : max_ulong, \
long long : max_llong, unsigned long long : max_ullong, \
float : max_float, double : max_double, long double : max_ldouble \
)(a, b)

[David Brown]

You can persuade C++ to use MIN and MAX as binary infix operators. I am
far from convinced it would be a good idea, but it is possible.

[Alf P. Steinbach]

On 19.06.2018 18:18, Keith Thompson wrote:
> David Brown <david...@hesbynett.no> writes:
> [...]
>> That reminds me - in maths, "a ∨ b" is the /maximum/ and "a ∧ b" is the
>> minimum, while you wanted to use the opposite symbols. I believe you
>> are familiar with boolean logic - "a ∨ b" is a way to write "a inclusive
>> or b", which is the maximum of two boolean values. If you like
>> axiomatic set theory and the Peano integers, then "maximum" is the same
>> as set union ∪, and "minimum" is set intersection ∩.
>
> I would oppose defining either "a ∨ b" or "a \/ b" as max(a, b)
> because most readers (myself included) are going to assume the
> symbol means "min".
>
> I would oppose defining either "a ∨ b" or "a \/ b" as min(a, b)
> because it's apparently the opposite of mathematical usage.

Both are good points.

But let's look at things from the boolean operations point of view.

I'd like "or" (and operator "||" which means the same) to just mean "max".

That way it would work nicely with three-value boolean logic.

Like, false, maybe and true as 0, 1 and 2.

E.g. or( false, maybe) == max( false, maybe ) == maybe.

> I'm not at all convinced that min and max operators, with whatever
> syntax, are worth adding to the language at all. If they were to be
> added, agreeing on a syntax would be difficult.

Maybe the time has come for more Unicode symbols in programming languages.

Just not all the way to APL...


Cheers!

- Alf

[Chris Vine]

On Tue, 19 Jun 2018 21:12:11 +0200

Thanks, that's interesting. So far as I understand it comprises a
macro which constructs a series of inline functions, which is combined
with another generic macro which calls one of them, depending on type.
Somewhat like a template function in C++ but with more boilerplate.

The macros themselves would still be unhygienic but that wouldn't
matter here.

[luser droog]

APL uses the same symbol for the dyadic function max() and the monadic
function ceiling() viz. ⌈ which is one half of the typical mathematics notation for ceiling.

APL uses the same symbol for the dyadic function min() and the monadic
function floor() viz. ⌊ which is one half of the typical mathematics
notation for floor.

So I suggest these. x⌈y == max(x,y), x⌊y == min(x,y)

[Rick C. Hodgin]

On 6/19/2018 7:42 PM, luser droog wrote:
> So I suggest these. x⌈y == max(x,y), x⌊y == min(x,y)

How do you recommend we type those symbols? Some of us will be using
ssh access into a remote computer, then using text-based editors like
nano or emacs. Those characters are not standard and they'll be hard
to implement.

I think for CAlive I'm going to use /\ max and \/ min, and then people
can #define their preferred character and use it as they wish.

I think using those standard characters will be easier for all, and a
small learning curve for some. But, people can also use min() and
max() if it works better for them.

--
Rick C. Hodgin

[Steve Carroll]

Having to endure the use of Linux it can hardly be called "free" when you include your time.

Habits change. Maybe the ubiquity of a newspaper is getting past its prime. Can you knock off begging for my attention?

This forum is a leaking porta potty. For most I would simply suggest it is doubtful. Given that it's Just 'The Shill' Wondering I would forget that step and go straight to 'ego-trip' because that's most of what he does. Innocent until proven guilty does not apply to Just 'The Shill' Wondering.

--
"You'll notice how quickly he loses interest when everything is about him. He clearly wants the attention"
Steven Petruzzellis, making the dumbest comment ever uttered.

[luser droog]

On Tuesday, June 19, 2018 at 6:53:10 PM UTC-5, Rick C. Hodgin wrote:
> On 6/19/2018 7:42 PM, luser droog wrote:
> > So I suggest these. x⌈y == max(x,y), x⌊y == min(x,y)
>
>
> How do you recommend we type those symbols? Some of us will be using
> ssh access into a remote computer, then using text-based editors like
> nano or emacs. Those characters are not standard and they'll be hard
> to implement.

I do have some ideas about reinventing the keyboard but they're not
ready for prime time yet. But it would be nice to combine the advantages
of screen-based keyboards which can change configuration and keycaps
with the haptic feedback of nastoyashee clickity clacks.

> I think for CAlive I'm going to use /\ max and \/ min, and then people
> can #define their preferred character and use it as they wish.
>
> I think using those standard characters will be easier for all, and a
> small learning curve for some. But, people can also use min() and
> max() if it works better for them.

Have you looked at the OLPC XO-1 and the old Alan Kay Dynabook project?
If it's a useful function, maybe stick on the keyboard itself. Like
APL did.

[Steve Carroll]

Steve "Steven Petruzzellis" Carroll's obsession with Flooder Carroll started in 2004 when Carroll got mad about his then girlfriend obsessing over Flooder Carroll (heavily documented here: <http://tinyurl.com/proof-about-ebot>). Flooder Carroll continued to respond to Steve for about 5 years, when Steve flipped out in 2009 and started contacting Flooder Carroll's employer with the stated goal to have him fired (he spoke of doing so even if he had to twist arms):

<http://goo.gl/OHNryA>
<http://goo.gl/MZ6yCD>
<http://goo.gl/WaKKGq>

There were more, but Carroll has had them deleted from the Google archive. I have not spent the time to find them elsewhere (and likely will not).

With that Flooder Carroll stopped responding directly to Steve except for *one* chance he gave him in 2011 when Steve was accusing *Flooder Carroll* of running: <http://goo.gl/racU64>.

Carroll, as predicted, ran (he always does when faced with facts):
<http://goo.gl/qHs5Xh>

Steven Petruzzellis knows he has no backing for any of his nonsense and has become, if anything, more and more obsessive since Flooder Carroll stopped responding to him.

Steve "Steven Petruzzellis" Carroll is truly a very, very sick man.

--
E-commerce Simplified
http://www.5z8.info/mercenary_w5v9dl_open.exe
http://www.5z8.info/gruesome-gunshot-wounds_t5z0au_cockdock.gif
Jonas Eklundh Communication

[David Brown]

By "unhygienic", do you mean they don't act like functions in the way
they handle parameters with side effects, or have multiple statements to
cause trouble in conditionals or loops without braces? No, the "max"
macro is not "unhygienic" - it is perfectly safe. It is fine to worry
about function-like macros that have risks, like the traditional C "max"
(or "MAX") macro. But labelling safe macros as "unhygienic" sounds like
prejudice.

(The "make_max" is a utility macro to reduce typing and the risk of
copy-and-paste errors - it is not a function-like macro.)

[Steve Carroll]

Steve Petruzzellis claims to be the scripting authority. Let us see him put up a form but lacking the data correction routines.

Steve Petruzzellis's posts are really entirely dishonest. There's zero question that as soon as any pardoned 'plonked person' does whatever to annoy the poor loser's feelings that they'll be put right back in the kill filter.

It was Steve Petruzzellis who got busted using tons of forgeries like a moron, and these are 'people' who come clearly out of the blue immediately into threads where he was being proved wrong... over and over for years. Geeeejus! How did Steve Petruzzellis get *so* self-centered he believes everything is about his comments?? By the way, spending time learning is never wasted time. Asserting you know everything and working to convince Sandman that it's true, as Steve Petruzzellis tries to do? That is a waste ;)

That lame duck update system failed over and over again.



--
Puppy Videos
http://www.macadvocacy.pw/2005/Nov/09/236626.html
http://www.5z8.info/facebook-of-sex_w4l4wg_bomb
Michael Glasser: Prescott Computer Guy
http://prescottcomputerguy.com
Jonas Eklundh

[Chris Vine]

On Wed, 20 Jun 2018 08:06:27 +0200

By "unhygienic" I mean that C89/90 macros (and as I understand it
from your example, also C11 macros) are "cut and paste" pre-processor
macros. Such macros systems are by definition unhygienic macro
systems. A macro system is generally called unhygienic when it does
not bind identifiers in the way that functions do: in particular when
it binds identifiers at the call site and not the definition site and
when it injects its own identifier names into the call site; in short,
when it does something at macro expansion time which could cause
identifier names to be accidentally captured or shadowed.

It is wrong to say that the problem arising from invoking:

#define max(a,b) (((a) >= (b)) ? (a) : (b))

with (++a,++b) arguments is due to lack of hygiene in that sense.
Instead, the lack of hygience in C macros makes it more difficult to
resolve the problem in the traditional way, by initializing local
variables at the beginning of the macro definition to simulate eager
evaluation of the arguments. The vagaries of C syntax with respect to
statement blocks also contributes to that.

However, not all code that unhygienic macro systems emit is unsafe.
Where they are used to construct inline functions ('make_max' in your
example), and to hand off directly to such an inline function ('max' in
your example), that usage is safe. It is safe because inline functions
are hygienic. 'max' is just the textual substitution of a function
call, so unwanted identifier capture is irrelevant. That particular use
of the macro is hygienic.

The only criticism of your macro that one could make is that the
the binding of the '>' operator is taken at the point at which the
'make_max' macro is called and not at the point where that macro is
defined. That is not something that would bother me. (It might bother
some who are especially firm advocates of hygienic macro systsms.)

In summary, all your code seems to do is to act like a template
function. That's fine.

[Chris Vine]

On Wed, 20 Jun 2018 12:07:53 +0100
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
[snip]

> The only criticism of your macro that one could make is that the
> the binding of the '>' operator is taken at the point at which the
> 'make_max' macro is called and not at the point where that macro is
> defined. That is not something that would bother me. (It might bother
> some who are especially firm advocates of hygienic macro systsms.)

And of course in C, as opposed to C++, you cannot (I believe, I don't
know C as well as you) rebind operator > anyway, so it's not a problem.

[David Brown]

All C and C++ macros are based on text substitution - "cut and paste"
macros.

No, that does not make them "by definition unhygienic" - at best, you
are defining "unhygienic" as "what C macros are", which is not at all
helpful.

> A macro system is generally called unhygienic when it does
> not bind identifiers in the way that functions do: in particular when
> it binds identifiers at the call site and not the definition site and
> when it injects its own identifier names into the call site; in short,
> when it does something at macro expansion time which could cause
> identifier names to be accidentally captured or shadowed.
>

To me, "unhygienic" would mean there is a potential problem or hazard
with a particular macro - /not/ that all macros are "unhygienic" because
/some/ macros could have problems.

> It is wrong to say that the problem arising from invoking:
>
> #define max(a,b) (((a) >= (b)) ? (a) : (b))
>
> with (++a,++b) arguments is due to lack of hygiene in that sense.
> Instead, the lack of hygience in C macros makes it more difficult to
> resolve the problem in the traditional way, by initializing local
> variables at the beginning of the macro definition to simulate eager
> evaluation of the arguments. The vagaries of C syntax with respect to
> statement blocks also contributes to that.
>
> However, not all code that unhygienic macro systems emit is unsafe.
> Where they are used to construct inline functions ('make_max' in your
> example), and to hand off directly to such an inline function ('max' in
> your example), that usage is safe. It is safe because inline functions
> are hygienic. 'max' is just the textual substitution of a function
> call, so unwanted identifier capture is irrelevant. That particular use
> of the macro is hygienic.

The macro "max" as I gave it is hygienic - it is safe to use in most
practical ways, similar to a function.

>
> The only criticism of your macro that one could make is that the
> the binding of the '>' operator is taken at the point at which the
> 'make_max' macro is called and not at the point where that macro is
> defined. That is not something that would bother me. (It might bother
> some who are especially firm advocates of hygienic macro systsms.)

We are talking about /C/ here. Operators are "bound" when the
post-processed source is compiled.

I don't know what languages you have in mind with "hygienic macros", but
I think what you are talking about is "functions" or perhaps
"templates", not macros.

In C, there are many sorts of macros for many kinds of usage. For
function-like macros, you can divide them into two groups - "safe" ones
that treat parameters with side-effects in a similar manner to
functions, and "unsafe" ones that can cause trouble. (There is also the
issue of multi-statement macros having trouble with conditionals and
loops without braces - usually that can be avoided by the "do {} while
(0)" idiom.) If you want to call these two types of function-like
macros "hygienic" and "unhygienic", that's okay.

[David Brown]

You can't "rebind" it in C++ either - unless perhaps you mean having a
virtual operator> member for a class.

[supe...@casperkitty.com]

On Tuesday, June 19, 2018 at 6:53:10 PM UTC-5, Rick C. Hodgin wrote:
> On 6/19/2018 7:42 PM, luser droog wrote:
> > So I suggest these. x⌈y == max(x,y), x⌊y == min(x,y)

> I think for CAlive I'm going to use /\ max and \/ min, and then people
> can #define their preferred character and use it as they wish.

Although at I didn't like such notation when I encountered it, I think that
FORTRAN's original way of handling relational operators was actually not a
bad approach: use a sequence of letters marked on either side with periods
but no intervening quite space (perhaps require whitespace outside the
periods). Thus, one could say:

foo = bar .max. boz;

That would avoid the need to try to invent a symbols for each new operator,
since one could simply give most of them alphanumeric names. If there
weren't any whitespacing rules such operators might pose ambiguity if they
immediately followed structures (e.g. what should

blockEnd = &foo.bar.max.blockEnd;

do if blockEnd is a void*, and foo.bar is a struct that contains a
member .max which in turn has a pointer-type member also called blockEnd)?

While I think implementations would be required to treat the above as
equivalent to

blockEnd = &foo.bar .max. blockEnd;

I doubt that there is much production code that includes whitespace between
a structure-type lvalue and a following member-access construct, and thus
I don't think treating the space between "bar" and "max" as semantically
significant should pose a problem.

[supe...@casperkitty.com]

On Wednesday, June 20, 2018 at 7:13:38 AM UTC-5, David Brown wrote:
> On 20/06/18 13:07, Chris Vine wrote:
> > A macro system is generally called unhygienic when it does
> > not bind identifiers in the way that functions do: in particular when
> > it binds identifiers at the call site and not the definition site and
> > when it injects its own identifier names into the call site; in short,
> > when it does something at macro expansion time which could cause
> > identifier names to be accidentally captured or shadowed.
>
> To me, "unhygienic" would mean there is a potential problem or hazard
> with a particular macro - /not/ that all macros are "unhygienic" because
> /some/ macros could have problems.

The dialect that gcc processed when I first saw it--sometime around
1990--made it possible to write macros to do most things that could be
done with in-line functions, with behavior that would not be affected
by the calling context. For example, IIRC:

#define intmax(x,y) ({ int ZXQ99_qx=(x),ZXQ99_qy=(y); \
ZXQ99_qx > ZXQ99_qy ? ZXQ99_qx : ZXQ99_qy; })

Unless the arguments happened to make use of identifiers starting with
ZXQ99, the above expression would behave like a function call even if
the operands had side-effects. Unfortunately, the authors of C89 were
disinclined to add things to the language that might be tough for some
compilers to implement, and even though the above feature would have
been cheaper and more widely useful than other features that C99 decided
to mandate, the authors never revisited it.

[Chris Vine]

On Wed, 20 Jun 2018 14:13:29 +0200

David Brown <david...@hesbynett.no> wrote:
[snip]

> All C and C++ macros are based on text substitution - "cut and paste"
> macros.
>
> No, that does not make them "by definition unhygienic" - at best, you
> are defining "unhygienic" as "what C macros are", which is not at all
> helpful.

That's wrong.

[bart...@gmail.com]

You don't want significant white space such that a .max. b is different from a.max.b which is a member access.

Whatever identifier is chosen for the macro, that will already reserve that name.

Then that name can be used as an infix operator or using function syntax. (My versions allow it both ways, as well as allowing augmented assignment.)

But pretty much any name is better than those funny looking \/ and /\ symbols that are hard to type (try it on a smartphone) and confusing. It doesn't matter if this is someone's private language, it's a very poor choice.

--
Bart

[Rick C. Hodgin]

I like /\ and \/ because they're pretty easy to type on a standard
keyboard.

And, how much programming do you do on your smartphone, Bart? :-)
You can include this to make it a non-issue:

// In CAlive, you can use ! for whitespaces, and . for whitespaces
// or operators, and they can be used on either side:
#define !max. /\
#define !min. \/

Now everywhere max and min are precede by a whitespace, and followed
with either a whitespace or some other operator, it will substitute
those. Then use:

x max= a;
y min= b;

c = a max b;
d = a min b;

Or, substitute the !max. and !min. with some symbol you like and then
you can type it and show it however you want.

--
Rick C. Hodgin

[Keith Thompson]

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
> On Wed, 20 Jun 2018 08:06:27 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 19/06/18 22:28, Chris Vine wrote:

[...]

>> > The macros themselves would still be unhygienic but that wouldn't
>> > matter here.
>>
>> By "unhygienic", do you mean they don't act like functions in the way
>> they handle parameters with side effects, or have multiple statements to
>> cause trouble in conditionals or loops without braces? No, the "max"
>> macro is not "unhygienic" - it is perfectly safe. It is fine to worry
>> about function-like macros that have risks, like the traditional C "max"
>> (or "MAX") macro. But labelling safe macros as "unhygienic" sounds like
>> prejudice.
>>
>> (The "make_max" is a utility macro to reduce typing and the risk of
>> copy-and-paste errors - it is not a function-like macro.)
>
> By "unhygienic" I mean that C89/90 macros (and as I understand it
> from your example, also C11 macros) are "cut and paste" pre-processor
> macros. Such macros systems are by definition unhygienic macro
> systems. A macro system is generally called unhygienic when it does
> not bind identifiers in the way that functions do: in particular when
> it binds identifiers at the call site and not the definition site and
> when it injects its own identifier names into the call site; in short,
> when it does something at macro expansion time which could cause
> identifier names to be accidentally captured or shadowed.

Apparently the term "hygienic macro" is in some general use. Wikipedia
defines them as "macros whose expansion is guaranteed not to cause the
accidental capture of identifiers". The problem is collisions between
identifiers defined within the macro and identifiers in the scope
surrounding the macro invocation.

https://en.wikipedia.org/wiki/Hygienic_macro

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Shorter version of the above: gcc has statement expressions as an
extension, and they were not added to the C standard even though they
would have been useful, particularly for macro definitions.

Was a proposal ever made to the committee to add this particular feature
to the language? Were they not added to the standard because they're
tough to implement (are they?), or simply because nobody proposed it?

I don't believe it was part of the committee's mandate to go looking for
useful extensions to add to the language.

[Chris Vine]

Indeed, although I would include "accidental shadowing" as an addition
to "accidental capture".

None of this is novel, or specific to C. Common lisp (defmacro) macros
are unhygienic if used naively, although the injection of local
identifiers into call sites is addressed by using gensym, which is
guaranteed to provide unique (non-clashing) identifier names. The
binding of identifiers at the call site rather than the definition site
is largely circumvented by lisp 2's placing of function names in a
different namespace from other names, and by prohibiting the rebinding
of core function names.

By contrast scheme's syntax-rules/syntax-case macros are wholly hygienic
by default, as are its renaming macros. Reputedly rust's macro's are
also hygienic although I have not written any rust code to verify that.

[bart...@gmail.com]

\ seems to be in a different place on every keyboard, and sometimes needs a special shift key.

But, what have you got against just using min and max? If it's to maintain some compatibility with C, then even _Min and _Max would be better.

--
Bart

[Rick C. Hodgin]

On 6/20/2018 2:24 PM, bart...@gmail.com wrote:
> \ seems to be in a different place on every keyboard, and sometimes needs a special shift key.
>
> But, what have you got against just using min and max? If it's to maintain some compatibility with C, then even _Min and _Max would be better.
>

Nothing. The traditional forms can still be used, of course, and
this new thing I'm introducing could allow someone to do this:

#define max /\
#define min \/

And then use min and max as you indicate.

Why do you have an issue with \/ and /\? Is it just because they're
awkward to type? I'm beginning to get used to typing \|casks|/ and
/|casks|\ now, so I'm getting better at hitting them:

Describes different types of casks, and their use:

https://groups.google.com/d/msg/caliveprogramminglanguage/DxwixRsfg_o/GrxK2jpvBgAJ

--
Rick C. Hodgin

[supe...@casperkitty.com]

On Wednesday, June 20, 2018 at 12:52:14 PM UTC-5, Keith Thompson wrote:

> supe...@casperkitty.com writes:
> > The dialect that gcc processed when I first saw it--sometime around
> > 1990--made it possible to write macros to do most things that could be
> > done with in-line functions, with behavior that would not be affected
> > by the calling context.
>

> Shorter version of the above: gcc has statement expressions as an
> extension, and they were not added to the C standard even though they
> would have been useful, particularly for macro definitions.
>
> Was a proposal ever made to the committee to add this particular feature
> to the language? Were they not added to the standard because they're
> tough to implement (are they?), or simply because nobody proposed it?
>
> I don't believe it was part of the committee's mandate to go looking for
> useful extensions to add to the language.

Do you think it's plausible that everyone on the C99 and C11 committees was
ignorant of gcc and the features it provides, and that nobody could see how
the statement-expression extension would make it easy to solve a common
problem with C macros?

One of the goals of C89 was to constrain the divergence of incompatible
extensions to the original C language. The original language only had
signed integer arithmetic, for example; when implementations started adding
support for unsigned arithmetic, they did so in incompatible fashion. In
the days before the Standards, compiler writers tended to add features that
other compilers supported and that seemed useful, and there was no particular
need for the Standard to interfere in that process except when features
were being handled in incompatible fashion (as happened with unsigned types,
system library functions that different implementations placed in different
headers, variable argument passing, etc.) The statement-expression feature
used a syntax unlike anything else, so compiler writers could simply support
it or not, at their convenience, based upon whether their users seemed to
want it.

As it happened, the omission of features from the C89 Standard served to
discourage their development in use, but I don't think the authors of C89
were expecting that to happen like it did. On the other hand, the authors
of C89 clearly had gone out looking for new features to add to the language,
thus adding things like Boolean types, variable length arrays, and complex
arithmetic, with semantics in each case that were sub-optimal for many usage
cases. Statement expressions would have been a construct with obvious
usefulness that would have been cheaper to implement than VLAs.

[Rick C. Hodgin]

CAlive allows something similar in the way its #define statements are
parsed. You can prefix and postfix tokens with special characters
which alter the way it does lookups on the tokens. Something similar
to what you state above can be used to define:

#define .max. /\
#define .min. \/

This will look for things surround on either side by whitespaces or
some non-alphanumeric/non-numeric text. It would allow:

c = a max b;

Which would be #define'd into:

c = a /\ b;

And then compiled.

--
Rick C. Hodgin

[Keith Thompson]

supe...@casperkitty.com writes:
> On Wednesday, June 20, 2018 at 12:52:14 PM UTC-5, Keith Thompson wrote:
>> supe...@casperkitty.com writes:
>> > The dialect that gcc processed when I first saw it--sometime around
>> > 1990--made it possible to write macros to do most things that could be
>> > done with in-line functions, with behavior that would not be affected
>> > by the calling context.
>>
>> Shorter version of the above: gcc has statement expressions as an
>> extension, and they were not added to the C standard even though they
>> would have been useful, particularly for macro definitions.
>>
>> Was a proposal ever made to the committee to add this particular feature
>> to the language? Were they not added to the standard because they're
>> tough to implement (are they?), or simply because nobody proposed it?
>>
>> I don't believe it was part of the committee's mandate to go looking for
>> useful extensions to add to the language.
>
> Do you think it's plausible that everyone on the C99 and C11 committees was
> ignorant of gcc and the features it provides, and that nobody could see how
> the statement-expression extension would make it easy to solve a common
> problem with C macros?

My questions were not rhetorical. Yours seems to be, and I'm not going
to take the bait.

Consider the possibility that the committee was more interested in
providing alternatives to the preprocessor than in making the
preprocessor easier to use (see inline functions, added in C99).

[...]

> Statement expressions would have been a construct with obvious
> usefulness that would have been cheaper to implement than VLAs.

You wrote:

Unfortunately, the authors of C89 were disinclined to add things to
the language that might be tough for some compilers to implement,

[...]

Are they "tough to implement" or not? My guess is that implementation
would not be difficult, but that difficulty of implementation was not
the reason they weren't added.

[Wouter Verhelst]

On 20-06-18 19:09, bart...@gmail.com wrote:
> But pretty much any name is better than those funny looking \/ and /\ symbols that are hard to type (try it on a smartphone)

Why would you ever type program code on a smartphone?

(I agree that there are good reasons why \/ and /\ are bad symbols, but
"hard to type on a smartphone" isn't one of them)

[Wouter Verhelst]

On 20-06-18 19:29, Rick C. Hodgin wrote:
> I like /\ and \/ because they're pretty easy to type on a standard
> keyboard.

That's only true on your keyboard layout. On mine, it's shift-/, altgr-\
(or vice versa)...

[bart...@gmail.com]

When you're posting to Usenet?

That's how I found that forward stroke backslash is awkward enough to make it easier to spell them out.

Mind you things like square brackets aren't so easy either. Maybe I've finally found a use for trigraphs.

--
Bart

[Robert Wessel]

On Wed, 20 Jun 2018 21:30:53 +0200, Wouter Verhelst <w...@uter.be> wrote:

>On 20-06-18 19:09, bart...@gmail.com wrote:
>> But pretty much any name is better than those funny looking \/ and /\ symbols that are hard to type (try it on a smartphone)
>
>Why would you ever type program code on a smartphone?

By choice? Never. But I have remoted into my desktop from my phone,
made a code change, run a build (etc.), and copied the result to our
FTP server for a customer to download.

[Steve Carroll]

One guy reported Jonas 'The Flooder' Eklundh years ago. As expected, it did not a thing to attenuate the ninny. Recently I did work on and showed some C++ for the front end which is the only thing you can do when trying to avoid Jonas 'The Flooder' Eklundh's dishonest crap while reading with Google Groups.

I'd post to Jonas 'The Flooder' Eklundh honestly but he's an ignoramus who plays trolling games to realize his appetite to call everyone a con artist. I still remain unpersuaded that these never ending posts are definitely scripted.

--
This Trick Gets Women Hot For You!
http://prescottcomputerguy.com
http://www.5z8.info/dont-just-drizzle_y8q4ut_5waystokillwithamelon
https://www.reddit.com/r/linux/comments/6sfhq6/what_desktop_tasks_does_linux_handle_better_than/
Jonas Eklundh Communication

[Juha Nieminen]

In comp.lang.c++ David Brown <david...@hesbynett.no> wrote:
> auto max(auto a, auto b) {
> return (a >= b) ? a : b;
> }

Wouldn't that be passign the variables by value, and returning the result
by value? Copying may be a very heavy operation in some cases. (Also, in
the case of C++, copying might be disabled completely.)

[Juha Nieminen]

In comp.lang.c++ Keith Thompson <ks...@mib.org> wrote:
> Which is why it's traditional to write macro names in all-caps (MIN()
> and MAX()) so the reader is reminded that they're macros and can have
> odd interactions with side effects.

Good thing that the C standard followed that convention with names
like assert and FILE.

[David Brown]

Yes, it is by value - but compilers will omit trivial copying when
possible (such a function is likely to be inline). In C++, copy elision
is allowed to skip copy constructors (but you can't make copies of
uncopyable objects).

A more complete implementation - such as for the standard library -
would have const and constexpr, references, efficiency considerations
(like trying to move rather than copy).

[Juha Nieminen]

In comp.lang.c++ David Brown <david...@hesbynett.no> wrote:
> On 21/06/18 09:26, Juha Nieminen wrote:
>> In comp.lang.c++ David Brown <david...@hesbynett.no> wrote:
>>> auto max(auto a, auto b) {
>>> return (a >= b) ? a : b;
>>> }
>>
>> Wouldn't that be passign the variables by value, and returning the result
>> by value? Copying may be a very heavy operation in some cases. (Also, in
>> the case of C++, copying might be disabled completely.)
>>
>
> Yes, it is by value - but compilers will omit trivial copying when
> possible (such a function is likely to be inline). In C++, copy elision
> is allowed to skip copy constructors (but you can't make copies of
> uncopyable objects).

But suppose I wanted a reference to one of two large data containers,
depending on which one compares "larger than":

std::vector<T> hugeVector1, hugeVector2;
...
std::vector<T>& bigger = max(hugeVector1, hugeVector2);

I would prefer if max() took references and returned a reference,
so that bigger would be a reference to either the original hugeVector1
or hugeVector2. For two reasons: Modifying 'bigger' would modify the
original (rather than a temporary copy) and, of course, to elide
needless copying (even if we aren't modifying anything).

[Steve Carroll]

DFS's actions are in fact in all respects duplicitous. There can be no dispute that as soon as any former 'person in his KF' does one thing to frighten the coward's feelings that they'll be replonked. Right, DFS is looking to retail a JavaScript reference, which Snit (a real advocate) can get in seconds. If he could stop being so screwed up he'd get how stupid he appears ;) Pay for a background report on DFS and you will find that he was in gaol last year. Not surprising to anyone. The investigation sites do not go into that amount of detail and legal reports are private unless subpoenaed.

What did you assume from the lying imbecile? That DFS ignoramus has nothing to waste but time. He has nothing else, especially not a girlfriend. Outright gobbledygook by an uneducated, lying, manipulative, conspiring birdbrain who would not tell the truth if his life depended on it.

DFS asked to be rated according to provable trolling measurements, which I obliged him with.

Ending support for Pulseaudio is needed for progress.

-
This Trick Gets Women Hot For You!

https://youtu.be/5OfWsoPAg7o
Jonas Eklundh Communication AB

[John Bode]

On Monday, June 18, 2018 at 1:54:51 PM UTC-5, Rick C. Hodgin wrote:
> Is there a native operator for min and max in C or C++?
>

Not in C.

The C++ <algorithm> header defines min and max function templates:

template<class T>
constexpr const T& min(const T& a, const T& b);

template<class T, class Compare>
constexpr const T& min(const T& a, const T& b, Compare comp);

template<class T>
constexpr T min(initializer_list<T> t);

template<class T>
constexpr const T& min(const T& a, const T& b);

template<class T, class Compare>
constexpr const T& min(const T& a, const T& b, Compare comp);

template<class T>
constexpr T min(initializer_list<T> t);

There are several others find mins and maxes from lists.

No *operators* as such, though.

> // Traditional way
> #define min(a, b) ((a <= b) ? a : b)
> #define max(a, b) ((a >= b) ? a : b)
>

Which, unfortunately, results in one of the operands being evaluated twice. Bad juju
if either operand has side effects, or is a function call that returns a different value
each time (such as rand()).

> int a, b, c, d;
>
> a = 5;
> b = 8;
>
> // Assign min and max:
> c = min(a, b); d = max(a, b);
>
> Is there an operator for this? Like /\ for max, \/ for min?
>

No. And if such operators existed, they'd be used for logical AND and OR.

> // Assign min and max using operators:
> c = a \/ b; d = a /\ b;
>
> Or min/max-assignment operators?
>
> // Min of b and a is assigned to b
> b \/= a; // Equivalent of b = min(b, a)
>
> // Max of b and a is assigned to b
> b /\= a; // Equivalent of b = max(b, a)
>
> --
> Rick C. Hodgin

Not as such, no.

[Richard Bos]

Keith Thompson <ks...@mib.org> wrote:

> I'm not at all convinced that min and max operators, with whatever
> syntax, are worth adding to the language at all. If they were to be
> added, agreeing on a syntax would be difficult.

It's a very simple idea, which has been mentioned before, but has
(ttbomk) never appeared as an extension in any compiler _in a
generalisable, Standardisable manner_. Ad-hoc hacks, yes; something we
could have in the Standard, no.
That, to me, strongly suggests that there is no real desire for such a
feature in general. Everybody wants a _specific_ instance from time to
time, but those specific instances are too easy to write with what we
already have for the general feature to be worth including.

Richard

[Bart]

If min/max were operators, so that they could be written as 'a max b',
perhaps as well as 'max(a,b)', then the following becomes possible:

a max= b;

as well as:

A[++i] max= lowerlim;

This I would use (as I do use when it is available elsewhere).

(And actually, the x64 processor has native MIN and MAX instructions for
floating point; presumably they were considered useful enough to
implement in hardware.)


--
bartc

Not C:

real x, y
x max:= y

Compiler output:

movq XMM0, [x]
maxsd XMM0, [y]
movq [x], XMM0

[Wouter Verhelst]

On 30-06-18 13:17, Bart wrote:
> On 30/06/2018 11:29, Richard Bos wrote:
>> Keith Thompson <ks...@mib.org> wrote:
>>
>>> I'm not at all convinced that min and max operators, with whatever
>>> syntax, are worth adding to the language at all.  If they were to be
>>> added, agreeing on a syntax would be difficult.
>>
>> It's a very simple idea, which has been mentioned before, but has
>> (ttbomk) never appeared as an extension in any compiler _in a
>> generalisable, Standardisable manner_. Ad-hoc hacks, yes; something we
>> could have in the Standard, no.
>> That, to me, strongly suggests that there is no real desire for such a
>> feature in general. Everybody wants a _specific_ instance from time to
>> time, but those specific instances are too easy to write with what we
>> already have for the general feature to be worth including.
>
> If min/max were operators, so that they could be written as 'a max b',
> perhaps as well as 'max(a,b)', then the following becomes possible:
>
>    a max= b;

Which can be written as a = max(a, b); just as well

> as well as:
>
>    A[++i] max= lowerlim;

A[++i] = max(A[i], b);

... and then max just needs to either be a safe macro or an inline function.

With gcc, you can make it a safe macro like so:

#define max(a, b) ({ typeof(a) _a = (a); typeof(b) _b = (b); _a > _b ?
_a : _b; })

typeof is a gcc extension that evaluates to the type of the expression,
without evaluating the expression (so it has no side effects), except as
necessary to do what it needs to do:

#include <stdio.h>
int main(void) {
int i = 0;
char c = 2;
typeof(i++) j = i;
printf("%d %d\n", i, j); // output: 0 0
typeof(++i == 1 ? i : c) c2 = c;
printf("%d %d\n", i, (int)c2); // output: 0 2
}

the ({ ...code... }) syntax is also a gcc extension called a "statement
expression", which evaluates to the value of the final expression in the
inner code block.

https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Statement-Exprs.html

> This I would use (as I do use when it is available elsewhere).
>
> (And actually, the x64 processor has native MIN and MAX instructions for
> floating point; presumably they were considered useful enough to
> implement in hardware.)

I'm sure a decent optimizing compiler will optimize something like a max
function or safe macro implemented with a trinary operator or a simple
if() to that instruction.

[Barry Schwarz]

On Sun, 1 Jul 2018 09:23:54 +0200, Wouter Verhelst <w...@uter.be> wrote:

>On 30-06-18 13:17, Bart wrote:
>> On 30/06/2018 11:29, Richard Bos wrote:
>>> Keith Thompson <ks...@mib.org> wrote:
>>>
>>>> I'm not at all convinced that min and max operators, with whatever
>>>> syntax, are worth adding to the language at all.  If they were to be
>>>> added, agreeing on a syntax would be difficult.
>>>
>>> It's a very simple idea, which has been mentioned before, but has
>>> (ttbomk) never appeared as an extension in any compiler _in a
>>> generalisable, Standardisable manner_. Ad-hoc hacks, yes; something we
>>> could have in the Standard, no.
>>> That, to me, strongly suggests that there is no real desire for such a
>>> feature in general. Everybody wants a _specific_ instance from time to
>>> time, but those specific instances are too easy to write with what we
>>> already have for the general feature to be worth including.
>>
>> If min/max were operators, so that they could be written as 'a max b',
>> perhaps as well as 'max(a,b)', then the following becomes possible:
>>
>>    a max= b;
>
>Which can be written as a = max(a, b); just as well
>
>> as well as:
>>
>>    A[++i] max= lowerlim;
>
>A[++i] = max(A[i], b);

Unfortunately, this invokes undefined behavior.


--
Remove del for email

[Bart]

On 01/07/2018 08:23, Wouter Verhelst wrote:
> On 30-06-18 13:17, Bart wrote:

>> If min/max were operators, so that they could be written as 'a max b',
>> perhaps as well as 'max(a,b)', then the following becomes possible:
>>
>>    a max= b;
>
> Which can be written as a = max(a, b); just as well

Sure. As can 'a += b'.

But there must be a reason why such 'assignment operators' (not
'augmented assignment' as I thought they were called) were present even
in early C.

>> (And actually, the x64 processor has native MIN and MAX instructions for
>> floating point; presumably they were considered useful enough to
>> implement in hardware.)
>
> I'm sure a decent optimizing compiler will optimize something like a max
> function or safe macro implemented with a trinary operator or a simple
> if() to that instruction.

I don't use an optimising compiler. Evaluating 'max(a,b)' when a,b are
ints, and 'max' is a function (not a macro, not even an inline function)
involves executing some 14 instructions, including call, return and
branches [on x64].

But when 'max' is an intrinsic operator, then it can be trivially done
in 4 instructions when a and b are int (3 is possible), and 2
instructions when they are floats, none of which are branches.

You also get the advantage of overloading via the usual operator
mechanisms, without needing to rely on anything else (safe macros,
overloaded functions etc).


--
bart

[Alf P. Steinbach]

On 01.07.2018 11:08, Bart wrote:
> On 01/07/2018 08:23, Wouter Verhelst wrote:
>> On 30-06-18 13:17, Bart wrote:
>
>>> If min/max were operators, so that they could be written as 'a max b',
>>> perhaps as well as 'max(a,b)', then the following becomes possible:
>>>
>>>     a max= b;
>>
>> Which can be written as a = max(a, b); just as well
>
> Sure. As can 'a += b'.
>
> But there must be a reason why such 'assignment operators' (not
> 'augmented assignment' as I thought they were called) were present even
> in early C.

They corresponded directly, and still correspond, to very common
processor instructions, and at that time it was more the programmer's
job, and not the compiler's, to optimize the resulting machine code.

Typically an integer add instruction, say, adds to a register, like on
the i8086 (the original IBM PC processor, except for data bus width):

add ax, bx ; add the contents of register ax, to bx

So in C and C++:

ax += bx;

Of course, historically that was ten years or so after development of C
started, PC 1981 versus plain C 1971. I think the original C development
was on a PDP-10. I had some limited exposure to the PDP-11, but all I
remember about the assembly language was that it was peppered with @
signs (probably indicating macros), and that the registers were numbered
and memory-mapped. But I'm pretty sure that if the PDP-11 didn't have
add to register, I'd remember that. And so, presumably also the PDP-10.

Disclaimer: maybe C development started a year or two later. And maybe
it was a PDP-9, if such a beast existed. Google could probably cough up
the more exact history, but it doesn't matter here.

[snip]


Cheers!,

- Alf

[Alf P. Steinbach]

On 01.07.2018 12:15, Alf P. Steinbach wrote:
> [snip]

> Typically an integer add instruction, say, adds to a register, like on
> the i8086 (the original IBM PC processor, except for data bus width):
>
>     add ax, bx    ; add the contents of register ax, to bx

"of register bx, to ax"

> So in C and C++:
>
>     ax += bx;

> [snip]


Sorry,

- Alf

[Ben Bacarisse]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:

> On 01.07.2018 11:08, Bart wrote:

<snip>

>> But there must be a reason why such 'assignment operators' (not
>> 'augmented assignment' as I thought they were called) were present
>> even in early C.
>
> They corresponded directly, and still correspond, to very common
> processor instructions, and at that time it was more the programmer's
> job, and not the compiler's, to optimize the resulting machine code.

I think that is an unlikely explanation. First, they came into C from
Algol68 via B, and Algol68 never had any intention of providing
operators for the purpose of helping the programmer optimise code!
Secondly, there never was a B compiler in the traditional sense of one
that generated machine instructions.

However, there's a grain of truth here. B was implemented as "threaded
code" where each operation is translated into a jump to the code that
performs the appropriate action. There was no possibility of doing any
optimisation in 8K (on a PDP-7) but a =+ b was bound to be more
efficient that a = a + b simply because it could be translated to single
jump.

> I think the original C development was on a PDP-10.

Even "New B" development was done on the PDP-11 and anything that can
reasonably be called C certainly was.

> Disclaimer: maybe C development started a year or two later. And maybe
> it was a PDP-9, if such a beast existed.

B was born on the PDP-7 and C on the PDP-11.

> Google could probably cough
> up the more exact history, but it doesn't matter here.

True, but it's nice to keep the history straight.

--
Ben.

[Bart]

On 01/07/2018 11:15, Alf P. Steinbach wrote:
> On 01.07.2018 11:08, Bart wrote:
>> On 01/07/2018 08:23, Wouter Verhelst wrote:
>>> On 30-06-18 13:17, Bart wrote:
>>
>>>> If min/max were operators, so that they could be written as 'a max b',
>>>> perhaps as well as 'max(a,b)', then the following becomes possible:
>>>>
>>>>     a max= b;
>>>
>>> Which can be written as a = max(a, b); just as well
>>
>> Sure. As can 'a += b'.
>>
>> But there must be a reason why such 'assignment operators' (not
>> 'augmented assignment' as I thought they were called) were present
>> even in early C.
>
> They corresponded directly, and still correspond, to very common
> processor instructions, and at that time it was more the programmer's
> job, and not the compiler's, to optimize the resulting machine code.

Sometimes they will correspond to hardware instructions, other times
they don't (eg. floating point on modern x86).

Such assignments were of part of Algol68 (created around 1968 I
believe), and there were doubtless earlier precedents.

They are useful to better express intent, and make it easier for a
compiler to generate code (otherwise they have to decide where a[f(x)].b
= a[f(x)].b + 1 is the same thing as a[f(x)].b += 1; it's a lot easier
if the programmer just writes the latter).

They can also indicate something subtly different from A = A+1, as in my
more complex example, where f(x) with possible side-effects might be
called once or twice.

Also in this example (not from C):

s = s + "A"

This takes a string s, creates a new string with "A" appended, then
assigns back into s, destroying the original. Lots of string processing
going on.

But write it like this:

s += "A"

and now it can be taken to mean in-place append. Given adequate
capacity, which is usually the case, this now writes adds one byte onto
the end of s, and updates its length.

> Of course, historically that was ten years or so after development of C
> started, PC 1981 versus plain C 1971. I think the original C development
> was on a PDP-10. I had some limited exposure to the PDP-11, but all I
> remember about the assembly language was that it was peppered with @
> signs (probably indicating macros), and that the registers were numbered
> and memory-mapped. But I'm pretty sure that if the PDP-11 didn't have
> add to register, I'd remember that. And so, presumably also the PDP-10.

I don't think C was developed for PDP10, not at first anyway. But as I
said, augmented assignment was not just limited to C, it has other
benefits that just mapping neatly to hardware instructions.


--
bart

[Rick C. Hodgin]

On 06/30/2018 07:17 AM, Bart wrote:
> If min/max were operators, so that they could be written as 'a max b',
> perhaps as well as 'max(a,b)', then the following becomes possible:
>
>    a max= b;

You won't find a better syntax than:

a /\= b;

It takes a moment to learn, but once you get the concept it's easy to
use everywhere.

a = (b /\ c) * d;

I've thought about your comment regarding it not working due to the
use of the \ character in certain circumstances. But, this wouldn't
be a \ character in and of itself, but would be the /\ combination in
some cases, and \/ in others. The compiler would have no issues in
parsing that.

--
Rick C. Hodgin

[Wouter Verhelst]

On 01-07-18 11:08, Bart wrote:
> I don't use an optimising compiler.

Your loss.

> Evaluating 'max(a,b)' when a,b are
> ints, and 'max' is a function (not a macro, not even an inline function)
> involves executing some 14 instructions, including call, return and
> branches [on x64].

Sure, but on a decent optimizing compiler there won't be a difference --
and no need to complicate the language with extra operators etc.

To me, that is a huge benefit.

[Ben Bacarisse]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:

> On 06/30/2018 07:17 AM, Bart wrote:
>> If min/max were operators, so that they could be written as 'a max b',
>> perhaps as well as 'max(a,b)', then the following becomes possible:
>>
>>    a max= b;
>
> You won't find a better syntax than:
>
> a /\= b;

Except that (a) there is an existing implementation that uses <? and >?;
(b) your symbols are the reverse of what some people would expect; and
(c) there is an ambiguity to resolve when /\ oecus at the end of a
line.

There is a strong argument against proliferating incompatible extensions
to C. (b) is, in my opinion, comparatively minor, but (c) must be
resolved in such a way as to respect the meaning of existing code making
the new operator a little off (see below).

> It takes a moment to learn, but once you get the concept it's easy to
> use everywhere.
>
> a = (b /\ c) * d;
>
> I've thought about your comment regarding it not working due to the
> use of the \ character in certain circumstances. But, this wouldn't
> be a \ character in and of itself, but would be the /\ combination in
> some cases, and \/ in others. The compiler would have no issues in
> parsing that.

The problem is not the compiler -- you can make a compiler that
implements whatever rules you want about /\. The problem is whether or
not you break existing code because this

a = b /\
2;

already has a meaning. You can, of course, write the new rules so that
the meaning of such code does not change, but it makes the new operator
a little odd in that you can't break an expression across lines after
it.

--
Ben.

[Rick C. Hodgin]

On 07/01/2018 12:14 PM, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c...@gmail.com> writes:
>
>> On 06/30/2018 07:17 AM, Bart wrote:
>>> If min/max were operators, so that they could be written as 'a max b',
>>> perhaps as well as 'max(a,b)', then the following becomes possible:
>>>
>>>    a max= b;
>>
>> You won't find a better syntax than:
>>
>> a /\= b;
>
> Except that (a) there is an existing implementation that uses <? and >?;

I considered <? and >? when mentioned before, but they're not for me.
I think /\ and \/ convey the meaning very clearly, and I've been con-
sidering the existing mathematical use of the opposite direction, and
I really think they got it wrong. Especially when the use a closed
triangle.

My opinion. In CAlive, it will be as I have indicated. Other C-like
languages, including C or C++, are able to implement them however they
choose ... though I do not believe they will ever be implemented in C
or C++, so it's a non-issue.

My original inquiry was to see if there was a min or max operator. I
have never seen one in my 30+ years of programming. I could've used
one in database programming a great many time. Have always had to use
the min(a,b) syntax. An operator seems a better choice.

> (b) your symbols are the reverse of what some people would expect; and
> (c) there is an ambiguity to resolve when /\ oecus at the end of a
> line.
>
> There is a strong argument against proliferating incompatible extensions
> to C. (b) is, in my opinion, comparatively minor, but (c) must be
> resolved in such a way as to respect the meaning of existing code making
> the new operator a little off (see below).
>
>> It takes a moment to learn, but once you get the concept it's easy to
>> use everywhere.
>>
>> a = (b /\ c) * d;
>>
>> I've thought about your comment regarding it not working due to the
>> use of the \ character in certain circumstances. But, this wouldn't
>> be a \ character in and of itself, but would be the /\ combination in
>> some cases, and \/ in others. The compiler would have no issues in
>> parsing that.
>
> The problem is not the compiler -- you can make a compiler that
> implements whatever rules you want about /\. The problem is whether or
> not you break existing code because this
>
> a = b /\
> 2;
>
> already has a meaning. You can, of course, write the new rules so that
> the meaning of such code does not change, but it makes the new operator
> a little odd in that you can't break an expression across lines after
> it.

Does the \ work everywhere in C? Or just in a #define block? I don't
think I've ever seen it anywhere else.

The rule has been written, Ben B. In CAlive, the native interpretation
of your example will be as "a = b /\ 2;":

--
Rick C. Hodgin

[Rick C. Hodgin]

On 07/01/2018 12:30 PM, Rick C. Hodgin wrote:
> The rule has been written, Ben B. In CAlive, the native interpretation
> of your example will be as "a = b /\ 2;":

To be clear about this, in CAlive if you wanted to use your example of
a continuation it would need to be written as:

[Bart]

On 01/07/2018 17:30, Rick C. Hodgin wrote:

> The rule has been written, Ben B. In CAlive, the native interpretation
> of your example will be as "a = b /\ 2;":

Is /\ min or max? Because, you know, one end is small so it could mean
min, but then the other end is fat so it could be max.

Or are you supposed to use device such as that /\ looks a bit like 'A',
which is the second letter of MAX? Assuming it is actually max.

--
bart