square signatures

From: Zefram

Date: November 13, 2017 20:07

Subject: square signatures

Message ID: 20171113200700.GV4913@fysh.org

November 13, 2017 20:07square signatures

There is a change we could make to signature syntax, within the scope of the present experimental feature, which would have some value and which I think we should consider making. The change I propose is firstly that signatures should be delimited by square brackets instead of parentheses, and secondly that enabling signature syntax should not disable the short prototype syntax. Under this arrangement we would see things like: use feature "signatures"; sub add [$x, $y] { $x + $y } # signature sub my_rand (;$) { rand($_[0] || 5) } # prototype sub mul ($$) [$x, $y] { $x * $y } # prototype and signature Why do this? Because a perennial problem around signatures has been confusion between signatures and prototypes. A lot of the proposals for signatures suffered from treating them as a funny kind of prototype. If implementors couldn't keep them straight, we can't expect users to be clear about them. The confusion largely arises from them having some syntactic similarity, so much that they actually clash and so we needed to disable one syntax when the other is enabled. Brackets in place of parens make signatures very visually distinct from prototypes, which would probably be a big help in keeping them mentally distinct. A side benefit is that signature syntax would no longer clash with short prototype syntax, so we would have no need to disable the latter. We didn't consider this at the time of the original development of signatures because no one thought of it. The quick consensus we had on the basic features was built on an an assumption that the delimiters would be parens, based on nothing more than that being the usual arrangement in other languages. The consensus also incorporated an unambiguous and technically simple way to distinguish the syntaxes. It wasn't until confusion became evident after implementation that I started thinking "wish we'd made them more syntactically distinct, delimited them with square brackets or something". Since then my line of thought has gradually solidified to the position that I think there's real benefit in obvious non-clashing syntax, and that brackets are probably the best way to do it. If brackets are too weird, there are other options for distinguishing them such as sticking a "+" before the opening paren. The downside is that with parens still being the main delimiters the degree of visual distinction is much lower. In summary, pros: * can immediately see whether you're looking at a prototype or a signature, not having to consider pragmata * prototype and signature more mentally distinct * nicer syntax for prototypes when signatures are enabled * enabling signature syntax (in one file, or as a "use 5.030" bundle) doesn't break the old prototype syntax in existing code * documentation that gives examples using prototypes doesn't need any complexification Cons: * looks a bit weird * all existing signature-using code (which either emits or explicitly muffles a "signatures are experimental" warning) needs to change Let the opinions flow. -zefram



