136
General Discussion / Re: Typo in manual
« on: March 06, 2017, 09:36:44 PM »
fixed.
I hope you have a very pleasantflight eh experience from now on 
I hope you have a very pleasant
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
137
General Discussion / Re: Diffs to C99 and C11
« on: February 16, 2017, 04:50:44 PM »
There is a page called 'Changes from C' in the documentation that highlights some big changes. Otherwise
there are many smaller changes. Just look at some code fragments in the examples/ dir and the unit tests.
Macros in C/C++ work by including (copy-pasting) a header file into a .c/cpp file. The preprocessor then does
textual replacements. This is very flexible, but also prevents the compiler from many useful diagnostics
(or at least makes it very hard). There is a post about macros on the forum that explains the different use
cases for macros.
Variable length arrays are supported in function scope (just like newer C standards). At global scope, C2 allows
'adding' items from different parts of the code, but essentially at runtime these are fixed size. Multi-dimensional arrays
are supported just like C/C++.
OpenMP is not in the planning yet..
there are many smaller changes. Just look at some code fragments in the examples/ dir and the unit tests.
Macros in C/C++ work by including (copy-pasting) a header file into a .c/cpp file. The preprocessor then does
textual replacements. This is very flexible, but also prevents the compiler from many useful diagnostics
(or at least makes it very hard). There is a post about macros on the forum that explains the different use
cases for macros.
Variable length arrays are supported in function scope (just like newer C standards). At global scope, C2 allows
'adding' items from different parts of the code, but essentially at runtime these are fixed size. Multi-dimensional arrays
are supported just like C/C++.
OpenMP is not in the planning yet..
138
General Discussion / Re: clangd compilation server
« on: February 16, 2017, 04:45:06 PM »
Thanks for mentioning it here. I did catch something of it some time ago. This solution is nice for large C/C++ codebases
where compilation times are non-trivial. For C2 I haven't even found a good reason to multi-thread yet... (1.8 Mloc/sec parsing,
800Kloc/sec with analysis). Since the latest vim (7 if I remember correctly) they support pipes that can be used by plugins
to for example talk to a persistent server/daemon like this..
where compilation times are non-trivial. For C2 I haven't even found a good reason to multi-thread yet... (1.8 Mloc/sec parsing,
800Kloc/sec with analysis). Since the latest vim (7 if I remember correctly) they support pipes that can be used by plugins
to for example talk to a persistent server/daemon like this..
139
Implementation Details / Re: incremental arrays
« on: January 29, 2017, 11:16:30 AM »
The intention was indeed to remove a lot of macro magic by allowing incremental arrays. Currently all parts must be
in the same file I think, but I don't think there are problems when allowing multiple files in same module (since the order is
specified in the recipe).
in the same file I think, but I don't think there are problems when allowing multiple files in same module (since the order is
specified in the recipe).
140
Ideas / Re: Vectors in combination with semi-automatic memory management
« on: January 04, 2017, 08:04:00 AM »
C has a perfect mechanism to clean up what you allocate in a function: the stack.
When you need some piece of memory that has a bigger lifetime than the function, you use malloc.
So I'm a bit confused as well what you want. In C++ destructor functions are used to do the stuff you describe
(with smartpointer concepts).
When you need some piece of memory that has a bigger lifetime than the function, you use malloc.
So I'm a bit confused as well what you want. In C++ destructor functions are used to do the stuff you describe
(with smartpointer concepts).
141
Ideas / Re: Enum classes
« on: January 04, 2017, 07:45:40 AM »
Most modern C compilers will give a warning on this. In C2 this will just be an error and requires an
explicit cast to work..
explicit cast to work..
142
Ideas / Re: Enum classes
« on: January 02, 2017, 08:30:36 PM »
The big advantage of explicit enum types would be to catch mistakes like:
In languages where an enum is just an integer, the above would be perfectly fine. Currently the C2 compiler
catches these issues (but ATM doesn't give a nice diagnostic msg yet). So internally, enum constants have
the type of the enum (and not just int8). Maybe that's enough for now, since the only other advantage is being
able to have different enum types in the same module, with same enum constants (eg. both have a 'Middle')...
Code: [Select]
type Temperature enum int8 {
Low,
High,
}
type State enum int8 {
Begin,
End,
}
State state = High; // <- wrong enum constant
In languages where an enum is just an integer, the above would be perfectly fine. Currently the C2 compiler
catches these issues (but ATM doesn't give a nice diagnostic msg yet). So internally, enum constants have
the type of the enum (and not just int8). Maybe that's enough for now, since the only other advantage is being
able to have different enum types in the same module, with same enum constants (eg. both have a 'Middle')...
143
Ideas / Re: Struct Functions - part 2
« on: January 02, 2017, 08:19:35 PM »
In C2 'this' is not a keyword. It's just the name of the first argument used in struct functions. You are allowed
to use any name you want. The question was whether to let developers skip the 'this.member' and just type 'member'
inside struct functions. The compiler would then convert 'member' to '<name_of_arg0>.member'.
This way struct functions are a lot more similar to C++ class functions (where you are also allowed to use 'this->member'),
but can also just use 'member'.
to use any name you want. The question was whether to let developers skip the 'this.member' and just type 'member'
inside struct functions. The compiler would then convert 'member' to '<name_of_arg0>.member'.
This way struct functions are a lot more similar to C++ class functions (where you are also allowed to use 'this->member'),
but can also just use 'member'.
144
General Discussion / Re: Pthreads
« on: January 02, 2017, 08:15:04 PM »
I think that in general most modern solutions tend to trade complexity for disk-space. Disk space is cheap, while
complexity is growing. So, for example, instead of having a complex package system with a lot of dependency-tracking,
a (big) application would just provide all the libs it needs itself. This is also basically the idea of Docker and such.
While I agree that it is often a good trade, it also feels a bit like admitting to a loss.
Building software can be quite straightforward, as shown by many (non-mainline) languages such as Ada etc. Remember
that the C2 compiler knows everything it needs to build the C2 code in the project. The only other things it needs to understand
are libraries (basically collections of symbols with some plumbing) and linking (format depends on platform). For stuff like
opening a file, C2 re-uses llvm libraries.
While it would be very nice to solve all the libc legacy, that is simply not a realistic way forward for C2 at the moment. So there
will be different versions of C2 libc for different platforms. Since C2 does *not* target Windows, most *nix systems don't differ
too much to cause real problems..
complexity is growing. So, for example, instead of having a complex package system with a lot of dependency-tracking,
a (big) application would just provide all the libs it needs itself. This is also basically the idea of Docker and such.
While I agree that it is often a good trade, it also feels a bit like admitting to a loss.
Building software can be quite straightforward, as shown by many (non-mainline) languages such as Ada etc. Remember
that the C2 compiler knows everything it needs to build the C2 code in the project. The only other things it needs to understand
are libraries (basically collections of symbols with some plumbing) and linking (format depends on platform). For stuff like
opening a file, C2 re-uses llvm libraries.
While it would be very nice to solve all the libc legacy, that is simply not a realistic way forward for C2 at the moment. So there
will be different versions of C2 libc for different platforms. Since C2 does *not* target Windows, most *nix systems don't differ
too much to cause real problems..
145
General Discussion / Re: Question: how are growable arrays implemented?
« on: January 02, 2017, 03:44:32 PM »
C2 doesn't have growable arrays in the sense that they can grow during runtime. They can 'grow' during compilation. The C2 compiler just
merges all the 'array += value' declarations and creates a single (static) array. The may goal was to avoid having to use complicated macros when
you want to extend both an enum and a data structure that uses the enum constants as index.
merges all the 'array += value' declarations and creates a single (static) array. The may goal was to avoid having to use complicated macros when
you want to extend both an enum and a data structure that uses the enum constants as index.
146
General Discussion / Re: C-domain useful features
« on: December 10, 2016, 09:26:03 AM »
Exactly, It's also a explicit non-goal to make the language help developers. What!?!?
With C2 my ideas is to restrict to language a bit more. This is similar to Python with the
one-way to do things. So if something is allowing in C, but in any of my project we would
disallow a certain construction (by agreement), in C2 this would simply be forbidden in the
language. This will make C2 programs more consistent and easier to read.
With C2 my ideas is to restrict to language a bit more. This is similar to Python with the
one-way to do things. So if something is allowing in C, but in any of my project we would
disallow a certain construction (by agreement), in C2 this would simply be forbidden in the
language. This will make C2 programs more consistent and easier to read.
147
Ideas / Re: Struct Functions - part 2
« on: December 09, 2016, 08:47:07 AM »
One of the basic design choices in C2 is not to do symbol mangling. So for a function, it should be quite
clear what the exact symbol will look like. In C2 this is currently 'module_symbol', which is not real mangling,
but just concat-ing module name and symbol name.
I agree that the syntax of struct functions is probably not the best it can be, but I'm still puzzling to find
a better one.
One idea that came up during usage is to add the struct members to the 'namespace' of the function. So
you don't have to do 'this.member' but can simply do 'member'. This leads to the question whether a user
should have to type the first argument and whether it's always 'this'. I always prefer simplicity when in doubt
and I don't think that saving some keystrokes should be a goal. A simple language with a well readable syntax
is a higher goal imho.
Another idea would be to make the fact that a function is a struct function more explicit. In that sense your
syntax proposal could be used...
clear what the exact symbol will look like. In C2 this is currently 'module_symbol', which is not real mangling,
but just concat-ing module name and symbol name.
I agree that the syntax of struct functions is probably not the best it can be, but I'm still puzzling to find
a better one.
One idea that came up during usage is to add the struct members to the 'namespace' of the function. So
you don't have to do 'this.member' but can simply do 'member'. This leads to the question whether a user
should have to type the first argument and whether it's always 'this'. I always prefer simplicity when in doubt
and I don't think that saving some keystrokes should be a goal. A simple language with a well readable syntax
is a higher goal imho.
Another idea would be to make the fact that a function is a struct function more explicit. In that sense your
syntax proposal could be used...
148
General Discussion / Re: C-domain useful features
« on: December 09, 2016, 08:40:37 AM »The 'examples' directory from the c2compiler git archive is indeed a more practical example. For more
extensive code fragments showing of specific features, you can look at the 'test' directory. That contains
the automated tests that test individual features.
The goal of C2 is to be a better C. For some problem domains, C++ would be a better choice than C. Let's
call this domain the systems-programming domain. Most big new languages like Go, Swift, D, Rust target
that domain. C2 explicitly does not, since you need a lot more higher-level features there, like some form
of object-orientation, some form of memory-management (even like C++'s destructor).
Even the C2 compiler is written in C++, which is a better choice than C for those type of applications.
I used to love C++, but the direction it's going is simply that of one big mess. And looking on the Internet,
I'm not alone in that opinion. I would love to see a combination of C++ and C2, say C2++
But for C2, there simply cannot be a viable, runtime, etc.
Which features of C++ don't you like?
149
General Discussion / Re: C-domain useful features
« on: December 08, 2016, 08:22:58 PM »
Nice that you like it!
Now about your remarks/question:
attributes
The syntax for type definitions is: 'type <name> <definition> <aliases>'.
This works quite well for some types, but might indeed look weird on enum and structs that
use {} in their definition. Since function definitions look similar to struct type definitions and
they use the syntax: 'func <return type> <name> (<params>) <attributes> { .. }', it might
be an idea to make struct/enum refs similar to functions so that it becomes:
What do you think?
semicolon
In regard to the remark about missing semi-colon after a '}', the rule is very simple: In C2 a '}' will never be followed
by a semi-colon. This is done because C sometimes requires it and sometimes not. It's also easier on the eyes.
ordering
Funny that you find ordering helpful. I just jump-to-definition in my editor and don't care much about where something is
defined. The design rule here is 'define everything once'. This is one of the foundations of C2. So no forward declarations,
so then you need a multi-pass parser since declarations cannot mutually refer to the other.
imports
One other design goal is to keep the syntax as simple/readable as possible since you spent a lot more time reading code than
writing it. So in my opinion, all the extra public {} is just plain ugly and unnecessary complex. Also it's important to think about
the semantics of such a thing. That is, what does it mean. That should also be very clear. Since C2 does no symbol mangling
like for example C++, some restrictions apply (for example no operator overloading on functions, etc).
So currently there are 2 access types:
- public - this means visible outside module (if imported)
- non-public - only usable from within same module.
The concept of a third one has been discussed earlier, namely a 'private' access, so only usable within the same file.
After consideration this was deemed to introduce nothing new and only make things more complex. Also consider the
no-mangling rule.
auto / lambda
Both the auto and lambda concepts have their place, but they simply don't fit into a c-like language. I
find the auto keyword annoying, since I cannot see the type directly. And the 'gain' is nothing much.
Lambda functions are very nice, but required functions as first class citizens to make them truly useful. This
just doesn't work in a C-like language. So keep it mind that C2 tries to improve C while keeping the same 'core'.
struct functions
You have a point about the syntax of struct functions. There might be a better syntax. The thing to keep in
mind is the no-name-mangling though. Also (quote) C2 is not C++ (unquote). So there is no viable and this
pointer in the sense of C++. Struct functions are purely syntactic sugar (but very nice nonetheless).
I am toying with the idea of adding the struct members in the namespace of a struct functions to avoid all
the 'this.' usage. I cannot see any real objections so far and the code does look a lot cleaner (and the same
as for example C++).
stdlib/stdio imports
When code in some file wants to use symbols from another module, it needs to import those. The 'import verylongname as van'
allows developers to make their own code look much nice, while allowing longer module names to be used. Imports are NOT
handled in the same way is C/C++ #include's. Those are much more expensive. In a C2 program, the stdio code is only parsed
once for the entire compilation of the entire program, not once per file. Also the symbol table is linked into the global symbol table,
a very cheap operation. If you worry about speed, you should definitely switch to C2
On my laptop C2 compiler parses around 1.5-1.8 million lines of C2 per second in a single thread!
Whow that was also a long reply. Your ideas were definitely useful. So we need to re-evaluate the syntax of struct-functions and
the syntax(position) of attributes for enum/struct types.
--Cheers--
Now about your remarks/question:
attributes
The syntax for type definitions is: 'type <name> <definition> <aliases>'.
This works quite well for some types, but might indeed look weird on enum and structs that
use {} in their definition. Since function definitions look similar to struct type definitions and
they use the syntax: 'func <return type> <name> (<params>) <attributes> { .. }', it might
be an idea to make struct/enum refs similar to functions so that it becomes:
Code: [Select]
type Point struct @(packed) {
int32 x;
int32 y;
}
What do you think?
semicolon
In regard to the remark about missing semi-colon after a '}', the rule is very simple: In C2 a '}' will never be followed
by a semi-colon. This is done because C sometimes requires it and sometimes not. It's also easier on the eyes.
ordering
Funny that you find ordering helpful. I just jump-to-definition in my editor and don't care much about where something is
defined. The design rule here is 'define everything once'. This is one of the foundations of C2. So no forward declarations,
so then you need a multi-pass parser since declarations cannot mutually refer to the other.
imports
One other design goal is to keep the syntax as simple/readable as possible since you spent a lot more time reading code than
writing it. So in my opinion, all the extra public {} is just plain ugly and unnecessary complex. Also it's important to think about
the semantics of such a thing. That is, what does it mean. That should also be very clear. Since C2 does no symbol mangling
like for example C++, some restrictions apply (for example no operator overloading on functions, etc).
So currently there are 2 access types:
- public - this means visible outside module (if imported)
- non-public - only usable from within same module.
The concept of a third one has been discussed earlier, namely a 'private' access, so only usable within the same file.
After consideration this was deemed to introduce nothing new and only make things more complex. Also consider the
no-mangling rule.
auto / lambda
Both the auto and lambda concepts have their place, but they simply don't fit into a c-like language. I
find the auto keyword annoying, since I cannot see the type directly. And the 'gain' is nothing much.
Lambda functions are very nice, but required functions as first class citizens to make them truly useful. This
just doesn't work in a C-like language. So keep it mind that C2 tries to improve C while keeping the same 'core'.
struct functions
You have a point about the syntax of struct functions. There might be a better syntax. The thing to keep in
mind is the no-name-mangling though. Also (quote) C2 is not C++ (unquote). So there is no viable and this
pointer in the sense of C++. Struct functions are purely syntactic sugar (but very nice nonetheless).
I am toying with the idea of adding the struct members in the namespace of a struct functions to avoid all
the 'this.' usage. I cannot see any real objections so far and the code does look a lot cleaner (and the same
as for example C++).
stdlib/stdio imports
When code in some file wants to use symbols from another module, it needs to import those. The 'import verylongname as van'
allows developers to make their own code look much nice, while allowing longer module names to be used. Imports are NOT
handled in the same way is C/C++ #include's. Those are much more expensive. In a C2 program, the stdio code is only parsed
once for the entire compilation of the entire program, not once per file. Also the symbol table is linked into the global symbol table,
a very cheap operation. If you worry about speed, you should definitely switch to C2
On my laptop C2 compiler parses around 1.5-1.8 million lines of C2 per second in a single thread!
Whow that was also a long reply. Your ideas were definitely useful. So we need to re-evaluate the syntax of struct-functions and
the syntax(position) of attributes for enum/struct types.
--Cheers--
150
General Discussion / Re: Syntax highlighting for vim
« on: December 08, 2016, 07:47:53 PM »
I've tried it and it look a lot better than applying the C syntax! Kudos!
Do you have any plans to extend it even more?
Do you have any plans to extend it even more?