Front page | perl.perl5.porters |
Postings from May 2021
Re: Namespaces (was Re: Revisiting trim)
Thread Previous
|
Thread Next
From:
Aaron Priven
Date:
May 28, 2021 18:19
Subject:
Re: Namespaces (was Re: Revisiting trim)
Message ID:
38B885B3-C8CC-4A1D-8274-A589DE1507AF@priven.com
Hiding functions behind a namespace just makes an artificial distinction between “functions Larry Wall thought of in 2002” and “functions his successors thought of since then.” It makes it harder for people to actually use those functions.
It is good to add new functions; they’re useful! They show that the language is improving! When hidden by a feature flag the actual backward compatibility issues are minimal. (People can’t blindly add “use 5.36” to their old code…is this really an issue?)
If things need to be hidden behind a namespace, the namespace should be something short like “_” or maybe “p” (for perl), and there should be just one of them, so we don’t have pointless arguments about whether “any” should go under “list::” (since it takes a list) or “bool::” (since it returns a boolean). And all those functions should be listed in perlfunc and not hidden away.
--
Aaron Priven, aaron@priven.com, www.priven.com/aaron
> On May 28, 2021, at 2:27 AM, demerphq <demerphq@gmail.com> wrote:
>
> On Thu, 27 May 2021 at 19:20, Neil Bowers <neilb@neilb.org> wrote:
>>
>> Hi Yves,
>>
>> But I really really appeal to those in charge these days to addressthis issue of where new functional (not control) keywords go and howit can be done in a forwards and backwards compatible way (meaning usefeature is out).
>>
>>
>> We’ve added this to the agenda for this week’s meeting, under "namespaces".
>>
>> That will start the ball rolling, and is an opportunity for people to share any well-formed thoughts on this matter.
>
> I would like to separate my thoughts into two categories.
>
> The first concerns the namespaces themselves. On this subject I dont
> have a strong opinion, I lean towards "scalar" over "string", but I
> know the internals and newbies don't and overall I don't actually care
> too much provided the namespaces are well thought out and somewhat
> "coherent". Eg, for me "scalar", "array", "hash", "reference", "list"
> etc are a consistent and cohesive definition, if somewhat arbitrary
> and maybe coarse grained. "string" sounds ok, but what do you do for
> numbers, some numeric things maybe should be in "math", others in
> "num" maybe? And then you have functions oriented towards operating on
> perl primitives and its type system, Eg you could argue that the
> entire Ref::Util should be built in, as should the entire Scalar::Util
> and List::Util, so where would you put them. We have prior art with
> 'utf8', 're'. Anyway, to me I think you could argue about the perfect
> set of namespaces, and ultimately this is a "perfect is the enemy of
> good enough" case, nearly any sane categorization would probably be
> fine. Just keep the outliers in mind, eg, where should utf8::downgrade
> go in the new scheme if it werent where it is? Where would the 're'
> special functions go? (regexp_pattern) What about the functions for
> locking hashes that live in Hash::Util, arguably they should be built
> in too, what namespace would/should they go into? For me the main
> point is here is that we agree "no more unnecessary new changes to the
> default language, new functions must go into a namespace if they can",
> the exact namespaces chosen is less important to me provide it
> "works".
>
> The second category is how they are added to the language. I care
> about this a lot more than the namespaces we use. I don't think we
> should use the as currently implemented "feature" mechanism for these
> keywords, and I think we should think carefully about choosing
> implementations that cannot be provided in a transparently backwards
> compatible way. What I would like is that we can somehow say:
>
> use keyword "string::trimmed" => "trimmed"; # it would be nice if
> we could use "as" instead of "=>" here, but it wouldnt be back-compat
>
> and have keyword do the magic of determining if we are on a perl that
> contains string::trimmed and exports it as "trimmed", and if we are
> not, it loads the module which "supplies" string::trimmed (and which
> is responsible installing trimmed into the "string" namespace), and
> then does the require export.
>
> If someone does
>
> use keyword "string::trimmed";
>
> it simply ensures that string::trimmed is available, eg no import into
> the current namespace.
>
> On a perl new enough where they *knew* it had "string:trimmed" they
> could write perl -e'print string::trimmed(...)' just like they
> currently can for anything defined in universal.c
>
> The purpose of the "keyword" pragma would be to declare that you need
> a given built in to be there, and to provide a way that we can provide
> back-compat machinery that can fake it up so that things work all the
> way back to 5.6 if we wanted.
>
> This would not render "feature" obsolete, changes to the control
> structures of perl, new operators for instance as opposed to
> functions, or new control structures would be triggered by feature.
>
> I believe that the perl docs have specified that single word lower
> case pragamatta names are reserved for Perl internals use. Adding a
> new "keyword" pragma and the required logic to do this would be pretty
> straightforward, for most of us on this list I imagine it would take
> us less time to code it up than it would to reply to this mail. :-)
>
> With this I feel we would be backwards and forwards compatible. Any
> time we added a new keyword function like trimmed() we could implement
> its backcompat as well, and that backwards compat layer would work as
> far back as we wish.
>
> Done nicely we could have the "keyword" pragmatta produce nice errors like this:
>
> "this version of 'keyword' does not recognize "string::trimmed",
> either there is no such keyword or you should upgrade your version of
> the 'keyword' module."
> "you need to install Perl::Keyword::string::trimmed to supply the
> "string::trimmed" keyword for this version of perl"
>
> If the keyword module is a dual lifed module, then we can have our
> cake and eat it too. By using segregated namespaces we dont pollute
> main::, we can make functions available in one liners by fully
> qualified function call syntaxt, we have a clean way to declare and
> request the keywords we want, and how we want to address them in our
> namespace, and we have a clean way to write plug ins for back compat.
> Done right this would make it easy to deal with dependencies in a
> distribution, you could simply declare the list of Perl::Keyword::
> modules you depend on, and it would Just Work on all versions.
>
> NOTE: an observation, if we want to supply seamless back-compat then
> we should eschew implementation choices that cant be implemented in a
> backwards compatible way. For instance in the trimmed() proposal to
> provide an efficient inline modification the patch is using compiler
> optimizations to determine the target is the same as the argument, if
> I am correct that this is not something you can do in an XS module
> alone then we should think carefully. Code that is optimized on a
> modern perl might end up quadratic on an older one. In such a case it
> might be better to make the inplace (and optimal trim strategy) case
> occur in void context alone. This is obviously debatable, you could
> argue we do "best effort back compat" and that we should be able to
> implement the back compat shims as pure perl modules. So long as the
> policy is clear and consistent it doesnt matter I guess. I lean
> towards maximum back-compat.
>
> My point here is perl already has a more or less usable mechanism for
> adding new functions to language, namespaces, and it has all the
> machinery needed to add new ones to the core in modern perls and still
> provide a shim layer that makes them available in older perls. The
> "use feature" api is bound to perl version, and doesnt provide any
> machinery for adding back-compat shims. It also doesnt have existing
> logic for mapping functions in one namespace into another. I think a
> new way to manage these new functions would make a lot of the issues
> and acrimony about them go away. a clean and clear rule:
>
> "new functions are added to the perl core via the 'keyword' frame,
> which means population into the appropriate reserved namespace, and
> providing a back compat layer for keyword, and patches to the
> keyword.pm module itself, and releasing that as a dual life module".
>
> My $0.02
>
> Yves
>
>
>
>
>
>
>
> --
> perl -Mre=debug -e "/just|another|perl|hacker/"
>
Thread Previous
|
Thread Next