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 1 of 4  [1] 2 3 4  Next page →

#89835 — Forward declarations ... the straw that broke the camel's back

Log entry, June 29, 2016:

Okay.  I'm done.

Forward declarations have pushed me over the edge of tolerance.  I have
tried to work with C and C++ within their constraints, but it makes things
increasing complex and difficult, and reduces productivity significantly,
in trying to address their needs.

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.

My sole programming focus from this day forward is to complete CAlive and
its related requirements. as CAlive has no forward declaration constraints.

I plan on doing this as a stand-alone compiler that is not integrated with
the GUI so that I can get it to the point where it compiles my code as other
compilers do today, and then I am going to bootstrap my own CAlive source
code base and extend it out to supporting the GUI, and then I will proceed
with the rest of my planned development.

-----
Forward declaration requirements are completely insane in the year 2016,
and if it's at all possible, I will never require them in any product I
create.  I will always do my best to allow for the n-pass scenario, to take
the microsecond hit in performance to alleviate the burden from the
shoulders of the human developer.

And from our recent discussions in comp.std.c, and here, I'm still amazed
any C/C++ developer in 2016 would desire them as a requirement, and not
simply as an option.

Best regards,
Rick C. Hodgin

[toc] | [next] | [standalone]

#89842

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, as well as a means of
allowing a type to be initially declared with any of the above and then
redefined using a pointer to a more specific type.  If the Standard were
to include the aforementioned types and allow redefinition of types
provided that the redefinition was compatible with the existing definition
(with the more specific definition "winning" in cases where something was
defined with non-specific types but also with specific types), would you
still need forward definitions?  If so, for what?

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

#89843

On Wednesday, June 29, 2016 at 7:04:48 PM UTC-4, supe...@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?

Types.  I have attempted to arrange my SAbc structure to be declared in
the abc.h file, along with all the normal abc_*() functions, etc.  But,
because SAbc is a first-class citizen, it is also used in xyz.h, def.h,
etc.  And when they reference the unknown struct as by passed parameter
type, it's okay.  But in the function body if it does something with one
of the members, then it must be declared before use.  So, I rearrange
my headers.  But now I've got SLmn and so on, and they all do the same.

It mandates I create a master all_structs.h type file which has all of
the structures declared in one place, so that all of the various
references throughout the system can be accomplished, and I don't want
to do that.

My goals are like in cooking.  I want to pour in the ingredients in any
order, and then have the mixer run once everything is in there.

Newer programming languages have it right.  Forward declaration require-
ments are ridiculous.  Only declaration requirements should exist.  And
even then, why does it need to be declared at compile time?  Why can't
the references to the various types be inferred from use, and then fixed
up in the linker?  The compiler can construct whatever it's able from
the source file, even with a few options being given based on observed
data types in use (could be 16-bit int, 32-bit, 64-bit, etc.), and then
when it actually finds the real declaration in another object file,
then note any discrepancies, or generate any fixup code to solidify
that it is, in fact, a 32-bit integer, for example.

Oh well ... in CAlive I'll have freedom to explore these things and then,
possibly, prove to myself and my hard-headed skull why it isn't being done
that way today.  LOL! :-)

-----
Off-topic:

BTW, I don't advocate piracy, but this is of the most amazing solo piano
arrangements of an otherwise powerful orchestral piece of music I've ever
heard.  Written by Klaus Badelt, and arranged by Jarrod Radnich, Jarrod's
arrangement was so popular it spawned a YouTube contest to see who could
cover it as well as the original:

    Original arranging author:
    https://www.youtube.com/watch?v=n4JD-3-UAzM

    My favorite entry:
    https://www.youtube.com/watch?v=sHAg5kM73ag

    Full orchestral version:
    https://www.youtube.com/watch?v=MufORSL68v0

I just came across this song for the first time a few weeks ago.  The
full orchestral version is also very similar to the Misty Island Rescue
theme song in a few places:

    Misty Island Rescue Theme Song:
    https://www.youtube.com/watch?v=dj1TiphId38

My son came across the illustrated piano version and really liked it.
We were later watching Misty Island Rescue and he said, "This sounds
so familiar," and then he remembered where he'd heard it from:

    https://www.youtube.com/watch?v=72BYjy-bW6M

Best regards,
Rick C. Hodgin

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

#89848

On Thursday, June 30, 2016 at 12:30:14 AM UTC+1, Rick C. Hodgin wrote:
>
> Types.  I have attempted to arrange my SAbc structure to be declared in
> the abc.h file, along with all the normal abc_*() functions, etc.  But,
> because SAbc is a first-class citizen, it is also used in xyz.h, def.h,
> etc.  And when they reference the unknown struct as by passed parameter
> type, it's okay.  But in the function body if it does something with one
> of the members, then it must be declared before use.  So, I rearrange
> my headers.  But now I've got SLmn and so on, and they all do the same.
> 
Types are a nuisance.
A function takes a path described by a Bezier spline, so you need
four points for each segments, with the not shared, possibly
"corner" flags to indicate G1 continuity, and probably a flag
for whether the path is closed.
However there are many sensible ways of arranging that data, and
no firm conventions on what names to use. Quite likely there will
be a "point" structure defined somewhere else which the Bezier path
will be dependent on. There might also be a "vector" structure
defined by the language you wrote the basic Bezier routines in.
Theb something as simple as a boolean for the path closed flag
might be typedefed as "BOOL" somewhere else.

The more bits and pieces you add, the harder it gets to make
your code interoperate with anything else, and all because
of an essentially trivial data formatting problem.

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

#89857

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Thursday, June 30, 2016 at 12:30:14 AM UTC+1, Rick C. Hodgin wrote:
>>
>> Types.  I have attempted to arrange my SAbc structure to be declared in
>> the abc.h file, along with all the normal abc_*() functions, etc.  But,
>> because SAbc is a first-class citizen, it is also used in xyz.h, def.h,
>> etc.  And when they reference the unknown struct as by passed parameter
>> type, it's okay.  But in the function body if it does something with one
>> of the members, then it must be declared before use.  So, I rearrange
>> my headers.  But now I've got SLmn and so on, and they all do the same.
>> 
> Types are a nuisance.

Many people think quite the opposite.  Types are a huge convenience.  C
evolved from the typeless B by adding "just enough" of the type concept
to make it useful, but it remains only very loosely typed so it is not a
particularly good example to demonstrate how types help the programmer.
Even so...

> A function takes a path described by a Bezier spline, so you need
> four points for each segments, with the not shared, possibly
> "corner" flags to indicate G1 continuity, and probably a flag
> for whether the path is closed.
> However there are many sensible ways of arranging that data, and
> no firm conventions on what names to use. Quite likely there will
> be a "point" structure defined somewhere else which the Bezier path
> will be dependent on. There might also be a "vector" structure
> defined by the language you wrote the basic Bezier routines in.
> Theb something as simple as a boolean for the path closed flag
> might be typedefed as "BOOL" somewhere else.
>
> The more bits and pieces you add, the harder it gets to make
> your code interoperate with anything else, and all because
> of an essentially trivial data formatting problem.

... types help to solve this problem.  First, they alert you to the fact
that the data layout in the two kind of point might be different.
Second, they document the layout so it's easy to do the conversion if
it's needed.  Implicit data formats were not convenient and few people
who were forced to use them want to go back.

-- 
Ben.

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

#89858

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.

I actually view the forward declaration REQUIREMENT as being the single
worst language feature of C and C++.  I can see where it might be beneficial
to have it at times, but very rarely, and certainly not not all of the time.
And I would say it's so rarely needed that it could be dropped with minimal
loss and effort.

I began programming in C in the early 1990s, and I've never had a single
case in all of my C and C++ programming career since where it would've been
an issue to not have this thing declared after that other thing.  It's
always only been a compiler constraint / requirement.  But I have had over
500 separate instances where it's been a notable hindrance causing me to
have to do extra work to make it compile.

I don't code in such a way as to explicitly reuse the same names for
variables that are in scope, or types in scope, so I see no value in
having the requirement.  And in CAlive it won't be a requirement, and in
the first few versions at least, it won't even be an option.  Things will
be declared anywhere that's in the compiler or linker scope, and they'll
be able to be used if the syntax is correct on their use.

I'd like to invite any of you who might be interested to join the CAlive
Google Group:

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

I would welcome feedback on my language proposals.

Best regards,
Rick C. Hodgin

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

#89864

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?

The only thing I can think of is that sometimes structs S and T have a 
mutual pointer to each other, but there is way to get around that.

It's functions which are most of a problem: it's not just F calling G 
and G calling F, but any function a file can call any other functions. 
Then C requires forward declarations to sort out the mess, or have to 
have functions in a certain order but that doesn't always work.

Here it would be genuinely useful to not need forward declarations of 
functions.


-- 
Bartc

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

#89865

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.

> The only thing I can think of is that sometimes structs S and T have a 
> mutual pointer to each other, but there is way to get around that.
> 
> It's functions which are most of a problem: it's not just F calling G 
> and G calling F, but any function a file can call any other functions. 
> Then C requires forward declarations to sort out the mess, or have to 
> have functions in a certain order but that doesn't always work.
>
> Here it would be genuinely useful to not need forward declarations of 
> functions.

I look at software compilation as assembling a puzzle.  Sometimes there
are pieces missing, but that shouldn't prevent the puzzle from being
created.  It will just have some places which have no code in them.  Even
if you get to a line of code referencing an unknown type, or an unknown
member of a known type, it's not really an error, it's just incomplete
code, which may possibly indicate an error because you typed "fi" and
you mean "fo".

In any event, there are several aspects of CAlive which lend to this
puzzle arrangement, and in allowing programs to run which do not have
everything defined.  It's the nature of the LiveCode compiler, inside
the RDC (Rapid Development Compiler) framework.

