Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #139150 > unrolled thread

Range-aware modulo operator -%

Back to article view | Back to comp.lang.c

Contents

  Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-27 21:09 -0500
    Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-27 21:34 -0500
      Re: Range-aware modulo operator -% "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2018-12-28 05:37 +0100
      Re: Range-aware modulo operator -% James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-29 16:04 -0500
        Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-29 19:13 -0500
    Re: Range-aware modulo operator -% Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-28 03:05 +0000
      Re: Range-aware modulo operator -% Robert Wessel <robertwessel2@yahoo.com> - 2018-12-27 21:31 -0600
        Re: Range-aware modulo operator -% Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-28 04:20 +0000
      Re: Range-aware modulo operator -% James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-27 19:32 -0800
        Re: Range-aware modulo operator -% Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-28 04:18 +0000
    Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-28 12:29 +0000
      Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-28 08:10 -0500
        Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-28 10:25 -0500
          Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-28 15:56 +0000
            Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-28 17:26 -0500
              Re: Range-aware modulo operator -% Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2018-12-28 23:45 +0100
          Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-28 11:44 -0500
          Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-28 12:16 -0500
            Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-28 17:08 -0500
              Re: Range-aware modulo operator -% Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-28 15:01 -0800
              Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-31 09:04 -0500
                Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-31 18:07 +0000
                  Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-31 14:22 -0500
                    Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-31 21:05 +0000
                      Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-31 16:32 -0500
                        Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-31 23:43 +0000
                          Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2018-12-31 16:44 -0800
                            Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-01 01:06 +0000
                              Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2018-12-31 19:06 -0800
                                Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-01 11:32 +0000
                                  Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2019-01-01 12:48 -0800
                                    Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-01 23:54 +0000
                                      Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2019-01-01 16:09 -0800
                                        Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-02 00:49 +0000
                                          Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2019-01-01 17:53 -0800
                                            Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-02 02:36 +0000
                                              Leader Kiki is not going to like this... (Was: Range-aware modulo operator -%) gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-02 08:36 +0000
                                              Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2019-01-02 00:38 -0800
                                      Re: Range-aware modulo operator -% rbowman <bowman@montana.com> - 2019-01-01 22:40 -0700
                                        Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-02 12:12 +0000
                            Re: Range-aware modulo operator -% gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-01 01:53 +0000
                      Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-31 16:57 -0500
                        Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-31 22:33 +0000
                  Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2018-12-31 13:34 -0800
                    Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-31 16:43 -0500
                      Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2018-12-31 15:20 -0800
    Re: Range-aware modulo operator -% Eduardo <abdulai60@gmail.com> - 2018-12-28 07:18 -0800
      Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-28 11:45 -0500

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#139281

On 12/28/2018 5:08 PM, Richard Damon wrote:
> On 12/28/18 12:16 PM, Rick C. Hodgin wrote:
>> How many new symbols have I created, or implemented in CAlive?
> 
> Looking over the past 6 months of messages, I see suggested:
> 
> min/max: \/  /\  \/=  /\=
> swap:    ><
> shortcut indirect: ~> which later became ~~
> modulus:  -%

The swap operator wasn't my idea.  I just happen to think it's
an excellent idea.  I also introduced ><= as a follow-up, one
which operates standalone and conveys more meaning than simply
the "a >< b;" syntax on a stand-alone line, but it is otherwise
synonymous when used in stand-alone.  When ><= is used in-flight,
it doesn't just swap the values for the remainder of the expres-
sion, but rather permanently update the target variables.

     https://groups.google.com/d/msg/comp.lang.c/S0Y0yfuY8bk/JcW-H8p6AQAJ

> and that doesn't count syntax changes like a < b < c

I have also introduced the underscore-bang operator:  _!

     https://groups.google.com/d/msg/comp.lang.c/TerqLu1Rvg4/bD4xkKizBgAJ

It was added to augment legacy systems with new struct / class
information the new additions to the app are aware of, but old
code is not.  It allows traditional uses of prior structures,
such as dynamically linked external modules which have not been
recompiled and are not aware of the new fields, to still operate
properly while allowing the code that has been recompiled to use
the new features.  It doesn't work on legacy arrays, but does
work apart from that, such as single instance structures that
need to convey more cargo than their finite size allows.  By
passing the pointer, the pre and post portions remain visible
to apps that are aware of it.  And the _ptr! syntax indicates
it's being conveyed with pre and/or post data.

I've added predicates:

     // Old way:
     if (units > 1) qty /= units;

     // As a predicate
     ((units > 1)) qty /= units;

I've added the /% divide-modulo operator, which operates to
obtain the divide value and remainder in one op:

     // Old way:
     divide_value = a / b;
     remainder    = a % b;

     // Using divide-modulo
     divide_value = a /% b : remainder;

I've introduced the @ character for use when passing a variable
to indicate it's being passed by reference.

I've introduced the ability to perform a bit rotate operation
using <<< and >>>, which include <<<= and >>>= as well as the
ability to rotate a sub-portion using start#length syntax, as
in <<7#4<< to begin rotating at the 7th bit and extend for 4
bits to the 7th,8th,9th,10th bit.

     x <<<= 5;           // Rotate the bits in x 5 positions
     y >>>= 5 : carry;   // Rotate the bits in y right 5 pos-
                         // itions, and rotate not just in y,
                         // but rotate each bit through the
                         // carry variable.

I've added mated ctors / dtors, so that when something is in-
stantiated with a particular constructor it calls the associated
destructor, which can then also call an explicitly named one by
using the constructor's name, as ~name().

     class Xyz
     {
         Xyz(void) name1
           { /* ctor code */ }
         ~ { /* dtor code */ }

         Xyz(int a) name2
           { /* ctor code */ }
         ~ { /* dtor code */ }
     };

I've added associated pre {} and post {} blocks to everything:

     pre {
         // Code here

     } if (x == 5) {
         // Code here

     } post {
         // Code here
     }

It encapsulates code associated with the inner thing.  Works
with anything that can be in a block.  Can also be explicitly
moved to using pre; or post;, or you can name them and call
the one explicit one if you have more than one defined using
the pre name; and post name; syntaxes.

