Messages

196

Implementation Details / Re: Why do we need Clang and LLVM?

« on: October 25, 2018, 11:51:44 PM »

For fun I wrapped all the calls of DiagnosticsEngine aside from the config in C2Builder::build.

The only calls outside of C2Builder would be starting a new file, Report, hasErrorOccurred + DiagnosticErrorTrap.

However, it's also passed into the Preprocessor and the SourceManager. From what I understand they are actually both not required in the sense that C2 doesn't have a complex library search, nor any preprocessing (or at least trivial such processing)

If we consider dog fooding C2 eventually, then this is a task that has to be done sooner or later. A self-hosting c2c might rely on LLVM IR and optimization, but not Clang for frontend (unless it's actually used for C parsing – which it isn't)

197

General Discussion / Mail of posts / this BBS

« on: October 25, 2018, 02:53:21 PM »

Somewhat unfortunate this forum does not seem to allow (or have enabled?) mail of new posts. I'm also a bit spoiled by modern forums that use markdown.

Can some improvement be made perhaps...? NodeBB is fairly straightforward to set up but the ideal would be some hosted forum that would be free for an open source project.

198

Ideas / C11's _Generic

« on: October 25, 2018, 11:19:44 AM »

I suggest support for a version of _Generic.

The functionality is simple:

Code: [Select]

#define to_num(x) _Generic((x), int:0, char:1, long:2, default:3)

int i = 2;
long x = 100;   

printf("%d / %d / %d\n", to_num(i), to_num(x), to_num(&x));

This prints "1 / 2 / 3"

Basically _Generic acts like a switch:

switch ("type of x") {
   case "int": 0
   case "char": 1
   case "long": 2
   default: 3
}

Because the non-taken paths aren't evaluated, this rather powerful in expressing "overloaded" math functions (to take an example)

This could be used to implement overloads for operators as well.

199

Ideas / Fix C operator precedence rules

« on: October 25, 2018, 12:49:12 AM »

C's precedence rules are not in fact, there are cases where they can be considered really bad.

These are the current rules in C2:

1. (),.*, ->*
2. !,~
3. *, /, %
4. -, +
5. <<, >>
6. >=, <=, >, <
7. ==, !=
8. &
9. ^
10. |
11. &&
12. ||
13. ?
14. =, *=, /=, %=, +=, -=, <<=, >>=, &=, ^=, |=
15. ,

I would suggest a flatter and more reasonable precedence order:

1. (),.*, ->*
2. !,~
3. *, /, %
4. <<, >>
5. &, ^, |
6. -, +
7. ==, !=, >=, <=, >, <
8. &&, ||
9. ?
10. =, *=, /=, %=, +=, -=, <<=, >>=, &=, ^=, |=
11 ,

This means that we cant write something like a || b && c || d && e and expect anything other left-to-right evaluation. In my opinion the operator precedence rules here are allowing hard-to-read code.

We're also removing the common pitfall of a << 3 + b << 2, it's no longer evaluated to (a << (3 + b)) << 2 but instead (a << 3) + (b << 2).

Flattening the bitwise operators follows the same rationale as for logical and/or. An expression such as a | b ^ c & d which has the evaluation of (a | (b ^ (c & d))) might be unexpected for many.

Moving the bitwise operators before comparisons finally allows us for the intuitive code of a & b == 0 instead of the currently required (a & b) == 0. I would say that the standard evaluation of a & (b == 0) is virtually never intended.

We'd be removing three levels of precedence and creating code that's easier to understand and remember. (And the bitwise operator precedence of C should be considered a bug more than anything.)

Other languages with similar precedence rules: Julia, Nim, Zig, Python.

200

Implementation Details / Re: Why do we need Clang and LLVM?

« on: October 24, 2018, 11:06:00 PM »

One thing would be to localize the DiagnosticsEngine to part of the code and call it through a wrapper. That way it's straightforward to replace it.

Can you explain what you use Clang's preprocessing for? Are we parsing any of standard C so that we need it as input?

201

General Discussion / Contribute / get into the code

« on: October 24, 2018, 10:05:33 PM »

If I'd like to contribute to the code, is there some area where one reasonably could do some minor cleanup / additions without having to understand the entire code and it's useful enough that you'd accept a pull req once it's done?

I noticed that there were two pull requests that wasn't accepted, if I spend some time doing additions I'd like to make sure it's somewhere helpful. So where could one start?

(BTW, the code is a bit inconsistent in its formatting, consider a style guide for the source)

202

Ideas / Re: Preprocessor and Macros

« on: October 24, 2018, 10:01:04 PM »

You forget a big one: generics.

Look at pretty much any hash map implementation in C.

I haven't made a [generics] proposal for C2 yet, because I'm still trying to figure how to do this the best possible way.

It's interesting to look at the draft for Go2, since it wrestles with the same issue.

