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

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

Shorthand ~> pointers

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

Contents

  Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-19 21:31 -0500
    Re: Shorthand ~> pointers bitrex <user@example.net> - 2018-12-20 03:29 -0500
      Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 06:40 -0500
    Re: Shorthand ~> pointers Andrew Smallshaw <andrews@sdf.org> - 2018-12-20 10:23 +0000
      Re: Shorthand ~> pointers Bart <bc@freeuk.com> - 2018-12-20 11:15 +0000
        Re: Shorthand ~> pointers David Brown <david.brown@hesbynett.no> - 2018-12-20 13:46 +0100
          Re: Shorthand ~> pointers mark.bluemel@gmail.com - 2018-12-20 05:04 -0800
            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 05:11 -0800
      Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 03:25 -0800
      Re: Shorthand ~> pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-20 11:51 +0000
        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 06:54 -0500
          Re: Shorthand ~> pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-20 12:17 +0000
            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 07:21 -0500
              Re: Shorthand ~> pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-20 14:18 +0000
                Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 09:26 -0500
            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 04:29 -0800
              Re: Shorthand ~> pointers mark.bluemel@gmail.com - 2018-12-20 04:46 -0800
              Re: Shorthand ~> pointers David Brown <david.brown@hesbynett.no> - 2018-12-20 15:00 +0100
        Re: Shorthand ~> pointers scott@slp53.sl.home (Scott Lurndal) - 2018-12-20 14:26 +0000
          Re: Shorthand ~> pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-20 15:03 +0000
          Re: Shorthand ~> pointers James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-20 07:05 -0800
    Re: Shorthand ~> pointers "Fred.Zwarts" <F.Zwarts@KVI.nl> - 2018-12-20 11:16 +0100
      Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 07:16 -0500
    Re: Shorthand ~> pointers Bart <bc@freeuk.com> - 2018-12-20 12:39 +0000
      Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 08:20 -0500
        Re: Shorthand ~> pointers Bart <bc@freeuk.com> - 2018-12-20 14:02 +0000
          Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-20 09:15 -0500
            Re: Shorthand ~> pointers Bart <bc@freeuk.com> - 2018-12-20 17:48 +0000
      Re: Shorthand ~> pointers Juha Nieminen <nospam@thanks.invalid> - 2018-12-21 11:36 +0000
        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-21 08:05 -0500
          Re: Shorthand ~> pointers scott@slp53.sl.home (Scott Lurndal) - 2018-12-21 14:56 +0000
            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-21 10:03 -0500
              Re: Shorthand ~> pointers scott@slp53.sl.home (Scott Lurndal) - 2018-12-21 15:35 +0000
                Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-21 10:41 -0500
                  Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-21 15:41 +0000
                  Re: Shorthand ~> pointers scott@slp53.sl.home (Scott Lurndal) - 2018-12-21 17:04 +0000
                    Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-21 12:23 -0500
          Re: Shorthand ~> pointers scott@slp53.sl.home (Scott Lurndal) - 2018-12-21 14:57 +0000
            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-21 10:20 -0500
              Re: Shorthand ~> pointers scott@slp53.sl.home (Scott Lurndal) - 2018-12-21 15:37 +0000
                Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-21 10:42 -0500
                  Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-21 15:42 +0000
                  Re: Shorthand ~> pointers David Brown <david.brown@hesbynett.no> - 2018-12-21 17:39 +0100
                  Re: Shorthand ~> pointers scott@slp53.sl.home (Scott Lurndal) - 2018-12-21 17:05 +0000
                    Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-21 12:24 -0500
                      Re: Shorthand ~> pointers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-21 23:49 -0800
                        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-22 13:05 -0500
                          Re: Shorthand ~> pointers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-22 16:38 -0800
          Re: Shorthand ~> pointers Juha Nieminen <nospam@thanks.invalid> - 2018-12-22 18:39 +0000
            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-22 13:42 -0500
              Re: Shorthand ~> pointers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-22 16:23 -0800
                Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-22 21:52 -0500
                  Re: Shorthand ~> pointers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-22 20:26 -0800
                    Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-22 23:54 -0500
                      Re: Shorthand ~> pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-23 12:43 +0000
                        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 08:34 -0500
                          Re: Shorthand ~> pointers James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-23 08:09 -0800
                            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 11:56 -0500
              Re: Shorthand ~> pointers Juha Nieminen <nospam@thanks.invalid> - 2018-12-23 08:24 +0000
                Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 08:24 -0500
                  Re: Shorthand ~> pointers Bart <bc@freeuk.com> - 2018-12-23 15:28 +0000
                    Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 12:15 -0500
                      Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-23 17:24 +0000
                        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 12:35 -0500
                          Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-23 17:39 +0000
                            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 14:07 -0500
                              Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-23 19:17 +0000
                                Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 14:52 -0500
                                  Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-23 21:14 +0000
                                  Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-23 21:36 +0000
                                    Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 19:24 -0500
                                      Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-24 10:14 +0000
                                        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-24 07:53 -0500
                                          Re: Shorthand ~> pointers gazelle@shell.xmission.com (Kenny McCormack) - 2018-12-24 14:16 +0000
                                            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-24 10:17 -0500
                                          Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-24 15:36 +0000
                                            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-24 10:43 -0500
                                              Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-24 15:46 +0000
                                              Re: Shorthand ~> pointers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-24 14:16 -0800
                                                Re: Shorthand ~> pointers Melzzzzz <Melzzzzz@zzzzz.com> - 2018-12-24 22:36 +0000
                                                Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-24 18:35 -0500
                                                  Re: Shorthand ~> pointers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-24 15:44 -0800
                                                    Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-24 18:55 -0500
                                                      Re: Shorthand ~> pointers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-25 22:20 -0800
                                                        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-26 05:32 -0500
                                                          You are so full of shit (Was: Shorthand ~> pointers) gazelle@shell.xmission.com (Kenny McCormack) - 2018-12-26 14:10 +0000
                                                            Re: You are so full of .. (Was: Shorthand ~> pointers) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-26 09:47 -0500
                                                              Re: You are so full of shit (Was: Shorthand ~> pointers) gazelle@shell.xmission.com (Kenny McCormack) - 2018-12-26 15:21 +0000
                      Re: Shorthand ~> pointers Ian Collins <ian-news@hotmail.com> - 2018-12-24 08:26 +1300
                        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 15:02 -0500
                        Re: Shorthand ~> pointers Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-28 08:21 -0800
                      Re: Shorthand ~> pointers nobody@example.org (Scott) - 2018-12-25 03:56 +0000
                        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-24 23:55 -0500
                          Re: Shorthand ~> pointers Richard Damon <Richard@Damon-Family.org> - 2018-12-25 10:14 -0500
                            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-25 10:36 -0500
                    Re: Shorthand ~> pointers Juha Nieminen <nospam@thanks.invalid> - 2018-12-24 14:22 +0000
                      Re: Shorthand ~> pointers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-24 15:47 -0800
              Re: Shorthand ~> pointers Reinhardt Behm <rbehm@hushmail.com> - 2018-12-23 16:31 +0800
                Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 08:28 -0500
    Re: Shorthand ~> pointers nobody@example.org (Scott) - 2018-12-21 01:14 +0000
      Re: Shorthand ~> pointers "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2018-12-21 03:23 +0100
        Re: Shorthand ~> pointers nobody@example.org (Scott) - 2018-12-21 09:45 +0000
          Re: Shorthand ~> pointers David Brown <david.brown@hesbynett.no> - 2018-12-21 12:05 +0100
          Re: Shorthand ~> pointers Vir Campestris <vir.campestris@invalid.invalid> - 2018-12-21 21:24 +0000
            Re: Shorthand ~> pointers scott@slp53.sl.home (Scott Lurndal) - 2018-12-21 21:47 +0000
            Re: Shorthand ~> pointers David Brown <david.brown@hesbynett.no> - 2018-12-22 16:09 +0100
              Re: Shorthand ~> pointers Richard Damon <Richard@Damon-Family.org> - 2018-12-22 11:49 -0500
                Re: Shorthand ~> pointers Bart <bc@freeuk.com> - 2018-12-22 18:41 +0000
                  Re: Shorthand ~> pointers Anton Shepelev <anton.txt@gmail.com> - 2018-12-22 21:48 +0300
                    Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-22 14:00 -0500
                      Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-22 19:08 +0000
                        Re: Shorthand ~> pointers fir <profesor.fir@gmail.com> - 2018-12-22 16:42 -0800
                      Re: Shorthand ~> pointers Richard Damon <Richard@Damon-Family.org> - 2018-12-22 17:10 -0500
                        Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-22 17:42 -0500
                          Re: Shorthand ~> pointers Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-23 10:19 +0000
                            Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-23 08:40 -0500
                Re: Shorthand ~> pointers Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-25 21:00 +0000
      Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-21 07:57 -0500
    Re: Shorthand ~> pointers Bonita Montero <Bonita.Montero@gmail.com> - 2018-12-24 14:38 +0100
      Re: Shorthand ~> pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-24 10:26 -0500
        Re: Shorthand ~> pointers Bonita Montero <Bonita.Montero@gmail.com> - 2018-12-28 13:35 +0100

Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

