Perl_foo() vs foo() etc
I'm in the middle of drafting the PDD on coding conventions, and in the bit on naming things, I've run into the Perl 5 stuff that does #define foo Perl_foo etc. Its not clear to me whether this is for backwards compatibility or for convenience (or for something even more fiendish related to per thread objects etc). So my question is: in Perl 6 we clearly want externally linked functions and variables to have a unique prefix, but do we also want shorter aliases, either in core or elsewhere? My instinct is to say no, at the risk of making all the perl internals slightly more verbose. For that matter, we could insist that all macros and public structs typedefs etc have a standard prefix too. This happily avoids all possible clashes with system and other header files, but would involve an awful lot more typing :-( Opinions, anyone ? Dave.
Re: Perl_foo() vs foo() etc
At 11:04 AM 4/11/2001 +0100, Dave Mitchell wrote: >I'm in the middle of drafting the PDD on coding conventions, >and in the bit on naming things, I've run into the Perl 5 stuff >that does > >#define foo Perl_foo > >etc. > >Its not clear to me whether this is for backwards compatibility or for >convenience (or for something even more fiendish related to per thread >objects etc). Both, really. The problem with perl 5 (though it's arguably caused by a Unix linker deficiency) is that there is no real API/internals line, and all the functions from inside perl get exported to the world. This causes a big problem when you link in extensions that link to other libraries, since they tend to export routines with the same name and you get clashes when linking. (Or worse, have to use both perl's foo() and your library's foo() routine) >My instinct is to say no, at the risk of making all the perl internals >slightly more verbose. My inclination is the opposite. In fact, what I'd propose is: *) All exported perl functions and functionlike things have a Perl_ prefix *) All exported data and dataish thigns have a PL_ prefix *) All private routines have #defines to give them a _Perl_ prefix *) All private data have #defines to give them a _PL_ prefix *) Internal data and functions get referenced via the unqualified names That way the internals can use the utility function str_to_UTF(), while the world would see it (or, rather, not see it) as _Perl_str_to_UTF(). Less typing for private things, and more for the much smaller (and probably not used internally) set of public functions. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl_foo() vs foo() etc
On Wed, 11 Apr 2001, Dan Sugalski wrote: > *) All exported perl functions and functionlike things have a Perl_ prefix > *) All exported data and dataish thigns have a PL_ prefix > *) All private routines have #defines to give them a _Perl_ prefix > *) All private data have #defines to give them a _PL_ prefix > *) Internal data and functions get referenced via the unqualified names > That way the internals can use the utility function str_to_UTF(), while the > world would see it (or, rather, not see it) as _Perl_str_to_UTF(). But think also about embedding applications. If you want to embed perl into another program that has its own str_to_UTF() function, then #include "myprogram.h" #include /* ... */ str_to_UTF(); may get inadvertantly stuck with _Perl_str_to_UTF(). Offhand, I see at least three possible approaches: 1. Don't ever have short names. (Yuck, lots of typing, but that's ultimately how we got in the perl5 state). 2. Don't have the #defines #included by by default (or have them only set #ifdef PERL_CORE or some such). 3. Provide an unembed.h that un-does all those defines #include "myprogram.h" #include #include Of course _that_ could still collide with a #define for str_to_UTF() in myprogram.h, though this is starting to get less likely. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Perl_foo() vs foo() etc
Okay, I may be slow, but I make mistakes. Why 3 & 4 below? Having the bare names doesn't solve any of the linking/clobbering issues, and why have #defines giving public names to routines you're not exporting? This isn't to bypass the 'leading underscore' reservation, is it? On Wednesday 11 April 2001 10:29, Dan Sugalski wrote: > My inclination is the opposite. In fact, what I'd propose is: > > *) All exported perl functions and functionlike things have a Perl_ prefix > *) All exported data and dataish thigns have a PL_ prefix > *) All private routines have #defines to give them a _Perl_ prefix > *) All private data have #defines to give them a _PL_ prefix > *) Internal data and functions get referenced via the unqualified names > > That way the internals can use the utility function str_to_UTF(), while the > world would see it (or, rather, not see it) as _Perl_str_to_UTF(). Less > typing for private things, and more for the much smaller (and probably not > used internally) set of public functions. > > Dan > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even > teddy bears get drunk -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Perl_foo() vs foo() etc
At 10:48 AM 4/11/2001 -0400, Andy Dougherty wrote: >On Wed, 11 Apr 2001, Dan Sugalski wrote: > > > *) All exported perl functions and functionlike things have a Perl_ prefix > > *) All exported data and dataish thigns have a PL_ prefix > > *) All private routines have #defines to give them a _Perl_ prefix > > *) All private data have #defines to give them a _PL_ prefix > > *) Internal data and functions get referenced via the unqualified names > > > That way the internals can use the utility function str_to_UTF(), while > the > > world would see it (or, rather, not see it) as _Perl_str_to_UTF(). > >But think also about embedding applications. If you want to embed perl >into another program that has its own str_to_UTF() function, then > > #include "myprogram.h" > #include > /* ... */ > str_to_UTF(); > >may get inadvertantly stuck with _Perl_str_to_UTF(). No. That's because you won't include perl.h when you embed perl in your app--you'll include something like per/embed.h or perlembed.h that has just the definitions for the bits perl exports for embedding. The embedding app will have access to _Perl_str_to_UTF if it chooses to call it (adding in the proper definitions, since they won't be there for it) but the #define that added the _Perl_ prefix won't be around. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl_foo() vs foo() etc
At 10:46 AM 4/11/2001 -0400, Bryan C. Warnock wrote: >Okay, I may be slow, but I make mistakes. Why 3 & 4 below? >Having the bare names doesn't solve any of the linking/clobbering issues, >and why have #defines giving public names to routines you're not exporting? It does fix the link issues, though. perl6.so won't ever have an unqualified function in it--they'll all have either a Perl_ or _Perl_ prefix on them, and all global data will have a PL_ prefix on it. Whether you can use the routines unqualified or not depends on whether you're in core code (with the core headers) or in extension or embedding code (presumably using the perlextend.h or perlembed.h headers) >This isn't to bypass the 'leading underscore' reservation, is it? Nah, not really. >On Wednesday 11 April 2001 10:29, Dan Sugalski wrote: > > My inclination is the opposite. In fact, what I'd propose is: > > > > *) All exported perl functions and functionlike things have a Perl_ prefix > > *) All exported data and dataish thigns have a PL_ prefix > > *) All private routines have #defines to give them a _Perl_ prefix > > *) All private data have #defines to give them a _PL_ prefix > > *) Internal data and functions get referenced via the unqualified names > > > > That way the internals can use the utility function str_to_UTF(), while the > > world would see it (or, rather, not see it) as _Perl_str_to_UTF(). Less > > typing for private things, and more for the much smaller (and probably not > > used internally) set of public functions. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl_foo() vs foo() etc
Okay, I *really* may have missed something Do you mean this: /* Allow us to refer to _Perl_foo() as just foo() inside */ #define _Perl_foo foo or this: /* We're foo(), other folks can call us _Perl_foo() */ #define foo _Perl_foo The second is what I read from your list, although the first seems like more what you're talking about. > > > *) All exported perl functions and functionlike things have a Perl_ > > > prefix *) All exported data and dataish thigns have a PL_ prefix > > > *) All private routines have #defines to give them a _Perl_ prefix > > > *) All private data have #defines to give them a _PL_ prefix > > > *) Internal data and functions get referenced via the unqualified names > > > > > > That way the internals can use the utility function str_to_UTF(), while > > > the world would see it (or, rather, not see it) as _Perl_str_to_UTF(). > > > Less typing for private things, and more for the much smaller (and > > > probably not used internally) set of public functions. > -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Perl_foo() vs foo() etc
At 11:00 AM 4/11/2001 -0400, Bryan C. Warnock wrote: >Okay, I *really* may have missed something > >Do you mean this: > >/* Allow us to refer to _Perl_foo() as just foo() inside */ >#define _Perl_foo foo > >or this: > >/* We're foo(), other folks can call us _Perl_foo() */ >#define foo _Perl_foo > >The second is what I read from your list, although the first seems like more >what you're talking about. The second is the one I'm talking about. > > > > *) All exported perl functions and functionlike things have a Perl_ > > > > prefix *) All exported data and dataish thigns have a PL_ prefix > > > > *) All private routines have #defines to give them a _Perl_ prefix > > > > *) All private data have #defines to give them a _PL_ prefix > > > > *) Internal data and functions get referenced via the unqualified names > > > > > > > > That way the internals can use the utility function str_to_UTF(), while > > > > the world would see it (or, rather, not see it) as _Perl_str_to_UTF(). > > > > Less typing for private things, and more for the much smaller (and > > > > probably not used internally) set of public functions. > > > >-- >Bryan C. Warnock >[EMAIL PROTECTED] Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl_foo() vs foo() etc
On Wed, 11 Apr 2001, Dan Sugalski wrote: > No. That's because you won't include perl.h when you embed perl in your > app--you'll include something like per/embed.h or perlembed.h that has just > the definitions for the bits perl exports for embedding. Ah, ok. That's a change from perl5 practice, but probably a good one. It's worth noting explicitly in the appropriate PDD. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Perl_foo() vs foo() etc
At 12:05 PM 4/11/2001 -0400, Andy Dougherty wrote: >On Wed, 11 Apr 2001, Dan Sugalski wrote: > > > No. That's because you won't include perl.h when you embed perl in your > > app--you'll include something like per/embed.h or perlembed.h that has > just > > the definitions for the bits perl exports for embedding. > >Ah, ok. That's a change from perl5 practice, but probably a good >one. It's worth noting explicitly in the appropriate PDD. Good point. Folks are going to assume we're doing things the perl 5 way unless we specify otherwise. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl_foo() vs foo() etc
On 4/11/01 10:55 AM, Dan Sugalski wrote: > It does fix the link issues, though. perl6.so won't ever have an > unqualified function in it--they'll all have either a Perl_ or _Perl_ > prefix on them, and all global data will have a PL_ prefix on it. Remind me again why it's PL_ and not PERL_? It seems to me that PL_ has *got* to be used somewhere in the wide world of code. (Isn't it a country code?) Maybe I'm being too paranoid, but Perl has basically staked out the letters "p e r l", whereas "PL" is probably still up for grabs. The last thing we need is some whizzy new product exploding into the "PL" moniker in 2003 and creating weird new embedding problems. PERL_ also matches up nicely with _Perl_ and Perl_, of course. What are two characters worth? ;) -John
Re: Perl_foo() vs foo() etc
At 03:09 PM 4/11/2001 -0400, John Siracusa wrote: >On 4/11/01 10:55 AM, Dan Sugalski wrote: > > It does fix the link issues, though. perl6.so won't ever have an > > unqualified function in it--they'll all have either a Perl_ or _Perl_ > > prefix on them, and all global data will have a PL_ prefix on it. > >Remind me again why it's PL_ and not PERL_? Well, Perl_ and PERL_ won't work, since that's relying on case-sensitivity in the various linkers, which is a Bad Thing. Having Perl_ and PL_ to separate code and data is in there mainly to make separating things programmatically easier. We could, I suppose, make everything Perl_ and have a config file somewhere with the type (data/code/whatever) indicated. That's probably the best thing--since we're exporting only a reasonably few things, and only explicitly, it ought to be OK. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl_foo() vs foo() etc
On Wed, Apr 11, 2001 at 04:38:21PM -0400, Dan Sugalski wrote: > At 03:09 PM 4/11/2001 -0400, John Siracusa wrote: > >On 4/11/01 10:55 AM, Dan Sugalski wrote: > > > It does fix the link issues, though. perl6.so won't ever have an > > > unqualified function in it--they'll all have either a Perl_ or _Perl_ > > > prefix on them, and all global data will have a PL_ prefix on it. > > > >Remind me again why it's PL_ and not PERL_? > > Well, Perl_ and PERL_ won't work, since that's relying on case-sensitivity > in the various linkers, which is a Bad Thing. Having Perl_ and PL_ to > separate code and data is in there mainly to make separating things > programmatically easier. We could, I suppose, make everything Perl_ and > have a config file somewhere with the type (data/code/whatever) indicated. > > That's probably the best thing--since we're exporting only a reasonably few > things, and only explicitly, it ought to be OK. I would say that everything could/should be hidden behind code, no naked exported data if at all possible. As far as the code is concerned, keeping the number of arguments small and preferring pointers (to structs or void) instead of a list of naked native types helps portability and extensibility. The distinction between public/embedding/private APIs also needs to be followed fervently. > Dan > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even > teddy bears get drunk -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Perl_foo() vs foo() etc
On 4/11/01 4:38 PM, Dan Sugalski wrote: > At 03:09 PM 4/11/2001 -0400, John Siracusa wrote: >> On 4/11/01 10:55 AM, Dan Sugalski wrote: >>> It does fix the link issues, though. perl6.so won't ever have an >>> unqualified function in it--they'll all have either a Perl_ or _Perl_ >>> prefix on them, and all global data will have a PL_ prefix on it. >> >> Remind me again why it's PL_ and not PERL_? > > Well, Perl_ and PERL_ won't work, since that's relying on case-sensitivity > in the various linkers, which is a Bad Thing. D'oh! Hadn't thought of that... > Having Perl_ and PL_ to separate code and data is in there mainly to make > separating things programmatically easier. We could, I suppose, make > everything Perl_ and have a config file somewhere with the type > (data/code/whatever) indicated. Well, that does sound a bit harder. Maybe I'm crazy, but I just keep seeing that "PL" product/technology/language/dessert-topping/floor-wax coming along and messing things up. And its kind of like domain names: how many two-letter combinations aren't already taken? > That's probably the best thing--since we're exporting only a reasonably few > things, and only explicitly, it ought to be OK. Cool beans :) ;) -John
Re: Perl_foo() vs foo() etc
At 03:47 PM 4/11/2001 -0500, Jarkko Hietaniemi wrote: >On Wed, Apr 11, 2001 at 04:38:21PM -0400, Dan Sugalski wrote: > > At 03:09 PM 4/11/2001 -0400, John Siracusa wrote: > > >On 4/11/01 10:55 AM, Dan Sugalski wrote: > > > > It does fix the link issues, though. perl6.so won't ever have an > > > > unqualified function in it--they'll all have either a Perl_ or _Perl_ > > > > prefix on them, and all global data will have a PL_ prefix on it. > > > > > >Remind me again why it's PL_ and not PERL_? > > > > Well, Perl_ and PERL_ won't work, since that's relying on case-sensitivity > > in the various linkers, which is a Bad Thing. Having Perl_ and PL_ to > > separate code and data is in there mainly to make separating things > > programmatically easier. We could, I suppose, make everything Perl_ and > > have a config file somewhere with the type (data/code/whatever) indicated. > > > > That's probably the best thing--since we're exporting only a reasonably > few > > things, and only explicitly, it ought to be OK. > >I would say that everything could/should be hidden behind code, no naked >exported data if at all possible. I was generally dividing things up into code stuff (macros and function calls) and data stuff (typedefs, structs, and maybe pointers to things). I agree that we shouldn't expose any of our internal data >As far as the code is concerned, keeping the number of arguments small >and preferring pointers (to structs or void) instead of a list of >naked native types helps portability and extensibility. Speed, too, at least a little bit. >The distinction between public/embedding/private APIs also needs to be >followed fervently. And violently. I fully intend to use both VMS' "If it's not explicitly exported you can't see it" linker complaints along with scans of exported symbols on some of the Unix platforms to keep this in check. If anyone knows of a portable (or at least semi-portable) way to restrict what symbols get exported in shared libraries on Unix systems, I'm all for using it. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
