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

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

CAlive and char* p1, p2 --vs-- char *p1, p2

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

Contents

  CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 19:40 -0700
    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 supercat@casperkitty.com - 2015-10-30 19:50 -0700
      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 19:56 -0700
        Re: CAlive and char* p1, p2 --vs-- char *p1, p2 supercat@casperkitty.com - 2015-10-31 13:00 -0700
    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 11:23 +0000
      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 07:45 -0700
        Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 15:02 +0000
          Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 10:52 -0700
            Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 20:01 +0000
              Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 13:51 -0700
                Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 21:43 +0000
                  Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 17:04 -0700
                    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-01 01:17 +0000
                      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 19:20 -0700
                Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-10-31 16:02 -0700
                  Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 17:06 -0700
    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Bartc <bc@freeuk.com> - 2015-10-31 13:54 +0000
      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 07:52 -0700
        Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Richard Damon <Richard@Damon-Family.org> - 2015-10-31 11:16 -0400
          Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 10:08 -0700
            Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Richard Damon <Richard@Damon-Family.org> - 2015-10-31 14:00 -0400
          Re: CAlive and char* p1, p2 --vs-- char *p1, p2 gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-31 17:41 +0000
            Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 11:03 -0700
              Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 20:04 +0000
                Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 13:56 -0700
                  Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 21:49 +0000
          Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-31 12:20 -0700
    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-01 04:17 +0000
      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Chad <cdalten@gmail.com> - 2015-11-01 00:02 -0700
    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ian Collins <ian-news@hotmail.com> - 2015-11-01 20:30 +1300
    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 David Brown <david.brown@hesbynett.no> - 2015-11-01 23:48 +0100
      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-01 16:54 -0800
        Re: CAlive and char* p1, p2 --vs-- char *p1, p2 David Brown <david.brown@hesbynett.no> - 2015-11-02 02:05 +0100
          Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-01 17:12 -0800
            Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-01 17:23 -0800
      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-02 02:28 -0800
        Re: CAlive and char* p1, p2 --vs-- char *p1, p2 raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:57 +0000
        Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-10 08:11 -0800
          Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Gareth Owen <gwowen@gmail.com> - 2015-11-10 18:34 +0000
            Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-10 10:55 -0800
          Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-10 21:08 -0800
            Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 05:14 -0800
              Re: CAlive and char* p1, p2 --vs-- char *p1, p2 BartC <bc@freeuk.com> - 2015-11-12 13:31 +0000
                Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 06:21 -0800
              Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-12 14:29 +0000
                Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 06:36 -0800
                Re: CAlive and char* p1, p2 --vs-- char *p1, p2 supercat@casperkitty.com - 2015-11-12 06:45 -0800
                  Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 06:48 -0800
                    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 David Brown <david.brown@hesbynett.no> - 2015-11-12 15:59 +0100
                      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 07:03 -0800
                      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-12 16:21 +0000
                        Re: CAlive and char* p1, p2 --vs-- char *p1, p2 supercat@casperkitty.com - 2015-11-12 09:09 -0800
                          Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 09:16 -0800
                            Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 09:46 -0800
                            Re: CAlive and char* p1, p2 --vs-- char *p1, p2 supercat@casperkitty.com - 2015-11-12 09:51 -0800
                              Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 10:01 -0800
                                Re: CAlive and char* p1, p2 --vs-- char *p1, p2 supercat@casperkitty.com - 2015-11-12 11:10 -0800
                                  Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 11:31 -0800
                                    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 supercat@casperkitty.com - 2015-11-12 12:14 -0800
                                      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 12:18 -0800

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

#74459

