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 t
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
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?
On Tue, 24 Aug 2004, Aaron Sherman wrote:
> On Tue, 2004-08-24 at 11:50, Dave Whipp wrote:
>
> > You're assuming that C 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. C).
>
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 decla
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.fe
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 refer
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 s
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 then
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 th
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 a
> > 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 wi
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. La
> 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])
http://cec.
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
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 ove
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 woul
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 suppo
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
> represent
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
t
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 $_
> wil
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 ac
> 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,
> no
> 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 wha
30 matches
Mail list logo