#138787

On Thursday, December 20, 2018 at 9:27:06 AM UTC-5, Scott Lurndal wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> >Andrew Smallshaw <andrews@sdf.org> writes:
> >
> >> On 2018-12-20, Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> >>> I've had the idea to introduce the ~> symbol for shorthand pointers.
> >>
> >>> It would only work for uniquely named members, but could also be
> >>> used from a relative point where, from that point down the rest
> >>> of the hierarchy it is then unique.
> >>
> >> What an absolutely horrid idea.  So adding a new variable to a
> >> structure causes well-written code to break when it was fine before?
> >
> >Break, in the sense of issue a diagnostic, yes, but I don't think it can
> >break in the sense of suddenly and silently meaning something else
> >because of the uniqueness requirement.
> 
> Changing the language definition in such a way as to cause
> existing code to not compile is by definition "breaking" it.

Code that contains the tokens '~' immediately followed by the token '>'
is currently a syntax error. Do you think there's any significant amount
of such code?

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

#138769

Would it also traverse more then 2 levels?
When traversing the descendants, would it also traverse pointers to members
in pointers to members, etc.? With other words, would it also work with

     struct SChild
     {
         SGrandChild  * gc;
     };

This operator may save a few keystrokes, but it makes reading the code
more difficult.

I am afraid that it will make debugging of code more difficult, in
particular if there is not such a trivial nesting of simple classes, but a
hierarchy of deeply nested complex classes. If there is a problem with the
member, it might not be easy to find its declaration, as it can be in one of
many class definitions, declared in many different files. 

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