On 10/31/15 1:08 PM, Rick C. Hodgin wrote:
> On Saturday, October 31, 2015 at 11:16:27 AM UTC-4, Richard Damon wrote:
>> Rick,
>> Can I ask if you have written the Grammar to handle this to see how
>> complicated it is to implement? Or if you are going to skip some of the
>> normal formal steps of design, as real parser to decode 'real'
>> declarations (things with the full complexity of the language you are
>> proposing)?
>
> Ah, the age-old, "Do you still beat your wife?" style of question.
>
> I'll answer your question, Richard Damon, in song:
>
>      https://www.youtube.com/watch?v=TLs4MGTTXRU
>
> ...and in deference and acknowledgement to God, and of my sincere
> internal drive and desire to give the Lord the best of what He
> first gave me in all areas.
>
> And to directly answer your question:  I have a plan.  I've poked and
> prodded it in my mind, and have coded a portion of it, and so far it
> bears up to scrutiny.  It just takes deep concentration to implement,
> and with a regular full-time job, a two-hour commute, family and church
> time ... it doesn't leave many contiguous hours for the deeper aspects
> of development.  So, I've had to work around that.
>
> Best regards,
> Rick C. Hodgin
>

Perhaps you need a lesson in Logic. It sounds like the answer to my 
question in 'No', which doesn't have an implication like answering "Do 
you still beat your wife?" (Any answer implies that you have beaten you 
wife).

People with more experience than you have given you warnings that some 
of the decisions you have made in your design for your language are 
going to lead you into trouble, but you continue to say that you don't 
see a problem and it will all work out. This sounds like the blind 
leading themselves and turning down the offers of help. I suggest you 
think about Luke 14:28, and think if you really have what it takes to 
complete the task you have laid in front of yourself, especially when 
you refuse the advice of people who have knowledge in this.

You say this is your offering to God for what he has given you. Is this 
the offering of Abel, who gave the God the very best of what he had, or 
is it of Cain, who gave God just from the works of his hand. It may be 
that this is your best first fruits, but my first impression is that it 
is not (I hope you are more capable in what you do in your day job than 
this).

I too have a full time (plus) day job with a commute, a family, helping 
in my church and other community service. I allocate some time to come 
to places like this newsgroup to share the help from what I have been 
given, and in part fulfill the commandment to love and serve my 
neighbor. What I don't understand is your attitude that YOU are going to 
do this with an abject refusal to listen to people warning you that some 
of your decisions are questionable. To me, this sounds more like the 
attempt to build the Tower of Babble, than an offering to God.

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

#74455

In article <5X4Zx.28474$5L.14296@fx25.iad>,
Richard Damon  <Richard@Damon-Family.org> wrote:
>On 10/31/15 10:52 AM, Rick C. Hodgin wrote:
>>
>> My primary goal in adding this feature is to make the code clear.  The
>> * should be near the thing that's a pointer.  If it's near the type,
>> it's conveyed that way.  If it's near the variable, it's conveyed that
>> way.
>>
>> Best regards,
>> Rick C. Hodgin
>>
>
>Rick,
>Can I ask if you have written the Grammar to handle this to see how 
>complicated it is to implement? Or if you are going to skip some of the 
>normal formal steps of design, as real parser to decode 'real' 
>declarations (things with the full complexity of the language you are 
>proposing)?

I think it is pretty clear that Rick's ideas about how to parse source code
are going to be entirely ad-hoc (i.e., heuristic).  Heuristic parsers can
do anything (well, anything that a human being could do) - that is, if you
actually are able to complete the writing of the parser.

That's where Rick's head is at on all of this.

P.S.  I don't understand Rick's comment about "Do you still beat your
wife?" (Yes, I know the phrase, its meaning, and its history; I just don't
see how it applies here.  I'm sure Rick will enlighten us.)

-- 
Religion is what keeps the poor from murdering the rich.

	- Napoleon Bonaparte -

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

#74460

