On Wed, 23 Aug 2000 18:02:21 -0700, Nathan Wiger wrote:
>I hate it, it's miserable. Too much hidden trickery and special cases.
Quite the countrary, I should think. Have you seen the subs
self_or_default and self_or_CGI in the source of CGI.pm? These serve to
check if a sub is called as a functi
Glenn Linderman wrote:
>
> Tony Olekshy wrote:
>
> > Hi, it's me again. Not to be a pain, but RFC 88 does say:
>
> Hey, no pain.
>
> > retry
>
> I do recall seeing this quote; however, replacing AUTOLOAD is a very
> specific instance of resuming from or retrying a fault condition. And
> e
Glenn Linderman wrote:
>
> These three recent postings expressing ways to implement the
> differences between RFC 119 and RFC 88 are encouraging. With a
> bit of syntactic sugar, it looks like RFC 88 can be made to handle
> all the cases I care about. Now if you'd just get rid of that
> "try"...
Tony Olekshy wrote:
> Chaim Frenkel wrote:
> >
> > Tony Olekshy wrote:
> >
> > > If no exception is in scope Perl should continue to generate and
> > > propagate exceptions (die and $@) as it does now, so we don't
> > > break tradition.
> >
> > No, that should be the difference between die and th
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
> : =~ has no real world equivalent, and in fact I don't know how to
> : pronounce it in English so that $x =~ /a/ makes sense.
>
> Yes, that's all pretty much on the mark.
Not true, IMO. In math, =~ is used to indicate "rough equivalence".
(Actually, the ~ goes on top of the =, but this is a mi
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
> >>...;
I've sent this version to the RFC librarian, but it hasn't shown
up yet. Until it does, it's available at:
Formatted: http://www.avrasoft.com/perl/rfc/rfc88v2.htm
POD as text: http://www.avrasoft.com/perl/rfc/rfc88v2.txt
This doesn't include Peter's latest changes yet, none of which
are show-
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 01:49 PM 8/23/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: At 11:30 AM 8/23/00 -0700, Larry Wall 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
>
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 .
Glenn Linderman wrote:
>
> Tony Olekshy wrote:
>
> > Glenn Linderman wrote (in RFC 119 v2):
> > >
> > > It is not clear whether the finally clause is executed if
> > > the try statement is exited via a goto or return, but the
> > > statement is made that once a try statement is entered, it
Jarkko Hietaniemi wrote:
>
> I don't think we should assume that we can't scratch our nose without
> getting overly object-happy. For the particular aspect I'm driving at
> there is no *need* for objects of any kind, no catch, no throw, no
> structured exceptions: I want the program simply to _d
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
Peter Scott wrote:
>
> At 10:13 AM 8/23/00 -0600, Tony Olekshy wrote:
>
> >Making throw a method of Exception just means we don't have to say
> >
> > throw Exception->new("Can't foo.", tag => "ABC.1234", ...);
> >
> >and it means throw isn't a new keyword, and that throw $@ can,
> >invoked now
Chaim Frenkel wrote:
>
> Tony Olekshy wrote:
>
> > If no exception is in scope Perl should continue to generate and
> > propagate exceptions (die and $@) as it does now, so we don't
> > break tradition.
>
> No, that should be the difference between die and throw. Die is
> immediately fatal. (i.
Glenn Linderman wrote:
>
> Tony Olekshy wrote:
>
> > > 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
Other than for the except and always clauses, RFC 199 is very
similar to RFC 88. I like the idea behind except and always,
but I think the proposed implementation could be dramatically
simplified.
The first thing to realize is that just because 119 doesn't say
"try" the doesn't mean it isn't the
Some discussion has suggested that it might be a good idea if it
were possible to have a simple way to prevent catch from catching
so-called "fatal" errors. Some fringe ideas have actually included
two seperate mechanisms, one for so-called fatal errors (based on
die), and one for so-called non-f
To use a $20 OO word, polymorphism. But this applies even if
$@ isn't an instance of an OO class, as explained herein.
If die/throw can put any data they want in $@, then before a
exception can be conditionally caught, the value of $@ must be
checked to see if it conforms to the intended check.
> 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
On Tue, 22 Aug 2000 00:03:48 -0600 (MDT), Nathan Torkington wrote:
>Normally what you'd say is:
>
> with (%record) {
>
> }
>
>(look at me, using Larry's new ... operator :-)
No you didn't. You typed four dots.
--
Bart.
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;
At 05:20 PM 8/23/00 -0700, Glenn Linderman wrote:
I'd appreciate your description of what you meant by orthogonal, it certainly
>doesn't fit my definition, or that of my dictionaries, as far as I understand
>mathematics. This dissertation on the meaning of the word orthogonal is, of
>course, some
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> At 02:28 PM 8/23/00 -0700, Glenn Linderman wrote:
>> Chaim Frenkel wrote:
>>
>> > No, that should be the difference between die and throw. Die is
>> > immediately fatal. (i.e. current semantics) throw is new and does
>> > the magic.
>> >
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
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
> 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
--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 -
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.
> "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
--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
> "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
> "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.
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
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
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
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
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
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 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'
At 04:38 PM 8/22/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > I thought the discussion was around how
> >
> > throw object;
> >
> > could be a run-time error if object ! isa Exception (which is
> > what I think should happen) if
> >
> > throw LIST;
> >
> > had to hav
> 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) =~
* 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
> 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
> 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
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
> 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
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
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
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
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
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
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
> I believe Dan said that he wanted to make objects a lot faster in P6. I
> don't think we should be precluded from requesting Things That Make Sense
> (tm) just because the current implementation is sub-optimal in performance
> if nothing inherently prevents a better implementation.
I don't
>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
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.
But that *is* being orthogonal
At 08:36 AM 8/23/00 -0600, Tony Olekshy wrote:
>Jarkko Hietaniemi wrote:
> >
> > On Tue, Aug 22, 2000 at 11:07:44PM -0700, Peter Scott wrote:
> > >
> > > I think this should be perl6-language-errors
> >
> > I scoured the -errors but all I could see was fancy-schmanzy talk
> > about OOish exception
Peter Scott wrote:
> Yes, we get breakage; the user expects die to be trapped by eval.
It still would be.
> Users of
> Error.pm also expect it to be trapped by catch.
It still would be, if you 'use Error.pm'.
> I do not think we should
> maintain die/eval as a separate mechanism from try/catc
At 10:13 AM 8/23/00 -0600, Tony Olekshy wrote:
>Making throw a method of Exception just means we don't have to say
>
> throw Exception->new("Can't foo.", tag => "ABC.1234", ...);
>
>and it means throw isn't a new keyword, and that throw $@ can,
>invoked now as an instance method rather than a
At 02:28 PM 8/23/00 -0700, Glenn Linderman wrote:
>Chaim Frenkel wrote:
>
> > No, that should be the difference between die and throw. Die is
> > immediately fatal. (i.e. current semantics) throw is new and does
> > the magic.
> >
> > We get no breakage that way.
>
>Hear, hear. That's (some of) w
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
At 12:41 PM 8/23/00 -0700, Glenn Linderman wrote:
> > > But on the other hand, if you really want to trap both fatal and
> > > non-fatal errors, doing it via a single general exception
> > > mechanism is nice. How can we achieve both?
> >
> > RFC 88 already achieves both, like this:
> >
> >
Chaim Frenkel wrote:
> No, that should be the difference between die and throw. Die is
> immediately fatal. (i.e. current semantics) throw is new and does
> the magic.
>
> We get no breakage that way.
Hear, hear. That's (some of) what RFC 119 proposes. Keep fatal error handling
and non-fatal e
At 04:31 PM 8/23/00 -0400, Chaim Frenkel wrote:
> > "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
>
> >> The unwind logic would treat a scope with no exception set _as if_
> >> each call were wrapped in at try block.
>
>TO> I don't think so. If no exception is in scope Perl should continue
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 {
= ...
=
* 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:
> > 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 doesn't have to
> be at the start (with or without whitespace).
I w
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,
> 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
* Johan Vromans ([EMAIL PROTECTED]) [24 Aug 2000 06:39]:
> 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/.*/ ...
Of course. But see below.
> With
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
Dan Sugalski writes:
: At 11:30 AM 8/23/00 -0700, Larry Wall 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 opposite "W
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
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
> 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
[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
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
> 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
> "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
>> The unwind logic would treat a scope with no exception set _as if_
>> each call were wrapped in at try block.
TO> I don't think so. If no exception is in scope Perl should continue
TO> to generate and propagate exceptions (die and $@) as
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 writes:
: Despite all that, I don't have strong feelings about this RFC. I just
: thought it would be an interesting idea to bring to Larry's eyes.
Well, the fact is, I've been thinking about possible ways to get rid
of =~ for some time now, so I certainly don't mind brainstorming in
t
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
At 11:26 AM 8/23/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: The core will already know.
>
>Especially if we add return types.
Sure. Can't hurt to add code to optimize 'old-style' perl 5 code either,
though.
>: Whether this justifies exposing the information's for someone else to
>: ju
1 - 100 of 180 matches
Mail list logo
