Variable declaration syntax

[Rick C. Hodgin]

Has there ever been a proposal to the C++ standards committee to have
something like this:

01: CWhatever *a, b;
02: CWhatever* a, b;

01 produce a pointer to an instance of CWhatever in a, and it
allocates an actual CWhatever for b, while the declaration in
02 to produce pointers to instances of CWhatever for both a
and b?

Basically, to have the compiler look at the type as it exists con-
tiguously, and apply it in that contiguous fashion (comparing the
"[CWhatever][space][asterisk]" to "[CWhatever][asterisk][space]"),
indicating [CWhatever] in the first, and [CWhatever*] combined in
the second, because of the contiguous nature of the declaration.

I use this a lot, and I do not like it makes sense to write:

03: CWhatever* a, *b;

Or:

03: CWhatever* a;
04: CWhatever* b;

Seems the syntax could be improved to be this:

03: CWhatever* a, b; // Both are declared as pointers
// because the type is "CWhatever*"
// and not just CWhatever and a tag
// for variable #1 that it, and it
// alone, is a pointer.

--
Rick C. Hodgin

[bartc]

On 09/04/2018 13:48, Rick C. Hodgin wrote:
> Has there ever been a proposal to the C++ standards committee to have
> something like this:
>
> 01: CWhatever *a, b;
> 02: CWhatever* a, b;
>
> 01 produce a pointer to an instance of CWhatever in a, and it
> allocates an actual CWhatever for b, while the declaration in
> 02 to produce pointers to instances of CWhatever for both a
> and b?
>

So, C++ syntax isn't complicated or ambiguous enough, it's necessary to
make white space significant?

I'll go along with that (since I'm never going to use C++ anyway)...

--
bartc

[Mr Flibble]

Significant whitespace is the worst idea ever and I refuse to use
languages that use it (e.g. Python).

/Flibble

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

[Rick C. Hodgin]

On 4/9/2018 9:10 AM, bartc wrote:
> On 09/04/2018 13:48, Rick C. Hodgin wrote:
>> Has there ever been a proposal to the C++ standards committee to have
>> something like this:
>>
>>      01:  CWhatever *a, b;
>>      02:  CWhatever* a, b;
>>
>> 01 produce a pointer to an instance of CWhatever in a, and it
>> allocates an actual CWhatever for b, while the declaration in
>> 02 to produce pointers to instances of CWhatever for both a
>> and b?
>>
>
> So, C++ syntax isn't complicated or ambiguous enough, it's necessary to
> make white space significant?

I think both 01 and 02 above producing the same declarations is very
confusing. It's burned me a few times when I've looked at code, or
gone to create new variables.

I would much rather see 02 produce two pointers. My C-like language
operates that way. When enabled, whatever is declared contiguously
becomes the full de facto type for every reference thereafter. By
default it works as above for backward compatibility.

> I'll go along with that (since I'm never going to use C++ anyway)...

--

Rick C. Hodgin

PS -- The email address you post under is not valid. I accidentally
clicked "Reply" instead of "Follow-up" and it was immediately
returned.

[David Brown]

On 09/04/18 14:48, Rick C. Hodgin wrote:
> Has there ever been a proposal to the C++ standards committee to have
> something like this:
>
> 01: CWhatever *a, b;
> 02: CWhatever* a, b;
>
> 01 produce a pointer to an instance of CWhatever in a, and it
> allocates an actual CWhatever for b, while the declaration in
> 02 to produce pointers to instances of CWhatever for both a
> and b?

I am sure you are not the first person to want this. But I think most
people would find it confusing and inconsistent if C++ worked this way,
and since both currently mean the same thing ("a" is a pointer, "b" is
an object) then there is absolutely zero chance of it being changed - it
would break lots of code.

>
> Basically, to have the compiler look at the type as it exists con-
> tiguously, and apply it in that contiguous fashion (comparing the
> "[CWhatever][space][asterisk]" to "[CWhatever][asterisk][space]"),
> indicating [CWhatever] in the first, and [CWhatever*] combined in
> the second, because of the contiguous nature of the declaration.
>
> I use this a lot, and I do not like it makes sense to write:
>
> 03: CWhatever* a, *b;
>

Don't write that. It would confuse people (yourself included).

> Or:
>
> 03: CWhatever* a;
> 04: CWhatever* b;
>
> Seems the syntax could be improved to be this:
>
> 03: CWhatever* a, b; // Both are declared as pointers
> // because the type is "CWhatever*"
> // and not just CWhatever and a tag
> // for variable #1 that it, and it
> // alone, is a pointer.
>

If you were designing a non-C language from scratch, you might want to
do something like that. But C++ will never change in this regard.

And if you follow C++ (and modern C) common practice of almost always
initialising your variables on declaration, there is no question of how
to do it:

CWhatever *a = new CWhatever;
CWhatever b = *a;

A single declaration and initialisation per line is common. Usually you
should not declare your variable until you have something useful to put
in it.

Sometimes, because of scoping, you need a declaration earlier. Even
then, you usually want to keep one declaration per line.

The exception is a bunch of related variables - like "int x, y, z;".
Don't mix types, pointers, references, etc., in the same declaration.

[Mr Flibble]

On 09/04/2018 14:51, Rick C. Hodgin wrote:
> On 4/9/2018 9:10 AM, bartc wrote:
>> On 09/04/2018 13:48, Rick C. Hodgin wrote:
>>> Has there ever been a proposal to the C++ standards committee to have
>>> something like this:
>>>
>>>      01:  CWhatever *a, b;
>>>      02:  CWhatever* a, b;
>>>
>>> 01 produce a pointer to an instance of CWhatever in a, and it
>>> allocates an actual CWhatever for b, while the declaration in
>>> 02 to produce pointers to instances of CWhatever for both a
>>> and b?
>>>
>>
>> So, C++ syntax isn't complicated or ambiguous enough, it's necessary
>> to make white space significant?
>
> I think both 01 and 02 above producing the same declarations is very
> confusing.  It's burned me a few times when I've looked at code, or
> gone to create new variables.
>
> I would much rather see 02 produce two pointers.  My C-like language
> operates that way.  When enabled, whatever is declared contiguously
> becomes the full de facto type for every reference thereafter.  By
> default it works as above for backward compatibility.

Your language is toy and this behaviour is probably at the top of the
list of reasons why: language syntax being predicated on a compiler
setting is an even worse idea than significant whitespace.

[Rick C. Hodgin]

On 4/9/2018 9:51 AM, Mr Flibble wrote:
> On 09/04/2018 14:10, bartc wrote:
>> So, C++ syntax isn't complicated or ambiguous enough, it's necessary
>> to make white space significant?
>

> Significant whitespace is the worst idea ever

One of my goals for my C-like language is to allow whitespaces in
names. To this end, I allow a ctrl+spacebar to introduce a linked
whitespace, which is a connector of related name components.

Internally it's stored as the \377 character (ASCII 255). I have
used it in Visual FreePro already since 2014:

(See upper-left editor image)
http://www.visual-freepro.org/images/vjr_054.png

It puts a blue line underneath linked name portions, uses a half-
indent on the left-and-right side, and averages out the remaining
pixels within the normal space allocated, so the internal spaces
actually take up less space than a real whitespace, but are still
a clear indicator for the eye.

> and I refuse to use
> languages that use it (e.g. Python).

Okay.

--
Rick C. Hodgin

[Rick C. Hodgin]

On Monday, April 9, 2018 at 9:54:57 AM UTC-4, Mr Flibble wrote:
> On 09/04/2018 14:51, Rick C. Hodgin wrote:
> > I think both 01 and 02 above producing the same declarations is very
> > confusing.  It's burned me a few times when I've looked at code, or
> > gone to create new variables.
> >
> > I would much rather see 02 produce two pointers.  My C-like language
> > operates that way.  When enabled, whatever is declared contiguously
> > becomes the full de facto type for every reference thereafter.  By
> > default it works as above for backward compatibility.
>
> Your language is toy and this behaviour is probably at the top of the
> list of reasons why: language syntax being predicated on a compiler
> setting is an even worse idea than significant whitespace.

My C-like language is called "CAlive" for two reasons. Second, because
I am trying to inject some life back into C (adding the class, exceptions,
a few other things). It also serves the primary meaning of a reminder
that Jesus Christ is alive. The entire language is offered to Him, as
the best I'm able to produce given the skills He has given me.

It may be "toy" to other people, but it's the best I have, Leigh. And
I give it to Him by name explicitly.

What would you say to your child if they gave you something they created
by their own choice to do so just for you, yet it wasn't as good as you
could've done had you been there to aid them during the project?

As I recall, you've rejected my calls when I've repeatedly asked for
help. You hold my love of Jesus Christ as the primary reason you won't
engage me in technical matters. You seem to only drop by to disparage
my work and call me horrible names. That's a testimony I would worry
about if it came from my life.

--
Rick C. Hodgin

[Mr Flibble]

On 09/04/2018 14:58, Rick C. Hodgin wrote:
> On 4/9/2018 9:51 AM, Mr Flibble wrote:
>> On 09/04/2018 14:10, bartc wrote:
>>> So, C++ syntax isn't complicated or ambiguous enough, it's necessary
>>> to make white space significant?
>>
>> Significant whitespace is the worst idea ever
>
> One of my goals for my C-like language is to allow whitespaces in
> names.  To this end, I allow a ctrl+spacebar to introduce a linked
> whitespace, which is a connector of related name components.
>
> Internally it's stored as the \377 character (ASCII 255).  I have
> used it in Visual FreePro already since 2014:
>
>     (See upper-left editor image)
>     http://www.visual-freepro.org/images/vjr_054.png

Worst. Idea. Ever. As to your deliberate indirect spamming of Christian
iconography to try to push your agenda: speed of light mate.

[Bo Persson]

On 2018-04-09 15:52, David Brown wrote:
> On 09/04/18 14:48, Rick C. Hodgin wrote:
>> Has there ever been a proposal to the C++ standards committee to have
>> something like this:
>>
>> 01: CWhatever *a, b;
>> 02: CWhatever* a, b;
>>
>> 01 produce a pointer to an instance of CWhatever in a, and it
>> allocates an actual CWhatever for b, while the declaration in
>> 02 to produce pointers to instances of CWhatever for both a
>> and b?
>
> I am sure you are not the first person to want this. But I think most
> people would find it confusing and inconsistent if C++ worked this way,
> and since both currently mean the same thing ("a" is a pointer, "b" is
> an object) then there is absolutely zero chance of it being changed - it
> would break lots of code.
>

And even if we were to define those examples, we would then have to
consider the meaning of


03: CWhatever * a, b;
04: CWhatever*a,b;

And now we are closing in on madness.



Bo Persson

[Mr Flibble]

+1 for one declaration per line.

[Rick C. Hodgin]

On Monday, April 9, 2018 at 10:09:15 AM UTC-4, Mr Flibble wrote:
> On 09/04/2018 14:58, Rick C. Hodgin wrote:
> > On 4/9/2018 9:51 AM, Mr Flibble wrote:
> >> On 09/04/2018 14:10, bartc wrote:
> >>> So, C++ syntax isn't complicated or ambiguous enough, it's necessary
> >>> to make white space significant?
> >>
> >> Significant whitespace is the worst idea ever
> >
> > One of my goals for my C-like language is to allow whitespaces in
> > names.  To this end, I allow a ctrl+spacebar to introduce a linked
> > whitespace, which is a connector of related name components.
> >
> > Internally it's stored as the \377 character (ASCII 255).  I have
> > used it in Visual FreePro already since 2014:
> >
> >     (See upper-left editor image)
> >     http://www.visual-freepro.org/images/vjr_054.png
>
> Worst. Idea. Ever.

It's been incorporated into other database languages, such as
Microsoft's TSQL (in TSQL you have to use [brackets for any]
names with spaces).

> As to your deliberate indirect spamming of Christian
> iconography to try to push your agenda: speed of light mate.

Everything I've done personally since July 12, 2012 has been
done for Jesus Christ, Leigh. I thought long and hard about
what it means to be a Christian, and I have incorporated that
understanding into my life. It's daily. It's active. It's
in everything I do. I still fail a lot because I am tied to
this flesh, and I am consistently hit with rhetoric from the
unsaved which is designed to discourage me, to prevent me from
moving forward, to harm me in various ways.

It's the life of a Christian, Leigh. We are abused hard all
day long by those who are perishing because they don't want to
face the reality that God exist, and that they are under judg-
ment. It's very hurtful to be attacked continually like this,
but we endure it because we know who it is we serve. He is
worth all the pain, all the loss, all the damage done by others.
He was humiliated in this world, and rose in full power. We are
to take up our cross daily and follow Him ... and our fate may
well be the same as His, to suffer greatly in this world, but to
then rise in full power as He gives to us, enduring and shining
like the stars forever.

It's much better than a fair trade. Temporary pain here, and a
life lived in His Kingdom with Him forever. It's an easy choice.

--
Rick C. Hodgin

[Chris Vine]

On Mon, 9 Apr 2018 14:51:32 +0100
Mr Flibble <flibbleREM...@i42.co.uk> wrote:
> On 09/04/2018 14:10, bartc wrote:
> > On 09/04/2018 13:48, Rick C. Hodgin wrote:
> >> Has there ever been a proposal to the C++ standards committee to
> >> have something like this:
> >>
> >>      01:  CWhatever *a, b;
> >>      02:  CWhatever* a, b;
> >>
> >> 01 produce a pointer to an instance of CWhatever in a, and it
> >> allocates an actual CWhatever for b, while the declaration in
> >> 02 to produce pointers to instances of CWhatever for both a
> >> and b?
> >>
> >
> > So, C++ syntax isn't complicated or ambiguous enough, it's
> > necessary to make white space significant?
> >
> > I'll go along with that (since I'm never going to use C++
> > anyway)...
>
> Significant whitespace is the worst idea ever and I refuse to use
> languages that use it (e.g. Python).

Your programming choices then are going to be severely limited. I
cannot immediately think of one where whitespace is not significant
except brainfuck. Good luck with that one.

C++ for the most part inherits C's tokenizing. When tokenizing, "+ +"
is not the same as "++", "< <" is not the same as "<<" and so on.
Whitespace is significant in the pre-processor as well.

That's not to say that I agree with Rick's views. He is obviously
severely up his backside on this one.

[Mr Flibble]

On 09/04/2018 15:28, Rick C. Hodgin wrote:
> On Monday, April 9, 2018 at 10:09:15 AM UTC-4, Mr Flibble wrote:
>> On 09/04/2018 14:58, Rick C. Hodgin wrote:
>>> On 4/9/2018 9:51 AM, Mr Flibble wrote:
>>>> On 09/04/2018 14:10, bartc wrote:
>>>>> So, C++ syntax isn't complicated or ambiguous enough, it's necessary
>>>>> to make white space significant?
>>>>
>>>> Significant whitespace is the worst idea ever
>>>
>>> One of my goals for my C-like language is to allow whitespaces in
>>> names.  To this end, I allow a ctrl+spacebar to introduce a linked
>>> whitespace, which is a connector of related name components.
>>>
>>> Internally it's stored as the \377 character (ASCII 255).  I have
>>> used it in Visual FreePro already since 2014:
>>>
>>>     (See upper-left editor image)
>>>     http://www.visual-freepro.org/images/vjr_054.png
>>
>> Worst. Idea. Ever.
>
> It's been incorporated into other database languages, such as
> Microsoft's TSQL (in TSQL you have to use [brackets for any]
> names with spaces).

You can visually see those brackets so that is slightly less egregious
than your idea but only slightly less.

>
>> As to your deliberate indirect spamming of Christian
>> iconography to try to push your agenda: speed of light mate.
>
> Everything I've done personally since July 12, 2012 has been
> done for Jesus Christ, Leigh. I thought long and hard about
> what it means to be a Christian, and I have incorporated that
> understanding into my life. It's daily. It's active. It's
> in everything I do. I still fail a lot because I am tied to
> this flesh, and I am consistently hit with rhetoric from the
> unsaved which is designed to discourage me, to prevent me from
> moving forward, to harm me in various ways.
>
> It's the life of a Christian, Leigh. We are abused hard all
> day long by those who are perishing because they don't want to

You are mistaken; you are not being ridiculed your beliefs are. It is
you who chose to conflate the believer with their beliefs: I never do
that. People are free to believe whatever nonsense they want and I
would defend their right to do so however that does not mean that I have
to respect those beliefs.

> face the reality that God exist, and that they are under judg-
> ment. It's very hurtful to be attacked continually like this,
> but we endure it because we know who it is we serve. He is
> worth all the pain, all the loss, all the damage done by others.
> He was humiliated in this world, and rose in full power. We are
> to take up our cross daily and follow Him ... and our fate may
> well be the same as His, to suffer greatly in this world, but to
> then rise in full power as He gives to us, enduring and shining
> like the stars forever.
>
> It's much better than a fair trade. Temporary pain here, and a
> life lived in His Kingdom with Him forever. It's an easy choice.

And what if you are wrong? You have been putting up with misplaced
ridicule for no reason wasting so much time defending the indefensible
in the process.

Are you wrong? Speed of light mate.

[Rick C. Hodgin]

On Monday, April 9, 2018 at 10:28:22 AM UTC-4, Rick C. Hodgin wrote:
> On Monday, April 9, 2018 at 10:09:15 AM UTC-4, Mr Flibble wrote:
> > As to your deliberate indirect spamming of Christian
> > iconography to try to push your agenda: speed of light mate.
>
> Everything I've done personally since July 12, 2012 has been
> done for Jesus Christ, Leigh. I thought long and hard about
> what it means to be a Christian, and I have incorporated that
> understanding into my life. It's daily. It's active. It's
> in everything I do. I still fail a lot because I am tied to
> this flesh, and I am consistently hit with rhetoric from the
> unsaved which is designed to discourage me, to prevent me from
> moving forward, to harm me in various ways.

One other thing ... the vision I've had is to create a complete
computer system from hardware to operating system to drivers to
compilers to user apps, all as an offering to Jesus rather than
to self, to a corporation, to money, or some other purpose. It
is an offering to Him, and to all of mankind, all free and open,
the best we're able to produce (Christians working together on
this project), so that people can have a complete computer for
their use free from all IP and licensing entanglements.

It is a goal to take what God gives us first, and give it back
to mankind.

With regards to whitespace variable names, it is part of a much
more comprehensive vision than Ctrl+spacebar. I began working
on a keyboard design for this hardware platform, which incorporates
a three-key spacebar. One of those is for whitespaces in contiguous
names:

http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/ukm/keyboard/graphics/key_assignments_empty.png

-----
The vision I have is a comprehensive vision. I do not want to do
it alone, but I am proceeding on it because it's all I have. It
incorporates my interests (hardware and software design), and it is
using the skills He first gave me in a way designed explicitly to
honor Him.

I mention all of this to you because you seem to think I am not a
well thought out individual. I spend a great deal of time regularly
reflecting on and examining the path of my life. I make purposeful
adjustments to things as I go, and following much prayer and real
contemplation.

There is nothing I do that is "toy." It is me on my knees, looking
up, seeing what I am able to do in this world, and moving forward
with it, trusting in the Lord to bring it to fruition, because it
is only by Him that any of us (non-believers included) achieve any
degree of success in this world (yourself included). Without Him
there to give you that success, it never would've been yours.

So my apparent failures are not failures, but are simply me being
obedient to Him until His time brings them to fruition. I press
on because I desire these things, and He knows perfectly well what
my true intentions are. I move heartily unto Him, always looking
up and doing my best. And I fail a lot in the world's eyes, but
as I press on I succeed a lot in His eyes because I am not dis-
couraged by the world, only hindered by it, and even then only be-
cause He allows me to be hindered by it.

I trust in the Lord, Leigh. And I bring that faith to bear in
all areas of my life.

--
Rick C. Hodgin

[Rick C. Hodgin]

On Monday, April 9, 2018 at 10:39:32 AM UTC-4, Mr Flibble wrote:
> On 09/04/2018 15:28, Rick C. Hodgin wrote:
> > On Monday, April 9, 2018 at 10:09:15 AM UTC-4, Mr Flibble wrote:
> >> On 09/04/2018 14:58, Rick C. Hodgin wrote:
> >>> On 4/9/2018 9:51 AM, Mr Flibble wrote:
> >>>> On 09/04/2018 14:10, bartc wrote:
> >>>>> So, C++ syntax isn't complicated or ambiguous enough, it's necessary
> >>>>> to make white space significant?
> >>>>
> >>>> Significant whitespace is the worst idea ever
> >>>
> >>> One of my goals for my C-like language is to allow whitespaces in
> >>> names.  To this end, I allow a ctrl+spacebar to introduce a linked
> >>> whitespace, which is a connector of related name components.
> >>>
> >>> Internally it's stored as the \377 character (ASCII 255).  I have
> >>> used it in Visual FreePro already since 2014:
> >>>
> >>>     (See upper-left editor image)
> >>>     http://www.visual-freepro.org/images/vjr_054.png
> >>
> >> Worst. Idea. Ever.
> >
> > It's been incorporated into other database languages, such as
> > Microsoft's TSQL (in TSQL you have to use [brackets for any]
> > names with spaces).
>
> You can visually see those brackets so that is slightly less egregious
> than your idea but only slightly less.

You can visibly see the blue underline on the variable in my
design. I actually incorporated that design because I wanted
it to be less syntactically obtuse than something like brackets.

--
Rick C. Hodgin

[Mr Flibble]

We are talking about the significance of whitespace AFTER
preprocessing/tokenization.

[Rick C. Hodgin]

On 4/9/2018 10:23 AM, Bo Persson wrote:
> And even if we were to define those examples, we would then have to
> consider the meaning of
>
>    03:  CWhatever * a, b;
>    04:  CWhatever*a,b;
>
> And now we are closing in on madness.

In my opinion, two warnings are issued:

03 -- "ambiguous declaration, assuming type CWhatever* for a,
CWhatever for b."

04 -- "ambiguous declaration, assuming type CWhatever* for a, b."

And any alternate uses of those types would produce relative errors,
with the diagnostic there to aid in discovery / recovery.

--
Rick C. Hodgin

[Rick C. Hodgin]

On 4/9/2018 10:45 AM, Mr Flibble wrote:
> On 09/04/2018 15:38, Chris Vine wrote:
> We are talking about the significance of whitespace AFTER
> preprocessing/tokenization.

In the case of CAlive and Visual FreePro, Jr., they are not whitespaces
but are linking spaces, a completely different character that is readily
tokenized out during lexing and grouping together of co-joined symbols.

From that point forward, the alphanumeric form of the variable name is
all that remains as a thing in the language, making it easy to handle.

The only unusual thing I had to add was a unique way to render that
component. But, since my editor is linked directly to my compiler,
the fact that the compile-time information is already there is the
benefit which made it easy. I simply render the name like normal,
and then post-process and re-render the one component using the high-
lighted syntax.

I can teach you how to do it if you like.

--
Rick C. Hodgin

[Chris Vine]

On Mon, 9 Apr 2018 15:45:17 +0100

No we weren't. You would have to change the lexing rules to implement
his daft idea. And you would have to do the same to implement python
style significance, whereby whitespace replaces braces.

Anyway tokenizing is an implementation issue. There is no one way to
scan and tokenize a line of code and build up your AST. In the C++
language, whitespace is significant. Just not in the way it is in
python.

[Mr Flibble]

If they gave out awards for how to waste the most time you would win the
award for greatest time waster in the universe.

You remind me of Terry A. Davis who is doing a similar thing with his
TempleOS but at least you don't appear to be shouty racist like Terry
which is a +1 for you.

Seriously mate you need to stop wasting time on religiously themed wheel
reinvention vanity projects and do something more useful with your time.

How much time have you got? Try to answer that question whilst
pretending that there is no afterlife and this is the only life you get:
YOLO.

[Mr Flibble]

Obviously I am talking about how whitespace is significant in Python.

[Mr Flibble]

Linking the editor directly to the compiler is yet another bad idea (YABI).

>
> I can teach you how to do it if you like.

Based on all previous interactions it is higly unlikely that you can
teach me anything either on theology or software engineering.

[Jorgen Grahn]

On Mon, 2018-04-09, bartc wrote:
...

> I'll go along with that (since I'm never going to use C++ anyway)...

If you're not, then what are you doing posting in comp.lang.c++?

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Rick C. Hodgin]

Terry has a degenerative neurological disease. I watched his work
before his OS became Temple OS, back in the late 90s and early 00s
when I was working on my OS.

He has excellent developer skills, but, by his own admission, has
many neurological issues. He also reports hearing things from God
that are not consistent with Biblical teachings. He is hearing the
voice of demons twisting things around and adding confusion.

> Seriously mate you need to stop wasting time on religiously themed wheel
> reinvention vanity projects and do something more useful with your time.
>
> How much time have you got? Try to answer that question whilst
> pretending that there is no afterlife and this is the only life you get:
> YOLO.

