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.

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!

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.



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

I actually changed it to (:int)x over the weekend, so it's basically the C syntax now except for the prefix colon.

I agree that *ptr++ and other idioms like that are very handy. Maybe keeping the other assignment operators as statements and having post/pre increment/decrement as expressions is the right decision. I'll think about it.

Alright, I got around to changing ++ and -- to be expressions (in both postfix and prefix forms) like in C. I'd been planning on switching after last post, but the last drop was noticing an evil precedence bug. *p++ cannot have the same meaning as in C if ++ is a statement since we'll need to parse it as <expr> ++, which means it will be parsed as (*p)++ rather than *(p++). Granted, *p++ in the C sense isn't useful when ++ is only a statement, but the mere fact that the precedence was busted like that pushed me into action.

(There was also an unrelated bug in the C code generator which for (*p)++ would generate *(p)++ because I wasn't parenthesizing the subexpression. That is now fixed too.)