Table of Contents

• Questions and Answers
• Why are there anonymous arguments for native functions but named keyword arguments for everything else? That's inconsistent!
• All this type checking results in a lot of errors that I wouldn't have had to deal with in python.
• There are no modules and I have to keep rewriting boilerplate across scripts.
• There's no way to catch and handle exceptions.
• It's annoying that scripts have access to the parent and child reservations of a multi-resource reservation when they're attached to a single resource.
• I found a bug or some unexpected behavior.

Questions and Answers

Why are there anonymous arguments for native functions but named keyword arguments for everything else? That's inconsistent!

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.

All this type checking results in a lot of errors that I wouldn't have had to deal with in python.

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 are no modules and I have to keep rewriting boilerplate across scripts.

There may one day be simple import statements for other scripts, but as of now there is not.

There's no way to catch and handle exceptions.

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.

It's annoying that scripts have access to the parent and child reservations of a multi-resource reservation when they're attached to a single resource.

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.

I found a bug or some unexpected behavior.

Great! We'd love to hear about it, so contact us at https://get.qreserve.com/contact-us.