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 3 of 3 — ← Prev page 1 2 [3]

#75714

"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?
>
>     https://groups.google.com/forum/#!forum/caliveprogramminglanguage

Yes, I noticed you were doing this, and I appreciate you making an
effort to find another forum.  If the one on google groups isn't
working out, I suggest trying comp.lang.misc and/or comp.programming,
both of which have some amount of relatively recent traffic.  Also
the sorts of things I think you want to discuss seem like a better
fit to the nominal charter of one or the other, depending on which
aspect you are asking about.

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

#75814

On Wednesday, November 11, 2015 at 12:09:02 AM UTC-5, Tim Rentsch 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?
> >
> >     https://groups.google.com/forum/#!forum/caliveprogramminglanguage
> 
> Yes, I noticed you were doing this, and I appreciate you making an
> effort to find another forum.  If the one on google groups isn't
> working out, I suggest trying comp.lang.misc and/or comp.programming,
> both of which have some amount of relatively recent traffic.  Also
> the sorts of things I think you want to discuss seem like a better
> fit to the nominal charter of one or the other, depending on which
> aspect you are asking about.

FWIW, I don't see the logic in your suggestion.  I'm making a direct
follow-on to C that is going to be very very compatible with C90 and
C99.  It could even be thought of as a C compiler with "Alive"
extensions.  It makes sense to discuss it here in the C group.

However, I am content to post about it in my own CAlive group, even
if it is just alone conversations between me, the crickets, and God.
:-)

Best regards,
Rick C. Hodgin

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

#75815

On 12/11/2015 13:14, Rick C. Hodgin wrote:
> On Wednesday, November 11, 2015 at 12:09:02 AM UTC-5, Tim Rentsch wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

>>> 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
>>
>> Yes, I noticed you were doing this, and I appreciate you making an
>> effort to find another forum.

> FWIW, I don't see the logic in your suggestion.  I'm making a direct
> follow-on to C that is going to be very very compatible with C90 and
> C99.  It could even be thought of as a C compiler with "Alive"
> extensions.  It makes sense to discuss it here in the C group.
>
> However, I am content to post about it in my own CAlive group, even
> if it is just alone conversations between me, the crickets, and God.
> :-)

Yes, you've discovered that creating a new language, or even 
implementing it, is child's play compared with getting anyone else 
interested in using it or even discussing it!

That's why I've never bothered pushing anything of mine (and in the past 
having my own highly productive tools gave me an edge; why would I want 
to share them!)

But I don't think this is any different from trying to sell any other 
product, even if it's free. (And with programming, anyone with enough 
knowledge to discuss it, will already have their own favourite 
languages. Which these days, will be so large and comprehensive, that it 
would be difficult to compete with.)

(I remember working on a compiler as a final year project at college. I 
was quite pleased with the result, but the assessors were more 
interested in how I was going to advertise it so that others were aware 
of it. I had no idea; I think I suggested placing a small ad in the paper.)

-- 
Bartc

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

#75818

On Thursday, November 12, 2015 at 8:32:09 AM UTC-5, Bart wrote:
> On 12/11/2015 13:14, Rick C. Hodgin wrote:
> > On Wednesday, November 11, 2015 at 12:09:02 AM UTC-5, Tim Rentsch wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> >>> 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
> >>
> >> Yes, I noticed you were doing this, and I appreciate you making an
> >> effort to find another forum.
> 
> > FWIW, I don't see the logic in your suggestion.  I'm making a direct
> > follow-on to C that is going to be very very compatible with C90 and
> > C99.  It could even be thought of as a C compiler with "Alive"
> > extensions.  It makes sense to discuss it here in the C group.
> >
> > However, I am content to post about it in my own CAlive group, even
> > if it is just alone conversations between me, the crickets, and God.
> > :-)
> 
> Yes, you've discovered that creating a new language, or even 
> implementing it, is child's play compared with getting anyone else 
> interested in using it or even discussing it!
> 
> That's why I've never bothered pushing anything of mine (and in the past 
> having my own highly productive tools gave me an edge; why would I want 
> to share them!)
> 
> But I don't think this is any different from trying to sell any other 
> product, even if it's free. (And with programming, anyone with enough 
> knowledge to discuss it, will already have their own favourite 
> languages. Which these days, will be so large and comprehensive, that it 
> would be difficult to compete with.)
> 
> (I remember working on a compiler as a final year project at college. I 
> was quite pleased with the result, but the assessors were more 
> interested in how I was going to advertise it so that others were aware 
> of it. I had no idea; I think I suggested placing a small ad in the paper.)

