sts so you can say that you want the first thing
> from date()'s list value I hate casts. I would trust mjd to
> tell me that it could be done right, but until he says that, I'm
> against anything that requires casting.
I'll be against casts *even* if MJD blesses them.
I REALLY hate casts.
Damian
e" ugly:
my $seen;
$has_odd_elem = grep { $seen && last; $_%2 && ++$seen } @numbers;
:-(
Damian
Garrett wrote:
> It almost feels like grep could have been written like this (in
> another life): @a = grep (@b) { $_ > 2 or last }
http://www.csse.monash.edu.au/~damian/TPC/2000/Romana/perligata.html
;-)
> While I'm at it, I'm curious as to why:
>
evaluate to *anything*. So the C is terminated by the C
without the block having ever evaluated true. So no element of LIST is
ever "passed through". So the C evaluates to zero.
Damian
reaches 100 (and exclude that result)...
@squares = map { my $sq = $_ ** 2; $sq >= 100 ? die : $sq }
@numbers;
$product = reduce { my $pr = $_[0] * $_[1]; $pr >= 100 ? die : $pr }
@numbers
I'll be happy to change the C RFC if people like this alternative.
Damian
h the
exceptions it throws.
This proposal just suggests that C, C, etc. should catch
exceptions emanating from their control BLOCKs and act on them. :-)
Damian
> I don't think C should be able to eat unintentional exceptions.
> Perhaps it could short-circuit if the exception is 1 or false, as
> opposed to true or false?
No objection here.
Damian
> > 'Pends on whether you modulate them.
>
> KCHP 1570 on your AM dial!
Aw, not *another* one of those easy-listening Californian motor cop stations!
Damian
ith this. I'm not sure if that's good or bad.
Bad, I think.
Damian
> Shoot chop. and chomp. Unless you add unchop and unchomp.
C *has* an inverse.
Surely you know about the unary postfix C<.$/> operator?
Of course, you have to be careful. There's a known bug that
the C<.$/> doesn't properly "unchomp" if you've ever used the
C<$/&=``> operator.
;-)
Damian
I should have an RFC out on this by next week.
Damian
> Feel free to hijack and/or infiltrate my RFC.
You Will Be Assimilated.
Damian
.
The trailing C<&> parameter specification tells the parser that there
the last argument will be a raw block and that it need not be a followed
by a semicolon. It's no harder than parsing an C, C, or C,
except that parser has to update itself when it sees the parameter
specification.
Damian
> Would it be possible to expand the function prototypes so that a function
> could be defined to take a loop block instead of a code block?
I'm not sure what you mean here.
Damian
xt statement
after the C, whereas the block needs to start from the beginning on
each iteration.
Damian
> I'm under the impression that "&" used in a function prototype signifies
> that the function takes a code block.
That's right. As I said in another post, I'm functioning rather poorly
just at the moment. :-(
Damian
$_[0] }
sub takes_any { print "takes_any: ", Dumper $_[0] }
takes_block { a => print("then\n"), b => 2 };
takes_any { a => print("then\n"), b => 2 };
Damian
ive something else a
>a chance to do its things. And while you are doing
>that please take this EXPR from me.
The problem is, C also means "..and when this code is next
executed start at the line after this C".
Which is *not* the desired semantics.
Damian
d *that* in to RFC 31.
Thanks
Damian
the current block.
Damian
foreach @bigarray {
$unmerge->();
}
It's only drawback being that it's appalling. ;-)
Damian
that inevitably ends up
in $self.
Damian
Why not just give \I..\E a special "turn-on-interpolation" meaning in
q{} docs?
$code = '
$x = $y;
@a = (1..10);
$name = \I$funcname\E;
# etc.
';
Damian
nd if it fails to find a \E,
then it turns itself off after the first interpolation >:-)
Damian
qq{..} semantics on
the text in between. So you'd still write:
"..\I${\func($arg1)}\E.."
or
"..\I@{[func($arg1)]}\E.."
Damian
escape should be another char than \E?
Make \E significant only where it's explicit. Also make \E signifcant
only when \I is in effect.
So to get the string '$interpolated\E\Einterpolated\E$$'
we write:
$x = 'interpolated\E';
$y = q{$\I$x\E\E\I$x\E$$};
Damian
ints throughout your script.
Easy. Put them in a subroutine:
sub format1 { format $template1, @data };
sub format2 { print STDERR format $template1, @data };
# etc.
Damian
it SPURNS your PATHETIC HUMAN ATTEMPTS to THWART it!!
Take the ' separator; the MIGHTY Klingon module SHALL TRIUMPH regardless!!!
;-)
Damian
> They need to learn to speak English.
>
> $line_sans_terminator = chomped ;
> $last_list_element= popee some_func();
>
> Perhaps.
Or Latin:
verso_absque_termino FHum mordementum.
elemento_ultimo somefunctementa decumulamentum.
;-)
Damian
idth and then allow the header/footer
> to simply indicate left|center|right text?
I have a good idea for this. I'll add it to the next version of the RFC.
Thanks,
Damian
> >print format $fmt, @stuff;
>
> Early brain-dump. This should be it.
That's what I've done for the second version (on its way soon).
Damian
e difference between a module and a
> pragma, and more particular, why it is important that this would become
> a pragma?
Should be a standard module not a pragma.
I'll excise that remnant of an earlier version in the next draft.
Thanks.
Damian
lue) : repeat{1,} ) {...}
> Could the prototype people please report whether Tim Bunce's issues with
> prototypes have been intentionally/adequately addressed?
I'm not a prototype person (in fact RFC 128 makes it a hanging offence
to use that confusing word in connection with parameter lists! ;-)
Could someone please recapitulate Tim's issues?
Damian
're hard to read and remember.
> Methinks break_tex is sufficient. But that's just my opinion.
I ain't gonna argue with Donald Knuth! ;-)
Damian
ing to do?
The short answer is that there is no "manual" reset of iterators.
Damian
are detecting a 'HASH' context, since a 'LIST' is
> really just a more general case of both of them.
>
>@data = Matrix->gendata; # want 'ARRAY';
>($a, $b, $c) = Matrix->gendata # fail
>
> It seems like this is something that want should be able to handle.
I *really* doubt that this is ever a useful distinction.
Can anyone suggest a Real World case where it might be useful?
Damian
> > Collection:
> >
> > @triples = @{ reduce sub($;$$$){ [@{shift},[@_] }, [], @singles };
>
> You've a typo there
Noted. Thanks.
Damian
[0] }
> > > > [[],[]],
> > > > @numbers;
> >
> > > I don't understand this one.
> >
> > $sorted = reduce { push @{ ^0 [ ^1 % 2 ] }, ^1; ^0 }, [[],[]], @numbers;
>
> I guess I'm confused with the syntax. Shouldn't there be an -> in
> there?
>
>$sorted = reduce { push @{ ^0->[^1%2] }, ^1; ^0 }, [[],[]], @numbers;
Yep.
Note that the original @_-based *didn't* need one, because ->'s are optional
between ] and [.
Damian
> > list of partial values -- to that point. If the C occurs during
> > the first reduction, an exception is thrown.
>
> Again, no other builting currently throws an exception. If throwing
> an exception is to become the norm then that should be a separate
> RFC suggesting that builtins throw exceptions, but reduce should do
> what others do.
Even at the risk of Destroying the Entire Universe???
What do others think?
Damian
> These raise an exception whenever they're feeling curmudgeonly:
>
> glob require substr sysread syswrite write
>
> I presume this would fall in the lattermost category.
Very nicely expressed :-)
Damian
rray in there?
:-)
And even if you wrote:
$sum = reduce(^_+^_, @numbers) || die "Chaos!!";
you're still going to over-react to a zero-sum sequence.
You need:
defined($sum = reduce ^_+^_, @numbers) || die "Chaos!!";
Damian
Just as a data point, I have now removed this short-circuiting bits
from the C RFC. You may take that as a deferral to -- and
endorsement of -- the more general mechanism mooted in RFC 199.
Damian
the "empty list" exception never raises (ahem) its ugly head.
I think the consensus is still that reducing an empty list shall throw an
exception.
Damian
from scratch, so
the alternatives are:
1. I retract the RFC, and we live with the problem
2. I freeze the RFC, having added an Unresolved Problems section
3. Someone else takes it over and fixes it properly
Preferences? Suggestions? Volunteers?
Damian
ways cleaner *and* shorter. :-)
Damian
make 0 the default value by default?
Yes. In the RFC you'll find several examples of reductions where the
default isn't 0. Simplest example:
$product = reduce ^_*^_, 1, @data;
Damian
Should I point out that RFC 225 (Superpositions) actually covers most of this?
C is equivalent in semantics to C or C.
Except, of course, the superpositional versions work...In Constant Time!
;-)
Damian
-- to which the RFC also refers -- does
provide a comprehensive exposition of superpositions.
I take the liberty of reprinting it for you below.
Damian
---cut---cut---cut---cut---cut--
NAME
Quantum::Superpositions - QM-like superposi
t) internationalization issues you raise: break_16bit, break_kanji,
etc.
Since this would be part of the standard module (and therefore presumably
implemented in C and integrated with the C function itself), I
don't believe speed would be an issue.
I will mention this prospect in the final version of the RFC.
Damian
don't think so. I suggest you need a separate RFC to propose semantic
changes like this and:
> Y'know, this C-based interface has always sucked. ...
> I know this isn't directly related to your RFC, but I needed to bring it
> up. Seems like adding the upack('C4') thing to the gethost* functions
> wouldn't be that hard and would make these common tasks a lot easier.
Damian
e your handlers seems ok.
> for one thing, this is not hard to describe in basic terms (until you
> get to the inheritance stuff) and it is useful in many ways. maybe you
> should rename this as triggers as handlers have a meaning is signals and
> in event callbacks.
I think the term "triggers" is too obscure. "Handler" is a very general
term that people understand in many contexts, apart from signals and
callbacks.
Thanks again,
Damian
ame
> machinery as lazy subs.
RFC 21 provides just the mechanism you (ahem) want in order to implement
a "finite list" context behaviour for the diamond operator.
Damian
steal whatever they feel is worthwhile from this now-defunct proposal.
Damian
the original predicate is true
for that file. Then one could write:
if ( $file == all(writable, directory) ) { ...
as well as:
@readable = eigenstates(any(@file) == readable));
Bwah-ha-ha-ha!
Damian
gt; -^rwx; # $_ is readable, writable and executable
> > >
> > > ($size, $mod, $acc, $ichange) = -^sMAC;
>
> The use of a caret was to prevent decimation of the user's namespace,
But the syntax already has a meaning under the very popular RFC 23: Higher
Order Functions. :-(
Damian
ing is not adequate in the general
(and common) case.
> I'm not sure Filter is the best name for this. How about Filter::Transform
> or Filter::Simple?
Filter::Simple is much better. Thanks. :-)
Damian
t the same.
Even though I never looked at the modules. :-)
I've added the complete module list to the REFERENCES section of the RFC.
Damian
> So getpwnam/uid should probably return gecos, not gcos.
Yep. Already fixed in the next version.
Damian
my $result = $real_abc->(@_);
>do_post_handler($result);
>return $result;
>}
is just:
pre abc {
my $real_abc = (caller(0))[10];
do_pre_handler(@_);
$_[-1] = $real_abc->(@_);
do_post_handler($_[-1]);
}
Damian
> That's now DWIM for me!!!
Setting aside the error in the RFC, the point is that this isn't the way
you use pre and post in an OO context. If you have a class with a
next_temp that only handles Celsius, then you *derive* a new class with
a new, polymorphic next_temp that handles the
use of subs from
the non-OO.
> Wouldn't you want all the pre-handlers invoked all the way up? Even
> if you don't care about the results of those pre's which are
> conditions?
Not for methods. Methods don't need inherited pre-*handlers*, since you
can already "wrap" them simply by providing an overriding method (one that
delegates via SUPER::) in the derived class.
Damian
> >Or, should we just implement usleep() and (for lack of a better name)
>
> snooze() is a better name ;-)
nap() is even better (shorter that sleep() :-)
Damian
> Speaking of contract names, is Damien about?
No, but when you summon the AntiChrist, I sometimes appear instead. ;-)
Damian
push @unresolved, $sub;
}
Or else it checks all the candidates and resolves only if there is exactly one
whose condition is satisfied, generating an "Ambiguous subroutine..." error
if more than one condition is fulfilled.
Damian
ose this also implies a C subroutine (C'd,
of course :-) within modules -- so that one can replace:
@EXPORT_OK = qw( only by request );
with:
autouse only{requested},
by {requested},
request {requested},
;
H. Tidy, but too tedious perhaps?
Damian
y if the package's C is still called,
when it's in effect. All too often I want the convenience of Exporter, but
I need to twiddle the import semantics too.
Damian
f" ...
> scalar()
> }
> continue {
> close F;
> }
RFC 271 handles this. Your example would be:
sub readit {
open F, "< $f" ...
scalar()
}
post readit {
close F;
}
Damian
echanism on *any* block. For historical reasons, I suppose it should be
C, though I would much prefer a more generic name, such as
C.
Damian
l, in conjunction with the C:
while (1) {
... # add to $text in complex ways
}
continue { $text .= "\n"; } # separate with newlines
always { $trycount++ }# count attempts (including last)
Damian
> Of course all of this has been discussed. (See
> http://archive.develooper.com/perl6-language-io%40perl.org/,
> especially RFCs 100 and 14.)
And is already available in a nearby parallel dimension:
http://www.yetanother.org/damian/Perl5+i/open.html
;-)
Damian
Surely that should be:
use Policy::O::Reilly; # really gonna miss that ' package separator ;-)
or
use Policy::Mongolian::Navy::Office::Procurement;
Next you'll be putting the month and day before the year in dates!
Damian
> : Hey, that would make "_ _ __" legal Perl code. Abigail, Abigail!
>
> Now we just need to make "... ___ ..." mean something exceptional.
Just download the Bleach.pm module from the CPAN.
It includes Morse.pm.
Damian
---cut---cu
> > You Americans and your non-ISO penchant for putting the specific before
> > the general. Surely that should be:
> >
> > use Policy::O::Reilly;
>
> I knew someone would argue that, but I didn't think it would
> be someone
> > Because you might have a wantarray situation that expects no values?
> >
> > () = whateveryouwant();
>
> I am sure that situation is handled by the 'want' RFC.
Yep. The most recent version is at:
http://www.yetanother.org/damian/
> >Hopefully the "something similar", I hope in Perl 6 we will able to
> >bury the "0 but true" workaround to the backyard on a moonless night :-)
>
> Especially since you don't need it. "0E0" and "0.", to name just t
ike the current "while ()" magic we all know and occasionally
> love. I'd expect $FOO.readln (or something less Pascalish) to do an
> explicit readline to a variable other than $_
$STDIN.next is the current plan.
Damian
@d" in Perl5
>3. Or the mystery meat behind Door #3
This one's still less-than-certain. Definitely either 1 or 3 though.
If option 3, it would be the equivalent of the Perl 5:
%c = map {($_=>undef)} @d;
Damian
> Doubtless Damian could come up with a way to view them as hashes...
Well, of course.
An iterator is neither pure state nor pure behaviour. It's an
inextricable commingling of the two. In other words: an object.
So they are *most naturally* viewed as hashes:
package
foo.{$k})
Code reference $foo->(@a) $foo(@a) (or $foo.(@a))
Array slice @foo[$n]
Hash slice @foo{$k}
Damian
> @bar{$foo}; # C
Syntax error
> %bar[$foo]; # D
Syntax error
Damian
ules and
add a single line to your program:
use Attribute::Handlers autotie => { Sorted => 'Tie::SortHash' };
Then you can write:
my %hash : Sorted;
or:
my %hash : Sorted({}, sub { $hash{$b} cmp $hash{$a}});
etc.
Damian
PS: Casey, if you'd like to
> Perhaps it's because the people who are capable of writing such a
> module, are the ones who don't need it. But, not everyone is a conway.
Immortality at last...I appear to have become a common noun. ;-)
Damian
tches to #1 (distance = 0)
> (We could still subtract addtional values of epsilon for later files
> to make Yuval happy--or at least less unhappy...)
This would make Damian very unhappy as it discriminates against good
development practices like refactoring code into modules.
> We co
s as more special:
multi sub Foo((Int|Str) where Any) {...}
multi sub foo(Int) {...}
or treat junctions as less special:
multi sub Foo(Int|Str) {...}
multi sub foo(Int where Any) {...}
In each case, these variations in "significance" are now explicitly and
consistently marked.
Damian
^
C<.method> is perfectly legal on *any* topic anywhere that $?SELF doesn't exist.
Damian
formance
was not appreciably worse.
Damian
least-inherited'
most specific non-where type and with 'most-specialized' the strictest
where clause?
I mean: least cumulative derivation distance summed over the set of parameter
types, with greatest *number* of parameter specializations as a tie-breaker
(if required).
Damian
. Metric schemes have far
fewer ambiguities and usually dispatch in an predictable way. Metric schemes
can still provide pure-ordering analyses via static analysis tools or special
warning modes, but pure ordering schemes can't avoid ambiguities or DWIM.
Of course, none of this prevents:
use MMD ;
Damian
y close to the same
performance by jitting an MMD look-up table on-the-fly (possibly with some
table-compression where large hierarchies or many parameters are involved).
Damian
Luke wrote:
Thanks for your very detailed explanation of your views on the Pure
MMD scheme, Damian. I finally understand why you're opposed to it. I
could never really buy your previous argument: "Manhattan distance is
better".
That was never my *argument*, merely my statem
ce those redefined methods may be completely
irrelevant to the particular multimethod being dispatched and therefore
not a reliable distance measure in *its* particular dispatch space.)
To summarize:
* LSP/Meyer requires high level semantics and type relationships be
preserved, *not* that specific dispatch behaviour be preserved.
* So LSP specifically doesn't prohibit changes in a dispatch target
when a hierarchy changes, unless that change in target terminates
normal flow control.
* LSP applies to singly dispatched method calls, not to
multiple dispatch.
Damian
of
instance behaviours are--again by definition--*not* identical.
Or just don't satisfy me.
I suspect it this is the option that will occur. You seem to be looking for
mathematical correctness and theoretical purity...a laudable goal. But I'm
merely looking for practical utility and convenience.
So far, the twain seemed destined never to meet.
Damian
autothreading.
Not surprisingly, I strongly agree with this sentiment! ;-)
Damian
nding the best possible design solutions that has
made/is making/will make Perl 6 insanely great.
Damian
nd of consistency, and if we s/+/:/ in sigs, a sig containing
:$foo could instead be written $:foo (presuming we take : away from
privates as we've postulated),
Yes please. Underscore is much better in that role.
Damian
Texan
equivalents here would be a dire step backwards. They're already overloaded
for word lists and hyperoperators. I think using them for an invocant marker
as well would simply be too much.
The colon really was (and still is) the right choice here.
Damian
ming). So far we're contemplating:
=:=
~~
==
eq
eqv
equals
Do we really need even that many???
Damian
baz")
You're going to need to find another syntax. That one already means something
else (namely, shell-like interpolating word list).
Damian
s. People will associate inward facing >><< with hyperization,
regardless of what's being hyperized.
Damian
else" in a ternary operation. Splitting the ternary destroys
that vital characteristic, which would be a very bad outcome.
Damian
201 - 300 of 1296 matches
Mail list logo
