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

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

Forward declarations ... the straw that broke the camel's back

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

Contents

  Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-29 10:36 -0700
    Re: Forward declarations ... the straw that broke the camel's back supercat@casperkitty.com - 2016-06-29 16:04 -0700
      Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-29 16:30 -0700
        Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-29 19:52 -0700
          Re: Forward declarations ... the straw that broke the camel's back Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-30 13:00 +0100
            Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 05:42 -0700
              Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 18:11 +0100
                Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 10:30 -0700
                  Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 19:54 +0100
                    Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 12:31 -0700
                      Re: Forward declarations ... the straw that broke the camel's back Ian Collins <ian-news@hotmail.com> - 2016-07-01 07:59 +1200
                        Re: Forward declarations ... the straw that broke the camel's back Gareth Owen <gwowen@gmail.com> - 2016-06-30 21:31 +0100
                        Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 14:19 -0700
                          Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 14:31 -0700
                      Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 21:18 +0100
                        Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 14:26 -0700
                          Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 22:44 +0100
                            Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 17:23 -0700
                  Re: Forward declarations ... the straw that broke the camel's back David Brown <david.brown@hesbynett.no> - 2016-07-05 21:38 +0200
                    Re: Forward declarations ... the straw that broke the camel's back Richard Heathfield <rjh@cpax.org.uk> - 2016-07-05 21:05 +0100
                    Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-05 13:32 -0700
                      Re: Forward declarations ... the straw that broke the camel's back David Brown <david.brown@hesbynett.no> - 2016-07-05 23:20 +0200
                        Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-05 14:25 -0700
                        Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-05 16:14 -0700
                          Re: Forward declarations ... the straw that broke the camel's back David Brown <david.brown@hesbynett.no> - 2016-07-06 11:18 +0200
                            Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-06 03:36 -0700
                        Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-05 16:23 -0700
                          Re: Forward declarations ... the straw that broke the camel's back David Brown <david.brown@hesbynett.no> - 2016-07-06 11:29 +0200
                            Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-06 02:49 -0700
                              Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-06 05:18 -0700
                                Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-07-06 13:57 +0100
                                  Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-06 06:24 -0700
                              Re: Forward declarations ... the straw that broke the camel's back David Brown <david.brown@hesbynett.no> - 2016-07-06 15:22 +0200
                                Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-06 07:12 -0700
                                Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-06 08:08 -0700
                                  Re: Forward declarations ... the straw that broke the camel's back supercat@casperkitty.com - 2016-07-06 09:00 -0700
                                    Re: Forward declarations ... the straw that broke the camel's back Ian Collins <ian-news@hotmail.com> - 2016-07-07 08:01 +1200
                                      Re: Forward declarations ... the straw that broke the camel's back supercat@casperkitty.com - 2016-07-06 13:30 -0700
                                Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-07-06 17:30 +0100
      Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 00:39 +0100
        Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-06-30 22:08 +0200
    Re: Forward declarations ... the straw that broke the camel's back gordonb.h5sc5@burditt.org (Gordon Burditt) - 2016-06-29 20:52 -0500
      Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-29 19:00 -0700
        Re: Forward declarations ... the straw that broke the camel's back Ian Collins <ian-news@hotmail.com> - 2016-06-30 16:06 +1200
          Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-30 02:48 -0700
            Re: Forward declarations ... the straw that broke the camel's back Ian Collins <ian-news@hotmail.com> - 2016-06-30 23:25 +1200
              Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-30 04:39 -0700
                Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-06-30 21:50 +0200
              Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 06:49 -0700
                Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-06-30 22:23 +0200
                  Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-04 10:43 -0700
                    Vaporware (Was: Forward declarations ... the straw that broke ...) gazelle@shell.xmission.com (Kenny McCormack) - 2016-07-04 17:59 +0000
                    Re: Forward declarations ... the straw that broke the camel's back Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-06 12:38 -0500
                      Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-06 11:38 -0700
            Re: Forward declarations ... the straw that broke the camel's back Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-30 19:51 +0100
              Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-06-30 21:59 +0200
                Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-01 01:05 -0700
          Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 11:32 +0100
            Re: Forward declarations ... the straw that broke the camel's back Ian Collins <ian-news@hotmail.com> - 2016-06-30 23:23 +1200
              Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 14:28 +0100
                Re: Forward declarations ... the straw that broke the camel's back supercat@casperkitty.com - 2016-06-30 08:24 -0700
                  Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 16:56 +0100
                Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-06-30 22:17 +0200
                  Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 22:22 +0100
                    Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-01 08:25 +0200
                      Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-07-01 12:09 +0100

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

#90052

On Tuesday, July 5, 2016 at 3:39:03 PM UTC-4, David Brown wrote:
> On 30/06/16 19:30, Rick C. Hodgin wrote:
> > On Thursday, June 30, 2016 at 1:11:48 PM UTC-4, Bart wrote:
> >> On 30/06/2016 13:42, Rick C. Hodgin wrote:
> >>> On Thursday, June 30, 2016 at 8:00:23 AM UTC-4, Ben Bacarisse wrote:
> >>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >>>>> Types are a nuisance.
> >>>>
> >>>> Many people think quite the opposite.  Types are a huge convenience...
> >>>
> >>> My only issue regarding types is that in C and C++ they must be declared
> >>> before use, even if they're declared later on in the same source file,
> >>> or in a later include file that's still in scope relative to the compile
> >>> instance.
> >>
> >> Why would declaring types ahead of use be an issue?
> >
> > It's as I described in my OP.
> >
> > Because it requires that all things be declared ahead of use, as you have
> > mentioned in this thread.  Some master "all_structs.h" file with all of
> > the types used throughout the system.
> >
> > I don't want that.  I want to include the SVariable type in the variable.h
> > header, along with its prototype definitions and other related declarations.
> > Then in the variables.cpp are all the body functions.  But since SVariable
> > is a first class citizen in my project, other modules use it, such as
> > SReport directly knows about the SVariable type, and SDatabase knows about
> > the variable type.  So now I've got other header files declaring references
> > to the SVariable type, which by pointer isn't an issue, but if it's by non-
> > pointer, then it's an issue.
> >
> 
> Maybe I am misunderstanding something here.  It looks like you want to 
> be able to declare the type SVariable in a header file "svariable.h" and 
> its associated functions in "svariable.c".  And you now want to be able 
> to use your SVariable types in all files, including the structure 
> definition of "SReport" in "sreport.h".  So why not simply #include 
> "svariable.h" in "svariable.h" ?
> 
> // File svariable.h
> #ifndef SVARIABLE_H_
> #define SVARIABLE_H_
> 
> #include <stdint.h>
> typedef struct {
> 	uint32_t a32;
> 	uint16_t a16;
> 	uint8_t a8;
> } SVariable;
> 
> #endif		// #ifndef SVARIABLE_H_
> 
> // File sreport.h
> #ifndef SREPORT_H_
> #define SREPORT_H_
> 
> #include <stdbool.h>
> #include "svariable.h"
> typedef struct {
> 	SVariable var;
> 	bool b;
> } SReport;
> 
> #endif		// #ifndef SREPORT_H_
> 
> 
> // File foo.c
> #include "sreport.h"
> SReport rep;
> 
> 
> You are only ever declaring your types once (which you usually have to 
> do somewhere).  If you have intertwined types with fields that are 
> pointers to each other, then they are so closely related that it is 
> usually natural to put them in the same header.

