Nathan Torkington wrote:
> Actually, I think I'd like to see this extended. I'd like to be able
> to hook into the parser so that when it sees a function call:
>
> foo()
>
> I can have it call my subroutine.
>
> foo_handler( $token_stream )
>
> foo_handler can access the token stream that ma
On Sat, Sep 16, 2000 at 03:24:32AM -, Perl6 RFC Librarian wrote:
> Currently, trying to dynamically assign to unnamed classes is very
> difficult:
>
>$pkg::$var = $val; # error
>${pkg}::$var = $val; # nope
>${$pkg::$var} = $val; # you wish
>${${pkg}::$var} =
On Sat, Sep 16, 2000 at 03:36:45AM -, Perl6 RFC Librarian wrote:
> Change the way $SIG{__WARN__} and $SIG{__DIE__} are used
I don't think this is enough to repair $SIG{__WARN__} and
$SIG{__DIE__}. I know some people out there have some very strong
feelings about these pseudo-signals. It may
On Fri, 15 Sep 2000, Chris Nandor wrote:
> You can only avoid breakage with current scripts if you make no changes to
> the current facilities (which is what Andy proposed).
Well I have to admit that I was unaware that on Mac and VMS (without the
wizardry in vms/vms.c) the value returned by time
(To the folks on the license-discuss list.) As you may know,
Perl is currently undergoing a rewrite. As part of this
rewrite licensing is being reviewed, and we are attempting
to come up with an Artistic License that is (*ahem*) on
somewhat better grounds than the current one. This is my
curren
On Thu, Sep 14, 2000 at 08:10:54PM -, Perl6 RFC Librarian wrote:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Objects: C pragma
>
> =head1 VERSION
>
> Maintainer: Damian Conway <[EMAIL PROTECTED]>
> Date: 14 September 2000
> Mail
Perl6 RFC Librarian wrote:
>
> =head1 TITLE
>
> Inline Comments for Perl.
Why was this posted again? I see no CHANGES section.
> An idea that produces a paired feeling would be to use one of the
> paired character pairs, as in "#<" and ">#".
#Oh Lord, What Have I Gotten Myself Into
On Fri, Sep 15, 2000 at 02:11:55PM -0400, Dan Sugalski wrote:
> -c in there between the load-time things
> (-M, -T, -U, etc...) and the runtime things (-n, -p)
I'd say -c should be last, if only to keep Abigail happy:
% perl -nce '}print $.; {'
-e syntax OK
simon@deep-dark-truthful-mirror ~/p
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Data: Multi-dimensional arrays/hashes and slices
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 15 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 231
Version: 1
St
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Data: overloading via the SECOND operand if needed
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 15 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 234
Version: 1
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Data: sprintf() with overloaded objects
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 15 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 235
Version: 1
Status: Dev
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace Exporter by a better scaling mechanism
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 15 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 233
Version: 1
Stat
On Fri, 15 Sep 2000 08:28:30 -0700 (PDT), Dave Storrs wrote:
> Personally, I like the way it works at the moment; all the subs
>that you want to memoize are up at the top, where they are easy to see.
You have a point.
What I don't like is how the basic module syntax pretty much requires
t
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Keep default Perl free of constraints such as warnings and strict.
=head1 VERSION
Maintainer: Daniel Chetlin <[EMAIL PROTECTED]>
Date: 3 Aug 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROT
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace localtime() and gmtime() with date() and utcdate()
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 05 Aug 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTE
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Legacy Perl $pkg'var should die
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 08 Aug 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 71
Version:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Make length(@array) work
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: Sep 12 2000
Last Modified: Sep 15 2000
Mailing List: [EMAIL PROTECTED]
Number: 212
Version: 2
St
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Emit warnings and errors based on unoptimized code
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: Sep 12 2000
Last Modified: Sep 15 2000
Mailing List: [EMAIL PROTECTED]
Num
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
length(@ary) deserves a warning
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 238
Version: 1
Status: Developing
Sup
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
IO: Standardization of Perl IO Functions to use Indirect Objects
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 239
Vers
documentation
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Form a documentation working group to edit, clean, and produce
documentation
=head1 VERSION
Maintainer: Daniel Chetlin <[EMAIL PROTECTED]>
Date: 15 Sep 2000
On Thu, 14 Sep 2000 18:14:49 -0400, Mark-Jason Dominus wrote:
>The perl 5 -> perl 6 translator should replace calls to 'eval' with
>calls to 'perl5_eval', which will recursively call the 5->6 translator
>to translate the eval'ed string into perl 6, and will then eval the
>result.
Blech, no. eval
Nathan Wiger wrote:
> >
> > and this may, indeed, be sufficient.
>
> Remember, this still won't solve the problem of a module whose functions
> can handle both OO and function-oriented calls - and yes, I have many
> that do this. :-)
I think such modules are a bad idea, because their functional
On Thu, Sep 14, 2000 at 03:36:10PM -0700, Nathan Wiger wrote:
> See, this is just too inflexible. The main complaint that I've heard has
> been "You can't have leading or trailing whitespace around your
> terminator". This is a very common error made by everyone, and *this* is
> where Perl should
On Fri, Sep 15, 2000 at 01:52:00AM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Extend the window to turn on taint mode
As long as we're talking about tainting (this is a good idea, BTW) how
does everyone feel about a few other tainting widgets...
- A way to know when taint mode is on.
On Thu, 14 Sep 2000 19:19:34 -0400, Chris Nandor wrote:
>And yes, sometimes the OS is completely lacking in knowledge of a
>time zone.
This problem isn't new. Currently, Perl must know the timezone to be
able to correctly generate gmtime() and localtime().
--
Bart.
On 15 Sep 2000 02:09:23 -, Perl6 RFC Librarian wrote:
>A version of Memoize.pm should be added into the Perl6 standard
>library, and it should be added as a pragmatic module (i.e. memoize.pm).
Is that it?
I would rather have a flag when generating the sub, er, what's that
syntax again, ":so
On Thu, 14 Sep 2000 18:37:22 -0500, David L. Nicol wrote:
> print "Today's weather will be ${weather->temp} degrees and sunny.";
>
>which would follow the "You want something funny in your interpolated
>scalar's name or reference, you put it in curlies" rule.
I too feel that an approach li
On Thu, Sep 14, 2000 at 05:31:44PM -0500, David L. Nicol wrote:
> A possibility that does not appear in RFC222.1 is to put tho whole
> accessor expression inside curlies:
>
> print "Today's weather will be ${weather->temp} degrees and sunny.";
>
> which would follow the "You want something
On Fri, Sep 15, 2000 at 10:58:26AM +0200, Bart Lateur wrote:
> MJD has a "silly module" which can tie a hash to a function:
> Interpolation.pm. I think I would like a special case, a specific hash
> that is *always* tied to a function that returns the arguments. Make it,
> for example, %$, %@ or %
On Fri, 15 Sep 2000 01:36:50 -0800, Michael Fowler wrote:
>Or maybe an alternative, using &:
>
>"foo &foo(arg, arg, arg) bar"
>"foo &{ foo(arg, arg, arg) } bar"
Ah, yes, &{...}, I kinda like that. Unfortunately, in regexes, /&{1,3}/
means matching 1 to three ampersands. There's a slight
On Thu, 14 Sep 2000 15:47:43 -0700, Steve Fink wrote:
>Currently, toke.c turns "foo$bar" into "foo".$bar before the parser or
>anything else sees it. So any features implemented in the tokenizer have
>to get smarter about remembering what they did.
This sound pretty much like the same problem yo
> > On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote:
> > > That's fine for the VM and the support libraries, but I'd *really*
> > > like to see the parser/front-end in Perl. There are dozens of RFCs
> > > that require some non-trivial extensions to the parser. It would
> > > be nice to cod
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>> (Someone remind me, What is the point of -T if not running setuid?)
JH> Being paranoid is never a bad idea because They are always out to get you.
That's fine, but tell me what security breach can be caused by not having
a -T?
The p
Michael Fowler wrote:
> Or maybe we need a more generic solution (as someone else suggested, I
> forget who). Something that allows the arbitrary execution of code, much
> like @{[ ]}, but cleaner. Unfortunately, I can't think of anything
> suitable.
>
> Whatever direction this discussion take
> "AT" == Adam Turoff <[EMAIL PROTECTED]> writes:
AT> The crux of my proposal/request is that when perl6 innards are
AT> designed, -T processing is handled the same way -p and -i are.
AT> That is, option processing should start out cleaner than what
AT> is in 5.7.0 or what was in 5.004 (at le
On Fri, Sep 15, 2000 at 09:19:14AM -0400, Chaim Frenkel wrote:
> > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>
> >> (Someone remind me, What is the point of -T if not running setuid?)
> JH> Being paranoid is never a bad idea because They are always out to get you.
>
> That's fine
Graham Barr wrote:
>
> One of the benefits I was hoping to get from having a variable hold
> the invocant is the ability for the invocant to be undef if the sub
> was not called as a method.
Um, functions can return undef too, ya know. :-)
--
John Porter
> Perl6 should allow scalars and arrays to be tagged such that they are
> interpolated in single quotish context.
How do you turn it off? I want to keep a way to specify stuff without any
interpolation whatsoever. I see the usefulness of this sort of quoting,
but I also see the usefulness of bei
On 14 Sep 2000, at 14:18, Nathan Wiger wrote:
> Before you balk at #1 in favor of religious flexibility, please consider
> how unmaintainable Perl code would be if @ARGV, or $AUTOLOAD, or STDERR,
> or @INC, or chomp(), or split(), or any other widely-used variable or
> function was renameable. If
Hildo Biersma wrote:
>
> I think such modules are a bad idea, because their functionality is
> typically restricted.
Oh? Where do you get that idea?
> Altering the language to make that easier seems a
> bad idea to me.
On the contrary: altering *anything* about Perl to make
something easier
On Fri, 15 Sep 2000, Bart Lateur wrote:
> On Thu, 14 Sep 2000 18:14:49 -0400, Mark-Jason Dominus wrote:
>
> >The perl 5 -> perl 6 translator should [recursively handle eval]
>
> Blech, no. eval should stay eval. People are responsible for generating
> Perl6 compatible code, if they construct
On Fri, Sep 15, 2000 at 05:56:36AM -, Perl6 RFC Librarian wrote:
> $foo = 'def';
> $bar = 'ghi';
> $x = "abc$foo$bar";
> $y = 'abc$foo$bar';
>
> There is no way to turn obtain the value of $x from the value of $y.
> In other words, while $foo and $bar were interp
At 9:17 -0400 2000.09.15, Chaim Frenkel wrote:
>> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
>
>CN> At 22:19 -0400 2000.09.14, Chaim Frenkel wrote:
>>> If you want to adjust for timezones just calculate the constant. Which
>>> since you are giving it in HHMM format you might as well just
> >One problem is the definition of "Reasonable Copying Fee" given in the
> >license. It is possible the definition means: "You can charge any amount as
> >copying fee, if people will pay it". If this interpretation is correct,
> >there is no real legal limit on the fee at all.
>
> That is aga
Eryq wrote [seriously elided by jdp]:
>
> they would be even more informative if, instead of
> using =head2 or =item to document our APIs, we had things
> like this:
> =method open FILENAME
> =method
> @type class,instance
>
> That's why I favor taking generally-useful things
On Fri, 15 Sep 2000, Bart Lateur wrote:
> On 15 Sep 2000 02:09:23 -, Perl6 RFC Librarian wrote:
>
> >A version of Memoize.pm should be added into the Perl6 standard
> >library, and it should be added as a pragmatic module (i.e. memoize.pm).
>
> I would rather have a flag when generating t
Dave Storrs sent the following bits through the ether:
> Personally, I like the way it works at the moment; all the subs
> that you want to memoize are up at the top, where they are easy to see.
> You can add, subtract, and change the list in a few seconds, without
> having to hunt through your f
On Fri, Sep 15, 2000 at 10:21:58AM +0200, Bart Lateur wrote:
> On 15 Sep 2000 02:09:23 -, Perl6 RFC Librarian wrote:
> >A version of Memoize.pm should be added into the Perl6 standard
> >library, and it should be added as a pragmatic module (i.e. memoize.pm).
>
> Is that it?
>
> I would rath
On Fri, 15 Sep 2000 11:58:08 -0400 (EDT), Andy Dougherty wrote:
>[Aside: Does this mean that make(1) is useless for one hour after
>standard time resumes?]
That'll teach you. You shouldn't be programming in the middle of the
night.
--
Bart.
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Any time the code being executed isn't being run as the person asking for
DS> its execution you can have problems. Think daemons in perl, or
DS> client-server code. (Like CGI programs, or mailing-list managers) Jobs run
DS> automagical
At 03:38 PM 9/15/00 -0400, Michael G Schwern wrote:
>On Fri, Sep 15, 2000 at 01:03:50PM -0400, Dan Sugalski wrote:
> > Take a look at the Taint modules on CPAN. Mine does just these, and I
> think
> > Tom Phoenix's does a bunch more.
>
>Tom's Taint.pm has never worked for me. I just tried instal
At 03:58 PM 9/15/00 -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> Any time the code being executed isn't being run as the person asking for
>DS> its execution you can have problems. Think daemons in perl, or
>DS> client-server code. (Like CGI programs,
Dave Storrs wrote:
>
> As to solving problem #1 (which is, arguably, the bigger problem),
> suppose we add a new switch to perl? I propose we add the -H switch
> (mnemonic: *H*elpful errors/warnings). When -H is set, the optree would
> be generated with a sufficient amount of bloat that
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> But these all lack command line switches that are passed to perl.
DS> No, they don't. Not everywhere, certainly. Command-line switches
DS> can be passed to all of 'em. Not everyone counts on the magic
DS> shebang line to find the command
On Fri, Sep 15, 2000 at 01:03:50PM -0400, Dan Sugalski wrote:
> Take a look at the Taint modules on CPAN. Mine does just these, and I think
> Tom Phoenix's does a bunch more.
Tom's Taint.pm has never worked for me. I just tried installing it
again and it failed a bunch of tests (in both 5.005 a
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> It may not be. Think CGI.
JH> The code is running under what ever poor security measures the silly
JH> subclued webmaster set it up to be, and has access to which ever files
JH> yadayadayada.
No command line switches there. Only t
I thought you people might need a little break. The first one is
particularly... yeah.
- Forwarded message from Jim Monty <[EMAIL PROTECTED]> -
From: Jim Monty <[EMAIL PROTECTED]>
Subject: Re: [FWP] Comic goodness
To: [EMAIL PROTECTED]
Date: Fri, 15 Sep 2000 09:53:48 -0700 (MST)
> See,
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Alternative lists and quoting of things
=head1 VERSION
Maintainer: Richard Proctor <[EMAIL PROTECTED]>
Date: 27 Aug 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 166
V
The discussion about RFC 227 in -internals brought up a few good ideas
about a taint pragma. In brief:
- taint(), tainted() and other such functions would be useful
when sending scalars around or inspecting them. A few other
functions may fall into this category.
> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
>> my_time_in_local_epoc
>> + current_os_epoch_offset
>> - timezone_ofset_in_seconds
>> = time_in_unix_epoch_seconds
CN> But again, I don't know what you are trying to say. Are you saying we
CN> should have some global "constant"? If so, y
At 15:55 -0400 2000.09.15, Chaim Frenkel wrote:
>CN> * We do not know if it will always be this simple for every platform
>
>Hard to see how the three variables wouldn't cover the spectrum.
Very hard to see, until we know what the disparate platforms might require. :)
>CN> * You might need to
> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
>> This new module to cover your feature would require that it know every
>> known epoch and timesystem (or at least the useful ones.) Something
>> this domain knowledgable shouldn't be in CORE.
CN> Why? File::Spec is in the core. So are m
At 17:11 -0400 2000.09.15, Chaim Frenkel wrote:
>> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
>
>>> This new module to cover your feature would require that it know every
>>> known epoch and timesystem (or at least the useful ones.) Something
>>> this domain knowledgable shouldn't be in
Dan Sugalski wrote:
> 1) How fast is the C (or whatever) code it emits likely to be?
The perl-in-perl interpreter would not be a deliverable. Speed would
not be its goal. It would be a reference implementation that would be
easier to break and repair. An internals tutorial, if you will.
So
I don't believe that the optree has to be bloated. I think having the
actual line number in the optree vs. having a seperate structure
mapping offsets to line numbers are the same.
Then an error report would be akin to
error_me_this(current_op_address, "Foo didn't baz in time. Aborting")
On Fri, Sep 15, 2000 at 05:04:23PM -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> >> But these all lack command line switches that are passed to perl.
>
> DS> No, they don't. Not everywhere, certainly. Command-line switches
> DS> can be passed to all of 'em
At 05:21 PM 9/15/00 -0400, Chaim Frenkel wrote:
>I don't believe that the optree has to be bloated. I think having the
>actual line number in the optree vs. having a seperate structure
>mapping offsets to line numbers are the same.
>
>Then an error report would be akin to
> error_me_this(c
Steve Fink writes:
> I suspect perl can do a much better job than it does now, but if you
> make it a requirement, you prevent many optimizations. I think the RFC
> should be very specific about when it applies and when it gets out of
> the way.
I can't be more specific unless I know the optimiza
> (?Q$foo) Quotes the contents of the scalar $foo - equivalent to
> (??{ quotemeta $foo }).
How is this different from
\Q$foo\E
?
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace =~, !~, m//, s///, and tr// with match(), subst(), and trade()
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 27 Aug 2000
Last Modified: 15 Sep 2000
Mailing List: [EMA
Interesting point you made about context. $size = @array is typically
the first introduction of the idea of contexts to a new programer.
On Sat, Sep 16, 2000 at 03:38:47AM -, Perl6 RFC Librarian wrote:
> (2) require changes to the prototype system to permit length() to
> still be overridabl
> I'm surprised there hasn't be a good overhaul of the prototyping
> system proposeed yet.
What exactly didn't you like about RFC 128???
Damian
On Sat, Sep 16, 2000 at 04:21:15PM +1100, Damian Conway wrote:
>> I'm surprised there hasn't be a good overhaul of the prototyping
>> system proposeed yet.
>
> What exactly didn't you like about RFC 128???
Ummm... the fact that its title doesn't match /proto/. My bad.
Okay, its a prop
> > What exactly didn't you like about RFC 128???
>
> Ummm... the fact that its title doesn't match /proto/. My bad.
In fact it proposes that "prototype" be banished as a term of reference. :-)
> Okay, its a proposal to overhaul prototyping, cool. But I don't see
> anything
On 15 Sep 2000, at 1:10, Perl6 RFC Librarian wrote:
> With this proposal, the scalar C<$filename> can be tagged to be interpolated
> by the C<\I...\E> pair and the double quotish context replaced by single
> quotish context resulting in the following:
Definitely with this change, you should incl
On 14 Sep 2000, at 21:06, Glenn Linderman wrote:
> I _like_ the conceptual idea, here. But I think we need a different kind of
> quoting, not extend single quote semantics. Single quote semantics are really,
> really, good for exact quoting. I'm sure you (since you mention VMS) find single
> q
Michael Schwern wrote:
>See, I never understood this. If you're indenting the terminator, it
>implies you're also indenting the here-doc text. I mean, this doesn't
>make any sense:
>
>{ { { {
>print gripe is. A critic is
>simply someone paid to
>render opinions
On Fri, Sep 15, 2000 at 01:04:50PM -0400, Dan Sugalski wrote:
> At 01:15 AM 9/15/00 -0400, Adam Turoff wrote:
> >On Thu, Sep 14, 2000 at 10:37:40PM -0400, Chaim Frenkel wrote:
> > > I vaguely recall when Chip put that in. He worked pretty hard to
> > > adjust the command line/#! option processing.
On Fri, Sep 15, 2000 at 12:53:29PM -0400, Dan Sugalski wrote:
> The only reason I can see nice winning over fast is if nice brings in whole
> new concepts to the language. (Like, say, matrix ops or Damian's currying stuf)
Well, taking the idea of writing the parser in Perl, let's have a look
at
On Fri, Sep 15, 2000 at 01:03:50PM -0400, Dan Sugalski wrote:
> At 04:52 AM 9/15/00 -0400, Michael G Schwern wrote:
> >On Fri, Sep 15, 2000 at 01:52:00AM -, Perl6 RFC Librarian wrote:
> > > =head1 TITLE
> > >
> > > Extend the window to turn on taint mode
> >
> >As long as we're talking about t
At 01:53 PM 9/15/00 -0400, Adam Turoff wrote:
>On Fri, Sep 15, 2000 at 01:04:50PM -0400, Dan Sugalski wrote:
> > At 01:15 AM 9/15/00 -0400, Adam Turoff wrote:
> > >On Thu, Sep 14, 2000 at 10:37:40PM -0400, Chaim Frenkel wrote:
> > > > I vaguely recall when Chip put that in. He worked pretty hard t
It seems to me that everyone in this thread pretty much agrees that this
is a good idea, but has one of the following reservations:
1) Tracking sufficient information to be able to report errors at the
exact spot they happen involves bloating the optree a lot and slowing down
the whole program;
At 02:40 PM 9/14/00 +0100, Piers Cawley wrote:
>Simon Cozens <[EMAIL PROTECTED]> writes:
>
> > On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote:
> > > That's fine for the VM and the support libraries, but I'd *really*
> > > like to see the parser/front-end in Perl. There are dozens of RFCs
At 03:06 PM 9/14/00 +0100, Simon Cozens wrote:
>On Thu, Sep 14, 2000 at 02:40:31PM +0100, Piers Cawley wrote:
> > > Are there any better reasons than "It would be nice?"
> >
> > Can there *be* a better reason than "It would be nice"? Seriously,
> > niceness is a damned fine goal.
>
>No, it isn't.
At 10:07 PM 9/13/00 -0600, Nathan Torkington wrote:
>Ken Fox writes:
> > The dogfood theory? One of the design goals for Perl is to make text
> > munging easy. Parsing falls into that category and therefore we should
> > use it, i.e. eat our own dogfood.
>
>How about this. During design, we try t
At 01:15 AM 9/15/00 -0400, Adam Turoff wrote:
>On Thu, Sep 14, 2000 at 10:37:40PM -0400, Chaim Frenkel wrote:
> > I vaguely recall when Chip put that in. He worked pretty hard to
> > adjust the command line/#! option processing. (Something about
> > unsafe operations already being done before the
At 04:52 AM 9/15/00 -0400, Michael G Schwern wrote:
>On Fri, Sep 15, 2000 at 01:52:00AM -, Perl6 RFC Librarian wrote:
> > =head1 TITLE
> >
> > Extend the window to turn on taint mode
>
>As long as we're talking about tainting (this is a good idea, BTW) how
>does everyone feel about a few other
At 09:19 AM 9/15/00 -0400, Chaim Frenkel wrote:
> > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>
> >> (Someone remind me, What is the point of -T if not running setuid?)
>JH> Being paranoid is never a bad idea because They are always out to get you.
>
>That's fine, but tell me what
On Fri, 15 Sep 2000, Dan Sugalski wrote:
> Doing core work in perl also has startup issues--either we need to parse
> perl code every time perl starts, write the optree stuff to be
> position-independent, compile perl down to native code, or embed and
> process bytecode every time we start.
I
Bart Lateur wrote:
>
> On Thu, 14 Sep 2000 15:47:43 -0700, Steve Fink wrote:
>
> >Currently, toke.c turns "foo$bar" into "foo".$bar before the parser or
> >anything else sees it. So any features implemented in the tokenizer have
> >to get smarter about remembering what they did.
>
> This sound
At 10:27 PM 9/14/00 -0400, Chaim Frenkel wrote:
> > "SF" == Steve Fink <[EMAIL PROTECTED]> writes:
>
>SF> I suspect perl can do a much better job than it does now, but if you
>SF> make it a requirement, you prevent many optimizations. I think the RFC
>SF> should be very specific about when it
Mark-Jason Dominus writes:
> I think it would be a step in the right direction if the WG chairs
> actually required RFC authors to maintain their RFCs.
In preparation for the end-run of RFCing, how about we compile a list
of "developing" RFCs that haven't been touched in more than a week,
and con
Chaim Frenkel writes:
> We are not at that stage yet.
>
> There are too many new things that are _supposed_ to interact to
> bother with a prototype. It doesn't do any good, until the language
> is nailed down.
That's no argument against prototyping, though. Prototype one feature
and then you
On Fri, Sep 15, 2000 at 04:11:27PM -0600, Nathan Torkington wrote:
> Mark-Jason Dominus writes:
> > I think it would be a step in the right direction if the WG chairs
> > actually required RFC authors to maintain their RFCs.
>
> In preparation for the end-run of RFCing, how about we compile a lis
> The only decision, then, is to decide which context to use; if it deparses
> to concatenation then it seems logical to use scalar context. This also
> makes sense in that you can force list context with @{[ $weather->temp ]} if
> you really wanted it.
$ perl -le 'sub w{wantarray?"WA":"WS"};pr
On Fri, Sep 15, 2000 at 07:24:39PM -0500, David L. Nicol wrote:
> > The only decision, then, is to decide which context to use; if it
> > deparses to concatenation then it seems logical to use scalar context.
> > This also makes sense in that you can force list context with @{[
> > $weather->temp
> This RFC proposes a support of a situation when a more-knowledgable module may
> steal overloading from a less-knowledgable module or visa versa;
What if both modules have this :override bit set at the same time? Does
the second one still win? Or does the first one win again?
Either way I'm no
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
More direct syntax for hashes
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: 5 Sep 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 196
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
hashes should interpolate in double-quoted strings
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 237
Version: 1
Statu
1 - 100 of 150 matches
Mail list logo