It's all part of a long-term comprehensive way of looking at software
design and execution.  And I eventually plan to incorporate a follow-
on framework (for after it's been developed and debugged) called RaCE
(Rapid Code Engagement) for highly optimized code.  But, that's a long-
term goal, and not part of any of my initial plans as I will not place
any kind of priority on optimization at first.  Only functionality.
Though eventually, you'll be able to choose your development platform
model as by a selection, either targeting RDC or RaCE for output.

Best regards,
Rick C. Hodgin

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

#89867

On 30/06/2016 18:30, Rick C. Hodgin wrote:
> On Thursday, June 30, 2016 at 1:11:48 PM UTC-4, Bart wrote:

>> Why would declaring types ahead of use be an issue?

> I look at software compilation as assembling a puzzle.  Sometimes there
> are pieces missing, but that shouldn't prevent the puzzle from being
> created.  It will just have some places which have no code in them.  Even
> if you get to a line of code referencing an unknown type, or an unknown
> member of a known type, it's not really an error, it's just incomplete
> code, which may possibly indicate an error because you typed "fi" and
> you mean "fo".

You might be describing Python there, where all names are resolved at 
run-time. (Not even at load-time, but as each line is executed.)

But for a static language, that introduces extra complexities (as we may 
have already discussed in c.s.c), and many C compilers are slow enough 
already.

In my experiments to get a faster compiler, I've had to eliminate one 
pass, and that meant dropping out-of-order declarations (except for 
labels and functions; type declarations already needed to be declared 
ahead-of-use).

And interestingly, I haven't missed the feature at all, as I never used 
it! This is for a language where anything still only needs to be defined 
once.


-- 
Bartc

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

#89868

On Thursday, June 30, 2016 at 2:54:20 PM UTC-4, Bart wrote:
> On 30/06/2016 18:30, Rick C. Hodgin wrote:
> > On Thursday, June 30, 2016 at 1:11:48 PM UTC-4, Bart wrote:
> 
> >> Why would declaring types ahead of use be an issue?
> 
> > I look at software compilation as assembling a puzzle.  Sometimes there
> > are pieces missing, but that shouldn't prevent the puzzle from being
> > created.  It will just have some places which have no code in them.  Even
> > if you get to a line of code referencing an unknown type, or an unknown
> > member of a known type, it's not really an error, it's just incomplete
> > code, which may possibly indicate an error because you typed "fi" and
> > you mean "fo".
> 
> You might be describing Python there, where all names are resolved at 
> run-time. (Not even at load-time, but as each line is executed.)
> 
> But for a static language, that introduces extra complexities (as we may 
> have already discussed in c.s.c), and many C compilers are slow enough 
> already.

CAlive has a non-static type (called "var") which is a discriminating
union which backs into static types, but everything else in CAlive is
static.  It's just that the CAlive design allows for things to be changed
through its ABI via source-code changes without affecting things (in most
cases, there are some changes which require a restart, but not many in
its current design).

> In my experiments to get a faster compiler, I've had to eliminate one 
> pass, and that meant dropping out-of-order declarations (except for 
> labels and functions; type declarations already needed to be declared 
> ahead-of-use).

Since I'll be working with a continuous compile LiveCode compiler, it
won't be an issue.  There will never be a time when compilation takes
any additional time.  If you see it on the screen, within a partial
second it will be ready to run, or the changes will already be running.

I've actually considered introducing some kind of toggle icon into the
GUI which allows you to make changes which are compiled without going
into the live ABI, unless the icon is toggled to do so, allowing for a
staging of code which "will go live" once it's instructed to do so.

> And interestingly, I haven't missed the feature at all, as I never used 
> it! This is for a language where anything still only needs to be defined 
> once.

One of CAlive's goals is to eliminate function prototype declarations.
I would also like to eliminate even having to have some struct and class
declarations, to have them be derived at compile-time instead.  But,
we'll see.

"Rapid Development Compiler" ... it's named that for a real reason.

Best regards,
Rick C. Hodgin

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

#89870

On 07/ 1/16 07:31 AM, Rick C. Hodgin wrote:
> On Thursday, June 30, 2016 at 2:54:20 PM UTC-4, Bart wrote:
>
>> In my experiments to get a faster compiler, I've had to eliminate one
>> pass, and that meant dropping out-of-order declarations (except for
>> labels and functions; type declarations already needed to be declared
>> ahead-of-use).
>
> Since I'll be working with a continuous compile LiveCode compiler, it
> won't be an issue.  There will never be a time when compilation takes
> any additional time.  If you see it on the screen, within a partial
> second it will be ready to run, or the changes will already be running.

How can this scale to anything greater than a one person project?  If 
you were to bring another programmer's updates into your working copy, 
compile time would be an issue!

-- 
Ian

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

#89876

Ian Collins <ian-news@hotmail.com> writes:

> How can this scale to anything greater than a one person project?  

What on earth makes you think it would ever need to?

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

#89877

On Thursday, June 30, 2016 at 3:59:29 PM UTC-4, Ian Collins wrote:
> On 07/ 1/16 07:31 AM, Rick C. Hodgin wrote:
> > On Thursday, June 30, 2016 at 2:54:20 PM UTC-4, Bart wrote:
> >> In my experiments to get a faster compiler, I've had to eliminate one
> >> pass, and that meant dropping out-of-order declarations (except for
> >> labels and functions; type declarations already needed to be declared
> >> ahead-of-use).
> >
> > Since I'll be working with a continuous compile LiveCode compiler, it
> > won't be an issue.  There will never be a time when compilation takes
> > any additional time.  If you see it on the screen, within a partial
> > second it will be ready to run, or the changes will already be running.
> 
> How can this scale to anything greater than a one person project?  If 
> you were to bring another programmer's updates into your working copy, 
> compile time would be an issue!

I have plans for a system called Anchor which operates like a live
version of git.  It allows a person to take a snapshot of code that
exists at a certain point and time and anchor to it, doing development
on top of that version, with the live compilation being done in real-
time.  When it comes time to check in the changes, more than just a
diff is performed, and the integrated GUI compiler is able to determine
what has changed based on what other code has been checked in.

It is not a small project I have designed.  It is exceedingly
comprehensive actually.  I am planning these things for the Liberty
Software Foundation (LibSF) as part of something I call the Village
Freedom Project (VFrP).  I plan to have other developers come on board
and help me once I get past the point of having only talk about my
products.  It just takes a long time because all I encounter is much
resistance and naysayers.  I literally don't have anybody in my life
who says I can do it, except me.  But, I know I can, so I press on.

Best regards,
Rick C. Hodgin

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

#89880

On Thursday, June 30, 2016 at 5:19:58 PM UTC-4, Rick C. Hodgin wrote:
> It is not a small project I have designed.  It is exceedingly
> comprehensive actually.  I am planning these things for the Liberty
> Software Foundation (LibSF) as part of something I call the Village
> Freedom Project (VFrP).  I plan to have other developers come on board
> and help me once I get past the point of having only talk about my
> products.  It just takes a long time because all I encounter is much
> resistance and naysayers.  I literally don't have anybody in my life
> who says I can do it, except me.  But, I know I can, so I press on.

To be clear, I mention it this way because it is just me doing
development at the present time.  I am not part of a team, but I am the
sole developer doing all of this, and I have a regular full-time day
job which consumes well in excess of 50 hours per week.  And here until
this past week, has been consuming all of my free time because I had a
particular project I had to get out.

In any event, I would like to do these things full-time, or to be able
to spend 3+ hours per day at least working on them.  As it is, it is
all done in the evenings, weekends, holidays, vacation days, sick days,
lunch hours, and periodic time-shifts where I work when I feel inspired
and then trade that time for evening work on my regular full-time job's
work, though this has only happened a handful of times.

    https://github.com/RickCHodgin/libsf/graphs/punch-card

Best regards,
Rick C. Hodgin

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

#89874

On 30/06/2016 20:31, Rick C. Hodgin wrote:
> On Thursday, June 30, 2016 at 2:54:20 PM UTC-4, Bart wrote:

>> But for a static language, that introduces extra complexities (as we may
>> have already discussed in c.s.c), and many C compilers are slow enough
>> already.

> One of CAlive's goals is to eliminate function prototype declarations.
> I would also like to eliminate even having to have some struct and class
> declarations, to have them be derived at compile-time instead.  But,
> we'll see.

So you are writing a Python lookalike after all! There, also, you can't 
tell what attributes a class has by looking at the static source code, 
as it's all done at runtime. And each run could have a different set. I 
think also each instance of the class could have a different from every 
other!

The sort of coding we're interested in here needs to be more disciplined 
I think.

> "Rapid Development Compiler" ... it's named that for a real reason.

I've never had problems in that area. Taking one compiler project (for 
the C-like language), then recompiling it all takes 2 seconds. Compiling 
a single module takes 0.1 to 0.2 seconds. There is no linker.