On Saturday, October 31, 2015 at 1:41:51 PM UTC-4, Kenny McCormack wrote:
> In article <5X4Zx.28474$5L.14296@fx25.iad>,
> Richard Damon  <Richard@Damon-Family.org> wrote:
> >On 10/31/15 10:52 AM, Rick C. Hodgin wrote:
> >>
> >> My primary goal in adding this feature is to make the code clear.  The
> >> * should be near the thing that's a pointer.  If it's near the type,
> >> it's conveyed that way.  If it's near the variable, it's conveyed that
> >> way.
> >>
> >> Best regards,
> >> Rick C. Hodgin
> >>
> >
> >Rick,
> >Can I ask if you have written the Grammar to handle this to see how 
> >complicated it is to implement? Or if you are going to skip some of the 
> >normal formal steps of design, as real parser to decode 'real' 
> >declarations (things with the full complexity of the language you are 
> >proposing)?
> 
> I think it is pretty clear that Rick's ideas about how to parse source code
> are going to be entirely ad-hoc (i.e., heuristic).  Heuristic parsers can
> do anything (well, anything that a human being could do) - that is, if you
> actually are able to complete the writing of the parser.

I have a language definition tool which define various aspects of the
language.  These are then run through a definition compiler which
generates C/C++ source code that's used in a large part of the parsing.
There are also some mechanical aspects as well.

RDC is a full compiler framework.  I'm creating tools which allow language
databases to be constructed which are fed through the framework without
any underlying changes to the framework.  The manual bits come from some
minor custom DLL code that will be required at various places.

> That's where Rick's head is at on all of this.

You are making mistaken assumptions about me, and when I correct you
there is no acknowledgement of the correction in any of your thoughts
about me.  It is sufficient for me to begin ignoring your posts because
there is no proper exchange in place.

Best regards,
Rick C. Hodgin

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

#74483

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
<snip>
> I have a language definition tool which define various aspects of the
> language.  These are then run through a definition compiler which
> generates C/C++ source code that's used in a large part of the
> parsing.

A parser generator -- that's interesting.  Do you use an existing one or
is it your own?  Is the grammar publicly available?  Is the tool
available?

<snip>
-- 
Ben.

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

#74496

On Saturday, October 31, 2015 at 4:05:01 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> <snip>
> > I have a language definition tool which define various aspects of the
> > language.  These are then run through a definition compiler which
> > generates C/C++ source code that's used in a large part of the
> > parsing.
> 
> A parser generator -- that's interesting.  Do you use an existing one or
> is it your own?  Is the grammar publicly available?  Is the tool
> available?

It is my own.  It's called SourceLight.  And it's more than a parser
generator.  It documents the functionality and provides a type of
Intellisense context that I call SourceLight.

I have the grammar partially defined for VXB, my Visual FreePro, Jr.
XBASE language.  I do not have the tool sufficiently completed to
address VXB's needs, or CAlive's needs.

It requires Visual FoxPro 9 to run:

    https://github.com/RickCHodgin/libsf/tree/master/source/vjr/source/sourcelight/xbase

Here's a sample of what it produces in terms of contextual documentation
while you're typing in the IDE (also not completed, designed and partially
coded for):

    https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/sourcelight/xbase/graphics/sourcelight_sample.png
    https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/commands/command_sourcelight.h

Best regards,
Rick C. Hodgin

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

#74502

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

> On Saturday, October 31, 2015 at 4:05:01 PM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> <snip>
>> > I have a language definition tool which define various aspects of the
>> > language.  These are then run through a definition compiler which
>> > generates C/C++ source code that's used in a large part of the
>> > parsing.
>> 
>> A parser generator -- that's interesting.  Do you use an existing one or
>> is it your own?  Is the grammar publicly available?  Is the tool
>> available?
>
> It is my own.  It's called SourceLight.  And it's more than a parser
> generator.  It documents the functionality and provides a type of
> Intellisense context that I call SourceLight.
>
> I have the grammar partially defined for VXB, my Visual FreePro, Jr.
> XBASE language.  I do not have the tool sufficiently completed to
> address VXB's needs, or CAlive's needs.
>
> It requires Visual FoxPro 9 to run:
>
>     https://github.com/RickCHodgin/libsf/tree/master/source/vjr/source/sourcelight/xbase
>
> Here's a sample of what it produces in terms of contextual documentation
> while you're typing in the IDE (also not completed, designed and partially
> coded for):
>
>     https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/sourcelight/xbase/graphics/sourcelight_sample.png
>     https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/commands/command_sourcelight.h

Ah.  I think we have another misunderstanding about words.

-- 
Ben.

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

#74475

On Saturday, October 31, 2015 at 3:16:27 PM UTC, Richard Damon wrote:
>
> Rick,
> Can I ask if you have written the Grammar to handle this to see how 
> complicated it is to implement? Or if you are going to skip some of the 
> normal formal steps of design, as real parser to decode 'real' 
> declarations (things with the full complexity of the language you are 
> proposing)?
>
If you're a language designer, you have a special privilege.

The language is defined by the constructs your implementation
accepts. That easier and more fun than writing a parser that
must accept a language defined from outside.

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

#74518

Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> What a difference a whitespace makes!
 
> -----
> CAlive makes pointer declarations more logical.
 
>    (1)  If the * is located directly beside the type (no whitespaces
>         between the type and *), it defines every item thereafter to
>         be a pointer to that type.
 
>    (2)  If, however, the * is located at least one whitespace away from
>         the type, the * only applies to the first variable, and then
>         must be explicitly applied to any other variables that need to
>         be pointers.

It is complicated in C by * being prefix, but [] is postfix.

I like the Java way better:

int [] x, y, z;
int x[], y[], z[];

Each declares three arrays.  But for more fun:

int [] a[], b[], c[];

declares three arrays of arrays.

-- glen

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

#74519

I think Java is the worst thing since jeggings.

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

#74521

Rick C. Hodgin wrote:
> What a difference a whitespace makes!
>
> -----
> CAlive makes pointer declarations more logical.
>
>      (1)  If the * is located directly beside the type (no whitespaces
>           between the type and *), it defines every item thereafter to
>           be a pointer to that type.
>
>      (2)  If, however, the * is located at least one whitespace away from
>           the type, the * only applies to the first variable, and then
>           must be explicitly applied to any other variables that need to
>           be pointers.
>
> For example:
>
>      char*   p1, p2, p3;
>      // p1, p2, and p3 are all char* variables
>
>      char    *p4, p5, *p6;
>      // p4 and p6 are char*, but p5 is just char

It would be much simpler to enforce the common guideline which prohibits 
the declaration of more than one valuable on a line.  Since the 
introduction last century of mixed declarations and code, the need for 
large blocks of declarations as been significantly reduced.

-- 
Ian Collins

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

#74592

On 31/10/15 03:40, Rick C. Hodgin wrote:
> What a difference a whitespace makes!
>
> -----
> CAlive makes pointer declarations more logical.
>
>      (1)  If the * is located directly beside the type (no whitespaces
>           between the type and *), it defines every item thereafter to
>           be a pointer to that type.
>
>      (2)  If, however, the * is located at least one whitespace away from
>           the type, the * only applies to the first variable, and then
>           must be explicitly applied to any other variables that need to
>           be pointers.
>
> For example:
>
>      char*   p1, p2, p3;
>      // p1, p2, and p3 are all char* variables
>
>      char    *p4, p5, *p6;
>      // p4 and p6 are char*, but p5 is just char
>

If I were inventing a new language, I would put some sort of punctuation 
between the type and the identifiers.  The identifier list would allow 
/only/ the identifiers - no pointer, references, arrays, etc.  For example:

	char* : p1, p2, p3;

There's no doubts - each of p1, p2 and p3 are pointers to char.

	char : *p4, p5, *p6;

Illegal syntax - you can't have the pointer symbol in the identifier list.

	char[20] : s, t;

There are no doubts - s and t are arrays of 20 chars.

	char : s[20], t;

Illegal syntax.

Basically, it is the same thing as in Pascal, bare the minor detail of 
the ordering.
	