That's the C way of doing things.  I don't want that.  It's not a good
solution in my opinion.  I also don't want to #include something, but
would rather import it, and then have it be of a particular form which
completely handles everything it needs internally.  I've added the
ability in a function to automatically undef it if there's a dependency
missing, so that if SReport is not present, then the related SReport
features will automatically be excluded, without having to surround the
code in an #ifdef / #endif block.

I'm trying to rethink programming, keeping what's good, and leaving
what's bad, and making CAlive be more than just C or C++.

I basically want to include the things I need in my application one time,
and in the exact program that's using them, then they are auto-handled
internally.

I'm even considering doing away with the .h concept at all and creating
a comparable single-source file which includes header definitions and
source files and call it a .cai file (a CAlive import).

That way you'll have .ca source files, and .cai import files.  The
syntax of the .cai file will allow either direct source code or library
references without then having to add any linker settings.

Best regards,
Rick C. Hodgin

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

#90054

On 05/07/16 22:32, Rick C. Hodgin wrote:
> On Tuesday, July 5, 2016 at 3:39:03 PM UTC-4, David Brown wrote:
>> On 30/06/16 19:30, Rick C. Hodgin wrote:
>>> On Thursday, June 30, 2016 at 1:11:48 PM UTC-4, Bart wrote:
>>>> On 30/06/2016 13:42, Rick C. Hodgin wrote:
>>>>> On Thursday, June 30, 2016 at 8:00:23 AM UTC-4, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>>>>> Types are a nuisance.
>>>>>>
>>>>>> Many people think quite the opposite.  Types are a huge convenience...
>>>>>
>>>>> My only issue regarding types is that in C and C++ they must be declared
>>>>> before use, even if they're declared later on in the same source file,
>>>>> or in a later include file that's still in scope relative to the compile
>>>>> instance.
>>>>
>>>> Why would declaring types ahead of use be an issue?
>>>
>>> It's as I described in my OP.
>>>
>>> Because it requires that all things be declared ahead of use, as you have
>>> mentioned in this thread.  Some master "all_structs.h" file with all of
>>> the types used throughout the system.
>>>
>>> I don't want that.  I want to include the SVariable type in the variable.h
>>> header, along with its prototype definitions and other related declarations.
>>> Then in the variables.cpp are all the body functions.  But since SVariable
>>> is a first class citizen in my project, other modules use it, such as
>>> SReport directly knows about the SVariable type, and SDatabase knows about
>>> the variable type.  So now I've got other header files declaring references
>>> to the SVariable type, which by pointer isn't an issue, but if it's by non-
>>> pointer, then it's an issue.
>>>
>>
>> Maybe I am misunderstanding something here.  It looks like you want to
>> be able to declare the type SVariable in a header file "svariable.h" and
>> its associated functions in "svariable.c".  And you now want to be able
>> to use your SVariable types in all files, including the structure
>> definition of "SReport" in "sreport.h".  So why not simply #include
>> "svariable.h" in "svariable.h" ?
>>
>> // File svariable.h
>> #ifndef SVARIABLE_H_
>> #define SVARIABLE_H_
>>
>> #include <stdint.h>
>> typedef struct {
>> 	uint32_t a32;
>> 	uint16_t a16;
>> 	uint8_t a8;
>> } SVariable;
>>
>> #endif		// #ifndef SVARIABLE_H_
>>
>> // File sreport.h
>> #ifndef SREPORT_H_
>> #define SREPORT_H_
>>
>> #include <stdbool.h>
>> #include "svariable.h"
>> typedef struct {
>> 	SVariable var;
>> 	bool b;
>> } SReport;
>>
>> #endif		// #ifndef SREPORT_H_
>>
>>
>> // File foo.c
>> #include "sreport.h"
>> SReport rep;
>>
>>
>> You are only ever declaring your types once (which you usually have to
>> do somewhere).  If you have intertwined types with fields that are
>> pointers to each other, then they are so closely related that it is
>> usually natural to put them in the same header.
>
> That's the C way of doing things.

This is a C newsgroup, and your question/complaint/issue was the trouble 
you were having in writing this sort of thing in C.  So a C way of doing 
it is a pretty good start.

> I don't want that.  It's not a good
> solution in my opinion.

That's not a justification.

> I also don't want to #include something, but
> would rather import it, and then have it be of a particular form which
> completely handles everything it needs internally.

If you want some sort of modules, with an "import" rather than an 
"#include", then that's not a bad idea for a new language - it is widely 
considered to be a missing feature for C and C++.  People are working on 
them for C++, where compilation of headers is a serious time-waster 
(unlike in C, where it is only noticeable problem in the minds of a few 
people).  But that does not change the situation here - it just makes 
things a little more efficient if you have big files.

>  I've added the
> ability in a function to automatically undef it if there's a dependency
> missing, so that if SReport is not present, then the related SReport
> features will automatically be excluded, without having to surround the
> code in an #ifdef / #endif block.

That sounds terrible, but of course that is merely my opinion.

>
> I'm trying to rethink programming, keeping what's good, and leaving
> what's bad, and making CAlive be more than just C or C++.
>

You make it sound like there is some clear distinction between "good" 
and "bad" features of programming.  Your CAlive project is highly 
personal - it is about rethinking how /you/ want to program, keeping 
what /you/ think is good, and discarding what /you/ think is bad. 
That's fair enough - you are trying to make the perfect language for 
/you/.  But never forget that it is your personal language fitting your 
personal ideas about programming - there is nothing objective about it.

