Proposal: More flexible comparisons

I

Ioannis Vranos

Proposal:


I think the following simple approach will provide great flexibility in conditions.


The style:

1.

if(1<x<4)
// ...


2.

if(1<x<4 and 3<=y<=5 and z>1)
// ...




--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net
 
B

Bo Persson

Ioannis said:
Proposal:


I think the following simple approach will provide great
flexibility in conditions.

The style:

1.

if(1<x<4)
// ...


2.

if(1<x<4 and 3<=y<=5 and z>1)
// ...

The proposal has the disadvantage that it proposes new semantics for
an existing syntax. Very low likelyhood for acceptance.

Example 1 could also be written as

if (x == 2 or 3)

with the same problem.


Bo Persson
 
S

Stefan Ram

Bo Persson said:
Example 1 could also be written as
if (x == 2 or 3)
with the same problem.

To avoid repetition of »x«:

switch( x ){ case 2: case 3: ... }
 
I

Ioannis Vranos

Bo said:
The proposal has the disadvantage that it proposes new semantics for
an existing syntax. Very low likelyhood for acceptance.

Example 1 could also be written as

if (x == 2 or 3)

with the same problem.


Bo Persson


What do you mean new semantics. The first example could be resolved to:


if(1<x and x<4)
// ...



--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net
 
I

Ioannis Vranos

Ioannis said:
Proposal:


I think the following simple approach will provide great flexibility in
conditions.


The style:

1.

if(1<x<4)
// ...


2.

if(1<x<4 and 3<=y<=5 and z>1)
// ...



My mistake.

The condition


1<x<4 is currently valid, it is evaluated from left to right as usual and is equivalent to

(1<x)<4


which is not the obvious mathematical meaning.



--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net
 
V

Victor Bazarov

Juha said:
How should this be interpreted?

if(a < b < c < d)

Both are valid constructs now, AFAICT. Right? So, we can't expect the
language to introduce a different interpretation of those because it
might break existing code. The (1<x<4) always evaluates to 'true' (now)
and the example you gave evaluates to 'true' when (a >= b) and (c < d).

I understand that you want to know what the proposal is in more detail,
don't get me wrong.

V
 
R

Richard Herring

Ioannis Vranos said:
What do you mean new semantics.

Semantics that differ from the existing semantics, presumably. (1<x<4)
is already a valid expression in C++, but it doesn't mean (i.e. its
existing semantics are other than) what you would like it to.
 
I

Ioannis Vranos

Ioannis said:
Proposal:


I think the following simple approach will provide great flexibility in
conditions.


The style:

1.

if(1<x<4)
// ...


2.

if(1<x<4 and 3<=y<=5 and z>1)
// ...


The proposal corrected:

I think a keyword like "condition" with function semantics, and with the operands evaluated only once, would
provide great flexibility (readability), abstraction and efficiency optimisation:


For example:


while( condition(x< z< pow(x,y)<= 35) )
// ...



would mean:


while(x< z and z< pow(x,y) and pow(x,y)<= 35)
// ...


The first code is more readable, provides the ability to evaluate pow(x, y) only once, and thus is more flexible.


Any thoughts are welcome.



--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net
 
I

Ioannis Vranos

Clarification:


Ioannis said:
The proposal corrected:
I think a keyword like "condition" with function ==> appearance, and ==> perhaps under the rule with the
operands evaluated only once, would provide great flexibility
(readability), abstraction and efficiency optimisation:


For example:


==> int x= 2, y= 3;

while( condition(x< z< pow(x,y)<= 35) )
// ...



would mean:


while(x< z and z< pow(x,y) and pow(x,y)<= 35)
// ...


The first code is more readable, provides the ability to evaluate pow(x,
y) only once, and thus is more flexible.


Any thoughts are welcome.



--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net
 
J

Jonathan Lee

I think the following simple approach will provide great flexibility in conditions.
...
if(1<x<4)

While we're on the topic, I wish there was an "in" operator, $B":(B. As in
set-theory membership. Then you might be able to write something like

if (x $B":(B (1,4)) { } // if (x in (1,4)) { }

Also while we're at it, unions, intersections, subset,...

No joke. That would be awesome.

--Jonathan
 
V

Victor Bazarov

Jonathan said:
While we're on the topic, I wish there was an "in" operator, $B":(B. As in
set-theory membership. Then you might be able to write something like

if (x $B":(B (1,4)) { } // if (x in (1,4)) { }

Also while we're at it, unions, intersections, subset,...

No joke. That would be awesome.

--Jonathan

But you can do it yourself. You can define a class Interval with a
consturctor that takes two ends (or four classes: OpenInterval,
ClosedInterval, OpenClosedInterval, ClosedOpenInterval), and then define
an operator, say, equality. Here is pseudo code:

template<class value_type> struct Interval_t
{
value_type from, to;

Interval_t(value_type f, value_type t) : from(f), to(t) {}
};

template<class T> Interval_t<T> Interval(T f, T t)
{
return Interval_t<T>(f, t);
}

template<class T> bool operator ^ (T t, Interval_t<T> const& i)
{
return t > i.from && t < i.to;
}

int main()
{
bool in = 4 ^ Interval(1, 10));
bout out = 444 ^ Interval(1, 10));
}

V
 
J

Jonathan Lee

But you can do it yourself.

