Support Dereferenced Function/Method Returns in Grammar

[engineerjoe440]

Related Issues

• Dereferenced Variables in Function Calls Not Parsing Correctly #57

Changes

• Added optional dereference (^) character to function and method call (return) statements.

Closing Thoughts

These changes should make this all a bit more convenient, and should allow for syntax such as:

uut.call1()^.call2(A := 1).call3(B := 2)^.call4().done();

Which can allow for chained method calls using dereferences on any returned pointers.

[codecov-commenter]

Codecov Report

Merging #59 (f214d07) into master (8988e2e) will increase coverage by 0.3%.
The diff coverage is 100.0%.

Additional details and impacted files

@@           Coverage Diff            @@
##           master     #59     +/-   ##
========================================
+ Coverage    72.3%   72.6%   +0.3%     
========================================
  Files          18      18             
  Lines        3797    3806      +9     
========================================
+ Hits         2746    2764     +18     
+ Misses       1051    1042      -9     

Impacted Files	Coverage Δ
blark/tests/test_transformer.py	100.0% <ø> (ø)
blark/transform.py	99.0% <100.0%> (+<0.1%)	⬆️

... and 1 file with indirect coverage changes

[klauer]

Thanks yet again @engineerjoe440!

My comments in the review are partly verbose notes-to-self/thinking aloud as usual.
The core of this is good; merging and calling this completed 👍

[klauer]

Looks like it's time to get rid of method_statement entirely.

function_call_statement (using function_call) handles everything it does and more, so having both just makes for ambiguity in the grammar.

I'll make an issue to remove it along with its related MethodStatement class.

[klauer]

Technically the remaining_parameters annotation needs updating here because it can now contain a lark.Token as well (holding that semi-colon ";"). Then static analyzers will complain that parameters is no longer compatible with List[ParameterAssignment], ...

Let's just roll with this and maybe clean it up later - there are much bigger fish to fry!

[engineerjoe440]

I think that's a fair point, though, @klauer... I had toyed with it, but decided the same about "bigger fish" (at least for this moment in time). Do you have thoughts on a better name? I'd be happy to lob something in there in upcoming changes.

[klauer]

I couldn't think of a way to express it in words - sometimes code is more succinct.
I think this might be preferable:

    @staticmethod
    def from_lark(
        name: SymbolicVariable,
        *params: Union[ParameterAssignment, lark.Token, None],
    ) -> FunctionCall:
        # Condition parameters (which may be `None`) to represent empty tuple
        if params and params[0] is None:
            params = params[1:]
        dereferenced = bool(params and params[-1] == "^")
        if dereferenced:
            params = params[:-1]

        return FunctionCall(
            name=name,
            parameters=typing.cast(List[ParameterAssignment], list(params)),
            dereferenced=dereferenced,
        )

[engineerjoe440]

OK! I'm gonna roll this in to the next bit of work I do. 👍