Non-standard CAL features about orcc HOT 6 OPEN

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.
ii) Personnaly, I like the current syntax and I'm not really fond of changing all applications due to a new one... @mraulet I'm not sure about the standardization state of this.
iii) Same idea, is there really an interest to change again if it solves the problem ?
iv) This is a bug that has to be fixed ;)
v,vi) Why not... I've never seen any String declaration in the applications :)

And, of course, contributions are always welcome !

Regards,
Hervé

from orcc.

Hi Hervé, All,

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.

To support string concatenation is one possible solution. However I am weary of introducing a Java style string concatenation we int, floats etc is magically converted to string values. I think we should start with just "string" + "string", and introduce some helper function "int2str" etc.
ii) Personnaly, I like the current and I'm not really fond of changing all applications due to a new syntax... @mraulet I'm not sure about the standardization state of this.
iii) Same idea, is there really an interest to change again if it solves the problem ?

Well, I think we all should be interested if there is a better way. And in any situation applications that are using non standard features are of course in danger of having to be modified. You are the guys driving the standard so I assume you value standard compliance.
iv) This is a bug that has to be fixed ;)
v,vi) Why not... I've never seen any String declaration in the applications :)

And, of course, contributions are always welcome !

Great, should I fix the grammar right away?

Cheers,
J

from orcc.

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 :

• The reaction of other people (At least, the one of @mraulet )
• We plan to do a release today, It would be preferable to keep the FE in its current state for this one

from orcc.

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.

from orcc.

I) print is not part of the standard. So what you propose might be the best solution
We like the java like print. It works well for us.

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

from orcc.

6d68080 has been merged to master (see 73e953b), so iv) & v) are now fixed

from orcc.