Front page | perl.perl5.porters |
Postings from November 2017
Re: square signatures
Thread Previous
|
Thread Next
From:
Leon Timmermans
Date:
November 14, 2017 20:38
Subject:
Re: square signatures
Message ID:
CAHhgV8iNxR04Oquom8HnEO5ToARCnc4QUGvxY5XYcQhe9PHLfw@mail.gmail.com
On Mon, Nov 13, 2017 at 9:07 PM, Zefram <zefram@fysh.org> 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
for.
Leon
Thread Previous
|
Thread Next