On Wed, Aug 23, 2000 at 11:43:04PM -0400, Uri Guttman 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...)
[snip of other possibilities]
> the variation i learned somewhere was
Tony Olekshy wrote:
> Glenn Linderman wrote:
> >
> > Just to point out that fatal is, indeed, as several people keep
> > saying, truly in the eye of the catcher.
> >
> > That said, none of the currently proposed mechanisms permit
> > "resume from fault" semantics, much less "resume from hardware
Glenn Linderman wrote:
>
> Just to point out that fatal is, indeed, as several people keep
> saying, truly in the eye of the catcher.
>
> That said, none of the currently proposed mechanisms permit
> "resume from fault" semantics, much less "resume from hardware
> fault" semantics. Sounds like go
Dan Sugalski wrote:
> At 02:48 AM 8/24/00 +0200, Markus Peter wrote:
>
> >--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
> >>...;
Dan Sugalski wrote:
>
> Markus Peter wrote:
>
> > There is no such thing as an ultimately fatal error - it should
> > always be up to the user of a module wether the program should
> > die, but I guess you see that the same and will answer me with
> > "use eval" then ;-)
>
> I hope you're speakin
At 02:48 AM 8/24/00 +0200, Markus Peter wrote:
>--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 .
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
> 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
> "BCW" == Bryan C Warnock <[EMAIL PROTECTED]> writes:
BCW> 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...)
>>
>> "Th
Nathan Torkington wrote:
>
> use strict 'types';
>
> To turn Perl into full B&D mode.
I think you mean S&M mode.
> Be afraid. Be very afraid.
I think I'm gonna hurl!
As long as it's a *pragma*, feel free to torture yourself in whatever
sick ways you desire. ;-)
-Nate
On the subject of 'strict', I'm looking forward (once the typing
proposals string out) to having
use strict 'types';
To turn Perl into full B&D mode. This will also enable maximum
optimizations.
I'm picturing type-checking at this level:
my hash %a;
my StructuredHash %b;
%b = %a;
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
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 = {
'@' => *{'
> 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
--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
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 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
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
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
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.
> "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
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
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
> 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'
> 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
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
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
/--- 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
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
> 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
Dan Sugalski writes:
: And do we want to consider making this (and its ilk) Do The Right Thing?
:
:(@foo, @bar) = (@bar, @foo);
We certainly want to consider it, though perhaps not in -internals.
You can talk about passing @bar and @foo around as lazy lists, and
maybe even do lazy list-flatt
> I was wondering this morning whether we ought to write the Perl 6
> parser as a set of recursive regexes.
That would also solve one of my nagging headaches:
RFC XXX: Parse::RecDescent 2.0 *is* Perl 6.0
Of course, then we'd have to have Perl 6 out "by Christmas"!
;-)
Damian
P
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
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 = ();
>:
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
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
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
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/) {
>
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
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
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
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/) {
:
>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
> 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
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
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 );
: >
: >This would be dead handy for building sourc
From: "dLux" <[EMAIL PROTECTED]>
Sent: Wednesday, August 23, 2000 7:32 AM
Subject: transaction-enabled variables
> 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 commen
Perl6 RFC Librarian wrote:
> =head2 Cheating Is Still Possible
>
> Not ignoring the return value is of course no guarantee of doing
> anything useful with the return value:
>
> $so_what++ unless defined fork();
>
> But detecting whether 'something useful' is done is squarely in
> the re
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 );
>
>This would be dead handy for building source-code filtering modules,
>rather than
At 09:37 AM 8/23/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: What I've been hoping for is:
>:
>: 1) The ability to dump the program and its current state out into something
>: that can be reloaded later. (Though filehandles and other
>: external-interface things make this tricky)
>:
>: 2)
David Corbin wrote:
> >
> > For the remainder of the enclosing block, the barewords var,
> > array and hash are to be interpreted as references to a scalar, an
> > array, and a hash.
>
> I'm confused by this statement. Are you suggesting an alternative to
> the original RFC?
No, I was trying
At 09:37 AM 8/23/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: What I've been hoping for is:
>:
>: 1) The ability to dump the program and its current state out into something
>: that can be reloaded later. (Though filehandles and other
>: external-interface things make this tricky)
>:
>: 2)
Dan Sugalski writes:
: What I've been hoping for is:
:
: 1) The ability to dump the program and its current state out into something
: that can be reloaded later. (Though filehandles and other
: external-interface things make this tricky)
:
: 2) The ability to dump out a variable and all its a
"David L. Nicol" wrote:
>
> >
> > Consider the following syntax:
> >
> > my var; # declaring a scalar
> > my array[]; # declaring an array
> > my hash{};# declaring a hash
>
> For the remainder of the enclosing block, the barewords var,
> array and hash are to be interpreted as r
At 06:00 PM 8/21/00 -0700, Larry Wall wrote:
>[EMAIL PROTECTED] writes:
>: How about this then:
>:
>: In a void context, C dumps the program's current opcode representation
>: to its filehandle argument (or STDOUT, by default).
>
>It's not clear to me that reusing a lame keyword for this is the
>h
--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 called with
> C.
I'm not so s
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
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
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,
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
60 matches
Mail list logo
