Shorthand ~> pointers

[Rick C. Hodgin]

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.

--
Rick C. Hodgin

[bitrex]

Pretty hard for me to distinguish between the two at a glance on my
laptop monitor at a normal working distance. I'm headed towards middle
age, not 20/20 in both eyes anymore and I'm squinting over here...

[Rick C. Hodgin]

On 12/20/18 3:29 AM, bitrex wrote:
> On 12/19/2018 09:31 PM, 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:
>>

>>      // 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.
>
> Pretty hard for me to distinguish between the two at a glance on my
> laptop monitor at a normal working distance. I'm headed towards middle
> age, not 20/20 in both eyes anymore and I'm squinting over here...

Mine too. Maybe e~~>gcInt would be better, that way it would be
more visual that it's a shorthand.

--
Rick C. Hodgin

[Fred.Zwarts]

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.

[Rick C. Hodgin]

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

[Bart]

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

[Rick C. Hodgin]

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

[Bart]

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

[Rick C. Hodgin]

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

[Bart]

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

[Scott]

On Wed, 19 Dec 2018 21:31:34 -0500, "Rick C. Hodgin"
<rick.c...@gmail.com> wrote:

>I've had the idea to introduce the ~> symbol for shorthand pointers.

It's a bad idea. I had to go back and remind myself why, and it's for
much the same reason that Pascal's "with" keyword turned out to be a
bad idea. It brings ambiguity, hides scoping issues, makes code easier
to write at the expense of being harder to read.

[Alf P. Steinbach]

Well, I liked Pascal's `with`, but not the one in Visual Basic 6.x.

One can have roughly the Pascal functionality in C++ by defining

#define WITH( ... ) if( auto&& _ = __VA_ARGS__; true or !!&_ )
#define ITEMS( c ) std::begin( *&c ), std::end( c )

Then one can write e.g.

using To = ostream_iterator<char>;
WITH( to_string( 3.14 ) ) { copy( ITEMS( _ ), To( cout, " " ) ); }
cout << endl;

There `true or` effectively disables a sillywarning from g++, warning
that it understands that `!!&_` will always be true. There is however a
corresponding sillywarning from Visual C++, number 4127, that it's best
to just disable. I don't think there's any good code workaround.


Cheers!,

- Alf

[Scott]

On Fri, 21 Dec 2018 03:23:34 +0100, "Alf P. Steinbach"
<alf.p.stein...@gmail.com> wrote:

>On 21.12.2018 02:14, Scott wrote:
>> It's a bad idea. I had to go back and remind myself why, and it's for
>> much the same reason that Pascal's "with" keyword turned out to be a
>> bad idea. It brings ambiguity, hides scoping issues, makes code easier
>> to write at the expense of being harder to read.
>
>Well, I liked Pascal's `with`, but not the one in Visual Basic 6.x.
>
>One can have roughly the Pascal functionality in C++ by defining
>
> #define WITH( ... ) if( auto&& _ = __VA_ARGS__; true or !!&_ )
> #define ITEMS( c ) std::begin( *&c ), std::end( c )

Ah, my fault, I meant to trim headers back to CLC only. C++ as it
exists today seems only loosely related to the C++ I learned 20 years
ago, and it's not really on my short list.

>Then one can write e.g.
>
> using To = ostream_iterator<char>;
> WITH( to_string( 3.14 ) ) { copy( ITEMS( _ ), To( cout, " " ) ); }
> cout << endl;

Hey, do you remember that time when I said something is a bad idea if
it makes code easier to write at the expense of being harder to read?

[David Brown]

What if it makes code harder to read /and/ harder to write? Surely that
restores the balance?

(To be fair, Alf said you /could/ do this - not that you /should/ do it.)

[Juha Nieminen]

In comp.lang.c++ Bart <b...@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.

[Rick C. Hodgin]

I'm not sure what that syntax is or does. The purpose of the ~> (now
renamed ~~) is to indicate there are intermediate members that are not
typed out, but are there. The editor would be able to expand them for
you when needed, either visibly on the line, or logically as a tooltip
popup or some other information displayed nearby.

It's not for all types of code. But there are types of code it would
be desirable.

--
Rick C. Hodgin

[Rick C. Hodgin]

On 12/21/2018 6:36 AM, Juha Nieminen wrote:
> In comp.lang.c++ Bart <b...@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

[Scott Lurndal]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:
>On 12/21/2018 6:36 AM, Juha Nieminen wrote:
>> In comp.lang.c++ Bart <b...@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.

[Scott Lurndal]

"Rick C. Hodgin" <rick.c...@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.

[Rick C. Hodgin]

On 12/21/2018 9:56 AM, Scott Lurndal wrote:
> "Rick C. Hodgin" <rick.c...@gmail.com> writes:
>> On 12/21/2018 6:36 AM, Juha Nieminen wrote:
>>> In comp.lang.c++ Bart <b...@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

[Rick C. Hodgin]

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

[Scott Lurndal]

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.

[Scott Lurndal]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:
>On 12/21/2018 9:57 AM, Scott Lurndal wrote:
>> "Rick C. Hodgin" <rick.c...@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.

[Rick C. Hodgin]

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

[Rick C. Hodgin]

Don't use it then. It's an extension to the language, not a requirement.
And it's not even a requirement that you use my language when/if it's
released.

You're fighting an idea presently, Scott. While I respect your right
to have your position, I do think your position is wrong. I think your
judgment is clouded by personal issues.

--
Rick C. Hodgin

[Mr Flibble]

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

[Mr Flibble]

On 21/12/2018 15:42, Rick C. Hodgin wrote:
> You're fighting an idea presently, Scott.  While I respect your right
> to have your position, I do think your position is wrong.  I think your
> judgment is clouded by personal issues.

And Satan invented fossils, yes?

[David Brown]

On 21/12/18 16:42, Rick C. Hodgin wrote:
> On 12/21/2018 10:37 AM, Scott Lurndal wrote:
>> "Rick C. Hodgin" <rick.c...@gmail.com> writes:
>>> 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.
>
> Don't use it then. It's an extension to the language, not a requirement.
> And it's not even a requirement that you use my language when/if it's
> released.

I don't think Scott is saying he would not want to use the feature - I
think that is so obvious it does not need to be put down in words.

He is advising /you/ not to include the feature in your own language,
never mind attempt to add it as an extension to C and/or C++.

>
> You're fighting an idea presently, Scott. While I respect your right
> to have your position, I do think your position is wrong. I think your
> judgment is clouded by personal issues.
>

No, Scott (and others) have given good technical reasons to dislike your
suggestion. It is /you/ whose judgement seems to be entirely a matter
of personal issues.

We see the pattern again and again:

1. Rick suggests a new idea.

2. People say why they think it is unnecessary, how the problem could
better be solved with existing language constructs, and how the feature
would conflict with existing software or tools.

3. Rick declares it to be the best idea since sliced bread, and that it
will revolutionise programming.

4. People say they advise against it, and give more helpful technical
reasoning and suggestions.

5. Rick bemoans the imaginary hatred and negativity, while taking it as
proof that the idea is brilliant.

6. People try to convince Rick that their objections are technical, not
personal.

7. Rick insults people, declaring them haters, blind, unable to adapt,
possessed by the devil, etc. This is backed by references to science
fiction programs and/or rabid TV evangelists.

8. People start complaining about the off-topic posting and wondering
why anybody ever responds to Rick. Many of those who responded wonder
that too - but can't resist the temptation to do so again in the future.

9. Rick leaves the group in a huff, declaring that he will change the
world alone. We all know he'll be back.


I think these threads can start off quite interesting and lead to some
entertaining or informative discussions for a while. But we are now in
stage 7 - maybe it is possible to skip the later stages.

[Scott Lurndal]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:
>On 12/21/2018 10:35 AM, Scott Lurndal wrote:
>> "Rick C. Hodgin" <rick.c...@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

