2004-02-26T14:26:47 Larry Wall:
> Well now, I remember Perl 0, sonny.
Does that still exist anywhere? I don't have anything older than
perl 1.
> They don't make 'em like they used to...
That they don't. On Bent Linux (my own distro, based on uClibc
instead of glibc) I get
; ls -l perl1 perl5.8.
2003-03-18T13:54:12 Michael Lazzaro:
> A perl5-native parser can be rigged up fairly easily, but it's
> *numbingly* slow compared to the C version. I mean, 20-50 times
> slower, by my guess.
That's the nature of the beast; XML requires a lexer which knows
about more than just two or so character
2000-09-26-21:56:04 Paris Sinclair:
> A "small" fixed upper bound? It is N that is bounded, that doesn't
> stop it from using N*50 variables to represent N, or N*150
> variables if I'm only matching vs 2 characters.
In big-O notation, the N is the size of the problem; in this case,
it could be th
2000-09-26-21:11:53 Paris Sinclair:
> Please keep your fetishes and/or geocentricism to yourself.
They get all ingrown and infested if I don't take 'em out and
air 'em out occasionally:-).
> There is no need to propose that others should share them.
No indeedy! I'm not opposed to i18n support i
2000-09-26-20:29:22 Paris Sinclair:
> On Tue, 26 Sep 2000, Bennett Todd wrote:
> > $hist[ord($_)]++ for split //, $string;
>
> But would technique work with unicode?
Beats me, I've never tried programming against unicode, as I don't
speak any other language than
2000-09-26-05:18:57 Paris Sinclair:
> > (%alphabet) = $string =~ tr/a-z//;
>
> also a little more concise (and certainly more efficient...) than
>
> %alphabet = map { $_ => eval "\$string =~ tr/$_//" } (a..z);
However, compared to say
$hist[ord($_)]++ for split //, $string;
2000-08-22-15:13:23 Peter Scott:
> I too would rather say
>
> my $fh = open $filename or die "Couldn't copy source: $!"
>
> than
>
> my $fh; try { $fh = open $filename } catch { die "Couldn't copy
> source: ", $@->syserr }
I'd usually rather just say
my $fh = open $
2000-08-11-11:59:47 Steve Simmons:
> There's a strong implication here that we've just made package
> namespaces heirarchical.
The possibility of doing so was raised during discussion of ways to
handle needs for one running program to have two different versions
of the same support module.
Once
2000-08-10-17:36:41 Graham Barr:
> And the difference is ?
>
> $ perl -e 'warn \$main::fred::x," ",\$fred::x'
> SCALAR(0x80dc254) SCALAR(0x80dc254) at -e line 1.
Today there's no difference. If the proposal under discussion were
to pass, and packages' namespaces were to become local to the
names
2000-08-10-12:19:49 Peter Scott:
> Ah, got it. Now we have actually two types of error from builtins:
>
> Non-trapped (builtins return 0, undef, 1 :-) , n where n < # requests, etc).
> RFC 70 wants all these to be turned into optional exceptions if Fatal is used.
Ultimately, yes, that's my goal
2000-08-10-11:52:31 Dan Sugalski:
> Why not, then, introduce non-fatal errors and a new keyword to
> throw them?
If we were to add a non-fatal exception type, that would just mean
that those of us who want errors to behave differently than they do
now, would have to wrap our whole program in a ca
2000-08-09-17:33:25 Steve Simmons:
> If that's the intent, then yes, author name must become part of the
> package identifier. Rather than change the meaning of "ref $object"
> unexpectedly, I'd add one or more alternate forms of ref. Off the
> top of the head, something like
>
> ( $version
2000-08-09-21:00:31 Chaim Frenkel:
> Making a module local to the using package, might have interesting
> properties. [...]
> The only breakage that I see, is having some way of globally setting
> a variable. For example, turning on debugging for all uses. (FTP::Debug
> I find quite popular.)
>
>
2000-08-10-02:40:41 Perl6 RFC Librarian:
> RFC 70 proposes that all builtins throw trappable exceptions on
> error.
Not quite. RFC 70 acknowleges that perl's current behavior is
preferred by some very focal participants in the language's
development, and even if it weren't, that switching all bu
2000-08-08-16:34:16 Uri Guttman:
> how does this work with RFC 63 (Exception handling syntax proposal - it
> wants the Error.pm syntax) written by peter scott?
As far as I can tell, my proposal stands independant of RFC 63. I'm
not proposing that the language add a built-in provision for
exceptio
2000-08-08-04:42:00 Leon Brocard:
> Martyn J. Pearce sent the following bits through the ether:
> > I use this in one-liners, and it's _dead_ handy
>
> May I suggest that Perl6 will be a different language?
If perl6 substantially fails to fill the important roles that perl5
fills, we should stop
2000-08-07-19:22:59 Michael Fowler:
> Is $CURRENT_PACKAGE any different, value-wise, than __PACKAGE__?
I'm guessing no, unless I've misunderstood something from the
preceeding discussion.
> Is there a reason to prefer it?
I suppose some folks who want to do a truly stunningly huge amount
of thi
17 matches
Mail list logo