#138770

On 12/20/18 5:16 AM, Fred.Zwarts wrote:
> Would it also traverse more then 2 levels?

Yes.

> When traversing the descendants, would it also traverse pointers to members
> in pointers to members, etc.? With other words, would it also work with
> 
>      struct SChild
>      {
>          SGrandChild  * gc;
>      };

Yes.

> This operator may save a few keystrokes, but it makes reading the code
> more difficult.

Sometimes.

> I am afraid that it will make debugging of code more difficult, in
> particular if there is not such a trivial nesting of simple classes, but a
> hierarchy of deeply nested complex classes. If there is a problem with the
> member, it might not be easy to find its declaration, as it can be in 
> one of
> many class definitions, declared in many different files.

It must be used where appropriate.  But in many cases, it would be
desirable to have this feature.  Certainly not in all.

This idea came about because I'm currently working on a project and
I have many sub-references into a fixed number of members that use
structs to aggregate common data items.  It would simplify many lines
of code and make the overall concept of what's happening much easier
to understand.

In these types of cases, it would probably make debugging easier.
The debugger and editor could be configured to auto-expand the short-
hand reference, so you can access child members as needed.

-- 
Rick C. Hodgin

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

#138774

On 20/12/2018 02:31, Rick C. Hodgin wrote:
> I've had the idea to introduce the ~> symbol for shorthand pointers.
> 
> These are pointers which access uniquely named child member objects
> without having to traverse the child member hierarchy to get there:
> 
>      // Define a structure hierarchy example
>      struct SGrandChild
>      {
>          s32  gcint;
>      };
> 
>      struct SChild
>      {
>          SGrandChild  gc;
>      };
> 
>      struct SExample
>      {
>          SChild* child;
>      };
> 
>      // Use in code:
>      SExample* e = generate_new_e();
>      e->child->gc.gcInt = 5;     // Traditional access
>      e~>gcInt           = 5;     // Shorthand access
> 
> It would only work for uniquely named members, but could also be
> used from a relative point where, from that point down the rest
> of the hierarchy it is then unique.

Uniqueness of the member might not be enough. There might be multiple 
paths to that unique member; does a~>c mean:

    a -> x -> c

or:

    a -> y -> c   ?

There is no other member called 'c' in any struct accessible via 'a'.

And to continue, could a~>c also mean:

   a -> u -> v -> c  ?

Here, the possible graph of different paths to check could become 
exponential (and in the next example, also recursive).

Plus there are times when it could mean one of these:

   a -> c
   a -> next -> c
   a -> next -> next -> c
   etc

So I think it is troublesome.

(The a~>c example is illustrated in a more realistic example here, using 
"." rather than "->":

     typedef struct {int x, y;} Point;
     typedef struct {Point p, q;} Vector;
     Vector a, b;

     a~.x

This could mean a.p.x or a.q.x. All member names are unique.)

-- 
bart

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

#138779

On 12/20/2018 7:39 AM, Bart wrote:
> On 20/12/2018 02:31, Rick C. Hodgin wrote:
>> I've had the idea to introduce the ~> symbol for shorthand pointers.
>>
>> These are pointers which access uniquely named child member objects
>> without having to traverse the child member hierarchy to get there:
>>
>>      // Define a structure hierarchy example
>>      struct SGrandChild
>>      {
>>          s32  gcint;
>>      };
>>
>>      struct SChild
>>      {
>>          SGrandChild  gc;
>>      };
>>
>>      struct SExample
>>      {
>>          SChild* child;
>>      };
>>
>>      // Use in code:
>>      SExample* e = generate_new_e();
>>      e->child->gc.gcInt = 5;     // Traditional access
>>      e~>gcInt           = 5;     // Shorthand access
>>
>> It would only work for uniquely named members, but could also be
>> used from a relative point where, from that point down the rest
>> of the hierarchy it is then unique.
> 
> Uniqueness of the member might not be enough. There might be multiple paths 
> to that unique member; does a~>c mean:
> 
>     a -> x -> c
> 
> or:
> 
>     a -> y -> c   ?

In such cases it would be ambiguous and unusable.  I would generate a
diagnostic indicating the same.

> There is no other member called 'c' in any struct accessible via 'a'.
> 
> And to continue, could a~>c also mean:
> 
>    a -> u -> v -> c  ?

Again, ambiguous.  I suppose an extension could be added to allow a~>v->c.
It would bypass the parts between a..v to arrive at that location where the
c member is then unique from there.  I'll consider that.

> Here, the possible graph of different paths to check could become exponential 
> (and in the next example, also recursive).
> 
> Plus there are times when it could mean one of these:
> 
>    a -> c
>    a -> next -> c
>    a -> next -> next -> c
>    etc
> 
> So I think it is troublesome.

a~>c would terminate at c, and not go into self-repeating structures or
classes.  It would go to an extent out that does not have some kind of
recursion.

> (The a~>c example is illustrated in a more realistic example here, using "." 
> rather than "->":
> 
>      typedef struct {int x, y;} Point;
>      typedef struct {Point p, q;} Vector;
>      Vector a, b;
> 
>      a~.x
> 
> This could mean a.p.x or a.q.x. All member names are unique.)

There is no ~. syntax in my thinking / proposal.  The a~>x syntax would
be used to access direct terminal members that are uniquely named.  It
would not enter recursive pointers, or pointers to prior parts of its
own structure / design.  It would refer to members which are unique in
all ways from the use of the ~> shorthand pointer.

-- 
Rick C. Hodgin

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

#138781

On 20/12/2018 13:20, Rick C. Hodgin wrote:
> On 12/20/2018 7:39 AM, Bart wrote:

>> And to continue, could a~>c also mean:
>>
>>    a -> u -> v -> c  ?
> 
> Again, ambiguous.

Yes it is. But you have to establish first that it is not ambiguous 
before allowing a construct like that, and I have a feeling that it 
might not be trivial.

>>    a -> c
>>    a -> next -> c

> a~>c would terminate at c,

This suggests a problem of the kind someone already mentioned: a~>c maps 
to a->x->c, until a new member 'c' is added to the struct at a->, and 
now all those a~>c means something slightly different.

Would this now class a~>c as ambiguous or not? As you're saying the 
search terminates at the first match.

There is a similar problem to this; suppose you have a program where 
this is a valid access:

     a -> b -> c

and then you change things around so that a->b->c is no longer valid but:

     a -> x -> y -> c

is. In normal code, this would be detected, and you would need to update 
it. But if "a ~> c" was used for "a -> b -> c", this is now still legal, 
and instead maps to "a -> x -> y ->", which could mean something different.

>>      a~.x
>>
>> This could mean a.p.x or a.q.x. All member names are unique.)
> 
> There is no ~. syntax in my thinking / proposal.

Well, you said elsewhere that you treat . and -> as the same thing. So that:

     a.b.c.d.e.f  and  a->b->c->d->e->f

or any combinations or "." and "->", are all valid. So that a~>f could 
be used for any combination. Then it comes down to whether you would use 
"~>" rather than "~.". If the former, then my example becomes "a~>x".

> The a~>x syntax would
> be used to access direct terminal members that are uniquely named.  It
> would not enter recursive pointers, or pointers to prior parts of its
> own structure / design.  It would refer to members which are unique in
> all ways from the use of the ~> shorthand pointer.