> -----
> This feature was included in deference to the D programming language and
> Walter Bright who, back in 2006, unknowingly first introduced me to the
> idea that pointer symbols should always be next to the type for pointer
> declarations.
>
> Thank you, Walter, for opening my eyes.
>
> Best regards,
> Rick C. Hodgin
>

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

#74612

On Sunday, November 1, 2015 at 5:49:01 PM UTC-5, David Brown wrote:
> On 31/10/15 03:40, Rick C. Hodgin wrote:
> > What a difference a whitespace makes!
> >
> > -----
> > CAlive makes pointer declarations more logical.
> >
> >      (1)  If the * is located directly beside the type (no whitespaces
> >           between the type and *), it defines every item thereafter to
> >           be a pointer to that type.
> >
> >      (2)  If, however, the * is located at least one whitespace away from
> >           the type, the * only applies to the first variable, and then
> >           must be explicitly applied to any other variables that need to
> >           be pointers.
> >
> > For example:
> >
> >      char*   p1, p2, p3;
> >      // p1, p2, and p3 are all char* variables
> >
> >      char    *p4, p5, *p6;
> >      // p4 and p6 are char*, but p5 is just char
> >
> 
> If I were inventing a new language, I would put some sort of punctuation 
> between the type and the identifiers.  The identifier list would allow 
> /only/ the identifiers - no pointer, references, arrays, etc.  For example:
> 
> 	char* : p1, p2, p3;
> 
> There's no doubts - each of p1, p2 and p3 are pointers to char.
> 
> 	char : *p4, p5, *p6;
> 
> Illegal syntax - you can't have the pointer symbol in the identifier list.
> 
> 	char[20] : s, t;
> 
> There are no doubts - s and t are arrays of 20 chars.
> 
> 	char : s[20], t;
> 
> Illegal syntax.
> 
> Basically, it is the same thing as in Pascal, bare the minor detail of 
> the ordering.

I've always liked C's style of declaration, except I did not like
having to create a typedef in order to get multiple pointer
declarations on the same line without having to declare a * at
each variable, so even today I use multiple lines to declare
multiple pointer definitions, even if they're the same.

It's on the cover of my book that way even (with comp, compNext,
and compFile):

    https://github.com/RickCHodgin/libsf/blob/master/books/rdc/rdc_front.png

Now that I've introduced type* forms, I suppose I could change that.
:-)  And, I have a lot of peace with the "type* p" and "type *p"
forms working together.  And since most people seem to think it
should be "char *p;" even if it's a stand-alone declaration, it
will provide a lot of backward compatibility (he said grinning).

:-)

> > -----
> > This feature was included in deference to the D programming language and
> > Walter Bright who, back in 2006, unknowingly first introduced me to the
> > idea that pointer symbols should always be next to the type for pointer
> > declarations.
> >
> > Thank you, Walter, for opening my eyes.

Best regards,
Rick C. Hodgin

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

#74614

