4 ms·

Without a value judgement here is my analysis. It bears an unexpected similarity with PHP/FI 1.0, where a limited set of extended statements are mixed to the ba

Without a value judgement here is my analysis. It bears an unexpected similarity with PHP/FI 1.0, where a limited set of extended statements are mixed to the base language (which is HTML in PHP/FI and C in Vely). I had a gut reaction that memory management would be problematic, and Vely "solved" it by implicitly owning all memory allocated by Vely statements and deallocating them at the end of the current request. If my understanding is correct, vv doesn't seem to fully understand the C-plus-Vely language and just detects Vely keywords from C tokens [1], and I don't think it's a good idea. [1] https://vely.dev/language_statements.html https://vely.dev/language_statements.html "Note that, Vely statements, after translated into C code by vv, are generally made of multiple C statements, hence Vely statements can never be treated as single-line statements." (suggesting that there is no full parser for C-plus-Vely)

dmillar 4y ago
It seems like what i imagine a cython poc looked like, plus html?
- dsvr 4y ago
  I guess you could see some similarities. Vely is standalone though, not an extension. And it is 100% C, always creating native executables. By that I mean a direct native executable from either pure C or embedded statement producing shallow and performant C, without layers of other languages intertwined (because in the end anything is always a native executable even if it has layers of byte codes, interpreters, alone or mixed with native extensions).
  - dsvr 4y ago
    But I guess from a bird's view point, I can see how all the impressions given here are correct. It does look somewhat like PHP for C or like a markup language, or a declarative language etc. There's some truth to all of that to some extent.
dsvr 4y ago
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.

dmillar 4y ago

It seems like what i imagine a cython poc looked like, plus html?

dsvr 4y ago
I guess you could see some similarities. Vely is standalone though, not an extension. And it is 100% C, always creating native executables. By that I mean a direct native executable from either pure C or embedded statement producing shallow and performant C, without layers of other languages intertwined (because in the end anything is always a native executable even if it has layers of byte codes, interpreters, alone or mixed with native extensions).
- dsvr 4y ago
  But I guess from a bird's view point, I can see how all the impressions given here are correct. It does look somewhat like PHP for C or like a markup language, or a declarative language etc. There's some truth to all of that to some extent.

dsvr 4y ago

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.