Messages

16

Ideas / [Email suggestion No. 2] libraries and build system suggestions

« on: July 19, 2016, 10:23:46 AM »

The introduction of the library system was a great addition which basically turned C2 from an interesting toy that proves some improvement concepts to an interesting usable language. However, there could be some tiny additions make it easier to work with:


2.1 Allow targets to specify additional, perhaps local to the project, C2 libs directory. In C and C++, it is also common to have more include paths, so allowing something like this:

Code: [Select]

target trg
     $generate-c
     $libdir ./myotherinterfacefiles
     file1.c2
     file2.c2
end
could be a great addition to the library system.

2.2 Ability to recognize a prefix in in .c2i files. When there is a header that exposes the following functions:

Code: [Select]

void thislib_function1();
void thislib_function2();
void thislib_function3();
Then typing it as thislib.thislib_function1(); in C2 is not nice on the eyes. My suggestion is to the use of a prefix value in the toml manifest file for the library in the following manner:

Code: [Select]

//manifest file for the thislib
[library]
language = "C"
prefix = "thislib_"

Code: [Select]

[[modules]]
name = "thislib"
header = "thislib.h"

Code: [Select]

//thislib.c2i
func void thislib_function1();
func void thislib_function2();
func void thislib_function3();
In other words, the .c2i files would still contain the prefix, but when used in C2 code, one would use thislib.function1(); which is shorter and more sane.

17

Ideas / [Email suggestion No. 1] macros in C2

« on: July 19, 2016, 10:21:29 AM »

It has been stated in previously that macros need to be changed and not like the ones in C/C++, since those were limited/impacted by the age in which C and C++ were created in. When I was playing with Rust, which is a great programming language with some oddities (like filenames having significance in code, odd build system, variables immutable by default etc.), I stumbled upon Rust's macros, which are a great part of the language I otherwise think is okay, but not overly great. This is how a macro in Rust looks

Code: [Select]

macro_rules! foo {
    (x => $e:expr) => (println!("mode X: {}", $e));
    (y => $e:expr) => (println!("mode Y: {}", $e));
}

The following macro would be then used as:

Code: [Select]

foo!(x => 5); or foo!(y => 10);
because this example uses Rust's pattern matching. I think that a modification of Rust macros, suited for C2's cause, could be a good way how macros could work. Here is a simple suggestion of rules C2 macros could follow:

• Each starts with keyword like macro, followed by name and the content of the macro.
  
• The content may be either single value/statement or a mutiple lines of stuff in {} brackets.
  
• Macros are multi-line by default, no need to use \ to extend number of lines
  
• Macros must contain parse-able C2 code
  
• When used, an exclamation mark ! must be added to the name of the macro and semicolon at the and as if it was a regular statement. example macro:
  

Code: [Select]

macro myassert(desc, test) {
    tests_ran++;
    if (!(test)) {
        char* error;
        asprintf(&error, "[%s:%d]\x1b[31mTEST FAILED\x1b[0m: %s\n",__FILE__, __LINE__, desc);
        asprintf(&finalmessage, "%s%s", finalmessage, error);
    }
    else {
        char* success;
        tests_passed++;
        asprintf(&success, "[%s:%d]\x1b[32mTEST PASSED\x1b[0m: %s\n", __FILE__, __LINE__, desc);
        asprintf(&finalmessage, "%s%s", finalmessage, success);
    }
}
Which could then be used as

Code: [Select]

myassert!("Test if 1 == 1", 1 == 1);
Of course, this is just a simple suggestion, it is just an idea how fitting and readable yet distinguishable macros could work in C2.