When you create a predicate instance it creates the corresponding underlying clingo.Symbol object. Clorm does not try to validate the input to the predicate but instead lets the clingo API take care of that. So if a user tries to assign to the wrong type (for example, passing a string when you're trying to create an integer symbol) then it is up to the clingo API to deal with it. There are a few issues here:
The CFFI errors that are thrown for a failed conversion are not easy to understand. So I should catch these errors and report back a clearer message of the type conversion failure.
Clorm works with both clingo 5.4 and 5.5. I think clingo 5.4 is more permissive and will try to use Python's duck-typing to generate the correct data type (eg. the string "5" can be converted to number 5). Clingo 5.5 (which uses CFFI) is stricter and will fail such cases. I think it is best to let the clingo API decide these matters so I don't think there is anything I should do; except...
In the noclingo mode where it uses my internal Symbol proxy objects I let Python's duck typing handle trying to make any conversions. So we could potentially get some unexpected behaviours. For example, a main process that uses noclingo mode assigns "5" as a number. Python duck-typing accepts this and creates the proxy symbol object without complaint. However, the value of the predicate parameter is still "5". This object is the serialised and passed to a worker process which is using clingo mode because it will call the solver. So when the object is de-serialised it will try to create a clingo.Symbol object. But this will fail since the conversion from the string "5" to an integer will now fail (if you're using clingo 5.5). So the main process won't detect anything wrong but the worker process will throw an exception. I need to think about this. I'm not sure if it is better to try to do something or to simply document it.
When you create a predicate instance it creates the corresponding underlying
clingo.Symbolobject. Clorm does not try to validate the input to the predicate but instead lets the clingo API take care of that. So if a user tries to assign to the wrong type (for example, passing a string when you're trying to create an integer symbol) then it is up to the clingo API to deal with it. There are a few issues here:The CFFI errors that are thrown for a failed conversion are not easy to understand. So I should catch these errors and report back a clearer message of the type conversion failure.
Clorm works with both clingo 5.4 and 5.5. I think clingo 5.4 is more permissive and will try to use Python's duck-typing to generate the correct data type (eg. the string "5" can be converted to number 5). Clingo 5.5 (which uses CFFI) is stricter and will fail such cases. I think it is best to let the clingo API decide these matters so I don't think there is anything I should do; except...
In the noclingo mode where it uses my internal Symbol proxy objects I let Python's duck typing handle trying to make any conversions. So we could potentially get some unexpected behaviours. For example, a main process that uses noclingo mode assigns "5" as a number. Python duck-typing accepts this and creates the proxy symbol object without complaint. However, the value of the predicate parameter is still "5". This object is the serialised and passed to a worker process which is using clingo mode because it will call the solver. So when the object is de-serialised it will try to create a clingo.Symbol object. But this will fail since the conversion from the string "5" to an integer will now fail (if you're using clingo 5.5). So the main process won't detect anything wrong but the worker process will throw an exception. I need to think about this. I'm not sure if it is better to try to do something or to simply document it.