> I basically want to include the things I need in my application one time,
> and in the exact program that's using them, then they are auto-handled
> internally.

If you were to write your code as a collection of .h and .c files, it 
should not be a difficult issue to have a built system that sorts this 
out automatically without moving an inch from standard C.  A makefile 
with a spot of scripting could easily allow the individual headers to be 
collected and automatically #include'd into each C file when you do a build.

>
> I'm even considering doing away with the .h concept at all and creating
> a comparable single-source file which includes header definitions and
> source files and call it a .cai file (a CAlive import).

Add a call to "cproto" to the builder.

I am not saying that your ideas here are bad for your CAlive project - 
if I were creating a new language, I would definitely have some kind of 
proper module system rather than C's "copy-and-paste" pre-processor 
includes.  I would also probably allow file/global scope and namespace 
scope (but /not/ local, block or function scope) functions, types and 
data to be used before declaration.

So my point is not that they are bad ideas, but that C is not really as 
bad as you seem to imagine here, and you can come quite close to your 
desires with creative use of build scripts and/or code preprocssing, 
without having to create a whole new language.  You might get to program 
closer to the way you want before CAlive is ready.

>
> That way you'll have .ca source files, and .cai import files.  The
> syntax of the .cai file will allow either direct source code or library
> references without then having to add any linker settings.
>
> Best regards,
> Rick C. Hodgin
>

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

#90055

On Tuesday, July 5, 2016 at 5:20:46 PM UTC-4, David Brown wrote:
> On 05/07/16 22:32, Rick C. Hodgin wrote:
> > On Tuesday, July 5, 2016 at 3:39:03 PM UTC-4, David Brown wrote:
> >> On 30/06/16 19:30, Rick C. Hodgin wrote:
> >>> On Thursday, June 30, 2016 at 1:11:48 PM UTC-4, Bart wrote:
> >>>> On 30/06/2016 13:42, Rick C. Hodgin wrote:
> >>>>> On Thursday, June 30, 2016 at 8:00:23 AM UTC-4, Ben Bacarisse wrote:
> >>>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >>>>>>> Types are a nuisance.
> >>>>>>
> >>>>>> Many people think quite the opposite.  Types are a huge convenience...
> >>>>>
> >>>>> My only issue regarding types is that in C and C++ they must be declared
> >>>>> before use, even if they're declared later on in the same source file,
> >>>>> or in a later include file that's still in scope relative to the compile
> >>>>> instance.
> >>>>
> >>>> Why would declaring types ahead of use be an issue?
> >>>
> >>> It's as I described in my OP.
> >>>
> >>> Because it requires that all things be declared ahead of use, as you have
> >>> mentioned in this thread.  Some master "all_structs.h" file with all of
> >>> the types used throughout the system.
> >>>
> >>> I don't want that.  I want to include the SVariable type in the variable.h
> >>> header, along with its prototype definitions and other related declarations.
> >>> Then in the variables.cpp are all the body functions.  But since SVariable
> >>> is a first class citizen in my project, other modules use it, such as
> >>> SReport directly knows about the SVariable type, and SDatabase knows about
> >>> the variable type.  So now I've got other header files declaring references
> >>> to the SVariable type, which by pointer isn't an issue, but if it's by non-
> >>> pointer, then it's an issue.
> >>>
> >>
> >> Maybe I am misunderstanding something here.  It looks like you want to
> >> be able to declare the type SVariable in a header file "svariable.h" and
> >> its associated functions in "svariable.c".  And you now want to be able
> >> to use your SVariable types in all files, including the structure
> >> definition of "SReport" in "sreport.h".  So why not simply #include
> >> "svariable.h" in "svariable.h" ?
> >>
> >> // File svariable.h
> >> #ifndef SVARIABLE_H_
> >> #define SVARIABLE_H_
> >>
> >> #include <stdint.h>
> >> typedef struct {
> >> 	uint32_t a32;
> >> 	uint16_t a16;
> >> 	uint8_t a8;
> >> } SVariable;
> >>
> >> #endif		// #ifndef SVARIABLE_H_
> >>
> >> // File sreport.h
> >> #ifndef SREPORT_H_
> >> #define SREPORT_H_
> >>
> >> #include <stdbool.h>
> >> #include "svariable.h"
> >> typedef struct {
> >> 	SVariable var;
> >> 	bool b;
> >> } SReport;
> >>
> >> #endif		// #ifndef SREPORT_H_
> >>
> >>
> >> // File foo.c
> >> #include "sreport.h"
> >> SReport rep;
> >>
> >>
> >> You are only ever declaring your types once (which you usually have to
> >> do somewhere).  If you have intertwined types with fields that are
> >> pointers to each other, then they are so closely related that it is
> >> usually natural to put them in the same header.
> >
> > That's the C way of doing things.
> 
> This is a C newsgroup, and your question/complaint/issue was the trouble 
> you were having in writing this sort of thing in C.  So a C way of doing 
> it is a pretty good start.
> 
> > I don't want that.  It's not a good
> > solution in my opinion.
> 
> That's not a justification.
> 
> > I also don't want to #include something, but
> > would rather import it, and then have it be of a particular form which
> > completely handles everything it needs internally.
> 
> If you want some sort of modules, with an "import" rather than an 
> "#include", then that's not a bad idea for a new language - it is widely 
> considered to be a missing feature for C and C++.  People are working on 
> them for C++, where compilation of headers is a serious time-waster 
> (unlike in C, where it is only noticeable problem in the minds of a few 
> people).  But that does not change the situation here - it just makes 
> things a little more efficient if you have big files.
> 
> >  I've added the
> > ability in a function to automatically undef it if there's a dependency
> > missing, so that if SReport is not present, then the related SReport
> > features will automatically be excluded, without having to surround the
> > code in an #ifdef / #endif block.
> 
> That sounds terrible, but of course that is merely my opinion.
> 
> >
> > I'm trying to rethink programming, keeping what's good, and leaving
> > what's bad, and making CAlive be more than just C or C++.
> >
> 
> You make it sound like there is some clear distinction between "good" 
> and "bad" features of programming.  Your CAlive project is highly 
> personal - it is about rethinking how /you/ want to program, keeping 
> what /you/ think is good, and discarding what /you/ think is bad. 
> That's fair enough - you are trying to make the perfect language for 
> /you/.  But never forget that it is your personal language fitting your 
> personal ideas about programming - there is nothing objective about it.
> 
> > I basically want to include the things I need in my application one time,
> > and in the exact program that's using them, then they are auto-handled
> > internally.
> 
> If you were to write your code as a collection of .h and .c files, it 
> should not be a difficult issue to have a built system that sorts this 
> out automatically without moving an inch from standard C.  A makefile 
> with a spot of scripting could easily allow the individual headers to be 
> collected and automatically #include'd into each C file when you do a build.
> 
> >
> > I'm even considering doing away with the .h concept at all and creating
> > a comparable single-source file which includes header definitions and
> > source files and call it a .cai file (a CAlive import).
> 
> Add a call to "cproto" to the builder.
> 
> I am not saying that your ideas here are bad for your CAlive project - 
> if I were creating a new language, I would definitely have some kind of 
> proper module system rather than C's "copy-and-paste" pre-processor 
> includes.  I would also probably allow file/global scope and namespace 
> scope (but /not/ local, block or function scope) functions, types and 
> data to be used before declaration.
> 
> So my point is not that they are bad ideas, but that C is not really as 
> bad as you seem to imagine here, and you can come quite close to your 
> desires with creative use of build scripts and/or code preprocssing, 
> without having to create a whole new language.  You might get to program 
> closer to the way you want before CAlive is ready.
> 
> >
> > That way you'll have .ca source files, and .cai import files.  The
> > syntax of the .cai file will allow either direct source code or library
> > references without then having to add any linker settings.