Where do you live, Bart?  I'm in Indianapolis, IN.  If you're ever out
this way, hit me up.  I would enjoy meeting and speaking with you.

Best regards,
Rick C. Hodgin

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

#75821

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
<snip>
> [...]                                         I'm making a direct
> follow-on to C that is going to be very very compatible with C90 and
> C99.  It could even be thought of as a C compiler with "Alive"
> extensions.  It makes sense to discuss it here in the C group.

It makes sense to discuss the C part here -- even the interaction
between the extensions and standard C is topical[1], but that's not what
you've been doing.  The are a huge number of extensions to C and none of
them are topical here except in so far as they interact with standard C.

But to be topical: what level of compatibility are you aiming for -- a
conforming C99 implementation?  What systems will you support?  How do
you plan to switch between C syntax and semantics and your own?  Do you
have anything implemented yet?

[1] For example, Jacob Navia introduced one of lcc-win's extensions to C
using a context-sensitive keyword so that no conforming C program would
be affected.  That kind of thing is, to my mind, topical here.

-- 
Ben.

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

#75822

On Thursday, November 12, 2015 at 9:30:04 AM UTC-5, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> <snip>
> > [...]                                         I'm making a direct
> > follow-on to C that is going to be very very compatible with C90 and
> > C99.  It could even be thought of as a C compiler with "Alive"
> > extensions.  It makes sense to discuss it here in the C group.
> 
> It makes sense to discuss the C part here -- even the interaction
> between the extensions and standard C is topical[1], but that's not what
> you've been doing.  The are a huge number of extensions to C and none of
> them are topical here except in so far as they interact with standard C.
> 
> But to be topical: what level of compatibility are you aiming for -- a
> conforming C99 implementation?  What systems will you support?  How do
> you plan to switch between C syntax and semantics and your own?  Do you
> have anything implemented yet?
> 
> [1] For example, Jacob Navia introduced one of lcc-win's extensions to C
> using a context-sensitive keyword so that no conforming C program would
> be affected.  That kind of thing is, to my mind, topical here.

Ultimately, 100% conforming.  Initially, largely conforming using a
standard library compiled from some other source code base, except
for many of the functions I use which will be included directly.

Eventually, I would like to enlist comp.lang.c and C Standard gurus
to help me achieve a 100% conforming compiler with full -C90 and -C99
support.

