On Tue, Nov 05, 2002 at 05:13:45AM -0600, Me wrote:
> > relatively few subroutines need access
> > to the upscope topic.
>
> Well, this is a central issue. What are
> the real percentages going to be here?
> Just how often will one type the likes
> of
>
> -> is given($foo is topic) { ... }
>
> rather than
>
> -> $foo: { ... }
>
> ?
>
> My imagination suggests to me that in a
> typical short perl 6 script, between 20%
> and 50% of all sub defs would use the
> upscope topic... ;>
>
> Seriously, the functions chapter of Camel
> III contains 202 functions; 36 of these
> use the upscope topic.
The fact that accessing the upscope topic is common enough to be useful
is why we decided to provide an easy way to do it.
But compare that frequency to the frequency of addition.
> > Moreover, because ['is given'] compromises
> > the lexical scoping of the upscope topic,
> > it ought to be marked very clearly
>
> Yes.
Which is another reason why it shouldn't be too easy.
> So that gives an idea of what to expect --
> although there is likely to be /more/ use
> of tricks like this that support brevity
> when advanced coders specifically wish to
> write brief scripts.
>
> Unless of course the very syntax that
> creates /call/ brevity is itself so
> verbose that it neutralizes some of its
> utility in such cases, something that
> would be rather ironic, don't you think?
I don't consider the ability to write brief code to be the chief goal of
language design. One of the goals, sure. No one wants to type:
is the_property_that_provides_access_to_the_topic_in_the_callers_scope($foo is
the_current_topic_in_the_block)
But brevity is a lower goal than clarity and ease of maintenance. It's
a balance, like everything in language design (and life in general).
> > [keywords are clearer than punctuation for
> > marking something]
>
> I think that's overly general.
>
> In something that is as likely to be naturally
> keyword dense as a sub or method definition, I
> imagined the situation would be near reverse,
> i.e. well chosen punctuation would often be a
> better pick than YAK for marking something.
>
> (Maybe colon isn't it, but I didn't pick that.)
>
> Of course, in code written to be brief, sub
> defs would tend to be less keyword, but then
> again, in code written to be brief, brevity
> would again suggest punctuation.
>
> So perhaps punctuation wins in both cases;
> in large projects sub defs will be keyword
> dense and punctuation would better highlight
> "it" and in small scripts, punctuation in
> sub defs would be desirable for brevity.
It's a balance again. You can't just look at the one feature in
isolation and decide if it's better off as a keyword or punctuation. You
have to look at the whole language as a system and decide which features
most deserve punctuation. Even if we have the option of unicode
punctuation, moderation is still desirable. The logical extreme of a
language that prefers punctuation is something like:
$%(_^?.)*@!+-#&
I'm sure that's not what you meant, or what you want, but it illustrates
the point that more punctuation leads toward less clarity. Somewhere
between the insanity of all punctuation and the verbosity of no
punctuation lies the happy medium.
Allison
--
Punctuation is the spice of life.