Using a post block allows for easy structured exit from a
multi-nested inner loop.

-----
Many features in CAlive.  They are all well into development,
including most of the newer ones over the past couple months.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#139291

On 31/12/2018 14:04, Rick C. Hodgin wrote:
> On 12/28/2018 5:08 PM, Richard Damon wrote:
>> On 12/28/18 12:16 PM, Rick C. Hodgin wrote:
>>> How many new symbols have I created, or implemented in CAlive?
>>
>> Looking over the past 6 months of messages, I see suggested:
>>
>> min/max: \/  /\  \/=  /\=
>> swap:    ><
>> shortcut indirect: ~> which later became ~~
>> modulus:  -%

> I have also introduced the underscore-bang operator:  _!
> 
>      https://groups.google.com/d/msg/comp.lang.c/TerqLu1Rvg4/bD4xkKizBgAJ

I must have missed that one. Looking at it now, I still don't understand 
what it does or how it might be useful.

Looking through your CAlive newgroup articles, I can see these new 
operators and symbols, in addition to those above:

   ((...))      as alternative to if (...)
   <<<, >>>     rotates
   /%           divide/mod, but used in very peculiar way
   ==#          ?
   f32#2        The #2 means 2 decimals??
   #            Concatenation of some sort
   !+ +!        ?
   [x]          Same as *x
   ~|...|~      different kinds of 'casks'
   <|...|>
   [|...|]
   (|...|)
   /|...|/
   \|...|/
   |            Alignment operator (to do away with {} and indents)
   <-           Note sure (can't read the note I made)
   _            Dereference? (as in _x and x_f...)
   ?            As in 'if (x?)'
   b<-a         Means same as a->b
   |-, -|       ? 'lbar' and 'rbar'
   <-           To do with pointers again (3rd overload?)
   @            'pass by pointer'
   #x           'before value of x'?
   ##x          reset something or other
   #=           ?
   i|++         I think still increment

Together with the dozens of other puzzling features, I really look 
forward to seeing what a program in this language will look like that 
when using all this lot.

And that's not meant to be complimentary. (Combining this with all of 
supercat's ideas would be even more intriguing.)


>      // As a predicate
>      ((units > 1)) qty /= units;

Why is that better than:

        if (units > 1) qty /= units;

> 
> I've added the /% divide-modulo operator, which operates to
> obtain the divide value and remainder in one op:
> 
>      // Old way:
>      divide_value = a / b;
>      remainder    = a % b;
> 
>      // Using divide-modulo
>      divide_value = a /% b : remainder;

People will want to write:

        divide_value, remainder = a /% b;

(Your use of ":" interferes with "?:" if you still have that.)

> I've introduced the @ character for use when passing a variable
> to indicate it's being passed by reference.

You seem to use & for that purpose, so what's the point of @?

, which include <<<= and >>>= as well as the
> ability to rotate a sub-portion using start#length syntax, as
> in <<7#4<<

<< or <<<?

  to begin rotating at the 7th bit and extend for 4
> bits to the 7th,8th,9th,10th bit.
> 
>      x <<<= 5;           // Rotate the bits in x 5 positions
>      y >>>= 5 : carry; 

And yet one more use of ":". And another example where two things are 
modified in the same expression. (What happens with 'y>>>=5:y;' ?)

> Many features in CAlive.

Clearly.

[toc] | [prev] | [next] | [standalone]

#139295

On 12/31/2018 1:07 PM, Bart wrote:
> On 31/12/2018 14:04, Rick C. Hodgin wrote:
>> On 12/28/2018 5:08 PM, Richard Damon wrote:
>>> On 12/28/18 12:16 PM, Rick C. Hodgin wrote:
>>>> How many new symbols have I created, or implemented in CAlive?
>>>
>>> Looking over the past 6 months of messages, I see suggested:
>>>
>>> min/max: \/  /\  \/=  /\=
>>> swap:    ><
>>> shortcut indirect: ~> which later became ~~
>>> modulus:  -%
> 
>> I have also introduced the underscore-bang operator:  _!
>>
>>      https://groups.google.com/d/msg/comp.lang.c/TerqLu1Rvg4/bD4xkKizBgAJ
> 
> I must have missed that one. Looking at it now, I still don't understand what 
> it does or how it might be useful.
> 
> Looking through your CAlive newgroup articles, I can see these new operators 
> and symbols, in addition to those above:
> 
>    ((...))      as alternative to if (...)
>    <<<, >>>     rotates
>    /%           divide/mod, but used in very peculiar way
>    ==#          ?
>    f32#2        The #2 means 2 decimals??

These are used to compare floating point values to that many decimals in
base-10.  It allows values like 1.999999999 and 2.00000001 to compare as
equal.

>    #            Concatenation of some sort

For readability.  It allows a single operator to span multiple sources,
with each one being together with its cohort in the nth position.  The
example I use is (c1#c2 == 13#10), rather than (c1 == 13 && c2 == 10).
It conveys more clearly you're looking for a 13/10 (CR/LF) pair in two
variables, where as c1 == 13 && c2 == 10 breaks it out and it's not
completely clear.

>    !+ +!        ?

I don't remember these.  I think they were going to be nested comments.
I've since changed the syntax to be /+ and +/ to follow D's syntax.

>    [x]          Same as *x

A new pointer syntax.  And [[x]] for pointer-to-pointer.

>    ~|...|~      different kinds of 'casks'
>    <|...|>
>    [|...|]
>    (|...|)
>    /|...|/
>    \|...|/

Each has a particular purpose.  ~|utility|~ for ad hoc code.  <|logic|>
for decisions, or responding to flow control.  [|definition|] for def-
ining things.  (|reference|) for referencing things.

Other syntaxes are not generally for visible use, but are internal, to
be injected by the compiler, used by the gui editor, etc.

>    |            Alignment operator (to do away with {} and indents)
>    <-           Note sure (can't read the note I made)

Pointers can go either way a->b or b<-a.  It's provided to give con-
textual meaning, such as prev<-p and p->next so they indicate visually
their direction.

>    _            Dereference? (as in _x and x_f...)

All variables have an implicit underscore variable form unless there
is an explicitly created underscore variable name in scope.  If you
create "char* x" there's an implicit _x which is the unsigned integer
equivalent value that can be used.

>    ?            As in 'if (x?)'

An immediate evaluation of x to 0, and returns true or false.  It is
not required, but has utility in something like "if (x? == validState)".
It's the same as "if ((x != NULL) == validState)".

>    b<-a         Means same as a->b
>    |-, -|       ? 'lbar' and 'rbar'

Same as <- and ->, except they categorize the data in the struct
or class as being primary members, or lesser used members.  An
lbar or rbar member is typically set at instantiation, and then
not altered.  It's designed to provide a visual cue that this data
is different than other oft-changing data.

>    <-           To do with pointers again (3rd overload?)

Only one.  If there's more than one please point it out.

>    @            'pass by pointer'

This has changed since that content was originally posted.  The
@ is now used for reference members, and can be an enforced re-
quirement.

>    #x           'before value of x'?

During an assignment, it allows the value to be conveyed with
its before-assignment value, such as "if ((x == f()))" would
now return the value of f(x), but it allows the prior value
of x before it was assigned.

>    ##x          reset something or other

Allows the before value to propagate through the expression
from that point forward, even though it's now been assigned
a new value.

>    #=           ?

Another syntax for #x, one which is specified on the equal
operator.

>    i|++         I think still increment

Yes.  It adds a visual differentiation to let the person know
the value being used is before the increment.  It's only for
postfix operations, since it really is two operations.

I've also added "bit = x?<<;" to do a bit scan and report the
position where the first bit is set.  Same with "bit = >>?x;"
to scan down from msb to lsb.

I've also added ^ parent pointers, so you can reference an
encapsulating structure when you know the pointer or variable
you're referencing is contained in a parent structure.

>> I've added the /% divide-modulo operator, which operates to
>> obtain the divide value and remainder in one op:
>>
>>      // Using divide-modulo
>>      divide_value = a /% b : remainder;
> 
> (Your use of ":" interferes with "?:" if you still have that.)

The ?: syntax has the ?, then the colon.  This syntax only has
the colon.

> , which include <<<= and >>>= as well as the
>> ability to rotate a sub-portion using start#length syntax, as
>> in <<7#4<<
> 
> << or <<<?

The syntax when you use n#m is two before, two after, so it
would be more like <<<<, but with the n#m injected in the
middle.

>   to begin rotating at the 7th bit and extend for 4
>> bits to the 7th,8th,9th,10th bit.
>>
>>      x <<<= 5;           // Rotate the bits in x 5 positions
>>      y >>>= 5 : carry; 
> 
> And yet one more use of ":". And another example where two things are 
> modified in the same expression. (What happens with 'y>>>=5:y;' ?)

Everything in CAlive follows the logical sequence of operations.

The code "y >>>= 5 : y;" will be processed in operator terms.
The : y is an assignment, so after y is loaded, rotated through
carry, it will store the result of the rotate into y, then it
will overwrite y with the 1 or 0 from the carry? bit.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#139298

On 31/12/2018 19:22, Rick C. Hodgin wrote:
> On 12/31/2018 1:07 PM, Bart wrote:

>>    #            Concatenation of some sort
> 
> For readability.  It allows a single operator to span multiple sources,
> with each one being together with its cohort in the nth position.  The
> example I use is (c1#c2 == 13#10), rather than (c1 == 13 && c2 == 10).
> It conveys more clearly you're looking for a 13/10 (CR/LF) pair in two
> variables, where as c1 == 13 && c2 == 10 breaks it out and it's not
> completely clear.

In my dynamic language, there is no specific operator like this, but 
there are several ways of expressing that using existing features:

    if (c1,c2) = (13,10) then       # compare two lists
    if c1..c2 = 13..10 than         # compare two ranges (ordering
                                    # doesn't matter here)
    case (c1,c2)
    when (13,10) then               # test 1st of several pairs

Such syntax can be adapted for static code. The advantage is that is 
much clearer what is being attempted.


>>    !+ +!        ?
> 
> I don't remember these.  I think they were going to be nested comments.
> I've since changed the syntax to be /+ and +/ to follow D's syntax.
> 
>>    [x]          Same as *x

Assuming you are still using * from C, that means that for dereferencing 
a pointer to struct member, you can use:

   (*p).m
   p->m
   m<-p
   [p].m
   p~~m

For dereferencing a double pointer to a struct member, the choices are:

   (*(*q)).m
   (*q)->m
   m<-(*q)
   [[q]].m
   [q]->m
   m<-[q]
   q~~m       # ???

You see the problem? The syntax I use has ONE way to dereference a 
pointer (postfix "^"), and ONE way to select a member ("."):

These examples must be written

      p^.m        # one pointer level, one ^
      q^^.m       # two pointer levels, two ^

Both access one member, so both have one ".". Take out member select:

     p^           # access the whole struct
     q^^

Try and take out the member select part of the 10 or 12 examples in your 
syntax; you can't just remove the ".m", because most of them don't use it.

C syntax has always been a mess that way. Your additions make it worse.


>>    <|...|>
>>    [|...|]
>>    (|...|)
>>    /|...|/
>>    \|...|/
> 
> Each has a particular purpose.  ~|utility|~ for ad hoc code.  <|logic|>
> for decisions, or responding to flow control.  [|definition|] for def-
> ining things.  (|reference|) for referencing things.

Who's ever going to remember that lot? And don't tell me the last two, 
/|...|/ and \|...|/ aren't going to get mixed up, unless that was a typo 
and the last was meant to be \|...|\ (although all of them are a 
complete pain to type).

To add attributes, just have the ONE syntax. The name of the attribute 
will tell you which kind it is.

> Pointers can go either way a->b or b<-a.  It's provided to give con-

In Algol 68, p.m or p->m would be written as m OF p. (There is no 
explicit dereferencing.) But it has just the one choice.) Most languages 
went with variations on p.m.

> All variables have an implicit underscore variable form unless there
> is an explicitly created underscore variable name in scope.  If you
> create "char* x" there's an implicit _x which is the unsigned integer
> equivalent value that can be used.

Say again? I expected you to say that _x means *x, some syntactic sugar. 
You mean that _x means '*(unsigned char)x'?

(My old language could do the first example like this:

    ref char x
    ref. char _x @x
    char c:='A'

    x := &c
    print x           # display pointer address
    print x^          # display A
    print _x          # display A

Again, features of more general use. The "." in the second line 
indicated an auto-deref point. This has now been dropped, while @ 
(equivalence) only works for a native target.)

>>    ?            As in 'if (x?)'
> 
> An immediate evaluation of x to 0, and returns true or false.  It is
> not required, but has utility in something like "if (x? == validState)".
> It's the same as "if ((x != NULL) == validState)".

I actually have this in the form of 'istrue'. But it is so rarely used 
that I had to try it to see if it was available in user code.

In any case, C programs can use 'if (!!x)' for exactly this purpose.

>>    b<-a         Means same as a->b
>>    |-, -|       ? 'lbar' and 'rbar'
> 
> Same as <- and ->, except they categorize the data in the struct
> or class as being primary members, or lesser used members.  An
> lbar or rbar member is typically set at instantiation, and then
> not altered.  It's designed to provide a visual cue that this data
> is different than other oft-changing data.

Ugh. How about some features that simplify coding and make it easier to 
write, read, and understand?

>>    #x           'before value of x'?
> 
> During an assignment, it allows the value to be conveyed with
> its before-assignment value, such as "if ((x == f()))" would
> now return the value of f(x), but it allows the prior value
> of x before it was assigned.

I think this was discussed before in this group. No one could come up 
with a suitable syntax for it, and #x isn't it.

It's a kind of assignment inside an expression, which returns the value 
of the lhs before it was assigned to.

> I've also added "bit = x?<<;" to do a bit scan and report the
> position where the first bit is set.  Same with "bit = >>?x;"
> to scan down from msb to lsb.

What's the point of all these cryptic symbol that might be used once in 
a blue moon? There would be so long between each use, that you will have 
long forgotten what x?<< was ever supposed to be.

x64 calls these ops BSF and BSR. Or bitscanforward and bitscanreverse. 
Just use those names, and no one will ever need to scratch their head 
about them.

> I've also added ^ parent pointers, so you can reference an
> encapsulating structure when you know the pointer or variable
> you're referencing is contained in a parent structure.

This is typical of your explanations that I have to read several and 
still can't grok the meaning or purpose of your feature.

Maybe I am particularly thick, or not very receptive to new ideas. Or 
maybe I am fairly typical and this is a poor feature that is hard to get 
your head around.

>>> I've added the /% divide-modulo operator, which operates to
>>> obtain the divide value and remainder in one op:
>>>
>>>      // Using divide-modulo
>>>      divide_value = a /% b : remainder;
>>
>> (Your use of ":" interferes with "?:" if you still have that.)
> 
> The ?: syntax has the ?, then the colon.  This syntax only has
> the colon.

Can /% be used anywhere an expression can be, or only in conjunction 
with "="? If the former, than /% and ?: can be used in the same 
expression and there can be clashes.

Even if only as above, then someone can write:

   x = a ? b /% c : d ? e @ r : d;

I think the problem is clear.

-- 
bart

[toc] | [prev] | [next] | [standalone]

#139299

On 12/31/2018 4:05 PM, Bart wrote:
> On 31/12/2018 19:22, Rick C. Hodgin wrote:
>> On 12/31/2018 1:07 PM, Bart wrote:
> 
>>>    #            Concatenation of some sort
>>
>> For readability.  It allows a single operator to span multiple sources,
>> with each one being together with its cohort in the nth position.  The
>> example I use is (c1#c2 == 13#10), rather than (c1 == 13 && c2 == 10).
>> It conveys more clearly you're looking for a 13/10 (CR/LF) pair in two
>> variables, where as c1 == 13 && c2 == 10 breaks it out and it's not
>> completely clear.
> 
> In my dynamic language, there is no specific operator like this, but there 
> are several ways of expressing that using existing features:
> 
>     if (c1,c2) = (13,10) then       # compare two lists
>     if c1..c2 = 13..10 than         # compare two ranges (ordering
>                                     # doesn't matter here)
>     case (c1,c2)
>     when (13,10) then               # test 1st of several pairs
> 
> Such syntax can be adapted for static code. The advantage is that is much 
> clearer what is being attempted.

I like your language, Bart.  I think you have some interesting ideas
and perspectives.

>>>    <|...|>
>>>    [|...|]
>>>    (|...|)
>>>    /|...|/
>>>    \|...|/
>>
>> Each has a particular purpose.  ~|utility|~ for ad hoc code.  <|logic|>
>> for decisions, or responding to flow control.  [|definition|] for def-
>> ining things.  (|reference|) for referencing things.
> 
> Who's ever going to remember that lot? And don't tell me the last two, 
> /|...|/ and \|...|/ aren't going to get mixed up, unless that was a typo and 
> the last was meant to be \|...|\ (although all of them are a complete pain to 
> type).

The last two are not designed to be typed by people.  They are unique
identifiers used by the compiler and GUI editor for the purposes of
conveying compile-time information.

     \|cask|/    -- Side coding
     /|cask|\    -- Auto-injected content
     @|cask|@    -- Anchor cask

They serve specific purposes that will be handled automatically and
invisibly by the GUI editor.  That's why they have that syntax.

>> All variables have an implicit underscore variable form unless there
>> is an explicitly created underscore variable name in scope.  If you
>> create "char* x" there's an implicit _x which is the unsigned integer
>> equivalent value that can be used.
> 
> Say again? I expected you to say that _x means *x, some syntactic sugar. You 
> mean that _x means '*(unsigned char)x'?

     char* x = "Hi, mom!";

x was assigned an address by the compiler to reference that data.  Let
us suppose it was 0x123456.  That means printf("0x%x\n"), _x) would print
out 0x123456.

> In any case, C programs can use 'if (!!x)' for exactly this purpose.

Yeah, and I still don't know what that operator does. :-)  I think the
x? conveys information similar to what we see in assembly, with the
carry? flag, sign? flag, zero? flag, etc.  It's actually where I got
that inspiration.

>>>    b<-a         Means same as a->b
>>>    |-, -|       ? 'lbar' and 'rbar'
>>
>> Same as <- and ->, except they categorize the data in the struct
>> or class as being primary members, or lesser used members.  An
>> lbar or rbar member is typically set at instantiation, and then
>> not altered.  It's designed to provide a visual cue that this data
>> is different than other oft-changing data.
> 
> Ugh. How about some features that simplify coding and make it easier to 
> write, read, and understand?

I have those too.  And I would argue these do make it easier, because
the editor can reveal the -| as a -> and put the variables in use in
another color, so it's more clear they're not oft used.  They can also
be declared that way when created using [|lbar|] and [|rbar|] definition
casks (to define something, an attribute about their data, type, or in
this case, utility).

It's all designed to make it easier to read in the editor.

>>>    #x           'before value of x'?
>>
>> During an assignment, it allows the value to be conveyed with
>> its before-assignment value, such as "if ((x == f()))" would
>> now return the value of f(x), but it allows the prior value
>> of x before it was assigned.
> 
> I think this was discussed before in this group. No one could come up with a 
> suitable syntax for it, and #x isn't it.
> 
> It's a kind of assignment inside an expression, which returns the value of 
> the lhs before it was assigned to.

Yes, it's like (auto t = x, x = f(x), t).  #x is an excellent syntax
for it, Bart. :-)  If I had an anchor syntax, I would use it as I
think that would be a better symbol.

>> I've also added "bit = x?<<;" to do a bit scan and report the
>> position where the first bit is set.  Same with "bit = >>?x;"
>> to scan down from msb to lsb.
> 
> What's the point of all these cryptic symbol that might be used once in a 
> blue moon? There would be so long between each use, that you will have long 
> forgotten what x?<< was ever supposed to be.
> 
> x64 calls these ops BSF and BSR. Or bitscanforward and bitscanreverse. Just 
> use those names, and no one will ever need to scratch their head about them.

#define BSF(x) x?<<
#define BSR(x) >>?x

Done.

>> I've also added ^ parent pointers, so you can reference an
>> encapsulating structure when you know the pointer or variable
>> you're referencing is contained in a parent structure.
> 
> This is typical of your explanations that I have to read several and still 
> can't grok the meaning or purpose of your feature.
> 
> Maybe I am particularly thick, or not very receptive to new ideas. Or maybe I 
> am fairly typical and this is a poor feature that is hard to get your head 
> around.

It allows you to pass in a single variable to a remote function,
and gain access to it, it's parent, its grandparent if you know
the scope it comes from, and all other variables of that struc
or class relative to it.

It's a notable stack saver.

>>>> I've added the /% divide-modulo operator, which operates to
>>>> obtain the divide value and remainder in one op:
>>>>
>>>>      // Using divide-modulo
>>>>      divide_value = a /% b : remainder;
> 
> Can /% be used anywhere an expression can be, or only in conjunction with 
> "="? If the former, than /% and ?: can be used in the same expression and 
> there can be clashes.

It currently has no syntax for use anywhere outside of an explicit
equal assignment as above.

> Even if only as above, then someone can write:
> 
>    x = a ? b /% c : d ? e @ r : d;
> 
> I think the problem is clear.

That syntax is not allowed presently.  I don't have a good syntax
for using it as a stand-alone operator.  It only makes sense with
the double-assignment.

I suppose it could use:

     {a /% b : divide_value, remainder};

That might work.  I'll think about it.  It might be better defined
for CAlive in a cask:

     (||a /% b | divide_value | remainder ||)

That way it's encapsulated no matter where it appears.  Casks are
always in this format:

     (||
         left
              | middle
                       | right
                               ||)

The ends determine what it is:

     () reference
     [] definition
     <> logic (like a flow chart)
     And the ~|utility|~ cask injects arbitrary code.

If you only have a middle, it appears as:        (|middle|)
If you have a left and middle, it's:       (||left|middle|)
If you have a right and middle, it's:            (|middle|right||)
If you have all three, it appears as:      (||left|middle|right||)

It's very straight-forward, it's just not well known (yet). :-)

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#139310

On 31/12/2018 21:32, Rick C. Hodgin wrote:
> On 12/31/2018 4:05 PM, Bart wrote:

>> Say again? I expected you to say that _x means *x, some syntactic 
>> sugar. You mean that _x means '*(unsigned char)x'?
> 
>      char* x = "Hi, mom!";
> 
> x was assigned an address by the compiler to reference that data.  Let
> us suppose it was 0x123456.  That means printf("0x%x\n"), _x) would print
> out 0x123456.