My life's offering is unto the Lord, Leigh. I put my faith and
trust in Him and His teachings because I know the Rick before I
came to ask forgiveness for my sin, and the Rick after. The old
Rick still tries to thwart the efforts of the new Rick (meaning
my flesh still tries to do the things of the world, even as my
spirit leads me to do the things of God).

It is a struggle. And men and women like you and Peter Cheung,
piling on all manner of hate daily, does not help. It does not
make it any easier. But it also solidifies the realization that
I am on the right path because Jesus told us we would face such
persecution. He also told us it would get worse and worse as the
Day approaches.

> "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 put your faith in your own self-belief, Leigh. But as I've
indicated to you previously: Do you know everything? No. Do
you know half of everything? No. Is it possible that God exists
in the half you don't know? Yes.

It's where I found Him. It's where all people who were previously
non-believers (all people) found Him. He is in the part they did
not know previously, otherwise they would've already been following
Him with their lives.

-----
All I've ever asked anyone to do is to seek the truth for their
own sake. Read the Bible and seek the truth. Go to a church and
ask your hardest questions ("speed of light mate") and see what
their personal response is to you.

Don't just assume. Go and seek and find out and be willing to
learn something new. That's how all of us got saved. We had to
get to a point where we said, "It's possible I don't have it right.
It's possible I could be wrong." From there, God did the rest.

--
Rick C. Hodgin

[Rick C. Hodgin]

On 4/9/2018 11:01 AM, Mr Flibble wrote:
> On 09/04/2018 15:51, Rick C. Hodgin wrote:
>> On 4/9/2018 10:45 AM, Mr Flibble wrote:
>>> On 09/04/2018 15:38, Chris Vine wrote:
>>> We are talking about the significance of whitespace AFTER
>>> preprocessing/tokenization.
>>
>> In the case of CAlive and Visual FreePro, Jr., they are not whitespaces
>> but are linking spaces, a completely different character that is readily
>> tokenized out during lexing and grouping together of co-joined symbols.
>>
>>  From that point forward, the alphanumeric form of the variable name is
>> all that remains as a thing in the language, making it easy to handle.
>>
>> The only unusual thing I had to add was a unique way to render that
>> component.  But, since my editor is linked directly to my compiler,
>> the fact that the compile-time information is already there is the
>> benefit which made it easy.  I simply render the name like normal,
>> and then post-process and re-render the one component using the high-
>> lighted syntax.
>
> Linking the editor directly to the compiler is yet another bad idea (YABI).

It's a LiveCode ABI (edit-and-continue, continuous changes to all
data and code while running). I introduce a new concept called an
'inquiry' which is a program state where it's not running, hasn't
crashed, but is waiting for the developer to provide information on
how to handle an unexpected condition. One option is to terminate
the program with an error code. Another is to fix the data or code
and resume ... hence "live code".

It's an incredibly comprehensive philosophy, Leigh. It's been
developed over years. It's even been part of a vision I've had
on things I would incorporate in my OS since the 90s. I would
not expect you to be able to summarily step in and conclude rightly
all of the components to it because I don't even remember all of
them all the time and I've spent weeks and months working on each
of them at various times.

>> I can teach you how to do it if you like.
>
> Based on all previous interactions it is higly unlikely that you can
> teach me anything either on theology or software engineering.

There is a lot I could teach you if you were willing to learn.

--
Thank you! | Indianapolis, Indiana | God is love -- 1 John 4:7-9
Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj
-------------------------------------------------------------------------
Software: LSA, LSC, Debi, RDC/CAlive, ES/1, ES/2, VJr, VFrP, Logician
Hardware: Arxoda Desktop CPU, Arxita Embedded CPU, Arlina Compute FPGA

[Scott Lurndal]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:
>On 4/9/2018 9:51 AM, Mr Flibble wrote:
>> On 09/04/2018 14:10, bartc wrote:
>>> So, C++ syntax isn't complicated or ambiguous enough, it's necessary
>>> to make white space significant?
>>
>> Significant whitespace is the worst idea ever
>
>One of my goals for my C-like language is to allow whitespaces in
>names.

*The* *Worst* *Idea* *EVER*.

[Chris Vine]

On Mon, 9 Apr 2018 15:59:53 +0100

Flibble: "Significant whitespace is the worst idea ever and I refuse to
use languages that use it (e.g. Python)". Python was an example not a
constraint. It could not have been a constraint because your argument
was directed to whitespace significance in "CWhatever *a, b" versus
"CWhatever* a, b", which has no bearing on how whitespace is significant
in Python.

Let's end it. I don't like unnecessary significance in whitespace
where there are better ways of doing it. If you eliminate it entirely
you end up with something like the aptly named brainfuck. And I agree
that Rick's idea falls within the "unnecessary signficance" category.
I would go further. It is completely undesirable.

[Mr Flibble]

On 09/04/2018 16:10, Rick C. Hodgin wrote:
> On 4/9/2018 11:01 AM, Mr Flibble wrote:
>> On 09/04/2018 15:51, Rick C. Hodgin wrote:
>>> I can teach you how to do it if you like.
>>
>> Based on all previous interactions it is higly unlikely that you can
>> teach me anything either on theology or software engineering.
>
> There is a lot I could teach you if you were willing to learn.

Wrong. There is nothing that you can teach me and I base this assertion
on the fractal wrongness nature of all of your posts so far.

[Mr Flibble]

We have been over this several times. As you put it in the half that I
*do* know I know that *your* god doesn't exist (speed of light mate) but
I am agnostic about the existence of gods in general.

/Flibble

--

[Kenny McCormack]

In article <EpLyC.79280$bz1....@fx01.iad>,

It is certainly a candidate for that title. Although, Rick is a bubbling
font of bad ideas, so don't count him out anytime soon.

But here's the thing: It's not *THAT* much worse of an idea than that of
allowing spaces (and other garbage characters) in filenames.

I know that this is a minority view, but I strongly believe that allowing
garbage in filenames is a big mistake, that just complicates everybody's
lives. Rather, the Right Way to Do It is to distinguish between a thing's
NAME and its LABEL. Names should be kept short and garbage-free, but
labels can, of course, contain anything.

Some early DOS system-enhancement-tools gave this functionality. They
couldn't do anything about the basic 8.3 limitation of DOS, so they gave
you the ability to attach an arbitrary label to the file (and, in some
limited circumstances, use this label as an alias for the filename).

I strongly believe that is the Right Way to Do It.

--
If you think you have any objections to anything I've said above, please
navigate to this URL:
http://www.xmission.com/~gazelle/Truth
This should clear up any misconceptions you may have.

[Rick C. Hodgin]

On Monday, April 9, 2018 at 11:19:03 AM UTC-4, Mr Flibble wrote:
> On 09/04/2018 16:10, Rick C. Hodgin wrote:
> > On 4/9/2018 11:01 AM, Mr Flibble wrote:
> >> On 09/04/2018 15:51, Rick C. Hodgin wrote:
> >>> I can teach you how to do it if you like.
> >>
> >> Based on all previous interactions it is higly unlikely that you can
> >> teach me anything either on theology or software engineering.
> >
> > There is a lot I could teach you if you were willing to learn.
>
> Wrong. There is nothing that you can teach me and I base this assertion
> on the fractal wrongness nature of all of your posts so far.

I could also learn a lot from you, Leigh. God made us to be stronger
together than we are in isolation and apart. It's why He gave each of
us our several abilities, but not all abilities to each of us wholly.

He wanted us to come together and help one another, to form communities
and grow and share and learn together, as I imagine that is what Heaven
is going to be like, and it's a precursor view here in our limited and
(currently) tangible form.

You are a most capable developer, Leigh. You would be a great addition
to the hardware and software project I am working on. You could do a
great many things I either couldn't do, or would be worse at than you
are.

We would be stronger together than we are apart.

--
Rick C. Hodgin

[Rick C. Hodgin]

I believed the same way before I became a Christian. I did not think
such a conversion was truly possible.

> but
> I am agnostic about the existence of gods in general.

I was not. I was an atheist and I was convinced I was right (because
all I knew then was my flesh). It's actually why I agreed to read
the Bible. I was convinced I was right and I knew I could tear it
down systematically from factual error to outright lie to misleading
point, one after the other.

What I was not able to know or be prepared for was the introduction
of the spirit into my life. When I was drawn spiritually, and when
I was made alive spiritually, my entire life changed, and remains
changed to this day.

Each person who will be saved has their day, and they will truly be
forever changed.

--
Rick C. Hodgin

[Mr Flibble]

I would rather stick pins in my eyes.

[Rick C. Hodgin]

On Monday, April 9, 2018 at 11:24:48 AM UTC-4, Kenny McCormack wrote:
> But here's the thing: It's not *THAT* much worse of an idea than that of
> allowing spaces (and other garbage characters) in filenames.
>
> I know that this is a minority view, but I strongly believe that allowing
> garbage in filenames is a big mistake, that just complicates everybody's
> lives. Rather, the Right Way to Do It is to distinguish between a thing's
> NAME and its LABEL. Names should be kept short and garbage-free, but
> labels can, of course, contain anything.
>
> Some early DOS system-enhancement-tools gave this functionality. They
> couldn't do anything about the basic 8.3 limitation of DOS, so they gave
> you the ability to attach an arbitrary label to the file (and, in some
> limited circumstances, use this label as an alias for the filename).
>
> I strongly believe that is the Right Way to Do It.

Human beings deal well with visual components broken out. We have
a huge percentage of our lifetime's visual training spent learning
to read using our system which uses spaces to separate things.

I view spaces in names as a desirable thing across the board,
largely for those reasons.

--
Rick C. Hodgin

[Mr Flibble]

On 09/04/2018 16:28, Rick C. Hodgin wrote:
> On Monday, April 9, 2018 at 11:22:28 AM UTC-4, Mr Flibble wrote:
>> On 09/04/2018 16:07, Rick C. Hodgin wrote:
>>> You put your faith in your own self-belief, Leigh. But as I've
>>> indicated to you previously: Do you know everything? No. Do
>>> you know half of everything? No. Is it possible that God exists
>>> in the half you don't know? Yes.
>>
>> We have been over this several times. As you put it in the half that I
>> *do* know I know that *your* god doesn't exist (speed of light mate)
>
> I believed the same way before I became a Christian. I did not think
> such a conversion was truly possible.
>
>> but
>> I am agnostic about the existence of gods in general.
>
> I was not. I was an atheist

[snip]

I am an agnostic atheist but such a concept is probably alien to you.

As far as your particular god (the god of Abraham) is concerned I know
it doesn't exist because I know evolution and the speed of light in a
vacuum (paired with what we can observe in the night sky) are facts and
both of these facts contradict the Genesis narrative which gives us the
fictions of a 6000 year old universe and a first human.

[Rick C. Hodgin]

On Monday, April 9, 2018 at 11:35:30 AM UTC-4, Mr Flibble wrote:
> On 09/04/2018 16:28, Rick C. Hodgin wrote:
> > On Monday, April 9, 2018 at 11:22:28 AM UTC-4, Mr Flibble wrote:
> >> I am agnostic about the existence of gods in general.
> >
> > I was not. I was an atheist
> [snip]
>
> I am an agnostic atheist but such a concept is probably alien to you.
>
> As far as your particular god (the god of Abraham) is concerned I know
> it doesn't exist because I know evolution and the speed of light in a
> vacuum (paired with what we can observe in the night sky) are facts and
> both of these facts contradict the Genesis narrative which gives us the
> fictions of a 6000 year old universe and a first human.

There is more understanding than our flesh gives us. There is
spirit. It is spiritually where the true understanding of many
things we thought of a particular way here are superseded by the
new knowledge our new "spiritual eyes" and "spiritual mind" are
able to see, know, and understand.

I can't convince you, but remember this statement. When you
come to faith you will then known what I wrote and what it now
means in reality. Remember how sure you were of your beliefs
before faith, and how you only saw through certain eyes. And
then be compassionate and patient with those who do not yet
believe because they do not know what they do not know, and
therefore are only moving as they're able. It's not a personal
attack against you or your beliefs / faith, but is simply an
outcropping of them being spiritually dead, and espousing only
from their flesh.

It is difficult sometimes to navigate that which comes from
them, but it is required and it is something God leads you in
and through by His Holy Spirit.

--
Rick C. Hodgin

[bartc]

It's famously allowed (or was, if they've changed it) in Fortran and
Algol 68, among others.

--
bartc

[Mr Flibble]

On 09/04/2018 16:48, Rick C. Hodgin wrote:
> When you come to faith

Never going to happen mate.

[bartc]

On 09/04/2018 16:06, Jorgen Grahn wrote:
> On Mon, 2018-04-09, bartc wrote:
> ...
>> I'll go along with that (since I'm never going to use C++ anyway)...
>
> If you're not, then what are you doing posting in comp.lang.c++?

This is in my list of subscribed groups, for reasons I can't remember,
and I haven't got round to removing it.

Maybe it's helpful looking at C++ code every so often (when someone
posts some instead of the all religious nonsense), and realising that
perhaps C isn't so bad after all.

--
bartc

[Öö Tiib]

I hope I see what you do but I can't see why you do it?
I try to say what I did understand, please tell where I'm wrong.

The usual syntax that uses (same for both UTF-8 and ASCII)
underscore symbol '_' (char)95 in variable names "multiple_word_name"
was somehow not good for you.

Therefore you made it so that you can have spaces in variable names.

You decided to use for those spaces in names a UTF-8-inompatible
and ASCII-incompatible code (char)255.

Some Windows stuff I tried show that code as symbol 'ÿ' so likely
you have to use exclusively your own tools to see that symbol as a
space.

Your own tools underline the variable names with blue.

Visually if there were underscore symbols instead of spaces in a
"multiple word name" then these would coincide with that
blue underline that your tools anyway put there.

Where is the benefit?

[Rick C. Hodgin]

The ASCII-255 character is taken from the days of DOS-based video
cards and the associated fonts pre-loaded from the factory. They
remain the same today:

http://www.theasciicode.com.ar/american-standard-code-information-interchange/ascii-codes-table.png

The ASCII-255 character was already an empty space, as was ASCII-0.
Since 0 already has a definition as ASCIIZ strings, I went with the
other choice.

As part of my plan to build a complete hardware and software system
from the ground up, I have a plan to not use UTF-8, but to have a
different system:

https://groups.google.com/d/msg/comp.lang.c/Tq6ChAOreAg/IGz_FJ_VAAAJ

Conversion to/from UTF will be possible, but will be a layer atop
the fundamental forms.

--
Rick C. Hodgin

[bartc]

On 09/04/2018 14:51, Rick C. Hodgin wrote:

> On 4/9/2018 9:10 AM, bartc wrote:
>> On 09/04/2018 13:48, Rick C. Hodgin wrote:
>>> Has there ever been a proposal to the C++ standards committee to have
>>> something like this:
>>>
>>>      01:  CWhatever *a, b;
>>>      02:  CWhatever* a, b;
>>>
>>> 01 produce a pointer to an instance of CWhatever in a, and it
>>> allocates an actual CWhatever for b, while the declaration in
>>> 02 to produce pointers to instances of CWhatever for both a
>>> and b?
>>>
>>

>> So, C++ syntax isn't complicated or ambiguous enough, it's necessary
>> to make white space significant?
>

> I think both 01 and 02 above producing the same declarations is very
> confusing.  It's burned me a few times when I've looked at code, or
> gone to create new variables.

This syntax comes from C, which C++ unwisely adopted (I believe in the
interests of improving take-up of the language which would have been
harder with an incompatible new syntax).

It's been done like that for coming up to half a century, but according
to the experts on comp.lang.c, it's not a problem at all provided you
use the right tools, use the right guidelines (one declaration per line)
and learn C properly so you that will know that the example declares one
pointer only.

But as you say, you can do all that and still get tripped up. It could
even, if you've mistyped and CWhatever is the name of a variable rather
than a type, end up writing an expression that multiplies CWhatever by
a, then yields the value b.

> My C-like language operates that way.

If this is a new language, why repeat the mistake of C++ and try and
have compatible syntax? Do something obviously new rather than
perpetuating design errors from 50 years ago.

If you need compatibility, do something like this:

CWhatever *a, b; // old rules, one pointer
var CWhatever *a, b; // new rules, two pointers

and use the new form until the old can be deprecated. Then you can drop
the 'var'. And not need to rely on white space to alter meaning.

--
bartc

[Rick C. Hodgin]

I seek to provide compatibility with C, and incorporate some of C++'s
features, as they are into CAlive. I require switches to be enabled
to default to CAlive's syntax, which can either be instance settings,
#pragmas, or command line switches. Other new features do not break
backward compatibility and are enabled by default.

This all assumes I'll get it all coded. It's a tremendous amount of
work to do it right.

--
Rick C. Hodgin

[Ben Bacarisse]

There's some talking at cross purposes here. Fortran ignored spaces
(except for the special columns) so you could have them pretty much
anywhere, and Algol 68 allowed spaces in identifiers. However, in
neither case were the spaces significant.

--
Ben.

[Manfred]

On 4/9/2018 3:52 PM, David Brown wrote:

> On 09/04/18 14:48, Rick C. Hodgin wrote:
>> Has there ever been a proposal to the C++ standards committee to have
>> something like this:
>>
>> 01: CWhatever *a, b;
>> 02: CWhatever* a, b;
>>
>> 01 produce a pointer to an instance of CWhatever in a, and it
>> allocates an actual CWhatever for b, while the declaration in
>> 02 to produce pointers to instances of CWhatever for both a
>> and b?
>

> I am sure you are not the first person to want this.
I would say the first to /consider/, not to want this.

But I think most
> people would find it confusing and inconsistent if C++ worked this way,
> and since both currently mean the same thing ("a" is a pointer, "b" is
> an object) then there is absolutely zero chance of it being changed - it
> would break lots of code.
>

It is even more than that: it is just so basic (I would say dogmatic) in
C tokenization that whitespaces are not significant between different
symbols: the declaration "T*x" is equivalent to "T* x" or "T *x" in the
same way as "a+b" is equivalent to "a + b". This goes to the extent that
even newlines are not significant.
C (and, by inheritance, C++) programmers are used to this since the
beginning of time, and appreciate that this allows for adapting to one's
readability preferences without any impact on the meaning of the code.
In my opinion it is simply undesirable.

[Kenny McCormack]

In article <qDJyC.218504$Cz7.1...@fx10.am4>, bartc <b...@freeuk.com> wrote:

>On 09/04/2018 13:48, Rick C. Hodgin wrote:
>> Has there ever been a proposal to the C++ standards committee to have
>> something like this:
>>
>> 01: CWhatever *a, b;
>> 02: CWhatever* a, b;
>>
>> 01 produce a pointer to an instance of CWhatever in a, and it
>> allocates an actual CWhatever for b, while the declaration in
>> 02 to produce pointers to instances of CWhatever for both a
>> and b?
>>
>

>So, C++ syntax isn't complicated or ambiguous enough, it's necessary to
>make white space significant?
>

>I'll go along with that (since I'm never going to use C++ anyway)...

Then why are you even reading, much less posting to, a C++ group?

--
Donald Drumpf claims to be "the least racist person you'll ever meet".

This would be true if the only other person you've ever met was David Duke.

[Kenny McCormack]

In article <DJednduAcrqH5lbH...@giganews.com>,
Mr Flibble <flibbleREM...@i42.co.uk> wrote:
...
>> It's the life of a Christian, Leigh. We are abused hard all
>> day long by those who are perishing because they don't want to
>
>You are mistaken; you are not being ridiculed your beliefs are. It is
>you who chose to conflate the believer with their beliefs: I never do
>that. People are free to believe whatever nonsense they want and I
>would defend their right to do so however that does not mean that I
>have to respect those beliefs.

Actually, we *ARE* ridiculing Ricky. For posting wildly off-topic crap in
a technical newsgroup. If he did his stuff in religious groups, we'd be
fine with it.

I realize that he can't help it. And that's what makes it so deliciously
awful to read it.

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

[Öö Tiib]

To my knowledge ASCII is encoding that has only 7-bit characters.

How you convert from UTF-8? Convert that into your "ASCII of DOS
video-cards of eighties" encoding:

std::string name = u8"ℛ𝒾𝒸𝓀";

Also, what you wrote did not even attempt to answer my question.
What you did does not conform to anything actually working now
and also gives no benefits visually in your on tools. So why?

[Rick C. Hodgin]

On 4/9/2018 1:50 PM, Öö Tiib wrote:
> To my knowledge ASCII is encoding that has only 7-bit characters.

ASCII and extended-ASCII. I grew up in the DOS days, and ASCII was
all 256 characters.

> How you convert from UTF-8? Convert that into your "ASCII of DOS
> video-cards of eighties" encoding:
>
> std::string name = u8"ℛ𝒾𝒸𝓀";

Each character in the "ASCII of video cards" will map to and from
UTF-8 by translation tables.

> Also, what you wrote did not even attempt to answer my question.
> What you did does not conform to anything actually working now
> and also gives no benefits visually in your on tools. So why?

Nobody has to use it. It's a new feature. You can use variable
names with underscores all day long. You can use camelCase, or
OtherCase or whatever.

The goal is to look to the future when the complete system is
ready, and to give people an option to use if they want to.

--
Rick C. Hodgin

[Scott Lurndal]

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

>On 4/9/2018 1:50 PM, Öö Tiib wrote:
>> To my knowledge ASCII is encoding that has only 7-bit characters.
>
>ASCII and extended-ASCII. I grew up in the DOS days, and ASCII was
>all 256 characters.

"Extended ASCII (EASCII or high ASCII) character encodings are
eight-bit or larger encodings that include the standard seven-bit
ASCII characters, plus additional characters. The use of the term
is sometimes criticized,[1][2][3] because it can be mistakenly
interpreted to mean that the ASCII standard has been updated to
include more than 128 characters or that the term unambiguously
identifies a single encoding, neither of which is the case."

[Öö Tiib]

On Monday, 9 April 2018 20:59:33 UTC+3, Rick C. Hodgin wrote:
> The goal is to look to the future when the complete system is
> ready, and to give people an option to use if they want to.

Perhaps in future there are more people who are satisfied by
being limited with 256 symbols of eighties. Currently it is
unpopular option. Most require Unicode support.

[Rick C. Hodgin]

In the future I plan to implement a 32-bit system allowing for
100,000 characters per language, with the first 256 of each
being available as 8-bit forms, and up to 65,536 being in 16-
bit forms, and the full range in 32-bit forms per character:

https://groups.google.com/d/msg/comp.lang.c/Tq6ChAOreAg/IGz_FJ_VAAAJ

I think our current hodge podge systems are inadequate. We
need a single, unified, extensible system. That one allows
for up to ~43,000 language forms to each have 100,000 symbols.
It can also be reduced to allow ~430,000 languages to each have
10,000 symbols, all with their own 8-bit and 16-bit access for
the most common symbols.

--
Thank you! | Indianapolis, Indiana | God is love -- 1 John 4:7-9
Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj
-------------------------------------------------------------------------
Software: LSA, LSC, Debi, RDC/CAlive, ES/1, ES/2, VJr, VFrP, Logician
Hardware: Arxoda Desktop CPU, Arxita Embedded CPU, Arlina Compute FPGA

[Rick C. Hodgin]

On 4/9/2018 2:08 PM, Scott Lurndal wrote:
> "Rick C. Hodgin" <rick.c...@gmail.com> writes:

>> On 4/9/2018 1:50 PM, Öö Tiib wrote:
>>> To my knowledge ASCII is encoding that has only 7-bit characters.
>>
>> ASCII and extended-ASCII. I grew up in the DOS days, and ASCII was
>> all 256 characters.
>
> "Extended ASCII (EASCII or high ASCII) character encodings are
> eight-bit or larger encodings that include the standard seven-bit
> ASCII characters, plus additional characters. The use of the term
> is sometimes criticized,[1][2][3] because it can be mistakenly
> interpreted to mean that the ASCII standard has been updated to
> include more than 128 characters or that the term unambiguously
> identifies a single encoding, neither of which is the case."

I'll re-write it for you:

I grew up in the DOS days, and "ASCII" was all 256 characters.

Better?

Even to this day all video cards still come with support for the
256 character set from back then. There are 8-scan line forms,
14-scan line forms, and 16-scan line forms, among others.

A person can download them here if you like:

http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/es2/ES1/VGA

They were scanned from an ATI video card in November, 2017:


http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/es2/ES1/VGA/VGA.CPP

[bartc]

On 09/04/2018 18:30, Kenny McCormack wrote:
> In article <qDJyC.218504$Cz7.1...@fx10.am4>, bartc <b...@freeuk.com> wrote:
>> On 09/04/2018 13:48, Rick C. Hodgin wrote:
>>> Has there ever been a proposal to the C++ standards committee to have
>>> something like this:
>>>
>>> 01: CWhatever *a, b;
>>> 02: CWhatever* a, b;
>>>
>>> 01 produce a pointer to an instance of CWhatever in a, and it
>>> allocates an actual CWhatever for b, while the declaration in
>>> 02 to produce pointers to instances of CWhatever for both a
>>> and b?
>>>
>>
>> So, C++ syntax isn't complicated or ambiguous enough, it's necessary to
>> make white space significant?
>>
>> I'll go along with that (since I'm never going to use C++ anyway)...
>
> Then why are you even reading, much less posting to, a C++ group?

Why, is it a prerequisite to have to use a language in order to be able
to read discussion about it? I sometimes look at the Fortran group, and
have even read the Awk group, and don't code in either. But I have
briefly dabbled in all of them.

Languages are languages. Was my comment about C++'s syntax incorrect or
irrelevant? The second bit was a joke.

You're the second person to bring this up; I thought you were against
people attempting to police unmoderated groups.

[Scott Lurndal]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:
>On 4/9/2018 2:08 PM, Scott Lurndal wrote:
>> "Rick C. Hodgin" <rick.c...@gmail.com> writes:
>>> On 4/9/2018 1:50 PM, Öö Tiib wrote:
>>>> To my knowledge ASCII is encoding that has only 7-bit characters.
>>>
>>> ASCII and extended-ASCII. I grew up in the DOS days, and ASCII was
>>> all 256 characters.
>>
>> "Extended ASCII (EASCII or high ASCII) character encodings are
>> eight-bit or larger encodings that include the standard seven-bit
>> ASCII characters, plus additional characters. The use of the term
>> is sometimes criticized,[1][2][3] because it can be mistakenly
>> interpreted to mean that the ASCII standard has been updated to
>> include more than 128 characters or that the term unambiguously
>> identifies a single encoding, neither of which is the case."
>
>
>I'll re-write it for you:
>
> I grew up in the DOS days, and "ASCII" was all 256 characters.
>
>Better?

No, wrong is still wrong.

>
>Even to this day all video cards still come with support for the
>256 character set from back then. There are 8-scan line forms,
>14-scan line forms, and 16-scan line forms, among others.

So what? Backwards compatability is de rigour for modern
hardware, so they can still run obsolete software like windows
and DOS. Doesn't make it any form of standard, nor should
any new software adopt it in place of rational, well-considered
and universally supported standards like Unicode and encodings
such as UTF-8.

[Rick C. Hodgin]

On 4/9/2018 3:08 PM, Scott Lurndal wrote:
> "Rick C. Hodgin" <rick.c...@gmail.com> writes:
>> On 4/9/2018 2:08 PM, Scott Lurndal wrote:
>>> "Rick C. Hodgin" <rick.c...@gmail.com> writes:

>>>> On 4/9/2018 1:50 PM, Öö Tiib wrote:
>>>>> To my knowledge ASCII is encoding that has only 7-bit characters.
>>>>
>>>> ASCII and extended-ASCII. I grew up in the DOS days, and ASCII was
>>>> all 256 characters.
>>>
>>> "Extended ASCII (EASCII or high ASCII) character encodings are
>>> eight-bit or larger encodings that include the standard seven-bit
>>> ASCII characters, plus additional characters. The use of the term
>>> is sometimes criticized,[1][2][3] because it can be mistakenly
>>> interpreted to mean that the ASCII standard has been updated to
>>> include more than 128 characters or that the term unambiguously
>>> identifies a single encoding, neither of which is the case."
>>
>>
>> I'll re-write it for you:
>>
>> I grew up in the DOS days, and "ASCII" was all 256 characters.
>>
>> Better?
>
> No, wrong is still wrong.

I identified it above as "ASCII and extended-ASCII" correctly. My
use of quotes indicates "that's what we all (all of the DOS-based
developers I knew at that time) called ASCII."

You're just nitpicking. I know ASCII is only the lower 128 chars.
I know Extended-ASCII is the upper 128. I grew up in an environment
where we called that ASCII because every DOS-based computer had that
full set baked into it (in CGA), and by default in EGA/VGA, and to
this day it remains.

>> Even to this day all video cards still come with support for the
>> 256 character set from back then. There are 8-scan line forms,
>> 14-scan line forms, and 16-scan line forms, among others.
>
> So what? Backwards compatability is de rigour for modern
> hardware, so they can still run obsolete software like windows
> and DOS. Doesn't make it any form of standard, nor should
> any new software adopt it in place of rational, well-considered
> and universally supported standards like Unicode and encodings
> such as UTF-8.

Why do my goals and methods affect you, Scott? If I choose to
move in this way, designing a whole new system from the ground
up, how are you impacted? What difference do my efforts make in
your life when I'm over here, and you're over there?

--
Rick C. Hodgin

[Mr Flibble]

The fractal wrongness continues unabated.

https://www.google.co.uk/search?q=fractal+wrongness&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiEvJb_9a3aAhUKKMAKHY8XDwMQ_AUICigB&biw=1547&bih=672&dpr=2.25

[Rick C. Hodgin]

On 4/9/2018 3:26 PM, Mr Flibble wrote:
> https://www.google.co.uk/search?q=fractal+wrongness&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiEvJb_9a3aAhUKKMAKHY8XDwMQ_AUICigB&biw=1547&bih=672&dpr=2.25


LOL! Remember this day also, Leigh. :-)

--
Rick C. Hodgin

[Chris M. Thomasson]

On 4/9/2018 7:40 AM, Rick C. Hodgin wrote:

> On Monday, April 9, 2018 at 10:28:22 AM UTC-4, Rick C. Hodgin wrote:
>> On Monday, April 9, 2018 at 10:09:15 AM UTC-4, Mr Flibble wrote:

[...]
> One other thing ... the vision I've had is to create a complete
> computer system from hardware to operating system to drivers to
> compilers to user apps, all as an offering to Jesus rather than
> to self

Would you flip out if Jesus totally passed on your vision? Remember what
happened to Cain...

[...]

[Chris M. Thomasson]

On 4/9/2018 8:29 AM, Mr Flibble wrote:
> On 09/04/2018 16:25, Rick C. Hodgin wrote:
>> On Monday, April 9, 2018 at 11:19:03 AM UTC-4, Mr Flibble wrote:
>>> On 09/04/2018 16:10, Rick C. Hodgin wrote:
>>>> On 4/9/2018 11:01 AM, Mr Flibble wrote:
>>>>> On 09/04/2018 15:51, Rick C. Hodgin wrote:
>>>>>> I can teach you how to do it if you like.
>>>>>
>>>>> Based on all previous interactions it is higly unlikely that you can
>>>>> teach me anything either on theology or software engineering.
>>>>
>>>> There is a lot I could teach you if you were willing to learn.
>>>
>>> Wrong. There is nothing that you can teach me and I base this assertion
>>> on the fractal wrongness nature of all of your posts so far.
>>
>>
>> I could also learn a lot from you, Leigh.  God made us to be stronger
>> together than we are in isolation and apart.  It's why He gave each of
>> us our several abilities, but not all abilities to each of us wholly.
>>
>> He wanted us to come together and help one another, to form communities
>> and grow and share and learn together, as I imagine that is what Heaven
>> is going to be like, and it's a precursor view here in our limited and
>> (currently) tangible form.
>>
>> You are a most capable developer, Leigh.  You would be a great addition
>> to the hardware and software project I am working on.  You could do a
>> great many things I either couldn't do, or would be worse at than you
>> are.
>>
>> We would be stronger together than we are apart.
>
> I would rather stick pins in my eyes.

You forgot to add salt and concentrated lemon juice. ;^)

[bartc]

That's the wrong approach IMO.

It means you can't look at a fragment of code and know what it means. Or
email or post code without also explaining what settings are intended.
Or copy & paste code between files which use different settings.

As it is, it will already look like C or C++ (or anything with braces
for that matter). It needs to have a strong identity of its own.

But, it's your project.

--
bartc

[Rick C. Hodgin]

On Monday, April 9, 2018 at 7:41:41 PM UTC-4, bartc wrote:
> On 09/04/2018 17:30, Rick C. Hodgin wrote:
> > On 4/9/2018 12:25 PM, bartc wrote:
>
> >> If you need compatibility, do something like this:
> >>
> >>          CWhatever *a, b;        // old rules, one pointer
> >>      var CWhatever *a, b;        // new rules, two pointers
> >>
> >> and use the new form until the old can be deprecated. Then you can
> >> drop the 'var'. And not need to rely on white space to alter meaning.
> >
> >
> > I seek to provide compatibility with C, and incorporate some of C++'s
> > features, as they are into CAlive.  I require switches to be enabled
> > to default to CAlive's syntax, which can either be instance settings,
> > #pragmas, or command line switches.  Other new features do not break
> > backward compatibility and are enabled by default.
>
> That's the wrong approach IMO.
>
> It means you can't look at a fragment of code and know what it means. Or
> email or post code without also explaining what settings are intended.
> Or copy & paste code between files which use different settings.

I have a large code base that I've written over decades. I plan to
fully support my own code base. And I eventually want to provide
full C90 and C99 support so that people who have C code today can
switch to CAlive and make the migration in stages.

> As it is, it will already look like C or C++ (or anything with braces
> for that matter). It needs to have a strong identity of its own.
>
> But, it's your project.

I appreciate your input. I've given this a lot of thought. It's
not an idle or rash decision.

I think C is an amazing language. I think C++ added tremendously
valuable extensions, but went way too far. CAlive is an attempt
to combine some of those extensions to C, to remove some of C's
limitations, to take a different view of data through strict
typing by variable, but easy of transformation through union-like
constructs. I also have new ideas I want to incorporate.

Time will tell. It's a large project and I can't find anyone to
help me. So, it will take time and effort over years.

--
Rick C. Hodgin

[Chris M. Thomasson]

On 4/9/2018 4:54 PM, Rick C. Hodgin wrote:
> On Monday, April 9, 2018 at 7:41:41 PM UTC-4, bartc wrote:
>> On 09/04/2018 17:30, Rick C. Hodgin wrote:
>>> On 4/9/2018 12:25 PM, bartc wrote:
>>
>>>> If you need compatibility, do something like this:
>>>>
>>>>          CWhatever *a, b;        // old rules, one pointer
>>>>      var CWhatever *a, b;        // new rules, two pointers
>>>>
>>>> and use the new form until the old can be deprecated. Then you can
>>>> drop the 'var'. And not need to rely on white space to alter meaning.
>>>
>>>
>>> I seek to provide compatibility with C, and incorporate some of C++'s
>>> features, as they are into CAlive.  I require switches to be enabled
>>> to default to CAlive's syntax, which can either be instance settings,
>>> #pragmas, or command line switches.  Other new features do not break
>>> backward compatibility and are enabled by default.
>>
>> That's the wrong approach IMO.
>>
>> It means you can't look at a fragment of code and know what it means. Or
>> email or post code without also explaining what settings are intended.
>> Or copy & paste code between files which use different settings.
>
> I have a large code base that I've written over decades. I plan to
> fully support my own code base. And I eventually want to provide
> full C90 and C99 support so that people who have C code today can
> switch to CAlive and make the migration in stages.

Just a quick high level idea that can get your work out there:

Get a server.

Put a little websever on it.

Put your compiler on it.

Create a HTML based front end.

Send code generated from the webpage to the webserver.

Send the code from the webserver to the compiler.

Compile it; run it.

Send generated output to the user viewing the webpage.

You surly have something that can compile a hello world program right?

[Rick C. Hodgin]

On Monday, April 9, 2018 at 7:59:49 PM UTC-4, Chris M. Thomasson wrote:
> Just a quick high level idea that can get your work out there:
> Get a server.
> Put a little websever on it.
> Put your compiler on it.

> Create a HTML based front end...

You've mentioned this several times. So you'll stop posting about
it, know that I will never do this. It has no part of any desire
of my goals. CAlive uses a new ABI and is designed to work with a
developer during development. It does not simply run or fail as
other code does. A CAlive program with errors will compile and run
until it reaches the error code, then it will enter a new state
called an inquiry.

When it is completed and released publicly, you can study it if
you want to. Until then ... please stop requesting that I do this
thing you desire. I will never do it.

--
Rick C. Hodgin

[Chris M. Thomasson]

On 4/9/2018 5:21 PM, Rick C. Hodgin wrote:
> On Monday, April 9, 2018 at 7:59:49 PM UTC-4, Chris M. Thomasson wrote:
>> Just a quick high level idea that can get your work out there:
>> Get a server.
>> Put a little websever on it.
>> Put your compiler on it.
>> Create a HTML based front end...
>
> You've mentioned this several times. So you'll stop posting about
> it, know that I will never do this. It has no part of any desire
> of my goals.

It can help get it out there.

> CAlive uses a new ABI and is designed to work with a
> developer during development. It does not simply run or fail as
> other code does. A CAlive program with errors will compile and run
> until it reaches the error code, then it will enter a new state
> called an inquiry.

This can all be accomplished by creating a compatible debugging GUI in
HTML5.

> When it is completed and released publicly, you can study it if
> you want to. Until then ... please stop requesting that I do this
> thing you desire. I will never do it.

Okay. Well, can you show us a simple hello world program in CAlive right
now?

[Rick C. Hodgin]

On Monday, April 9, 2018 at 8:41:25 PM UTC-4, Chris M. Thomasson wrote:
> On 4/9/2018 5:21 PM, Rick C. Hodgin wrote:
> > On Monday, April 9, 2018 at 7:59:49 PM UTC-4, Chris M. Thomasson wrote:
> >> Just a quick high level idea that can get your work out there:
> >> Get a server.
> >> Put a little websever on it.
> >> Put your compiler on it.
> >> Create a HTML based front end...
> >
> > You've mentioned this several times. So you'll stop posting about
> > it, know that I will never do this. It has no part of any desire
> > of my goals.
>
> It can help get it out there.

I don't have a goal to "get it out there." I have a goal to design
and code it right, and let the tool's own merits speak for itself,
allowing people who have come to use it to tell other people about
it.

> > CAlive uses a new ABI and is designed to work with a
> > developer during development. It does not simply run or fail as
> > other code does. A CAlive program with errors will compile and run
> > until it reaches the error code, then it will enter a new state
> > called an inquiry.
>
> This can all be accomplished by creating a compatible debugging GUI in
> HTML5.

Yes. I have no interest and will never do it.

> > When it is completed and released publicly, you can study it if
> > you want to. Until then ... please stop requesting that I do this
> > thing you desire. I will never do it.
>
> Okay. Well, can you show us a simple hello world program in CAlive right
> now?

I am not here to cater to your whims, Chris. When the product is
released you'll be able to download it, source code and all, and
examine it fully.

--
Rick C. Hodgin

[David Brown]

On 09/04/18 18:25, bartc wrote:
> On 09/04/2018 14:51, Rick C. Hodgin wrote:
>> On 4/9/2018 9:10 AM, bartc wrote:
>>> On 09/04/2018 13:48, Rick C. Hodgin wrote:
>>>> Has there ever been a proposal to the C++ standards committee to have
>>>> something like this:
>>>>
>>>> 01: CWhatever *a, b;
>>>> 02: CWhatever* a, b;
>>>>
>>>> 01 produce a pointer to an instance of CWhatever in a, and it
>>>> allocates an actual CWhatever for b, while the declaration in
>>>> 02 to produce pointers to instances of CWhatever for both a
>>>> and b?
>>>>
>>>
>>> So, C++ syntax isn't complicated or ambiguous enough, it's necessary
>>> to make white space significant?
>>
>> I think both 01 and 02 above producing the same declarations is very
>> confusing. It's burned me a few times when I've looked at code, or
>> gone to create new variables.
>
> This syntax comes from C, which C++ unwisely adopted (I believe in the
> interests of improving take-up of the language which would have been
> harder with an incompatible new syntax).
>

It would have been better if it had never been possible to mix a type
and pointers to the type in a single declaration in C. But since C had
it, C++ had no choice about how to interpret the same code.

What would have been possible in C++ would be to deprecate the mixture -
allowing either "int a, b;" or "int *a, *b;" but giving an error for
"int a, *b;" or "int *a, b;" regardless of white space positioning.

> It's been done like that for coming up to half a century, but according
> to the experts on comp.lang.c, it's not a problem at all provided you
> use the right tools, use the right guidelines (one declaration per line)
> and learn C properly so you that will know that the example declares one
> pointer only.
>

People make mistakes with this sort of thing, and it would have been
better (IMHO) if mixing types and pointers in one declaration had never
been allowed in C (or C++). But it is not a /problem/ - if you don't
make such mixes, you don't get it wrong. And if you /do/ get it wrong,
you will almost certainly get an error somewhere in the code when you
use the variables.

/Problems/ come when there are mistakes you can easily make that are
hard to spot, hard to avoid despite good coding rules, and which are not
easily detected automatically by tools. There are plenty of /real/
problem areas in C - you don't need to invent them out of things that
are simply not as nice as they could have been.

> But as you say, you can do all that and still get tripped up. It could
> even, if you've mistyped and CWhatever is the name of a variable rather
> than a type, end up writing an expression that multiplies CWhatever by
> a, then yields the value b.

First, however, you will have had an expression that assigns a value to
a or b - that will always come before the use of the variable. And that
assignment is generally going to be a syntax error unless you are
over-zealous with casting.

There will be occasions where both T and T* types are valid, but they
are rare.

>
>> My C-like language operates that way.
>
> If this is a new language, why repeat the mistake of C++ and try and
> have compatible syntax? Do something obviously new rather than
> perpetuating design errors from 50 years ago.

Agreed.

>
> If you need compatibility, do something like this:
>
> CWhatever *a, b; // old rules, one pointer
> var CWhatever *a, b; // new rules, two pointers
>

Disagreed.

> and use the new form until the old can be deprecated. Then you can drop
> the 'var'. And not need to rely on white space to alter meaning.
>

Strongly disagreed - making a significant change in the interpretation
would be crazy.

Try this:

CWhatever *a, b;
-> Warning - mixing types and pointers is deprecated in "C mode"
-> Error - mixing types and pointers is not allowed in "CAlive mode"

The alternative is to use a noticeably different syntax to avoid the
possibility of errors or confusion. For example:

var CWhatever : a, b; // not pointers
var CWhatever* : a, b; // both pointers
var CWhatevr : *a, b; // syntax error

[David Brown]

On 09/04/18 16:47, Rick C. Hodgin wrote:
> On 4/9/2018 10:23 AM, Bo Persson wrote:
>> And even if we were to define those examples, we would then have to
>> consider the meaning of
>>
>> 03: CWhatever * a, b;
>> 04: CWhatever*a,b;
>>
>> And now we are closing in on madness.
>
> In my opinion, two warnings are issued:
>
> 03 -- "ambiguous declaration, assuming type CWhatever* for a,
> CWhatever for b."
>
> 04 -- "ambiguous declaration, assuming type CWhatever* for a, b."
>
> And any alternate uses of those types would produce relative errors,
> with the diagnostic there to aid in discovery / recovery.
>

Declarations like this should not be ambiguous, but clearly defined by
the language. Having warnings (or even error messages) here is a good
thing, but I would have something like "mixed declaration" rather than
"ambiguous declaration".

[Kenny McCormack]

In article <pai39g$bbl$1...@dont-email.me>,
David Brown <david...@hesbynett.no> wrote:
...

>What would have been possible in C++ would be to deprecate the
>mixture - allowing either "int a, b;" or "int *a, *b;" but giving
>an error for "int a, *b;" or "int *a, b;" regardless of white space
>positioning.

Except that it would break existing code...

--
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

[Öö Tiib]

On Tuesday, 10 April 2018 13:22:52 UTC+3, David Brown wrote:
>
> It would have been better if it had never been possible to mix a type
> and pointers to the type in a single declaration in C. But since C had
> it, C++ had no choice about how to interpret the same code.
>
> What would have been possible in C++ would be to deprecate the mixture -
> allowing either "int a, b;" or "int *a, *b;" but giving an error for
> "int a, *b;" or "int *a, b;" regardless of white space positioning.

Isn't it about way more things than just type and pointers to type in mix?
I think that is "well-formed" C++ code:

int *a, b, c(long x), d[5];

In real C++ code bases it is getting irrelevant because raw arrays
are rarely used and raw pointers are rarely used and lot of coding
standards forbid to declare more than one thing per declaration.

[David Brown]

On 10/04/18 12:49, Kenny McCormack wrote:
> In article <pai39g$bbl$1...@dont-email.me>,
> David Brown <david...@hesbynett.no> wrote:
> ...
>> What would have been possible in C++ would be to deprecate the
>> mixture - allowing either "int a, b;" or "int *a, *b;" but giving
>> an error for "int a, *b;" or "int *a, b;" regardless of white space
>> positioning.
>
> Except that it would break existing code...
>

Yes - it would have been another incompatibility between C and C++.
There has always been a number of C constructs that are not compatible
with C++. It would have caused few issues with "real" C++ code, since
there is much more of a tendency to initialise variables when they are
declared, and therefore there are rarely many of them declared on each
line. But it would have cause issues with existing C code - ones that
would be easily found (from compiler error messages) and easily fixed.

[David Brown]

On 10/04/18 13:27, Öö Tiib wrote:
> On Tuesday, 10 April 2018 13:22:52 UTC+3, David Brown wrote:
>>
>> It would have been better if it had never been possible to mix a type
>> and pointers to the type in a single declaration in C. But since C had
>> it, C++ had no choice about how to interpret the same code.
>>
>> What would have been possible in C++ would be to deprecate the mixture -
>> allowing either "int a, b;" or "int *a, *b;" but giving an error for
>> "int a, *b;" or "int *a, b;" regardless of white space positioning.
>
> Isn't it about way more things than just type and pointers to type in mix?

Yes - T and T* are just an example.

> I think that is "well-formed" C++ code:
>
> int *a, b, c(long x), d[5];

You can get a lot worse than that (you can throw in some function
declarations, typedefs, etc.), but such mixes are fortunately rare in
real code - even in C code without coding standards.

[bartc]

Why don't more people who write coding standards design language syntax?
They seem to have more sense.

--
bartc

[Rick C. Hodgin]

My view is, in certain cases such as this declaration extension, spaces
could and should serve as delineators. It would simplify code by making
the one left-side declaration, allowing everything on the right to be
of that type. It would remove the need for the existing pointer declar-
ation syntax which can be prickly, and it would not break existing code
because the new form would have to be enabled to be used.

-----
CAlive also takes a different view on how to declare pointers so they
are more visual:

CWhatever [pointer], instance;

By declaring a token name in brackets, it makes it a pointer. You can
also declare a pointer to a pointer:

CWhatever [[pointer_to_pointer]];

And when you go to reference them in code (you can do this using also
the dot form because CAlive makes . and -> synonymous, and also allows
instances of --> or ---> to be the same as -> for alignment):

CWhatever [p], [[pp]]; // Same as CWhatever* p; CWhatever** pp;

p.member; // Access p->member using .
pp = &p;
[pp].member; // Same as (*pp)->member, again using .

It's a nod to assembly language, which uses [reg] for indirection,
and an extension of that syntax to [[pp]] for double-indirection.

But, that's neither here nor there. The people who choose to use
CAlive when it's completed will do so for many reasons, not just
declaration or pointer syntax. Mostly for its LiveCode ABI, the
inclusion of the simple class, and enhanced exception handling,
would be my estimation.

--
Rick C. Hodgin

[Mr Flibble]

On 10/04/2018 01:21, Rick C. Hodgin wrote:
> On Monday, April 9, 2018 at 7:59:49 PM UTC-4, Chris M. Thomasson wrote:
>> Just a quick high level idea that can get your work out there:
>> Get a server.
>> Put a little websever on it.
>> Put your compiler on it.
>> Create a HTML based front end...
>
> You've mentioned this several times. So you'll stop posting about
> it, know that I will never do this. It has no part of any desire
> of my goals. CAlive uses a new ABI and is designed to work with a
> developer during development. It does not simply run or fail as
> other code does. A CAlive program with errors will compile and run
> until it reaches the error code, then it will enter a new state
> called an inquiry.

So what you are saying is that the CAlive compiler requires a human
presence so it cannot be used with an automated build system for
example? This and the ridiculous whitespace thing that would be better
solved by an error if different types are present in a multi-variable
declaration just confirms what I said in my other post: your software is
toy as it is next to useless as it doesn't sit well with modern well
established software development practices.

[Rick C. Hodgin]