I really just mean the notation. As it is I pretty much do as you've
suggested, and mimic the functionality (though I tend to use '<' to
hint at subset notationt). But I'm more of a mathematician than a
programmer so it doesn't really "feel" right. Highly subjective, I
know.

But I don't immediately see what would be wrong with allowing the user
to introduce new binary operators. Source could be written in Unicode,
so that's not a huge issue. And precedence could be specified at the
time of declaration:

operator @ like ^; // new operator, @, has precedence of ^

I see the potential for abuse, but used correctly I think it would
make a lot of things more readable.

--Jonathan
 
V

Victor Bazarov

Jonathan said:
I really just mean the notation. As it is I pretty much do as you've
suggested, and mimic the functionality (though I tend to use '<' to
hint at subset notationt). But I'm more of a mathematician than a
programmer so it doesn't really "feel" right. Highly subjective, I
know.

But I don't immediately see what would be wrong with allowing the user
to introduce new binary operators. Source could be written in Unicode,
so that's not a huge issue. And precedence could be specified at the
time of declaration:

operator @ like ^; // new operator, @, has precedence of ^

I see the potential for abuse, but used correctly I think it would
make a lot of things more readable.

What symbol would you use for "belongs" or "includes" (for sets)? You
already can do

#define is ^
#define in Interval
...
if (4 is in (1, 10))
...

Preprocessor is not always your enemy.

V
 
J

Jonathan Lee

What symbol would you use for "belongs" or "includes" (for sets)?

The usual "element of". I don't think it'll show up in the newsgroup
post, but this is what I mean:
http://www.fileformat.info/info/unicode/char/2208/index.htm

Similarly, cup for union, etc. Basically, as you would write it with
pen and paper.

I realize the characters are not easy to type since they aren't on any
keyboard -- it's just wishful thinking. Also, being familiar with some
WYSIWYG LaTeX editors makes me inclined to think it's not _that_
troublesome.
    #define is ^
    #define in Interval
    ...
        if (4 is in (1, 10))
    ...

Interesting. I usually *do* think of the preprocessor as my enemy :)
But that could be useful.

--Jonathan
 
J

James Kanze

This can be interpreted as:
if(a<b and b< c and c< d)

Not in C++. In C++, it is:

if ( ((a < b) < c) < d )

While there is some merit in your suggestion, it would break
code which depends on the above meaning, and so has very little
chance of being adopted. (On the other hand, I suspect that
code which actually wants the above semantics is very rare; I
think even that some compilers warn about it.)
 
F

Fred Zwarts

Jonathan Lee said:
I really just mean the notation. As it is I pretty much do as you've
suggested, and mimic the functionality (though I tend to use '<' to
hint at subset notationt). But I'm more of a mathematician than a
programmer so it doesn't really "feel" right. Highly subjective, I
know.

But I don't immediately see what would be wrong with allowing the user
to introduce new binary operators. Source could be written in Unicode,
so that's not a huge issue. And precedence could be specified at the
time of declaration:

operator @ like ^; // new operator, @, has precedence of ^

I see the potential for abuse, but used correctly I think it would
make a lot of things more readable.

I don't think it is a good idea to add operators to a general purpose
language for each mathematical operation that mathematicians can
think of. Giving each of them a separate character is also not a
good idea. My keyboard is not big enough and I don't like
more keys like shift, alt, Ctrl, and combinations thereof.
Maybe that a mathematician would find it easier to read,
for others it will become very difficult to understand the differences
between *, ¤, ∈, ×, /,â„, ÷, ·, ., ¯,–, —,¬,-,ø,‡,†.
The language should define a small amount of elementary operations
in which other more complex operations can be expressed.
more complex operators should have a descriptive name.
I think C++ offers enough elementary operations for integral numbers.
and the possibility to extend it with classes and overloading are also sufficient.
 
J

Jonathan Lee

Except that this wreaks havoc with code like this
   std::istream& operator<<(std::istream& is, const T& o);
which isn't really uncommon.

True, but maybe there is the possibility of #define-ing in as LaTeX
would: \in. Or even the unicode character itself, but I don't know
offhand if the preprocessor will recognize the character.
Using this <http://www.research.att.com/~bs/whitespace98.pdf>
idea, however, we can introduce a class 'in', overload the
appropriate operator, and everything works beautifully. :)

Too bad that was written as an April Fool's joke :) The wing dings
with the telephone was priceless.

Still, the exaggeration doesn't mean it's a totally bad idea. You
could probably make an identifier out of the first chapter of
"Finnegan's Wake" and underscores, but that doesn't mean identifiers
are a bad idea in general. For example, I think at least a couple
people here would appreciate a cross-product, or dot-product operator.
But anyways, it's not a proposal of any sort. Just thinking out loud.
 
R

robertwessel2

Proposal:

I think the following simple approach will provide great flexibility in conditions.

The style:

1.

if(1<x<4)
   // ...

2.

if(1<x<4 and 3<=y<=5 and z>1)
   // ...


While it has some merit, it doesn't appear to work very well in
practice. Take a look at Cobol, which has done that since the sixties
(although they did change how some of the complex combinations are
interpreted in COBOL-74). Most coding standards prohibit the use of
those forms, for pretty good reason - while simple case are not too
bad, it's very easy to generate statements that are very hard to
interpret (for humans).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,007
Messages
2,570,266
Members
46,863
Latest member
montyonthebonty

Latest Threads

Top