On 02/11/15 01:54, Rick C. Hodgin wrote:
> On Sunday, November 1, 2015 at 5:49:01 PM UTC-5, David Brown wrote:
>> On 31/10/15 03:40, Rick C. Hodgin wrote:
>>> What a difference a whitespace makes!
>>>
>>> -----
>>> CAlive makes pointer declarations more logical.
>>>
>>>       (1)  If the * is located directly beside the type (no whitespaces
>>>            between the type and *), it defines every item thereafter to
>>>            be a pointer to that type.
>>>
>>>       (2)  If, however, the * is located at least one whitespace away from
>>>            the type, the * only applies to the first variable, and then
>>>            must be explicitly applied to any other variables that need to
>>>            be pointers.
>>>
>>> For example:
>>>
>>>       char*   p1, p2, p3;
>>>       // p1, p2, and p3 are all char* variables
>>>
>>>       char    *p4, p5, *p6;
>>>       // p4 and p6 are char*, but p5 is just char
>>>
>>
>> If I were inventing a new language, I would put some sort of punctuation
>> between the type and the identifiers.  The identifier list would allow
>> /only/ the identifiers - no pointer, references, arrays, etc.  For example:
>>
>> 	char* : p1, p2, p3;
>>
>> There's no doubts - each of p1, p2 and p3 are pointers to char.
>>
>> 	char : *p4, p5, *p6;
>>
>> Illegal syntax - you can't have the pointer symbol in the identifier list.
>>
>> 	char[20] : s, t;
>>
>> There are no doubts - s and t are arrays of 20 chars.
>>
>> 	char : s[20], t;
>>
>> Illegal syntax.
>>
>> Basically, it is the same thing as in Pascal, bare the minor detail of
>> the ordering.
>
> I've always liked C's style of declaration, except I did not like
> having to create a typedef in order to get multiple pointer
> declarations on the same line without having to declare a * at
> each variable, so even today I use multiple lines to declare
> multiple pointer definitions, even if they're the same.
>
> It's on the cover of my book that way even (with comp, compNext,
> and compFile):
>
>      https://github.com/RickCHodgin/libsf/blob/master/books/rdc/rdc_front.png
>
> Now that I've introduced type* forms, I suppose I could change that.
> :-)  And, I have a lot of peace with the "type* p" and "type *p"
> forms working together.  And since most people seem to think it
> should be "char *p;" even if it's a stand-alone declaration, it
> will provide a lot of backward compatibility (he said grinning).
>
> :-)

People vary - in particular, it is often said that C fans like "char 
*p;", while C++ fans like "char* p;".  But this is your chance to fix 
one of C's big mistakes, which leads to common errors amongst 
programmers (admittedly errors that are usually caught be the compiler). 
  Don't make your own language worse than C - make it better!

>
>>> -----
>>> This feature was included in deference to the D programming language and
>>> Walter Bright who, back in 2006, unknowingly first introduced me to the
>>> idea that pointer symbols should always be next to the type for pointer
>>> declarations.
>>>
>>> Thank you, Walter, for opening my eyes.
>
> Best regards,
> Rick C. Hodgin
>

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

#74615

On Sunday, November 1, 2015 at 8:05:52 PM UTC-5, David Brown wrote:
> On 02/11/15 01:54, Rick C. Hodgin wrote:
> > On Sunday, November 1, 2015 at 5:49:01 PM UTC-5, David Brown wrote:
> >> On 31/10/15 03:40, Rick C. Hodgin wrote:
> >>> What a difference a whitespace makes!
> >>>
> >>> -----
> >>> CAlive makes pointer declarations more logical.
> >>>
> >>>       (1)  If the * is located directly beside the type (no whitespaces
> >>>            between the type and *), it defines every item thereafter to
> >>>            be a pointer to that type.
> >>>
> >>>       (2)  If, however, the * is located at least one whitespace away from
> >>>            the type, the * only applies to the first variable, and then
> >>>            must be explicitly applied to any other variables that need to
> >>>            be pointers.
> >>>
> >>> For example:
> >>>
> >>>       char*   p1, p2, p3;
> >>>       // p1, p2, and p3 are all char* variables
> >>>
> >>>       char    *p4, p5, *p6;
> >>>       // p4 and p6 are char*, but p5 is just char
> >>>
> >>
> >> If I were inventing a new language, I would put some sort of punctuation
> >> between the type and the identifiers.  The identifier list would allow
> >> /only/ the identifiers - no pointer, references, arrays, etc.  For example:
> >>
> >> 	char* : p1, p2, p3;
> >>
> >> There's no doubts - each of p1, p2 and p3 are pointers to char.
> >>
> >> 	char : *p4, p5, *p6;
> >>
> >> Illegal syntax - you can't have the pointer symbol in the identifier list.
> >>
> >> 	char[20] : s, t;
> >>
> >> There are no doubts - s and t are arrays of 20 chars.
> >>
> >> 	char : s[20], t;
> >>
> >> Illegal syntax.
> >>
> >> Basically, it is the same thing as in Pascal, bare the minor detail of
> >> the ordering.
> >
> > I've always liked C's style of declaration, except I did not like
> > having to create a typedef in order to get multiple pointer
> > declarations on the same line without having to declare a * at
> > each variable, so even today I use multiple lines to declare
> > multiple pointer definitions, even if they're the same.
> >
> > It's on the cover of my book that way even (with comp, compNext,
> > and compFile):
> >
> >      https://github.com/RickCHodgin/libsf/blob/master/books/rdc/rdc_front.png
> >
> > Now that I've introduced type* forms, I suppose I could change that.
> > :-)  And, I have a lot of peace with the "type* p" and "type *p"
> > forms working together.  And since most people seem to think it
> > should be "char *p;" even if it's a stand-alone declaration, it
> > will provide a lot of backward compatibility (he said grinning).
> >
> > :-)
> 
> People vary - in particular, it is often said that C fans like "char 
> *p;", while C++ fans like "char* p;".  But this is your chance to fix 
> one of C's big mistakes, which leads to common errors amongst 
> programmers (admittedly errors that are usually caught be the compiler). 
>   Don't make your own language worse than C - make it better!

That's what I was going for [to make my language better than CAlive].
And, that's what I achieved.

type* p; and type *p; both make perfect sense.  It's the feature I
wish C would've had all these years.  And now CAlive has it, and
when I say "has" I mean it's part of the design.

> >>> -----
> >>> This feature was included in deference to the D programming language and
> >>> Walter Bright who, back in 2006, unknowingly first introduced me to the
> >>> idea that pointer symbols should always be next to the type for pointer
> >>> declarations.
> >>>
> >>> Thank you, Walter, for opening my eyes.

Best regards,
Rick C. Hodgin

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

#74617

On Sunday, November 1, 2015 at 8:12:34 PM UTC-5, Rick C. Hodgin wrote:
> On Sunday, November 1, 2015 at 8:05:52 PM UTC-5, David Brown wrote:
> > On 02/11/15 01:54, Rick C. Hodgin wrote:
> > > On Sunday, November 1, 2015 at 5:49:01 PM UTC-5, David Brown wrote:
> > >> On 31/10/15 03:40, Rick C. Hodgin wrote:
> > >>> What a difference a whitespace makes!
> > >>>
> > >>> -----
> > >>> CAlive makes pointer declarations more logical.
> > >>>
> > >>>       (1)  If the * is located directly beside the type (no whitespaces
> > >>>            between the type and *), it defines every item thereafter to
> > >>>            be a pointer to that type.
> > >>>
> > >>>       (2)  If, however, the * is located at least one whitespace away from
> > >>>            the type, the * only applies to the first variable, and then
> > >>>            must be explicitly applied to any other variables that need to
> > >>>            be pointers.
> > >>>
> > >>> For example:
> > >>>
> > >>>       char*   p1, p2, p3;
> > >>>       // p1, p2, and p3 are all char* variables
> > >>>
> > >>>       char    *p4, p5, *p6;
> > >>>       // p4 and p6 are char*, but p5 is just char
> > >>>
> > >>
> > >> If I were inventing a new language, I would put some sort of punctuation
> > >> between the type and the identifiers.  The identifier list would allow
> > >> /only/ the identifiers - no pointer, references, arrays, etc.  For example:
> > >>
> > >> 	char* : p1, p2, p3;
> > >>
> > >> There's no doubts - each of p1, p2 and p3 are pointers to char.
> > >>
> > >> 	char : *p4, p5, *p6;
> > >>
> > >> Illegal syntax - you can't have the pointer symbol in the identifier list.
> > >>
> > >> 	char[20] : s, t;
> > >>
> > >> There are no doubts - s and t are arrays of 20 chars.
> > >>
> > >> 	char : s[20], t;
> > >>
> > >> Illegal syntax.
> > >>
> > >> Basically, it is the same thing as in Pascal, bare the minor detail of
> > >> the ordering.
> > >
> > > I've always liked C's style of declaration, except I did not like
> > > having to create a typedef in order to get multiple pointer
> > > declarations on the same line without having to declare a * at
> > > each variable, so even today I use multiple lines to declare
> > > multiple pointer definitions, even if they're the same.
> > >
> > > It's on the cover of my book that way even (with comp, compNext,
> > > and compFile):
> > >
> > >      https://github.com/RickCHodgin/libsf/blob/master/books/rdc/rdc_front.png
> > >
> > > Now that I've introduced type* forms, I suppose I could change that.
> > > :-)  And, I have a lot of peace with the "type* p" and "type *p"
> > > forms working together.  And since most people seem to think it
> > > should be "char *p;" even if it's a stand-alone declaration, it
> > > will provide a lot of backward compatibility (he said grinning).
> > >
> > > :-)
> > 
> > People vary - in particular, it is often said that C fans like "char 
> > *p;", while C++ fans like "char* p;".  But this is your chance to fix 
> > one of C's big mistakes, which leads to common errors amongst 
> > programmers (admittedly errors that are usually caught be the compiler). 
> >   Don't make your own language worse than C - make it better!
> 
> That's what I was going for [to make my language better than CAlive].
> And, that's what I achieved.

