HaloO,
Yuval Kogman wrote:
On Wed, Sep 28, 2005 at 09:49:11 -0700, Larry Wall wrote:
But thinking about optional continuations, another thing occured
to me. It's always bugged me that warnings were something different
from exceptions, and now I think we can unify them, if we say that
Yes, I'
Hi!
On Thu, Sep 29, 2005 at 10:49:40 +0200, TSa wrote:
> BTW, I would call *intentional* exceptions terrorism.
Then I would call terrorism non linear control flow ;-)
In that case Afghanistan might be harboring computer scientists that
really like CPS, and bush is Java ;-)
> In lack of a better
At 11:46 AM -0500 9/28/05, Adam D. Lopresto wrote:
The recent thread on Expectuations brought back to mind something I've been
thinking for a while. In short, I propose that "use fatal" be on by default,
I totally, TOTALLY, agree with this.
EVERY built-in function and operator that talks to p
I'd like to ammend, and perhaps formalize with some definitions from
my dictionary, which ships with OSX:
error - a mistake... the state or condition of being wrong in
conduct or judgement... technical - a measure of the estimated
difference between the observed or calculat
# New Ticket Created by Joshua Hoblitt
# Please include the string: [perl #37303]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37303 >
- Forwarded message from Nick Glencross <[EMAIL PROTECTED]> -
From: Nick Gle
HaloO,
Yuval Kogman wrote:
On Wed, Sep 28, 2005 at 11:46:37 -0500, Adam D. Lopresto wrote:
The recent thread on Expectuations brought back to mind something I've been
thinking for a while. In short, I propose that "use fatal" be on by default,
and
that "err" be turned into syntactic sugar fo
On Thu, Sep 29, 2005 at 12:53:51 +0200, TSa wrote:
> I don't like it at all. I fear, that we mix two orthogonal concepts
> just because it is convenient.
"just because it is convenient" is precicely why I like it =)
> To me the statement
>
>return 42; # 1
>
> has to orthogonal meanings:
>
TSa schreef:
> Yes, I'm also all for unifying the concepts. But please
> don't let us call it exception. Exception should be a
> termination oriented (sub)concept. Some kind of scoped giving
> up. [...]
> In lack of a better word I use Event and we get
> Event::Exception, Event::Control, Event::Wa
Hi,
TSa wrote:
> Yuval Kogman wrote:
>> On Wed, Sep 28, 2005 at 11:46:37 -0500, Adam D. Lopresto wrote:
>>>thinking for a while. In short, I propose that "use fatal" be on by
>>>default, and that "err" be turned into syntactic sugar for a very
>>>small try/CATCH block.
>>
>> I like it a lot. It
On 29/09/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> * "try { foo() } err next" will next even if foo() did not throw
> an exception, but returned undef. But I don't think that's a problem
> in most cases. One can always do:
> try { foo(); 1 }
I think that's a flag that it's not
Tcl's [expr] command now compiles expressions to PIR (before, it
would create an AST that it would then interpret when you wanted the
value.). Note: the language itself is still interpreted, this is only
one command in the language.
E.g: given a command like
while {$a < 10} {incr $a}
Orig
Luke Palmer wrote:
Joked? Every other language that has pattern matching signatures that
I know of (that is, ML family and Prolog) uses _. Why should we break
that? IMO, it's immediately obvious what it means.
Something tells me that in signature unification, "undef" means "this
has to be un
Imagine you're writing an implementation of the unix "uniq" function:
my $prev;
for grep {defined} @in -> $x {
print $x unless defined $prev && $x eq $prev;
$prev = $x;
}
This feels clumsy. $prev seems to get in the way of what I'm trying to
say. Could we imbue optional b
TSa wrote:
> HaloO,
>
> Yuval Kogman wrote:
>
>> On Wed, Sep 28, 2005 at 11:46:37 -0500, Adam D. Lopresto wrote:
>>
>>> The recent thread on Expectuations brought back to mind something
>>> I've been
>>> thinking for a while. In short, I propose that "use fatal" be on by
>>> default, and
>>> that
Dave Whipp wrote:
> Imagine you're writing an implementation of the unix "uniq" function:
>
>my $prev;
>for grep {defined} @in -> $x {
>print $x unless defined $prev && $x eq $prev;
>$prev = $x;
>}
>
> This feels clumsy. $prev seems to get in the way of what I'm trying
Very cool. Will have to look into it soon.
Are you still contemplating making the whole thing compiled?
> Tcl's [expr] command now compiles expressions to PIR (before, it would
create an AST that it would then interpret when you wanted the value.).
Note: the language itself is still interpreted, t
On 9/29/05, Dave Whipp <[EMAIL PROTECTED]> wrote:
>for grep {defined} @in -> $item, ?$next {
> print $item unless defined $next && $item eq $next;
>}
This is an interesting idea. Perhaps "for" (and "map") shift the
minimum arity of the block from the given list and bind the maximum
a
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #37308]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37308 >
With a a fresh checkout (r9274) I get a number of errors where parrot eventually
gobb
On 9/29/05, via RT Andy Dougherty <[EMAIL PROTECTED]> wrote:
> # '
> # expected: '3 * 5 == 15!
> # '
> # './parrot --gc-debug
> "/home/doughera/src/parrot/parrot-andy/t/op/gc_13.pir"' failed with exit code
> 131
> # Looks like you failed 1 test of 22.
this same test fails on win32, however
Luke Palmer wrote:
>>On 9/29/05, Dave Whipp <[EMAIL PROTECTED]> wrote:
>
>
for grep {defined} @in -> $item, ?$next {
print $item unless defined $next && $item eq $next;
}
>>
>>
>
>>This is an interesting idea. Perhaps "for" (and "map") shift the
>>minimu
On Thu, Sep 29, 2005 at 13:52:54 -0400, Austin Hastings wrote:
> You already know that "err" is the low-precedence version of //, right?
> What replaces that? I like "default" or "defaults" myself,
Yes, he proposed 'dor'.
As I see it err is like this:
sub infix: ($lhs is delayed, $rhs i
Yes, that's the plan, but the initial implementation isn't going to
be a compiler like most people would expect:
For example, something like:
while {$a < 10} { incr a }
while isn't language syntax. it's a command. So, this code would
result in creating two PMCs for the args (first arg is {$
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 disagre
On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> Luke Palmer wrote:
> >>This is an interesting idea. Perhaps "for" (and "map") shift the
> >>minimum arity of the block from the given list and bind the maximum
> >>arity. Of course, the minimum arity has to be >= 1 lest an infinite
> >>loop
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: option
On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
> >
> >for (1, 2) -> ?$prev, $cur, ?$next {
> > say "$prev -> $cur" if $prev;
> > say $cur;
> > say "$cur -> $next" if $next;
> > say "next";
> >}
> >
> [...]
>
> I assume so because it's the only execution path th
26 matches
Mail list logo