Isn't that what happens now with printing 'x'?

>> In any case, C programs can use 'if (!!x)' for exactly this purpose.
> 
> Yeah, and I still don't know what that operator does. :-)

not not. The first converts (-3, -2, -1, 0, 1, 2, 3) to (0, 0, 0, 1, 0, 
0, 0). The second to (1, 1, 1, 0, 1, 1, 1).



   I think the
> x? conveys information similar to what we see in assembly, with the
> carry? flag, sign? flag, zero? flag, etc.  It's actually where I got
> that inspiration.

If you write if(x), while(x), or for(;x;), then it automatically applies 
the effective equivalent of !! to give a true (x!=0) or false (x==0) 
result. (The same with (x && y) and any such combinations.)

You don't need an explicit !! or ?.

I don't see it being the same as carry and zero flags at all. Certainly 
not the zero flag, which does the opposite thing.

> #define BSF(x) x?<<
> #define BSR(x) >>?x
> 
> Done.

Yes, you demonstrated this back-to-front thinking before.

Tell me, what operator do you use to extract (or set) the nth bit of an 
integer value? /That/ would be more useful.


> I suppose it could use:
> 
>      {a /% b : divide_value, remainder};

The lldiv function in C returns a struct of two values. /% ought to also 
return two values, which could also be in the form of a struct, to avoid 
adding more features.