[Scott Lurndal]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:
>On 12/21/2018 10:37 AM, Scott Lurndal wrote:
>> "Rick C. Hodgin" <rick.c...@gmail.com> writes:
>>> 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.
>
>Don't use it then. It's an extension to the language, not a requirement.
>And it's not even a requirement that you use my language when/if it's
>released.

But it causes any code I write with the compiler to not
be future proof, so I can't use the language for that reason alone.

[Rick C. Hodgin]

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

[Rick C. Hodgin]

Don't use it then. You won't hurt my feelings.

--
Rick C. Hodgin

[Daniel]

On Friday, December 21, 2018 at 7:56:05 AM UTC-5, Rick C. Hodgin wrote:
>
> there are intermediate members that are not typed out, but are there.

Dark variables, yes.

Daniel

[Rick C. Hodgin]

#1 You don't have to use this feature. Type out everything like normal
and it will never be an issue for anyone.

#2 Not dark variables ... when intelligently used, a friend helping you
the developer save unnecessary typing. The editor can resolve the full
variable path for you. It's not lost information, nor dark variables.
It's a condensing of the relevant information so you only bring forth
what is required for the task, and don't get bogged down in full minutiae.

#3 Merry Christmas. :-) No snow here in Indiana, but plenty of rain.

--
Rick C. Hodgin

[Vir Campestris]

On 21/12/2018 09:45, Scott wrote:
> Hey, do you remember that time when I said something is a bad idea if
> it makes code easier to write at the expense of being harder to read?

No, I don't. But I agree with you.

Yet there are respected C++ "Gurus" in favour of the rule "almost always
auto".

Andy

[Scott Lurndal]

How does one become a "respected C++ Guru", anyway? The most YouTube views?
The highest StackOverflow score?

C++ has delighted in adding unnecessary complexity in their quest to
reduce the required skill level of the C++ code writer.

[somewhat, but not necessarily fully, tongue-in-cheek]

[Chris M. Thomasson]

Do you think CAlive might be ready in alpha, or beta by Christmas 2020,
or even 2019?

[David Brown]

There are lots of situations where "auto" makes code easier to read, as
well as easier to write - and then it's a definite plus. (But I would
not say that applies to "almost all" situations.)

[Richard Damon]

I would say that there as SOME situations where it make sense to use
auto, when the type is complicated/ugly to write or the exact type is an
implementation detail of something being used. For example, the type of
an iterator being pulled from a container.

For me, most of the time being explicit with the type makes the code
more readable. The issue is that with auto, the compiler may know
exactly what type is being used, but the programmer reading the code
needs to figure it out and remember what it is, and that act of remember
adds to the cognitive load of analyzing the code, you can't just look
back up at the declaration to remember. Adding a comment giving the
expected type (maybe not precisely enough for the compiler to generate
the code) can help a lot here.

Being explicit with the type also catches errors quicker, rather than
getting an error when using the variable because its type isn't what was
expected, and having to back trace to figure out where the discrepancy
is, you tend to get the error in initializing the variable.

The problem gets especially bad if you are a couple of layers deep in
'auto' types.

[Rick C. Hodgin]

On 12/22/2018 2:49 AM, Chris M. Thomasson wrote:
> Do you think CAlive might be ready in alpha, or beta by Christmas 2020, or
> even 2019?

My goal has always been Christmas 2019.

--
Rick C. Hodgin

[Bart]

When I make this kind of objection to something which adds one or more
abstraction layers to some information I want to know, I usually get
told that with the right tools, a single mouse-click over a name will
tell me everything I need to know.

--
bart

[Juha Nieminen]

In comp.lang.c++ Rick C. Hodgin <rick.c...@gmail.com> wrote:
> On 12/21/2018 6:36 AM, Juha Nieminen wrote:
>> In comp.lang.c++ Bart <b...@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

You might not have control over the names in those structs you are
adding as members of this struct. Maybe they are structs from some
libraries that you don't have control over (or otherwise shouldn't
be changing).

[Rick C. Hodgin]

True. In those cases, don't use shorthand pointers. An option could
be added to the compiler to disallow them.

--
Rick C. Hodgin

[Anton Shepelev]

Bart:

> When I make this kind of objection to something which adds
> one or more abstraction layers to some information I want
> to know, I usually get told that with the right tools, a
> single mouse-click over a name will tell me everything I
> need to know.

I make it a requirement that code shall be readable and
maintainable with only a text editor. If any decision in
coding style is dependent on some tool, it a bad decision.
Everybody is free to use whatsoever tools they like, but
they must be optional.

--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]

[Rick C. Hodgin]

On 12/22/2018 1:48 PM, Anton Shepelev wrote:
> Bart:
>
>> When I make this kind of objection to something which adds
>> one or more abstraction layers to some information I want
>> to know, I usually get told that with the right tools, a
>> single mouse-click over a name will tell me everything I
>> need to know.
>
> I make it a requirement that code shall be readable and
> maintainable with only a text editor. If any decision in
> coding style is dependent on some tool, it a bad decision.
> Everybody is free to use whatsoever tools they like, but
> they must be optional.

I have had this philosophy for many years. However, I was
using an editor that had certain macro abilities, built-in
abilities for searching, some refactoring, etc. As I moved
to other tools, I found that the user experience was not the
same even though the base text editor abilities were there.

I've come to realize over time that there are abilities which
exist that should not be ignored simply because they are not
part of a minimal set of abilities in an editor. I think we
should reach higher.

Of course, anyone with a generic text editor would be able to
use shorthand pointers, or do any other kind of coding. It's
all in the developer's mind when they're "in the moment" or
"in the zone," but the tools make it easier. They should be
used.

My goals with CAlive are to recognize that these abilities to
help human developers not only exist, but should exist. I
seek to move them from the background into the foreground, to
make them first class citizens, not exactly a requirement, but
a friend helping you.

CAlive is more than just a compiler in that way. It's a whole
philosophy of how compilers should be built, how they should
integrate with their user, with their environment, with the
product goals (CPUs, type of app, user debugger needs, etc.).

I think it's a good goal I'm pursuing it, but it's a lot of
work for one man, and I seem to consistently hit the "why on
Earth would you consider doing something so stupid, Rick?"
mentality in people who ... I don't know ... are lacking in
some social graces maybe?

I think if people stepped out of the box they're in for a
moment and looked around at what else is possible ... they
might just appreciate a new direction.

We shouldn't be stuck in legacy design models when we have
computers today that are 1000x or more powerful than the
machines those legacy app models were designed for. We need
to move to the next level in the same way we moved from the
horse to the steam locomotive to the automobile to the jet
airliner, and from slow printing press, to telgraph, to tele-
phone, to Internet, to mobile handheld always-connected dev-
ices.

Our coding models must move forward as well. CAlive (and
probably more importantly RDC--the framework CAlive is built
on) are moving in those directions. As one person working
on this enormous project it's difficult. I would like to see
other entities moving in this way as well so that I wouldn't
have to. I'd also like to see interest in moving in this way
so I don't have to go it alone, and we can go it together.

--
Rick C. Hodgin

[Mr Flibble]

It isn't just about editors. If I post a code snippet that uses your
fucktarded ~> idea people won't have the slightest clue what it means.

It is a bad idea, period.

[Rick C. Hodgin]

On Saturday, December 22, 2018 at 2:08:44 PM UTC-5, Mr Flibble wrote:
> It isn't just about editors. If I post a code snippet that uses your

> .. ~> idea people won't have the slightest clue what it means.

>
> It is a bad idea, period.

It's ~~ now for CAlive's shorthand pointer usage. And if you were
to ever post a CAlive code snippet, I'd look nearby for the vulgarity
or slander because I believe that's the only reason you'd ever do so
(to make fun of it, or demean it, or say something about it or me).