(Your entire proposal is equivalent to taking a file path like this:

     /a/b/c/d/e/f.txt

and trying to get away with writing only:

     /a/~f.txt

or some such syntax. This is actually feasible, but the issues involved 
are easier to appreciate.)


-- 
bart

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

#138782

On 12/20/2018 9:02 AM, Bart wrote:
> On 20/12/2018 13:20, Rick C. Hodgin wrote:
>> On 12/20/2018 7:39 AM, Bart wrote:
> 
>>> And to continue, could a~>c also mean:
>>>
>>>    a -> u -> v -> c  ?
>>
>> Again, ambiguous.
> 
> Yes it is. But you have to establish first that it is not ambiguous before 
> allowing a construct like that, and I have a feeling that it might not be 
> trivial.

To me it is trivial.  I enter a recursion look searching for the named
token tree, but when it's found it continues looking and returns the
count found in addition to the last one found.  If the count is one,
the reference is valid.  If the count is not one, invalid.

>>>    a -> c
>>>    a -> next -> c
> 
>> a~>c would terminate at c,
> 
> This suggests a problem of the kind someone already mentioned: a~>c maps to 
> a->x->c, until a new member 'c' is added to the struct at a->, and now all 
> those a~>c means something slightly different.

The introduction of another "c" would cause a problem.  It would then
introduce a new ambiguity that did not previously exist, and the code
would now be in error.

It would be similar to if you renamed "c" to "c2".  Every prior reference
to "c" would now generate an error.

I actually use that feature sometimes, by the way, to document all places
in a program where a particular member is used. :-)

> Would this now class a~>c as ambiguous or not? As you're saying the search 
> terminates at the first match.

I've never said it terminates at the first match.  It terminates at the
terminal levels, meaning it won't enter recursion.  A link-list pointer
would not be traverseable as you indicated:

     a->c
     a->next->c
     a->next->next->c
     etc

It would stop at the a->c in that case, and not descend further.  But in
determining if something is unique or not, it performs a search and then
does not stop at the first find, but continues to see if any other names
match up at the tree/level being searched.

> There is a similar problem to this; suppose you have a program where this is 
> a valid access:
> 
>      a -> b -> c
> 
> and then you change things around so that a->b->c is no longer valid but:
> 
>      a -> x -> y -> c
> 
> is. In normal code, this would be detected, and you would need to update it. 
> But if "a ~> c" was used for "a -> b -> c", this is now still legal, and 
> instead maps to "a -> x -> y ->", which could mean something different.

Correct.  I do not see that as a problem.  I see it as a feature of this
awesome shorthand pointer syntax.  In this case, you would not have to
change any of your code, making refactoring much easier.

>>>      a~.x
>>>
>>> This could mean a.p.x or a.q.x. All member names are unique.)
>>
>> There is no ~. syntax in my thinking / proposal.
> 
> Well, you said elsewhere that you treat . and -> as the same thing. So that:
> 
>      a.b.c.d.e.f  and  a->b->c->d->e->f
> 
> or any combinations or "." and "->", are all valid. So that a~>f could be 
> used for any combination. Then it comes down to whether you would use "~>" 
> rather than "~.". If the former, then my example becomes "a~>x".

I did say that.  I had never intended to allow ~. as an extension of that.
I intend for ~> to be its own thing.  In fact, based on bitrex's comment
that ~ and - are not easily distinguishable in some fonts or display devices,
maybe it should just be a ~~ syntax bit itself, like a~~b rather than having
to use . or > ... something to consider.

I think I might like that.  a~~x rather than a~>x or a~.x ... Hmmm...

>> The a~>x syntax would
>> be used to access direct terminal members that are uniquely named.  It
>> would not enter recursive pointers, or pointers to prior parts of its
>> own structure / design.  It would refer to members which are unique in
>> all ways from the use of the ~> shorthand pointer.
> 
> (Your entire proposal is equivalent to taking a file path like this:
> 
>      /a/b/c/d/e/f.txt
> 
> and trying to get away with writing only:
> 
>      /a/~f.txt
> 
> or some such syntax. This is actually feasible, but the issues involved are 
> easier to appreciate.)

Yes exactly.  It seems completely doable for a compiled language like
C or C++ where the exact syntax of everything is known at compile-time
and not resolved at runtime.

It would also work where it is resolved at runtime, but would be slow
because each reference would need to do a full live search as things
can be dynamically added or removed at runtime in those models, and if
there is a multi-thread model at work ... it could've happened between
two lines of code in one thread that something new was added or removed.

