Recent Posts

Pages: 1 ... 3 4 [5] 6 7 ... 10
41
Ideas / Macro-system design
« Last post by bas on January 30, 2019, 09:17:13 AM »
Since C2 wants to avoid the pitfalls of the C textual-replacement based macro system (and C2 doesn't have includes), a replacement macro system is needed.
Macros have a various, valid use-cases. I'll focus on one case here and try to find a nice syntax + semantics.

What I want is to be able to put a loop over a data structure in a macro, so that changing the underlying data structure maybe doesn't need any 'api' change
for users. So something like

(in some function)
Code: [Select]
   // there is a list.List* mylist that points to the list (let's say a linked-list)
   list.foreach(mylist, i) {     // i is the name of the Element*
      // use Element* i here
      if (i.value == 10) break;
  }

So:
  • list.foreach is the macro
  • When changing the data structure from a linked list to a vector, nothing much has to change in the fragment.
  • The break statement should break out of the macro loop even if  the macro itself has multiple, nested loops.
Note that this is generally not possible in C, since the macro probably needs to add code before and after the user code inside the loop.

The definition could be roughly something like:
Code: [Select]
public macro foreach(List* thelist, iname) {
   Element* iname = thelist.first;
   while (iname != nil) {
       // macro body should be here, How to specify?
      iname = iname.next;
   }
}
So this brings up a lot of questions:
  • how to let a user specify the name of the iterator?
  • Do we required types for macro arguments?
  • How can we specify the place for the macro body?
  • Do we allow using variables from the calling scope (and how to specify)
  • How can we implement the break in user code
  • Do we allow nested macro calling?

For C macro's all these questions are easy, since it's just replacing text. But that gives rise to a lot of issues, so a new system
is definitely needed. But I think a non-textual system will have a lot more restrictions (which can be good), so when designing a
new system, the goal should not be to find a replacement for every possibility in C macros. This won't work. My plan is to
start creating a set of use-cases and build on top of that. The foreach example is just one of those use-cases.
42
Implementation Details / Re: C2 in C
« Last post by bas on January 29, 2019, 10:18:12 AM »
The difference between C and C2 is that you need multiple passes to analyze C2. So sizeof(Foo) cannot be resolved until you
know what Foo is. This means the parser (with Sema) will have to create the AST first and the Analyzer will iteratively resolve
it. That's what's happening currently. A pass is very lightweight, if it only wants to look at a subset (for example the imports), since
we are iterating over a data structure and not actually 'parsing' it again.

So constant folding is just a certain pass that can happen if other required passes have been done.
43
Ideas / Re: deleted
« Last post by bas on January 29, 2019, 10:13:52 AM »
ok
44
Ideas / Re: Operation's priorities - more difficulties then benefits
« Last post by chqrlie on January 24, 2019, 10:08:20 PM »
What is ergonomical in swapping the semantics of < and << ?
Can you cite another language where a < b does not mean a less than b?
This change is a gratuitous departure from common practice, not just C compatibility... very confusing and not at all ergonomical.
45
Ideas / Re: Operation's priorities - more difficulties then benefits
« Last post by chqrlie on January 24, 2019, 04:48:37 PM »
You cannot seriously proposeto change the meaning of operators such as <, >, << or >> ... It would be catastrophic.

Regarding the sometimes counter intuitive order of precedence of the lesser used operators, it is indeed confusing and error-prone. Many compiles offer warnings for unparenthesized use, preventing common errors.

Changing the precedence rules is IMHO a bad idea because it is a gratuitous difference with C, causing more confusion when porting code and/or writing in both languages. A simpler proposal is to make these relative precedence of these operators undefined, causing compile time errors when the are used without parentheses except for simple arguments and unary operators.  This would make some C code incompatible with C2 but would preserve compatibility of C2 code with C.
46
Ideas / Re: Operation's priorities - more difficulties then benefits
« Last post by lerno 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.
47
Ideas / deleted
« Last post by acbaile on January 24, 2019, 04:00:24 PM »
deleted
48
Ideas / Re: Readability of keywords "uint32", "float64" etc
« Last post by lerno on January 23, 2019, 11:12:46 PM »
I've recently discovered that i32 can be significantly faster than "register sized" int.
49
Implementation Details / C2 in C
« Last post by lerno 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.
50
Ideas / Re: Unnatural behavior in C type cast - (uint64)(int32)
« Last post by chqrlie on January 21, 2019, 11:36:34 PM »
I agree that the behavior uint64 var3 = (uint64)(int64)var0; is somewhat unnatural, but converting a negative value as an unsigned value is bound to cause surprising results. Your solution is just as surprising: uint64 var4 = (uint64)(uint32)var0; has the disadvantage that converting the resulting value back to a signed type int64 does not produce the original value, whereas the C semantics do ensure that.

In other words (int64)var3 == var0 for all values of var0, but (int64)var4 == var0 only holds for positive values of var0.

I rest my case.
Pages: 1 ... 3 4 [5] 6 7 ... 10