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 - lerno

Pages: 1 2 [3] 4 5 ... 16
31
Ideas / Re: typedef struct name_ {} name;
« on: December 07, 2018, 06:23:48 PM »
Yes, that works in C2.

On a completely different note: please change the special font you're using. It makes your texts quite unreadable.

32
General Discussion / Re: C2x
« on: December 07, 2018, 06:22:33 PM »
1. Follow the changes here: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2257.htm#dr_476. Volatile should apply to the access of an object through an lvalue marked volatile.

2. Issues supporting u128, i128, u256, i256 should be considered so that C2 doesn't end up with the same problems. Also, consider emulated 128, 256 integer, and a way for supporting optional integers above width of 64 bits http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2303.pdf

3. Issues with atomics that have different guarantees for ++x and x++: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1955.htm

4. User defined attributes: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2269.pdf This could be useful in a macro system, where one could – for example – create a serialization system based on macros and these user defined attributes.

5. "Add a new calling conventions with error return for library functions that avoids the use of errno" relevant for updated error handling in C2.

6. "constexpr to evaluate expressions at compile time as in C++" relevant for semantic macros.

7. Introduce UTF-8 character type: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2231.htm

Some of these are mostly relevant when compiling to LLVM since it affects LLVM code generation.

33
General Discussion / Re: Overwriting fields in init struct.
« on: December 07, 2018, 11:05:24 AM »
I am concerned over the fact that we're excluding an important feature that's used in the linux kernel. I would actually claim that we're *not* adding much complexity, since we can actually prune this in the parsing step already!

34
Ideas / Re: Error handling [proposal]
« on: December 07, 2018, 10:49:58 AM »
I understand the scepticism. But let’s see if we can refine the proposal syntax wise first? I’ll adress the practical issues if we can create something syntactically simple.

35
Ideas / Re: Error handling [proposal]
« on: December 05, 2018, 05:03:22 PM »
C-compatibility

From C, it is possible to use the generated error structs. Some additional macros can be written to ensure even smoother usage.

Calling C, it can be useful to have a seamless conversion of result-code based calls (1), errno-calls (2) and calls with error as in-parameter (3) e.g:

Code: [Select]
// 1
API_RESULT do_something(int a, Foo *foo);

// 2
bool success = do_something(int a, Foo *foo);
if (!success) { /* do something with errno */ }

// 3
Error err;
bool success = do_something(int a, Foo *foo, &err);
if (!success) { /* do something with err */ }

All of these could be automatically wrapped by C2 later on. However, it's not important for the first version.

Function signatures

Zig uses ! to denote errors or error separator, e.g:

Code: [Select]
pub fn parseU64(buf: []const u8, radix: u8) !u64 { ... } // inferred error
pub fn parseU64(buf: []const u8, radix: u8) anyerror!u64 { ... } // catchall
pub fn parseU64(buf: []const u8, radix: u8) ErrorSetX!u64 { ... } // throws errors from the ErrorSetX enum.

For Go it's just part of the signature.

For C2 there are a bunch of solutions:

Code: [Select]
func u64 parseU64(u8* buf, u8 radix) !anyerror { ... }
func u64 parseU64(u8* buf, u8 radix) anyerror!!  { ... }
func u64 ! anyerror parseU64(u8* buf, u8 radix)  { ... }
func u64 !! anyerror parseU64(u8* buf, u8 radix)  { ... }
func u64 parseU64(u8* buf, u8 radix) fails(anyerror) { ... }
func u64 parseU64(u8* buf, u8 radix) throws anyerror  { ... }
func u64, anyerror parseU64(u8* buf, u8 radix)  { ... }
func u64, anyerror!! parseU64(u8* buf, u8 radix)  { ... }
func u64 parseU64(u8* buf, u8 radix) anyerror!!  { ... }

Payload
I believe the idea of Zig to simply make the error code an enum union is good. Unlike other schemes, this means that adding additional error codes does not break the signature. The enum union should be register sized but at least 32 bit, meaning 64 or 32 bits in practice.

Encoding additional information some further discussion, there are essentially 3 approaches:

  • No additional data, just the enum
  • Error is encoded in the result
  • A thread local errno can encode information

(3) breaks purity of functions.
(2) changes size in return object if the error payload is allowed to vary. If (2) returns a pointer then cleanup of that pointer might be hard to enforce.
(1) Is limiting, and will probably mean ad-hoc solutions passing in &err-structs.

I'm slightly partial to (2) despite the drawbacks.

36
Ideas / Error handling [proposal]
« on: December 05, 2018, 02:34:37 PM »
The main idea is to pass results using an error channel that is separate from the underlying result. The call is compatible with C.

A return value can be described as:

Code: [Select]
struct _result {
   union {
     Result result;
     Error error;
   }
   bool error;
}

Where "Result" is the result type which will vary by method.

For example, consider a method createFoo() that could return an error or a Foo*. The C signature would look like this:

Code: [Select]
struct _resultFooStar {
   union {
     Foo* result;
     Error errorResult;
   }
   bool error;
}

struct _resultFooStar createFoo() {
   ...
}

For C it can then be used in this manner:

Code: [Select]
struct _resultFooStar res = createFoo();
if (res.error) {
  // Do something with res.errorResult
  return;
}
Foo *foo = res.result;

For C2 we obviously want some more syntactially pleasing. The tricky part is to assign both error and normal result, even though they are exclusive.

Go would write something like foo, errorResult := createFoo() but this still requires an extra test and is something they actively work on to improve. Not to mention that C2 doesn't have tuples.

Keyword or not?

We can decide on using keyword (catch, rethrow) or use symbols, e.g. !!, !? etc. Below I will offer both versions with keywords and without keywords.

Rough common ground

First of all we need a way to rethrow any error to the top. In Go this would be:

Code: [Select]
res, err := createFoo();
if (err) return nil, err;

Zig on the other hand uses "try" to signal that it will rethrow:
Code: [Select]
res = try createFoo();

Here I suggest we use the same method as Zig, but with postfix:

Code: [Select]
res = createFoo()!!; // !! to signal rethrow.
res = createFoo() rethrow; // using keyword instead.
res = createFoo(); // compile time error since error is not handled.

Secondly, we need a way to ignore the error and replace it with a dummy value if there was an error.

In Zig:

Code: [Select]
res = createFoo() catch defaultFoo; // Return defaultFoo in case of error.

For C2 I propose the following:

Code: [Select]
res = createFoo() !! defaultFoo; // The idea is using !! as "||"
res = createFoo() ?! defaultFoo; // Instead borrowing from ?: syntax
res = createFoo() catch defaultFoo; // Using keyword catch
res = createFoo() else defaultFoo; // Using keyword else

Different possibilities

For handling errors we have two major directions (that actually can be used together). One is using error handlers defined separately, the other is handling direct at the callpoint.

We can look at Zig's handling:

Code: [Select]
if (createFoo()) |foo| {
  doSomethingWithFoo(foo);
} else |err| switch (err) {
  error.FooCreation => {
    // handle this...
  },
  // handle next error here ...
}

In the Go2 proposal we have handlers:

Code: [Select]
handle err {
  if (err == "FooCreation") {
     // handle this
  } else {
    // Handle other error
}

foo := check createFoo()

C2 errors with inline error handling (like Zig)

Code: [Select]
// Using !!
FILE *f = fopen("Foo") !! (err) {
  // Switch-like structure opened by default
  case error.FooCreation:
    // handle this...
  case ...
   // handle next error here ...
};

// Using catch keyword
FILE *f = fopen("Foo") catch (err) {
  // Switch-like structure opened by default
  case error.FooCreation:
    // handle this...
  case ...
   // handle next error here ...
};

// Using !=> with error variable being implicitly defined (does not allow nesting)
FILE *f = fopen("Foo") !=> {
  // Switch-like structure opened by default
  case error.FooCreation:
    // handle this...
  case ...
   // handle next error here ...
};

The downside of the above is when wanting to handle things in an if statement. Consider:

Code: [Select]
while (Foo* foo = createFoo()) {
   ...
}

Now envision error handling of the above type. Not pretty. Here error handlers shine.

C2 errors with error handlers

Code: [Select]
handler errHandler(err) {
  case error.FooCreation:
    // handle this...
  case ...
   // handle next error here ...
}

Foo *foo = createFoo() catch errHandler;

while (Foo* foo = createFoo() catch errHandler) {
   ...
}
;

This also allows for reuse of handlers at several points in the code.

Note that they are not mutually exclusive, they can actually coexist.

Examples

Finally I end with a few examples that can be used to imagine real life situations:

Rethrowing or using defaults:

Code: [Select]
if (a_may_throw() rethrow + 2 > 0) {
    // do something
}

if (a_may_throw()!! + 2 > 0) {
    // do something
}

if ((a_may_throw() !! 0) + 2 > 0) {
    // do something
}

if ((a_may_throw() ?! 0) + 2 > 0) {
    // do something
}

(I'll add some more later)

Proposals rules out

I considered a solution like this:

Code: [Select]
FILE *f ! err = fopen("Foo");

// read(f) - Would be compiler error
// as err is not tested in the scope

if (err) {
    printf("Found error! %s", err);
    raise err;       
}   

// f can be used here since err is checked

But it did not seem attractive enough compared to the other methods (inline and error handlers), and it also requires more analysis and special syntax / grammar without adding clarity.

37
Ideas / Re: Typeinfo at runtime
« on: December 03, 2018, 02:08:56 AM »
vtype could actually be simply an enum, generated at runtime.

38
Implementation Details / CTC (partial, full, none)
« on: December 01, 2018, 05:34:50 PM »
I'd like some clarification on how this one works and what the expectation is for each state.

39
Ideas / Typeinfo at runtime
« on: December 01, 2018, 10:59:10 AM »
I want to suggest that type info should be available at runtime. There are various way to implement this. In the end, the type should only be reduced to a number that’s used to access a generated a set of functions that are built during code generation.

To do this we need to introduce another built in type, ”vtype”.

Code: [Select]
vtype x = typeof(a);
bool y = is_struct(x);

What’s interesting here is for scripting and very dynamic plugins.
A function may take a void* plus the vtype and work on the data as if it was the given type, even though the code was built BEFORE the type was written.

The most general use for this is to dump structure data for debugging.
The macro can then be something like:

Code: [Select]
#define DUMP(x) dump_data(typeof(x), (void*)&x)

(Very rough, but hopefully you see what I mean)

dump_data here is a FUNCTION not a macro.

This is just a discussion starter. Add to the idea!

40
Ideas / Re: Switch proposal
« on: November 30, 2018, 06:39:23 PM »
Err... My proposal was to add implicit break.

41
General Discussion / Re: Overwriting fields in init struct.
« on: November 30, 2018, 06:37:46 PM »
Motivation why it should be allowed is in the first post...

42
Implementation Details / Re: Suppress warnings
« on: November 30, 2018, 06:36:53 PM »
For file maybe. I find that I mostly will turn of statement based warnings. It's when I run into a piece of code I know will be safe, but that the compiler think might be unsafe. In java that's usually casting between generics. For Objective-C, using dynamic calls where the compiler can't see the definition, etc. Things that you want to avoid 90% of the cases.

43
Implementation Details / Re: Code formatting of C2's c++
« on: November 30, 2018, 06:33:38 PM »
Oh, it's not about stupidity, it's about grammar ambiguity.

44
Implementation Details / Re: LLVM/C gen
« on: November 30, 2018, 06:32:45 PM »
I don't know. I've looked at IR gen by other languages and it seems they don't have it. It might me that they are not yet heavily invested in debugging. I don't know.

45
General Discussion / Re: Overwriting fields in init struct.
« on: November 29, 2018, 02:45:24 PM »
/Init/init_field_designator_duplicate.c2

Pages: 1 2 [3] 4 5 ... 16