Thanks for the feedback, I appreciate it. Yes, Vely does not parse C. Placing Vely statement outside of functional context (say in between functions) will result in gcc errors. Vely allows error reporting to show both generated C or line numbers in Vely code, so depending on what the error is, it's not that difficult to find.
Making Vely understand C, at least insofar as necessary to prevent issues like this is something that I might add, and it probably wouldn't cost that much. It's definitely worth a look.
From a purely functional perspective, assuming Vely statement is placed properly in a functional context, understanding C (as in parsing and then parsing Vely within) might not bring much benefit. Syntactically speaking, Vely is built to not require much about host language. Though, Vely understands enough to emit meaningful messages, such as in the case of writing:
if (cond)
vely_statement
where you will get an error that will prevent code from doing unexpected things. There's quite a few of those safeguards built-in.
Being embedded, Vely is a compromise. That was the goal to preserve pure C performance.
Beyond the above, one can still do anything that C can do and that may not be safe; but if Vely is used for what it does, the chances of that go down. Being able to rapidly do stuff in C that is richer and safer is the plus side of it. Without a compromise with being embedded, it would be yet another language that does everything great but with ever declining performance.
And that is fine, if such loss of performance and increased footprint is acceptable; there is nothing wrong with that. Vely's niche is to stay in best performance bracket, and yet bring that performance to general and web application development.
Making Vely understand C, at least insofar as necessary to prevent issues like this is something that I might add, and it probably wouldn't cost that much. It's definitely worth a look.
From a purely functional perspective, assuming Vely statement is placed properly in a functional context, understanding C (as in parsing and then parsing Vely within) might not bring much benefit. Syntactically speaking, Vely is built to not require much about host language. Though, Vely understands enough to emit meaningful messages, such as in the case of writing:
if (cond) vely_statement
where you will get an error that will prevent code from doing unexpected things. There's quite a few of those safeguards built-in.
Being embedded, Vely is a compromise. That was the goal to preserve pure C performance.
Beyond the above, one can still do anything that C can do and that may not be safe; but if Vely is used for what it does, the chances of that go down. Being able to rapidly do stuff in C that is richer and safer is the plus side of it. Without a compromise with being embedded, it would be yet another language that does everything great but with ever declining performance.
And that is fine, if such loss of performance and increased footprint is acceptable; there is nothing wrong with that. Vely's niche is to stay in best performance bracket, and yet bring that performance to general and web application development.