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 script is read.)
The crux of my proposal/request is
Dave Storrs <[EMAIL PROTECTED]> writes:
[...]
> > print << FIRST_HERE_DOC; print << SECOND_HERE_DOC;
> > This is on the left margin.
> > This is indented one char.
> > FIRST_HERE_DOC
> > This is indented one char.
> > This is on the left margin.
> > SECOND_HERE_D
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Variable interpolation on demand.
=head1 VERSION
Maintainer: Glenn Linderman <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 229
Version: 1
Status: Developing
=hea
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Object neutral error handling via exceptions
=head1 VERSION
Maintainer: Glenn Linderman <[EMAIL PROTECTED]>
Date: 16 Aug 2000
Last Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 119
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Inline Comments for Perl.
=head1 VERSION
Maintainer: Glenn Linderman <[EMAIL PROTECTED]>
Date: 14 Aug 2000
Last Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 102
Version: 2
Sta
On 14 Sep 2000, Chaim Frenkel wrote:
> (Someone remind me, What is the point of -T if not running setuid?)
All you need to get root is an unprivilaged shell on anything but a
fully patched machine. A dumb Perl CGI running without -T is all you need
to get a shell.
Besides, I bet most online st
Damian Conway wrote:
>> now, what if the double quoted range had a \E in it? either directly or
>> via interpolation? maybe the end escape should be another char than \E?
>
> Make \E significant only where it's explicit.
None of the \ escapes are significant via interpolation, even today
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
quote semantics good for escaping all those $ VMS requires.
Michael G Schwern writes:
> I have misgivings. I like single-quote context *because* you don't
> have to worry about anything magical (except ' and \).
Genericise it.
Alter the overloaded string constant behaviour of perl5 so that
when you say:
use MagicInterpolativeStrings;
$foo = '$bar <
> that makes good sense. so in a single quote string you can have domains
> of double quote behavior.
That's it exactly. Very well expressed, thanks Uri.
> now, what if the double quoted range had a \E in it? either directly or
> via interpolation? maybe the end escape should be ano
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> > No thanks. Suppose I want:
>> >
>> > '$x = $a;
>> > $y = func(\I$arg1, $arg2, $arg3\E);
>>
>> Hmmm...should \Ifunc($arg1)\E be replaced by the return value of
>> func($arg1)?
DC> I don't think so. I think \I..\E sh
> > No thanks. Suppose I want:
> >
> > '$x = $a;
> > $y = func(\I$arg1, $arg2, $arg3\E);
>
> Hmmm...should \Ifunc($arg1)\E be replaced by the return value of
> func($arg1)?
I don't think so. I think \I..\E should just impose qq{..} semantics on
the text in between. So yo
Damian Conway wrote:
> You can't, in serial implementation. But on a parallel architecture
> or, better still, on a quantum device, you can run all the computations
> in parallel.
I see that. PDL has that as an experimental feature on any ufunc (in
fact on any function that has a signature). It
On Fri, Sep 15, 2000 at 01:56:39PM +1100, Damian Conway wrote:
>> Hang on... \I \E amounts to the same number of characters as using
>> '. .' (that is, terminating this q-string, concat the thing, start
>> a new q-string)
>
> You can't do that in a <<'HERE' doc.
True.
>> For
> Hang on... \I \E amounts to the same number of characters as using
> '. .' (that is, terminating this q-string, concat the thing, start
> a new q-string)
You can't do that in a <<'HERE' doc.
> For arrays, yes, the proposed \I \E would still be useful. Maybe the
> \I should
"David L. Nicol" wrote:
> >
> >1. You must use globs to pass them in and out of functions
>
> This could be resolved by allowing undecorated types to be passed
This is already allowed. It's called "passing in a bareword".
And barewords are just strings. Are you proposing
that "a barewor
> (Someone remind me, What is the point of -T if not running setuid?)
Being paranoid is never a bad idea because They are always out to get you.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
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 script is read.)
You are asking for the first line of the input script be read before
any of the command line arguments a
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 calculate
>directly.
>
>So what am I missing.
Beats me. I am not sure whether or not you have a point, and if so,
> "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 applies and when it gets out of
SF> the way.
Expressi
> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
>> This is a wider
>> problem then a fixed epoch for perl. Let's turn this around. What if
>> we are on a platform that doesn't use perl's epoch and we need to write
>> a value to a file?
CN> Yes. What if? That's what we're addressing. Ri
Hang on... \I \E amounts to the same number of characters as using
'. .' (that is, terminating this q-string, concat the thing, start
a new q-string) So for scalars, there would be no savings at all.
For arrays, yes, the proposed \I \E would still be useful. Maybe the
\I should just scan for t
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add memoize into the standard library
=head1 VERSION
Maintainer: Adam Turoff <[EMAIL PROTECTED]>
Date: Sep 14 2000
Mailing List: [EMAIL PROTECTED]
Number: 228
Version: 1
Status: Developing
=hea
On Thu, Sep 14, 2000 at 10:01:23PM -0400, Jerrad Pierce wrote:
> What's wrong with extending current syntax such that:
Please read the discussion so far.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Oh yeah I forget to outline what it currently does for those whom may not have
seen it...
It's usally used for evaluation and interplation of code/subroutines
in "", qq() and <>2||($_<<2>12)){$_="Vainyvq ragel";&{$F[0]};last;}&t;$0-=$_;$_="Lbh jva";
die(&{$F[0]}) if !($0-1);$0-=$0%2?$0>2?2:1:$0<=
What's wrong with extending current syntax such that:
$a = "Hello";
print q(@{[$a]} World), "\n";
outputs
Hello World
instead of
@{[$a]} World
yes, it's a few extra char's but IMHO
it's a logical extension
it makes you think twice before doing it, do you really need to do thi
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Extend the window to turn on taint mode
=head1 VERSION
Maintainer: Adam Turoff <[EMAIL PROTECTED]>
Date: Sep 14 2000
Mailing List: [EMAIL PROTECTED]
Number: 227
Version: 1
Status: Developing
=h
> > =head2 The C method
> > =head3 The C method
>
> Hey! You left out the alternative names NEW / RENEW and BLESS / REBLESS
> that we all like! :-(
Oops. You're correct. I will rectify that.
Damian
On Thu, 14 Sep 2000, Steve Fink wrote:
> Alan Burlison wrote:
> > Having done so I have been very happy to see the wide consensus
> > that seems to be appearing.
>
> Huh? I'd say quite the opposite. I expected more. There are many, many
> people who use perl. Anybody who uses anything will come u
In RFC 72, Peter Heslin gives this example:
:Imagine a very long input string containing data such as this:
:
:... GCAAGAATTGAACTGTAG ...
:
:If you want to match text that matches /GA+C/, but not when it
:follows /G+A+T+/, you cannot at present do so easily.
I haven't tried to work it out exa
> =head2 The C method
> =head3 The C method
Hey! You left out the alternative names NEW / RENEW and BLESS / REBLESS
that we all like! :-(
-Nate
> I'm opposed to an obligation to replace m// and s///. I won't mind the
> ability to give a prototype of "regex" to functions, or even
> *additional* functions, match and subst.
As the RFC basically proposes. The idea is that s///, tr///, and m//
would stay, seemingly unchanged. But they'd actua
In <2914020627.B1479@yogi>, Peter Heslin writes:
[...]
:Bart pointed out that it would be more consistent to use the type of
:syntax you have also (unconsciously?) used:
:
:"abcdef...xyz" =~ /(?<=x+)y/
Nothing unconscious about it: I was suggesting that the cleanest way
to add VLLB would be t
"David L. Nicol" wrote:
> Nathan Wiger wrote:
> >3. There's no way to have them interpolated in strings into
> > something potentially useful.
>
> The string value of a file handle. Hmm. Is it's internal file
> descriptor number?
Umm... that's the numeric value of a file handle, ri
On Wed, 13 Sep 2000 19:57:28 -0700, Nathan Wiger wrote:
>Perl should stop nagging about this. Perl should be smart and not bother
>you about uninitialized values in the following situations:
>
> - string concat
> - string comparison
Allow me to disagree. In my case, I mostly use variables in
> > Do any() and all() have some magic around how they are
> > implemented in von Neumann computers that make them faster than
> > standard CS searching techniques?
>
> I'm probably naive here but shortcuts in a non-parallelized (classical)
> implementation rely on the usual sho
On Thu, Sep 14, 2000 at 06:37:22PM -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 Thu, 14 Sep 2000 12:41:04 -0700, Glenn Linderman wrote:
>> 1) With a string, there can be no compile-time check on the variables.
>> If one isn't found, you can, at best, get a runtime error.
>
>What compile time checks are you expecting on the variables? For example:
Well, for one: "use st
Jeremy Howard wrote:
> Do any() and all() have some magic around how they are implemented in von
> Neumann computers that make them faster than standard CS searching
> techniques?
I'm probably naive here but shortcuts in a non-parallelized (classical)
implementation rely on the usual shortcircui
Nathan Wiger wrote:
(in response to an assertion of preference for undecorated filehandles)
> Well, I think you might be overlooking a couple of important things
> about filehandles. First, having them NOT be scalars caused many
> problems:
>
>1. You must use globs to pass them in and out o
"David L. Nicol" wrote:
> File handles work perfectly well
> right now as undecorated terms with well defined characteristics
Perfectly well?
* Have to use ugly globref syntax to pass them around reliably.
* Not first-class objects, so you can't subclass them.
* Special
>
> Method calls should interpolate in double-quoted strings, and similar
> locations.
>
> print "Today's weather will be $weather->temp degrees and sunny.";
A possibility that does not appear in RFC222.1 is to put tho whole
accessor expression inside curlies:
print "Today's weath
At 17:47 -0400 2000.09.14, Chaim Frenkel wrote:
>> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
>
>CN> No, that won't really work. When my offset from GMT changes for daylight
>CN> savings time, it will break. The point of having a module is that epoch
>CN> conversions are more complicat
John Porter wrote:
> > For more flexibility, the test could look at an inline_tests.t.list
> > file in the cwd to determine *which* .pm's should be tested.
>
> This could be done now, without further ado.
>
> ##
> # testing code here...
> ...
> ##
>
> Podulation
"David L. Nicol" wrote:
>
> I don't know how large a point of view I represent, but I do not agree that
> all data should be decorated like scalars.
Well, I think you might be overlooking a couple of important things
about filehandles. First, having them NOT be scalars caused many
problems:
How much optimization are we talking about?
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.
If you do common subexpression elimination, one opcode may c
>
> All I'm doing is suggesting another way, one that makes more sense for
> beginners:
>
> $a = length @b;
>
> I think we're going to have to see prototypes extended to cope with
> functions like this, anyway. I'll mention this requirement in the
> next version of the RFC.
>
> Nat
Loo
So you're saying that it's ok if people wouldn't want to upgrade on the
basis of one of the improvements, but rather that the aggregation of all
of them had damn well better be worth upgrading for. Fair enough. But
hey, people won't even upgrade to 5.6; when someone asks me "why should
I upgrade t
> =head1 ABSTRACT
>
> Consensus has been reached that filehandles (currently
> barewords) will be revamped to become true $scalars, to
> make them consistent with other Perl variables.
>
> C, C, C, and C should follow suit and be
> renamed C<$STDIN>, C<$STDOUT>, C<$STDERR>, and C<$DATA>, becomi
Bart Lateur <[EMAIL PROTECTED]> writes:
> Now, on those platforms without 64 bit support, a double float has a lot
> more mantissa bits than 32, typically 50-something (on a total of 64
> bits). This means that all integers with up to more than 50 significant
> bits can exactly be represented. Th
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Proposed syntax for matrix element access and slicing.
=head1 VERSION
Maintainer: Buddha Buck <[EMAIL PROTECTED]>
Date: 29 August 2000
Last Modified: 14 September 2000
Mailing List: [EMAIL PROTE
Philip Newton <[EMAIL PROTECTED]> writes:
> You have another assumption up there: that time_t == signed long (since
> you're printing it with %ld) with a resolution of seconds (since you say
> "%ld seconds"). ISO/IEC 9899:1999 (draft C standard, the only C
> standard-y thing I have around) says t
> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
CN> No, that won't really work. When my offset from GMT changes for daylight
CN> savings time, it will break. The point of having a module is that epoch
CN> conversions are more complicated than that. For example, Mac OS epoch
CN> begins a
> Imagine a special "inline_tests.t" which goes through every
> .pm in the distribution's "lib" directory, and runs every
> in-line test it finds directly (WITHOUT extracting it to a .t).
> All we'd need is one; it would be general-purpose, and you
> could just download it from CPAN and stick it
At 08:13 AM 9/15/00 +1100, Damian Conway wrote:
>Piers wrote:
>
>> I'm kind of tempted to look at adding another pragma to go with 'use
>> base' along the lines of:
>>
>> use implements 'Interface';
>>
>> Which is almost entirely like C but with
>> 'Interface' cons
Perl6 RFC Librarian (aka Damian Conway) wrote:
> This RFC (seriously) proposes Perl 6 provide C and C operators,
> and, thereby, conjunctive and disjunctive superpositional types.
>
Great to see this RFC'd--this will makes lots of data crunching code _way_
easier.
Now, I haven't quite finished re
Bradley M. Kuhn wrote:
>
>
>bkuhn wrote:
> > >law,
> > >and it isn't worth putting statements like this in licenses. They are
> > >unenforceable through copyright law, and thus
>
>Ben Tilly wrote:
>
> > I borrowed it from both the BSD and the GPL. Even if it is
> > unenforcable, it is likely to
Piers wrote:
> I'm kind of tempted to look at adding another pragma to go with 'use
> base' along the lines of:
>
> use implements 'Interface';
>
> Which is almost entirely like C but with
> 'Interface' consisting of nothing but:
>
>
> package Interfac
John Porter wrote:
>
> Glenn Linderman wrote:
> >
> > 1) why extract it if it could potentially be used in place
> > 2) if it cannot be used in place, then why bundle it
>
> I tend to agree. If they're stored as podified sections, and
> get extracted to files, then pod has merely been (mis-)use
Bradley M. Kuhn wrote:
>
>Ben Tilly wrote:
>
> > >I believe that is correct as well.
> >
> > Is subset really the word? Should I choose to accept and redistribute
> > using the AL, I should be able to distribute under any terms I choose
>that
> > are consistent with the distribution requirements
Michael G Schwern wrote:
>
> No, it still has all the problems of any other regex-based solution.
> If you shift the code right or left, it breaks (due to the \s{8}) and
> you're back to counting whitespace again.
Y'know, I pointed out before why I think this is a superfluous issue.
You have to
Glenn Linderman wrote:
>
> 1) why extract it if it could potentially be used in place
> 2) if it cannot be used in place, then why bundle it
I tend to agree. If they're stored as podified sections, and
get extracted to files, then pod has merely been (mis-)used as
some kind of shar.
If the t
Glenn Linderman wrote:
> I think $mesg wins up with the value of "1" the way you've coded it.
Sorry, I missed the placement of the (). $mesg is fine.
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
__
On Thu, Sep 14, 2000 at 10:52:16AM -0700, Nathan Wiger wrote:
> Before you scream "Bloody murder", please read on...
I'll wait patiently for the end...
>if( $is_fitting && $is_just ) {
> die subst /\s{8}(.*?\n)/$1/g, qq/
> The old lie
>Dulce et decorum est
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Data: Superpositions
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 14 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 225
Version: 1
Status: Developing
=head1 ABSTRA
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Rationalizing C, C, and C
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 14 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 224
Version: 1
Status: Developing
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
Mailing List: [EMAIL PROTECTED]
Number: 223
Version: 1
Status: Developing
=head1 ABSTRACT
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Hierarchical calls to initializers and destructors
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 1 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 189
Version
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 17 August 2000
Last Modified: 14 September 2000
Nathan Wiger wrote:
> Solves problem #1, indented terminator, except that it adds two newlines
> (more later).
I never found anything later about these extra newlines... so if this idea
has merit, it needs to be finished.
> However, it leaves 2 and 3. Let's try adding in a regexp:
>
>if( $i
On Thu, Sep 14, 2000 at 12:15:28PM -0700, Glenn Linderman wrote:
> 1) why extract it if it could potentially be used in place
> 2) if it cannot be used in place, then why bundle it
>
> So I guess RFC 183 leaves me not understanding its goals. If there
> is a benefit to the bundling, then RFC 183
First of all, I think this is a great idea
On 14 Sep 2000, Perl6 RFC Librarian wrote:
> Are there any contexts besides double quotes ("", qq{}, <<"EOF") where this
> need be applied? What about inside regexes? And if so, left and/or right
> hand side?
Regexes are enough like double quoted str
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interpolation of method calls
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 222
Version: 1
Status: Developing
=head
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interpolation of method calls
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 222
Version: 1
Status: Developing
=head
Ben Tilly wrote:
> The Perl6 RFC Librarian quoth:
> >
> >This and other RFCs are available on the web at
> > http://dev.perl.org/rfc/
> >
> >=head1 TITLE
> >
> >Perl6's License Should Be a Minor Bugfix of Perl5's License
> [...]
> This resolves very few of the IMHO rather serious issues I have
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects should have builtin stringifying STRING method
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 06 Aug 2000
Last Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
STDIN, STDOUT, STDERR, ARGV, and DATA should become scalars
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 04 Aug 2000
Last-Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interpolation of method calls
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 222
Version: 1
Status: Developing
=head
John Porter wrote:
> Chaim Frenkel wrote:
> >
> > Removing -1 as a valid result, could be a breakage (if someone is
> > doing something weird with a negative result)
>
> What, like using it as an index into a substr?
> Bad Code is its own reward, my friend.
>
> > $foo = "flabergasted";
> >
> Bradley M . Kuhn <[EMAIL PROTECTED]> writes:
> >I don't think this is completely out the question, either. I was actually
> >planning on writing an RFC that proposes that all contributions to the core
> >be copyright assigned to Larry.
Nick Ing-Simmons wrote:
> Well if that becomes a require
Ben Tilly wrote:
> >I believe that is correct as well.
>
> Is subset really the word? Should I choose to accept and redistribute
> using the AL, I should be able to distribute under any terms I choose that
> are consistent with the distribution requirements of the AL. This may
> include adding
arrays-of-scalars
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Standard support for opening i/o handles on scalars and
arrays-of-scalars
=head1 VERSION
Maintainer: Eryq (Erik Dorfman) <[EMAIL PROTECTED]>
Date: 23 Aug 2
On Thu, Sep 14, 2000 at 02:19:38PM +0100, Piers Cawley wrote:
> Michael G Schwern <[EMAIL PROTECTED]> writes:
> > package Dog;
> > use fields qw(this night up);
> >
> > my Dog $ph = [];
> > $ph->{this} = "that";
>
> That works? I thought you had to do:
>
> my Dog $self = f
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Exception objects and classes for builtins
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 9 Aug 2000
Last Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Bart Lateur wrote:
> On Wed, 13 Sep 2000 22:49:14 -0700, Glenn Linderman wrote:
>
> >So who needs a special format type? Just need a string. It becomes a
> >format when you use it as such... So just
> >
> > my $frm = <<'.'
> >@<: @
> >$name, $ssn
> >.
>
> I, for one, can
bkuhn wrote:
> >law,
> >and it isn't worth putting statements like this in licenses. They are
> >unenforceable through copyright law, and thus
Ben Tilly wrote:
> I borrowed it from both the BSD and the GPL. Even if it is
> unenforcable, it is likely to discourage people from abusing
> that.
Nathan Torkington <[EMAIL PROTECTED]> writes:
>Dan Sugalski writes:
>> It's possible, for example, for a tied/overloaded/really-darned-strange
>> variable to look true but still be false. If you do:
>>
>>$foo = $bar || $baz;
>>
>> and both $bar and $baz are objects, the 'naive' way is to ma
On Thu, Sep 14, 2000 at 11:49:18AM -0700, Glenn Linderman wrote:
> I'm all for solving problems, and this message attempts to specify 3
> problems, but it needs more specification. You describe three
> problems, but it is not clear what the problems are
Since we've been charging back and forth o
Nick Ing-Simmons wrote:
> Bradley M . Kuhn <[EMAIL PROTECTED]> writes:
> >
> >(Think of it as writing a Last Will and Testament---you can do it on your
> > own in a pinch, but it's always better to write a draft and then have a
> > lawyer help you rewrite it so it's more legally sound, because it
Steve Fink writes:
> I just don't know if I'd bother to switch to Perl6 for a 10% speedup
Speed will *not* be the only reason to switch to perl6. It will (might)
have:
- bytecode compilation
- compile-time checking
- a rational stdlib
- vastly simpler extension mechanism
You can focus on an
> > This reminds me of a related but rather opposite desire I have had
> > more than once: a quotish context that would be otherwise like q() but
> > with some minimal extra typing I could mark a scalar or an array to be
> > expanded as in qq().
>
> I have wanted that also, although I don't remem
This whole debate has got silly.
RFC 111 V1 covered both the whitespace on the terminator and the
indenting - there was a lot of debate that this was two things - more were
in favour of the terminator and there was more debate on the indenting.
Therefore I split this into two RFCs leaving RFC111
On Thu, Sep 14, 2000 at 07:49:32AM -0700, Nathan Wiger wrote:
> > > print 'Today\'s weather will be '.join($", $weather->temp()).
> > > ' degrees and sunny.';
> > >
> > > However if temp() calls wantarray(), the result will be FALSE (scalar).
>
> I think what he's trying to get at i
On Thu, 14 Sep 2000 10:52:16 -0700, Nathan Wiger wrote:
>We already have q//, qq//, and qx// which duplicate their
>functions far more flexibly. Question: Do we really need here docs?
With your above functions, you always need to be able to escape the
string end delimiter. Therefore, you will al
Michael,
Thanks for the explanation. So you see, I'm one of those people that go around
looking for redundancies to eliminate. So when I hear that you want to extract
a .t file from perl source (as specified by the RFC 183), it makes me wonder
1) why extract it if it could potentially be used
Alan Burlison wrote:
>
> Adam Turoff wrote:
>
> > It would have been nicer to institute this policy from the start,
> > but no one expected to get 200 RFCs in just over one month, either.
>
> Indeed - I think everyone was astonished by the rate at which they
> appeared. I just hope the code is
Nathan Torkington wrote:
>
> And there's no law that says some areas can't run *faster* than 10%.
"...where all the children are above average.". 10% across the board
demands that, unless you overclock by 10%. :-)
> But I think we have to be realistic. We all want a programming
> language that
On Thu, 14 Sep 2000 11:58:46 -0400, Mark-Jason Dominus wrote:
>If there are no objections, I will freeze this in twenty-four hours.
Oh, I have a small one: I feel that this speudo-random salt should NOT
affect the standard random generator. I'll clarify: by default, if you
feed the pseudo-random
On 13 Sep 2000 14:22:30 -0700, Russ Allbery wrote:
>I think it should be specified that the return value is seconds since Unix
>epoch and the storage size be left unspecified, from the language
>perspective. On those platforms that support it, using 64 bits is
>obviously a good idea.
64 bits is
On Thu, 14 Sep 2000 08:47:24 -0700, Nathan Wiger wrote:
>One thing to remember is that regex's are already used in a number of
>functions:
>
> @results = grep /^VAR=\w+/, @values;
You are being mislead. You might just as well say that length() is being
used in other functions:
@result
1 - 100 of 175 matches
Mail list logo