However, the new project I'm working on now, will recompile that 
/entire/ project in 0.03 seconds[1] - from scratch. No need to maintain 
a database of everything and keep track of every change.

You can get speed by making things simpler as well as more complex. (I 
don't even use any fancy techniques; most lists are searched linearly 
for example.)

([1] 25Kloc, 17 modules, source to runnable byte-code)

-- 
Bartc

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

#89879

On Thursday, June 30, 2016 at 4:18:29 PM UTC-4, Bart wrote:
> On 30/06/2016 20:31, Rick C. Hodgin wrote:
> > On Thursday, June 30, 2016 at 2:54:20 PM UTC-4, Bart wrote:
> 
> >> But for a static language, that introduces extra complexities (as we may
> >> have already discussed in c.s.c), and many C compilers are slow enough
> >> already.
> 
> > One of CAlive's goals is to eliminate function prototype declarations.
> > I would also like to eliminate even having to have some struct and class
> > declarations, to have them be derived at compile-time instead.  But,
> > we'll see.
> 
> So you are writing a Python lookalike after all! There, also, you can't 
> tell what attributes a class has by looking at the static source code, 
> as it's all done at runtime. And each run could have a different set. I 
> think also each instance of the class could have a different from every 
> other!
> 
> The sort of coding we're interested in here needs to be more disciplined 
> I think.

The ability I am referring to introducing is this:

    // myfile.c
    struct SAbc;   // No declaration anywhere else

    void myfunc(void)
    {
        float f;
        struct SAbc abc;  // It has not been defined anywhere

        f = 3.0f;

        abc.fMonthAmt  = f;             // I define and populate:
        abc.fYearTotal = f * 12.0f;     // abc::fMonthAmt as float
                                        // abc::fYearTotal as float

        otherFunc(&abc);
    }

    void otherFunc(struct SAbc* abc)
    {
        abc.fCenturyTotal = abc.fYearTotal * 100.0f;
        // Now abc::fCenturyTotal is defined also as float
    }

