On 6/8/2017 6:28 PM, Rasmus Schultz wrote: >> it could be a single symbol instead of two > > even if this can be done without parser ambiguity, it suffers from visual > ambiguity with the assignment operator. > > consider what this would look like if the expression itself uses the > assignment operator... > > f($x) = $y = $y + $x; > > versus something like: > > f($x) => $y = $y + $x; > > even that is visually ambiguous when used in arrays though: > > $a = [ > "foo" => f($x) => $y = $y + $x, > ]; > > also unreadable. > > even if the parser can cope, I think we need some other symbol that isn't > visually ambiguous when used in these contexts? >
Absolutely, yes. One thing that could work is a combination of colon and equal sign with an optional type in between: f($x, &$y):= $y = $y + $x f($x, &$y): int = $y = $y + $x Still, kind of ambiguous if used with a type. Earlier I used the greater than sign only: f($x, $y)> $x > $y f($x, $y): bool > $x > $y As we can clearly see, also not optimal. A thing that should work is a hyphen greater than: f(object $o)->$o->property Looks weird without proper spacing, but with proper spacing ... f(object $o) -> $o->property ... it looks fine, imho. Of course, we still have the other options that were mentioned earlier already: f ~> 42 // bad on some keyboard layouts f ==> 42 // I personally do not like this option Another possibility is to use a keyword. This would definitely avoid symbol soup and help visual recognition: f do 42 f($x) do $x^3 f($x, &$y) do $y = $y + $x However, I am very unsure about this option to be honest. I'd say my choice here is `~>` but I'm on a US layout, second is `->`. Note that the latter is used in Java, Elixier, Erlang, Haskell, Julia, OCaml, F#, and probably others. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature