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

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

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

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

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

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

7
Ideas / Re: Function inside function
« on: September 24, 2018, 12:20:16 PM »
Features like this are not used very often in C and do make a language more complex than needed. So it was removed.

8
Ideas / Re: Keyword "func" - redundancy?
« on: September 24, 2018, 12:19:34 PM »
If the func keyword was completely redundant it would have been removed indeed. The keyword does make it a lot
easier on the parser. For a human it probably looks redundant. I was initially thinking about 3 keywords for globals:
type, func and (var?). That way it's completely obvious. Many new languages use something like this because making
stuff utterly obvious is usually a good thing. I did not add the (var?) keyword, because I felt that all variables should then
use it; so also local variables. This make the function bodies less easy to read, so now types and functions have a
keyword and variables don't.

9
Ideas / Re: Readability of keywords "uint32", "float64" etc
« on: September 24, 2018, 12:15:51 PM »
C2 started out with the short versions (u8, etc), then returned to versions. After a while, this didn't feel right, so it was changed back to the short
versions. In the end, it takes a bit of getting used to, but it is easier on the eyes. This is the same as Rust btw.

Encapsulation at compile time level does not exist anymore at all, since the C2 compiler has a different unit of compilation. Having no
headers avoids a lot of issues and increasing the unit of compilation also allows some pretty nice features.

10
General Discussion / Re: State of progress?
« on: July 15, 2018, 09:24:39 PM »
C2 is definitely not going as fast as I would like, but it's definitely not dead either. Work and family life does
take a big toll on available time. Luckily it's already quite usable, so people (me included) can play around
with it to get a feel and evaluate it for parts that could be improved.

Parts where C2 still needs developers:
- LLVM IR  generation
- inline assembly support
- some tooling (syntax highlighting, style formatting)

11
Ideas / Re: What about initialization in conditions?
« on: June 27, 2018, 09:01:32 AM »
Currently in C++ it's possible to do (using pointer now)

Code: [Select]
while (Ptr* p = getPointer()) {
  ..
}

This compiles to the exact same thing. So each iteration, p is assigned a value from a call to getPointer().
So this call could have an internal iterator state and return NULL once it's done. These type of constructions
are also used in clang itself because they lower the scope of p.


12
General Discussion / Re: Struct "inheritance"
« on: June 27, 2018, 08:57:23 AM »
struct 'inheritance' in already possible in C by just having the other struct as (first) member.
Also, you can already have object-oriented like features by adding function pointers in a
struct (also in C). Those two cover you example already..

13
General Discussion / Re: Complex numbers
« on: June 25, 2018, 09:00:29 AM »
Since C2 is a descendant of C and has no symbol-mangling, function overloading (multiple functions with same name bit with different arguments)
is not supported. I recently looked at Zig (ziglang.org) a bit and they allow putting functions on many constructs, like types, enums etc. This could
also be implemented in C2..

Code: [Select]
type Color enum u8 { Red, Green, Blue }

func bool Color.isRed(const Color* color) {
  return *color == Red
}

14
General Discussion / Re: Struct "inheritance"
« on: June 25, 2018, 07:53:02 AM »
I think your proposal would complicate the language and create more corner cases. The only thing gained would be
that instead of a.data.name a developer could use a.name. Right?

15
I agree with your extension idea. When compiling C2 code, the compiler has a global view
of the code (ie not per-file, but the whole lib/binary). Thus there can never be multiple functions
with the same name. This also goes for struct functions. While it would be possible to let other
modules add functions to a struct; these functions would have to be globally unique.

This does not have to be a problem, but the error message might be an indication for the developer
to refactor some code..

Pages: [1] 2 3 ... 8