FWIW Leigh ... I think your neoGFX is looking very interesting. You
are an excellent developer and many people will undoubtedly gain sig- nificantly from using your product. I wish you the greatest success
with it.

--
Rick C. Hodgin

[Mr Flibble]

In the context of this newsgroup the main difference between my project
and yours is that yours is off topic as it has nothing to do with C++.

You appear to be incapable of making on topic posts instead making posts
of the form "hey I've got this idea about extending C++ language but what
it actually is is an excuse to advertise my non-C++ language" or an
egregious religious post.

[Rick C. Hodgin]

On Saturday, December 22, 2018 at 2:43:56 PM UTC-5, Mr Flibble wrote:
> In the context of this newsgroup the main difference between my project
> and yours is that yours is off topic as it has nothing to do with C++.

Yours is a product, Leigh. It's not augmenting C++. You're not
asking people questions about how to implement something you don't
understand. You're releasing a product you hope will make you mo'
money.

When you do reply to people in clc++, you use profanity, are vulgar,
call them names, demean and diminish their lives in multiple ways.
You make fun of them if their question isn't "up to snuff," or if
they are having some degree of misunderstanding.

You're a very hurtful abrasive man that I can only conclude is
hurting terribly on the inside. The pain you endure must be un-
bearable for you to seek such outlets to try to diminish it. :-(

> You appear to be incapable of making on topic posts instead making posts
> of the form "hey I've got this idea about extending C++ language but what
> it actually is is an excuse to advertise my non-C++ language"

I offer ideas up to the C/C++ communities. I'm trying to improve
C and C++. My ideas stem from my daily use of C and C++, and then
factor in to ideas on how the language could be extended or improved.
I offer the ideas for consideration or rejection by the communities.
I don't seek to hoard my ideas, but to share them with others.

It's an act of giving, and one that you pooh-pooh because of your
own inner issues.

You don't seem to realize that people can disagree without being
disagreeable. You only know the state of being disagreeable. I've
never one seen you be loving, caring, compassionate, giving. I've
only seen you be almost neutral, or doing harm to people.

> or an egregious religious post.

You're an amazing hypocrite, Leigh. You post 12 lines of religious
commentary on every post you write. You even upped the quantity from
a prior lesser amount of content when it was suggested that four lines
of signature is the Usenet standard. You rebelled against that guid-
ance just to be bad and to be worse, all out of meanness, hatred, spite,
contempt, and a character that will not tolerate any guidance in life
save your own.

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

You are lost and blind, Leigh. Your destruction will be amazing...
unless you repent.

--
Rick C. Hodgin

[Richard Damon]

My preference is that basic computer languages, like C and in may
respect like C++ should be accessible with a basic text editor, and not
REQUIRE a fancy IDE. There are some features a smart editor/IDE can
bring, but they should not be essentially needed to understand the code.

Other, higher level languages, might be more dependent on the
development environment.

The Editor/IDE can provide a lot of services that help the programmer,
things like syntax highlighting, block collapsing, popping up
signatures/documentation for elements, code completion, 'preety
printing', and lots of related functions are great usability features.
One reason to want the base language to be accessible with a simple
editor is that it allows the programmer to have a choice of 3rd party
editors to promote the development of new editor features.

The ~> operator, in my mind would be a great idea in the IDE, where
after completing the clause, the IDE replaces it with the path to the
member, and maybe even add comments to allow it to collapse the display.

[Rick C. Hodgin]

On 12/22/2018 5:10 PM, Richard Damon wrote:
> My preference is that basic computer languages, like C and in may
> respect like C++ should be accessible with a basic text editor, and not
> REQUIRE a fancy IDE. There are some features a smart editor/IDE can
> bring, but they should not be essentially needed to understand the code.

CAlive will meet that criteria. You could write software for it in
edlin if you wanted to do so.

> Other, higher level languages, might be more dependent on the
> development environment.

CAlive has an integration which allows for its edit-and-continue
nature (called "LiveCode"), as well as its Inquiry system, which
is a type of debugger tool at runtime where, when something unex
pected happens it generates an Inquiry, which traps to the debug-
ger and allows the developer to correct the problem and continue
processing. The LiveCode ABI exists only when compiled to be that
way. It's traditional runtime-like otherwise, and traps to an
inquiry() function, which then can capture runtime information and
politely exit.

> The Editor/IDE can provide a lot of services that help the programmer,
> things like syntax highlighting, block collapsing, popping up
> signatures/documentation for elements, code completion, 'preety
> printing', and lots of related functions are great usability features.
> One reason to want the base language to be accessible with a simple
> editor is that it allows the programmer to have a choice of 3rd party
> editors to promote the development of new editor features.

With some of the features CAlive provides, the integrated editor
will be of great benefit. In addition, our computers are far more
capable today than they used to be. To limit your code authoring
session to a lesser editor is, in my opinion, preventing technology
from helping you.

> The ~> operator, in my mind would be a great idea in the IDE, where
> after completing the clause, the IDE replaces it with the path to the
> member, and maybe even add comments to allow it to collapse the display.

In my view, it should be that way in source code, with the editor's
ability to expand it if you want with a keystroke or two-stroke key
combination. ^K+~ for example, to toggle the full display of short-
hand pointers on/off.

--
Rick C. Hodgin

[Chris M. Thomasson]

It seems like you say, don't use shorthand pointers, quite a lot.

[Chris M. Thomasson]

On 12/22/2018 10:05 AM, Rick C. Hodgin wrote:
> On 12/22/2018 2:49 AM, Chris M. Thomasson wrote:
>> Do you think CAlive might be ready in alpha, or beta by Christmas
>> 2020, or even 2019?
>
> My goal has always been Christmas 2019.
>

Great! I will install it for sure. If you can, please think about adding
support for C11 threads, atomics and membars! Then, you can compete with
Pelles C.

[Rick C. Hodgin]

People don't seem to realize the need for self-constraints in software
design. If you have a worry about breaking future code, and it's going
to be such a large issue, it seems to go without saying that you would
not want to use that feature. But some people don't seem to see it.

Even in conventional software design, with long-standing legacy functions,
there are things we're taught not to use, such as goto. Perfectly valid.
Perfectly legal. But it causes trouble, so you don't use it.

In any event ... my statement goes along these lines: All of these
features people seem to hate are add-ons. No one is required to use
any of them. They're there if you want them. If not, code like you
always have. People don't seem to realize that either.

--
Rick C. Hodgin

[Chris M. Thomasson]

I understand that CAlive will be a standard C compiler at its most basic
level. However, it will have a lot of other exotic spices that a user
can decide to use as well. Also, it should have an interesting
specialized GUI. We can write code in a text editor, or choose to use
your GUI, or any other GUI. However, your GUI will have the special
spice that is CAlive... How off base am I Rick? Looking forward to new
years eve 2019. :^)

[Rick C. Hodgin]

We have an expression at my house: "Spot on nailed it." :-)

--
Rick C. Hodgin

[Juha Nieminen]

How would you know in advance that, perhaps, months or years from now
there might be such a naming conflict?

Besides, it's silly that variable names in one struct or class
(which in C++ may even be private) may cause a conflict with names
in a completely unrelated struct or class.

[Reinhardt Behm]

So there is a simple general solution: Don't use it at all.

--
Reinhardt

[Mr Flibble]

On 22/12/2018 20:49, Rick C. Hodgin wrote:
> On Saturday, December 22, 2018 at 2:43:56 PM UTC-5, Mr Flibble wrote:

>> or an egregious religious post.
>
> You're an amazing hypocrite, Leigh. You post 12 lines of religious
> commentary on every post you write.

Atheism isn't a religion nor is it about religion.

/Flibble

--

[Mr Flibble]

Richard just offered a sensible way forward for your feature: make it part
of the IDE rather than part of the language but as usual you reject any
sane help.

[Rick C. Hodgin]

I think it's equally silly to require that a user type out the fully
qualified path to a uniquely named variable in a system where it's
not likely that there will be a name conflict.

It's just a different philosophy.

--
Rick C. Hodgin

[Rick C. Hodgin]

On 12/23/2018 5:17 AM, Mr Flibble wrote:
> On 22/12/2018 20:49, Rick C. Hodgin wrote:
>> On Saturday, December 22, 2018 at 2:43:56 PM UTC-5, Mr Flibble wrote:
>>> or an egregious religious post.
>> You're an amazing hypocrite, Leigh.  You post 12 lines of religious
>> commentary on every post you write.
>
> Atheism isn't a religion nor is it about religion.

It has every earmark of a religion, Leigh:


https://answersingenesis.org/media/audio/answers-with-ken-ham/volume-131/atheism-its-a-religion/

--
Rick C. Hodgin

[Rick C. Hodgin]

On 12/23/2018 5:19 AM, Mr Flibble wrote:
> On 22/12/2018 22:42, Rick C. Hodgin wrote:
>> On 12/22/2018 5:10 PM, Richard Damon wrote:
>>> The ~> operator, in my mind would be a great idea in the IDE, where
>>> after completing the clause, the IDE replaces it with the path to the
>>> member, and maybe even add comments to allow it to collapse the display.
>>
>> In my view, it should be that way in source code, with the editor's
>> ability to expand it if you want with a keystroke or two-stroke key
>> combination.  ^K+~ for example, to toggle the full display of short-
>> hand pointers on/off.
>
> Richard just offered a sensible way forward for your feature: make it part of
> the IDE rather than part of the language but as usual you reject any sane help.

Richard's view is a good one. His position is a particular philosophy
regarding source code. I have a different philosophy. My solution ful-
ly incorporates his solution, and goes the step further to actually change
the source code rather than just change the display.

--
Rick C. Hodgin

[Bart]

Suppose you type a~~c but the path it uses isn't the one you expected?

In my own code, very long dotted sequences are not that common, the
longest are probably 4 or 5 names. And those tend to have multiple paths
and/or involve recursive structs.

So the conditions to be able to use ~~ effectively are going to be rare.

There is one common use-case where such a shorthand would be
unambiguous, and could save some typing, but there are only three names,
so it would only save the middle name [a->objptr->length becomes a~~length].

But then that hides what is happening. When I do a lot of work with such
terms, then I might store a->objptr into an intermediate and work with
that (p->length). That could be more efficient.

Using a~~length, I lose sight of the fact that there are these extra
indirections, and also a~~length and a->ptr appear to be of the same
rank, as do a~~length and b->length, although a and b must be very
different types.

So I still think this is more usefully employed in an external tool.

--
bart

[Rick C. Hodgin]

On 12/23/2018 10:28 AM, Bart wrote:
> Suppose you type a~~c but the path it uses isn't the one you expected?

There should be only one c. If there is more than one it would be a
syntax error.

> In my own code, very long dotted sequences are not that common, the longest
> are probably 4 or 5 names. And those tend to have multiple paths and/or
> involve recursive structs.

Mine too. I typically use 3 or 4 max.

> So the conditions to be able to use ~~ effectively are going to be rare.

On oft-used structures in my apps, for things like SWindow or SObject,
I often refer to them as SWindow* w, as well as SObject* o for a short-
hand common reference. By dropping that "anchor" of the short parent
name, and then referencing a unique name, it makes the code more clear
for instance names:

w~~left;
w~~top;

Rather than something like w->settings->rc.left, etc. It's another type
of shorthand for that reference, making it more clear in source code
what's being used, without the visual clutter of the multiple levels.

> There is one common use-case where such a shorthand would be unambiguous, and
> could save some typing, but there are only three names, so it would only save
> the middle name [a->objptr->length becomes a~~length].

That's its intent right there. And I intend to use it in my own code
only on structures / classes that are relatively stable, such as those
things which interface with the OS or my own API that has grown over
time and stabilized.

> But then that hides what is happening. When I do a lot of work with such
> terms, then I might store a->objptr into an intermediate and work with that
> (p->length). That could be more efficient.

I do this often in source code today. I did it recently for a lot of
bit structures I needed to access. It's actually where this idea came
up for the shorthand reference, as I was creating those intermediate /
unnecessary temporary references just to make the typing I had to do
less intense, the idea came to me.

> Using a~~length, I lose sight of the fact that there are these extra
> indirections, and also a~~length and a->ptr appear to be of the same rank, as
> do a~~length and b->length, although a and b must be very different types.

Correct. CAlive contains meta data on each source code line which is
used to convey the full meaning of every lex'd symbol.

> So I still think this is more usefully employed in an external tool.

I can see that argument. For CAlive, it will be a feature. It will
also extend into my support of C/C++ as it is added. But, for other
languages ... authors get to make choices. I respect yours.

--
Rick C. Hodgin

[Mr Flibble]

On 23/12/2018 17:15, Rick C. Hodgin wrote:
> Correct.  CAlive contains meta data on each source code line which is
> used to convey the full meaning of every lex'd symbol.

I suggest you read a book on compiler theory because you are DOING IT
WRONG (tm).

[Rick C. Hodgin]

On 12/23/2018 12:24 PM, Mr Flibble wrote:
> On 23/12/2018 17:15, Rick C. Hodgin wrote:
>> Correct.  CAlive contains meta data on each source code line which is
>> used to convey the full meaning of every lex'd symbol.
>
> I suggest you read a book on compiler theory because you are DOING IT WRONG
> (tm).

You do not have enough information about me or my design to conclude as
you have done here.

--
Rick C. Hodgin

[Mr Flibble]

My assertion is based on what you said that I quoted. You are DOING IT
WRONG (tm) so I suggest you go read a book on compiler theory.

[Rick C. Hodgin]

On 12/23/2018 12:39 PM, Mr Flibble wrote:
> My assertion is based on what you said that I quoted...

What did I say? And why did it indicate to you that I'm doing it wrong?

--
Rick C. Hodgin

[Mr Flibble]

On 23/12/2018 19:07, Rick C. Hodgin wrote:
> On 12/23/2018 12:39 PM, Mr Flibble wrote:
>> My assertion is based on what you said that I quoted...
>
> What did I say?  And why did it indicate to you that I'm doing it wrong?
>

lern2fuckingusenet

[Ian Collins]

On 24/12/2018 06:15, Rick C. Hodgin wrote:
> On 12/23/2018 10:28 AM, Bart wrote:
>> Suppose you type a~~c but the path it uses isn't the one you expected?
>
> There should be only one c. If there is more than one it would be a
> syntax error.
>
>> In my own code, very long dotted sequences are not that common, the longest
>> are probably 4 or 5 names. And those tend to have multiple paths and/or
>> involve recursive structs.
>
> Mine too. I typically use 3 or 4 max.
>
>> So the conditions to be able to use ~~ effectively are going to be rare.
>
> On oft-used structures in my apps, for things like SWindow or SObject,
> I often refer to them as SWindow* w, as well as SObject* o for a short-
> hand common reference. By dropping that "anchor" of the short parent
> name, and then referencing a unique name, it makes the code more clear
> for instance names:
>
> w~~left;
> w~~top;
>
> Rather than something like w->settings->rc.left, etc. It's another type
> of shorthand for that reference, making it more clear in source code
> what's being used, without the visual clutter of the multiple levels.

Just write

auto& box {w->settings->rc};

box.left = something;

which will always be unambiguous.

Your scheme falls down as soon a you have a struct with more than one
compound member of the same type.

--
Ian.

[Rick C. Hodgin]

On 12/23/2018 2:17 PM, Mr Flibble wrote:
> On 23/12/2018 19:07, Rick C. Hodgin wrote:
>> On 12/23/2018 12:39 PM, Mr Flibble wrote:
>>> My assertion is based on what you said that I quoted...
>> What did I say?  And why did it indicate to you that I'm doing it wrong?
>

