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 ... 17
16
Ideas / Re: Require explicit (un)initialization.
« on: January 31, 2019, 12:43:19 AM »
I like the reuse of void.

In regards to int a; initialized to zero implicitly - I understand the thought that this is counter to whar one usually expects. On the other habd this makes static and local variables behave exactly the same way and it simplifies how one reasons about struct init.

For example, it is more natural to expect Foo f = { .one_field = 1 } to actually zero out all other fields in the struct if we have implicit zeroing.

An alternative would be to disallow int a; completely, requiring it to either be initialized to ”void” or some value. On the other hand, that would then also need to be true for göobals, and I don’t know if this added requirement for statics is something that would be appreciated.

17
Ideas / Require explicit (un)initialization.
« on: January 30, 2019, 06:07:18 PM »
Instead of warning on non-initialized variables and explicitly initializing, consider the following change:

Code: [Select]
int a; // a initialized to 0, as if it was static.
int a = 10; // a initialized to 10
int a = uninitialized; // a not initialized, warning if used before later assignment.

Alternatives to uninitialized:

Code: [Select]
int a = ---;
int a = *;
int a = ?;

18
Ideas / Re: Macro-system design
« on: January 30, 2019, 10:48:55 AM »
All of the above ties into the generics proposal. The generics being a way to create packets of macros basically, but has space advantages.

19
Ideas / Re: Macro-system design
« on: January 30, 2019, 10:47:08 AM »
Allowing nested macros could allow us to do recursive macro resolution, which opens up compile time execution.

20
Ideas / Re: Macro-system design
« on: January 30, 2019, 10:41:04 AM »
In the case of the inline body I think this would be reasonable:

Code: [Select]
public macro foreach(thelist, @body(Element *) ) {
   Element* iname = thelist.first;
   while (iname != nil) {
      @body(iname);
      iname = iname.next;
   }
}

Or a version that is more flexible:
Code: [Select]
public macro foreach(thelist, @body(typeof(thelist.first)) ) {
   typeof(thelist.first) iname = thelist.first;
   while (iname != nil) {
      @body(iname);
      iname = iname.next;
   }
}

Usage:

Code: [Select]
foreach(list, Element *i) { // <- Note type declaration!
   i.print();
}

Since type is going to appear very often, we could make a shortcut for it, like $@ as prefix meaning "typeof".

We then get

Code: [Select]
public macro foreach(thelist, @body($@thelist.first) ) {
   $@thelist.first iname = thelist.first;
   while (iname != nil) {
      @body(iname);
      iname = iname.next;
   }
}

Possibly we could even write the code like this:

Code: [Select]
public macro foreach(thelist, @body($element_type) ) {
   $element_type iname = thelist.first;
   while (iname != nil) {
      @body(iname);
      iname = iname.next;
   }
}

In this case $element_type works like "auto", but is also assigned the type, which then can be referred to in the signature.

21
Ideas / Re: Macro-system design
« on: January 30, 2019, 10:33:30 AM »
1. I think it's a bad idea to syntax check the macros using types (the "List" type) there. In order to show constraints, prefer contracts like in the Go2 proposal. Such a contract can include type if one wants to.

Possibility (1) inline require/contract

Code: [Select]
public macro foreach(thelist, iname) {
   @require {
      thelist.first;
      thelist.first.next == thelist.first;
   }
   Element* iname = thelist.first;
   while (iname != nil) {
       // macro body should be here, How to specify?
      iname = iname.next;
   }
}

We can then continue making this even more general:

Code: [Select]
public macro foreach(thelist, iname) {
   @require {
      thelist.first;
      thelist.first.next == thelist.first;
   }
   typeof(iname.first) iname = thelist.first;
   while (iname != nil) {
       // macro body should be here, How to specify?
      iname = iname.next;
   }
}

I suggest the use of compile time variables to clean up things:

Code: [Select]
public macro foreach(thelist, iname) {
   @require {
      thelist.first;
      thelist.first.next == thelist.first;
   }
   $element_type = typeof(iname.first); // Not visible after compilation
   $element_type iname = thelist.first;
   while (iname != nil) {
       // macro body should be here, How to specify?
      iname = iname.next;
   }
}

The alternative to inline contracts are external ones:

Code: [Select]
type List contract {
   self.first;
   self.first.next == self.first;
}

public macro foreach(@List thelist, iname) {
   $element_type = typeof(iname.first); // Not visible after compilation
   $element_type iname = thelist.first;
   while (iname != nil) {
       // macro body should be here, How to specify?
      iname = iname.next;
   }
}


22
Ideas / Re: Operation's priorities - more difficulties then benefits
« on: January 24, 2019, 04:26:35 PM »
Changing operator meanings to mean something completely different makes zero sense.

Note that operator precedence is already changed.

23
Ideas / Re: Readability of keywords "uint32", "float64" etc
« on: January 23, 2019, 11:12:46 PM »
I've recently discovered that i32 can be significantly faster than "register sized" int.

24
Implementation Details / C2 in C
« on: January 23, 2019, 01:12:38 AM »
I'm implementing a version of the C2 parser in C right now. Not all that much to see. It parses all of C2 as far as I know (...probably a quite a few bugs...) and mostly follows C2C's architecture. Reading recipe files and a some other stuff and also the semantic analysis is just started.

However the idea is that the parser is prepared from the first for some compile time evaluation. For example, this would be completely valid and resolved during compile time:

Code: [Select]
Foo foo[sizeof(i32) > 0 ? 1 : 2];

I'm intending to have everything constant folded by default to open up for some lightweight compile time resolution. I suspect it will help with future semantic macros and generics.

