On Mon, Mar 14, 2005 at 08:10:15AM -0600, Patrick R. Michaud wrote:
: I ran into this problem while creating a mini-list of S29 functions
: (which Rod's work supercedes, I suspect, and I'm very glad he's taking
: this on). What are some guidelines we could use in deciding
: which functions are automatically in ::* ? Or is this just a case
: where we need to use past experience and best guesses as our guide?
You have the irritating habit of asking good questions I don't have
an easy answer for. Please don't stop.
Thinking about it a bit, it really comes down to an issue of
pragmatics in the linguistic sense. The question is, if you glance
at any particular function foo(), does it immediately pop into your
head that this is probably a cultural meme, or does it sort of lazily
evaluate to the possibility of a cultural meme. So by this main
criterion, abs() is almost certainly the absolute value meme (unless
you're at the gym), while dump() doesn't really mean much to people
because it's too heavily overloaded.
There are going to be several secondary criteria that modify the main
criterion:
* Sometimes we want to force a particular meme into the foreground.
By the main criterion lock() isn't specific enough to be a keyword,
but we can choose to force it to mean one thing. The fact that all
such functions are the equivalent of Perl 5's 3rd-class keywords
makes this easier, since the user can still override the meaning of
lock() if they want to. (Or abs() for that matter.)
* Another confounding factor is that memes tend to come in bundles,
and you'd kind of like to keep the bundles together. So my earlier
question really amounted to whether POSIX was really a valid
bundle of memes. (Probably not.) On the other hand, the trig
functions might well be a valid bundle, and we might want to
keep them all together either in * or Trig.
* On the other hand, maybe some meme bundles deserve to be split up
into two bundles by the main criterion, with one bundle going into *
and the other into Trig (or whatever). Arguably sin and cos are
instantly recognizable, but the lesser known trig functions are
more debatable. But these are all fuzzy boundaries, and people
will see the boundaries in different places.
* We're really talking about a three-way distinction here. In the
middle we have the functions that are imported by default when
you say "use Trig" rather than "use Trig :all". There are some
folks who would argue well-formed modules should never export any
names by default, so that "use Trig" *only* makes sure that the
Trig module is available, and you'd have to say "use Trig :default"
or some such to get the default set. But that's just giving
the middle memes a different collective name.
* We do in fact have mechanisms for overriding any core feature,
and we don't want Perl to turn into a language where you have
to import a bunch of essential stuff at the top, it basically
argues that in case of doubt, we should throw it into the core.
We'll also have MMD to sort things out, so as long as things are
well-typed, we shouldn't fall into a PHP function-name hell.
* Backward compatibility with Perl 5 decisions certainly influences
what Perl 5 programmers will expect, but not necessarily newcomers
to Perl. We'll have to decide how to balance those where Perl 5
got it "a little wrong".
The upshot of all this is that, as you suspected, this is something
we'll just have to work out as a community. What we can do right
now is tell people not to be surprised when we move things around,
and that we'll feel free to move things around until 6.0.0 is about to
go golden. But maybe we could try to set some slushiness milestones
on the road to hell freezing over...
Larry
