Chris Nandor wrote:
> Interesting. I still think we should have our own real 64-bit time,
> though, since not all platforms will be 64 bit (although by 2020 they may
> be), and perhaps not all of them will be LP64 (and I confess to not know
> what that stands for :).
Simple - LP64 = 'Longs and
It seems to me that there are at least two important things missing
from this proposal.
1. There is no substantive rationale presented for why the change
would be desirable.
The only reasons you put forth are:
* The syntax is ugly and unintuitive.
Ugliness is a matter of opinion, and I d
Several RFCs have been issued that relate to regexes or pattern
matching but which predate the perl6-language-regex list. I have
asked the librarian to transfer ownership of these RFCs to this list.
In the meantime, here is a summary of the outstanding regex-related
RFCs:
72 (v1): The regexp en
Mark-Jason Dominus wrote:
>
> It seems to me that there are at least two important things missing
> from this proposal.
>
> 1. There is no substantive rationale presented for why the change
>would be desirable.
>
> The only reasons you put forth are:
>
> * The syntax is ugly and unintuit
In message <2823054734$[EMAIL PROTECTED]>
Uri Guttman <[EMAIL PROTECTED]> wrote:
> what happens if you modify the hash when you have an iterator? also we
> have to require the iteration order to be fixed for a given hash which
> is not modified so slices and such will remain synchro
Russ Allbery wrote:
> > Or, if we're gonna not go along with the standard time_t, might as well
> > make it 64.
>
> 32 bits is clearly insufficient; I would support that.
Be aware that perl5 already will support a 64-bit time_t if it is
compiled as a 64 bit application. This is because time_t
Mark-Jason Dominus wrote:
> If we're going to standardize on a single time format for all
> platforms, I wish we could choose a good format. Unix time runs out
> in 2038.
Not true. On 64 bit Unix platforms time_t is 64 bit.
Alan Burlison
At 11:05 +0100 2000.08.23, Alan Burlison wrote:
>Be aware that perl5 already will support a 64-bit time_t if it is
>compiled as a 64 bit application. This is because time_t is defined as
>long, and on LP64 platforms (the majority of 64 bit platforms are I
>think), long becomes 64 bit when apps ar
Steven W McDougall wrote:
>
> Does Perl6 support Symmetric MultiProcessing (SMP)?
>
> This is a *huge* issue. It affects everything else that we do with
> threads.
Umm... I don't know what you think you mean by 'SMP', but it doesn't
mean what you think it does. SMP means 'Symmetric Multi Proce
On Sun, 20 Aug 2000 16:32:16 +1000 (EST), Damian Conway said:
>> I think we agree.
> >
> > $foo is a tied variable
> > $bar is a normal variable
> >
> > sub zap : lvalue { return $_[0] ? $foo : $bar }
> >
> > zap(1) = 5; # Goes to tied variabl
iain truskett said
> Hmm. Just reread RFC5 and it doesn't really come out with a strong
> recommendation of anything --- as it says "no clear concensus after [a]
> week's discussion". MLCs are a good thing --- they're just tricky to get
> right.
I'm afraid this is just plain true. As the maintain
On Tue, 22 Aug 2000, Michael Mathews wrote:
> Tom Christiansen said:
> > Because they don't nest.
>
> Nesting is a problem you don't really want to solve, in my opinion. The
> world gets real weird, real fast when you can nest and/or overlap comments.
> Not worth the trouble.
I disag
On 23 Aug 2000, Johan Vromans wrote:
> In any case, commenting out large blocks (more than one visual page)
> is highly confusing unless you can clearly see what is commented out,
> for example, by prefixing every line with a '#' or so.
I don't generally have trouble with this...most
Johan Vromans said
> mm> Nesting is a problem you don't really want to solve, in my opinion.
The
> mm> world gets real weird, real fast when you can nest and/or overlap
comments.
> mm> Not worth the trouble.
>
> If the prime argument for mlc is commenting out large blocks of code
> then you'd bett
* Michael Mathews ([EMAIL PROTECTED]) [24 Aug 2000 01:48]:
> Johan Vromans said
[...]
> > If the prime argument for mlc is commenting out large blocks of code
> > then you'd better solve the nesting problem -- and do it well.
> Really, why? I have yet to hear any C or Java programmers complain
>
Hi,
I've created [EMAIL PROTECTED] which will take over the
discussions currently on bootstrap. The subscription list WILL NOT
be transferred to the new list, but perl6-all is subscribed of
course. If you are not at perl6-all you might want to subscribe to
perl6-meta by sending mail to [EMAIL PRO
Today around 9:33am, [EMAIL PROTECTED] hammered out this masterpiece:
: Karl Glazebrook wrote:
: >
: > Just a test to see if this list is actually alive...
:
: Seems to be. But no great activity yet. Where to start?
Perhaps the issues of where dump() will be in Perl6 should be moved here.
--
> If the prime argument for mlc is commenting out large blocks of code
> then you'd better solve the nesting problem -- and do it well.
vi substitution
:.,+20s/^/##obsoleted Aug 22, 2000 ## /
works really well for the large blocks of code problem, so do
$BOGUS::Comment=<
Thanks, the actual effects of \ in doublequotes slipped my mind.
Nathan Torkington gracefully extolled:
> I'd be more receptive to something that reuses existing or similar
> Perl syntax (e.g., extend ->).
with %container {
->$fieldname = $value;
${->destinationvaluename}
On Wed, Aug 23, 2000 at 12:45:06PM -0500, David L. Nicol wrote:
> with %container {
> ->$fieldname = $value;
> ${->destinationvaluename} = ->value_to_put_there
> }
Then I'd've expected that to have been:
with \%container {
->{$fieldname} = $value;
${->
-Original Message-
From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 23, 2000 1:06 PM
To: David L. Nicol
Cc: Nathan Torkington; [EMAIL PROTECTED]
Subject: Re: PROTOPROPOSAL FOR NEW BACKSLASH is still Re: implied
pascal-like"with" or "express"
[...]
How special p
From: "Damian Conway" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, August 18, 2000 12:56 AM
Subject: Re: implied pascal-like "with" or "express"
> Aha! How about this...which would give us your desired C
functionality
> *and* solve a nagging problem with named arguments:
>
> Suppose C
Michael Mathews <[EMAIL PROTECTED]> writes:
>
>Really, why? I have yet to hear any C or Java programmers complain about the
>fact that you cannot nest /*...*/ comments.
Well _this_ C programmer just does
#if 0
#endif
And come to that
if (0) {
}
in perl.
--
Nick Ing-Simmons
dLux wrote:
>
> I've posted an RFC about transaction-enabled variables (RFC130:
> http://dev.perl.org/rfc/130.pod), but I didn't get too much response
I think the RFC looks fine. This would be nice thing for perl to have.
--
John Porter
Larry Wall wrote:
>
> Dan Sugalski writes:
> : At 10:35 AM 8/19/00 +1000, Damian Conway wrote:
> : >However, for Perl 6 I'd really like to see run-time access to the
> : >Real Tokenizer (tm):
> : >
> : > use tokenizer;
> : >
> : > my $tree = tokenizer( $sourcecode );
> : >
> : >Th
> So if all I want to do is make sure that certain attributes are positive
> integers, I have to do this:
>
>[ admittedly ungainly solutions snipped ]
>
> I'd much prefer a solution where the positive-only logic was in a method
> belonging to the class, rather than being
Tom Christiansen wrote:
>
> >2) The ability to dump out a variable and all its attached state into
> >something that can be loaded in later somewhere else.
>
> To hope to do this completely and correctly is courageous.
>
> my @funx = ();
> for my $name (qw/violet purple cream/) {
>
Ariel Scolnicov wrote:
>
> print < The next line contains a space at the end.
> END
> This is still a here document
> END
>
> This can be very hard to discover. I find it hard to see myself doing
> this on purpose.
I agree with Larry that Perl should Do The Right Thing, bu
dLux wrote:
>
> Hello!
>
> I've posted an RFC about transaction-enabled variables (RFC130:
> http://dev.perl.org/rfc/130.pod), but I didn't get too much response
> about that. Does anyone have comment about that? I want to clarify
> the language part of that (new keyword, new pra
Markus Peter wrote:
> --On 23.08.2000 4:31 Uhr + Perl6 RFC Librarian wrote:
>
> > The calling syntaces of m()/s() should be consistent with other forms of
> > function call; this should be achieved not by eliminating the traditional
> > C form from m()/s(), but by allowing any function to be
At 11:18 AM 8/23/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: At 10:35 AM 8/19/00 +1000, Damian Conway wrote:
>: >However, for Perl 6 I'd really like to see run-time access to the
>: >Real Tokenizer (tm):
>: >
>: > use tokenizer;
>: >
>: > my $tree = tokenizer( $sourcecode
At 11:32 AM 8/23/00 -0700, Larry Wall wrote:
>Tom Christiansen writes:
>: >2) The ability to dump out a variable and all its attached state into
>: >something that can be loaded in later somewhere else.
>:
>: To hope to do this completely and correctly is courageous.
>:
>: my @funx = ();
>:
> If you want to save the world, come up with a better way to say "www".
> (And make it stick...)
The funniest thing I've ever read is that Tim Berners-Lee's wife
supposedly criticized the term "www" because "world wide web" was
shorter to say than "www" (3 syllables vs. 9).
-Nate
>2) The ability to dump out a variable and all its attached state into
>something that can be loaded in later somewhere else.
To hope to do this completely and correctly is courageous.
my @funx = ();
for my $name (qw/violet purple cream/) {
push @funx, sub {
print "I
Tom Christiansen writes:
: >2) The ability to dump out a variable and all its attached state into
: >something that can be loaded in later somewhere else.
:
: To hope to do this completely and correctly is courageous.
:
: my @funx = ();
: for my $name (qw/violet purple cream/) {
:
* Johan Vromans ([EMAIL PROTECTED]) [23 Aug 2000 18:25]:
[...]
> In any case, commenting out large blocks (more than one visual page)
> is highly confusing unless you can clearly see what is commented out,
> for example, by prefixing every line with a '#' or so.
Or use an editor which colours it,
* Johan Vromans ([EMAIL PROTECTED]) [24 Aug 2000 06:59]:
> iain truskett <[EMAIL PROTECTED]> writes:
> > > With SLC, discarding a line if it starts with a # (after optional
> > > whitespace) is straightforward, fail safe, and fast.
> >
> > Almost. You can have # in other places on the line. It d
iain truskett <[EMAIL PROTECTED]> writes:
> It's not *that* slow. Just means the parser is looking for /* as well as
> */ ...
And "/*" and ""/*" and '/*' and qw(*/) and #*/ and \#*/ and m/.*/ ...
With MLC, you need to _parse_ the comments. What happens if you find a
unterminated quoted string i
[Quoting Michael Mathews, on August 23 2000, 11:45, in "Re: why not just use"]
> Really, why? I have yet to hear any C or Java programmers complain
> about the fact that you cannot nest /*...*/ comments.
In their official (published!) coding standards, Sun explicitly states
that one should use th
You are certainly not the first nor only person to say this. You should know
that this point-of-view is listed in the final RFC, although it is not quite
the majority opinion of all the comments I've received.
--Michael
Johan Vromans said:
>
> In my opinion, there is no need in Perl for multi-li
"Michael Mathews" <[EMAIL PROTECTED]> writes:
> Nesting is a problem you don't really want to solve, in my opinion. The
> world gets real weird, real fast when you can nest and/or overlap comments.
> Not worth the trouble.
If the prime argument for mlc is commenting out large blocks of code
then
On Wed, 23 Aug 2000, Buddha Buck wrote:
> Perhaps someone should RFC the new special variable &ME, which is
> predefined to be the whole program. Who knows? Perhaps it would then make
> sense to use @_ at the top level, as if the program was invoked as
> "&ME(@ARGV);"...
Doesn't a lot of OO
dLux wrote:
>
>
> Thanks guys, you convinced me this is not a dead thing.
>
> I got some suggestion (2 phase commit support, DBI integration,
> other data source integration) from Glenn Linderman. I will improve
> this RFC with those things.
I might have mentioned this before, but I t
At 03:47 PM 8/23/00 -0400, David Corbin wrote:
>Tom Christiansen wrote:
> >
> > >2) The ability to dump out a variable and all its attached state into
> > >something that can be loaded in later somewhere else.
> >
> > To hope to do this completely and correctly is courageous.
> >
> > my @funx
Steve Fink wrote:
>
> (Off-topic for this list, but I'm not sure where else to send it)
>
> Could we have a discussion somewhere of useful filtering rules for all
> these perl6 lists? Specifically, I'm looking to steal other people's
> .procmailrc snippets. I imagine that a lot of people have wr
Hello!
I've posted an RFC about transaction-enabled variables (RFC130:
http://dev.perl.org/rfc/130.pod), but I didn't get too much response
about that. Does anyone have comment about that? I want to clarify
the language part of that (new keyword, new pragma), and if it is
clear,
John Porter wrote:
> [to you only, as this thread is now distinctly off-topic for perl6-language]
Well, as Peter pointed out, I managed to utterly mis-edit my headers.
And now I can't think of an appropriate expletive to express how I feel
about it.
Guess I'm just glad what I wrote wasn't rea
> Doesn't a lot of OO work (esp. on the Mac) tend to do this?
>
> The first thing they do in their application is instantiate an
> application (mainly, itself, without the application instantiation) and
> run it.
That's right. All "pure" object-oriented languages work this way: th
> I was wondering this morning whether we ought to write the Perl 6
> parser as a set of recursive regexes. Might make it easier to plug in
> new productions on the fly. And designing the parser around regexes
> might indicate ways in which Perl's regexes are not yet powerful
> enough.
>
There'
> my var; # declaring a scalar
> my array[]; # declaring an array
> my hash{}; # declaring a hash
Though the declarations seem fine, I assume that you propose this to be
optional at usage time, since variable interpolations such as
"xxx${var1}xxx${var2}xxx" really need the prefix. One of
Personally, I prefer a python, or matlab implementation:
array1 = array2[ start : stop ].
Of course, In perl we have the .. operator. This method has just always
seemed intuitive to me. Granted an explicit function call (or gasp, another
reg-ex like call), aids the newbies eyes. The trick in
/--- On Wed, Aug 23, 2000 at 03:49:02PM -0400, David Corbin wrote:
| I think it would be a good thing, and would be another things can
| distinguish Perl from the other languages like pattern matching
| once
| did. It strikes me as one of those things that are going to end up
| adding a whol
> Collected ideas (mostly not my own):
>
> EXPR /pattern/
> EXPR m/pattern/
> /pattern/ EXPR
> m(EXPR)/pattern/
> /pattern/->(EXPR)
> EXPR<-/pattern/
> EXPR<=/pattern/
> EXPR ~ /pattern/
> match(/pattern/, EXPR)
> EXPR ? /pattern/
The mythical (and insistent) 'in' operator to rescue?
$p
> The mythical (and insistent) 'in' operator to rescue?
I don't think so. "In" doesn't mean "matches".
>$pattern in @expr
any(@expr) =~ $pattern
all(@expr) =~ $pattern
>@pattern in $expr
$expr =~ any(@pattern)
$expr =~ all(@pattern)
>@pattern in @expr
any(@expr) =~
Steve Fink wrote:
> I couldn't for the life of me
> remember whether it was ~= or =~. I've also observed one perl beginner
> look up the symbol in a book every single time she needed it for a new
> program.
all the self-assignment operators are operator, then equal-sign.
=~ is not a self-assig
> I'm not concerned about / being mistaken for division, since that
> ambiguity already exists with bare /pat/ matches.
Yes, but the current ambiguity is resolved from context in a rather
complicated way. Nevertheless it turns out that Perl does the right
thing in most cases. You are proposin
Mark-Jason Dominus writes:
: It may turn out that the new notation really does have exactly the
: same ambiguities, but that's not clear to me now. All I said was that
: I would like to see some discussion of it.
Operator vs term processing would presumably treat any initial / as it
does now (in
Larry Wall wrote:
>
> The problem here is that I think =~ does one thing right--it brings the
> "topic" out front. Hiding the variable to be modified clear out at the
> end of a big regex is not going to be a winner. It's bad enough that
> the /x modifier comes at the end.
>
> More generally,
>But I agree that such examples would certainly make a better argument.
>The only concrete thing I can come up with is that I and several other
>perl coders I know had a lot of trouble remembering the =~ symbol. I've
>been a very frequent perl user for about 8 years, and after I didn't use
>perl f
> And that's just too much punctuation for too little value.
>
> How special purpose is "with"? Do people envision using it *only* on
> hashes? (I did until this email) If so, I like Damian's version best:
>
> http://www.mail-archive.com/perl6-language@perl.org/msg02649.html
Markus Peter <[EMAIL PROTECTED]> writes:
> --On 22.08.2000 18:24 Uhr + David L. Nicol wrote:
>
> >
> > Regardless of what its called, in a method called as a subroutine,
> > the variable could refer to the last instance of this kind of object
> > used by this thread.
>
> Hmm Does that m
Buddha Buck <[EMAIL PROTECTED]> wrote:
=
=At 11:26 AM 8/23/00 -0700, Larry Wall wrote:
=
=>I expect that we'll get more compile-time benefit from
=>
=> my HASH sub foo {
=> ...
=> }
=>
=> %bar = foo();
=
=So how would you fill in the type in:
=
=my TYPE sub foo {
= ...
=
On Wed, 23 Aug 2000, Benjamin Stuhl wrote:
> While I approve of this RFC, there are a few places where
> it proposes (unnecessary) new primatives. Most of these
> already exist or have planned names (in perl5).
>
> > The Thread module should add a C keyword or
> > function that explicitly
> > ac
In message <[EMAIL PROTECTED]>
Larry Wall <[EMAIL PROTECTED]> wrote:
> Dan Sugalski writes:
>
> : I have had the "Well, Duh!" flash, though, and now do realize that having
> : multiple iterators over a hash or array simultaneously could be rather
> : handy.
>
> You can also have the opp
On Thu, Aug 24, 2000 at 08:41:46AM +1000, iain truskett wrote:
> Does it try to parse other escape sequences (such as \t, \n, \r etc.) or
> just the Unicode one?
No, just the Unicode escapes. Think of it as trigraphs in C -- it's
there so you can translate code from a more-featureful character s
iain truskett noted:
> Anyway: rfc5 claims to be frozen so this is probably a useless
> discussion anyway.
Hmmm yes, there is that litle detail. So where was all this insightful
discussion two weeks ago!!?? Hmmm??!!!
Actually I might ask the Librarian for some flexibility on this if anyone
c
iain truskett said:
> Well, personally I was busy with work and uni. Still am, but less
> so.
My chide was only meant nicely. Of course everyone's experience and insight
is a needed contribution to the discussion.
> I'd say that no RFC should be frozen until the deadline for all RFCs.
> People
On Thu, Aug 24, 2000 at 06:53:31AM +1000, iain truskett wrote:
> >/* File: C:\user\jv\demo.java */
>
> > t.java:1: Invalid escape character.
> > /* File: C:\user\jv\demo.java */
>
> In that situation, I would say that the java compiler isn't really doing
> what it should be doing. i.e. That
* Damien Neil ([EMAIL PROTECTED]) [24 Aug 2000 08:27]:
> On Thu, Aug 24, 2000 at 06:53:31AM +1000, iain truskett wrote:
> > >/* File: C:\user\jv\demo.java */
> >
> > > t.java:1: Invalid escape character.
> > > /* File: C:\user\jv\demo.java */
> > In that situation, I would say that the java
I would have assumed that a pre/post/invariant would not be used regularly,
but rather under optional control. So this would lose that feature.
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> So if all I want to do is make sure that certain attributes are positive
>> integers, I hav
> I would have assumed that a pre/post/invariant would not be used regularly,
> but rather under optional control. So this would lose that feature.
The option is to opt out of preconditions, not opt in.
Besides, I intend to propose an attribute that makes them un-opt-out-able:
sub
Randal L. Schwartz writes:
: > "Joe" == Joe McMahon <[EMAIL PROTECTED]> writes:
:
: Joe> This is done by using SNOBOL's dynamic function evaluation and
: Joe> conditional assignment during a pattern match. To do this kind of
: Joe> thing in Perl, we'd need to be able to match a substring, and
Randal L. Schwartz writes:
> Joe> thing in Perl, we'd need to be able to match a substring, and
> Joe> then call an arbitrary function in the middle of a pattern match,
> Joe> and to back out the call if the match failed.
>
> Already done in 5.6. :) "perldoc perlre".
Anyone who has actually tri
On Wed, 23 Aug 2000 17:24:23 -0600 (MDT), Nathan Torkington wrote:
>Compile the main() program code into a subroutine called 0, and you're
>off!
>
> &0 anyone? :-)
>
>(that's digit 0, by analogy to $0)
What would be nice about this, is that then you could use "return" in a
script to stop execu
Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal
errors, people that want to write fatal errors can switch to using "warn
...; exit ( 250 );" instead of "die ...;" like they do today. [Tongue
firmly planted on cheek.]
Bart Lateur wrote:
> On Wed, 23 Aug 2000 17:24:23 -
--On 23.08.2000 17:26 Uhr -0700 Glenn Linderman wrote:
> Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal
> errors, people that want to write fatal errors can switch to using "warn
> ...; exit ( 250 );" instead of "die ...;" like they do today. [Tongue
> firmly plante
Buddha Buck wrote:
> Perhaps someone should RFC the new special variable &ME, which is
> predefined to be the whole program. Who knows? Perhaps it would then make
> sense to use @_ at the top level, as if the program was invoked as
> "&ME(@ARGV);"...
on -objects it has been proposed that &ME i
> If something fails, you should care.
Maybe.
> The 'strict' pragma (or whatever form it takes in perl6) should
> include in its 'default set of strictness' a new subpragma, 'system'.
> This subpragma has the following semantics:
Ok, I can live with a pragma. :-) However, I do think that "syst
Hello
Before I write an RFC about that topic, is there anybody else who thinks
the CORE:: package should be consistent in it's behaviour (especially for
symbol table manipulations and access) with all other packages?
For comparison:
print Dumper(\%{*{"main::"}});
$VAR1 = {
'@' => *{'
David L. Nicol wrote:
>
> RFC: It's all exception handling. I imagine the core syntax description
> as a set of catch clauses. Every token generates a "TOKEN-$whatever"
> exception, which is caught according to the current situation. How's
> that for a general paradigm? These things can be o
Larry Wall writes:
> Now all we have to do is make the program a variable, and the two
> requirements become one.
Compile the main() program code into a subroutine called 0, and you're
off!
&0 anyone? :-)
(that's digit 0, by analogy to $0)
Nat
> "Joe" == Joe McMahon <[EMAIL PROTECTED]> writes:
Joe> This is done by using SNOBOL's dynamic function evaluation and
Joe> conditional assignment during a pattern match. To do this kind of
Joe> thing in Perl, we'd need to be able to match a substring, and
Joe> then call an arbitrary function
On Mon, 21 Aug 2000 18:21:00 -0700 (PDT), Larry Wall wrote:
>If you want to save the world, come up with a better way to say "www".
>(And make it stick...)
"The world"? This problem only exists in English!
We pronounce it something similar to "way way way".
--
Bart.
Peter Scott wrote:
>
> If we were prepared to mandate that all system calls should return
> a value indicating success or failure *and nothing else*, I would
> probably not object to RFC 140 as is, but I think that would be
> unnecessarily crippling on the language.
Agreed. If one wants to make
On Tue, Aug 22, 2000 at 11:07:44PM -0700, Peter Scott wrote:
> At 04:32 AM 8/23/00 +, Perl6 RFC Librarian wrote:
> >One Should Not Get Away With Ignoring System Call Errors
> > Mailing List: [EMAIL PROTECTED]
>
> I think this should be perl6-language-errors
I scoured the -errors but all I
>"The first operation done on the return value of open() shall be defined()
>or you shall regret your pitiful existence."? (a flag on the scalar coming
>from open that makes any other op than defined() to die and defined() clears
>the flag)
No -- just true or false suffices.
--tom
On Wed, Aug 23, 2000 at 08:17:18AM -0600, Tom Christiansen wrote:
> >"The first operation done on the return value of open() shall be defined()
> >or you shall regret your pitiful existence."? (a flag on the scalar coming
> >from open that makes any other op than defined() to die and defined() cle
> Glenn Linderman wrote:
>
> I'm now reaching the conclusion that RFC 88 is apparently building
> more mechanism around item 2 to make it prettier for use as a
> general exception mechanism. If so, I don't think that is a
> good idea.
In some ways you are oversimplifying the problem, and in othe
On Wed, Aug 23, 2000 at 04:32:43AM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> One Should Not Get Away With Ignoring System Call Errors
>
> =head1 ABSTRACT
>
> =head1 EXECUTIVE SUMMARY
>
> If something fails, you should care.
>
> =head1 DESCRIPTION
>
> The 'strict' pragma (or whateve
Peter Scott wrote:
> At 02:37 PM 8/23/00 -0700, Glenn Linderman wrote:
> > > This means that die can be trapped by catch, and
> > > that throw can be trapped by eval.
> >
> >Blecch. Orthogonality of the mechanisms is easier to understand than funny
> >rules, special cases, and syntactical magic.
This just popped into my head after reading Jarko's RFC. I had some
DBI heavy code which was making use of RaiseError. So like a good
programmer I'd wrapped all my DBI code in eval blocks. However, there
were a few cases where I forgot to check $@ after a block! This
allowed errors to silently
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes:
DLN> Dan Sugalski wrote:
>>
>> Any variable that has a 'per-thread' component should be self-contained.
>>
>> Dan
DLN> We don't know how many instances of iteration happening in the
DLN> program there will be, or how many there can be.
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> Dan Sugalski writes:
LW> : I have had the "Well, Duh!" flash, though, and now do realize that having
LW> : multiple iterators over a hash or array simultaneously could be rather handy.
LW> You can also have the opposite "Well, Duh!" flash
--On 22.08.2000 22:11 Uhr + David L. Nicol wrote:
>
> $one{two} is $one\two
> $$one{two}{three} is $one\two\three
> $$$one{two}{three}{four} is $one\two\three\four
This has nothing to do with the problem with 'with' (and is probably the
wrong mailing lis
> You can have your cake, but not force us to eat it too...
>
> Like $AUTOLOAD, $ME would be dynamically scoped:
The first time I saw the bareword "self" keyword I almost wet myself in
horror, but I would say that $AUTOLOAD is a disaster that should not be
repeated. And that's the way that this
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
AB> Writing your own threading library as part of perl6 is a non-starter,
AB> because to do so requires cooperation from and intimate knowledge of the
AB> OS - for example the way threding is implemented on Linux and Solaris
AB> are radicall
Many people have commented on this, and made good suggestions, with the
trend generally heading toward explicit counters rather than implicit
counters.
I won't add to that drift, except to request that *if* an implicit solution
is implemented ($# was suggested in the original RFC), that the im
> Buddha Buck wrote:
>
> > Perhaps someone should RFC the new special variable &ME, which is
> > predefined to be the whole program. Who knows? Perhaps it would then make
> > sense to use @_ at the top level, as if the program was invoked as
> > "&ME(@ARGV);"...
>
> on -objects it has been pro
On Wed, Aug 23, 2000 at 11:59:15PM -0400, Buddha Buck wrote:
> How about a @CALLER array, with each element being a reference to the
> invoking function in the call-back stack. $CALLER[0] would be
> equivilant to \&ME, $CALLER[1] would be the sub that called &ME, etc,
> and then $CALLER[-1] wo
On Wed, 23 Aug 2000, Bart Lateur wrote:
> On Mon, 21 Aug 2000 18:21:00 -0700 (PDT), Larry Wall wrote:
>
> >If you want to save the world, come up with a better way to say "www".
> >(And make it stick...)
>
> "The world"? This problem only exists in English!
>
> We pronounce it something similar
1 - 100 of 180 matches
Mail list logo