In this example, at no point did I define what struct SAbc contained,
but it was derived from compilation by context.  Now, had SAbc been
defined like this the compiler would need to introduce some auto-
conversions:

    struct SAbc
    {
        float f;
        double fMonthAmt;
        double fYearTotal;
        float fCenturyTotal;
    }

But, it wasn't, so the compiler was able to make everything a float,
because that's what fed in to the missing members.

At compile-time, and in real-time through the CAlive GUI/API interface,
all members of struct SAbc can be known.  It is static at runtime, but
it's a little more flexible at compile-time, and due to the nature of
the LiveCode ABI, it is also a little more flexible at runtime, but it
is still static.

But, I don't know if I'll incorproate that ability.  I don't see much
utility for it.  I might still introduce it though.  I'll have to give
it some thought.

Best regards,
Rick C. Hodgin

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

#89881

On 30/06/2016 22:26, Rick C. Hodgin wrote:
> On Thursday, June 30, 2016 at 4:18:29 PM UTC-4, Bart wrote:

>> So you are writing a Python lookalike after all! There, also, you can't
>> tell what attributes a class has by looking at the static source code,
>> as it's all done at runtime. And each run could have a different set. I
>> think also each instance of the class could have a different from every
>> other!
>>
>> The sort of coding we're interested in here needs to be more disciplined
>> I think.
>
> The ability I am referring to introducing is this:
>
>     // myfile.c
>     struct SAbc;   // No declaration anywhere else
>
>     void myfunc(void)
>     {
>         float f;
>         struct SAbc abc;  // It has not been defined anywhere
>
>         f = 3.0f;
>
>         abc.fMonthAmt  = f;             // I define and populate:
>         abc.fYearTotal = f * 12.0f;     // abc::fMonthAmt as float
>                                         // abc::fYearTotal as float
>
>         otherFunc(&abc);
>     }
>
>     void otherFunc(struct SAbc* abc)
>     {
>         abc.fCenturyTotal = abc.fYearTotal * 100.0f;
>         // Now abc::fCenturyTotal is defined also as float
>     }

> In this example, at no point did I define what struct SAbc contained,
> but it was derived from compilation by context.

I think that's dangerous. Does SAbc have 4 members, or does it have 6 
because there are a couple of assignments to it buried in the code 
somewhere that you've forgotten about?

Or does it use space-effective floats, or has one or more been 
inadvertently forced to a double? Is a member a float, or is it an int 
because it has been assigned 0 instead of 0.0? Or assigned from an 
external opaque type? Etc.

These are all problems you can get in dynamic languages that occur much 
less in more static and more disciplined ones.

But if you did want this, what about using 'auto' to declare the type of 
a member? I still think it's too dangerous to leave the number and 
naming of members subject to rogue bits of code.

> At compile-time, and in real-time through the CAlive GUI/API interface,
> all members of struct SAbc can be known.  It is static at runtime, but
> it's a little more flexible at compile-time, and due to the nature of
> the LiveCode ABI, it is also a little more flexible at runtime, but it
> is still static.

It looks like something that can only work in your own language.

Otherwise, suppose 'struct SAbc' is exported from a library. Will that 
export include information about the number, names and types of the 
members? Could a module that imports it add its own members? Can it 
override the types?

-- 
Bartc

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

#89890

