Open ajberdy opened 11 months ago
Prototype branch started here to explore fixing this, which always allow input parameters to be declared at the time of registering them: https://github.com/amazon-braket/autoqasm/compare/main...rmshaffer/input-param-name-conflict
But as discussed above, this results in a failure in test_pulse_freeparameter_condition
due to the name collision between the input parameter and the free parameter:
RuntimeError: Program has conflicting variables with name duration
C:\Miniconda3\envs\autoqasm-py39\lib\site-packages\oqpy\program.py:203: RuntimeError
E RuntimeError: in user code:
E
E File "C:\Repos\autoqasm\test\unit_tests\autoqasm\test_pulse.py", line 235, in my_program *
E if duration > duration2:
E File "C:\Repos\autoqasm\src\autoqasm\operators\comparisons.py", line 90, in gt_
E return _aq_gt(a, b)
E File "C:\Repos\autoqasm\src\autoqasm\operators\comparisons.py", line 101, in _aq_gt
E oqpy_program.set(result, a > b)
E File "C:\Miniconda3\envs\autoqasm-py39\lib\site-packages\oqpy\program.py", line 667, in set
E self._do_assignment(var, "=", value)
E File "C:\Miniconda3\envs\autoqasm-py39\lib\site-packages\oqpy\program.py", line 652, in _do_assignment
E to_ast(self, value),
E File "C:\Miniconda3\envs\autoqasm-py39\lib\site-packages\oqpy\base.py", line 529, in to_ast
E return item.to_ast(program)
E File "C:\Miniconda3\envs\autoqasm-py39\lib\site-packages\oqpy\base.py", line 417, in to_ast
E return ast.BinaryExpression(self.op, to_ast(program, self.lhs), to_ast(program, self.rhs))
E File "C:\Miniconda3\envs\autoqasm-py39\lib\site-packages\oqpy\base.py", line 529, in to_ast
E return item.to_ast(program)
E File "C:\Miniconda3\envs\autoqasm-py39\lib\site-packages\oqpy\classical_types.py", line 218, in to_ast
E program._add_var(self)
E File "C:\Miniconda3\envs\autoqasm-py39\lib\site-packages\oqpy\program.py", line 203, in _add_var
E raise RuntimeError(f"Program has conflicting variables with name {name}")
I'm not sure this is possible right now. I think it would be after the program refactor.
Right now, when we process statement arguments, such as
b
inif not b
, we check for FreeParameters in the statement and register them. This lets us supportif not FreeParameter("b")
. But it also means that when we process:then
b
attempts to be registered again -- and we don't have the type information at that point, so we assume it's a float. This would look like a type collision, but it's the same symbol we already saw.@speller26 ^ Another example of a use case for the program refactor, although it might be confusing without more context. Basically, we don't have a great way to actually track symbols. When I hit that symbol a new time, I can't tell if it's the same symbol or if it's shadowing the prev symbol.