51
deleted
Recent Posts
52
Ideas / Re: Syntax of const pointers
« Last post by lerno on January 02, 2019, 02:45:37 AM »I've thought about this some more and I'm actually leaning towards 5 now, since that would make things easier when reading.
Do we want to write:
Maybe it's just me, but in the simple case then the prefix keyword really rules.
And for the complex ones, maybe () isn't such a bad idea:
// 4
// 5
// 1
Note that it looks very different visually depending on where you put the "*". (1) shines when the star is put next to the type.
One more thing to consider should be the parsing. For example: an expression starting with '(' can be deducted to always be an expression on C, but with ( ) in the type names, that would not be obvious.
Do we want to write:
Code: [Select]
int volatile x = 10;
Foo const foo = { ... };
int * const y = &x;
// or
volatile int x = 10;
const Foo foo = { ... };
int const* y = &x;
Maybe it's just me, but in the simple case then the prefix keyword really rules.
And for the complex ones, maybe () isn't such a bad idea:
// 4
Code: [Select]
int* volatile x = 10; // volatile pointer to int
Foo* const foo = { ... }; // const pointer to Foo
Foo const* foo = { ... }; // pointer to const Foo
int* const y = &x; // const pointer to int
int const* y = &x; // pointer to const int
// 5
Code: [Select]
int volatile* x = 10; // volatile pointer to int
Foo const* foo = { ... }; // const pointer to Foo
const Foo* foo = { ... }; // pointer to const Foo
int const* y = &x; // const pointer to int
const int* y = &x; // pointer to const int
// 1
Code: [Select]
volatile (int*) x = 10; // volatile pointer to int
const (Foo*) foo = { ... }; // const pointer to Foo
(const Foo)* foo = { ... }; // pointer to const Foo
const (int*) y = &x; // const pointer to int
(const int)* y = &x; // pointer to const int
Note that it looks very different visually depending on where you put the "*". (1) shines when the star is put next to the type.
One more thing to consider should be the parsing. For example: an expression starting with '(' can be deducted to always be an expression on C, but with ( ) in the type names, that would not be obvious.
53
Ideas / A brief and simple generics proposal
« Last post by lerno on December 28, 2018, 08:04:34 PM »Since we want semantic macros we need to consider the usecase where C uses macros to create generic code. Here is a sketch of how that could be implemented.
1. A generic implementation is implemented in a generics module:
To use this generic code, simply import:
Thanks to the namespacing in C2, we can don't actually need to create an alias if we want to. The module is all we need in order to make this work.
One issue
There is only one issue here. This solution has pretty much the same issue as C++ templates – lack of good error messages.
A solution would therefore be to set up a clause with contracts the types must pass. This is similar to the solution proposed in C++ / Go2:
A generic is not completely error checked until it is instantiated, with the contract however, the expressions are FIRST validated, and reported as errors.
This proposal is minimal, does not clutter the language with type arguments (i.e. no Foo<f32> etc), prevents misuse and requires very little extra syntax and complexity.
1. A generic implementation is implemented in a generics module:
Code: [Select]
module vector (A, B, C); // A, B, C are generic parameters.
type Foo struct {
A a;
}
func C test(B b, Foo *foo) {
return a + b;
}
To use this generic code, simply import:
Code: [Select]
import vector(f64, f32, i32) as generic_tests;
func f64 test()
{
generic_tests.Foo foo = { 2.0 };
return generic_tests.test(3.0, foo);
Thanks to the namespacing in C2, we can don't actually need to create an alias if we want to. The module is all we need in order to make this work.
One issue
There is only one issue here. This solution has pretty much the same issue as C++ templates – lack of good error messages.
A solution would therefore be to set up a clause with contracts the types must pass. This is similar to the solution proposed in C++ / Go2:
Code: [Select]
module vector (A, B, C);
contract(A a, B b, C c) {
a + b; // Only expressions allowed
c == a + b; // Only expressions allowed
}
... code ...
A generic is not completely error checked until it is instantiated, with the contract however, the expressions are FIRST validated, and reported as errors.
Code: [Select]
import vector(struct Bar, f32, i32) as gen_test;
// This would give the error
---> Illegal arguments for generic module vector, breaks contract 'struct Bar' == 'f32' + 'i32'
This proposal is minimal, does not clutter the language with type arguments (i.e. no Foo<f32> etc), prevents misuse and requires very little extra syntax and complexity.
54
Implementation Details / Re: Implementation based on Clang or...?
« Last post by lerno on December 21, 2018, 11:17:22 AM »Well I was not talking about "at the moment" but toward the future of a possible self-hosted C2.
55
Implementation Details / Re: Implementation based on Clang or...?
« Last post by bas 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.
56
Implementation Details / Implementation based on Clang or...?
« Last post by lerno on December 20, 2018, 08:25:20 PM »There are two lightweight C-based compilers of C, TCC and recently 9cc.
One idea would be to implement the C2 compiler on top of either of those instead. TCC is known for it's very fast compilations speed. The fact that both are written in C allows us to potentially implement them in C2 instead.
Possibilities
1. Use C2-Clang/LLVM to compile a mod of 9cc/TCC rewritten in C2
2. Write C2-9cc/TCC which then is piece by piece replaced by C2 implementation.
Obviously this is something for the future and should not detract from the current work on C2-Clang/LLVM.
One idea would be to implement the C2 compiler on top of either of those instead. TCC is known for it's very fast compilations speed. The fact that both are written in C allows us to potentially implement them in C2 instead.
Possibilities
1. Use C2-Clang/LLVM to compile a mod of 9cc/TCC rewritten in C2
2. Write C2-9cc/TCC which then is piece by piece replaced by C2 implementation.
Obviously this is something for the future and should not detract from the current work on C2-Clang/LLVM.
57
Ideas / Re: Extended switch statement
« Last post by lerno on December 17, 2018, 08:10:29 PM »First, a minimal change would be to simply allow ranges in switch statements, such as:
Secondly, I think it's a more constructive way to work by actually discussing how a proposal should look if adapted to C, rather than to dismiss it early because it doesn't feel like C.
I know it is tempting to dismiss this altogether, but if we have a proposal that looks like suitable for C, it's easier to both determine whether it is an evolution or not (i.e. sufficiently small change) and if worthwhile AND to have something to refer to later on when similar proposals inevitably show up.
Finally, its a good exercise "translating" the proposal to a useful form. I would argue the same for the error proposal: first see if it can be molded into something less ugly then decide whether it should be dismissed or not.
The limited switch IS a C deficiency, just like the limited error handling, header files, preprocessor macros etc. In order to see if there's an evolutionary way out of it, an evolutionary proposal should be made and I'm submitting incomplete proposals exactly so that it's more inviting to come and offer counterproposals and changes. The incompleteness is completely deliberate.
So again, I would like to discuss how it should look, then decide if that is useful enough to be considered for inclusion. Not dismissed in its incomplete state.
Code: [Select]
switch (x) {
case 1 .. 10:
...
case 11 .. 100:
...
}
Secondly, I think it's a more constructive way to work by actually discussing how a proposal should look if adapted to C, rather than to dismiss it early because it doesn't feel like C.
I know it is tempting to dismiss this altogether, but if we have a proposal that looks like suitable for C, it's easier to both determine whether it is an evolution or not (i.e. sufficiently small change) and if worthwhile AND to have something to refer to later on when similar proposals inevitably show up.
Finally, its a good exercise "translating" the proposal to a useful form. I would argue the same for the error proposal: first see if it can be molded into something less ugly then decide whether it should be dismissed or not.
The limited switch IS a C deficiency, just like the limited error handling, header files, preprocessor macros etc. In order to see if there's an evolutionary way out of it, an evolutionary proposal should be made and I'm submitting incomplete proposals exactly so that it's more inviting to come and offer counterproposals and changes. The incompleteness is completely deliberate.
So again, I would like to discuss how it should look, then decide if that is useful enough to be considered for inclusion. Not dismissed in its incomplete state.
58
Ideas / Re: Extended switch statement
« Last post by bas 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)..
59
General Discussion / Re: Overwriting fields in init struct.
« Last post by lerno on December 16, 2018, 07:28:51 PM »Weren't there any links in that article?
60
Ideas / Extended switch statement
« Last post by lerno on December 16, 2018, 04:08:21 PM »Something I’ve been considering is an extended switch statement that is a structured if-else. So consider something like this:
So it’s a glorified if-else actually. It has better readability over if-else though.
I’m thinking about some other things:
Has anyone given this any thought?
I think C2 should certainly /evolve/ switch-case a bit. But how far and if it should be a completely new statement type or not - that’s something I’m unsure of.
The main two use-cases for me to replace (1) long if-else chains (2) switch-case where we really want ranges instead single numbers and often need to use if-else instead of switch.
Code: [Select]
switch (x) {
case x > 200: return 0;
case x < 2:
small_x_warning();
break;
case 0:
....
case x > y && a < 1:
...
}
So it’s a glorified if-else actually. It has better readability over if-else though.
I’m thinking about some other things:
- In the code above x is explicit i conditionals, but that does not make sense for switch (foo()) {...}. However using ”broken” expressions is harder to parse and sometimes impossible. For simple cases we can do ”case >100:” but what about the case of x > 10 && x < 20? It can’t be expressed that way.
- A solution to the above is to allow the switch to introduce switch scoped variables: switch (int i = foo()) { ... }. Multiple variables could be permitted: switch (int i = foo(); int j = bar()) {}
- If using (2) we need to decide whether additional variables could skip initialization if they aren’t used in the case.
- I think there is a sweet spot between the plain switch and full pattern matching, especially when dealing with ranges and matching strings.
Has anyone given this any thought?
I think C2 should certainly /evolve/ switch-case a bit. But how far and if it should be a completely new statement type or not - that’s something I’m unsure of.
The main two use-cases for me to replace (1) long if-else chains (2) switch-case where we really want ranges instead single numbers and often need to use if-else instead of switch.