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 for a very small try/CATCH block.
Basically, my observation is that no-one consistently checks the
On Sat, 18 Sep 2004, Jonadab the Unsightly One wrote:
James Mastros [EMAIL PROTECTED] writes:
As a special case, if the filename argument to perl is a
directory, and the directory contains a file named main.pl,
then the directory is prepended to @*INC, and main.pl is run.
I
On Sat, 4 Sep 2004, David Green wrote:
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Larry Wall) wrote:
I'm still thinking A is the first one and Z is the last one. Someone
talk me out of it quick.
The actual issue is how to distinguish cardinal numbers from ordinals,
right? So if we
On Tue, 24 Aug 2004, Aaron Sherman wrote:
On Tue, 2004-08-24 at 11:50, Dave Whipp wrote:
You're assuming that Ceither in a ternary operator. It
could be a binary operator, defined as {eval $RHS if $LHS; return $LHS}. For
that interpretation, one might choose a different name (e.g.
On Fri, 20 Aug 2004, Dan Hursh wrote:
Peter Behroozi wrote:
I'm not particular to any of the verbs used yet, but maybe that's
because I don't think of the as a general iterator, but more of a
gobbler-type creature (and formerly a globber, too). Could we try:
for $foo.fetch { ... }
On Fri, 20 Aug 2004, Larry Wall wrote:
On Fri, Aug 20, 2004 at 10:07:02PM +0200, Juerd wrote:
: I'm proposing
:
: for zip(@foos, @bars, @xyzzies) - $foo, $bar, $xyzzy { ... }
: for %quux.kv - $key, $value { ... }
That'd probably work on the keys only if the hash was declared to
On Thu, 22 Jul 2004, Michele Dondi wrote:
On Thu, 22 Jul 2004, Robin Berjon wrote:
Do we have a :) operator yet?
[snip]
We could mimick XQuery where it is the comment terminator.
Well, since it's *optimistically* smiling, it could turn off warnings for
the statement it refers to.
On Tue, 8 Jun 2004, Matthew Walton wrote:
Ingo Blechschmidt wrote:
One should be able to unwrap $subref using
$id.unwrap();
Something tells me that you shouldn't be able to do that. Wrapping is an
operation on the subref, which implies very strongly to me that
unwrapping should
I've been trying to follow the recent discussion on roles and properties and
traits and such, but there's something that bugs me. If I understand
correctly, adding a role at runtime using but won't override any methods
defined by the class itself (but it will override inherited methods). But
On Fri, 3 Oct 2003, Simon Cozens wrote:
Dunno what .= would mean now . is method call. I'm sure someone will make it
mean something. :)
I've been saying for some time now that .= should mean exactly what one would expect
it to mean, method call and assign the result, for code like
$str .= lc;
I've had an idea brewing for a while, and since talk seems to have turned
to reg^H^H^Hpatterns and rules again, I figured this might be the time to
mention it.
A while ago someone asked about whether backtracking semantics are
mandatory in any implementation, or whether it would be legal to build
The question is, can I create a method on a class with a different scope than
the class itself has? Put another way, it seems like
module ArrayMath;
sub sum(Array $this){
$this.reduce(operator::+, 0);
}
method Array::sum(;){
.reduce(operator::+, 0);
}
(modulo syntax errors) then both
I'd like to point out one thing that I'm not sure of. It seems like the
original proposal only allowed for the operators to change terms around.
So given the same (1)-(4) from the message, (4) is exactly the same as (1), and
(2) and (3) are exactly the same as each other and as
@out
It seems to me that the simplest disambiguating rule is to require the
parentheses on methods.
The way I see it, any sort of matching of what [multi-]?method is to be called,
is automatically doomed to failure. But I don't think that means we need to
require parentheses, except to override the
Looks to me like with a few appropriate methods, you have left-to-right
ordering for free.
(@foo, @bar) := @a
. grep { $_ 0}
. sort { $^b = $^b }
. part [/foo/, /bar/];
Of course, that means that grep and sort and part are all methods of the Array
class, so the standard way to
I like it except for the name, which feels too active to me (ie, if I were to
purge those elements from the array I'd expect the array to be altered, instead
of returning a new array with only those elements). But I do like the idea. I
think the name except would be pretty nice, though. Then
My favorite was from ages ago:
sub bar(;$foo //= $_) {...}
I think that today that would be written more like this:
sub bar(;$foo) is given($def_foo) {
$foo = $def_foo unless exists $foo;
...
}
Though we might get away with:
I still prefer cached, which sounds less lingo-ish than memoized but reads
better than same (Same as what?).
Billy Naylor asked:
Would it be useful to apply memoization in a similar fashion...
sub square ( Num $n ) is memo {
return $n ** $n;
}
Yes. Larry indicated this in
I don't see why I'd want to do it with arrays, but...
%a_students = %grades{grep /^a/i, keys %grades};
Looks like that's just the same as
%a_students = grep {.key ~~ :i/^a/}, %grades.kv;
(after adjusting for perl6 syntax for a few things)
--
Adam Lopresto ([EMAIL PROTECTED])
I'm having trouble this is even being considered. At all. And especially for
these operators...
So, yeah, include trigraph sequences if it will make happy the people
on the list who can't be bothered to read the documentation for their
own keyboard IO system.
But don't expect the rest of
This is exactly what I wanted .= for.
@array .= splice(2,0,$element); # in-place, @array = @array.splice
@new = @array.splice(2,0,$element);
$sentence .= lcfirst;
The semantics are pretty clear, then it's just up to the compiler to optimize
it for in-place. Perhaps functions could
Really what I've been wishing for was an operator (or whatever) to let me do an
s// without changing the variable.
print 'He said '_($statement ~ s/\.$//)_', but we didn't believe him.';
I'm not sure exactly what the semantics would be, but somehow =~ without the =
seems appealing...it's always
: It's rare enough to need bitwise things in Perl 5 (outside golf). I'm
: hoping that it'll be even rarer in Perl 6, as better interfaces are
: designed for the things which at present require flipping individual
: bits.
I almost wonder if it's wrong to waste ~ on it...
That would be an
Sounds like a good place for fail, as described in Exegesis 4, so that it
could be taken as undef or an exception depending on pragmata.
This came up at YAPC::Europe. Someone [1] wanted to know if 1/0 would
produce a divide by zero error in Perl 6, or if it would return a value
representing
Would it make sense for the syntax to be more like
my $obj3 = $obj.new;
Of course, that would kill my .= new idea for instantiation (since it would
call an instance-based new instead of class-based), but I'm getting less fond
of that syntax anyway (though I think .= should definitely be
I'd say the correct solution isn't to control which modules can accidentally
untaint data (it seems pretty likely that no matter what we do, maliciously
coded modules will be able to screw you over if they try to do so
intentionally) but rather fix those aspects of tainting that allow any module
Personally, I like the looks of
sub foo($a, $b is given) { ... }
Does this mean that we allow/encourage uses of $_ other than as a default
for an optional argument? I think it would be less confusing and
error-prone to associate the underscore-aliasing with the parameter $_
will
Some regexpes will be longer, but a lot will benefit from the changes, by being
shorter or clearer, or often, both. The problem with your suggestion is you're
making assumeptions about what's common and what's not (character classes more
common than closures, for instance) that probably aren't
On Monday, September 2, 2002, at 03:44 AM, Damian Conway wrote:
my Date $date .= new('Jun 25, 20002');
H. That's a very interesting idea.
I like it.
Looks pretty groovy to me too. It looks like the .=
operator, no longer being employed as a string appender,
now means use
And, furthermore, that you could easily define special semantics
for void-context constructor calls via undef'd but typed variables,
so that you could just write:
(my Date $date).new('June 25, 2002');
and have the interpreter autovivify the object.
That's pretty close to what I
30 matches
Mail list logo