There's no doubt it requires some developer constraints on use, but I
believe it is an excellent extension for many types of coding scenarios.

-- 
Rick C. Hodgin

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

#138800

On 20/12/2018 14:15, Rick C. Hodgin wrote:
> On 12/20/2018 9:02 AM, Bart wrote:
>> On 20/12/2018 13:20, Rick C. Hodgin wrote:
>>> On 12/20/2018 7:39 AM, Bart wrote:
>>
>>>> And to continue, could a~>c also mean:
>>>>
>>>>    a -> u -> v -> c  ?
>>>
>>> Again, ambiguous.
>>
>> Yes it is. But you have to establish first that it is not ambiguous 
>> before allowing a construct like that, and I have a feeling that it 
>> might not be trivial.
> 
> To me it is trivial.  I enter a recursion look searching for the named
> token tree, but when it's found it continues looking and returns the
> count found in addition to the last one found.  If the count is one,
> the reference is valid.  If the count is not one, invalid.

It means doing a full tree traversal in the cases where the construct 
/is/ allowed. With special rules when recursion occurs. And with normal 
name resolution to be applied at each step.

I think there are other complications. Take this normal sequence:

    a -> b -> c -> c

What should a~>c or a~~c expand to? As it is, this could be ambiguous.

But what about a~~c->c? The last part matches the c->c of the normal 
sequence, so the ambiguity disappears, but only provided there is no 
possibility of doing:

    a -> b -> c -> c -> x -> y -> c

Given that, it would mean pattern-matching the ends of all possible 
sequences.

I think, as Ben suggested, this might be better off inside a tool. Then 
the experience of using it there might later lead to a more rigorously 
defined proposal.

In source code, I think seeing:

    a -> b -> c -> c

is more useful than seeing:

    a ~~ c

which would lead to the casual reader of the code either having to to 
their own tree traversal (after first tracking down all relevant struct 
definitions), or needing to use special tools.

-- 
bart

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

#138846

In comp.lang.c++ Bart <bc@freeuk.com> wrote:
> Uniqueness of the member might not be enough. There might be multiple 
> paths to that unique member

Another problem is that a member may become non-unique in the future,
breaking all code that uses the shortcut syntax.

Suppose there are thousands of instances of accessing a member using
the shortcut syntax, and then you simply add a new member object to
the struct/class which happens to introduce an ambiguity. Suddenly
those thousands of lines of code just broke, and need to be fixed,
even though nothing that already existed in the struct/class was
changed, only a new member object was added.

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

#138851

On 12/21/2018 6:36 AM, Juha Nieminen wrote:
> In comp.lang.c++ Bart <bc@freeuk.com> wrote:
>> Uniqueness of the member might not be enough. There might be multiple
>> paths to that unique member
> 
> Another problem is that a member may become non-unique in the future,
> breaking all code that uses the shortcut syntax.

Two things:  #1 -- The developer making that change would know it
immediately, and likely then pick another name, or #2 the ability
would be introduced to allow automatic refactoring of any instances
of the ~~ use, so that you are no longer only a typist, you are now
part of a system that knows the software, and is able to refactor
things for you intelligently.

Our toolsets must grow up and be more than piecemeal.  They need to
be integrated so that you're in a system, not just a functional com-
ponent of a system.

> Suppose there are thousands of instances of accessing a member using
> the shortcut syntax, and then you simply add a new member object to
> the struct/class which happens to introduce an ambiguity. Suddenly
> those thousands of lines of code just broke, and need to be fixed,
> even though nothing that already existed in the struct/class was
> changed, only a new member object was added.

Use a different name for the new name collision (problem solved), or
use the built-in refactoring tools to expand out all instances of the
collision name so that they are unique (problem solved).

You must not be limited in your thinking by what we have today, but
you must expand your thinking to address problems by solving even the
deeper issues that are there.

I've used this example before.  You approach a 1700s farmer and tell
him about how you can make his life easier.  He says, "How?"  You
say, you'll need about 1500 lbs of refined metal, a hundred pounds
of the finest safety glass, specialized rubber materials, specialized
alloys for various parts (like pistons, rings, bearings), and you'll
need a large factory to manufacture all of this stuff with hundreds,
maybe thousands of workers on an assembly line and when it's finished,
you need gallons and gallons of refined fuel brought up from oil thou-
sands of feet down in the ground ... and he looks at you like you're
insane.  But very few people would state that a pickup truck has less
utility than a horse and wagon for most tasks.  The horse may be be
better for going into the woods, but the truck is better for nearly
every other task.