You are an expert in the field and I appreciate your input, David.  Thank
you for taking the time.

Best regards,
Rick C. Hodgin

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

#90056

On Tuesday, July 5, 2016 at 5:20:46 PM UTC-4, David Brown wrote:
> On 05/07/16 22:32, Rick C. Hodgin wrote:
> > I've added the
> > ability in a function to automatically undef it if there's a dependency
> > missing, so that if SReport is not present, then the related SReport
> > features will automatically be excluded, without having to surround the
> > code in an #ifdef / #endif block.
> 
> That sounds terrible...

Do you understand it?  And if so, why do you think it's terrible?

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

In CAlive, the compiler and linker are tightly married together.  Some
compilation can be deferred until link time:

    https://groups.google.com/forum/#!topic/caliveprogramminglanguage/9zQ1_KxNz7M

This feature is for stand-alone compilation that is not part of the
normal GUI IDE where continuous compilation is utilized.

Best regards,
Rick C. Hodgin

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

#90067

On 06/07/16 01:14, Rick C. Hodgin wrote:
> On Tuesday, July 5, 2016 at 5:20:46 PM UTC-4, David Brown wrote:
>> On 05/07/16 22:32, Rick C. Hodgin wrote:
>>> I've added the
>>> ability in a function to automatically undef it if there's a dependency
>>> missing, so that if SReport is not present, then the related SReport
>>> features will automatically be excluded, without having to surround the
>>> code in an #ifdef / #endif block.
>>
>> That sounds terrible...
> 
> Do you understand it?  And if so, why do you think it's terrible?

I understand it.  But it makes it very difficult to know if the code you
are writing is actually going to be compiled - is the code part of the
program or not?  Will it be partly compiled (parsed, syntax checked,
etc.) or ignored?  Will it be sort-of compiled first, and then at
link-time it will either be fully compiled or scrapped?  (Plus, I
/really/ don't like your syntax for this sort of thing - but that's
personal opinion.)

It is all so completely unnecessary - at least for the sample you show
there.  Why not simply say that the compiler/linker will automatically
exclude functions that are not used?

If the relevant dependencies for the function are missing, then there
are two possible situations.  Either the function is used in code, and
you have to have an error message somewhere saying this is not possible.
 Or the function is not used in code, in which case the situation can be
detected automatically and the code excluded without an error message.

You can think of this as a sort of middle-ground between C and Python.
Python has run-time dependency resolution, which can make it easy to
write flexible code but loses out on static error checking.  C has
compile-time dependency resolution, which gives you errors early but
means that the compiler has to have all the relevant information on hand
while compiling each module (something that you dislike, though I still
don't really understand why).  But what you can have here is link-time
dependency resolution, giving you the advantages of static error
checking and efficient code generation, without needing to have
everything on-hand during compilation.

That, I think, gives you the best arrangement (based on my understanding
of your desires for CAlive).  And it can be done without adding more
verbose annotations to the code - it can be done automatically for all
functions.


> 
>     https://groups.google.com/forum/#!topic/caliveprogramminglanguage/y2oErllepxg
> 
> In CAlive, the compiler and linker are tightly married together.  Some
> compilation can be deferred until link time:
> 
>     https://groups.google.com/forum/#!topic/caliveprogramminglanguage/9zQ1_KxNz7M
> 
> This feature is for stand-alone compilation that is not part of the
> normal GUI IDE where continuous compilation is utilized.
> 
> Best regards,
> Rick C. Hodgin
> 

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

#90073

On Wednesday, July 6, 2016 at 5:18:40 AM UTC-4, David Brown wrote:
> On 06/07/16 01:14, Rick C. Hodgin wrote:
> > On Tuesday, July 5, 2016 at 5:20:46 PM UTC-4, David Brown wrote:
> >> On 05/07/16 22:32, Rick C. Hodgin wrote:
> >>> I've added the
> >>> ability in a function to automatically undef it if there's a dependency
> >>> missing, so that if SReport is not present, then the related SReport
> >>> features will automatically be excluded, without having to surround the
> >>> code in an #ifdef / #endif block.
> >>
> >> That sounds terrible...
> > 
> > Do you understand it?  And if so, why do you think it's terrible?
> 
> I understand it.  But it makes it very difficult to know if the code you
> are writing is actually going to be compiled - is the code part of the
> program or not?  Will it be partly compiled (parsed, syntax checked,
> etc.) or ignored?  Will it be sort-of compiled first, and then at
> link-time it will either be fully compiled or scrapped?

If your application references a function that's not included, then in the
case of it being undef'd it will generate an error, and give the reason
why it's not present (because it was undef'd).  You can then import or
include the missing module, and it goes away.  The GUI IDE will also have
auto-fixups for these sorts of errors with something like, "Load missing
import."

> (Plus, I
> /really/ don't like your syntax for this sort of thing - but that's
> personal opinion.)

It's adapted from XBASE, which is very verbose.  In this case it conveys
the whole meaning in a human-readable form.

