Anonymous arguments make sense to keep the language terse in places. It seems less ideal to use them for things like operators. add(x=2, y=3) is a lot longer and potentially less intuitive than 2 + 3.
For user declared and library functions which have more extensive argument schemes, it makes sense to have them include keyword arguments to make them more easily used without having to look up the documentation.
The type checking is to help ensure that you're acting on the data you intend to be acting on. Most scripts are simple and because of type checking, will work as intended by the user once the typing is dealt with.
There may one day be simple import statements for other scripts, but as of now there is not.
Because most scripts are short and self encapsulated, exception handling wasn't a priority to implement as compared to globally escaping Exceptions that can abort scripts and can be used to show conflicts to the user in the UI. There may someday be try: except: style syntax.
This was intended to give more flexibility but also to better map to the internal data structures of reservations at QReserve. You may want a script where you check on the other resources in a reservation to make a decision on whether or not a reservation can be made, or a script that prevents a resource being reserved with other resources.
If there is a lot of demand for it in the future, we can add an api function like api.reservations.script_is_attached_to_resource, but for now there should be sufficient expressiveness in sneq to achieve your goals.
Great! We'd love to hear about it, so contact us at https://get.qreserve.com/contact-us.