4 ms·
You're right. I did not explain that well enough. Even with sigils it is unclear whether qv_mult will take 1 or 2 arguments, or whether qq_mult will take 1, 2 o
by marpmarpmar 13y ago
You're right. I did not explain that well enough. Even with sigils it is unclear whether qv_mult will take 1 or 2 arguments, or whether qq_mult will take 1, 2 or 3. What is however clear is that only qq_mult and qv_mult are function calls, which it previously was not. Worse, what i did not mention then: When reading carefully it was easy to tell that they had to be function calls; however it was impossible to tell whether the two quaternions and the vector were variables, or function calls that did not take any arguments. Only with sigils becomes this clear.
- TylerE 13y agoI'm still unclear on what the dataflow is... is w set to the value of the qq_mult call and the rest just executed for side effects? Regardless, please defend how that is not just an improvement over, but better than, say: my $W = qq_mult $ConjugateQ, qv_mult $RotationQ, $Vector; w = qq_mult(qv_mult(CondugateQ, Vector)) or whatever the precedence and dataflow semantics are
- marpmarpmar 13y agoThat example doesn't show it very well. To be clear: The intended advantage is: Parens are optional. That permits syntax like the following to be implemented in pure Perl without changing the parser: try { die "foo"; } catch { warn "caught error: $_"; }; If parens were mandatory, it would need look like this: try( sub { die "foo"; } catch( sub { warn "caught error: $_"; } ) ); Having the nicer form in the first example is possible only because sigils are mandatory, along with auto-flattening variables and easy code highlighting. As for the example, with mandatory parens it would look like this: w = qq_mult( ConjugateQ, qv_mult( RotationQ, Vector ) ); In production i'd write it like this: my $W = qq_mult $ConjugateQ, qv_mult( $RotationQ, $Vector ); That gives a nice balance between a low number of parens, and clarity of intent.