1
General Discussion / Re: C2 discord server
« on: October 21, 2019, 11:19:45 PM »
nice!
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.
2
Ideas / Re: Remove const
« on: July 15, 2019, 10:00:01 PM »
(thought experiment using in/out)
Trying to convert const (in combination with pointers) to in/out gives the following:
All examples below as function arguments:
NOTE that for the char* case, that in the old situation only read+write can be expressed, while in the new
situation, both read-write (inout) AND write-only (out) (or uninitialized reads) can be expressed!
Trying to convert const (in combination with pointers) to in/out gives the following:
All examples below as function arguments:
| old | new | meaning |
| const char* | in char* | contents may only be read |
| char* | out char* | contents may be written, but must be considered uninitialized for reading at moment of call |
| inout char* | contents may be read and written | |
| char** | out char** | contents may be written, but must be considered uninitialized for reading at moment of call |
| inout char** | contents may be read and written |
NOTE that for the char* case, that in the old situation only read+write can be expressed, while in the new
situation, both read-write (inout) AND write-only (out) (or uninitialized reads) can be expressed!
3
Ideas / Re: Remove const
« on: July 15, 2019, 07:29:02 PM »
I was recently struggling with the '
To narrow the discussion, I think only const in combination with pointers are an issue.
Another note for Alias types in C2:
I always use the keyword const in combination with pointer arguments to indicate that the destination
is not changed. This is indeed more of an API thing. Also I recently had to work with a lot of UEFI
code. This is C code with many macros. One is that they use IN and OUT in all the header files. These
expend to nothing and are used like
This is also use in other languages like Ada:
I think words like IN/OUT read quite naturally. But to include them in C2, we would have
to decide on what this means with pointers or pointers-to-pointers. I can think of the following use-cases:
The goal here should be making the code more readable (or easier to understand),
not allowing extra compiler-optimizations. Or does anyone know if const unlocks some
very powerfull optimizations?
Code: [Select]
const int* const' syntax. This is not yet supported in C2.To narrow the discussion, I think only const in combination with pointers are an issue.
Code: [Select]
const i32 Max = 10; is no issue. It is roughly equivalent of using a define in C.Another note for Alias types in C2:
Code: [Select]
type IntP int*; // alias type
const IntP ip = a; // is a 'const IntP' ... but weird, 'const IntP' is different from 'const int*'
I always use the keyword const in combination with pointer arguments to indicate that the destination
is not changed. This is indeed more of an API thing. Also I recently had to work with a lot of UEFI
code. This is C code with many macros. One is that they use IN and OUT in all the header files. These
expend to nothing and are used like
Code: [Select]
void example(IN Buffer* buffer, OUT Result* result);
This is also use in other languages like Ada:
Code: [Select]
procedure TEST01 ( In_State : IN VECT_B ; Out_State : IN OUT VECT_B );
I think words like IN/OUT read quite naturally. But to include them in C2, we would have
to decide on what this means with pointers or pointers-to-pointers. I can think of the following use-cases:
- passing pointer - the dest may not be modified
- passing pointer - the dest may be modified
- passing pointer-pointer - the param may be modified, normal out-param case
- passing multiple-dimension pointer arg - dest may not be modified
The goal here should be making the code more readable (or easier to understand),
not allowing extra compiler-optimizations. Or does anyone know if const unlocks some
very powerfull optimizations?
4
Ideas / Re: Defer on functions.
« on: March 24, 2019, 11:20:23 AM »
Interesting idea. I recently read an article about functional languages where one of the basic requirements
of a function call in any language was that the caller could predict its own state after the call returned. This is
not the case anymore when defers are added by the called function..
of a function call in any language was that the caller could predict its own state after the call returned. This is
not the case anymore when defers are added by the called function..
5
Ideas / Re: Built-in managed pointers
« on: March 24, 2019, 11:18:44 AM »
Managed pointers are part of the core design of a language. Rust for example was built around some
management ideas. In those languages you cannot do without something like this. I don't see how
introducing an ideas like this wouldn't alter a C-like language completely.
I think programming in C requires some skill and experience, but like handling a chainsaw.
I prefer cutting a tree with a chainsaw (never actually tried though) than with a plastic toy.. (Not comparing
Rust with a toy!). Once you have some experience in C, memory management is not that hard.
management ideas. In those languages you cannot do without something like this. I don't see how
introducing an ideas like this wouldn't alter a C-like language completely.
I think programming in C requires some skill and experience, but like handling a chainsaw.
I prefer cutting a tree with a chainsaw (never actually tried though) than with a plastic toy.. (Not comparing
Rust with a toy!). Once you have some experience in C, memory management is not that hard.
6
Ideas / Re: Switch proposal
« on: March 12, 2019, 10:34:32 AM »
I was thinking about the fallthrough keyword and came up with a situation that requires some thinking.
How would we handle:
So the fallthrough can be used to 'jump' to the next case. Or only allow fallthrough at the end?
To avoid this complexity, I see that Go (golang.org) only allows fallthrough at the end. So probably that is best..
How would we handle:
Code: [Select]
...
case A:
if (b == 10) fallthrough;
do_something();
case B:
..
So the fallthrough can be used to 'jump' to the next case. Or only allow fallthrough at the end?
To avoid this complexity, I see that Go (golang.org) only allows fallthrough at the end. So probably that is best..
7
Ideas / Re: Macro-system design
« on: February 28, 2019, 08:26:30 AM »
I agree with https://npf.io/2018/09/go2-contracts-go-too-far. It's too complex IMHO.
When you want an argument to be of a specific type in C, don't you just say myfunc(Foo a), instead of requiring a to be
of type Foo later. The only thing you can't do that way is force multiple arguments to be of some Type 'T' that just supports
the required operations in the macro. Something Generics may solve. Also the typeof() may be needed as in your example.
I want to learn Nim macros more before building my opinion about them.. Today is Nim day
When you want an argument to be of a specific type in C, don't you just say myfunc(Foo a), instead of requiring a to be
of type Foo later. The only thing you can't do that way is force multiple arguments to be of some Type 'T' that just supports
the required operations in the macro. Something Generics may solve. Also the typeof() may be needed as in your example.
I want to learn Nim macros more before building my opinion about them.. Today is Nim day
8
Ideas / Re: Explicit non-null-ness
« on: February 28, 2019, 08:03:49 AM »
In C++ a reference is also a pointer that's 'guaranteed' to be non-null. This can work because a function in C++ can return
an object itself that's turned into a reference. I don't see how this could work in C because C doesn't have copy-constructors etc.
an object itself that's turned into a reference. I don't see how this could work in C because C doesn't have copy-constructors etc.
9
Ideas / Macro-system design
« on: January 30, 2019, 09:17:13 AM »
Since C2 wants to avoid the pitfalls of the C textual-replacement based macro system (and C2 doesn't have includes), a replacement macro system is needed.
Macros have a various, valid use-cases. I'll focus on one case here and try to find a nice syntax + semantics.
What I want is to be able to put a loop over a data structure in a macro, so that changing the underlying data structure maybe doesn't need any 'api' change
for users. So something like
(in some function)
So:
The definition could be roughly something like:
For C macro's all these questions are easy, since it's just replacing text. But that gives rise to a lot of issues, so a new system
is definitely needed. But I think a non-textual system will have a lot more restrictions (which can be good), so when designing a
new system, the goal should not be to find a replacement for every possibility in C macros. This won't work. My plan is to
start creating a set of use-cases and build on top of that. The foreach example is just one of those use-cases.
Macros have a various, valid use-cases. I'll focus on one case here and try to find a nice syntax + semantics.
What I want is to be able to put a loop over a data structure in a macro, so that changing the underlying data structure maybe doesn't need any 'api' change
for users. So something like
(in some function)
Code: [Select]
// there is a list.List* mylist that points to the list (let's say a linked-list)
list.foreach(mylist, i) { // i is the name of the Element*
// use Element* i here
if (i.value == 10) break;
}
So:
- list.foreach is the macro
- When changing the data structure from a linked list to a vector, nothing much has to change in the fragment.
- The break statement should break out of the macro loop even if the macro itself has multiple, nested loops.
The definition could be roughly something like:
Code: [Select]
public macro foreach(List* thelist, iname) {
Element* iname = thelist.first;
while (iname != nil) {
// macro body should be here, How to specify?
iname = iname.next;
}
}
So this brings up a lot of questions:- how to let a user specify the name of the iterator?
- Do we required types for macro arguments?
- How can we specify the place for the macro body?
- Do we allow using variables from the calling scope (and how to specify)
- How can we implement the break in user code
- Do we allow nested macro calling?
For C macro's all these questions are easy, since it's just replacing text. But that gives rise to a lot of issues, so a new system
is definitely needed. But I think a non-textual system will have a lot more restrictions (which can be good), so when designing a
new system, the goal should not be to find a replacement for every possibility in C macros. This won't work. My plan is to
start creating a set of use-cases and build on top of that. The foreach example is just one of those use-cases.
10
Implementation Details / Re: C2 in C
« on: January 29, 2019, 10:18:12 AM »
The difference between C and C2 is that you need multiple passes to analyze C2. So sizeof(Foo) cannot be resolved until you
know what Foo is. This means the parser (with Sema) will have to create the AST first and the Analyzer will iteratively resolve
it. That's what's happening currently. A pass is very lightweight, if it only wants to look at a subset (for example the imports), since
we are iterating over a data structure and not actually 'parsing' it again.
So constant folding is just a certain pass that can happen if other required passes have been done.
know what Foo is. This means the parser (with Sema) will have to create the AST first and the Analyzer will iteratively resolve
it. That's what's happening currently. A pass is very lightweight, if it only wants to look at a subset (for example the imports), since
we are iterating over a data structure and not actually 'parsing' it again.
So constant folding is just a certain pass that can happen if other required passes have been done.
12
Implementation Details / Re: Implementation based on Clang or...?
« on: December 21, 2018, 08:01:54 AM »
Why?? What would that bring for the language. It's just work at the moment. I think the most important
thing is the language itself, not the implementation.
A compiler consists of:
- tokenizer
- parser
- analyser + diagnostics
- code generator
currently, only the tokenizer + diagnostics are not lean, because they use Clang implementation for C/C++. The rest is quite lean already.
thing is the language itself, not the implementation.
A compiler consists of:
- tokenizer
- parser
- analyser + diagnostics
- code generator
currently, only the tokenizer + diagnostics are not lean, because they use Clang implementation for C/C++. The rest is quite lean already.
13
Ideas / Re: Extended switch statement
« on: December 17, 2018, 12:59:15 PM »
While there are a zillion things we can change about C2, the idea is that C2 is an evolution of C.
While changes like the binary operator precedence and default switch break are real improvements, I feel
that many other changes (like this one) are just that: changes. It's not really better/worse, just different.
On the roadmap are some (big) outstanding issues that really have to be designed, like a macro system
and cast operator syntax among others. Any other changes just make the language more different than
C. And since C is still used after 40 years, the core must be good..
This also goes for many other ideas and change pitches as well. For me, the fun in C2 is improving the bad
part and leave everything else the same (as possible)..
While changes like the binary operator precedence and default switch break are real improvements, I feel
that many other changes (like this one) are just that: changes. It's not really better/worse, just different.
On the roadmap are some (big) outstanding issues that really have to be designed, like a macro system
and cast operator syntax among others. Any other changes just make the language more different than
C. And since C is still used after 40 years, the core must be good..
This also goes for many other ideas and change pitches as well. For me, the fun in C2 is improving the bad
part and leave everything else the same (as possible)..
14
General Discussion / Re: C2x
« on: December 16, 2018, 10:56:47 AM »
Importing these changes will take careful consideration. Many changes however only become relevant when we generate IR code and not C code.
This goes (I think) for 1, 3
2. TBD
4. C2 has an extensible attribute system already, so this is pretty much solved
5. I don't see this ever happening in C also
6. agreed, will be included in C2's macro system partly also.
7. UTF-8 discussion are on the forum, but not really pressing in the current phase.
This goes (I think) for 1, 3
2. TBD
4. C2 has an extensible attribute system already, so this is pretty much solved
5. I don't see this ever happening in C also
6. agreed, will be included in C2's macro system partly also.
7. UTF-8 discussion are on the forum, but not really pressing in the current phase.
15
General Discussion / Re: Overwriting fields in init struct.
« on: December 16, 2018, 10:51:20 AM »
I'll have to think about this.. I've put in on the Wiki Roadmap so we don't forget.
I did some searching in the kernel code, but couldn't find actual usages. I've done quite some kernel work also
and never actually saw this in use.
I did some searching in the kernel code, but couldn't find actual usages. I've done quite some kernel work also
and never actually saw this in use.