[EMAIL PROTECTED] (Dan Sugalski) wrote on 12.04.01 in
<[EMAIL PROTECTED]>:
> At 12:16 AM 4/13/2001 +0200, Kai Henningsen wrote:
> >[EMAIL PROTECTED] (Dan Sugalski) wrote on 11.04.01 in
> ><[EMAIL PROTECTED]>:
> >
> > > *) All private routines have #defines to give them a _Perl_ prefix
> > > *)
On Thu, 12 Apr 2001, Dan Sugalski wrote:
> I think Perl_ and maybe Perl__ would be fine. I'd rather Perl_ and _Perl_,
> but...
How about PerlF_ and PerlD_ (for Functions and Data)?
To also specify Exported and Private we could have PerlFE_,
PerlFP, etc.
Coming back to the original question of whether its okay to have
convenience macros foo() to save typing perl_foo(),
I'm going to have one more go at arguing against it
We're all agreed that externally linked entities (functions and global
vars) need a perl_ prefix to avoid name clashes when
On Fri, Apr 13, 2001 at 04:05:05PM -0400, Dan Sugalski wrote:
> Okay, I think we're talking at cross-purposes at the moment.
>
> There are exactly 6 things that need prefixes added:
>
> 1) Functions that are explicitly exported as part of the API
> 2) Functions that are internal only, but we can
> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes:
NC> Presumably there are internal functions that aren't part of the
NC> public API, but because they are used in more than 1 source file
NC> do need external linkage. Or were your "linkers are dead-stupid"
NC> words meaning that we
At 10:24 PM 4/13/2001 +0100, Nicholas Clark wrote:
>On Fri, Apr 13, 2001 at 04:05:05PM -0400, Dan Sugalski wrote:
> > Okay, I think we're talking at cross-purposes at the moment.
> >
> > There are exactly 6 things that need prefixes added:
> >
> > 1) Functions that are explicitly exported as part
Okay, I think we're talking at cross-purposes at the moment.
There are exactly 6 things that need prefixes added:
1) Functions that are explicitly exported as part of the API
2) Functions that are internal only, but we can't stop being exported
because lots of linkers suck
3) Global data that w
At 01:21 PM 4/13/2001 +0200, Kai Henningsen wrote:
>[EMAIL PROTECTED] (Dan Sugalski) wrote on 12.04.01 in
><[EMAIL PROTECTED]>:
>
> > At 12:16 AM 4/13/2001 +0200, Kai Henningsen wrote:
> > >[EMAIL PROTECTED] (Dan Sugalski) wrote on 11.04.01 in
> > ><[EMAIL PROTECTED]>:
> > >
> > > > *) All priv
At 06:36 PM 4/12/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> The only difference between the aligned and unaligned runs is the
> DS> pointer to the aligned data is on an 8-byte boundary, and the
> DS> unaligned data is the aligned pointer p
On Fri, Apr 13, 2001 at 04:38:45PM -0400, Dan Sugalski wrote:
> It actually matters more for dynamic data structures, as compilers tend to
> queitly align things well for you. It's tough to get stack variables
> unaligned, but it's pretty easy to get dynamically allocated ones all messy.
At whi
> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes:
NC> On Fri, Apr 13, 2001 at 04:38:45PM -0400, Dan Sugalski wrote:
>> It actually matters more for dynamic data structures, as compilers
>> tend to queitly align things well for you. It's tough to get stack
>> variables unaligned, b
On Thu, 12 Apr 2001, Dave Storrs wrote:
> On Mon, 9 Apr 2001, Peter Scott wrote:
>
> > At 09:36 AM 4/9/01 +0200, Ariel Scolnicov wrote:
> > >
> > >One liners are supposed to be SHORT. `--cmd' is LONG. If we MUST go
> > >the multiflagged way, why not reflect `-e' to get the `-6' flag? At
> > >
> On Thu, 12 Apr 2001, Dave Storrs wrote:
> ...
> > We could then just add a -7 flag.
>
> Or, just use:
>
> #!/usr/bin/perl6
>
To solve this versioning issue, is there a way Perl 6 compiler can just
figure out what's being fed? I mean, without saying anything using options
or pragmas. There must
13 matches
Mail list logo
