Wednesday, April 11, 2018

Digest for comp.lang.c++@googlegroups.com - 25 updates in 2 topics

bartc <bc@freeuk.com>: Apr 11 11:36AM +0100

On 11/04/2018 09:06, Chris M. Thomasson wrote:
> On 4/10/2018 3:01 PM, Rick C. Hodgin wrote:
 
[New 'CAlive' language]
 
> I want to try out some programs in CAlive.
 
As far as I can tell, CAlive is and always will be vapourware.
 
Because it's far too ambitious, and full of crazy ideas that will be
found to simply not work (the one proposed in the OP is a mild example)
and that nobody else apart from Rick seems to understand the benefits of.
 
Apart from which, it's not just a language, but also a new processor,
new operating system, and comprehensive, innovative IDE and debugger.
 
(Not to mention the evangelising which must take a lot of time away from
it.)
 
On the other hand, talking about about new language ideas can be useful.
(I did once implement a version of one of them.)
 
But I think the project will fail because it's just a mish-mash of C and
C++; it's not usefully different enough to be worth creating a new
language for. So just use C++ or create some language that is a thin
wrapper around C++ and that outputs C++.
 
--
bartc
bartc <bc@freeuk.com>: Apr 11 12:06PM +0100

On 11/04/2018 07:43, Alf P. Steinbach wrote:
>     template< class T > using ptr_ = T*;
>     template< Size n, class T > using raw_array_ = T[n];
 
>     ptr_<raw_array_<10,int>> x;
 
I think this short example illustrates the problems I have with C++, in
using language building facilities to emulate some feature that ought
really to be built-in.
 
It works, but the result is unsatisfactory. (I would write this
declaration elsewhere as: 'ref[10]int x', using built-in syntax.)
 
This is similar to using macros in C to get emulate missing features or
different syntax, rather that just adding them to the language. Or
classes, decorators or whatever in Python.
 
(Speaking of macros, gcc-C allows this solution:
 
#define pointer(T) typeof(T*)
#define array(N,T) typeof(T[N])
 
pointer(array(10,int)) x;
 
and 'typeof' can also be directly used like this:
 
typeof(int*) p,q,r;
 
declaring three pointers. One neat solution to the OP's problem, which
doesn't hide the pointer-ness of the type as a typedef would.
 
But it requires the 'typeof(T)' feature.)
 
 
--
bartc
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 11 07:09AM -0400

On 4/11/2018 6:36 AM, bartc wrote:
 
> [New 'CAlive' language]
 
>> I want to try out some programs in CAlive.
 
> As far as I can tell, CAlive is and always will be vapourware.
 
Correct. It has a formal definition, and is in progress, but there is
nothing tangible for people to load and run yet, save the individual
algorithms for testing.
 
> Because it's far too ambitious, and full of crazy ideas that will be
> found to simply not work (the one proposed in the OP is a mild example)
> and that nobody else apart from Rick seems to understand the benefits of.
 
Possibly. Time will bear out the truth on that one.
 
> Apart from which, it's not just a language, but also a new processor,
> new operating system, and comprehensive, innovative IDE and debugger.
 
No. CAlive is targeted to run on 80386 and later CPUs. It will have
an innovative IDE and debugger (James 4:15) and will run on a new ABI
that requires a new loader to launch.
 
I plan eventually to port it to my new CPU, new OS, etc. However,
because I haven't found anyone interested in helping me, I've retreated
somewhat back into my own goals, rather than those of other people.
 
I look to the long-term to try to find a solution that honors the
Lord. One un-impeded by prior "art" that is focused on sources other
than Him. That is the sole reason I am doing everything from scratch.
 
> (Not to mention the evangelising which must take a lot of time away from
> it.)
 
As I go through my days I teach of the Lord and His ways. Hey... that
rhymed. :-)
 
> C++; it's not usefully different enough to be worth creating a new
> language for. So just use C++ or create some language that is a thin
> wrapper around C++ and that outputs C++.
 
It is notably different in design and style. It does keep backward
compatibility, however, because there is a tremendous code base al-
ready written, and I do not want to abandon that labor effort. It
is valuable and should not be abandoned.
 
I have considered making CAlive entirely new with no backward compat-
ibility, and writing a converter to take existing C and some C++ code
and translating it. I doubt I'll do that, however, as I do intend
full C90 and C99 support at some point.
 
-----
I do not plan to do this project alone. I just haven't found anyone
who's a Christian who desires to give of their great and vast talent
to the Lord in this way. Everybody wants to get paid. Everybody wants
to work for money, and not for gifting.
 
As a result, my vision may never see the light of day. However, it is
still the correct vision because it re-focuses all of our life's efforts
back onto the Lord where they should've been all along.
 
--
Rick C. Hodgin
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 11 12:27PM +0100

> template< class T > using ptr_ = T*;
> template< Size n, class T > using raw_array_ = T[n];
 
> ptr_<raw_array_<10,int>> x;
 
You forgot the ;-)
 
--
Ben.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 11 12:39PM +0100


> On 11/04/18 00:22, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
 
>>> On 10/04/18 16:29, Ben Bacarisse wrote:
<snip>
>> * placed as far away as possible from the declarator.
 
> I actually write "char * x;" in my code. But again, preferences
> differ.
 
Yes, I got that from the previous message. I was talking about what you
said about char* x; specifically -- that it puts the emphasis in the
right place. That surprised me because it does exactly the opposite for
me so I was curious to know a bit more.
 
But maybe it's just down to habit. If you are used to seeing and
writing the star in one place, that's where you will look for
"pointerness". When I see a bare " x ", my first thought is of an
un-decorated declarator.
 
<snip>
>> you saying that that carries less weight for you in declarations?
 
> No - I just disagree a little on what is "fighting the syntax" in
> declarations.
 
I don't understand this, but I appreciate that you may think there is
nothing more you can say to help me understand.
 
--
Ben.
David Brown <david.brown@hesbynett.no>: Apr 11 01:55PM +0200

On 11/04/18 13:39, Ben Bacarisse wrote:
>> declarations.
 
> I don't understand this, but I appreciate that you may think there is
> nothing more you can say to help me understand.
 
I mean that I also find "return! x;" and "return x +1;" annoy because
the spacing is "fighting the syntax". But I don't agree that "char* x"
is "fighting the syntax" in the same way.
 
When I see "char* x;", I think that says "declare a variable x of type
char*". When I see "char *x;", I think that says "declare a variable x
such that *x is of type char". It is only this second version that is
consistent with multiple declarations in the same statement - if you
write code with multiple declarations (as in your buffer example), then
I can understand why "char* x;" would feel very wrong. But if you
/don't/ usually write code with multiple declarations in the same
statement, then it merely feels different.
 
And if that doesn't help, then "maybe it's just down to habit" is the
fallback!
"Öö Tiib" <ootiib@hot.ee>: Apr 11 05:25AM -0700

On Wednesday, 11 April 2018 14:27:51 UTC+3, Ben Bacarisse wrote:
> > template< Size n, class T > using raw_array_ = T[n];
 
> > ptr_<raw_array_<10,int>> x;
 
> You forgot the ;-)
 
I trust Alf was likely serious. He has always searched ways to
achieve maximal uniformity of syntax even when result is
inconvenient or unorthodox. Sometimes his ideas are quite
good but more usually these meet serious criticisms (or
unserious flames). He is sturdy and keeps trying.
bartc <bc@freeuk.com>: Apr 10 07:47PM +0100

On 10/04/2018 18:21, Scott Lurndal wrote:
 
> 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
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 11 02:31PM +0100


>>> On 11/04/18 00:22, Ben Bacarisse wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
 
>>>>> On 10/04/18 16:29, Ben Bacarisse wrote:
<snip>
 
> I mean that I also find "return! x;" and "return x +1;" annoy because
> the spacing is "fighting the syntax". But I don't agree that "char* x"
> is "fighting the syntax" in the same way.
 
Sorry. I was not clear. I understood you did not think is was "fighting
the syntax", I was curious to know why.
 
> statement, then it merely feels different.
 
> And if that doesn't help, then "maybe it's just down to habit" is the
> fallback!
 
I think you are indeed saying it's about habit. The syntax has
"operators" like *, &, &&, [...], (...) that combine with the name along
with plain ()s for priority. It's very similar to the expressions you
find grating. Moving the * away means the spacing no longer reflects
the association that the syntax describes.
 
--
Ben.
bartc <bc@freeuk.com>: Apr 11 03:10PM +0100

On 11/04/2018 14:31, Ben Bacarisse wrote:
 
> with plain ()s for priority. It's very similar to the expressions you
> find grating. Moving the * away means the spacing no longer reflects
> the association that the syntax describes.
 
'int*, without a space, is commonly used inside casts and in parameter
lists where there is no associated name.
 
It just a synonym for 'pointer-to-int', as a type specification in its
own right/
 
So it doesn't look wrong when you write 'int* x' rather than 'int *x'.
 
Which means it is more likely to trip you up when someone writes 'int*
x,y' or adds ",y" onto "int* x".
 
The '*' can naturally be associated with either the 'int' or the 'x'.
This is the problem.
 
--
bart
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 11 03:37PM +0100

On 11/04/2018 15:10, bartc wrote:
> x,y' or adds ",y" onto "int* x".
 
> The '*' can naturally be associated with either the 'int' or the 'x'.
> This is the problem.
 
Why are we still discussing this? ONE DECLARATION PER LINE.
 
/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" <rick.c.hodgin@gmail.com>: Apr 11 11:23AM -0400

On 4/11/2018 10:37 AM, Mr Flibble wrote:
> Why are we still discussing this? ONE DECLARATION PER LINE.
 
 
I disagree with this philosophy. I use this today, and for some
functions I might have 15 pointers defined. I don't want to waste
15 lines of code when 10 of them might be the same type, and I could
save a lot of screen real estate by going horizontal.
 
In fact, in CAlive's editor design, I introduced something called
"side coding," which is where a single source code line can contain
information beyond source code. Compilers can inject information
that's attached to a line, etc.
 
One of the other capabilities of that ability is to block off lines
of code and give them a horizontal reference relative to a prior
anchor point, enabling blocks of code to be encapsulated in a cask,
and result in source code which is all vertical, but is arranged in
a horizontal fashion, like this:
 

https://i.pinimg.com/736x/5b/a1/27/5ba1274b1478699de147c663ce247174--generation-s-user-interface.jpg
 
That type of rounded form is in my app, and it's called a cask.
There are different types:
 
(Upper right)
http://www.visual-freepro.org/images/vjr_047.png
 
They are input as (|round|), [|square|], <|triangle|>, and ~|utility|~.
They each serve a purpose, and there are additional forms not generally
used by people, including side coding information, compiler injected
information, etc.
 
-----
In any event ... having code go vertical is not always the best idea.
I want to use all of the screen real-estate, and to be able to turn
on and off the simplified display for algorithms, so that more code
can be shown in less space, with placeholders and local encapsulation
casks which allow single-stepping through code at those encapsulated
levels, rather than line-by-line, and to be able to aggregate up at
multiple levels.
 
I have good ideas for developers, Leigh. I seek to give all honor and
praise to Jesus Christ for giving me these ideas in the first place.
 
--
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
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 11 04:45PM +0100

On 11/04/2018 16:23, Rick C. Hodgin wrote:
> multiple levels.
 
> I have good ideas for developers, Leigh.  I seek to give all honor and
> praise to Jesus Christ for giving me these ideas in the first place.
 
Again reminds me of TempleOS; i.e. it is batshit crazy.
 
/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."
Bonita Montero <Bonita.Montero@gmail.com>: Apr 11 06:05PM +0200

> 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.
 
That's plainly idiotic and without any necessity.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 11 09:12AM -0700

On Wednesday, April 11, 2018 at 12:06:02 PM UTC-4, Bonita Montero wrote:
> > names.  To this end, I allow a ctrl+spacebar to introduce a linked
> > whitespace, which is a connector of related name components.
 
> That's plainly idiotic and without any necessity.
 
Agreed that it's not a necessity. It is an extension, and a feature.
Nobody has to use it. It will work just fine without spaces. It's
just another tool in the toolbox.
 
--
Rick C. Hodgin
Bonita Montero <Bonita.Montero@gmail.com>: Apr 11 06:19PM +0200


> Agreed that it's not a necessity. It is an extension, and a feature.
> Nobody has to use it. It will work just fine without spaces. It's
> just another tool in the toolbox.
 
A tool should give a benefit - this tool hasn't a benefit.
Bonita Montero <Bonita.Montero@gmail.com>: Apr 11 06:21PM +0200

> 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).
 
That was because of a mistake of MS with MS Access. Access supports
identifiers with a space, and thereby SQL-Server inherits this stupid
"feature".
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 11 09:27AM -0700