You must get past your horse.  You must seek to build the full infra-
structure we need, and proceed with your vision there.  You can't
just move piecemeal in bits over time.  A vision has to be brought
forth, pursued, with effort put into the long-range vision.  It's a
type of terraforming the computer landscape.  The disparate vistas
of varying inhospitable climates seen today... they need to be colon-
ized, populated, roads need to be built between various areas, and
so on.

It must be made livable, and even beautiful, for the long term.

-- 
Rick C. Hodgin

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

#138857

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>On 12/21/2018 6:36 AM, Juha Nieminen wrote:
>> In comp.lang.c++ Bart <bc@freeuk.com> wrote:
>>> Uniqueness of the member might not be enough. There might be multiple
>>> paths to that unique member
>> 
>> Another problem is that a member may become non-unique in the future,
>> breaking all code that uses the shortcut syntax.
>
>Two things:  #1 -- The developer making that change would know it
>immediately, and likely then pick another name,

No, the developer is likely to discard the stupid compiler and
use one that doesn't fuck up his perfectly good program.   Especially
when recompiling a 20 year old source base.

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

#138859

On 12/21/2018 9:56 AM, Scott Lurndal wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> On 12/21/2018 6:36 AM, Juha Nieminen wrote:
>>> In comp.lang.c++ Bart <bc@freeuk.com> wrote:
>>>> Uniqueness of the member might not be enough. There might be multiple
>>>> paths to that unique member
>>>
>>> Another problem is that a member may become non-unique in the future,
>>> breaking all code that uses the shortcut syntax.
>>
>> Two things:  #1 -- The developer making that change would know it
>> immediately, and likely then pick another name,
> 
> No, the developer is likely to discard the stupid compiler and
> use one that doesn't .. his perfectly good program.   Especially
> when recompiling a 20 year old source base.

How many of those 20 year old source code bases used the new ~~ syntax,
Scott?

-- 
Rick C. Hodgin

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

#138864

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>On 12/21/2018 9:56 AM, Scott Lurndal wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>> On 12/21/2018 6:36 AM, Juha Nieminen wrote:
>>>> In comp.lang.c++ Bart <bc@freeuk.com> wrote:
>>>>> Uniqueness of the member might not be enough. There might be multiple
>>>>> paths to that unique member
>>>>
>>>> Another problem is that a member may become non-unique in the future,
>>>> breaking all code that uses the shortcut syntax.
>>>
>>> Two things:  #1 -- The developer making that change would know it
>>> immediately, and likely then pick another name,
>> 
>> No, the developer is likely to discard the stupid compiler and
>> use one that doesn't .. his perfectly good program.   Especially
>> when recompiling a 20 year old source base.
>
>How many of those 20 year old source code bases used the new ~~ syntax,
>Scott?

You, of course, know that "syntax" is completely unrelated to the
point about duplicate structure tags, which is the issue with any legacy
code base being compiled with your proposed language change.

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

#138866

On 12/21/2018 10:35 AM, Scott Lurndal wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> On 12/21/2018 9:56 AM, Scott Lurndal wrote:
>>> No, the developer is likely to discard the stupid compiler and
>>> use one that doesn't .. his perfectly good program.   Especially
>>> when recompiling a 20 year old source base.
>>
>> How many of those 20 year old source code bases used the new ~~ syntax,
>> Scott?
> 
> You, of course, know that "syntax" is completely unrelated to the
> point about duplicate structure tags, which is the issue with any legacy
> code base being compiled with your proposed language change.

The same happens if you try and refactor something today.  There's al-
ways the possibility of breaking existing code.  The art of being good
at it comes from being able to integrate refactoring changes without
breaking existing code.  That seamless integration requires a mastery
of understanding and coding ability.  It's not often seen to be honest.

Regardless, it's not a concern for me.  I do not expect any existing
C/C++ stalwart to ever seek to use my software.  I think it will be
for a new type of developer, a new way of thinking, a new philosophy
of computer use.  I expect a new ecosystem to rise that didn't exist
previously, and only there will CAlive be successful.

-- 
Rick C. Hodgin

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

#138868

On 21/12/2018 15:41, Rick C. Hodgin wrote:
> I expect a new ecosystem to rise that didn't exist
> previously, and only there will CAlive be successful.

Quite delusional.

/Flibble

-- 
“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who 
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – 
Ricky Gervais

"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."

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

