develooper Front page | perl.perl5.porters | Postings from November 2017

Re: square signatures

Thread Previous | Thread Next
Leon Timmermans
November 14, 2017 20:38
Re: square signatures
Message ID:
On Mon, Nov 13, 2017 at 9:07 PM, Zefram <> wrote:

> 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.

Quite frankly, I think that this is terrible language design. The current
syntax has one immense advantage: it's meaning is clear to anyone familiar
with pretty much any programming language. I quite frankly don't care about
the advantages for prototypes, they're clearly the wrong thing to optimize


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About