> 
> That might work.  I'll think about it.  It might be better defined
> for CAlive in a cask:
> 
>      (||a /% b | divide_value | remainder ||)
> 
> That way it's encapsulated no matter where it appears.  Casks are
> always in this format:
> 
>      (||
>          left
>               | middle
>                        | right
>                                ||)
> 
> The ends determine what it is:
> 
>      () reference
>      [] definition
>      <> logic (like a flow chart)
>      And the ~|utility|~ cask injects arbitrary code.
> 
> If you only have a middle, it appears as:        (|middle|)
> If you have a left and middle, it's:       (||left|middle|)
> If you have a right and middle, it's:            (|middle|right||)
> If you have all three, it appears as:      (||left|middle|right||)
> 
> It's very straight-forward, it's just not well known (yet). :-)

I've always had a divrem operator, but have never implemented it. When I 
do, it will simply be like this:

     d   := a divrem b        # d:=a%b (% is integer division)
     d,r := a divrem b        # d:=a%b, r:=a rem b

At the moment it would need to be done like this via a function that 
returns both values:

     d    := xdivrem(a,b)     # ignore the second value
     d, r := xdivrem(a,b)

so not inline. But notice I'm not bothered about having a symbol for the 
operator; and I use 'rem' for C's "%".

Notice also I don't need 'casks'.

-- 
bart

[toc] | [prev] | [next] | [standalone]

#139311

Bart <bc@freeuk.com> writes:
[...]
> If you write if(x), while(x), or for(;x;), then it automatically applies 
> the effective equivalent of !! to give a true (x!=0) or false (x==0) 
> result. (The same with (x && y) and any such combinations.)
[...]

That's one way to describe it.  It's now how the standard describes it.

For example, the description of the "if" statement says "the first
substatement is executed if the expression compares unequal to 0",
which I find clearer and simpler than your reformulation.

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139313

On 01/01/2019 00:44, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> If you write if(x), while(x), or for(;x;), then it automatically applies
>> the effective equivalent of !! to give a true (x!=0) or false (x==0)
>> result. (The same with (x && y) and any such combinations.)
> [...]
> 
> That's one way to describe it.  It's now how the standard describes it.
> 
> For example, the description of the "if" statement says "the first
> substatement is executed if the expression compares unequal to 0",
> which I find clearer and simpler than your reformulation.

That's the whole expression. It doesn't really explain how a complex 
expression ends up as zero or not zero. Or the difference between A && B 
when B is 'b==x' and when B is just 'b'.

 From a design and implementation point of view, you have to go into it 
in more detail.

Perhaps simpler might be to say that operands of if(), while(), for(;;), 
&&, || unary !, need to be either already Bool, or have to be converted 
to Bool.

It is that last that can also be done with !!.

-- 
bart

[toc] | [prev] | [next] | [standalone]

#139316

I've dropped comp.lang.c++ from the Newsgroups: header.  C++ rules
are effectively similar to C's, but are described differently.

Bart <bc@freeuk.com> writes:
> On 01/01/2019 00:44, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> If you write if(x), while(x), or for(;x;), then it automatically applies
>>> the effective equivalent of !! to give a true (x!=0) or false (x==0)
>>> result. (The same with (x && y) and any such combinations.)
>> [...]
>> 
>> That's one way to describe it.  It's now how the standard describes it.
>> 
>> For example, the description of the "if" statement says "the first
>> substatement is executed if the expression compares unequal to 0",
>> which I find clearer and simpler than your reformulation.
>
> That's the whole expression. It doesn't really explain how a complex 
> expression ends up as zero or not zero. Or the difference between A && B 
> when B is 'b==x' and when B is just 'b'.
>
>  From a design and implementation point of view, you have to go into it 
> in more detail.

No, you don't.  Any scalar expression can be compared for inequality
to 0.  That's what if(), while(), et al are defined to do.
(The comparison may involve a type conversion.)

> Perhaps simpler might be to say that operands of if(), while(), for(;;), 
> &&, || unary !, need to be either already Bool, or have to be converted 
> to Bool.

Assuming you mean _Bool, no, that's not what they do.  C90 didn't
have a boolean type.  C99 added _Bool, but did not change the
semantics of if(), while(), et al.  A scalar expression used as a
condition is compared for inequality to 0, implying that anything
that compares equal to 0 is treated as false, and anything else
is true.

> It is that last that can also be done with !!.

No, !!expr (for any scalar expression expr) yields a value *of type
int*, either 0 or 1.

    The result of the logical negation operator ! is 0 if the
    value of its operand compares unequal to 0, 1 if the value
    of its operand compares equal to 0. The result has type int.
    The expression !E is equivalent to (0==E).

(C++'s unary ! operator is described differently.)

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139321

On 01/01/2019 03:06, Keith Thompson wrote:

> Bart <bc@freeuk.com> writes:

>>   From a design and implementation point of view, you have to go into it
>> in more detail.
> 
> No, you don't.  Any scalar expression can be compared for inequality
> to 0.  That's what if(), while(), et al are defined to do.
> (The comparison may involve a type conversion.)

It doesn't help when trying to implement if (A), when A represents any 
expression. Assuming A has a suitable scalar type, doing:

   if ((A)!=0)

might work, but is inappropriate when A is (a==b), or A is (a<b && c). 
(And in the latter, the argument applies to the 'c' operand of &&.)

>> Perhaps simpler might be to say that operands of if(), while(), for(;;),
>> &&, || unary !, need to be either already Bool, or have to be converted
>> to Bool.
> 
> Assuming you mean _Bool, no, that's not what they do.  C90 didn't
> have a boolean type.

I deliberately didn't use _Bool. None of my languages have a boolean 
type, but the compilers do have one internally, just for this purpose, 
as something that should be yield by a conditional expression.

>> It is that last that can also be done with !!.
> 
> No, !!expr (for any scalar expression expr) yields a value *of type
> int*, either 0 or 1.
> 
>      The result of the logical negation operator ! is 0 if the
>      value of its operand compares unequal to 0, 1 if the value
>      of its operand compares equal to 0. The result has type int.
>      The expression !E is equivalent to (0==E).

if X is a scalar expression, what's the difference in the value (not 
type) of !!X compared with (_Bool)X?

