Agree completely. Despite my reasoned comfort with Go’s rationale I miss quite a few “but I want to express this algorithm beautifully for the ages” features. I don’t miss the ternary syntax but miss the natural way to say “it is an assignment, first, but subject to logic, second.” Same as I miss do...until/while, because the trivial workaround obscures the logic and I feel I’ve cheated the reader. Likewise, I lay out structs so the variable width parts (strings say) will be last so that the initializer will look as non-bad as possible after gofmt. I understand the trade off, but wish the literate style and beauty of mathematical typography had a better friend in go.
On Sat, Apr 27, 2019 at 10:19 AM <charles.fors...@gmail.com> wrote: > Ada originally followed BCPL and Pascal in distinguishing between commands > (statements) and expressions, compared say to Algol68 which was an > expression language. > BCPL had VALOF/RESULTIS to link the two realms. It also had a conditional > expression (A -> B, C) with the same meaning as B's and C's later (A? B: C) > [which is probably better syntax]. > Neither Pascal nor Ada had conditional expressions, for different reasons. > > Ada has since added both "if" and "case" as conditional expression forms > (including "elseif"). There's a discussion in the 2012 Rationale: > http://www.ada-auth.org/standards/12rat/html/Rat12-3-2.html A big reason > for introducing them was to support writing preconditions and > postconditions. > there are quantifying expressions as well (ie, "for all", "for some"). > Originally, they were > special pragmas in the SPARK subset but were finally promoted to be part > of the language. > > Following the discussion above, I'd note though that one difference > between (say) > > if a > b { > m = a > } else { > m = b > } > > and > m := b > if a > b { > m = a > } > is that the former emphasises that the two cases (assignments) are > mutually exclusive (m is either a or it is b), as opposed to (m is b unless > it then becomes a), > not very interesting here but there can be more complex cases. > > In converting a C# program to Go I've had a few instances where converting > to if/else was clumsier or even more obscure, often it seems in > constructors converted to struct literals, > but in practice it's a minor point. As someone observed, sometimes little > helper functions restore the flow and improve clarity (count!=0? > total/count: 0) => avg(total, count) > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