> lern2..usenet

It was a mistake for me to reply to you. I've never once seen you
actually help someone. Once again you exhibit your sole desire to
be mean, do harm, and hurt people.

I am very sad for you, Leigh. I'm sorry your life is like this.
It doesn't have to be.

--
Rick C. Hodgin

[Rick C. Hodgin]

That general idea is what I do today. It requires me creating box,
which is what the ~~ no longer requires. It also removes one more
line of source code, yet at the expense of not having the lengthy
reference somewhere nearby. If the reference is not common, you'll
probably want it. But if it's under an umbrella like "settings" it
may not be needed as it's an obvious part of the design.

> Your scheme falls down as soon a you have a struct with more than one
> compound member of the same type.

You can include compound members:

w~~rc1.left
w~~rc2.left

The shorthand portion takes up the common portion, leaving only the
unique portion as the focus in code.

It's not for everything. It's a tool for where it has uses.

--
Rick C. Hodgin

[Mr Flibble]

On 23/12/2018 19:52, Rick C. Hodgin wrote:
> On 12/23/2018 2:17 PM, Mr Flibble wrote:
>> On 23/12/2018 19:07, Rick C. Hodgin wrote:
>>> On 12/23/2018 12:39 PM, Mr Flibble wrote:
>>>> My assertion is based on what you said that I quoted...
>>> What did I say?  And why did it indicate to you that I'm doing it wrong?
>>
>> lern2..usenet
>
> It was a mistake for me to reply to you.  I've never once seen you
> actually help someone.  Once again you exhibit your sole desire to
> be mean, do harm, and hurt people.

Oh why don't you just grow a pair you snowflake?

>
> I am very sad for you, Leigh.  I'm sorry your life is like this.
> It doesn't have to be.

Replying to Usenet posts be they fucktarded or not is like 0.1% of what I
do/am.

[Mr Flibble]

You are sad for me? Trying being sad for yourself. The last person I need
a psychological evaluation from is a Christian who believes homosexuals
should be put to death. (Leviticus 20:13)

[Rick C. Hodgin]

On 12/23/2018 4:36 PM, Mr Flibble wrote:
> On 23/12/2018 19:52, Rick C. Hodgin wrote:
>> I am very sad for you, Leigh.  I'm sorry your life is like this.
>> It doesn't have to be.
>
> You are sad for me? Trying being sad for yourself. The last person I need a
> psychological evaluation from is a Christian who believes homosexuals should
> be put to death. (Leviticus 20:13)

Old Testament, different covenant. You're speaking of the Jewish people
today, not Christians. They still follow the Torah. Christians follow
Jesus.

Christians are taught to reach out to all people in love, teaching them
the things God taught us. We leave the judging to God, but warn people
of the things God has told us in advance He will judge.

--
Rick C. Hodgin

[Mr Flibble]

"Jesus believed that the Old Testament was divinely inspired, the
veritable Word of God. He said, ‘The Scripture cannot be broken’ (John
10:35). He referred to Scripture as ‘the commandment of God’ (Matthew
15:3) and as the ‘Word of God’ (Mark 7:13). He also indicated that it was
indestructible: ‘Until Heaven and earth pass away, not the smallest letter
or stroke shall pass away from the law, until all is accomplished’
(Matthew 5:18)."

[Rick C. Hodgin]

On 12/24/2018 5:14 AM, Mr Flibble wrote:
> On 24/12/2018 00:24, Rick C. Hodgin wrote:
>> On 12/23/2018 4:36 PM, Mr Flibble wrote:
>>> On 23/12/2018 19:52, Rick C. Hodgin wrote:
>>>> I am very sad for you, Leigh.  I'm sorry your life is like this.
>>>> It doesn't have to be.
>>>
>>> You are sad for me? Trying being sad for yourself. The last person I need
>>> a psychological evaluation from is a Christian who believes homosexuals
>>> should be put to death. (Leviticus 20:13)
>>
>> Old Testament, different covenant.  You're speaking of the Jewish people
>> today, not Christians.  They still follow the Torah.  Christians follow
>> Jesus.
>>
>> Christians are taught to reach out to all people in love, teaching them
>> the things God taught us.  We leave the judging to God, but warn people
>> of the things God has told us in advance He will judge.
>
> "Jesus believed that the Old Testament was divinely inspired, the veritable
> Word of God. He said, ‘The Scripture cannot be broken’ (John 10:35). He
> referred to Scripture as ‘the commandment of God’ (Matthew 15:3) and as the
> ‘Word of God’ (Mark 7:13). He also indicated that it was indestructible:
> ‘Until Heaven and earth pass away, not the smallest letter or stroke shall
> pass away from the law, until all is accomplished’ (Matthew 5:18)."

You always write "TL;DR" so here's the short version up front:

Jesus put the law to death in His body at the cross. He received
the punishment of the Law, He BECAME SIN in our place so we could
be set free. This act of love takes away our sin and brings us
to the age of Grace where we're no longer under the Law, but are
set free from it by His sacrifice.

Jesus came to save, Leigh. Not to damn. Not to judge. By His
gift of salvation all who believe in Him will not be judged, but
have already passed from death to life, even while they remain
here in this world for a time.

-----
Better explanation:

Jesus put the Law to death in His body on the cross. He was the sinless
sacrifice who exchanged His spotless righteousness for our sinful state,
taking our sin upon Himself at the cross so that when He died with our
sin, our sin died with Him. He then leaves us sin-free, which allows us
to be restored unto God because we are perfect in God's sight (no sin).

For believers, He died the death we deserved in our sin. He took that
death away so that even though we die in the flesh, yet will we live in
the spirit, yet will we live eternally. And the one coming to faith in
this present age will feel that burden of sin lifted as their spirit
comes alive, and they are aware of new things they weren't previously
aware of.

When Jesus came to the Earth it was heralded. It's the Christmas story,
the true meaning of Christmas, why we still celebrate it 2,000 years
later.

Luke 2:

7 And she brought forth her firstborn son, and wrapped him in
swaddling clothes, and laid him in a manger; because there
was no room for them in the inn.
8 And there were in the same country shepherds abiding in the
field, keeping watch over their flock by night.
==> 9 And, lo, the angel of the Lord came upon them, and the glory
of the Lord shone round about them: and they were sore afraid.
==> 10 And the angel said unto them, Fear not: for, behold, I bring
you good tidings of great joy, which shall be to all people.
==> 11 For unto you is born this day in the city of David a Saviour,
which is Christ the Lord.
12 And this shall be a sign unto you; Ye shall find the babe
wrapped in swaddling clothes, lying in a manger.
==> 13 And suddenly there was with the angel a multitude of the
heavenly host praising God, and saying,
==> 14 Glory to God in the highest, and on earth peace, good will
toward men.
15 And it came to pass, as the angels were gone away from them
into heaven, the shepherds said one to another, Let us now go
even unto Bethlehem, and see this thing which is come to pass,
which the Lord hath made known unto us.
16 And they came with haste, and found Mary, and Joseph, and the
babe lying in a manger.
17 And when they had seen it, they made known abroad the saying
which was told them concerning this child.

It's why we all need to come to Him, ask Him for forgiveness, so we
too can be set free from sin by His sacrifice at the cross.

It's why there is a 100% division between the saved and the unsaved.
It's why the message of God cannot be understood by people who are
not born again of the spirit, but are still flesh-only. God is spirit,
and the things He teaches are spirit. It's why people don't come to
Christ of their own volition. They are drawn by God to Him, and when
they are drawn they then ask forgiveness.

It takes an act of God to draw someone to God (John 6:44). God sees
through to the heart, past our sin, past our disobedience. He knows
who will believe, who will seek the truth, and He draws those on the
inside.

It's why I've said all along: Just seek the truth. God will do the
rest.

-----
Jesus gave a new commandment, to love one another as He first loved
us. He gave a new commission after dying, being buried, raising from
the dead, and returning to the Earth to give guidance. He said, "All
power is given me in Heaven and in Earth. Go ye therefore, and teach
all nations, baptizing them in the name of the Father, and of the Son,
and of the Holy Ghost: Teaching them to obey all things whatsoever I
have commanded you: and, lo, I am with you always, even to the end
of the world. Amen."

His whole goal was for us to love and teach one another, so that their
hard hearts could be softened, and they could be saved.

It's not about people judging people. It's about God's judgment, and
us teaching people about God and God's judgment. It's about us loving
people even when they're harsh and mean and hateful and hurtful, be-
cause that's how people are expected to be BEFORE God's spirit draws
them to His Son, before their sin is forgiven, before they are born
again of their own spirit and are able to be guided by God rather than
solely guided by the flesh.

-----
It's a comprehensive bit of teaching, Leigh... but the gist of it is
this: Jesus takes our sin away, so that we can have eternal life.
He does this willingly, gratefully, gladly, and He makes His sacrifice
open to all people world-wide. No sinner is too much a sinner, none
are too bad, none are too lost... it just takes coming to Him in true
sincerity, humbled, broken, knowing they are a sinner, and then asking
forgiveness.

--
Rick C. Hodgin

[Bonita Montero]

Do you have only such superfluous, idiotic and obfuscating ideas?

[Kenny McCormack]

In article <pvqkpr$ufo$1...@dont-email.me>,

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

...

>You always write "TL;DR" so here's the short version up front:
>
> Jesus put the law to death in His body at the cross. He received

Gosh, you're full of shit.

It just boggles my mind how full of shit you are.

Not just in general, but whenever you try to appear learned, you fall on
your face.

--
"Remember when teachers, public employees, Planned Parenthood, NPR and PBS
crashed the stock market, wiped out half of our 401Ks, took trillions in
TARP money, spilled oil in the Gulf of Mexico, gave themselves billions in
bonuses, and paid no taxes? Yeah, me neither."

[Juha Nieminen]

In comp.lang.c++ Bart <b...@freeuk.com> wrote:

>> I think it's equally silly to require that a user type out the fully
>> qualified path to a uniquely named variable in a system where it's
>> not likely that there will be a name conflict.
>
> Suppose you type a~~c but the path it uses isn't the one you expected?

How about a compromise? In a similar manner how you can write
namespace aliases in C++, you could create "path aliases". Something
along the lines of:

using A~>b = A->x->y->b;

Maybe you could even "bring" the scope of a member object into the
scope of the enclosing object in a similar manner.

[Rick C. Hodgin]

On 12/24/2018 9:16 AM, Kenny McCormack wrote:
> ... whenever you try to appear learned, you fall on your face.

Jesus tasted death for us so we don't have to. He took our sin away so
we will not be accountable for it. He is. It was a transfer, as if sin
were our dirty jacket. He takes off our dirty jacket and places it on
Himself, and gives us His spotless jacket in exchange. He washes us free
of sin by His blood in that way. It's His gift to us, because He loves
us.

https://www.biblegateway.com/passage/?search=Romans+10%3A4-13&version=KJV

4 For Christ is the end of the law for righteousness to every one
that believeth.
==> 9 That if thou shalt confess with thy mouth the Lord Jesus, and
shalt believe in thine heart that God hath raised him from the
dead, thou shalt be saved.
10 For with the heart man believeth unto righteousness; and with
the mouth confession is made unto salvation.
11 For the scripture saith, Whosoever believeth on him shall not
be ashamed.
13 For whosoever shall call upon the name of the Lord shall be
saved.

We are all sinners. Our sin condemns us, sends us to Hell. Jesus came to
take away our sin and set us free so we will not be judged. We have His
perfect, spotless, blameless righteousness, and He takes our sin away and
pays the penalty of that sin in our place.

It is the greatest gift imaginable, for we are all sinners.

How He does this is visualized and demonstrated in this video:

Brief introduction:
https://www.youtube.com/watch?v=es7w8G6Q5oc&t=23m20s

Video begins:
https://www.youtube.com/watch?v=es7w8G6Q5oc&t=23m39s

--
Rick C. Hodgin

[Rick C. Hodgin]

On 12/24/2018 8:38 AM, Bonita Montero wrote:
> Do you have only such superfluous, idiotic and obfuscating ideas?

I suppose the answer to that question is a matter of subjective opinion.
Tell me, Bonita ... what is your position on the matter?

--
Rick C. Hodgin

[Mr Flibble]

On 24/12/2018 12:53, Rick C. Hodgin wrote:
> On 12/24/2018 5:14 AM, Mr Flibble wrote:
>> On 24/12/2018 00:24, Rick C. Hodgin wrote:
>>> On 12/23/2018 4:36 PM, Mr Flibble wrote:
>>>> On 23/12/2018 19:52, Rick C. Hodgin wrote:
>>>>> I am very sad for you, Leigh.  I'm sorry your life is like this.
>>>>> It doesn't have to be.
>>>>
>>>> You are sad for me? Trying being sad for yourself. The last person I
>>>> need a psychological evaluation from is a Christian who believes
>>>> homosexuals should be put to death. (Leviticus 20:13)
>>>
>>> Old Testament, different covenant.  You're speaking of the Jewish people
>>> today, not Christians.  They still follow the Torah.  Christians follow
>>> Jesus.
>>>
>>> Christians are taught to reach out to all people in love, teaching them
>>> the things God taught us.  We leave the judging to God, but warn people
>>> of the things God has told us in advance He will judge.
>>
>> "Jesus believed that the Old Testament was divinely inspired, the
>> veritable Word of God. He said, ‘The Scripture cannot be broken’ (John
>> 10:35). He referred to Scripture as ‘the commandment of God’ (Matthew
>> 15:3) and as the ‘Word of God’ (Mark 7:13). He also indicated that it
>> was indestructible: ‘Until Heaven and earth pass away, not the smallest
>> letter or stroke shall pass away from the law, until all is
>> accomplished’ (Matthew 5:18)."
>
> You always write "TL;DR" so here's the short version up front:

[snip TL;DR]

Jesus believed the Old Testament was the commandment of God (Matthew 15:3)
ergo Jesus believed that homosexuals should be put to death (Leviticus 20:13).

Do you agree with Jesus that homosexuals should be put to death or not?
If Jesus is wrong about putting homosexuals to death then what else is
Jesus wrong about? I thought gods were supposed to be infallible.

/Flibble

[Rick C. Hodgin]

On 12/24/2018 10:36 AM, Mr Flibble wrote:
> Jesus believed the Old Testament was the commandment of God (Matthew 15:3)
> ergo Jesus believed that homosexuals should be put to death (Leviticus 20:13).

Jesus didn't just believe that. He wrote it. He gave it to Moses, and
other writings in the Bible to the prophets and apostles.

But Jesus the man wasn't born into this world as one of us to judge us.
He has reserved judgment for Judgment Day. While He is here, and while
we are in this age of grace, Jesus will forgive sin and save people de-
spite their guilt.

> Do you agree with Jesus that homosexuals should be put to death or not? If
> Jesus is wrong about putting homosexuals to death then what else is Jesus
> wrong about?  I thought gods were supposed to be infallible.

You misunderstand because you will not seek an understanding. You pre-
vent yourself willfully from coming into knowledge of the truth.

When you stand before God in your defiance on Judgment Day, mouth to
Him the letters "TL;DR" and see what His weighted consideration of that
attitude and response is with regards to the things He first taught man.

--
Rick C. Hodgin

[Mr Flibble]

I will try asking the question again since you avoided answering it:

Do you agree with Jesus that homosexuals should be put to death or not? If
Jesus is wrong about putting homosexuals to death then what else is Jesus
wrong about? I thought gods were supposed to be infallible.

[Rick C. Hodgin]

On Monday, December 24, 2018 at 10:47:00 AM UTC-5, Mr Flibble wrote:
> Do you agree with Jesus that homosexuals should be put to death or not? If
> Jesus is wrong about putting homosexuals to death then what else is Jesus
> wrong about? I thought gods were supposed to be infallible.

There's so much information you'd need to understand before you
would receive my answer in proper context.

There are two covenants: The Old. The New.

The Old Covenant did not know anything of the spirit. The
guidance God gave man at that time was in dealing with sin
from a solely flesh-based perspective.

In the New Covenant, knowledge of the spirit is given with the
forgiveness of sin and regeneration of our spirit into eternal
life. As such, we have a new perspective that is different than
the old. It's why it's called the New Covenant. It's why Christ-
ians teach things that are in many ways different than the Law
of Moses.

-----
Leigh:

You ask questions you cannot receive the answer to as they are.
It's not a direct response I can be give you for your question be-
cause it's like asking, "Is pickle skin made from the same material
seen on toads?" You have to learn other things before you can even
understand what questions you should be asking, let alone under-
standing the replies you would receive to those questions.

If you seek the truth, GOD HIMSELF will teach you, Leigh. You'll
literally hear thoughts which guide you to the information.

--
Rick C. Hodgin

[Mr Flibble]

No, you still haven't answered the question. I will try one final time
before I add you to my spam filter:

Jesus believed the Old Testament was the commandment of God (Matthew 15:3)

ergo Jesus believed that homosexuals should be put to death (Leviticus
20:13).

Do you agree with Jesus that homosexuals should be put to death or not? If
Jesus is wrong about putting homosexuals to death then what else is Jesus
wrong about? I thought gods were supposed to be infallible.

[Rick C. Hodgin]

You don't know enough to ask the question you're attempting to
ask. I cannot give you the answer you seek because I know what
I'm referring to and what it means, and you do not and would
take it wrong.

Add me to your spam filter.

--
Rick C. Hodgin

[Mr Flibble]

LOL. You are indeed full of shit.

OK, back to reality: your god doesn't exist and Jesus the man never
existed either. Satan didn't invent fossils because Satan doesn't exist
either.

Speed of light mate. Evolution mate. Your religion is a joke mate.

[Rick C. Hodgin]

On 12/24/2018 12:35 PM, Mr Flibble wrote:
> ...OK, back to reality: your god doesn't exist and Jesus the man never existed

> either.  Satan didn't invent fossils because Satan doesn't exist either.
>
> Speed of light mate. Evolution mate. Your religion is a joke mate.

If you want to know the truth, seek the truth, Leigh. It is everywhere
at all points before you. You cannot see it because you are unwilling
to see it. YOU keep yourself from it.

I was an atheist, Leigh. But I was not 100% certain I was right. I
wanted to know for sure if I was right, so I sought the truth ... and
found it. You have your head buried in your own personal self-beliefs
and are unwilling to seek the truth ... hence you'll never find it
(because you're not looking for it).

--
Rick C. Hodgin

[Mr Flibble]

I agree with everything you have just said but with just one small change:
replace the word "truth" with "delusion".

[Rick C. Hodgin]

On 12/24/2018 1:01 PM, Mr Flibble wrote:
> I agree with everything you have just said but with just one small change:
> replace the word "truth" with "delusion".

I would've said the same thing ... before it happened to me. Setting
your sights on the truth ... that's how you find it.

I pray this happens to you someday, Leigh. Then you'll know what I'm
talking about. Then you'll offer up apologies to God over the guilt
you feel (at that time) for how you've treated me all these years. It
will wrench your soul and squeeze liquid out of your eyes. At least
that's been my experience over the way I treated people before I was
saved.

--
Rick C. Hodgin

[Mr Flibble]

And Satan invented fossils, yes?

[Rick C. Hodgin]

On 12/24/2018 1:55 PM, Mr Flibble wrote:
> And Satan invented fossils, yes?

No.

--
Rick C. Hodgin

[Chris M. Thomasson]

On 12/24/2018 7:43 AM, Rick C. Hodgin wrote:
> On 12/24/2018 10:36 AM, Mr Flibble wrote:
>> Jesus believed the Old Testament was the commandment of God (Matthew
>> 15:3) ergo Jesus believed that homosexuals should be put to death
>> (Leviticus 20:13).
>
> Jesus didn't just believe that.  He wrote it.  He gave it to Moses, and
> other writings in the Bible to the prophets and apostles.

Why are you implying that Jesus basically wrote something like:

All gay things should be utterly destroyed in the flesh

?

How about after the death of the flesh... Should gay people suffer forever?

[...]

[Melzzzzz]

Old testament clearly says all gays should be put to death and their
blood on their heads...

--
press any key to continue or any other to quit...

[Mr Flibble]

On 24/12/2018 22:12, Rick C. Hodgin wrote:
> On 12/24/2018 1:55 PM, Mr Flibble wrote:
>> And Satan invented fossils, yes?
>
> No.

"Christianity is a total plagiarisation of prior religions. It is by far
one of the worst explanations of how we got here - likelihood near 0%."

"Do you know why we celebrate Christmas, and what it was called before it
was dubbed Christmas? Why we bring trees inside and decorate them? Do you
know who Mithra is? Do you understand where Easter originally came from?"

[Rick C. Hodgin]

On 12/24/2018 5:16 PM, Chris M. Thomasson wrote:
> On 12/24/2018 7:43 AM, Rick C. Hodgin wrote:
>> On 12/24/2018 10:36 AM, Mr Flibble wrote:
>>> Jesus believed the Old Testament was the commandment of God (Matthew 15:3)
>>> ergo Jesus believed that homosexuals should be put to death (Leviticus
>>> 20:13).
>>
>> Jesus didn't just believe that.  He wrote it.  He gave it to Moses, and
>> other writings in the Bible to the prophets and apostles.
>
> Why are you implying that Jesus basically wrote something like:
> All gay things should be utterly destroyed in the flesh

In the Law of Moses, for those in the Jewish community, the Law of Moses
demanded that many types of sins resulted in the death/stoning of the in-
dividual committing those sins.

God was seeking to keep His nation pure, free from sin's influence. He
knew the spirit nature of the prompting of sin, and that where one person
acquiesces to sin, that evil spirit then has a voice in the community and
will begin to influence others, resulting in more and more sin. We see
that very effect in our societies today everywhere across the Earth where
Christ has been pushed out, and "tolerance" has been brought in. Compare
the "normal, accepted activities" of the world to Biblical teaching, and
you see the extent to which sin has influenced when God's guidance is not
allowed.

Evil spirits tempt us to sin. When we agree to listen to their voice,
they gain a legal foothold into our physical flesh, into our lives. They
want this interface / interaction with the tangible world, which they do
not possess in their spirit form. The Bible says that the angels who fell
with Satan are locked in eternal chains awaiting judgment, meaning their
physical bodies are locked up somewhere inaccessible to this world, so
they leave their bodies and interact only with this world spiritually.
But when they get a human host to acquiesce to their prompting, their guid-
ance against God into sin, they gain a legal license to enter in to that
body and are then having a direct physical influence into this world.

It's why our media, our movies, our music, the "powers that be" in various
high level places, are all pushing "tolerance" and pushing Christianity
(and in general God's morality taught to people) out. It's because they
want to make more and more room for their brethren to come out and corrupt
God's creation of man to such an extent that where they will be judged and
cast into Hell, so will so many of us that God will not want to see His
creation destroyed, so He will change His laws, saving His creation, and
in so doing saving those evil spirits as well.

That's my personal take on the situation, as it fits with what we see,
what the Bible teaches, the nature of the influence evil spirits have
had in people over time, how it's changed people's behavior, dominated
their flesh, tempted them into immorality, etc.

So, before Christ came and gave us His Holy Spirit, before He physically
took away our sin at the cross, before man could be regenerated into the
new spirit life, God was ONLY dealing with the people here on Earth in
the flesh. He gave them a seeming harsh/strict set of laws to obey. In
now understanding the spirit nature of the enemy we face and the battles
we face against those evil spirits, we see that God was focusing His
people's attentions on rigid requirements, to give them discipline, to
give them focus, to give them a way to combat the enemy's influence into
their societies, communities, families, nation, etc.

Israel often disobeyed, however, and we see the corruption of the Israel
people today because of it. Compromised to such an extent due to the
turning away of God's guidance through the Law of Moses, such that most
Jews only celebrate major holidays, do not refrain from many of those
things taught in the Law, do not stone people any longer, etc.

This has happened during this age of Grace, when God reached out to the
Gentiles (non-Jews) world-wide, offering them salvation, because of how
His people (Israel) had rejected Him, even crucifying Him on the cross.
A type of blinders has been put on their eyes and minds so they cannot
see Jesus as the Messiah, and during this time God reaches out to the
rest of us (the non-Jews) and offers salvation.

God searches hearts and minds and intents and purposes to see who it is
that is seeking the truth, or would seek the truth if given the oppor-
tunity. He reaches into their lives supernaturally and using the same
type of spiritual influence the evil spirits use, except He uses it in
no evil way, but in a positive way, God guides the person to come to His
Son, ask forgiveness, and be saved. The person really does come to the
cross and ask forgiveness, but they would never have done so without
that drawing of God, because in their flesh they are literally dead
spiritually. But by God's spiritual prompting, they move, and in this
world, by their mouth, in their thoughts, by their flesh, they ask Him
to forgive their sin, which enables the transaction to take place.

The power of life and death is in our tongue.

God has promised a time when His attentions will again be restored to
the Jews. At that time, which many Christians believe will come after
the rapture, the Jews who are transformed in this way will then see
Jesus as their Messiah, will then know the Law of God in their heart
and in their mind. They won't need someone to teach it to them, be-
cause they will simply know it on the inside by the spirit guidance
God will give them, which gives them new knowledge the flesh cannot
know.

Those former Jews will become the "new Christians" during that time,
leading people to Christ, likely doing miracles as the Apostles did
during their time here on Earth. It will be an unprecedented time a
pouring out of God's spirit upon all flesh, such that men and women
will move to serve Him in ways not seen since the century when Christ
was on the Earth.

It is the time in the very end when the final seven years will come
upon the people of the Earth, when God pours out His wrath upon all
flesh that has become corrupt. It is the preparation for the coming
Millennial Age where Christ will rule upon the Earth for 1,000 years,
the day of rest representative of God creating the Earth in 6 days,
and on the 7th day He rested, with God having dealt with man for the
Biblical timeline of 6,000 years, with a 1,000 year "day of rest,"
as it were, for to God 1,000 years is as a day, and a day is as 1,000
years.

> How about after the death of the flesh... Should gay people suffer forever?

Those involved in sin will suffer torment forever in the unending
flames of Hell. That includes you too, Chris, with your flippant,
tolerant, wibbly-wobbly attitude/position, and your unrepentant, un-
coming-to-Jesus-asking-forgiveness state.

It is SIN that will be cast down, all sin. Not just "gay people,"
but rather sinners.

We all have sin. We all need Jesus. It's why Christians like me
reach out and teach people these things. We don't do it for the
mockers and haters. We do it because there are still some who will
be saved. We do it for them, and not for other people. And we do
it to honor the guidance of God who told us to go forth and do this.

God has worked mighty things against the totally and wholly de-
structive nature of sin at work in man. Sin has ravaged this world,
and that's only in a few thousand years. Imagine what sin could do
at work in eternal beings in eternity. It's why God build a special
place of confinement for sin, called Hell. No one entering in to
Hell will EVER escape. It is a place where that sin will be wholly
confined forever, with each person who loves sin being tormented to
such an extreme continually that they will not be able to wield that
sinful nature against anything ever. Only pain, agony, torment,
literally forever... a type of "commensurate jail" for the heinous
crime of sin for an eternal being. On Earth people get life in
prison without the possibility of parole. They go to jail, and they
die in jail, for truly horrific crimes.

In God's Kingdom built upon truth, where sin is anything that is
anti-God (anti-truth), it eats away at God's creation like a cancer,
like a plague. It has no redeeming qualities. Nothing positive.
It is the worst crime there is against truth, and God has decreed
that all who will not follow after Him, pursuing truth seriously,
embracing sin wholly, will be confined into the commensurate prison
for their own eternal being nature.

-----
We see people here on Earth as only so-and-so in their body that
lives for Nnn years. But we are more than that. Sin has blinded
our eyes to it because in sin our spirit nature died. We no long-
er have that eternal perspective, so all we see is the flesh. We
try to make our lives comfy and wonderful here, but we do not give
an ounce of concern for our eternal soul.

What the light of the Bible does is teach us what we don't know,
and gives us an opportunity to know the truth so that our desire
to know that truth can be piqued, so we can be intrigued wanting
to know more. We can't know more in our flesh, but God sees our
heart's desire to want to know more, and He then intervenes and
pours out His own spirit nature to draw us in supernatural non-
flesh ways to the truth, to more knowledge of His Son, to the point
where we eventually come to Him in repentance, in tears, broken,
seeing our sin, acknowledging that we are guilty, and then asking
Him to forgive us, to the point where we are saved.

The light of the gospel shines in the darkness of sin, driving
that darkness away. It is there for all who have eyes to see,
for all who will be saved.

For those who will embrace sin and reject the truth, they will
never see it and they will perish in their sin. Christians do
not know who it is who will be saved, so we reach out to all
sinners equally. We do not judge, but we warn what God has said
He will judge on that final day. We warn people so they have
time to repent of their sin, come to Jesus, ask forgiveness and
be saved. It's God's prescribed method of salvation for all who
will be saved, and we teach people these things so that those
who have an ear to hear will be saved. The rest will literally
go to their grave believing they are right, not realizing until
they leave this world that they were wholly consumed and deceived
by sin, believing the lies of the enemy, that that day of final
judgment will overtake them completely, and their eternal soul
will be cast headlong into the eternal lake of fire, from which
there will NEVER be any escape ever again.

It is the judgment of a Holy, Holy, Holy, righteous and pure God
keeping His House (Heaven, the universe) clear of sin's wholly
destructive influence.

God will not abide sin. But God's love for us gives us a way
out, a second chance, the ability to be redeemed even though we
are sinners.

God cannot allow sin to go unpunished, so He sent His own Son
to take on our sin, and God poured out His wrath against that
sin upon His own Son rather than us, literally crushing Him the
Bible says. And after that crushing, God raised Him back to
life and gave Him power and authority over all things in Heaven
and on Earth, because of His obedience, because of His righteous-
ness.

God's in the business of saving men and women today. It's why
He gave us Jesus. But that time is fast approaching an end,
and all who have rejected Him and remain alive in these final
end-times will be destroyed, consumed by their own sin, cast
forever into eternal judgment for it.

God gives people the choice today, teaching us that we must
call upon Him "while it is still called today," for none of us
know when we will leave this Earth. And none of us know the
day or the hour of Christ's second coming, when the rapture
will take place, and where Christ is coming back as a true con-
quering King to reclaim what was lost to sin, to put down every
enemy, to restore this world to His own for His upcoming full
Millennial reign.

If you hear His voice do not harden your heart. Listen to Him,
for He is reaching out to you to save your eternal soul.

--
Rick C. Hodgin

[Rick C. Hodgin]

On 12/24/2018 6:27 PM, Mr Flibble wrote:
> [snip]


Follow your own god, Leigh. See where that god leads you.

--
Rick C. Hodgin