On 4/10/2018 8:26 AM, Mr Flibble wrote:
> On 10/04/2018 01:21, Rick C. Hodgin wrote:
>> On Monday, April 9, 2018 at 7:59:49 PM UTC-4, Chris M. Thomasson wrote:
>>> Just a quick high level idea that can get your work out there:
>>> Get a server.
>>> Put a little websever on it.
>>> Put your compiler on it.
>>> Create a HTML based front end...
>>
>> You've mentioned this several times.  So you'll stop posting about
>> it, know that I will never do this.  It has no part of any desire
>> of my goals.  CAlive uses a new ABI and is designed to work with a
>> developer during development.  It does not simply run or fail as
>> other code does.  A CAlive program with errors will compile and run
>> until it reaches the error code, then it will enter a new state
>> called an inquiry.
>
> So what you are saying is that the CAlive compiler requires a human
> presence so it cannot be used with an automated build system for
> example?

No. CAlive will compile fully automated. It has default handlers
for inquiry conditions which mimic terminate-early / abort functions,
after saving some information about the inquiry state to disk.

Developers can also write their own inquiry() functions, which will
handle inquiry conditions.

CAlive is part of a framework being created which supports it, called
RDC (Rapid Development Compiler). It's designed (initially) to be a
fast source code development tool. You code, run, get to an inquiry
state, code more, resume, all while running the actual binary.

This feature was designed for me as I make many coding mistakes when
writing source code, nearly all of which do not represent my thoughts,
but are due to mistakes in translation from thought to fingers. And
I'm absolutely amazed at some of the mis-translations that occur. I
can go to write a particular word, and a word that merely sounds like
it, but is spelled completely differently, can come out. I sit there
at times saying out loud, "Wow!"

> This and the ridiculous whitespace thing that would be better
> solved by an error if different types are present in a multi-variable
> declaration

CAlive already has defined the use of CWhatever* as a type, and will
use that across the line when in CAlive mode. When in compatibility
mode, it will work as it does today. It's an extension, Leigh, not
the end of the world.

> just confirms what I said in my other post: your software is
> toy as it is next to useless as it doesn't sit well with modern well
> established software development practices.

You don't have to use it, Leigh. My feeling won't be hurt. CAlive
should not impact or affect you in the slightest.

--
Rick C. Hodgin

[Scott Lurndal]

=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes:

>Isn't it about way more things than just type and pointers to type in mix?
>I think that is "well-formed" C++ code:
>
> int *a, b, c(long x), d[5];
>
>In real C++ code bases it is getting irrelevant because raw arrays
>are rarely used and raw pointers are rarely used and lot of coding
>standards forbid to declare more than one thing per declaration.

What's a "real C++ code base"? We've several million lines of
actively developed C++ code that uses raw arrays and raw pointers.

[David Brown]

Language designers are aiming for flexibility - let programmers use the
language the way they want, for the tasks they want. Coding standards
authors are aiming to restrict those freedoms, often in a manner that
depends on the task in hand. A coding standard suitable for
small-systems embedded design would be useless for general purpose "big
computer" programming, and vice versa. And of course people have wildly
different ideas of what is good coding practice and clear presentation.

C was designed with a "trust the programmer" philosophy. That has let
the language be used in far more areas than were originally envisioned
by the designers. But it also means the programmer has to be more
responsible, because the language won't stop them writing a mess.

[David Brown]

I can't tell you what Öö thinks is "real C++", but I'd guess that in
your "real C++ code base" you don't declare variables of type T and T*
in the same line.

[David Brown]

I think it is fine to say that the type (including the pointer bit) has
to be on the left, separated by a space. I merely think you should
avoid there being ambiguity here - the declarations should be clearly
one thing, clearly the other thing, or an error. (C compatible mode
excluded, of course.)

>
> -----
> CAlive also takes a different view on how to declare pointers so they
> are more visual:
>
> CWhatever [pointer], instance;
>
> By declaring a token name in brackets, it makes it a pointer. You can
> also declare a pointer to a pointer:
>
> CWhatever [[pointer_to_pointer]];
>
> And when you go to reference them in code (you can do this using also
> the dot form because CAlive makes . and -> synonymous, and also allows
> instances of --> or ---> to be the same as -> for alignment):
>
> CWhatever [p], [[pp]]; // Same as CWhatever* p; CWhatever** pp;
>

This is all getting back to the same confusion - and then making it worse.

Pick /one/ method for declaring pointers. It does not really matter if
that is "CWhatever* p", "CWhatever [p]", "CWhatever^ p", "pointer to
CWhatever p". But the key thing is to have a single clear and
unambiguous syntax.

What you don't want is for some people to be writing "CWhatever* p",
others to be writing "CWhatever [p]", and neither being able to
understand the other's code because they never use that syntax themselves.

And don't allow mixing different levels of pointedness in the same
declaration. It is not needed, and just makes code harder to follow.


One thing you should also try to decide upon is how you view pointer and
types. For "int * p;", the usual C philosophy is "*p is an int -
therefore you write int *p", while the usual C++ philosophy is "p is of
type pointer-to-int - therefore you write int* p". Both C and C++
conflate these concepts but they have a bias towards one of them. In
designing a new language, I would aim to view it from one side.
Personally, I'd chose the "p is of type pointer-to-int", but a syntax
like "int [p]" matches the C idea better. It is up to you to choose one.


You should also think about initialisation syntaxes. A strange thing
about C is that when you write:

int x;
int *p = &x;

you are assigning to /p/, not to "*p". If you wrote "*p = &x" later, it
would be an error.

I can't see any neat way to have initialisation with declarations of the
form "int [p]".


So I would prefer to have the pointer as part of the type, and choose a
syntax that does not match C in order to avoid misunderstanding - such as:

int^ p = &x;

> p.member; // Access p->member using .
> pp = &p;
> [pp].member; // Same as (*pp)->member, again using .
>
> It's a nod to assembly language, which uses [reg] for indirection,
> and an extension of that syntax to [[pp]] for double-indirection.

Different assembly languages use different syntaxes. There is nothing
wrong with using [p] for indirection, taking inspiration from Intel
format x86 assembly, but don't imagine it is universal in assembly.

Just don't give multiple optional syntaxes.

And be careful about automatically dereferencing pointers to structs or
objects - it can be confusing. In Delphi (which is based on Object
Pascal), objects are mostly pointers that are automatically
dereferenced, but not always - it can be difficult to track which is
which. Consider copying C++'s concepts of references and pointers.
Consider also the possibility of disbanding pointers altogether, and
working /only/ with references.

[Rick C. Hodgin]

On Tuesday, April 10, 2018 at 9:36:55 AM UTC-4, David Brown wrote:
> This is all getting back to the same confusion - and then making it
> worse.

I disagree wholeheartedly, though I'm certain I'm in the minority
here in the C++ group.

--
Rick C. Hodgin

[Rick C. Hodgin]

One other thing: CAlive supports traditional C/C++ syntax. Nobody
has to use any of these new features I am adding. They exist as one
more tool in the toolbox, able to be used for those who see value in
that tool.

--
Rick C. Hodgin

[Scott Lurndal]

As a general rule, you're correct, variables are declared one per line.

[Scott Lurndal]

David Brown <david...@hesbynett.no> writes:
>On 10/04/18 14:11, Rick C. Hodgin wrote:

>> -----
>> CAlive also takes a different view on how to declare pointers so they
>> are more visual:
>>
>> CWhatever [pointer], instance;
>>
>> By declaring a token name in brackets, it makes it a pointer. You can
>> also declare a pointer to a pointer:
>>
>> CWhatever [[pointer_to_pointer]];
>>
>> And when you go to reference them in code (you can do this using also
>> the dot form because CAlive makes . and -> synonymous, and also allows
>> instances of --> or ---> to be the same as -> for alignment):
>>
>> CWhatever [p], [[pp]]; // Same as CWhatever* p; CWhatever** pp;
>>
>
>This is all getting back to the same confusion - and then making it worse.
>
>Pick /one/ method for declaring pointers. It does not really matter if
>that is "CWhatever* p", "CWhatever [p]", "CWhatever^ p", "pointer to
>CWhatever p". But the key thing is to have a single clear and
>unambiguous syntax.
>

Or you can be more verbose:

08050000 ssp_initialize
08054000PROC;
08055000SHARES
08056000 CONST loader_storage,
08057000 CONST mcp_identification,
08058000 CONST pointer_reference_table,
08059000 VAR queue_storage,
08060000 CONST shared_systems_data;
08061000
08062000VAR
08063000 base_ptr DAT_POINTER := ioat_ptrs.first_element,
08064000 ch_ptr PTR TO CHANNEL_TABLE_ENTRY := nil,
08065000 search_done BOOLEAN := false,
08066000 status_buffer SSP_STATUS,
08067000 status_ptr PTR TO SSP_STATUS := ptr( status_buffer );
08068000
08069000
08070000
08071000 DO
08072000 FIND ioat_ptr OVER base_ptr..ioat_ptrs.last_element
08073000 INTO ioat_ptrs.base @
08074000 WHERE ioat_ptr@.primary_hardware_type = shared_system_processor
08075000 THEN
08076000 ch_ptr := ptr( channel_table_ptrs.base @
08077000 [ioat_ptr @.primary_channel_number] );
08078000 ch_ptr @.flags.good_firmware_file := false;
...

Declarations are obvious "PTR TO <type>" and
dereferences are visible (@).

[bartc]

On 10/04/2018 14:36, David Brown wrote:
> On 10/04/18 14:11, Rick C. Hodgin wrote:

> I can't see any neat way to have initialisation with declarations of the
> form "int [p]".
>
>
> So I would prefer to have the pointer as part of the type, and choose a
> syntax that does not match C in order to avoid misunderstanding - such as:
>
> int^ p = &x;

That's getting on the right lines, depending on dereference syntax. If
it's now ^p, then you have the same problem.

(Elsewhere I write types strictly left-to-right, with a variable name
following if this is a declaration:

ref int p := &a
ref int p; p := &a

The difference between assignment and declaration/initialisation of one
variable, is simply that type spec stuck on the left. And the
left-to-right form allows building of complex types more naturally in a
way that exactly follows the English:

ref[]ref int p # pointer to array of pointer to int

The only quibble might be whether you stick the variable before or after
the type, and with what extra syntax.

What you wouldn't do is stick the variable name IN THE MIDDLE of the
type, and even end up splitting the type into THREE PARTS like the
variable 'c' here:

int a,b, *c[10];

So you have the 'int', '*', and '[10]' all in different places with
respect to the variable name. If someone were to invent this syntax now,
you'd think they were having a laugh.

And if that wasn't enough, if the parts are numbered 1, 2 and 3, you
have to rearrange them as 3, 2, 1 to read off the type, or as 2, 3, 1 if
it was (*c)[10].)

>
>> p.member; // Access p->member using .
>> pp = &p;
>> [pp].member; // Same as (*pp)->member, again using .
>>
>> It's a nod to assembly language, which uses [reg] for indirection,
>> and an extension of that syntax to [[pp]] for double-indirection.
>
> Different assembly languages use different syntaxes. There is nothing
> wrong with using [p] for indirection, taking inspiration from Intel
> format x86 assembly, but don't imagine it is universal in assembly.

This is recycling the C (and now also C++) idea of declaration syntax
having to mirror expression syntax, which leads to the situation I
mentioned above.

How about, just keeping it simple:

TYPE NAME

or, declaring several names with exactly the same type wouldn't be
objectionable:

TYPE NAME, NAME, NAME

And not STILL having part of the type syntax that wraps itself around name.

--
bartc

[Ben Bacarisse]

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

> On 10/04/18 13:27, 嘱 Tiib wrote:
>> On Tuesday, 10 April 2018 13:22:52 UTC+3, David Brown wrote:
>>>
>>> It would have been better if it had never been possible to mix a type
>>> and pointers to the type in a single declaration in C. But since C had
>>> it, C++ had no choice about how to interpret the same code.
>>>
>>> What would have been possible in C++ would be to deprecate the mixture -
>>> allowing either "int a, b;" or "int *a, *b;" but giving an error for
>>> "int a, *b;" or "int *a, b;" regardless of white space positioning.
>>
>> Isn't it about way more things than just type and pointers to type in mix?
>
> Yes - T and T* are just an example.
>
>> I think that is "well-formed" C++ code:
>>
>> int *a, b, c(long x), d[5];
>
> You can get a lot worse than that (you can throw in some function
> declarations, typedefs, etc.), but such mixes are fortunately rare in
> real code - even in C code without coding standards.

There is a function declaration in there! (You probably meant a pointer
to function, since those start to get more complex.)

I think part of the trouble is that so many people learn C "by
example". And when coding standards say you should put only one
declaration on a line there's no incentive to learn.

Because I know that the * is part of little expression-like syntax that
revolves around the name being declared, I can't stand seeing

char* x;

It really grates. It looks like

return! x;
or
return x +1;

