On Wed, Apr 30, 2008 at 07:29:58AM -0500, John M. Dlugosz wrote:
> I am listening. I'm synthesizing and documenting. I'm also disappointed
> with the lack of feedback from Larry, considering the amount of effort and
> time I'm putting into it. But I'm sure he'll squawk if I say something
> really off, rather than flesh out the existing skeleton.
Well, I mentioned before that I have very little bandwidth at the
moment, due to health and employment issues, plus needing to prepare
for a number of upcoming talks. (Not to mention stealing time to hack
on the STD grammar and longest-token matcher.) My only choice is to
operate in the bear-of-very-little-brain mode to see if any of this
will be remotely understandable to normal people. I can tell you my
uncomfy spots, but I haven't the energy to defend them at the moment.
First some nitpicky things.
I don't like using ::?CLASS for something that is not a compile-time
constant. The ? twigil is supposed to mean that, and that's why
we don't use ::?SELF anymore, but "self", because that can vary in
meaning dynamically. So I'd rather have a keyword or a pseudo-package,
if it's needed. Or a different twigil for generically instantiated
items, if it comes into common use, and gets applied to a variety
of names, neither of which is certain. But ::CLASS would be an
improvement over ::?CLASS, if we reserve that pseudo-package. Are
there other things that fall into the same twigilish category? Or
can they all be found via ::CLASS?
I don't like the indentation style that makes the closing quote look
like part of the contents of a block. You can do whatever you like
in your own papers, of course, but we've spent many years teaching
people in the Perl community to outdent their final curly so that
it means something, rather than hiding it on the end like it's an
embarrassing non-pythonism. So you'll get better acceptance of any
standards document if you follow that community standard.
The £ seems rather gratuitous from a language design point of view.
Every such symbol in a paper increases the number of people whose eyes
glaze over when they try to read it. I understand it's a placeholder,
but the current syntax can already express such a "like" constraint via:
$dog where .like(Goat)
We could also have syntactic relief for such a concept by making "like"
work like "where" syntactically:
$dog like Goat
On a more fundamental level, I wonder what the social ramifications
are. First, to what extent is this something that will interfere
with people who don't want to learn higher-order typing in order
to get their job done, but will be forced to because one of their
cohorts is using it, or the boss mandates it? And will Perl get
a Haskellian only-a-genius-can-use-it reputation because of that?
Second, is anybody actually going to implement it? We're pretty short
of volunteers as it is, and I don't think I'm smart enough to do it,
and I'm very, very slow to put anything into Perl that I don't know
how to implement.
Basically, I'm not a types person, historically speaking, so I'm
naturally a bit skeptical. But over the last few years I've seen some
of both the power and peril of strictly-typed FP. I'm interested in
making sure Perl 6 is close enough to supporting any paradigm that
it can be warped into full support of that paradigm in any lexical
scope, but I'm leary of any paradigm that starts sucking in all the
other lexical scopes into its sphere of influence whether they like
it or not. Compile-time typing tends to have that effect, and I'm
wondering how we avoid that problem.
> "isa" as a synonym for "is" that turns on warnings is documented at the end
> of my paper under "Concepts discussed in this paper that are not on the
> Synopses".
>From a language design point of view, having both "is" and "isa"
is a dreadfully powerful stink. Either something need to be unified,
or something needs to be better distinguished.
> Nobody's objected to it. In this group, I'm preaching to the
> choir anyway. Everyone knows higher-order typing is the idea, and I'm just
> trying to work out the ramifications and details that are in-tune with the
> orthodox documentation and discussions here.
That's fine, but please don't mistake the general silence for anything
other than people's eyes glazing over. If a fancy concept can't be
made easily understandable to the general public (or can't at least
be hidden from the general public beneath some cargo-cultable syntax),
it's not going into baseline Perl 6. I can be pretty clever at times,
but right now I'm standing up for Joe Blow, who doesn't give a rip
about orthodoxy. What's in it for him?
All that being said, I do like the fact that this whole effort is
exploring semantic niches that need to be fleshed out. I wish I had
time to think through the Perlish answers to some of these good
questions. I hope other people will continue to participate in
thrashing some of these things out.
Larry
