Messages

106

General Discussion / Re: State of progress?

« on: October 24, 2018, 02:33:12 PM »

The documentation describes this a bit in http://c2lang.org/site/development/internals/. It comes down to this:

Clang:
- Tokenizer (includes preprocessor)
- Diagnostics Engine
- Filemanagement (needed for Tokenizer + Diagnostics)

LLVM:
- Utils used by Clang components above.

It would have been fantastic to use the AST from Clang, but the AST is really tuned to single pass parsing+analysis, so really didn't fit..

107

Ideas / Re: Add defer

« on: October 22, 2018, 12:36:49 PM »

How would you define the syntax and semantics of something like that?

108

Ideas / Re: Macros again

« on: October 22, 2018, 12:25:09 PM »

In the foo2 example, do you mean that variable d is used in the macro, but not passed as an argument?
I think specifying all variables that are used from the 'calling' scope is a good thing. But maybe they need to
be separate from arguments?

Rust uses an exclamation mark (!) to indicate a macro(-function). I think it's better to make the use explicit also.
Currently the @ sign is used for attributes (@ttributes . I'll have to see if this use confuses the parser. In the
specifying part, we dont need the @, since the macro keyword makes it unambigous.

I understand what you try to do with the return in the macro. It makes the macro more readable.  It might be hard(er)
to implement.

body: that would solve a lot of current issues in macros that wrap around another piece of code. They always need a
pre and post macro. This would be nice, since you only have to write loop-code once. Trying to do reduce the same loop
code to 1 piece in C requires using a function pointer construction. The way functional languages solve this is much nicer,
so using that way would be very nice. I don't think this can be done without having functions an first-class citizens..

109

Ideas / Re: char / int / i8 / i32 and so on

« on: October 22, 2018, 12:13:09 PM »

The short/long names do make the exact size ambiguous, especially since C2 is a close relative to C. So if you're programming in C2 and
using C libraries, an *int* in the c2-part of your code is different than an *int* in the c-part of the code. I don't think that's any good..

110

Ideas / Re: Preprocessor and Macros

« on: October 22, 2018, 12:10:50 PM »

The Big problem with a meta language is that it becomes very hard for tooling. Even after almost 50 years of C, C-tooling still has a very hard time
to do proper analysis. For a very large part, this is because of the preprocessor magic that can happen. Because of this, I would try to avoid a meta
language. This was also the reason why fragment-based programming (hmm the name was different but it eludes me for now) failed; it was just a mess
to read.

I still amazes me that a C like language seems to need a macro system, while many other languages out there just do fine without.
Also if you think about it, an inline function is superior in almost every sense to a macro, except that it cannot modify variables in the calling scope.

111

Ideas / Re: Readability of keywords "uint32", "float64" etc

« on: October 22, 2018, 11:44:12 AM »

Currently in C if you want to write portable code, you often avoid the use of int, since since changes
the behaviour between platforms. Other recent languages (like Rust) do still have a general integere type
(isize/usize in Rust). I'm not sure if there is a real performance penalty (and how big) of using a 32bit
integer on a 64bit system. If there is a big one, we should introduce a generic 'int' like type.

112

Ideas / Re: Cumbersome of struct-functions

« on: October 18, 2018, 08:56:12 PM »

What did you study? Arts? A + is simply a +.

113

Ideas / Re: Consider native string & map

« on: October 18, 2018, 08:44:05 PM »

I read your blogs. I had to laugh at your 'To OO or not' post, because so many examples were so familiar. I think a lot of develops
feel that way about OO these days. Also if you post something on a site like Reddit, my experience is that it quickly ends up in some
flame war with somebody calling you 'a complete moron'. Well done ignoring them 

I think array, map and string handling are important in a system level programming language. Also functions as first class citizens with
proper closures etc would make a lot of code better. Unfortunately all these features cannot be well implemented without some form
of garbage collection (as you can see in a lot of discussions on Go development). Since C2 does not have GC it will be fairly limited in
changing the C behaviour. Or do you perhaps have an idea on how to do this?

114

General Discussion / Re: State of progress?

« on: October 18, 2018, 08:38:15 PM »

Since rebasing on Clang 7.0 it has gone down a bit. parsing + analysing is now at roughly 1.2 million lines of code per second
on my laptop. The backend that does code-generation is also quite fast (roughly takes twice the time of parse+analyse). But the
C-generation backend will be replaced by an LLVM IR code generation backend at some point.

115

Ideas / Re: Support of Unicode ?

« on: September 28, 2018, 03:48:59 PM »

Lol.. The basic scenario of the actual encoding is indeed a standard. But how to integrate in a language is another thing.
A programming language is a bag of choices; make it easy for some, but harder for other developers; force something on
everyone or allow multiple solutions; there's never an actual best solution for everyone. With UTF (and other encodings)
the most important thing I think is how it interacts with the common C string (ie const char*). So how do you go from one to
the other and so on. Also how do you define string constants that are UTF-8? maybe like u"My UTF-8 String" (for example)

116

Ideas / Re: Support of Unicode ?

« on: September 24, 2018, 12:34:08 PM »

Support of Unicode is simply not in yet. Ideally it would unify all the different approaches used in C code.
But the discussion on what to include (eg. only UTF-8, etc) is a tricky one that has no neat solution i fear.
UTF is not in yet, because C2's goal domain is embedded drivers/kernels/operating systems, etc. There UTF
is not really important as in a generic systems language.

But I haven't really looked into a proper UTF solution yet. On the web, UTF-8 is definately dominating.

117

Ideas / Re: Why "recipe.txt" ? :)

« on: September 24, 2018, 12:30:01 PM »

Haha my association with recipe was cooking. Like a cooking recipe to make cake. It describes the steps
needed to make something. Associating a thing with cake is of course better than associating with a docter .

118

Ideas / Re: Cumbersome of struct-functions

« on: September 24, 2018, 12:28:14 PM »

Yes, good one. The choice is between 2 sides:

• C-style: all arguments are explicitt.
• C++ style: the 'this' argument is implicit.

Both have advantages:
C: allows developer to name 'this' variable
C: does not beak C model of implicit stuff
C++: less typing

In the end, the not breaking of the C model was the most important one..

119

Ideas / Re: Keyword "local" (variable) - sense fog

« on: September 24, 2018, 12:25:04 PM »

The keyword local is the C2 version of C's static for local variables. I did not want to use the
keyword global, because that means something else. So C2's local variables have a function scope,
but do persist between function calls (so identical to C's static local variables). I agree that local does not
really convey that meaning, but I couldn't think of a better alternative..

120

Ideas / Re: Naming restrictions

« on: September 24, 2018, 12:22:29 PM »

I can easily image developers initially being irritated by something like this. It takes away some
of the freedom. However all C2 code then becomes a lot more similar and thus more readable. This is
a huge advantage. For the same reasion the Go language formats all libraries with the same required
style. Initially developers hate it, but in the end, code is So much more readable (and reusable).