to me.

Given that this is comp.lang.c++ it's worth noting that such derived
types are rare in programs that use the standard library so it's often
much less of an issue.

>> In real C++ code bases it is getting irrelevant because raw arrays

>> are rarely used and raw pointers are rarely used...

Oh, snap!

--
Ben.

[David Brown]

On 10/04/18 16:29, Ben Bacarisse wrote:
> David Brown <david...@hesbynett.no> writes:
>
>> On 10/04/18 13:27, 嘱 Tiib wrote:
>>> On Tuesday, 10 April 2018 13:22:52 UTC+3, David Brown wrote:
>>>>
>>>> It would have been better if it had never been possible to mix a type
>>>> and pointers to the type in a single declaration in C. But since C had
>>>> it, C++ had no choice about how to interpret the same code.
>>>>
>>>> What would have been possible in C++ would be to deprecate the mixture -
>>>> allowing either "int a, b;" or "int *a, *b;" but giving an error for
>>>> "int a, *b;" or "int *a, b;" regardless of white space positioning.
>>>
>>> Isn't it about way more things than just type and pointers to type in mix?
>>
>> Yes - T and T* are just an example.
>>
>>> I think that is "well-formed" C++ code:
>>>
>>> int *a, b, c(long x), d[5];
>>
>> You can get a lot worse than that (you can throw in some function
>> declarations, typedefs, etc.), but such mixes are fortunately rare in
>> real code - even in C code without coding standards.
>
> There is a function declaration in there! (You probably meant a pointer
> to function, since those start to get more complex.)

Let's assume that's what I meant, rather than simply failing to read
properly :-)

>
> I think part of the trouble is that so many people learn C "by
> example". And when coding standards say you should put only one
> declaration on a line there's no incentive to learn.
>

I don't think it is a matter of not learning - I know fine how things
work when you have multiple declarations in one line. But mixing
concepts together too tightly is never a good idea for clarity.

I also think your declarations mostly either have expressive (and
therefore somewhat longer) names, a useful comment, an initialiser, or
are so local that they are part of a loop (like "for (int i ..."). The
lines are long enough, and contain enough information, that one
declaration at a time is a good size.

There are exceptions, of course.

> Because I know that the * is part of little expression-like syntax that
> revolves around the name being declared, I can't stand seeing
>
> char* x;

To me, that is putting the emphasis on x being a pointer-to-char. I
tend to write "char * x;" myself, as I would usually want an initialisation:

char * x = &b;

I dislike seeing :

char *x = &b;

because "*x = &b;" would be wrong after the declaration and initialisation.

>
> It really grates. It looks like
>
> return! x;
> or
> return x +1;
>
> to me.

Those two would really annoy me too.

[David Brown]

On 10/04/18 16:20, bartc wrote:
> On 10/04/2018 14:36, David Brown wrote:
>> On 10/04/18 14:11, Rick C. Hodgin wrote:
>
>> I can't see any neat way to have initialisation with declarations of the
>> form "int [p]".
>>
>>
>> So I would prefer to have the pointer as part of the type, and choose a
>> syntax that does not match C in order to avoid misunderstanding - such
>> as:
>>
>> int^ p = &x;
>
> That's getting on the right lines, depending on dereference syntax. If
> it's now ^p, then you have the same problem.
>
> (Elsewhere I write types strictly left-to-right, with a variable name
> following if this is a declaration:
>
> ref int p := &a
> ref int p; p := &a
>
> The difference between assignment and declaration/initialisation of one
> variable, is simply that type spec stuck on the left. And the
> left-to-right form allows building of complex types more naturally in a
> way that exactly follows the English:
>
> ref[]ref int p # pointer to array of pointer to int
>

I'd be inclined to use either keywords or punctuation, rather than a
mixture, but that's just preference. I'd also use more spaces.

> The only quibble might be whether you stick the variable before or after
> the type, and with what extra syntax.

You might also want keywords to say that this is a variable declaration
(or a block of variable declarations) rather than a statement (or block
of statements). Some programming languages require an extra keyword to
declare the identifier as a non-constant variable, which I think is a
good idea - if I were designing a new language, "variables" would be
immutable by default.

>
> What you wouldn't do is stick the variable name IN THE MIDDLE of the
> type, and even end up splitting the type into THREE PARTS like the
> variable 'c' here:
>
> int a,b, *c[10];
>

Well, /you/ wouldn't do it! Clearly some other people are quite happy
with that. In C, the declaration syntax is designed to match the way
the variable is used, rather than to emphasis its type. Since the
language has postfix and prefix operators, both can occur in the
declarations.

If I were making a language, I would probably be using much stronger
typing than in C and with a bigger emphasis on types - thus having the
type entirely before or entirely after the variable name would be natural.

> So you have the 'int', '*', and '[10]' all in different places with
> respect to the variable name. If someone were to invent this syntax now,
> you'd think they were having a laugh.

No, you would not - at least, you would not laugh if you understood
about language design - as distinct from having designed a couple of
simple languages and thinking that they are the only good ways to make a
language.

[Öö Tiib]

I mean't that raw pointers are basically memory addresses that have
pile of unsafe operations only few of what make any sense in context
of particular memory address. C++ can abstract most of that away
without losing any efficiency. So good C++ code should do it and
that leaves rare cases for raw pointers in code base.

The raw array is decaying into that raw pointer in majority of
contexts so result is above described unsafe memory address plus
lost (often vital for optimizations and safety) information.
The std::array is safer, better and more efficient for most usages.
So good C++ code should prefer std::array and that leaves rare
cases for raw array in C++ code base.

[bartc]

On 10/04/2018 16:05, David Brown wrote:

> On 10/04/18 16:20, bartc wrote:

>> The only quibble might be whether you stick the variable before or after
>> the type, and with what extra syntax.
>
> You might also want keywords to say that this is a variable declaration

Yes: 'extra syntax'.

> Well, /you/ wouldn't do it! Clearly some other people are quite happy
> with that. In C, the declaration syntax is designed to match the way
> the variable is used, rather than to emphasis its type.

Which of course is completely wrong.

When you add "*" to "int x" to make it "int * x", you are inserting a
pointer level into the type.

When you add "*" to "x" to make it "*x", you are dereferencing x and
therefore /removing/ a pointer level from the resulting type.

> No, you would not - at least, you would not laugh if you understood
> about language design - as distinct from having designed a couple of
> simple languages

Based on ideas from well-regarded languages such as Algol-68, Pascal and
Ada. Fortunately I hadn't come across C at that point.

> and thinking that they are the only good ways to make a
> language.

The type syntax created in C and inherited by C++ is /not/ a good way of
doing it as evidenced by the numerous ways you can be tripped up (eg.
see this thread), all the guidelines that tell you the ways to avoid the
pitfalls or how to write complex types, and the number of utilities that
exist to explain what a particular type specification even means.

You don't need to be a language design expert to see that.

--
bartc

[Scott Lurndal]

bartc <b...@freeuk.com> writes:

>Based on ideas from well-regarded languages such as Algol-68, Pascal and
>Ada. Fortunately I hadn't come across C at that point.
>
>> and thinking that they are the only good ways to make a
>> language.
>
>The type syntax created in C and inherited by C++ is /not/ a good way of
>doing it as evidenced by the numerous ways you can be tripped up

The type syntax created in C and inherited by C++ _is_ a good way
of doing it as evidenced by the billions of lines of C and C++ code
in existence.

The fact that you refuse to understand the rules, doesn't invalidate them.

[bartc]

On 10/04/2018 18:21, Scott Lurndal wrote:
> bartc <b...@freeuk.com> writes:
>
>> Based on ideas from well-regarded languages such as Algol-68, Pascal and
>> Ada. Fortunately I hadn't come across C at that point.
>>
>>> and thinking that they are the only good ways to make a
>>> language.
>>
>> The type syntax created in C and inherited by C++ is /not/ a good way of
>> doing it as evidenced by the numerous ways you can be tripped up
>
> The type syntax created in C and inherited by C++ _is_ a good way
> of doing it as evidenced by the billions of lines of C and C++ code
> in existence.

I can't see the connection.

Maybe there were no viable alternatives for systems programming that
were just at the right level.

Maybe Unix started to take over the world and /that/ was written in C
and it came with a C compiler and most of the dealings with it had to
involve C or C interfaces.

Maybe there are billions of lines, instead of only hundreds of millions,
/because/ of the type system.

> The fact that you refuse to understand the rules, doesn't invalidate them.

I understand the rules. I just think the syntax is atrocious and many
seem to agree. Even Kernighan & Ritchie acknowledge that in K&R2 where
they say that C has been castigated for the syntax of its declarations,
before going on to present a program to convert C declarations into English.

My preferred syntax doesn't need turning into English because you can
read, write and understand it almost as though it /was/ English. You are
saying it is better if it's not so straightforward?


(This is the type spec that means 'pointer to a void function with no
parameters' in one of my languages:

ref proc # or:
pointer to proc # if you want it more verbose

This is the same thing in C:

void(*)(void)

Enough said...)

--
bartc

[Alf P. Steinbach]

On 10.04.2018 20:47, bartc wrote:
> [snip]

> My preferred syntax doesn't need turning into English because you can
> read, write and understand it almost as though it /was/ English. You are
> saying it is better if it's not so straightforward?
>
>
> (This is the type spec that means 'pointer to a void function with no
> parameters' in one of my languages:
>
>    ref proc                # or:
>    pointer to proc         # if you want it more verbose
>
> This is the same thing in C:
>
>    void(*)(void)
>
> Enough said...)

In C++ you can write

function<void()>

... where `function` is `std::function`, a class from the `<functional>`
header.

For data the standard library does not offer similar practical type
builders (both names and functionality suck), but you can trivially define

template< class Type >
using ptr = Type*;

... and then write e.g.

const ptr<const char> s = "Oh!";

Cheers & hth.,

- Alf

[Chris M. Thomasson]

I am wondering how old Leigh will have to be before he can even think
about trying it out? Just a little example compiler damn it! You can say
it is in a highly limited experimental state, for God's sake. What is
the hello world!

[Chris M. Thomasson]

Afaict, CDead for now.

[Rick C. Hodgin]

On Tuesday, April 10, 2018 at 4:58:00 PM UTC-4, Chris M. Thomasson wrote:
> I am wondering how old Leigh will have to be before he can even think
> about trying it out? Just a little example compiler damn it! You can say
> it is in a highly limited experimental state, for God's sake. What is
> the hello world!

You have demonstrated repeatedly that you do not want to know
the truth. You want only to know the things you already know,
and proceed on the path you're already on. It's the saddest thing
to see in a person.

I cannot help you, Chris.

--
Rick C. Hodgin

[Chris M. Thomasson]

What is the current state of your code? Can it compile a hello world
program or not?

[Chris M. Thomasson]

On 4/9/2018 5:51 PM, Rick C. Hodgin wrote:
> On Monday, April 9, 2018 at 8:41:25 PM UTC-4, Chris M. Thomasson wrote:

>> On 4/9/2018 5:21 PM, Rick C. Hodgin wrote:
>>> On Monday, April 9, 2018 at 7:59:49 PM UTC-4, Chris M. Thomasson wrote:
>>>> Just a quick high level idea that can get your work out there:
>>>> Get a server.
>>>> Put a little websever on it.
>>>> Put your compiler on it.
>>>> Create a HTML based front end...
>>>
>>> You've mentioned this several times. So you'll stop posting about
>>> it, know that I will never do this. It has no part of any desire
>>> of my goals.
>>

>> It can help get it out there.
>
> I don't have a goal to "get it out there."

Why do you continually mention it here?

[Rick C. Hodgin]

I have wanted the ideas I have to be incorporated into C and C++.

I spent a lengthy campaign in 2014 and 2015 attempting to get some
of these ideas added to the C Standard, specifically the addition of
the class and exception handling. Had that happened, I probably
would never have pursued CAlive. But I met nothing but resistence
from everybody, much as I am doing here with you, and it was clear
I was getting nowhere with anybody else, so I decided to move in
2015.

I have a host of projects I am working on. I do not work solely on
any one project. All of my work is publicly available for download
and use by any person for any reason. The license I have is a Public
Domain license with one caveat:

Self-accountability to God that you will keep the source code
open as you received it.

I do not enforce that request, but you are left to yourself and your
relationship with God to honor it or not. There will be no court
cases over those who use it contrary to that desire, but everything
related to compliance or non-compliance will be solely between you
and God.

http://www.libsf.org:8990/projects/LIB/repos/libsf/browse

--
Rick C. Hodgin