Juerd:
Ruud H.G. van Tol:
s/($search)/*\1*/go
\1 in Perl 5 is bad style and emits a warning
The point was to give \1 and \, in the replace part, a very limited
scope.
Maybe even better to limit \1 to the first '(?: ... )' in the search
part.
s/(?:$search)(?:.\1)+/\1/go
xy.xy.xy.xy --
TSa [EMAIL PROTECTED] writes:
BTW, I would call *intentional* exceptions terrorism.
So that would be all exceptions then. They all get implemented somewhere, even
the ones that get thrown by builtins.
CATCH Exception { say Why do you hate freedom? }
--
Piers Cawley [EMAIL PROTECTED]
HaloO,
Yuval Kogman wrote:
The try/catch mechanism is not like the haskell way, since it is
purposefully ad-hoc. It serves to fix a case by case basis of out
of bounds values. Haskell forbids out of bound values, but in most
programming languages we have them to make things simpler for the
On Mon, Sep 26, 2005 at 10:19:29PM +0200, Juerd wrote:
: In Perl 6, the match object $/ will instead be used. It's a bit harder
: to use with s///, because it will look ugly, but remember that you can
: always choose to use s^^^ or s[][] or any other of the many
: possibilities instead.
It's
On Thu, Sep 29, 2005 at 11:21:20PM -0600, Luke Palmer wrote:
[ discussion on undefs elided ]
Since we can annotate our undefs now, perhaps undefs that would be
generated because there are no previous or next elements get tagged
as such. Something like:
# assuming $b and $a are before
HaloO Piers,
you wrote:
TSa [EMAIL PROTECTED] writes:
BTW, I would call *intentional* exceptions terrorism.
So that would be all exceptions then. They all get implemented somewhere, even
the ones that get thrown by builtins.
I knew that the statement would emotionalize. Sorry to all who
Austin~
On 9/29/05, Austin Hastings [EMAIL PROTECTED] wrote:
Matt Fowles wrote:
Austin~
On 9/29/05, Austin Hastings [EMAIL PROTECTED] wrote:
Plus it's hard to talk about backwards. If you say
for @l - ?$prev, $curr, ?$next {...}
what happens when you have two items in the list? I
On Fri, Sep 30, 2005 at 18:02:46 +0200, TSa wrote:
I knew that the statement would emotionalize. Sorry to all who don't
like it an this list. But somehow I found it describes the impression
on the handling side somewhat. And I thought it illustrates that exceptions
shouldn't be considered just
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] - $curr, $next {
...
}
???
Damian
On 9/30/05, Damian Conway [EMAIL PROTECTED] wrote:
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] - $curr, $next {
...
}
???
Thanks. I missed that one.
However, I think your point is pretty much the same as
Damian Conway wrote:
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] - $curr, $next {
...
}
???
Damian
Shouldn't that be:
for [EMAIL PROTECTED], undef] ¥ @list[1...] - $curr, $next {
...
}
As I remember it zip hrows
Mark A. Biggar wrote:
Damian Conway wrote:
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] - $curr, $next {
...
}
???
Damian
Shouldn't that be:
for [EMAIL PROTECTED], undef] ¥ @list[1...] - $curr, $next {
...
}
As
Damian Conway wrote:
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] - $curr, $next {
...
}
???
There's nothing particularly wrong with it -- just as ther's nothing
particularly wrong with any number of other we don't need
13 matches
Mail list logo