#138873

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>On 12/21/2018 10:35 AM, Scott Lurndal wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>> On 12/21/2018 9:56 AM, Scott Lurndal wrote:
>>>> No, the developer is likely to discard the stupid compiler and
>>>> use one that doesn't .. his perfectly good program.   Especially
>>>> when recompiling a 20 year old source base.
>>>
>>> How many of those 20 year old source code bases used the new ~~ syntax,
>>> Scott?
>> 
>> You, of course, know that "syntax" is completely unrelated to the
>> point about duplicate structure tags, which is the issue with any legacy
>> code base being compiled with your proposed language change.
>
>The same happens if you try and refactor something today.

refactoring != recompiling

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

#138880

On 12/21/2018 12:04 PM, Scott Lurndal wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> On 12/21/2018 10:35 AM, Scott Lurndal wrote:
>>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>>> On 12/21/2018 9:56 AM, Scott Lurndal wrote:
>>>>> No, the developer is likely to discard the stupid compiler and
>>>>> use one that doesn't .. his perfectly good program.   Especially
>>>>> when recompiling a 20 year old source base.
>>>>
>>>> How many of those 20 year old source code bases used the new ~~ syntax,
>>>> Scott?
>>>
>>> You, of course, know that "syntax" is completely unrelated to the
>>> point about duplicate structure tags, which is the issue with any legacy
>>> code base being compiled with your proposed language change.
>>
>> The same happens if you try and refactor something today.
> 
> refactoring != recompiling

You're right.  You could refactor and then leave the source code in
that state without recompiling.  What a time saver that would be.

-- 
Rick C. Hodgin

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

#138858

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>On 12/21/2018 6:36 AM, Juha Nieminen wrote:

>Our toolsets must grow up and be more than piecemeal.  They need to
>be integrated so that you're in a system, not just a functional com-
>ponent of a system.

This is so wrong that it's hard to decide where to begin.

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

#138862

On 12/21/2018 9:57 AM, Scott Lurndal wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> On 12/21/2018 6:36 AM, Juha Nieminen wrote:
> 
>> Our toolsets must grow up and be more than piecemeal.  They need to
>> be integrated so that you're in a system, not just a functional com-
>> ponent of a system.
> 
> This is so wrong that it's hard to decide where to begin.

Man's cities used to be isolated requiring each person to make a long
journey to get from there to here to have communication with other
places.  Then the telegraph and steam locomotive were invented.  And
then the telephone and automobile were invented.  Now we have the jet
airplanes and the Internet and our communications and mobility is un-
precedented in this world.  And it is only growing more and more each
day.  Future programs show full-size rooms where doctors on one conti-
nent communicate with doctors on another, showing a type of hologram
of the patient from the digital scan data.  Collaboration across the
world!

In the beginning we had isolated computer systems.  People had to
carry tapes or disks from one place to another to install new soft-
ware.  Then they began to locally network and copy things.  Then we
began to have wide networking.  Today we are all interconnected and
our individual CPUs are multi-core machines with more memory and hard
disk capacity than many highest-end servers of the 1990s.

Our software needs to grow into integrated systems, all working toge-
ther, but presented to people in a type of flexible, dynamic, yet easy
access UI, with those functions related to their operation being inside
and aware of the other functions inside as well, integrating into a
smooth experience for the user, one that's reliable, consistent.  The
base design of object-orientation allows for this, as each thing added
is extensible, and adds to the other things already in existence.

It's also time for our compiler systems begin communicating with the
things they're a part of, to be aware of the CPUs they target, and to
be powerful tools working for developers in developer mode, and for
optimized code when not in developer mode, and to provide interfaces
making it easier for developers to do their work, to essentially be
moving forward just like all things do and must do as time marches on.
It's a natural evolution for all things.  And those big old dinosaurs
that used to roam the Earth ... where are they now, Scott?  Modern
science teaches that they couldn't adapt, so they became extinct.  And
those tremendous buggy whip manufacturers when the automobile came
along ... where are they now?

Are you able to adapt, Scott?  Or is casting stones at new ideas more
your forte?

-- 
Rick C. Hodgin

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

#138865

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>On 12/21/2018 9:57 AM, Scott Lurndal wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>> On 12/21/2018 6:36 AM, Juha Nieminen wrote:
>> 
>>> Our toolsets must grow up and be more than piecemeal.  They need to
>>> be integrated so that you're in a system, not just a functional com-
>>> ponent of a system.
>> 
>> This is so wrong that it's hard to decide where to begin.
>

Paragraphs of irrelevent attempts to draw parallels to reality elided.

>Are you able to adapt, Scott?  Or is casting stones at new ideas more
>your forte?

I adapt every day; that's what life is, adapting to change.

Not all change is good, including your proposed
structure tag access change to the C language.

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

Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

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

csiph-web