Bryan C. Warnock writes:
> The librarian bounced, so sending this internals way.
Sorry about that bounce. It's set up now. I'm still setting
up the repository (should have done that *before* publishing the RFC
format, I guess :-). Optimistic ETA: tomorrow. If it's not up by
then, I'll fall ba
Sam Tregar <[EMAIL PROTECTED]> wrote:
> On Tue, 1 Aug 2000, John Tobey wrote:
>
> > The people here are rightly skeptical about the effectiveness of using
> > the 5.6 code base as a starting point for v6, but I have a pretty
> > clear vision of how to do it, and I am committed to giving it a try,
Tim Bunce writes:
> > >The word "pluggable" gives me the willies. I feel like things like
> > >REs should have one blessed implementation and set of capabilities.
>
> The key point here is *one blessed implementation*.
(nat as nat)
When I said that, I was keeping in mind that we might have mul
On Tue, 1 Aug 2000, John Tobey wrote:
> The people here are rightly skeptical about the effectiveness of using
> the 5.6 code base as a starting point for v6, but I have a pretty
> clear vision of how to do it, and I am committed to giving it a try,
> even if no one else will. In fact, I'll give
On Wed, Aug 02, 2000 at 12:16:33AM -0400, Dan Sugalski wrote:
> From a language perspective, I have a scheme to allow us to yank all the
> cruft (sockets, shm, messages, localtime...) out into separate libraries,
> yet pull them in on demand without needing a use.
Yep, yep. That's unquestionab
At 01:02 PM 8/2/00 +0900, Simon Cozens wrote:
>On Tue, Aug 01, 2000 at 11:37:49PM -0400, Dan Sugalski wrote:
> > Right. That was my point. (The original poster wanted to pull IO out of
> the
> > core entirely)
>
>Ah. Barbarians-at-gates approach, then.
Damn straight. Dump the boiling oil! :)
>O
On Tue, Aug 01, 2000 at 11:37:49PM -0400, Dan Sugalski wrote:
> Right. That was my point. (The original poster wanted to pull IO out of the
> core entirely)
Ah. Barbarians-at-gates approach, then. On the other hand, there is
a lot of rubbish that *can* go out of core; I'd like to see core being
At 06:35 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 05:55 PM 8/1/00 -0400, John Tobey wrote:
> > >Dan, you are completely missing my point. Okay, fine, non-inline may
> > >be a performance win in some cases. Inline may be a win in others. I
> > >am not pr
At 06:44 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > Bad assumption. How often is av_fill called?
>
>Only once in av_fill.c (generated by allfuncs.pl). In most other
>places, it's called as i_av_fill().
Nope. In perl 6, the internal and external APIs will be v
At 06:23 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 09:43 PM 8/1/00 +, Nick Ing-Simmons wrote:
> > >Nor am I sure that the XS API is not one of the things I would not
> > >have near top of the list for "internals cleanup":
> > >
> > >PUSHMARK;
> > >XPUSH
May I offer an alternative. Why do an interpreter?
I remember reading good things about Threaded Interpreters
(e.g. Forth) So why not do a TIL? Compile it to machine calls/jumps.
Should be much faster than the inner run loop.
This would fit in with Dan and Nick's keep it in cache.
So there cou
On Tue, 01 Aug 2000, Dan Sugalski wrote:
> At 11:57 PM 7/31/00 -0700, Matthew Cline wrote:
> >Something else which might be useful for tainting would be something like:
> >
> > taint_var($foo);
> > no_taint_var($bar);
> >
> >With this, any value assigned to $foo would become tainted, and a
The librarian bounced, so sending this internals way.
=head1 TITLE
Implementation of Threads in Perl
=head1 VERSION
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Date: 01 Aug 2000
Version: 1
Mailing List: perl6-internals
Number: TBD
=head1 ABSTRACT
Perl 6 should be bu
[EMAIL PROTECTED] wrote:
> John Tobey wrote:
>
> > > Why is he bothering? A year to produce a prototype doesn't seem like a
> > > useful way to expend effort on something that isn't actually perl6.
> >
> > It is actually perl6 if/when it's finished.
>
> Right, so it isn't a community effort th
John Tobey wrote:
> > Why is he bothering? A year to produce a prototype doesn't seem like a
> > useful way to expend effort on something that isn't actually perl6.
>
> It is actually perl6 if/when it's finished.
Right, so it isn't a community effort then, as you intend doing it all
yourself.
Nick Ing-Simmons wrote:
> I have said this before but the gist of the Nick-theory is:
>
> Page boundaries are a don't care unless there is a page miss.
> Page misses are so costly that everything else can be ignored,
> but for sane programs they should only be incured at "startup".
> (Reducing c
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> >> But is usually much easier add entropy - so start with its the same
> >> function - call it, and let compiler decide which ones to expand.
> >
> >You'll get no
John Tobey <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
>> But is usually much easier add entropy - so start with its the same
>> function - call it, and let compiler decide which ones to expand.
>
>You'll get no argument on that point. Please stop suggesting that I
>
> > Having thought about it a bunch more (because of this) I'm
> > proposing we let the compiler decide. The caller doesn't
> > know enough to make that decision.
>
> Read carefully. I said we *let* the caller decide, not *make* the
> caller decide. What, specifically, disturbs you about my
John Porter <[EMAIL PROTECTED]> writes:
>> On Tue, Aug 01, 2000 at 12:01:52AM -0400, John Tobey wrote:
>> >
>> > That's a different problem. Configure is trying to reverse engineer
>> > header files. Garrett already knows the prototype of his DLL function
>> > he wants to call, but, unlike Confi
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Bad assumption. How often is av_fill called?
Only once in av_fill.c (generated by allfuncs.pl). In most other
places, it's called as i_av_fill().
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 05:34 PM 8/1/00 -0400, John Tobey wrote:
> >Okay. For starters, assume that every inline function is called in
> >exactly one place in the translation unit that defines its non-inline
> >counterpart. That one place being, of course, i_foo's foo. This
> > I think you may have missed the context of the message.
> > John was talking about creating his Alpha using various
> > existing projects that had already been done in C++.
>
> Why is he bothering? A year to produce a prototype doesn't
> seem like a useful way to expend effort on somethi
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 05:55 PM 8/1/00 -0400, John Tobey wrote:
> >Dan, you are completely missing my point. Okay, fine, non-inline may
> >be a performance win in some cases. Inline may be a win in others. I
> >am not proposing we mandate inlining in any case, I am proposi
Alan Burlison <[EMAIL PROTECTED]> wrote:
> Brent Fulgham wrote:
>
> > > I think there is an undiscussed assumption about the implementation
> > > language in there somewhere...
> >
> > I think you may have missed the context of the message. John was talking
> > about creating his Alpha using va
At 05:34 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > ) Compaq C
> > will do it differently depending on the number of times that the inlined
> > function is used.
>
>Okay. For starters, assume that every inline function is called in
>exactly one place in the tr
At 05:55 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > > >Non-inline functions have their place in reducing code size
> > > > >and easing debugging. I just want an i_foo for every foo that callers
> > > > >will have the option of using.
> > > >
> > > > Before w
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> But is usually much easier add entropy - so start with its the same
> function - call it, and let compiler decide which ones to expand.
You'll get no argument on that point. Please stop suggesting that I
want to take the power of decision away from
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 09:43 PM 8/1/00 +, Nick Ing-Simmons wrote:
> >Nor am I sure that the XS API is not one of the things I would not
> >have near top of the list for "internals cleanup":
> >
> >PUSHMARK;
> >XPUSHs(sv_2mortal(newSVpv('DeepThought'));
> >XPUSHs(sv_2morta
Brent Fulgham wrote:
> > I think there is an undiscussed assumption about the implementation
> > language in there somewhere...
>
> I think you may have missed the context of the message. John was talking
> about creating his Alpha using various existing projects that had already
> been done in
John Tobey <[EMAIL PROTECTED]> writes:
>> Maybe not for void functions with no args, tail-called and with
>> no prefix, but in more typically cases yes it can be different
>> the "function-ness" of i_foo applies constaints on where args
>> and "result" are which optimizer _may_ not be able to unr
At 09:43 PM 8/1/00 +, Nick Ing-Simmons wrote:
>Nor am I sure that the XS API is not one of the things I would not
>have near top of the list for "internals cleanup":
>
>PUSHMARK;
>XPUSHs(sv_2mortal(newSVpv('DeepThought'));
>XPUSHs(sv_2mortal(newSViv(42));
>PUTBACK;
>count = perl_call_method("C
Brent Fulgham <[EMAIL PROTECTED]> wrote:
> > Alan Burlison wrote:
> >
> > John Tobey wrote:
> >
> > > 1 November 2000 - Perl6 alpha in C++ that uses classes derived
> > >from PerlInterpreter and SV
> > everywhere in place
> > >of these types,
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> By all means have a go at Topaz-II
>
> But it won't be 'Perl 6' unless it implements what perl-language
> decides that _is_.
Agreed. It won't even remotely resemble 'Perl 6' (as opposed to Perl
5) until it's in a position to start changing the lex
Alan Burlison <[EMAIL PROTECTED]> wrote:
> John Tobey wrote:
>
> > 1 November 2000 - Perl6 alpha in C++ that uses classes derived
> >from PerlInterpreter and SV everywhere in place
> >of these types, a la Pickle, but with inline
> >
At 09:25 PM 8/1/00 +, Nick Ing-Simmons wrote:
>Alan Burlison <[EMAIL PROTECTED]> writes:
> >
> >No, I disagree. Perl gains a lot of its expressive power from being lax
> >about typing. I suspect it will also impose an unacceptable overhed for
> >the vast majority who don't want it - at the v
> Alan Burlison wrote:
>
> John Tobey wrote:
>
> > 1 November 2000 - Perl6 alpha in C++ that uses classes derived
> >from PerlInterpreter and SV
> everywhere in place
> >of these types, a la Pickle, but with inline
> >m
John Tobey <[EMAIL PROTECTED]> writes:
>The people here are rightly skeptical about the effectiveness of using
>the 5.6 code base as a starting point for v6, but I have a pretty
>clear vision of how to do it, and I am committed to giving it a try,
>even if no one else will. In fact, I'll give you
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > >Non-inline functions have their place in reducing code size
> > > >and easing debugging. I just want an i_foo for every foo that callers
> > > >will have the option of using.
> > >
> > > Before we make any promises to do all that extra work can we
>
Nick Ing-Simmons wrote:
> Cross posted to internals ('cos it is...)
Be it on your head... ;-)
> We should consider using "vtables" to avoid the cost of the conditional
> branches (and running out of flag bits).
>
> Thus this function would call variables "type check" "method" -
> which for nor
John Tobey wrote:
> 1 November 2000 - Perl6 alpha in C++ that uses classes derived
>from PerlInterpreter and SV everywhere in place
>of these types, a la Pickle, but with inline
>methods that use Perl 5's internal API.
At 05:21 PM 8/1/00 -0400, John Tobey wrote:
>Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> > John Tobey <[EMAIL PROTECTED]> writes:
> > >Is foo() compiled any differently in
> > >
> > >inline i_foo() { BLA; BLA; BLA; }
> > >foo() { i_foo(); }
> > >
> > >versus
> > >
> > >foo() { BLA; B
On Tue, Aug 01, 2000 at 08:55:09PM +, [EMAIL PROTECTED] wrote:
> >Non-inline functions have their place in reducing code size
> >and easing debugging. I just want an i_foo for every foo that callers
> >will have the option of using.
>
> Before we make any promises to do all that extra work c
Alan Burlison <[EMAIL PROTECTED]> writes:
>
>No, I disagree. Perl gains a lot of its expressive power from being lax
>about typing. I suspect it will also impose an unacceptable overhed for
>the vast majority who don't want it - at the very least every variable
>access will have to check an 'are
On Tue, Aug 01, 2000 at 05:23:27PM +0200, Dominic Dunlop wrote:
> At 15:19 +0100 2000-08-01, Tim Bunce wrote:
> > >RegEx (internals?)
> >
> >Yes, Yes, Yes.
>
> I could argue for regex being language too:
> If the language group is
> going to give each of perl's reserved words (and much
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:55 PM 8/1/00 -0400, John Tobey wrote:
> >Well, I am going to assume you are wrong and the above two foo()
> >implementations will produce exactly the same code.
>
> Your assumption is incorrect for good compilers. (Whether gcc counts as
> good for
> On Tue, Aug 01, 2000 at 12:01:52AM -0400, John Tobey wrote:
> >
> > That's a different problem. Configure is trying to reverse engineer
> > header files. Garrett already knows the prototype of his DLL function
> > he wants to call, but, unlike Configure, he doesn't have access to a C
> > comp
On Tue, Aug 01, 2000 at 01:28:09PM -0400, Dan Sugalski wrote:
> At 11:01 AM 8/1/00 -0600, Nathan Torkington wrote:
> >The word "pluggable" gives me the willies. I feel like things like
> >REs should have one blessed implementation and set of capabilities.
The key point here is *one blessed imple
Sam Tregar <[EMAIL PROTECTED]> wrote:
> On Tue, 1 Aug 2000, John Tobey wrote:
>
> > I'm thinking of a rewrite in the sense that (by my impression) BSD was
> > a rewrite of Unix. Refactoring, shifting stuff around until it's easy
> > to get a handle on things, and replace it all a little at a tim
At 04:55 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 04:37 PM 8/1/00 -0400, John Tobey wrote:
> > >Is foo() compiled any differently in
> > >
> > > inline i_foo() { BLA; BLA; BLA; }
> > > foo() { i_foo(); }
> > >
> > >versus
> > >
> > > foo() { BL
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >Is foo() compiled any differently in
> >
> >inline i_foo() { BLA; BLA; BLA; }
> >foo() { i_foo(); }
> >
> >versus
> >
> >foo() { BLA; BLA; BLA; }
>
> Maybe not for void functions with no args, tail
John Tobey <[EMAIL PROTECTED]> writes:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> (FWIW, it seems on many of the modern
>> processors that inlining code decreases your performance, so I think
>> deciding on stuff like that is rather premature)
>
>Is foo() compiled any differently in
>
>inl
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:37 PM 8/1/00 -0400, John Tobey wrote:
> >Is foo() compiled any differently in
> >
> > inline i_foo() { BLA; BLA; BLA; }
> > foo() { i_foo(); }
> >
> >versus
> >
> > foo() { BLA; BLA; BLA; }
> >
> >?
>
> Probably. On many newer chips, the
At 04:37 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > (FWIW, it seems on many of the modern
> > processors that inlining code decreases your performance, so I think
> > deciding on stuff like that is rather premature)
>
>Is foo() compiled any differently in
>
>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> (FWIW, it seems on many of the modern
> processors that inlining code decreases your performance, so I think
> deciding on stuff like that is rather premature)
Is foo() compiled any differently in
inline i_foo() { BLA; BLA; BLA; }
foo() { i_fo
At 11:01 -0600 2000-08-01, Nathan Torkington wrote:
>Dominic Dunlop writes:
>> Pluggable regex engines would make supporting (say) core and optional
>> regex language features easier.
>
>(Nat qua Nat speaking)
>
>The word "pluggable" gives me the willies. I feel like things like
>REs should hav
>Perl's regex syntax in not poorly documented (IMHO, of couse).
Some of the new stuff is. (Poorly documented, that is.)
>MRE made me feel like a ghod (after I read chapter 7 for the third time ;)
Some of the new stuff's not in MRE, which is, I suppose, partly why
Jeffrey Friedl's working on a
At 02:52 PM 8/1/00 -0400, Chaim Frenkel wrote:
>Please explain how having a no taint block would still keep the spirit
>of not making untainting easy?
Hadn't thought that much about it. That is an issue which'd need to be
dealt with if this proposal goes anywhere, which it very well might not.
Please explain how having a no taint block would still keep the spirit
of not making untainting easy?
Just add a no taint at the top of ones code, and the -T goes away.
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I think I'd prefer to leave untainting to regexes.
DS> What I wa
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:58 AM 8/1/00 -0500, Garrett Goebel wrote:
> >From: John Tobey [mailto:[EMAIL PROTECTED]]
> > >
> > > Since this issue mainly affects Windows users (I assume),
> >
> >Actually I've run across a couple people wanting this on unices.
>
> I want it on V
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> $Config{osname}, I think. I'm not thrilled with that, mainly because it
DS> means loading up Config, which ain't cheap.
Why not have $Config hard coded into the executable? Perl has to have
it or know it. So why not make it part of the
At 11:58 AM 8/1/00 -0500, Garrett Goebel wrote:
>From: John Tobey [mailto:[EMAIL PROTECTED]]
> >
> > Since this issue mainly affects Windows users (I assume),
>
>Actually I've run across a couple people wanting this on unices.
I want it on VMS, too.
> > That's a different problem. Configure is
At 11:01 AM 8/1/00 -0600, Nathan Torkington wrote:
>The word "pluggable" gives me the willies. I feel like things like
>REs should have one blessed implementation and set of capabilities. I
>don't want to have four modules in my program, each of which requires
>a different RE engine.
I very muc
Dominic Dunlop writes:
> Pluggable regex engines would make supporting (say) core and optional
> regex language features easier.
(Nat qua Nat speaking)
The word "pluggable" gives me the willies. I feel like things like
REs should have one blessed implementation and set of capabilities. I
don'
From: John Tobey [mailto:[EMAIL PROTECTED]]
>
> Since this issue mainly affects Windows users (I assume),
Actually I've run across a couple people wanting this on unices.
> That's a different problem. Configure is trying to reverse engineer
> header files. Garrett already knows the prototype
-Original Message-
From: Dominic Dunlop [mailto:[EMAIL PROTECTED]]
previously difficult or impossible (or merely verbose). But it's
also more or less poorly documented, more or less poorly understood,
more or less well-used, and more or less poorly tested. (Indeed,
some of it's sti
At 15:19 +0100 2000-08-01, Tim Bunce wrote:
> >RegEx (internals?)
>
>Yes, Yes, Yes.
I could argue for regex being language too: it's a little language,
and it's got very crufty of late. Yes, it's sexy cruft which can be
justified because it allows one to do neat things which were
pre
I respectfully request that one list be picked for this topic and
discussion confined to that one list even if it should occasionally
spill into the other bailiwick. Or perhaps it's a candidate for a new
working group.
If all messages are CC:ed to all lists, then simply have p5p reborn
(and the
At 11:57 PM 7/31/00 -0700, Matthew Cline wrote:
>On Mon, 31 Jul 2000, Nathan Wiger wrote:
>
> > Instead, it would be really cool if Perl6 let you do this:
> >
> >#! perl -T
> >local($^T) = 0;
> >$ENV{PATH} = read_config_file();
> >local($^T) = 1;
>
>I would prefer something like:
>
At 11:57 PM 7/31/00 -0700, Matthew Cline wrote:
>Something else which might be useful for tainting would be something like:
>
> taint_var($foo);
> no_taint_var($bar);
>
>With this, any value assigned to $foo would become tainted, and any value
>assigned to $bar would become untainted.
Whi
At 02:31 AM 8/1/00 -0400, Sam Tregar wrote:
>I suppose a reasonable question is: can we achieve
>our goals without a rewrite? Can we succeed in integrating threading and
>Unicode where the Perl5 developers have failed, without rewriting the
>internals? I'm not qualified to say no, but I'd like t
On Tue, 1 Aug 2000, John Tobey wrote:
> I'm thinking of a rewrite in the sense that (by my impression) BSD was
> a rewrite of Unix. Refactoring, shifting stuff around until it's easy
> to get a handle on things, and replace it all a little at a time. So,
> yes, these problems can be solved IMHO
> Another note: your examples with:
>
> local ($^T) = 0;
> $ENV{PATH} = read_config_file();
> local ($^T) = 1;
>
> is only using local() to confuse; it should be written with a block,
> correctly restoring the old value of $^T.
Sorry about that - I contemplated taking it
On Tue, Aug 01, 2000 at 07:03:42AM -0400, Grant M. wrote:
> Just trying to catch up. This is where I understand the discussion
> stands:
> INTERNALS(?)
> modular language:
>Scanner/Symbol Table/Parser/Executor
Internals.
>Standard Functions separate from core (moving to langu
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 01, 2000 at 01:43:05PM +0100, Graham Barr wrote:
> > Let me just say that Larry has said in the past that untainting was
> > deliberatly left difficult to do, on the basis that something which
> > can have serious effect (ie security) should no
On Tue, Aug 01, 2000 at 01:43:05PM +0100, Graham Barr wrote:
> Let me just say that Larry has said in the past that untainting was
> deliberatly left difficult to do, on the basis that something which
> can have serious effect (ie security) should not be easy to do.
>
> But then I suppose all pre
On Tue, Aug 01, 2000 at 08:13:24AM -0400, Bryan C.Warnock wrote:
> On Tue, 01 Aug 2000, Matthew Cline wrote:
>
> >
> > I would prefer something like:
> >
> > #! perl -T
> > $ENV{PATH} = untaint( read_config_file() );
> >
> > In other words, either make the 'Taint' and 'Untaint' package
I've heard rumors about PI -- Perl Implementation language. What is it?
--
Never ascribe to malice that which can be explained by stupidity.
(via, but not speaking for Deutsche Bank)
On Tue, 01 Aug 2000, Matthew Cline wrote:
>
> I would prefer something like:
>
> #! perl -T
> $ENV{PATH} = untaint( read_config_file() );
>
> In other words, either make the 'Taint' and 'Untaint' packages part of the
> standard distribution, or put them into the core language.
>
Thi
> [Reply redirected to perl6-internals, as requested by Dan Sugalski]
>
> At 13:20 -0500 2000-07-31, Garrett Goebel wrote:
> >- Pickle looks like a better XS. But I don't know much about it
>
> What Pickle would that be? Python has something with the right name,
Gah!! That shows my ignorance
On Mon, Jul 31, 2000 at 10:42:54PM -0700, Nathan Wiger wrote:
> Dan Sugalski wrote:
> >
> > > existence of a $^T variable for controlling tainting in the same way
> > > that $^W controls warnings.
> >
> > So put in an RFC. :)
>
> Dan-
>
> Ask and ye shall receive...in POD format ala Tim...
I
Just trying to catch up. This is where I understand the discussion
stands:
INTERNALS(?)
modular language:
Scanner/Symbol Table/Parser/Executor
Standard Functions separate from core (moving to language?)
Modules Separate from everything (definitely language)
Strict(er)
[Reply redirected to perl6-internals, as requested by Dan Sugalski]
At 13:20 -0500 2000-07-31, Garrett Goebel wrote:
>- Pickle looks like a better XS. But I don't know much about it
What Pickle would that be? Python has something with the right name,
but "[t]he pickle module implements a basic
Nathan Wiger <[EMAIL PROTECTED]> writes:
[...]
> =head1 Implementation
>
> This will avoid internals, but instead get into the details of how the
> implementation should *act*:
>
>1. Have the tainting engine "trust" any variables declared
> when tainting is off. So:
>
> #!
84 matches
Mail list logo