[toc] | [prev] | [next] | [standalone]

#139333

Bart <bc@freeuk.com> writes:
> On 01/01/2019 03:06, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
[...]
>>> Perhaps simpler might be to say that operands of if(), while(), for(;;),
>>> &&, || unary !, need to be either already Bool, or have to be converted
>>> to Bool.
>> 
>> Assuming you mean _Bool, no, that's not what they do.  C90 didn't
>> have a boolean type.
>
> I deliberately didn't use _Bool. None of my languages have a boolean 
> type, but the compilers do have one internally, just for this purpose, 
> as something that should be yield by a conditional expression.

So you think it's simpler to describe it in terms of a type that exists
only internally in your compiler?  Did you expect the rest of us to know
what you meant by "Bool"?

>>> It is that last that can also be done with !!.
>> 
>> No, !!expr (for any scalar expression expr) yields a value *of type
>> int*, either 0 or 1.
>> 
>>      The result of the logical negation operator ! is 0 if the
>>      value of its operand compares unequal to 0, 1 if the value
>>      of its operand compares equal to 0. The result has type int.
>>      The expression !E is equivalent to (0==E).
>
> if X is a scalar expression, what's the difference in the value (not 
> type) of !!X compared with (_Bool)X?

They differ in type.  I never said they differ in value.

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139340

On 01/01/2019 20:48, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 01/01/2019 03:06, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
> [...]
>>>> Perhaps simpler might be to say that operands of if(), while(), for(;;),
>>>> &&, || unary !, need to be either already Bool, or have to be converted
>>>> to Bool.
>>>
>>> Assuming you mean _Bool, no, that's not what they do.  C90 didn't
>>> have a boolean type.
>>
>> I deliberately didn't use _Bool. None of my languages have a boolean
>> type, but the compilers do have one internally, just for this purpose,
>> as something that should be yield by a conditional expression.
> 
> So you think it's simpler to describe it in terms of a type that exists
> only internally in your compiler?  Did you expect the rest of us to know
> what you meant by "Bool"?

You said C90 didn't have boolean types. I'm saying it doesn't matter. 
I'm sure people will easily guess how such a boolean type might work.

I just found it easier to think about the expression A in if(A), 
while(A) etc as requiring a Bool type, even if such a type doesn't exist 
in the language, and even if it doesn't need to be actually evaluated as 
0 or 1 (often code can act directly on condition flags).

[toc] | [prev] | [next] | [standalone]

#139343

Bart <bc@freeuk.com> writes:
> On 01/01/2019 20:48, Keith Thompson wrote:
[...]
>> So you think it's simpler to describe it in terms of a type that exists
>> only internally in your compiler?  Did you expect the rest of us to know
>> what you meant by "Bool"?
>
> You said C90 didn't have boolean types. I'm saying it doesn't matter. 
> I'm sure people will easily guess how such a boolean type might work.

Yes, I said C90 didn't have a boolean type -- and you snipped the
context in which I explained why that's relevant.

> I just found it easier to think about the expression A in if(A), 
> while(A) etc as requiring a Bool type, even if such a type doesn't exist 
> in the language, and even if it doesn't need to be actually evaluated as 
> 0 or 1 (often code can act directly on condition flags).

I believe that you find it easier.  I trust you're aware that you're
not typical.

But I'm curious, do you understand the description in the standard?
Did you even know what it said before I pointed it out?

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139347

On 02/01/2019 00:09, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 01/01/2019 20:48, Keith Thompson wrote:
> [...]
>>> So you think it's simpler to describe it in terms of a type that exists
>>> only internally in your compiler?  Did you expect the rest of us to know
>>> what you meant by "Bool"?
>>
>> You said C90 didn't have boolean types. I'm saying it doesn't matter.
>> I'm sure people will easily guess how such a boolean type might work.
> 
> Yes, I said C90 didn't have a boolean type -- and you snipped the
> context in which I explained why that's relevant.
> 
>> I just found it easier to think about the expression A in if(A),
>> while(A) etc as requiring a Bool type, even if such a type doesn't exist
>> in the language, and even if it doesn't need to be actually evaluated as
>> 0 or 1 (often code can act directly on condition flags).
> 
> I believe that you find it easier.  I trust you're aware that you're
> not typical.
> 
> But I'm curious, do you understand the description in the standard?
> Did you even know what it said before I pointed it out?
> 

You mean 6.8.4.1p2? No I don't remember looking at it before.

I don't think such expressions in C are much different from many other 
languages, and I've implemented this too many times to be in need of 
such guidance.

The text talks about comparing the expression with 0, which is fine for 
a programmer, but an implementer (this one, anyway) prefers it pinned 
down a little more.

Since an equality comparison with 0 might need to take account of 
multiple widths, and several types (int, pointer, float). A pseudo-bool 
result is just one type, not even a width when there is no actual bool type.

(Also, with certain languages I implement, a bare variable inside such 
an if() expression might not only be a int/float/pointer, but could be 
pretty much anything: string, list, dict etc. Then, usually a non-empty 
value makes it 'true'.

Comparing against 0 wouldn't work. Knowing this must be converted to a 
'bool' works better in that case. The conversion, a form of C's '!!', 
will take care of the type-specific details.)

[toc] | [prev] | [next] | [standalone]

#139350

Bart <bc@freeuk.com> writes:
> On 02/01/2019 00:09, Keith Thompson wrote:
[...]
>> But I'm curious, do you understand the description in the standard?
>> Did you even know what it said before I pointed it out?
>
> You mean 6.8.4.1p2? No I don't remember looking at it before.

So you've been describing how conditions work in C without knowing what
the standard says about them.

> I don't think such expressions in C are much different from many other 
> languages, and I've implemented this too many times to be in need of 
> such guidance.
>
> The text talks about comparing the expression with 0, which is fine for 
> a programmer, but an implementer (this one, anyway) prefers it pinned 
> down a little more.

The description in the standard tells you everything you need to know to
implement it, if you're willing to think about it a little.

> Since an equality comparison with 0 might need to take account of 
> multiple widths, and several types (int, pointer, float). A pseudo-bool 
> result is just one type, not even a width when there is no actual bool type.

A comparison with 0 may require a type conversion, as clearly described
by the C standard.

> (Also, with certain languages I implement,
[snip]

We were talking about C.  Of course if you're implementing something
other than C, you should follow the rules of that language.

[...]

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139351

On 02/01/2019 01:53, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 02/01/2019 00:09, Keith Thompson wrote:
> [...]
>>> But I'm curious, do you understand the description in the standard?
>>> Did you even know what it said before I pointed it out?
>>
>> You mean 6.8.4.1p2? No I don't remember looking at it before.
> 
> So you've been describing how conditions work in C without knowing what
> the standard says about them.
> 
>> I don't think such expressions in C are much different from many other
>> languages, and I've implemented this too many times to be in need of
>> such guidance.
>>
>> The text talks about comparing the expression with 0, which is fine for
>> a programmer, but an implementer (this one, anyway) prefers it pinned
>> down a little more.
> 
> The description in the standard tells you everything you need to know to
> implement it, if you're willing to think about it a little.
> 
>> Since an equality comparison with 0 might need to take account of
>> multiple widths, and several types (int, pointer, float). A pseudo-bool
>> result is just one type, not even a width when there is no actual bool type.
> 
> A comparison with 0 may require a type conversion, as clearly described
> by the C standard.
> 
>> (Also, with certain languages I implement,
> [snip]
> 
> We were talking about C.  Of course if you're implementing something
> other than C, you should follow the rules of that language.

There are several approaches to describing what is happening. The 
language reference necessary has to choose one. That doesn't mean it is 
the only possible one. (Think about that when next quoting chapter and 
verse.)

And if you take it literally, it means that:

   if (a==b && c==d)

needs to treated as though it was written as:

   if ((a==b && c==d) != 0)

Although this will work, it is also unnecessary. With my approach, the 
if-expression must be 0 or 1, and the result of && is already 0 or 1.

[toc] | [prev] | [next] | [standalone]

#139355 — Leader Kiki is not going to like this... (Was: Range-aware modulo operator -%)

In article <0tVWD.263283$DWh1.99504@fx36.am4>, Bart  <bc@freeuk.com> wrote:
...
>There are several approaches to describing what is happening. The 
>language reference necessary has to choose one. That doesn't mean it is 
>the only possible one. (Think about that when next quoting chapter and 
>verse.)

Uh oh.

Leader Kiki is not going to like this...

Leader K is firmly entrenched in the idea that there is exactly one
correct way.  To do (or say) anything.  Exactly one way.

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/Pearls

[toc] | [prev] | [next] | [standalone]

#139356

Bart <bc@freeuk.com> writes:
[...]
> There are several approaches to describing what is happening. The
> language reference necessary has to choose one. That doesn't mean it
> is the only possible one. (Think about that when next quoting chapter
> and verse.)

Sure.  Why would you not at least look at what the standard says before
making up your own description *that doesn't improve on what the
standard already says*?

> And if you take it literally, it means that:
>
>   if (a==b && c==d)
>
> needs to treated as though it was written as:
>
>   if ((a==b && c==d) != 0)
>
> Although this will work, it is also unnecessary. With my approach, the
> if-expression must be 0 or 1, and the result of && is already 0 or 1.

Of course it's unnecessary.  Read N1570 5.1.2.3p4, and feel free to take
it literally.

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139354

On 01/01/2019 04:54 PM, Bart wrote:
> I just found it easier to think about the expression A in if(A),
> while(A) etc as requiring a Bool type, even if such a type doesn't exist
> in the language, and even if it doesn't need to be actually evaluated as
> 0 or 1 (often code can act directly on condition flags).

Are you suggesting booleans with teeth like C#? I'm starting to warm to 
the idea but it would break much existing C code. I'm sure I'm not the 
only person to write

if (strcmp("foo", bar)) { ... }

That has the additional feature of confusing novice programmers.

[toc] | [prev] | [next] | [standalone]

#139359

On 02/01/2019 05:40, rbowman wrote:
> On 01/01/2019 04:54 PM, Bart wrote:
>> I just found it easier to think about the expression A in if(A),
>> while(A) etc as requiring a Bool type, even if such a type doesn't exist
>> in the language, and even if it doesn't need to be actually evaluated as
>> 0 or 1 (often code can act directly on condition flags).
> 
> Are you suggesting booleans with teeth like C#?

On the contrary, I never use actual booleans at all, but make a lot of 
use of integers that have values 0 or 1. (And those will invariably be 
of a standard 'int' type.)

  I'm starting to warm to
> the idea but it would break much existing C code. I'm sure I'm not the 
> only person to write
> 
> if (strcmp("foo", bar)) { ... }
> 
> That has the additional feature of confusing novice programmers.

I no longer use strcmp except for short pieces of portable C where I 
don't want extra dependencies.

I now mainly use a wrapper function eqstring(s,t), which returns 1 if 
equal, 0 if unequal.

If I still need an an actual relative compare, I'd use one called 
cmpstring(s,t) which is guaranteed to return one of -1, 0 or 1. (strcmp 
doesn't have that guarantee.)

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web