> It is all so completely unnecessary - at least for the sample you show
> there.  Why not simply say that the compiler/linker will automatically
> exclude functions that are not used?

It's a different way of looking at coding, but within this view I believe
it is necessary.

> If the relevant dependencies for the function are missing, then there
> are two possible situations.  Either the function is used in code, and
> you have to have an error message somewhere saying this is not possible.
>  Or the function is not used in code, in which case the situation can be
> detected automatically and the code excluded without an error message.

Excluding unused code is a separate issue altogether, and not necessarily
agood idea for an edit-and-continue compiler wrapped in a rapid development
framework.

It would be better to include the extra use of resources, and then have
them linkable when future code adds to it.  But, that's also an option
which merely introduces time in compilation and linking when a thing not
previously used is now required.

> You can think of this as a sort of middle-ground between C and Python.
> Python has run-time dependency resolution, which can make it easy to
> write flexible code but loses out on static error checking.  C has
> compile-time dependency resolution, which gives you errors early but
> means that the compiler has to have all the relevant information on hand
> while compiling each module (something that you dislike, though I still
> don't really understand why).  But what you can have here is link-time
> dependency resolution, giving you the advantages of static error
> checking and efficient code generation, without needing to have
> everything on-hand during compilation.

CAlive allows you to compile and run broken code.  When it gets to
something that is not resolvable, it generates an inquiry, which is a
type of exception.  The inquiry is called "inquiry" because it then
inquires of the developer how to proceed.  Since it's an edit-and-continue
compiler, the developer can then complete the missing code on-the-fly,
allowing whatever caused the inquiry to go away.

And it will generate inquirys on other exceptions, all because there is
the edit-and-continue ability to fix the issue and continue without
having to restart.

Remember, this is a Rapid Development Framework.  My goals in writing this
type of compiler are in helping developers write code.  Once the code is
developed and debugged, a special runtime inquiry handler is created which
would terminate the program on exception, for example, a process that I
call "unengage" as the process is unenaged.

> That, I think, gives you the best arrangement (based on my understanding
> of your desires for CAlive).  And it can be done without adding more
> verbose annotations to the code - it can be done automatically for all
> functions.

It's a different way of looking at things.  It's not the C way, but as I
examine different languages and consider things from a fundamental point
of view, I am concluding what things should exist, and what things should
not exist.

Forward declaration requirements, for example, should not exist.  Ever
(because computers are tools and they can do things, and we shouldn't
limit them in their ability to help us developers).

Best regards,
Rick C. Hodgin

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

#90057

On Tuesday, July 5, 2016 at 5:20:46 PM UTC-4, David Brown wrote:
> ... and you can come quite close to your 
> desires with creative use of build scripts and/or code preprocssing, 
> without having to create a whole new language.  You might get to program 
> closer to the way you want before CAlive is ready.

You seem to forget that I am not interested in building things atop those
efforts which have not been given over to the Lord.  I am desiring to
create a foundation upon which I can move forward in this world on a solid,
top-to-bottom, effort given over to the Lord.

It is my offering to worship Him in this world, that I am not content to
use existing toolsets and write everything in them.

I have been trying since the mid-90s to write alternative products to
Microsoft's tools.  For a time I used Linux, but in 2012 I learned about
Stallman's beliefs, and I had grown in my Christian faith, and I came to
realize that it means something who you serve in this world.

I desire to serve the Lord, so I move forward in these ways offering up
from inside me that which He first gave me, the fruits and talents of
the skills I possess.  I keep asking for help, and someday that help
will come.

Best regards,
Rick C. Hodgin

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

#90068

On 06/07/16 01:23, Rick C. Hodgin wrote:
> On Tuesday, July 5, 2016 at 5:20:46 PM UTC-4, David Brown wrote:
>> ... and you can come quite close to your 
>> desires with creative use of build scripts and/or code preprocssing, 
>> without having to create a whole new language.  You might get to program 
>> closer to the way you want before CAlive is ready.
> 
> You seem to forget that I am not interested in building things atop those
> efforts which have not been given over to the Lord.  I am desiring to
> create a foundation upon which I can move forward in this world on a solid,
> top-to-bottom, effort given over to the Lord.
> 

Oh, I haven't forgotten anything here - and you post no shortage of
reminders.

But the reality is that CAlive is, at the moment, very much vapourware.
 It will be a /long/ time before it is ready for use.  That means you
are stuck using existing real-world programming languages and tools to
do your development work.  You seem determined to use C (via a C++
compiler) despite how much you seem to dislike the language and despite
its questionable suitability for developing a compiler or IDE.  I am
merely trying to give you ideas that might help you use C in a way that
would bother you less - if you can work around the features or
restrictions of C that cause you most irritation, then you can be more
productive and happier when working with it (until CAlive is bootstrapped).

> It is my offering to worship Him in this world, that I am not content to
> use existing toolsets and write everything in them.
> 
> I have been trying since the mid-90s to write alternative products to
> Microsoft's tools.  For a time I used Linux, but in 2012 I learned about
> Stallman's beliefs, and I had grown in my Christian faith, and I came to
> realize that it means something who you serve in this world.
> 
> I desire to serve the Lord, so I move forward in these ways offering up
> from inside me that which He first gave me, the fruits and talents of
> the skills I possess.  I keep asking for help, and someday that help
> will come.
> 
> Best regards,
> Rick C. Hodgin
> 

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

#90070

On Wednesday, July 6, 2016 at 10:29:13 AM UTC+1, David Brown wrote:
> On 06/07/16 01:23, Rick C. Hodgin wrote:
>
> You seem determined to use C (via a C++ compiler) despite how much you seem to 
> dislike the language and despite its questionable suitability for developing a compiler or IDE.  
>
If I was writing a compiler for a new language as a one man project, the fact I was doing
so would imply that I didn't think C or any other established language was totally
suitable for my purposes. So it's quite likely I'd have many criticisms to make of C.

However I would implement the compiler in a  conservative subset of ANSI C and
output a similarly conservative subset. That gives the project maximum chance of 
longevity and usefulness.

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

#90074

On Wednesday, July 6, 2016 at 5:49:38 AM UTC-4, Malcolm McLean wrote:
> If I was writing a compiler for a new language as a one man project...

I do not intend for this to be a one man project.  I am designing a very
comprehensive system that I would ultimately like to see five full-time
developers working on and maintaining, and also porting to other operating
systems, other architectures, including my planned VVM (virtual machine).

I have big plans ... but I am one just man today.  Though soon, I hope to
be a small team of tightly knit folk each with a common goal to offer up
to the Lord the best of what He first gave them (knowledge, interests,
skills, etc.). :-)

