Re: [regex] \
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 -- xy
But if Perl6 can do the same with
s/($search)(.\1)+/$1/go
by detecting that the possible $1 and $2 and $ (or new equivalents) are
(almost certainly) not going to be used, that's of course best.
A '+' can often be optimized to a {2,}. In this case:
s/($search)+/$1/
only if the resulting count is never used.
--
Grtz, Ruud
Re: Exceptuations
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]
http://www.bofh.org.uk/
Re: Exceptuations, fatality, resumption, locality, and the with keyword; was Re: use fatal err fail
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
maintenance programmer.
My view here is that the parameters in the code pick a point in
the range from free on the one end and bound at the other end.
The unifying concept is constraints. So I see the following boundary
equalities:
unconstraint = free # 0.0
contstraint # 0.0^..^1.0
fully constraint
as the black and white ends with shades of gray in the middle.
And it is the type system that guaranties the availability
of the required information e.g. in $!. In that sense a sub
with a CATCH block is a different type than one without. This
difference is taking into account when dispatching exceptions.
Reentrancy is an implementation detail best left unmentioned.
Uh ohh, in an imperative language with shared state outside
the unshared state of multiple invocations of one sub the reentrance
proplem is just there. Interestingly it is easily unifyable with
shared data.
Assume that every bit of code you can run in perl 6 is first class
code - it gets safety, calls, control flow, exceptions, and so
forth.
Just to synchronize our understanding, I see the following
equivalences from the data and code domains
datacode
class = sub
instance = invocation
To illustrate my view consider
class foo
{
has ...
method ...
}
and match with
sub foo
{
has ... # my named parameters defined in body proposal
BEGIN ...
CATCH ...
label:
}
What I want to say is that calling a sub means creating an
instance of the class that describes---or *constrains*---
the potential invocations. If such an invocation is left
lying in memory unfinished we have a continuation. How concurrent
these continuations are stepped in real time with respect to their
respective inner causal logic is irrelevant to the concept.
But *causality* is important!
The view I believe Yuval is harboring is the one examplified
in movies like The Matrix or The 13th Floor and that underlies
the holodeck of the Enterprise: you can leave the intrinsic
causality of the running program and inspect it. Usually that
is called debugging. But this implies the programmer catches
a breakpoint exception or some such ;)
Exception handling is the programmatic automatisation of this
process. As such it works the better the closer it is in time
and context to the cause and the more information is preserved.
But we all know that a usefull program is lossy in that respect.
It re-uses finite resources during its execution. In an extreme
setting one could run a program *backwards* if all relevant
events were recorded!
Yes, even signals and exceptions.
The runtime is responsible for making these as fast as possible
without being unsafe.
Hmm, I would see the type system in that role. It has all the
information of the interested parties in a longjump. If it knows
there are no potential handlers
It can't be a method because it never returns to it's caller - it's
It beeing the CATCH block? Then I think it *is* in a certain
way a method with $! as it's invocant. HiHi and here a locality
metric for dispatch applies. BTW, how is the signature of a CATCH
block given? Simply
CATCH SomeException {...}
or is inspection with cascaded when mandatory?
a continuation because it picks up where the exception was thrown,
I would say it is given information about. In a way an exception
handler is dispatched on the type of exception.
and returns not to the code which continued it, but to the code that
would have been returned to if there was no exception.
This is the thing that I see is hardly possible from a far away scope.
But fair enough for closely related code.
It is, IMHO a multi though. There is no reason that every
continuation cannot be a multi, because a continuation is just a
sub.
I don't know if there are method continuations - i guess there could
be, but there's no need to permutate all the options when the
options can compose just as well.
My view is that a (free) method type becomes a continuation
as follows:
1) the invocant type is determined
2) the dispatcher selects a matching target
3) this method maker object (like a class for constructing data objects)
is asked to create a not yet called invocation and bind it to the
invocant at hand
4) at that moment we have a not yet invoked sub instance, so
plain subs just start here
5) The signature is checked and bound in the environment of the calling
scope, the callers return continuation is one of the args
6) then this invocation is activated
7a) a return uses the return continuation in such a way that
the invocation is abandoned after the jump
b) a yield keeps the continuation just like a constructed object
and
Re: [regex] \
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 always bothered me a little to use $/ the object when you
want to refer explicitly to the string matched, especially if the
object knows it matched more than the string is officially matching.
I think we could go as far as to say that $ is the name of the text
that would be returned by ~$/ and the number that would be returned
by +$/. If we did that, I think we could get away with making
/frontstuff \w* backstuff/
a shorthand for
/pre frontstuff $:=( \w* ) post backstuff/
The space after the would be required, of course. It works because
in the foo \d* form, the default is to take the argument as rule,
and here we merely have a null foo.
That gives us cool things like
s/back \s+ \d+ \s+ times/{ $ + 1 }/
to increment the number of times the quick brown fox jumped over the
lazy dog's back.
Larry
Re: Maybe it's Just Nothing (was: Look-ahead arguments in for loops)
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 and after elements
for @list - ?$b, $c, $?a {
given $b {
when undef but generated { say a fake undef!; }
when undef { say a real undef!; }
}
}
Oh, right, and as for my favorite actual usage of for:
for @list, :lookbehind(2) :lookahead(1)
- $behind1, $behind2, $value, $ahead {
...
}
Hmm. Something like:
for @list - $c :behind($b1,$b2) :ahead($a1) { ... }
would seem to make a more direct connection between the variables and
what they are aliased to (if only there wasn't that use/mention problem
with the variables).
I think there needs to be something that clearly and unambiguously says
that C$c is the value being iterated over and clearly makes a
correspondence between the other variables and their position relative
to C$c even with whatever other syntactic mumbling may be necessary.
(And maybe the proposed use of ? is it, but it feels wrong to me)
But, don't we have something like
for @list.kv - $i,$x { ... }
and even if I'm misremembering @Larry's blessing on that particular
construct, we certainly have this:
for zip([EMAIL PROTECTED](),@list) - $i,$x { ... }
And then getting the values fore and aft of the current value is just a
matter of indexing into @list. This seems clearer to me than virtual
parameters that exist on either side of the sliding window of the real
parameters.
Also, since for seems to be some kind of non-consumptive iterator, maybe
we can get at it with some magical $?ITERATOR variable if we need to:
for @list - $x {
my ($b1,$b2) = $?ITERATOR.prev(2);
my ($a) = $?ITERATOR.next;# defaults to next(1)
}
Though that's far more syntax than using zip, but has the advantage
that it would work when @list really is a list rather than an array.
I still like using zip() or .kv and indexing the array directly. Putting
the values in an Array-like thingy seems to be a smallish price to pay
for easily getting at some number of elements before or after the
current element.
Rambling in a pre-caffienated way,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Exceptuations
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 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 another tool.
CATCH Exception { say Why do you hate freedom? }
I don't. But the freedom of the individual ends where the
community begins.
--
$TSa.greeting := HaloO; # mind the echo!
Re: Look-ahead arguments in for loops
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 think we're best off
using signature rules: optional stuff comes last.
I disagree, I think that is an easy call
for (1, 2) - ?$prev, $cur, ?$next {
say $prev - $cur if $prev;
say $cur;
say $cur - $next if $next;
say next;
}
should print
1
1 - 2
next
1 - 2
2
next
Did you mean:
next
1 - 2 # two spaces
there?
No, my logic is that the loop is run through twice, once with (undef,
1, 2) and once with (1, 2, undef).
Matt
--
Computer Science is merely the post-Turing Decline of Formal Systems Theory.
-Stan Kelly-Bootle, The Devil's DP Dictionary
Re: Exceptuations
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 another tool.
I think you're taking it too seriously. I'm 99% sure Piers was
joking.
Regardless, exceptions *are* just another tool. They let you write
safe code in fewer words and with less distraction.
For example, Either you linearly serialize the entire tree of
possible events:
if (my $handle = open file) {
# the handle is open
if (my $other_file = open other :w) {
for =$handle - $line {
unless ($other_file.print($line)) {
$*ERR.print(other could not be written
to: $!); # disk might be full
if (close $other_file) {
if (close $handle) {
exit 1;
} else { ...; exit 1 }
} else { ...; exit 1 }
}
exit 0;
}
} else {
$*ERR.print(could not open other for writing: $!);
if (close $handle) {
exit 0;
} else {
$*ERR.print(could not close file: $!); # not
logical,
# since we don't write to file, but this is
safer
exit 1;
}
}
} else {
print $*ERR, could not open file: $!;
exit 1;
}
or you could throw exceptions:
use fatal;
my $handle = open file;
my $other_file = open other :w;
for =$handle - $line {
$other_file.print($line);
}
If you are going to avoid exceptions because they are too much
something for your taste, then I think you are misusing a language
that has support for exceptions.
I really don't understand why this has to do with freedom, or it's
restriction. It's your personal (and IMHO bad) taste not to use
exceptions for improving your code, but it's still your choice.
All I was saying is that you could leverage exceptions by letting
the UI code make the handling of exceptions a two way route, instead
of one way.
CATCH Exception { say Why do you hate freedom? }
I don't. But the freedom of the individual ends where the
community begins.
I think this is a big exaggeration. The community will not be harmed
if the individual uses exceptions.
On the contrary, i would be much happier to use code that does
through exceptions.
For example, a very useful perl 5 module, UNIVERSAL::require, lets
me write:
$class-require or die $UNIVERSAL::require::ERROR;
instead of
eval require $class; die $@ if $@;
but in both cases I have to check for errors, unlike
require Class;
I still prefer $class-require, though, because it feels more
readable to me. I don't say to myself wtf? why is this code doing
an eval while reading the code.
In perl 6, we would ideally have:
use fatal;
$class.require; # lives if class exists, dies if class doesn't exist
$class.method; # always lives (if method really exists)
or
use fatal;
try { $class.require } # always lives
$class.method; # might die, but at least it's obvious
or
no fatal;
$class.require; # always lives\
$class.method; # might die
In fact UNIVERSAL::require's author agrees with me:
http://use.perl.org/~schwern/journal/26939
Now, if this were
#!/usr/bin/perl
use fatal;
use Pluginish::App;
sub infix:s~ ($l, $r) { $l $r }; # spacey concatenator
{
Pluginish::App-load_plugins;
CATCH {
when Module::load_error {
if (prompt(The module $!.module_name could not
be loaded because
s~ an error occurred ($!). Try to
continue anyway?) {
$!.resume(undef);
} else {
die $!;
}
}
}
Pluginish::App-run;
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /methinks long and hard, and runs away: neeyah!!!
pgpKTxHNv1uR1.pgp
Description: PGP signature
Re: Look-ahead arguments in for loops
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] - $curr, $next {
...
}
???
Damian
Re: Look-ahead arguments in for loops
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 mine.
Certainly adding this to specialized syntax in signature matching is
an overfeature, so I tried to squish it down into options, which we
can add at will without really complexifying the core language. But
without options, like this, is even better.
Incidentally, the undef problem just vanishes here (being replaced by
another problem). Since zip takes the shorter of its argument lists,
you'll never even execute the case where $next is undef.
Luke
Re: Look-ahead arguments in for loops
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 away extras, not fills in with undef.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Look-ahead arguments in for loops
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 I remember it zip hrows away extras, not fills in with undef.
Drat I did that backwaeds didn't I.
try:
for @list ¥ [EMAIL PROTECTED], undef] - $curr. $next {
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Look-ahead arguments in for loops
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 this, because
we can program it things. Perl5 had many other these: we don't need a
switch statement, we don't need function signatures, etc.
My original idea, not consuming optional bindings, is barely a new
feature: just a clarification of the rules in a corner-case of the
language. Others took the idea and ran with it and added the bells as
whistles. I guess the best alternative is to say that optional bindings
aren't allowed in this context -- that leaves the issue open for Perl
6.1 (or a module).