On Thursday, June 30, 2016 at 5:44:41 PM UTC-4, Bart wrote:
> On 30/06/2016 22:26, Rick C. Hodgin wrote:
> > On Thursday, June 30, 2016 at 4:18:29 PM UTC-4, Bart wrote:
> 
> >> So you are writing a Python lookalike after all! There, also, you can't
> >> tell what attributes a class has by looking at the static source code,
> >> as it's all done at runtime. And each run could have a different set. I
> >> think also each instance of the class could have a different from every
> >> other!
> >>
> >> The sort of coding we're interested in here needs to be more disciplined
> >> I think.
> >
> > The ability I am referring to introducing is this:
> >
> >     // myfile.c
> >     struct SAbc;   // No declaration anywhere else
> >
> >     void myfunc(void)
> >     {
> >         float f;
> >         struct SAbc abc;  // It has not been defined anywhere
> >
> >         f = 3.0f;
> >
> >         abc.fMonthAmt  = f;             // I define and populate:
> >         abc.fYearTotal = f * 12.0f;     // abc::fMonthAmt as float
> >                                         // abc::fYearTotal as float
> >
> >         otherFunc(&abc);
> >     }
> >
> >     void otherFunc(struct SAbc* abc)
> >     {
> >         abc.fCenturyTotal = abc.fYearTotal * 100.0f;
> >         // Now abc::fCenturyTotal is defined also as float
> >     }
> 
> > In this example, at no point did I define what struct SAbc contained,
> > but it was derived from compilation by context.
> 
> I think that's dangerous. Does SAbc have 4 members, or does it have 6 
> because there are a couple of assignments to it buried in the code 
> somewhere that you've forgotten about?

CAlive determines and exposes that information.  It would be known
through the API.

> Or does it use space-effective floats, or has one or more been 
> inadvertently forced to a double? Is a member a float, or is it an int 
> because it has been assigned 0 instead of 0.0? Or assigned from an 
> external opaque type? Etc.

Without the explicit definition, it would be determined by the multiple
instances of use, and the operands used to assign into it.

> These are all problems you can get in dynamic languages that occur much 
> less in more static and more disciplined ones.

Well, it's not a dynamic language, Bart.  It's a static language that has
an inferred type.  It requires a recompile to change it.  And even though
in CAlive that recompile comes in the form of an edit-and-continue LiveCode
change to the running ABI, it's still a recompile.  You can't add members
to the struct at runtime.

For that purpose, I have the var type for variable types, and the obj
type for creating container objects.  Those are completely dynamic types,
but they also suffer a performance hit of 100x to 1000x over static types.

> But if you did want this, what about using 'auto' to declare the type of 
> a member? I still think it's too dangerous to leave the number and 
> naming of members subject to rogue bits of code.

It is more dangerous.  It would be easy to introduce a new member by
referring to the abc.xyz member instead of the abc.Xyz member, etc.  But,
it does have other utility and I may introduce it.  Right now, I don't
have any plans to do so.  But it's probably the thing that's closest to
entering the list compared to other things.

I see some value in the auto keyword, but I would prefer to not have that
be a language feature, but be a GUI editor feature, so that I can use
template code to generate real code that can then be debugged in its
native and applied form, rather than through the obscure and obtuse auto
form which must be derived by inquiring of the variable type in the
instance.

I would much rather see static code with a static type for each instance
where auto was used in the template.  And, I intend to create a much more
robust macro language to help generate template code in the editor, which
is then basically programmatically applied and introduced at compile-time
as referenced.

> > At compile-time, and in real-time through the CAlive GUI/API interface,
> > all members of struct SAbc can be known.  It is static at runtime, but
> > it's a little more flexible at compile-time, and due to the nature of
> > the LiveCode ABI, it is also a little more flexible at runtime, but it
> > is still static.
> 
> It looks like something that can only work in your own language.

I've never seen it before.  To my knowledge, it would be a new thing for
a static-typed language.  But, that doesn't mean it doesn't exist.

> Otherwise, suppose 'struct SAbc' is exported from a library. Will that 
> export include information about the number, names and types of the 
> members? Could a module that imports it add its own members? Can it 
> override the types?

If you are linking to a static library, then there are constraints on
what can exist in any I/O structs.  But on this side of that static
library, the compiler can introduce any degree of additional members
it finds, with the contraint then being that in any I/O the more robust
version internally must be copied to the less robust version for the
I/O, and then copied back.  And so on.

There are ways to handle it, but it depends on how much you want to
invest in such a thing.  It would be enough to honor the constraint
in those cases and limit its use.

Best regards,
Rick C. Hodgin

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

#90049

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.

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

#90050

On 05/07/16 20:38, David Brown wrote:
> So why not simply #include "svariable.h" in "svariable.h" ?

Shurely shome mishtake?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web