In the meantime, it'll be enough to not have "mean" time, but to have "be
nice to one another" time. :-)  Much more pleasant.  Much more desirable.

Best regards,
Rick C. Hodgin

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

#90075

On 06/07/2016 13:18, Rick C. Hodgin wrote:
> On Wednesday, July 6, 2016 at 5:49:38 AM UTC-4, Malcolm McLean wrote:
>> If I was writing a compiler for a new language as a one man project...
>
> I do not intend for this to be a one man project.  I am designing a very
> comprehensive system

I think this is the problem. It's /too/ comprehensive, /too/ ambitious.

It doesn't just cover a language or compiler or build system or IDE or 
smart editor or debugger, but, apparently, everything. (Not to forget 
that FPGA processor of yours too!)

And it isn't full of obvious enhancements that everyone can immediately 
understand, but lots of obscure features that few can appreciate even 
after you've explained them many times. Additionally, many sound a 
complete nightmare to implement, if they can be at all without clashing 
with each other.

But at least you haven't yet got together with supercat and his 
proposals to add so many extra controls to C (that few understand 
either) that the language reference would need to be several times the size!

> that I would ultimately like to see five full-time
> developers

If it was a one-man project I wouldn't have posted. But if others are to 
be involved: would they have any input in the 'vision' that you have, or 
are they expected to just implement your ideas?

> offer up
> to the Lord the best of what He first

It's up to you but I would keep quiet about that side of things if you 
want to be taken seriously. (If passengers heard their pilot offering up 
prayers for a safe flight, I think most of them would be uneasy!)

-- 
Bartc

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

#90078

On Wednesday, July 6, 2016 at 8:57:53 AM UTC-4, Bart wrote:
> On 06/07/2016 13:18, Rick C. Hodgin wrote:
> > On Wednesday, July 6, 2016 at 5:49:38 AM UTC-4, Malcolm McLean wrote:
> >> If I was writing a compiler for a new language as a one man project...
> >
> > I do not intend for this to be a one man project.  I am designing a very
> > comprehensive system
> 
> I think this is the problem. It's /too/ comprehensive, /too/ ambitious.
> 
> It doesn't just cover a language or compiler or build system or IDE or 
> smart editor or debugger, but, apparently, everything. (Not to forget 
> that FPGA processor of yours too!)

It is a plan and purpose for a top-to-bottom computer stack that is
our offering unto the Lord, which also means our offering unto mankind
because His purposes here on this Earth are about people (salvation,
and restoration because of sin).

It is the Liberty Software Foundation, a purposed large entity which will
have thousands of developers contributing, just as the Free Software
Foundation does today, except that ours will be in service to the Lord,
in reverence of Him, an offering of worship and acknowledgement of Him
here upon this Earth.

    http://www.libsf.org/

I have also created the Village Freedom Project, which aims to free us
from the oppressive closed source and open source models which exist
today, those kind which are not done in service to the Lord, but in
service to money, or to man.

    http://www.visual-freepro.org/wiki/index.php/Main_Page#Village_Freedom_Project

Most people aren't interested in this sort of thing.  But for those
who are, they are the ones it's for.

> And it isn't full of obvious enhancements that everyone can immediately 
> understand, but lots of obscure features that few can appreciate even 
> after you've explained them many times. Additionally, many sound a 
> complete nightmare to implement, if they can be at all without clashing 
> with each other.
> 
> But at least you haven't yet got together with supercat and his 
> proposals to add so many extra controls to C (that few understand 
> either) that the language reference would need to be several times the size!

We've talked offline briefly.  I've asked him if he would come on board
around 2020 or so and modify the CAlive source code base to include a
fully compatible C90 and C99 compatibility.  He has not committed or
even hinted at anything resembling accepting, but it has been an offer
made to him.

> > that I would ultimately like to see five full-time
> > developers
> 
> If it was a one-man project I wouldn't have posted. But if others are to 
> be involved: would they have any input in the 'vision' that you have, or 
> are they expected to just implement your ideas?

What does the Bible teach us?

    http://biblehub.com/kjv/proverbs/15-22.htm
    "Without counsel purposes are disappointed: but in the multitude
     of counsellers they are established."

God created a body of Christ, not just an individual, or a group of
isolated and separate individuals.  He gave to each special talents
and abilities, and these are for a purpose just as the members of our
body are for their purpose, but are yet one body.

Each person is to come on board and do their part.  And, to be very
frank and open, I would be grateful to be more of a doer and not a
planner on this project.  I like writing code, and I like being
creative in design.  But I am not a good manager or leader, and I have
no aspirations to be the same.  I am, however, a good encourager, a
good helper, and a good resource to be able to call upon because I am
very creative.

> > offer up
> > to the Lord the best of what He first
> 
> It's up to you but I would keep quiet about that side of things if you 
> want to be taken seriously. (If passengers heard their pilot offering up 
> prayers for a safe flight, I think most of them would be uneasy!)

What does the Bible teach us?

    http://biblehub.com/kjv/1_corinthians/3-11.htm
    "For other foundation can no man lay than that is laid, which is
     Jesus Christ."

Everything done apart from Christ is for not.  It will fade away when we
leave this world, and it will only have been here.  But those things we
do for the Lord remain ... which is why the enemy has setup this worldly
system to focus on getting your gain here, rather than in eternity.  Gain
here is loss, but loss here is gain when you are losing because of service
to the Lord, because He repays for that service in eternity, and not here.

    http://biblehub.com/kjv/1_corinthians/3-13.htm
    13 Every man's work shall be made manifest: for the day shall declare
       it, because it shall be revealed by fire; and the fire shall try
       every man's work of what sort it is.
    14 If any man's work abide which he hath built thereupon, he shall
       receive a reward.
    15 If any man's work shall be burned, he shall suffer loss: but he
       himself shall be saved; yet so as by fire.

The enemy comes to steal, kill, destroy.  He would have you naked and
destitute in eternity.  The Lord, however, comes to prosper and build up
all who seek Him, and for eternity.

The Lord's ways are right.  The world's ways are wrong.  It is to the
Lord I indicate, and it is unto Him I seek and desire greatly to serve.

Best regards,
Rick C. Hodgin

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

#90077