By default without use of any such switches, CAlive will recognize
standard C syntax, but it may not be conforming (probably due mostly
to my ignorance, though I intend from the beginning to have the code
I've written in all of my projects as C/C++ code to compile and work
as it has with literally zero source code changes... but I'm sure
that's a small part of C's quirks, and ... there you have the
limitations I'll be dealing with initially).

Best regards,
Rick C. Hodgin

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

#75824

On Thursday, November 12, 2015 at 8:30:04 AM UTC-6, Ben Bacarisse wrote:
> [1] For example, Jacob Navia introduced one of lcc-win's extensions to C
> using a context-sensitive keyword so that no conforming C program would
> be affected.  That kind of thing is, to my mind, topical here.

It's too bad C doesn't have any kind of context-sensitive macro facility to
make context-sensitive keywords safe.

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

#75825

On Thursday, November 12, 2015 at 9:46:16 AM UTC-5, supe...@casperkitty.com wrote:
> On Thursday, November 12, 2015 at 8:30:04 AM UTC-6, Ben Bacarisse wrote:
> > [1] For example, Jacob Navia introduced one of lcc-win's extensions to C
> > using a context-sensitive keyword so that no conforming C program would
> > be affected.  That kind of thing is, to my mind, topical here.
> 
> It's too bad C doesn't have any kind of context-sensitive macro facility to
> make context-sensitive keywords safe.

Don't C macros have scope if they're defined in the function block?

Best regards,
Rick C. Hodgin

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

#75827

On 12/11/15 15:48, Rick C. Hodgin wrote:
> On Thursday, November 12, 2015 at 9:46:16 AM UTC-5, supe...@casperkitty.com wrote:
>> On Thursday, November 12, 2015 at 8:30:04 AM UTC-6, Ben Bacarisse wrote:
>>> [1] For example, Jacob Navia introduced one of lcc-win's extensions to C
>>> using a context-sensitive keyword so that no conforming C program would
>>> be affected.  That kind of thing is, to my mind, topical here.
>>
>> It's too bad C doesn't have any kind of context-sensitive macro facility to
>> make context-sensitive keywords safe.
> 
> Don't C macros have scope if they're defined in the function block?
> 

No, macros have no scope rules.

(If you are going to try to write a C99 implementation, you really have
to learn these details.  For your own language, you can choose freely of
course - but for C, you are stuck with the existing language whether you
like it or not.)

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

#75828

On Thursday, November 12, 2015 at 9:59:55 AM UTC-5, David Brown wrote:
> On 12/11/15 15:48, Rick C. Hodgin wrote:
> > On Thursday, November 12, 2015 at 9:46:16 AM UTC-5, supe...@casperkitty.com wrote:
> >> On Thursday, November 12, 2015 at 8:30:04 AM UTC-6, Ben Bacarisse wrote:
> >>> [1] For example, Jacob Navia introduced one of lcc-win's extensions to C
> >>> using a context-sensitive keyword so that no conforming C program would
> >>> be affected.  That kind of thing is, to my mind, topical here.
> >>
> >> It's too bad C doesn't have any kind of context-sensitive macro facility to
> >> make context-sensitive keywords safe.
> > 
> > Don't C macros have scope if they're defined in the function block?
> > 
> 
> No, macros have no scope rules.
> 
> (If you are going to try to write a C99 implementation, you really have
> to learn these details.  For your own language, you can choose freely of
> course - but for C, you are stuck with the existing language whether you
> like it or not.)

I will.  Scope is easy to add.  And, FWIW, CAlive's macros would've had
scope relative to where they were defined by default because that's how
I understood it to be. :-)

Best regards,
Rick C. Hodgin

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

#75834

In article <n229cm$gcb$2@dont-email.me>,
David Brown  <david.brown@hesbynett.no> wrote:
>On 12/11/15 15:48, Rick C. Hodgin wrote:
>> On Thursday, November 12, 2015 at 9:46:16 AM UTC-5, supe...@casperkitty.com wrote:
>>> On Thursday, November 12, 2015 at 8:30:04 AM UTC-6, Ben Bacarisse wrote:
>>>> [1] For example, Jacob Navia introduced one of lcc-win's extensions to C
>>>> using a context-sensitive keyword so that no conforming C program would
>>>> be affected.  That kind of thing is, to my mind, topical here.
>>>
>>> It's too bad C doesn't have any kind of context-sensitive macro facility to
>>> make context-sensitive keywords safe.
>> 
>> Don't C macros have scope if they're defined in the function block?
>> 
>
>No, macros have no scope rules.
>
>(If you are going to try to write a C99 implementation, you really have
>to learn these details.  For your own language, you can choose freely of
>course - but for C, you are stuck with the existing language whether you
>like it or not.)
>
>

Has Rick ever claimed to be writing a C implementation? (I don't think so)

He has made vague claims about his long term, long term goal being to make
his language (whatever he is calling it this week) to be C compatible, but
I doubt slavish devotion to the standards documents will ever be high on
his list of priorities.

-- 
If it seems like I'm not responding to some moronic criticism that you've
posted in response to one of my posts, be aware that I do not debate with idiots.

It doesn't mean you've won anything...

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

#75842

On Thursday, November 12, 2015 at 10:21:38 AM UTC-6, Kenny McCormack wrote:
> Has Rick ever claimed to be writing a C implementation? (I don't think so)
> 
> He has made vague claims about his long term, long term goal being to make
> his language (whatever he is calling it this week) to be C compatible, but
> I doubt slavish devotion to the standards documents will ever be high on
> his list of priorities.

I would suggest that for Rick or anyone else who is considering writing a C-ish
language, a good set of objectives would be:

1. Code which is valid in both languages should have the same meaning in
   both.

2. C code whose meaning would require interpreting things in a fashion
   contrary to the spirit of the new language should not compile, *but*
   should be readily modifiable to a form *which would have the same
   meaning in both*.

Accepting those as starting principles will allow the new language to be
take advantage of a large corpus of C code, without being bound by some of
the peculiarities of C.  For example, the C standard requires that given:

    uint32_t x=1; int32_t y=-1;

compilers must accept the expression "x>y" and on machines where "int" is
32 bits it must yield 0.  I would suggest that it would be better for a
C-derived language to simply forbid that expression.  A programmer wanting
the behavior mandated by the C Standard could write the expression as
"x > (uint32_t)y", and it could be argued that the expression *should* be
written that way *even when writing in Standard C*; a programmer wanting the
expression evaluated by the rules of mathematical integers (and not needing
the code to be usable in C) could write the declaration as:

    unum32_t x=1; int32_t y=1;

What do you think of that as a language philosophy?

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

#75844

On Thursday, November 12, 2015 at 12:09:45 PM UTC-5, supe...@casperkitty.com wrote:
> On Thursday, November 12, 2015 at 10:21:38 AM UTC-6, Kenny McCormack wrote:
> > Has Rick ever claimed to be writing a C implementation? (I don't think so)
> > 
> > He has made vague claims about his long term, long term goal being to make
> > his language (whatever he is calling it this week) to be C compatible, but
> > I doubt slavish devotion to the standards documents will ever be high on
> > his list of priorities.
> 
> I would suggest that for Rick or anyone else who is considering writing a C-ish
> language, a good set of objectives would be:
> 
> 1. Code which is valid in both languages should have the same meaning in
>    both.

Mostly.  CAlive extends a few things syntax-wise, but on the whole,
everything that I know how to program in C/C++ code will compile with
zero changes in CAlive, and it will function identically.

> 2. C code whose meaning would require interpreting things in a fashion
>    contrary to the spirit of the new language should not compile, *but*
>    should be readily modifiable to a form *which would have the same
>    meaning in both*.

CAlive extends many things:
    https://github.com/RickCHodgin/libsf/blob/master/books/rdc/rdc.odt

But, it will also work as a standard C compiler on most everything.

> Accepting those as starting principles will allow the new language to be
> take advantage of a large corpus of C code, without being bound by some of
> the peculiarities of C.  For example, the C standard requires that given:
> 
>     uint32_t x=1; int32_t y=-1;
> 
> compilers must accept the expression "x>y" and on machines where "int" is
> 32 bits it must yield 0.  I would suggest that it would be better for a
> C-derived language to simply forbid that expression.  A programmer wanting
> the behavior mandated by the C Standard could write the expression as
> "x > (uint32_t)y", and it could be argued that the expression *should* be
> written that way *even when writing in Standard C*; a programmer wanting the
> expression evaluated by the rules of mathematical integers (and not needing
> the code to be usable in C) could write the declaration as:
> 
>     unum32_t x=1; int32_t y=1;
> 
> What do you think of that as a language philosophy?

CAlive will upsize signed and unsigned values to the next largest size
fundamental type in order to compare them.  To keep them the same size,
they must be cast one to other's type.

If no larger fundamental type exists, then it will be upsized to a "bi"
type, which is a fundamental type in CAlive, which is an arbitrary size
"big integer" of the next largest size, such as 64-bit to 128-bit).

Best regards,
Rick C. Hodgin

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

#75847

On Thursday, November 12, 2015 at 12:17:02 PM UTC-5, Rick C. Hodgin wrote:
> On Thursday, November 12, 2015 at 12:09:45 PM UTC-5, supe...@casperkitty.com > > Accepting those as starting principles will allow the new language to be
> > take advantage of a large corpus of C code, without being bound by some of
> > the peculiarities of C.  For example, the C standard requires that given:
> > 
> >     uint32_t x=1; int32_t y=-1;
> > 
> > compilers must accept the expression "x>y" and on machines where "int" is
> > 32 bits it must yield 0.  I would suggest that it would be better for a
> > C-derived language to simply forbid that expression.  A programmer wanting
> > the behavior mandated by the C Standard could write the expression as
> > "x > (uint32_t)y", and it could be argued that the expression *should* be
> > written that way *even when writing in Standard C*; a programmer wanting the
> > expression evaluated by the rules of mathematical integers (and not needing
> > the code to be usable in C) could write the declaration as:
> > 
> >     unum32_t x=1; int32_t y=1;
> > 
> > What do you think of that as a language philosophy?
> 
> CAlive will upsize signed and unsigned values to the next largest size
> fundamental type in order to compare them.

I should clarify to indicate that after the upsize, it then does a
signed compare.

Best regards,
Rick C. Hodgin

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

#75848

On Thursday, November 12, 2015 at 11:17:02 AM UTC-6, Rick C. Hodgin wrote:
> CAlive will upsize signed and unsigned values to the next largest size
> fundamental type in order to compare them.  To keep them the same size,
> they must be cast one to other's type.
> 
> If no larger fundamental type exists, then it will be upsized to a "bi"
> type, which is a fundamental type in CAlive, which is an arbitrary size
> "big integer" of the next largest size, such as 64-bit to 128-bit).

I would suggest that it is useful to have cardinal-number types which behave
in that way, but would suggest that it be separate from both C's "unsigned"
types and from "wrapping" types which mostly work like "unsigned int" but
without some of the weird corner-case behaviors that change depending upon
the relative sizes of integer types.

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

#75850

On Thursday, November 12, 2015 at 12:51:35 PM UTC-5, supe...@casperkitty.com wrote:
> On Thursday, November 12, 2015 at 11:17:02 AM UTC-6, Rick C. Hodgin wrote:
> > CAlive will upsize signed and unsigned values to the next largest size
> > fundamental type in order to compare them.  To keep them the same size,
> > they must be cast one to other's type.
> > 
> > If no larger fundamental type exists, then it will be upsized to a "bi"
> > type, which is a fundamental type in CAlive, which is an arbitrary size
> > "big integer" of the next largest size, such as 64-bit to 128-bit).
> 
> I would suggest that it is useful to have cardinal-number types which behave
> in that way, but would suggest that it be separate from both C's "unsigned"
> types and from "wrapping" types which mostly work like "unsigned int" but
> without some of the weird corner-case behaviors that change depending upon
> the relative sizes of integer types.

Computers should do what we (people/developers) expect, and our goals and
needs should not be subject to odd quirks based on the mechanical
peculiarities of the way computers must process binary data, when such a
requirement is not truly a fundamental requirement.

As such, CAlive takes that perspective...

CAlive's goals are to process data in the correct form as per the software
developer's point of view, possibly at the sacrifice of machine performance.
In this way, a signed and unsigned compare will always compare properly
as by the next-larger signed value, always yielding the correct answer.

Best regards,
Rick C. Hodgin

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

#75864

On Thursday, November 12, 2015 at 12:01:28 PM UTC-6, Rick C. Hodgin wrote:
> Computers should do what we (people/developers) expect, and our goals and
> needs should not be subject to odd quirks based on the mechanical
> peculiarities of the way computers must process binary data, when such a
> requirement is not truly a fundamental requirement.
>
> As such, CAlive takes that perspective...

I'm with you so far.

> CAlive's goals are to process data in the correct form as per the software
> developer's point of view, possibly at the sacrifice of machine performance.
> In this way, a signed and unsigned compare will always compare properly
> as by the next-larger signed value, always yielding the correct answer.

Given "unsigned x=1; int y=-1;", having "x>y" yield 0 may violate the
expectations of many people, but having it yield 1 would violate those of
many other people.  Having the compiler reject the expression outright would
avoid having the program behave in unexpected fashion at some unknown future
time.

Is there any particular reason you are opposed to the idea that if something
would be valid C code and valid CAlive code, the semantics should be the same
in both languages?

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

#75867

On Thursday, November 12, 2015 at 2:11:08 PM UTC-5, supe...@casperkitty.com wrote:
> On Thursday, November 12, 2015 at 12:01:28 PM UTC-6, Rick C. Hodgin wrote:
> > Computers should do what we (people/developers) expect, and our goals and
> > needs should not be subject to odd quirks based on the mechanical
> > peculiarities of the way computers must process binary data, when such a
> > requirement is not truly a fundamental requirement.
> >
> > As such, CAlive takes that perspective...
> 
> I'm with you so far.
> 
> > CAlive's goals are to process data in the correct form as per the software
> > developer's point of view, possibly at the sacrifice of machine performance.
> > In this way, a signed and unsigned compare will always compare properly
> > as by the next-larger signed value, always yielding the correct answer.
> 
> Given "unsigned x=1; int y=-1;", having "x>y" yield 0 may violate the
> expectations of many people, but having it yield 1 would violate those of
> many other people.  Having the compiler reject the expression outright would
> avoid having the program behave in unexpected fashion at some unknown future
> time.

I think your solution is inappropriate because the relationship of the
numeric expressions contained within their holders exists fundamentally.
If you substitute their values out and compare "1>-1" everybody would
agree on the result.  As such, the compiler should do that as well.

> Is there any particular reason you are opposed to the idea that if something
> would be valid C code and valid CAlive code, the semantics should be the same
> in both languages?

Syntax.  I think C syntax is elegant in places.  I think it's inelegant
and confusing in others.  So, I allow both:

    for (i = 0; i < 10; i++)
    {
        // Code goes here
    }

Great, but what about:

    for (line = parentObject->line; line; line = line->ll.next)
    {
        // Code goes here
    }

A little more unwieldly, not easy to break out naturally with the eye.
And if you extend it to include a few iterative definitions, tests, and
operators:

    for (line = parentObject->line, count = 0, processed = 0; line; line = line->ll.next, count++)
    {
        // Code goes here
        // If processed:
            ++processed;
    }

So I allow:

    for shortcut name
    | init line = parentObject->line, count = 0, processed = 0
    | test line
    | step line = line->ll.next, count++
    {
        // Code goes here
        // If processed:
            ++processed;
    }

Which can also be written out as:

    for shortcut name
    | init line = parentObject->line
    | init count = 0
    | init processed = 0
    |
    | test line
    |
    | step line = line->ll.next
    | step count++
    {
        // Code goes here
        // If processed:
            ++processed;
    }

And then collapsed in the GUI editor to its shortcut name, which
presumably would convey some real meaning to the developer:

    for [+] process up to 10 lines
    {
        // Code goes here
        // If processed:
            ++processed;
    }

The same could also be achieved with a [|definition cask|]:

    for ([||line = parentObject->line, count = 0, processed = 0|line|line = line->ll.next, count++||].name(process up to 10 lines))
    {
        // Code goes here
        // If processed:
            ++processed;
    }

Which then reduces to:

    for ([o||process up to 10 lines||o]))
    {
        // Code goes here
        // If processed:
            ++processed;
    }

A little more unwieldly, but still compacted.  And, ultimately the
whole expression could be combined:

    ~|{{for (line = parentObject->line, count = 0, processed = 0; line; line = line->ll.next, count++)
    {
        // Code goes here
        // If processed:
            ++processed;
    }
    }}|~.name(process up to 10 lines)

Which reduces down to one line of code which can then also be copied
as a unit, inserted here or there, etc:

    ~|process up to 10 lines|~

And single-stepping through the debugger at this cask level would
skip over all 10 iterations automatically as a single step.

-----
I just want source code to be more documenting while maintaining the
same low level features of a C-like language.  And I want to be able
to wield complex constructs as individual pieces.

Best regards,
Rick C. Hodgin

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

#75871

On Thursday, November 12, 2015 at 1:31:57 PM UTC-6, Rick C. Hodgin wrote:
> I think your solution is inappropriate because the relationship of the
> numeric expressions contained within their holders exists fundamentally.
> If you substitute their values out and compare "1>-1" everybody would
> agree on the result.  As such, the compiler should do that as well.

The value 1 is a number.  So is -1.  The value 1u is not a number; on a
32-bit system, it behaves mostly as a member of the equivalence class of
integers congruent to 1 mod 4294967296, and in turn as a member of the
ring of such equivalence classes.

Thus, if one has any integer which is congruent to 1 mod 4294967296 and
one subtracts any integer which is congruent to 2 mod 4294967296, one will
get an integer which is congruent to 4294967295 mod 4294967296; this is
represented in C by the fact that on a 32-bit system, 1u-2u==4294967295u.

Much of the confusion regarding unsigned types in C stems from the fact
that they mostly behave like algebraic ring members, but not absolutely
consistently.  I would suggest that using cleanly-separated ring types and
number types would alleviate a lot of the confusion.

>supercat wrote:
>>Is there any particular reason you are opposed to the idea that if something
>>would be valid C code and valid CAlive code, the semantics should be the same
>>in both languages?
> 
> Syntax. . . .
> So I allow:
> 
>     for shortcut name
>     | init line = parentObject->line, count = 0, processed = 0
>     | test line
>     | step line = line->ll.next, count++
>     {
>         // Code goes here
>         // If processed:
>             ++processed;
>     }

Since I don't think any C compiler would accept the latter syntax, it isn't
relevant to my concern.  CAlive should accept some things that C rejects, and
probably should reject some things which C accepts.  My concern is that things
which are *accepted by both* should have the same meaning on both.

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

#75874

On Thursday, November 12, 2015 at 3:14:44 PM UTC-5, supe...@casperkitty.com wrote:
> On Thursday, November 12, 2015 at 1:31:57 PM UTC-6, Rick C. Hodgin wrote:
> > I think your solution is inappropriate because the relationship of the
> > numeric expressions contained within their holders exists fundamentally.
> > If you substitute their values out and compare "1>-1" everybody would
> > agree on the result.  As such, the compiler should do that as well.
> 
> The value 1 is a number.  So is -1.  The value 1u is not a number; on a
> 32-bit system,

When peered through the lens of the "x > y" expression, it behaves as
a number.

> it behaves mostly as a member of the equivalence class of
> integers congruent to 1 mod 4294967296, and in turn as a member of the
> ring of such equivalence classes.
> 
> Thus, if one has any integer which is congruent to 1 mod 4294967296 and
> one subtracts any integer which is congruent to 2 mod 4294967296, one will
> get an integer which is congruent to 4294967295 mod 4294967296; this is
> represented in C by the fact that on a 32-bit system, 1u-2u==4294967295u.
> 
> Much of the confusion regarding unsigned types in C stems from the fact
> that they mostly behave like algebraic ring members, but not absolutely
> consistently.  I would suggest that using cleanly-separated ring types and
> number types would alleviate a lot of the confusion.

CAlive will treat them as by the operator they relate to.  In tests for
in/equality, they will be numbers.

> >supercat wrote:
> >>Is there any particular reason you are opposed to the idea that if something
> >>would be valid C code and valid CAlive code, the semantics should be the same
> >>in both languages?
> > 
> > Syntax. . . .
> > So I allow:
> > 
> >     for shortcut name
> >     | init line = parentObject->line, count = 0, processed = 0
> >     | test line
> >     | step line = line->ll.next, count++
> >     {
> >         // Code goes here
> >         // If processed:
> >             ++processed;
> >     }
> 
> Since I don't think any C compiler would accept the latter syntax, it isn't
> relevant to my concern.  CAlive should accept some things that C rejects, and
> probably should reject some things which C accepts.  My concern is that things
> which are *accepted by both* should have the same meaning on both.

To my knowledge they will, apart from perhaps some "fringe semantics,"
which would relate to peculiarities of C as you indicate, which are
resolved in CAlive as being non-issues in all cases, perhaps at the
sacrifice of some performance (measured in clock cycles).

Best regards,
Rick C. Hodgin

[toc] | [prev] | [standalone]

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

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

csiph-web