Open motib opened 9 years ago
The problem is that native functions are dynamically enumerated. So in theory some targets might not have all math.
functions for instance. We could implement "macros" that check for prerequisites and are available or not depending on which native functions are available, assuming that the name of the native functions provide similar semantics on all targets, which is the case currently with math.
functions.
This is somewhat dependant on issue #278. But if we want to add new features to the Aseba language, we should think whether creating a consistent and Pythonish syntax would not be a better investment of time, as anyway adding proper macro support implies to revisit the whole compiler source code.
I wasn't suggesting something as drastic as modifications to the language or the addition of new features to AESL!
What do you mean by "dynamically enumerated"? If all that means is that it is not guaranteed that all targets support the same set of native functions, then that is true today. Whatever happens (...what would happen?...) if "math.dot" isn't implemented will also happen when a new "math.sum" is called. A caveat to the user of all native functions would be sufficient.
I wasn't suggesting something as drastic as modifications to the language or the addition of new features to AESL!
Then I do not understand how you would see math.sum implemented?
If all that means is that it is not guaranteed that all targets support the same set of native functions, then that is true today.
Indeed it is. By convention all currently-deployed targets link to the Aseba native library, but a third-party might decide not to do so. The reason might be that the micro-controller has not enough memory. I think it was the case in one of the micro-controller of the research robots using Aseba, but I am not sure any more.
A caveat to the user of all native functions would be sufficient.
I agree.
Then I do not understand how you would see math.sum implemented?
I'm assuming (correct me if I am wrong) that the Studio compiler compiles AESL to bytecode that is interpreted by the Thymio microcontroller. I imagined that "math.sum" could be compiled into: allocate memory call fill call dot deallocate memory
This is such a minor issue that I'm willing to withdraw it if you think it raises major problem!
This is such a minor issue that I'm willing to withdraw it if you think it raises major problem!
Your suggested implementation is correct, but it implies modifying the parser of the aesl grammar, so it is not trivial, as one first have to re-discover how the parser works ;-)
But I think that it is good to keep this issue here, as it is a wish to have, and this discussion we have now as some value. I still hope that at some point we can have a Pythonish syntax, and while defining this syntax all the wishes should be considered.
I would like a native function to sum the elements of an array, instead of writing an explicit loop. Since the following code works, it should be possible to implement without changing the firmware.