My personal opinion is that too much generics makes languages very messy and hard to read. They encourage solutions that layers generics upon generics until you have a mess trying to read it.

It is not strange to get something like: std::shared_ptr<std::unordered_map<std::string, std::function<void(const std::shared_ptr<Foo> &)>>>

This almost requires you to use type inference where possible, which makes code reading harder.

Obviously for C++ we could have done something like:

Code: [Select]

using FooPtr = std::shared_ptr<Foo>;
using FooCall = std::function<void(const FooPtr &)>;
using FooCallMap = std::unordered_map<std::string, FooCall>;
using FooCallMapPtr = std::shared_ptr<FooCallMap>;

But then where the original (long) definition was very verbose, you still knew exactly how to access things in it. Not so with our new alias, which means you probably will have to go back and look up those definitions, which interrupts code reading.

How to create generics that remain readable and limited is the question...

203

Ideas / Re: Restricted pointers (and the analogue with threads)

« on: October 24, 2018, 09:49:38 PM »

Several languages, including Fortran, uses the same behaviour as "restrict" by default.

As memory latency increases, the aliasing issue becomes more and more important. When C was conceived it was wholly unnecessary. Today it's becoming something very important and gives you the ability to be "faster than C".

Since restrict wasn't available until C99, it's not surprising that you haven't used it much. I haven't done as much C programming as you, but I didn't really notice it until I started reading up on heavily optimized game engines.

204

Ideas / Re: Restricted pointers (and the analogue with threads)

« on: October 24, 2018, 05:10:15 PM »

It's fairly straightforward to try out different things using https://godbolt.org (e.g. https://godbolt.org/z/GpJ0UC)

There has been some benchmarking on PowerPC that I found, giving up to 30% faster code. However, this means the language still needs to be smart about it. Look at the problems mentioned here: https://blog.regehr.org/archives/1307

Aside from the situation of foo(&l, &l) where the user deliberately creates an aliasing issue, they need to be mitigated.

205

Implementation Details / Re: Why do we need Clang and LLVM?

« on: October 24, 2018, 04:46:30 PM »

My experience is that lexing is actually the most straightforward part of writing a parser?

206

General Discussion / Re: How should I set up the project for dev?

« on: October 24, 2018, 04:43:58 PM »

I'm going to do my best but it would have been nice if C2 was possible to work on independent of LLVM/Clang.

207

General Discussion / Re: State of progress?

« on: October 24, 2018, 04:29:48 PM »

Why is the lexer and preprocessor + diagnostics engine needed from Clang? Can't C2 do that on its own?

208

Implementation Details / Re: Why do we need Clang and LLVM?

« on: October 24, 2018, 12:11:36 PM »

On my older laptop LLVM compilation takes about 12 hours. When trying the c2-docker version, it died halfway through due to lack of virtual memory. After running a few hours. LLVM is a resource hog.

209

Ideas / Expression blocks

« on: October 22, 2018, 09:41:37 PM »

GNU has an extremely useful extension in expression blocks using ({ ... })

The suggestion I have is to allow C2 to implement those as a standard. There are a few ways to pick the syntax (that I can think of):

• Retain the GNU format
• Let any block ending with an *unterminated* expression return the value of that statement e.g. { foo = bar(); foo } is an expression returning the value of foo, while { foo = bar(); foo(); } is a normal statement.
• Use normal ( ) but allow statments. e.g. ( foo = bar(); foo )
• Use something similar to the GNU format but write explicit return, e.g. [{ foo = bar(); return foo() }] it would still be equivalent to the code above.
  

Also note that the value-returning macro becomes easy to express for the versions with explicit return. It's simply a macro wrapped in an expression block.

210

Ideas / In-loop definitions

« on: October 22, 2018, 09:31:55 PM »

This is a features I was considering for my own language.

Basically we recognize that in cases like this, we unnecessarily leak information to the outer scope:

Code: [Select]

int result;
if ((result = do_something()) != ERR_RESULT) {
  do_something_with_result(result);
}

Object *obj;
while ((obj = next_object()) != NULL) {
   ... do stuff ...
}

We could extend the syntax with an declaration:

Code: [Select]

if (int result; (result = do_something()) != ERR_RESULT) {
  do_something_with_result(result);
}

while (Object obj; (obj = next_object()) != NULL) {
   ... do stuff ...
}

switch (int result; (result = value())) {
  ...
}
 

There are a few more possibilities for separator:

Code: [Select]

while (Object obj : (obj = next_object()) != NULL) { 
   ...
}

while (Object obj, (obj = next_object()) != NULL) { 
   ...
}

while (Object obj | (obj = next_object()) != NULL) { 
   ...
}

while (Object obj :: (obj = next_object()) != NULL) { 
   ...
}

Obviously this is simply about extending what we have in "for" to a more general case.