Should read:

    That's what I was going for [to make my language better than C].
    And, that's what I achieved.

I'm getting so used to typing CAlive now ... it just flows. :-)

> type* p; and type *p; both make perfect sense.  It's the feature I
> wish C would've had all these years.  And now CAlive has it, and
> when I say "has" I mean it's part of the design.
> 
> > >>> -----
> > >>> This feature was included in deference to the D programming language and
> > >>> Walter Bright who, back in 2006, unknowingly first introduced me to the
> > >>> idea that pointer symbols should always be next to the type for pointer
> > >>> declarations.
> > >>>
> > >>> Thank you, Walter, for opening my eyes.

Best regards,
Rick C. Hodgin

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

#74635

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

> If I were inventing a new language, [snip]

You would show good manners by discussing it
in a different newsgroup?

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

#75588

Tim Rentsch <txr@alumni.caltech.edu> wrote:

> David Brown <david.brown@hesbynett.no> writes:
> 
> > If I were inventing a new language, [snip]
> 
> You would show good manners by discussing it
> in a different newsgroup?

Instead of in comp.lang.gnu-c++.advocacy, /sicut nunc/?

Richard

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

#75590

On Monday, November 2, 2015 at 5:28:42 AM UTC-5, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
> > If I were inventing a new language, [snip]
> 
> You would show good manners by discussing it
> in a different newsgroup?

I'm discussing it.  Nobody else is showing up to discuss it.  How long
shall I talk to the crickets?

    https://groups.google.com/forum/#!forum/caliveprogramminglanguage

Best regards,
Rick C. Hodgin

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

#75649

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

> On Monday, November 2, 2015 at 5:28:42 AM UTC-5, Tim Rentsch wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> 
>> > If I were inventing a new language, [snip]
>> 
>> You would show good manners by discussing it
>> in a different newsgroup?
>
> I'm discussing it.  Nobody else is showing up to discuss it.  How long
> shall I talk to the crickets?

Until enlightenment dawns.

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

#75654

On Tuesday, November 10, 2015 at 1:34:52 PM UTC-5, gwowen wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Monday, November 2, 2015 at 5:28:42 AM UTC-5, Tim Rentsch wrote:
> >> David Brown <david.brown@hesbynett.no> writes:
> >> 
> >> > If I were inventing a new language, [snip]
> >> 
> >> You would show good manners by discussing it
> >> in a different newsgroup?
> >
> > I'm discussing it.  Nobody else is showing up to discuss it.  How long
> > shall I talk to the crickets?
> 
> Until enlightenment dawns.

It's why I'm there in the first place, gwowen.  I come here to shed
that light on others, that they too might find ... enlightenment.

Best regards,
Rick C. Hodgin

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

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

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

csiph-web