That said it's far from being done.

25
Ideas / Re: Syntax of const pointers
« on: January 02, 2019, 02:45:37 AM »
I've thought about this some more and I'm actually leaning towards 5 now, since that would make things easier when reading.

Do we want to write:
Code: [Select]
int volatile x = 10;
Foo const foo = { ... };
int * const y = &x;

// or
volatile int x = 10;
const Foo foo = { ... };
int const* y = &x;

Maybe it's just me, but in the simple case then the prefix keyword really rules.

And for the complex ones, maybe () isn't such a bad idea:

// 4
Code: [Select]
int* volatile x = 10;     // volatile pointer to int
Foo* const foo = { ... }; // const pointer to Foo
Foo const* foo = { ... }; // pointer to const Foo
int* const y = &x;        // const pointer to int
int const* y = &x;        // pointer to const int

// 5
Code: [Select]
int volatile* x = 10;     // volatile pointer to int
Foo const* foo = { ... }; // const pointer to Foo
const Foo* foo = { ... }; // pointer to const Foo
int const* y = &x;        // const pointer to int
const int* y = &x;        // pointer to const int

// 1
Code: [Select]
volatile (int*) x = 10;     // volatile pointer to int
const (Foo*) foo = { ... }; // const pointer to Foo
(const Foo)* foo = { ... }; // pointer to const Foo
const (int*) y = &x;        // const pointer to int
(const int)* y = &x;        // pointer to const int

Note that it looks very different visually depending on where you put the "*". (1) shines when the star is put next to the type.

One more thing to consider should be the parsing. For example: an expression starting with '(' can be deducted to always be an expression on C, but with ( ) in the type names, that would not be obvious.

26
Ideas / A brief and simple generics proposal
« on: December 28, 2018, 08:04:34 PM »
Since we want semantic macros we need to consider the usecase where C uses macros to create generic code. Here is a sketch of how that could be implemented.

1. A generic implementation is implemented in a generics module:

Code: [Select]
module vector (A, B, C); // A, B, C are generic parameters.

type Foo struct {
   A a;
}

func C test(B b, Foo *foo) {
   return a + b;
}

To use this generic code, simply import:

Code: [Select]
import vector(f64, f32, i32) as generic_tests;

func f64 test()
{
   generic_tests.Foo foo = { 2.0 };
   return generic_tests.test(3.0, foo);

Thanks to the namespacing in C2, we can don't actually need to create an alias if we want to. The module is all we need in order to make this work.

One issue

There is only one issue here. This solution has pretty much the same issue as C++ templates – lack of good error messages.

A solution would therefore be to set up a clause with contracts the types must pass. This is similar to the solution proposed in C++ / Go2:

Code: [Select]
module vector (A, B, C);

contract(A a, B b, C c) {
   a + b;           // Only expressions allowed
   c == a + b;   // Only expressions allowed
}

... code ...

A generic is not completely error checked until it is instantiated, with the contract however, the expressions are FIRST validated, and reported as errors.

Code: [Select]
import vector(struct Bar, f32, i32) as gen_test;

// This would give the error
---> Illegal arguments for generic module vector, breaks contract 'struct Bar' == 'f32' + 'i32'

This proposal is minimal, does not clutter the language with type arguments (i.e. no Foo<f32> etc), prevents misuse and requires very little extra syntax and complexity.

27
Implementation Details / Re: Implementation based on Clang or...?
« on: December 21, 2018, 11:17:22 AM »
Well I was not talking about "at the moment" but toward the future of a possible self-hosted C2.

28
Implementation Details / Implementation based on Clang or...?
« on: December 20, 2018, 08:25:20 PM »
There are two lightweight C-based compilers of C, TCC and recently 9cc.

One idea would be to implement the C2 compiler on top of either of those instead. TCC is known for it's very fast compilations speed. The fact that both are written in C allows us to potentially implement them in C2 instead.

Possibilities

1. Use C2-Clang/LLVM to compile a mod of 9cc/TCC rewritten in C2
2. Write C2-9cc/TCC which then is piece by piece replaced by C2 implementation.

Obviously this is something for the future and should not detract from the current work on C2-Clang/LLVM.

29
Ideas / Re: Extended switch statement
« on: December 17, 2018, 08:10:29 PM »
First, a minimal change would be to simply allow ranges in switch statements, such as:

Code: [Select]
switch (x) {
  case 1 .. 10:
     ...
  case 11 .. 100:
     ...
}

Secondly, I think it's a more constructive way to work by actually discussing how a proposal should look if adapted to C, rather than to dismiss it early because it doesn't feel like C.

I know it is tempting to dismiss this altogether, but if we have a proposal that looks like suitable for C, it's easier to both determine whether it is an evolution or not (i.e. sufficiently small change) and if worthwhile AND to have something to refer to later on when similar proposals inevitably show up.

Finally, its a good exercise "translating" the proposal to a useful form. I would argue the same for the error proposal: first see if it can be molded into something less ugly then decide whether it should be dismissed or not.

The limited switch IS a C deficiency, just like the limited error handling, header files, preprocessor macros etc. In order to see if there's an evolutionary way out of it, an evolutionary proposal should be made and I'm submitting incomplete proposals exactly so that it's more inviting to come and offer counterproposals and changes. The incompleteness is completely deliberate.

So again, I would like to discuss how it should look, then decide if that is useful enough to be considered for inclusion. Not dismissed in its incomplete state.

30
General Discussion / Re: Overwriting fields in init struct.
« on: December 16, 2018, 07:28:51 PM »
Weren't there any links in that article?

Pages: 1 [2] 3 4 ... 17