Non-standard CAL features #42
Comments
|
Hi Johan, i) True, the print should be a standard native function... The tricky part is to handle the concatenation such as println("dd" + res), it's probably related to a better support of the string type/operation. And, of course, contributions are always welcome ! Regards, |
|
Hi Hervé, All,
Cheers, |
|
Hahaha, it's great to see your motivation... Be free to make your own branch, we have to wait two things before merging it to the master :
|
In function / procedure / action, CAL standard specify that variables must be declared in a specific 'var' block.
|
iv) has been fixed in 6d68080, but only in a branch for now. This better implementation of CAL standard introduces a lot of errors across all projects in https://github.com/orcc/orc-apps repository. These errors need to be fixed before merging this branch to master. |
|
I) print is not part of the standard. So what you propose might be the best solution Ii) it is already c style array declaration in the standard. This involves to change 3 different standards. Iii) this can be a contribution to MPEG. But at the moment we might have to change the applications according to the syntax allowed in the standard. Iv) grammar fixed. Works need to be done on applications. Vi) I have to check he standard. Don t remember the exact syntax |
Hi All,
I am looking into compiling the ORC-Apps with an alternative tool chain and run into a number of issues related to use of non standard functions and/or syntax (or maybe some has become standard and I am just out of sync).
i) The use of the built-in function println is causing incompatibilities. I seem to remember a standardization effort to address printing, so maybe you can show me how it shall look. I am sure at least that it is not part of the language, as it seems to be in ORCC.
I propose that you move println() to the system project.
ii) Array declarations using C-style notation is commonly used. Is that standardized yet? If not, I would propose a slightly modified syntax placing the brackets with the type, and not with variable, i.e. like
The syntax for variable declarations in CAL is " ", and as far as I am concerned the array dimensions are part of the type.
iii) The keyword 'elsif' is introduced to address the ugly problem with nested 'if'-loops. I think this is something that needs fixing, but maybe not this way.What is the status with this in the RVC standard. If not done yet, I propose we bring this up for discussion.
[edit] Next 2 points have been fixed in 73e953b
iv) ORCC do not require variables to be declared in the 'var' section of functions, procedures, action etc. and instead allow declarations in the beginning of the body.v) Semicolon for separation of declarations is allowed in ORCC. I think this is welcome addition, but needs to be added to the standard. The semicolon following the last declaration should be optional. I believe this is connected to #iv)vi) The type "String" is with capital letters. All other basic types are with lower case and I believe string should be as well. Is this standardized?
Cheers,
Johan
The text was updated successfully, but these errors were encountered: