Mar.16.2017 -- CAlive to introduce #needs keyword in augment of #include

[Rick C. Hodgin]

CAlive will introduce a new #needs keyword, which will indicate the support needed to allow the module to compile.  It will not automatically #include the file unless it has not yet been specified.

This will allow requirements to be specified in every source file, and multiple times, without producing conflicts or having to use manual workarounds which prevent the file from being loaded more than once.

    #needs <windows.h>

    #needs <myFile.h>

These #needs lines operate like #include files, but rather than directly including their content will add to an increasing and growing list of known files to include, which will only have been loaded once for each file during compilation.

Note:  #include is also still supported.

Thank you,

Rick C. Hodgin

[anto...@gmail.com]

Why did you decide against using true units instead of include files? I mean the way modern Pascal and the Modula languages do it? Include files are an unstructured and non-modular method of inserting text files into other text files. True modules can support namespaces *or* (for both would be redundant) import aliases to avoid name collisions.

[Rick C. Hodgin]

I don't want to support namespaces.  I'm trying to figure out a more elegant way to handle that feature.

The software I plan to write for LibSF will be an integrated unit.  I do not want to choose global names which will occupy the name space of other things.  By using classes, all issues should be resolvable without the need to enter into a namespace.

CAlive is also a compiler that does not require tokens to be defined before they're referenced, which is why the #needs keyword was added.  It is enough to indicate your application needs a particular library, and then everything within it is available to the rest of the program.  This changes some of the things about how C-like source code is compiled, in that everything is not completely sequentially compiled, but it does make it easier for human beings to deal with ... which is my goal.

Thank you,

Rick C. Hodgin

[anto...@gmail.com]

Rick C. Hodgin:

> I don't want to support namespaces. I'm trying to figure
> out a more elegant way to handle that feature.

To handle name collistions, that is?

I mentioned also import aliases like in Modula, e.g.:

import GetFiles from FileSystem AS FS_GetFiles;

which would make the function GetFiles() from the module
FileSystem available in the current module as FS_GetFiles().
Another method would be to assign a prefix for a whole
module:

import FileSystem as FS_

so that all the public functions from FileSystem should be
available with the 'FS_' prefix, whereas the simple
declarations

import GetFiles from FileSystem;
import FilesSystem

would make the functions available under their real names.

> The software I plan to write for LibSF will be an
> integrated unit.

Do you mean a single source file?

> I do not want to choose global names which will occupy the
> name space of other things. By using classes, all issues
> should be resolvable without the need to enter into a
> namespace.

That seems merely to substitute classes for namespaces, and
thereby move the problem to class level. The classes
themselves will share a single global namespace, will they
not? If so, does your solution rely on the lower number of
classes in a typical program compared to the number of
functions?

How is one supposed to use first-class functions, that is
normal procedures rather than the methods of a dynamic
class? Will you introduce static classes, such as C# has?

> CAlive is also a compiler that does not require tokens to
> be defined before they're referenced, which is why the
> #needs keyword was added. It is enough to indicate your
> application needs a particular library, and then
> everything within it is available to the rest of the
> program.

I fear it may muddle the design, for the dependencies of a
unit or file will no longer be visible at single glance at
the top. I think that the dependecies of every file should
be explicitly declared at least for the reader's sake, to
make the code clear. Good modular design is impossible
without rigid and explicitly specified inter-module
dependencies, which you seem to avoid.

Why do you keep to types of code file: .h and .c, whereas
true units with an "interface" and an "implemenation" secton
are eaisier to maintain and more cohesive. The addition of
a new public function, for example, does not require
modification of two files. Modules are self-contained and
thefore beautiful.

> This changes some of the things about how C-like source
> code is compiled, in that everything is not completely
> sequentially compiled, but it does make it easier for
> human beings to deal with ... which is my goal.

A most commendable goad, so best of luck with that and may
God help thee.

[Rick C. Hodgin]

On Tuesday, March 21, 2017 at 4:43:58 PM UTC-4, anto...@gmail.com wrote:

Rick C. Hodgin:

> The software I plan to write for LibSF will be an
> integrated unit.

Do you mean a single source file?

No.  But in each place the source code will be directly accessible with #needs references.  It will all be built together.

If you look at the various projects (superjet, for example) that use the Visual FreePro, Jr. engine, you can see how they all operate together even today in C/C++ code.

 

> I do not want to choose global names which will occupy the
> name space of other things. By using classes, all issues
> should be resolvable without the need to enter into a
> namespace.

That seems merely to substitute classes for namespaces, and
thereby move the problem to class level. The classes
themselves will share a single global namespace, will they
not?

There is no namespace in CAlive, but they will all be global in scope ... so in a way:  yes.
 

If so, does your solution rely on the lower number of
classes in a typical program compared to the number of
functions?

How is one supposed to use first-class functions, that is
normal procedures rather than the methods of a dynamic
class? Will you introduce static classes, such as C# has?

CAlive takes a very straight-forward view of the class.  I introduce private and public members, and that's it.

If you want a static class, you need only declare it publicly.  Static members will be available, but are not necessary.  CAlive will allow all members to be called dynamically or statically by use of marshalling functions for static references:

https://groups.google.com/d/msg/caliveprogramminglanguage/Z3Xzrz9Ai54/DWh-bnxXEAAJ

 

