Add section on parallel execution semantics

[acl-cqc]

closes #143

Note very much DRAFT

Added as a section of python_differences.md but might want to be a separate document. Can read here: https://github.com/Quantinuum/guppy-docs/blob/acl/parallel_semantics/sphinx/language_guide/python_differences.md#parallel-execution-semantics

Expectations of future releases

I'm assuming that we'll consider a change to the spec (i.e. allowing more reordering) as breaking, but have included a documentation of the v1.0 release with the intention that we can change that behaviour (within the bounds of the parent section) without considering it breaking. Unsure if this is the right approach...

...e.g. a "rolling breakage" model like that proposed for the standard library might be better, although deprecation here is not really practical (we can't tell when people are relying on particular semantics).

Content

I've stated panics can be reordered. I have not said anything specifically about qalloc; by implication, this means

• we could reorder qalloc vs, say, an array indexing op, and get an "unexpected" change to panic message
• we could reorder qalloc vs each other. My justification here is that currently the following program fails on an emulator with only one qubit: qalloc(); qalloc() - and it fails with a message guppylang.emulator.exceptions.EmulatorError: Panic (#1001): No more qubits available to allocate. - that is, we're (predictably) panicking, and the message does not specify which qalloc failed, so there is no possibility of surprise even there.

But, I have not said qallocs can be reordered vs. qfree - should I explicitly clarify that this cannot happen?

Re. documented behaviour of 1.0 release, I've investigated the hugrs for a few examples and think this is correct but please shout out if you think otherwise.

[hugrbot]

Hey there and thank you for opening this pull request! 👋

We follow the Conventional Commits convention for PR titles. It looks like your title needs some adjustment.

The title should have a type prefix, followed by a colon. The most important ones are:

• feat: for new features
• fix: for bug fixes

If the PR contains a breaking change, use feat!: or fix!: instead and include a "BREAKING CHANGE:" footer in the description of the pull request.

You may also include a (scope) after the type prefix.

Expand this message for the full list of tags.

• feat: New feature
• fix: Bug fix
• docs: Documentation-only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc)
• refactor: A code change that neither fixes a bug nor adds a feature
• perf: Performance improvements
• test: Adding missing or correcting existing tests
• ci: Changes to our CI configuration files and scripts
• chore: Other changes that do not alter public APIs or code behaviour
• revert: Reverts a previous commit

[acl-cqc]

this is just a note, doesn't need to go in