19 posts
Edited by Maykeye on Reason: Initial post
If yes, what kind?

I so far plan to add small built-in test framework (ala CATCH's sections)

And generally small quality of life changes - like additional syntax for casting("cast(int*, char_ptr)+4" is very explicit in its meaning, while "cast(int*)(char_ptr) + 4" can be misinterpreted as "(cast(int*)char_ptr)+4",
more stuff with enums (e.g. strong enums, like c++ enum class, if ion's enums will be more like C enums)

Hopefully ion will start go towards C codegen sometimes soon so it'll be easy to test drive language design ideas.
Per Vognsen
49 posts / 1 project
Edited by Per Vognsen on
We should be starting C codegen this week.

Your cast example made me realize I had bugs in the BNF and parser code for cast expressions, and it sounds like you thought that was intentional, so thanks for bringing that up. It's intended to have the same binding strength as a C cast, i.e. very tight, so the expression operand is now expr_unary rather than expr. If you write cast(int)p * 2, it will be interpreted as (cast(int)p) * 2.

I'll happily solicit alternative syntax suggestions for casts. I'd rather not have mandatory parentheses around the expression operand, though. At one point I was considering (^int)p * 2 and I'm starting to consider it again. It's syntactically compact in a way that's more reminiscent of C casts, it exploits the unused prefix operator ^ which also has mild mnemonic value as looking like an arrow. What do people think?

Edit: Someone pointed out that ^ requires two modifier keys on some European keyboards, which probably eliminates it from contention. I checked in support for cast(type, expr), but it's likely to change again if I get a better suggestion. Keep the suggestions coming!
19 posts
pervognsen

I'll happily solicit alternative syntax suggestions for casts. I'd rather not have mandatory parentheses around the expression operand, though. At one point I was considering (^int)p * 2 and I'm starting to consider it again. It's syntactically compact in a way that's more reminiscent of C casts, it exploits the unused prefix operator ^ which also has mild mnemonic value as looking like an arrow. What do people think?

Edit: Someone pointed out that ^ requires two modifier keys on some European keyboards, which probably eliminates it from contention. I checked in support for cast(type, expr), but it's likely to change again if I get a better suggestion. Keep the suggestions coming!

Honestly, having ^ seems strange, at least if a plan from early days to have casts int(nonInt) stays the same. In that case, one would expect to be able to write
(:int)(nonInt) as well, as it's the usual existing alternative way for types, which makes (^int)(nonInt) either redundant or confusing(when one should be used over the other?).

----

Well, anyway, I've managed to bring mion compiler to the point where it can make fizzbuzz, here it is on ideone with faked argc/argv. Noticeable extension - "func atoi(string : char*) : int = extern", as of now mion doesn't allow to use undeclarated functions.

(From unnoticeable, but I liked them - integer literals support underscores, like 0b1000_0000)

So, from an experience of writing fizzbuzz in ion:
I'm not sure that I like that increment/decrement is a statement, not an expression. Consider the following.

 1 2  s[i] = '0'; i++; s[i] = '\0'; i++; 

In C/Java/etc it's very easy to construct buffers(string in this case) incrementally: you just write bunch of lines like s[i++]=X, so you can insert/remove lines in the middle. In ion, you either will have to increment counter in separate statement or to hardcode indexes
Per Vognsen
49 posts / 1 project