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.

Messages - bas

Pages: [1] 2 3 ... 14
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.

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)..

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.

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.

Ideas / Re: Error handling [proposal]
« on: December 07, 2018, 10:40:23 AM »
The main issue I have with this approach is:
- what is the actual problem it's trying to solve?
- it makes the syntax a Lot more complex (and unreadable).
- it only helps if the error system is used universally used (like in Go). In C that will never be the case

I think the power of C(2) is it's simplicity. Code can be very readable, because once you understand
a few simple patterns, it's all the same. Like:

Code: [Select]
int fd = open(..);
if (fd == -1) {
   // error

So in C the pattern is to (for example) use signed values to be able to use special values (eg -1) to indicate
an error.

A more extended pattern is to always return a Result Enum, where Result_Ok is the happy flow. Other output
variables then need to be passed back via out params.

Just sticking to these patterns is so very powerfull, since all C programmers understand them from day 1.

General Discussion / Re: Overwriting fields in init struct.
« on: December 07, 2018, 10:26:35 AM »
I think this is again a situation that does make the language a bit more complex, while not adding much.
Let's really keep the language as simple as possible. That way, (extra) tooling could add warnings for
unset functions more easily..

Implementation Details / Re: LLVM/C gen
« on: December 02, 2018, 12:22:59 PM »
Can we just start without and add it when we need it?

Ideas / Re: Switch proposal
« on: December 02, 2018, 12:20:26 PM »
Ahh missed that sorry

I think the common case for a switch is that every case breaks. Fallthrough is a much rarer case. So I think making
all cases break by default is an improvement indeed. Syntax wise, this means the following:
- keyword break is allowed in a case.
- keyword fallthrough is used to indicate that the case will fallthrough (there must be a next case).

I'll put in on the roadmap

Ideas / Re: Support of Unicode ?
« on: December 02, 2018, 12:15:51 PM »
I'm not agaist Unicode in C2, but i just want in there as an optional part that you can use or not. So a basic string will Not be Unicode.

Ideas / Re: Typeinfo at runtime
« on: December 02, 2018, 12:11:32 PM »
For the macro system we will need something like typeof(), eg for swap() (pseudo code)

Code: [Select]
macro swap(x, y) {
   typeof(x) tmp = x;
   x = y;
   y = tmp;

I don't really like the vtype as it makes the language more complex again..

Implementation Details / Re: CTC (partial, full, none)
« on: December 02, 2018, 11:56:34 AM »
CTC = Compile Time Constant.
Code: [Select]
const i32 a = 32; // CTC full
const i32 b = a; // CTC full

// expr's:
i32 c = 10; // NOTE: c not const
3 + a; // CTC full
c; // CTC none
3 + c; // CTC partial (some sub-expr is FULL)

CTC full expressions are checked for value by the analyser (no casts needed then)

Also CTC full expressions can be evaluated at compile time and just added to the code as that value.

Ideas / Re: Switch proposal
« on: November 30, 2018, 05:03:55 PM »
Fallthrough is always automatic, except when you use break. So there is never an automatic break.
The compiler gives gives a warning/error if you don't use break/fallthrough in cases there is a code..

Ideas / Re: Support of Unicode ?
« on: November 30, 2018, 01:42:52 PM »
In all my years of programming, I've only had to do I18n twice. Both were C++ projects. In C never. In C a basic string is just a char* with 8-bit characters. That
works for 99.9% of the cases. What would be nice if we could add special Strings as an optional feature. If not used, no overhead etc.

General Discussion / Re: Overwriting fields in init struct.
« on: November 30, 2018, 01:19:43 PM »
Why would this not be an error?

General Discussion / Re: C2x
« on: November 30, 2018, 11:58:49 AM »
I always find it funny that most language seem to do well without all these big formal specification documents.

If you have concrete proposals, just make them, but there is enough work already to make this a priority..

Pages: [1] 2 3 ... 14