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).
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 {
...
}
???
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
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
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
Damian
Re: Exceptuations, fatality, resumption, locality, and the with keyword; was Re: use fatal err fail
On Fri, Sep 30, 2005 at 17:09:23 +0200, TSa wrote:
> And it is the type system that guaranties the availability
> of the required information e.g. in $!.
$! is polymorphic.
Since CATCH is a topcializer, and you use when blocks to case over
$!, you can check to see if it has the metadata you want yourself:
CATCH {
when It::Is::An::Error::I::Can::Deal::With {
deal_with_error_of_kind_foo($!); # it may resume
}
}
> >Reentrancy is an implementation detail best left unmentioned.
>
> the reentrance proplem is just there
No, it's not - the solution is that $! is bound lexically to the
CATCH block. Exceptions that redefine $! keep the old value in the
exception stack inside of each exception, but this does not trample
any CATCH block. It'd be outright stupid to make
CATCH {
handle_error();
warn "$! was thrown within the code yadda";
}
print out completely bogus info becaue handle_error overwrote $!.
We can even deal with this in perl 5:
eval { bad_code };
if ($@) {
{
local $@;
code_that_might_die_in_a_handler;
}
warn "$! was thrown within bad_code";
}
> Just to synchronize our understanding, I see the following
> equivalences from the data and code domains
>
> datacode
>
> class = sub
> instance = invocation
What?
> To illustrate my view consider
didn't help.
> 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 ;)
Err, no.
What I want is for perl 6 to help me write high quality user
interfaces easily.
One aspect of making this easy is letting me bridge between
exception throwing code and the UI layer using continuations.
> 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.
I read that as:
"As such it works the better the farther it is in time and
context from the UI code"
and I must disagree, but it is a matter of style.
As for information preserval:
* every object that inherits Exception can have an arbitrary
number of attributes.
* the base class Exception has code to make it be thrown,
or rethrown cleanly by making the previous value of $! available
as an attribute of the new value of $!
* Exception's constructor knows exactly where everything
happenned (for error reporting, *AND* resuming)
* a transition into a 'use fatal' lexical scope will cause the
throw method to be called on a value being returned, if it is an
exception.
* if the next statement to be executed is not inside a CATCH
block, the error object deletes it's .resume continuation, to
clean up the lexical scope that is still alive inside it. This
should be optional.
> 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!
That's a job for omniscient debuggers.
Languages with continuations are not debuggers.
Exceptions are not raised for every opcode, just to record the flow.
Exceptions normally do not happen.
> >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
The type system has nothing to do with code reentrency due to an
icky implementation that shares code.
Since malloc cannot be safely called within a C level signal
handler, the runtime needs to be responsible for setting the virtual
machine instruction pointer to the signal handling code, and to
mark a flag, and at the next opcode dispatch (no longer an unsafe
place) the signal handler will really happen.
This has nothing at all to do with the type system, and doesn't even
have anything to do with perl - this is parrot (or whoever)'s job.
> >It can't be a method because it never returns to it's caller - it's
>
> It beeing the CATCH block?
No, .resume.
I take it back, it could be a method that invokes a continuation.
> metric for dispatch applies. BTW, how is the signature of a CATCH
> block given? Simply
CATCH is just a topicalizer and a trait on the lexical scope.
Within it $! is topicalized, and you use when:
CATCH {
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
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: ($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
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
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: 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]
perl6-language@perl.org
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
/ $<>:=( \w* ) /
The space after the < would be required, of course. It works because
in the 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: 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 p
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/
perl6-language@perl.org
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