On 06/07/16 11:49, Malcolm McLean wrote:
> On Wednesday, July 6, 2016 at 10:29:13 AM UTC+1, David Brown wrote:
>> On 06/07/16 01:23, Rick C. Hodgin wrote:
>>
>> You seem determined to use C (via a C++ compiler) despite how much you seem to 
>> dislike the language and despite its questionable suitability for developing a compiler or IDE.  
>>
> If I was writing a compiler for a new language as a one man project, the fact I was doing
> so would imply that I didn't think C or any other established language was totally
> suitable for my purposes. So it's quite likely I'd have many criticisms to make of C.
> 

There are a great many reasons to choose to make a new language and a
new compiler.  There are a great many types of programs, and different
languages are suitable for different purposes.  Even if we only limit
ourselves to practical reasons (rather than "just for fun", or "to learn
about programming languages", or "because existing languages and tools
are written by evil people"), it is more likely that a new language
would be made to suit a particular purpose rather than simply to replace
an existing language.

Of course people are going to have criticisms of any language they use a
lot - I doubt if there is anyone in this group who likes every aspect of
C.  But there is a difference between having some minor dislikes or
criticisms, and the level of hatred that Rick seems to have for parts of C.

> However I would implement the compiler in a  conservative subset of ANSI C and
> output a similarly conservative subset. That gives the project maximum chance of 
> longevity and usefulness.
> 

/You/ might choose to do that - but it would be a rather silly choice in
this case.  C is a poor choice of language for writing a compiler these
days - at least for a first draft.  A language that has good support for
strings, parsing, dictionaries, and the like would make more sense.  I
would pick Python here, because I am familiar with it - there are many
other suitable high level languages that would do.  Once the basic
compiler and tools are working with Python, and I and others had used it
for enough man-years to be happy with the language in practice, it might
then be time to write a new implementation in C++ to get a more
efficient compiler if it looks like compilation speed is an issue, or if
the project is going to get bigger and have more features.

But a key to success is to use a language that will let you get the
basic system up and running quickly.  If you are trying to do it all
yourself, then higher level languages will get you faster results.  (If
you are combining ready-made libraries or creating a new front-end to
llvm, your choice will be influenced by that.)

Rick's aim here is to create an initial CAlive compiler that will let
him bootstrap his later version of the tools written in CAlive itself.
So it really doesn't matter what language the first compiler is written
in - certainly there is no point whatsoever of limiting himself to a
subset of a 25+ year old version of a low-level language in the name of
"portability".

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

#90079

On Wednesday, July 6, 2016 at 9:22:23 AM UTC-4, David Brown wrote:
> On 06/07/16 11:49, Malcolm McLean wrote:
> Of course people are going to have criticisms of any language they use a
> lot - I doubt if there is anyone in this group who likes every aspect of
> C.  But there is a difference between having some minor dislikes or
> criticisms, and the level of hatred that Rick seems to have for parts of C.

In each case where I have a strong dislike or hatred of C it has to do
with those areas which force people to do more work than they need to
do given the capabilities of the machine, or an ability which would be
exposed through a relaxed constraint, such as with forward declarations.

Where other people see stability and value, I sometimes see chains and
bondage to additional unnecessary labor.

However, in other areas I think C is lacking through its relaxations.
I think not having type casting is insane.  I think every reference
that goes across a family type should have casting.  And I also think
any downsizing within a family should be cast (a 32-bit int to 16-bit
int should include a cast, and arguably there should be a new type of
overflow detection cast at runtime which would branch to another
location when triggered, which is what one of the new casks I propose
would offer:

    int16_t i16;
    int32_t i32;

    i32 = 40000;
    i16 = (int16_t)i32 <| overflow | my_overflow_function() ||>;

In this case, the overflow is handled by the use of the <|overflow|>
cask.  And I think those things are desirable at times.

> But a key to success is to use a language that will let you get the
> basic system up and running quickly.

That affords a certain type of success, but another more lasting type
of success comes from planning something out correctly and implementing
the features which you have designed in turn.  It will take longer to
implement, but in the end the product will be a proper foundation.

I have tried to create a full new Visual FreePro XBASE-like language,
and I realized as I was developing it I needed my own compiler.  I
then back-pedaled a little and moved to Visual FreePro, Jr., a much
lesser-scope project (about 1/3rd the size), and also realized that
I needed my own compiler to implement everything I want to for the
long haul.  I also recognized this back in 2002 when I was working
on my operating system.

I have at each point tried to work-around that recognition of the
need, but it keeps coming back.  So, I am now resolved to address
the need.  And, over time, I'll see what becomes of it.

I am actually the most energized I've been on this project since
2012, and early 2014.  It's kind of exciting again actually.  Right
now I'm working on my assembler.  Once completed, I'm implementing
a much reduced CAlive compiler which will compile my existing source
code as a stand-alone compiler.  Then, I'll tweak that version to
allow the full extensions I want and begin on the full version of
CAlive, including the LiveCode (edit-and-continue) model.

Once those are completed, the rest will move very quickly.  I am
planning for an end-of-year 2017 timeframe right now.  But, life is
what life is and we'll see what happens.

Best regards,
Rick C. Hodgin

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

#90082

On Wednesday, July 6, 2016 at 2:22:23 PM UTC+1, David Brown wrote:
> On 06/07/16 11:49, Malcolm McLean wrote:
>
> There are a great many reasons to choose to make a new language and a
> new compiler.  There are a great many types of programs, and different
> languages are suitable for different purposes.  Even if we only limit
> ourselves to practical reasons (rather than "just for fun", or "to learn
> about programming languages", or "because existing languages and tools
> are written by evil people"), it is more likely that a new language
> would be made to suit a particular purpose rather than simply to replace
> an existing language.
>
B64, my own vapourware language, is intended as a replacement for C.
On the other hand, MiniBasic was intended as scripting language for
embedding into larger programs. In fact what people used it for was 
for embedded hobby programming, basically users who were more interested
in the electronics side than programming and just wanted a quick and
simple language to dispatch commands to peripherals.
>
> Of course people are going to have criticisms of any language they use a
> lot - I doubt if there is anyone in this group who likes every aspect of
> C.  But there is a difference between having some minor dislikes or
> criticisms, and the level of hatred that Rick seems to have for parts of C.
> 
> > However I would implement the compiler in a  conservative subset of ANSI C and
> > output a similarly conservative subset. That gives the project maximum chance of 
> > longevity and usefulness.
> > 
>
[language for implementing a compiler ] 
> I would pick Python here, because I am familiar with it - there are many
> other suitable high level languages that would do.  
>
> So it really doesn't matter what language the first compiler is written
> in - certainly there is no point whatsoever of limiting himself to a
> subset of a 25+ year old version of a low-level language in the name of
> "portability".
>
if you use a language which is 25+ years old, there's a reasonable chance that
everything will still work in another 25 years. C isn't ideal. Any idiot can knock
up a language with better string handling routines or built-in hash tables.
But it will do, you can get the code together. If you like automated tools, 
you can also integrate with yacc. There probably is a Yak that produces Python
output, but then your toolkit increasingly resembles a zoo.

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

#90086

On Wednesday, July 6, 2016 at 10:09:15 AM UTC-5, Malcolm McLean wrote:
> if you use a language which is 25+ years old, there's a reasonable chance that
> everything will still work in another 25 years.

That line of thinking would have been reasonable in 2000, but a lot of
code which would have been considered as extremely portable among
microcomputer implementations is no longer supported by "modern C".

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

#90095

On 07/ 7/16 04:00 AM, supercat@casperkitty.com wrote:
> On Wednesday, July 6, 2016 at 10:09:15 AM UTC-5, Malcolm McLean wrote:
>> if you use a language which is 25+ years old, there's a reasonable chance that
>> everything will still work in another 25 years.
>
> That line of thinking would have been reasonable in 2000, but a lot of
> code which would have been considered as extremely portable among
> microcomputer implementations is no longer supported by "modern C".

I can't see anything in my "portable" 80s and 90s embedded code that 
won't behave if compiled with a current compiler.

-- 
Ian

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

#90096

On Wednesday, July 6, 2016 at 3:01:56 PM UTC-5, Ian Collins wrote:
> I can't see anything in my "portable" 80s and 90s embedded code that 
> won't behave if compiled with a current compiler.

I don't know what kinds of things your code does, but some which had been
supported for 25 years prior to 2000 on nearly all machines that were
architecturally similar to the PDP-11, including nearly all general-purpose
reprogrammable microcomputers.

1. Performing arithmetic which might overflow when given invalid inputs,
   in code which only needed to meet very loose behavioral requirements
   when given invalid input, and whose behavioral requirements would be
   satisfied by abnormal program termination or by producing meaningless
   output.

2. Using relational operators on pointers that may or may not be related,
   in cases where the outcome of the operator would only matter if the
   pointers were related.

3. Creating structure-types variables which differ only in the size of a
   trailing array and passing pointers to such structures to code which
   could process them interchangeably.

4. Manipulate blobs of data in two-or four-byte chunks depending upon the
   operation to be performed [e.g. when drawing a 16-pixel wide shape on
   a 16-pixel boundary, using a 16-bit store for each word will likely be
   more efficient than using a 32-bit read-modify-write sequence, but when
   drawing a 32-pixel wide shape on a 32-pixel boundary, using a 32-bit
   store will likely be more efficient than two 16-pixel stores].

Can you suggest any practical means by which someone in 2000 could have
written code that would be regarded as defined by the maintainers of 
today's gcc without severe sacrifices in readability, performance, or
both?

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

#90087

On 06/07/2016 14:22, David Brown wrote:
> On 06/07/16 11:49, Malcolm McLean wrote:

>> However I would implement the compiler in a  conservative subset of ANSI C and
>> output a similarly conservative subset. That gives the project maximum chance of
>> longevity and usefulness.
>>
>
> /You/ might choose to do that - but it would be a rather silly choice in
> this case.  C is a poor choice of language for writing a compiler these
> days - at least for a first draft.

I'd been writing my compilers in dynamic, interpreted languages.

But now I'm converting at least one of them into my static, C-class 
language. There are a lot of advantages including:

* Very much faster speed (I'd forgotten compilers could be this fast)

* Can be distributed as standard C (as my language is not standard).
   (Python is standard, but a large, sprawling Python installation is
   needed, and the application itself will be multiple modules.)

* A C version is also much easier to distribute as a single binary
   executable.

One more advantage can appreciated if, for example, you write the 
compiler in Python, but are also responsible for the Python interpreter, 
and that interpreter is written in the language whose compiler you are 
writing in Python!

Then you can get a peculiar set of circular but offset dependencies 
(overlaps between different generations), that vanish if using a 
language that compiles straight to native code.

> A language that has good support for
> strings, parsing, dictionaries, and the like would make more sense.

You don't really need all that; compilers aren't that complicated. By 
parsing support I assume you mean a regular expression library. But 
that's a bit of a cop-out way of writing a parser.

Such features can also be inefficient, on top of using an interpreted 
language. Earlier this year I compared a tokeniser I'd written in 
Python, using low-level character-at-a-time methods, to one written in 
Python using regular expressions.

My tokeniser was faster! Despite the character-at-a-time processing 
presumably being done by native code libraries, not Python byte-code.

-- 
Bartc

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

#89844

On 30/06/2016 00:04, supercat@casperkitty.com wrote:
> On Wednesday, June 29, 2016 at 12:37:10 PM UTC-5, Rick C. Hodgin wrote:
>> I cannot have a massively distributed / interbred library without jumping
>> through hoops to declare things ahead of their actual need ... and I'm done
>> with coding that way.
>
> Is the problem with types, functions, variables, or what?  I can certainly
> see a use for "pointer to unknown struct", "pointer to unknown union",
> "pointer to unknown function", and "pointer to unknown pointer" types,
> with or without forward-reference related issues,

No, you don't want to bother with any of that.

You declare your function, variable, type, etc where it normally lives, 
and it's then available everywhere else without having to worry about 
location and ordering (depending on visibility control).

I assume that's what Rick on about, but that really needs a module 
system (he's doing a new language so no problem).

Otherwise, just allowing out-of-order declarations of functions in one 
module is fairly straightforward, and could be done in C with a simple 
external tool. Doing it with any other entities though is harder; and 
within a function, block scopes make that very tricky. But again, with a 
different language, it can have new rules.

> would you
> still need forward definitions?  If so, for what?
>

int main (void) {
  a = addint(x,y);
}

int addint(int a,int b){return a+b;}


You don't want the hassle of either defining addint() before all 
references to it, or having to write a forward declaration, which 
repeats much of the function signature, at the top of the module.

-- 
Bartc

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

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

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

csiph-web