On Wednesday, April 11, 2018 at 12:19:38 PM UTC-4, Bonita Montero wrote:
> > Nobody has to use it. It will work just fine without spaces. It's
> > just another tool in the toolbox.
 
> A tool should give a benefit - this tool hasn't a benefit.
 
You have not studied the many facets of my tool to be able to conclude
this statement. You're free to examine them:
 
https://groups.google.com/forum/#!forum/caliveprogramminglanguage
 
BTW, this ability to have spaces in token names is not just given
to CAlive. It is part of the base RDC framework itself. RDC will
be able to compile C-like code, Java-like code, XBASE-like code,
and anything else, based on the set of abilities it exposes. And
whereas spaces in token names may be undesirable in C-like code,
they are very desirable in other types of code.
 
--
Rick C. Hodgin
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 11 05:38PM +0100

>> the association that the syntax describes.
 
> 'int*, without a space, is commonly used inside casts and in parameter
> lists where there is no associated name.
 
I don't like that one either. A "type name" the syntactic form that
goes in ()s to make a cast is a declaration without the name and I write
then exactly as if that is what they were.
 
> So it doesn't look wrong when you write 'int* x' rather than 'int *x'.
 
To you. I'm fine with it looking OK to other people, provided they
don't get confused about other forms.
 
> Which means it is more likely to trip you up when someone writes 'int*
> x,y' or adds ",y" onto "int* x".
 
Yes, that's one of my objections to putting the * in the wrong place.
 
> The '*' can naturally be associated with either the 'int' or the
> 'x'. This is the problem.
 
That is true in some people's minds. In mine, the * is associated with
the name. When the name is not there, I would not move the *.
 
--
Ben.
"Öö Tiib" <ootiib@hot.ee>: Apr 11 09:41AM -0700

On Wednesday, 11 April 2018 19:27:40 UTC+3, Rick C. Hodgin wrote:
 
> https://groups.google.com/forum/#!forum/caliveprogramminglanguage
 
Wow! Have you made more groups to discuss things with
most pleasant person whom you know?
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 11 09:45AM -0700

On Wednesday, April 11, 2018 at 12:41:58 PM UTC-4, Öö Tiib wrote:
 
> > https://groups.google.com/forum/#!forum/caliveprogramminglanguage
 
> Wow! Have you made more groups to discuss things with
> most pleasant person whom you know?
 
I have documented all of my ideas publicly so other people can come
and see them and if they see value incorporate them into their own
languages.
 
It is me giving to mankind the fruit of what the Lord first gave me.
It's an offering to Him, and to each of you, the best I have to give.
 
--
Rick C. Hodgin
legalize+jeeves@mail.xmission.com (Richard): Apr 11 04:47PM

[Please do not mail me a copy of your followup]
 
bartc <bc@freeuk.com> spake the secret code
 
>'int*, without a space, is commonly used inside casts and in parameter
>lists where there is no associated name.
 
Meh. I write static_cast<int *>(p).
 
int* is commonly used in casts by people who write int* x;.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Juha Nieminen <nospam@thanks.invalid>: Apr 11 12:39PM

> As a null pointer, (char*)0 is prohibited from pointing at any object,
> so it cannot meet that requirement.
 
One has to wonder why std::string couldn't accept a null char* as a valid
parameter, and interpret it has being an empty string.
"James R. Kuyper" <jameskuyper@verizon.net>: Apr 11 09:04AM -0400

On 04/11/2018 08:39 AM, Juha Nieminen wrote:
>> so it cannot meet that requirement.
 
> One has to wonder why std::string couldn't accept a null char* as a valid
> parameter, and interpret it has being an empty string.
 
An empty string is represented by "". The whole point of a null pointer
is to indicate that no object of the pointed-at type is being provided.
It's a logical error to confuse the two, and it's meaningless to provide
no string at all, as the source from which a new std::string should be
created.
Bo Persson <bop@gmb.dk>: Apr 11 06:21PM +0200

On 2018-04-11 14:39, Juha Nieminen wrote:
>> so it cannot meet that requirement.
 
> One has to wonder why std::string couldn't accept a null char* as a valid
> parameter, and interpret it has being an empty string.
 
Originally it was considered an optimization. Assuming most std::strings
are constructed from literals, a null-pointer test would be totally
wasted on those.
 
 
Bo Persson
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.

No comments: