76
Implementation Details / Re: Decoupling DiagnosticsEngine
« on: November 07, 2018, 10:35:50 AM »
I would at least like to keep the option open to do parsing + analysis in multiple-threads.
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.
78
Implementation Details / Re: Parsing numbers
« on: November 07, 2018, 10:34:38 AM »
Constants are one area where C2 places more focus on compile-time than C. So
Will just result in an error. This sounds harsh at first, but there is never a reason to write code like this.
This analysis is already implemented (for integers) and can be seen in the unit tests as well. C2 is a
strongly typed language, so the value should match the type instead of deriving the type from the value.
I think binary notation is already present as well (was already in Clang base).
I'll put this on the lower priority stack..
Code: [Select]
u8 a = 300;Will just result in an error. This sounds harsh at first, but there is never a reason to write code like this.
This analysis is already implemented (for integers) and can be seen in the unit tests as well. C2 is a
strongly typed language, so the value should match the type instead of deriving the type from the value.
I think binary notation is already present as well (was already in Clang base).
I'll put this on the lower priority stack..
79
Implementation Details / Re: Keywords keywords keywords
« on: November 07, 2018, 10:28:32 AM »
Indeed, I've updated the documentation
elemsof() is implemented as a macro is C, but just the same as sizeof() in C2 (since this macro is implemented in so many programs).
There are just a few of these specials, so I don't think every C2 programmer will know them, just like sizeof() in C. Instead of a keyword
we could place them inside the c2 module, so you can access them with c2.sizeof() or sizeof() (if you import c2 local).
elemsof() is implemented as a macro is C, but just the same as sizeof() in C2 (since this macro is implemented in so many programs).
There are just a few of these specials, so I don't think every C2 programmer will know them, just like sizeof() in C. Instead of a keyword
we could place them inside the c2 module, so you can access them with c2.sizeof() or sizeof() (if you import c2 local).
80
General Discussion / Re: Overview of syntax
« on: November 07, 2018, 09:49:36 AM »
In the early stages, I did a big test with trying to remove the semicolon (
after each statement. That really
made the code look so much easier to read. I managed to get the syntax/parser to do this, except for a few
corner cases, with the if statement if I remember correctly. I used the same way as Go, just let the
Lexer insert semi-colons at certain points.
after each statement. That reallymade the code look so much easier to read. I managed to get the syntax/parser to do this, except for a few
corner cases, with the if statement if I remember correctly. I used the same way as Go, just let the
Lexer insert semi-colons at certain points.
81
General Discussion / Re: Overview of syntax
« on: October 31, 2018, 09:39:16 AM »
I must say that I do find the Ruby version quite readable. This surprised me. Maybe the end keyword is easier on the eyes then the }.
If never like the Allman style where half your screen seems filled with lines only containing a single character ({ }).
Changing the curly brackets to begin/end keywords, does change the language a lot at the surface (what people view first)...
If never like the Allman style where half your screen seems filled with lines only containing a single character ({ }).
Changing the curly brackets to begin/end keywords, does change the language a lot at the surface (what people view first)...
82
General Discussion / Re: State of progress?
« on: October 31, 2018, 09:33:21 AM »
Lexers are always fun to write (I think). The Clang Lexer can do lookahead() a few tokens and the C2Parser does rely
on that feature. Otherwise I think it's important to put all TokenKinds in an enum, so the compiler can warn if you miss
some in a switch statement.
For preprocessing, I think we (for now) need at least '#if 0/1 .. #endif' and maybe a basic '#ifdef FEATURE1 .. #endif'.
Otherwise we would need to think about another way to offer those features..
on that feature. Otherwise I think it's important to put all TokenKinds in an enum, so the compiler can warn if you miss
some in a switch statement.
For preprocessing, I think we (for now) need at least '#if 0/1 .. #endif' and maybe a basic '#ifdef FEATURE1 .. #endif'.
Otherwise we would need to think about another way to offer those features..
83
General Discussion / Re: Contribute / get into the code
« on: October 31, 2018, 09:29:25 AM »
You should keep the master branch of your archived synced with the official repository. For a feature, just
branch off and push it to your server. Ideally different pull requests are indepedent, so the order of merging
doesn't really matter. If a changes consists of several pull requests than it becomes a bit more hassle.
Solving merge issues is never fun, so avoiding them is better. So if you plan to do a big change, discussing
it upfront might save time.
branch off and push it to your server. Ideally different pull requests are indepedent, so the order of merging
doesn't really matter. If a changes consists of several pull requests than it becomes a bit more hassle.
Solving merge issues is never fun, so avoiding them is better
. So if you plan to do a big change, discussingit upfront might save time.
84
General Discussion / Re: Overview of syntax
« on: October 28, 2018, 09:44:47 AM »
Having keywords written out (like begin or end) always reminds me of my very early Basic days.
Especially fully capitalized versions (BEGIN .. END) really scream 1980's.
Especially fully capitalized versions (BEGIN .. END) really scream 1980's.
85
General Discussion / Re: State of progress?
« on: October 28, 2018, 09:41:31 AM »
Dropping the Clang lexer would also effectively remove the more complex #ifdef feature support (unless the
new lexer is also quite complex). But it would make the lexer itself somewhat faster I think. Clang's lexer needs
to support multiple languages and tokensets. The C2 parser would not. Additionally I've noticed that Clang's
Lexer seems to have slowed down in Clang 7. I haven't looked into it in more detail, but measurements are
definitely slower. I've written plenty of lexers, so I estimate it will take around 2 days to write a C2 replacement..
new lexer is also quite complex). But it would make the lexer itself somewhat faster I think. Clang's lexer needs
to support multiple languages and tokensets. The C2 parser would not. Additionally I've noticed that Clang's
Lexer seems to have slowed down in Clang 7. I haven't looked into it in more detail, but measurements are
definitely slower. I've written plenty of lexers, so I estimate it will take around 2 days to write a C2 replacement..
86
General Discussion / Re: Contribute / get into the code
« on: October 28, 2018, 09:37:11 AM »
So the command would be 'homebrew cmake' ?
87
General Discussion / Re: Broken link to the forum
« on: October 28, 2018, 09:34:22 AM »
I also get that recently, but I don't understand why. The HTML just says c2lang.org/forum, but my browser turns that into
'http://www.c2lang.org/forum/index.php?PHPSESSID=thsgtf5corng3c6nun2cm7eo40;wwwRedirect' ...
'http://www.c2lang.org/forum/index.php?PHPSESSID=thsgtf5corng3c6nun2cm7eo40;wwwRedirect' ...
88
Ideas / Re: Restricted pointers (and the analogue with threads)
« on: October 26, 2018, 03:43:50 PM »
Yes the hard part is detecting whenever the strict aliasing rules are broken..
89
General Discussion / Re: How should I set up the project for dev?
« on: October 26, 2018, 10:00:04 AM »
Nice! It's always frustrating if this part is hard. Getting into the change-build-test loop should be easy, but since we're based on LLVM (a complex project) it will always require some hassle
90
General Discussion / Re: Contribute / get into the code
« on: October 26, 2018, 09:58:10 AM »
Maybe you can look at the operator precedence? That is C2-only (no LLVM/Clang).
Changing the precedence order from C does bring one nasty bit: C-code generation should take
this into account when generating C (ie add some extra parentheses)
Step1 would be changing Parser and looking at the resulting AST (c2c -a1). This step can be varified on its own)
Step 2 would be changing the C generation. Because the changes are not that big, maybe we can get away
by always adding parentheses around (new) order 4 and 5 (that were boosted up).
Changing the precedence order from C does bring one nasty bit: C-code generation should take
this into account when generating C (ie add some extra parentheses)
Step1 would be changing Parser and looking at the resulting AST (c2c -a1). This step can be varified on its own)
Step 2 would be changing the C generation. Because the changes are not that big, maybe we can get away
by always adding parentheses around (new) order 4 and 5 (that were boosted up).