Why do you keep to types of code file: .h and .c, whereas
true units with an "interface" and an "implemenation" secton
are eaisier to maintain and more cohesive. The addition of
a new public function, for example, does not require
modification of two files. Modules are self-contained and
thefore beautiful.

CAlive will use .ca files.  It will not require .h files, but those can be used for backward compatabilty.  In fact, nearly all of C code can be left as is and it will compile.
 

> This changes some of the things about how C-like source
> code is compiled, in that everything is not completely
> sequentially compiled, but it does make it easier for
> human beings to deal with ... which is my goal.

A most commendable goad, so best of luck with that and may
God help thee.

Thank you.  I've spent a substantial amount of time on CAlive's design.  I believe it is well thought out, considered, and viable for software development.  However, I'm also creating it within the RDC framework, which will allow global changes to the overall language design to be made apart from the design, with support for the compiler layers and syntax parsing layers, which emanate from the framework and not directly from the language itself.

Thank you,

Rick C. Hodgin

[anto...@gmail.com]

Rick C. Hodgin:

> But in each place the source code will be directly
> accessible with #needs references.  It will all be
> built together.

It  is hard to understand without at least an infor-
mal description of what #needs does and how it  dif-
fers from C's #include or Pascal's 'uses'.

Do  you  not  maintain a working draft of a document
describing the language which people with experience
in  C could understand?  Google groups posts are too
desultory to give a consistent picture.

> There is no namespace in CAlive,  but  they  [Ant:
> objects]  will  all  be global in scope... so in a
> way:  yes.

So no mechanism is provided for solving name  colli-
sions?

> CAlive  takes  a very straight-forward view of the
> class.  I introduce private  and  public  members,
> and that's it.

No interfaces and polymorphism?  Although I do real-
ize that support for OOP is an additional  layer  of
tremendous  complexity,  going  half-way  seems  not
worth the effort either.

Shall you roll structs with function pointers  when-
ever  you  need  dependency  injection or loose cou-
pling?

> If you want a static class, you need only  declare
> it  publicly.   Static  members will be available,
> but are not necessary.

Shall the invocations of static functions be  always
qualified by the name of the class, as they shall in
C#?

[Rick C. Hodgin]

On Friday, March 24, 2017 at 11:27:52 PM UTC-4, anto...@gmail.com wrote:

Rick C. Hodgin:

> But in each place the source code will be directly
> accessible with #needs references.  It will all be
> built together.

It  is hard to understand without at least an infor-
mal description of what #needs does and how it  dif-
fers from C's #include or Pascal's 'uses'.

In C or C++, in order for something to compile it needs to have all of its dependencies applied.  You have all of the #include files required.

#needs operates in the same way, except that you are simply indicating that in order to compile this program it needs to have those #include files.

In this way, you can have #include files which have embedded #include files which use #needs instead of #include, such that the list is extended for any new files encountered, but those which are duplicates are simply ignored as already being known to be needed.

In this way, everything can indicate what it needs in order to compile, but without having errors of re-definition, symbols defined twice or functions already with a body, etc., as the #needs content is only compiled once, and even then only when it's needed.

 

Do  you  not  maintain a working draft of a document
describing the language which people with experience
in  C could understand?  Google groups posts are too
desultory to give a consistent picture.

Sort of:

http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/books/rdc

http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/exodus/tools/rdc/rdc_specs.txt

 

> There is no namespace in CAlive,  but  they  [Ant:
> objects]  will  all  be global in scope... so in a
> way:  yes.

So no mechanism is provided for solving name  colli-
sions?

Yes.  Rename things. :-)

 

> CAlive  takes  a very straight-forward view of the
> class.  I introduce private  and  public  members,
> and that's it.

No interfaces and polymorphism?  Although I do real-
ize that support for OOP is an additional  layer  of
tremendous  complexity,  going  half-way  seems  not
worth the effort either.

Polymorphism yes.  Interfaces no.

 

Shall you roll structs with function pointers  when-
ever  you  need  dependency  injection or loose cou-
pling?

Can you provide me an example.

 

> If you want a static class, you need only  declare
> it  publicly.   Static  members will be available,
> but are not necessary.

Shall the invocations of static functions be  always
qualified by the name of the class, as they shall in
C#?

No.  If they can be uniquely identified by their singular name, the class reference is not required.  It can, however, always be used.  And, when providing a static function you can use the class name or any class pointer, including the following:

    xyz* p = NULL;

    p->static_function();

The p variable is never actually referenced here, except as an identifier as to the type, which identifies static_function() as a static function, and allows it to be referenced as such.

[Rick C. Hodgin]

On Monday, March 20, 2017 at 5:26:40 PM UTC-4, Rick C. Hodgin wrote:
> I don't want to support namespaces.  I'm trying to figure out a more elegant way to handle that feature.
>
> The software I plan to write for LibSF will be an integrated unit.  I do not want to choose global names which will occupy the name space of other things.  By using classes, all issues should be resolvable without the need to enter into a namespace.
>
> CAlive is also a compiler that does not require tokens to be defined before they're referenced, which is why the #needs keyword was added.  It is enough to indicate your application needs a particular library, and then everything within it is available to the rest of the program.  This changes some of the things about how C-like source code is compiled, in that everything is not completely sequentially compiled, but it does make it easier for human beings to deal with ... which is my goal.

I have finally figured out a way to avoid namespaces. I will post
details about this solution in another thread.

--
Rick C. Hodgin