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 ... 3 4 [5] 6 7 ... 17
Implementation Details / Re: Code formatting of C2's c++
« on: November 27, 2018, 04:03:50 PM »
I think any else without { } is bad, so:

Code: [Select]
if (x) func1();
else func2();

Would also be a no-go from my perspective, to the point that I would consider changing grammar so that if-else WOULD NEED to be written with blocks.


Code: [Select]
if (foo) bar();

if (foo) {
} else {

if (foo) {
} else if (foo2) {

Accepted by C2, but not in C2 C++ formatting
Code: [Select]
if (foo)

Not accepted by C2, not allowed in C2's C++ formatting
Code: [Select]
if (foo) bar();
else baz();

if (foo) {
} else baz();

if (foo) bar();
else {

Implementation Details / Suppress warnings
« on: November 27, 2018, 02:57:12 PM »
Suppressing warnings should be easy to do on a file / func / statement.

In IntelliJ, annotations are used to suppress warnings on file / class / method level, but can be suppressed by statement with a comment as well, in this manner:

Code: [Select]
// noinspection unchecked
Map<String, List<String>> nameMap = (Map)result.get("names");

For Xcode / Clang, it's much more complicated. You push the current state with a pragma, disable a warning and then have to pop it later. Very ugly:

Code: [Select]
#pragma clang diagnostic push
#pragma ide diagnostic ignored "UnusedValue"
lSeek += file_info.size_file_comment - uSizeRead;
#pragma clang diagnostic pop

I'd like for C2 to have a very easy way to suppress warnings in the manner of IntelliJ's comments.

Something like this:

Code: [Select]
// A.
lSeek += file_info.size_file_comment - uSizeRead; // $ignoreunused$

// B.
lSeek /* $ignoreunused$ */ += file_info.size_file_comment - uSizeRead;

// C.
// $ignoreunused$
lSeek += file_info.size_file_comment - uSizeRead;

// D.
// {unchecked:warn_unused}
lSeek += file_info.size_file_comment - uSizeRead;

Other styles are possible as well. The same should go for other scopes:

Code: [Select]
// {unchecked:warn_unused}
func i32 foo() {

// {unchecked:warn_unused}
type Foo struct {

For file scope it should be slightly different to avoid parsing ambiguity.

General Discussion / Re: Overwriting fields in init struct.
« on: November 27, 2018, 02:42:24 PM »
Should the error on overwriting fields in init struct stay? Or just a warning that can be overridden?

That's fine with me. Might be useful to have that documented though. I only knew from certain from reading the source :D

General Discussion / Discussions where?
« on: November 25, 2018, 11:50:11 PM »
Github issues, this forum or emails? What's the best place for feature suggestions and other ideas for improvement? I note that I'm writing all over the place and maybe it would be best to stick with Github issues?

C++ allows nested namespaces, which means we can have foo::bar::baz() (in C++). For C2, will modules always be single level?

For example if one encounters, can I then be sure that foo is either the module name or the name of a variable defined in the local module – or imported as local?

And can I be sure that bar here can never be part of a module name?

I'm pretty sure that this is true right now, but what about the future – are any future ideas that could change this?

Ideas / Re: Macros again
« on: November 19, 2018, 03:43:54 PM »
A tiny way to modify macros would be to simply extend "#define" with a { ... } syntax:

Code: [Select]
#define ADD_TO(x, y) {
   x += y;

ADD_TO(x, 1)

The { } introduces a multiline macro that does not need explicit linebreaks.

Secondly we could add the "$" symbol to introduce hygienic temporaries:

Code: [Select]
#define SWAP(x, y) {
   typeof(x) $tmp = x;
   x = y;
   y = $tmp;

Here $tmp will actually be replaced by __<macro>_<variable_name>_<instance> when translating to C, so __SWAP_tmp_1, __SWAP_tmp_2 etc.

We then introduce the syntax macros using:

Code: [Select]
macro swap(&a, &b) {
   typeof(a) $tmp = a;
   b = a;
   a = $tmp;

The use of &a follows C++ standard: it simply refers to a variable OR EXPRESSION that is imported into its scope. Using the unadorned variable name as evaluated expression allows us to write this code:

Code: [Select]
macro max(a, b) {
  return (a > b ? a : b)

The above code is equivalent to:

Code: [Select]
macro max(&a, &b) {
  typeof(a) $tmp_a = a;
  typeof(b) $tmp_b = b;
  $tmp_a > $tmp_b ? $tmp_a : $tmp_b

Or in (GNU) C:


Code: [Select]
#define max(a,b) \
   ({ __typeof__ (a) _a = (a); \
       __typeof__ (b) _b = (b); \
     _a > _b ? _a : _b; })

To recap:

1. We add the { } format to #define for multiline defines.
2. We add the $<name> format as hygienic variable names.
3. We add the syntax "macro" type of definition.
4. The syntax macro makes a difference between "normal" parameters (with & as prefix) and "evaluated" parameters (unadorned variables)

In addition we need to make macros have a definite scope. I suggest the following:

#define is always defined local to a scope (unlike in C).

This means that

Code: [Select]
#define FOO printf("foo");
   #define BAR printf("bar");
FOO // adds printf("foo");
BAR; // Error, define not available in scope;

This also means that a define can be declared public to be accessed as if defined from the top of the file scope:

Code: [Select]
// file 1
module foo
public #define FOO { printf("FOO!\n"); }

// file 2
import foo

func void test() {

Only defines in the file scope that exists in the file scope may be public and used in other modules.

Ideas / Re: Macros again
« on: November 19, 2018, 12:48:08 PM »

Ideas / Re: Keyword "void" is terrible (!!)
« on: November 18, 2018, 04:18:05 PM »
P.S. I found styling

What you found was a way to make only half of your text to fit horizontally on the screen at a time when viewed on mobile. Seriously, stop it.

Ideas / Re: Support of Unicode ?
« on: November 18, 2018, 04:14:46 PM »
Swift recently switched to an internal representation of UTF-8 and said it worked out to being faster than alternatives even for languages where UTF-16/32 is considered "better".

General Discussion / Overwriting fields in init struct.
« on: November 18, 2018, 04:11:57 PM »
In this article:

The following method is discussed for setting better defaults of vtables than having NULL in C for the Linux kernel:

Code: [Select]
#define FOO_DEFAULTS  .bar = default_bar, .baz = default_baz
struct foo_operations my_foo = { FOO_DEFAULTS,
  .bar = my_bar,

The usefulness here is that having a meaningful default method, the test for NULL can be avoided. So instead of:

Code: [Select]
if ( != NULL);

We can simply use:

Code: [Select];

Since the default method is assumed to be correct for the situation.

Currently in C2, this would not be possible. While I understand the need to "error proof" things, I think this should not be forbidden in C2, and instead produce a warning that can be supressed using an @(override), like this:

Code: [Select]
#define FOO_DEFAULTS  .bar = default_bar, .baz = default_baz
Foo_operations my_foo = { FOO_DEFAULTS,
  .bar = my_bar @(override),

OR by setting a @(weak) on the default:

Code: [Select]
#define FOO_DEFAULTS  .bar = default_bar @(weak), .baz = default_baz @(weak)
Foo_operations my_foo = { FOO_DEFAULTS,
  .bar = my_bar,

Implementation Details / Re: Defer
« on: November 17, 2018, 02:00:03 PM »
Losing the boilerplate of cleanup at exit is great.

Ideas / Re: Readability of keywords "uint32", "float64" etc
« on: November 17, 2018, 01:59:04 PM »
I would have prefered using the well known Java convention of:

byte = i8
short = i16
int = i32
long = i64
float = f32
double = f64

Then extend to unsigned:

char = u8
ushort = u16
uint = u32
ulong = u64

However, if we want to support: i/u24 i/u48, f128 then that naming scheme is better. I prefer shorter if numbers are added. For the real horror example: NSUInteger of Objective-C on mac. That one is 32 bits or 64 depending on architecture. Aside from the obvious problem of 32/64 bit, the real pain is writing 4 uppercase followed by lower case. Hard to type as well as overly long.

Ideas / Re: Unified style for numbering system
« on: November 17, 2018, 01:44:20 AM »
What is the usecase? C2 supports standard binary, octal and hex notation. Why would this be needed?

Pages: 1 ... 3 4 [5] 6 7 ... 17