Responses to Comments from Damian ConwayMovable Type Pro 4.382016-07-03T23:22:53Zhttp://blogs.perl.org/mt/mt-cp.fcgi?__mode=feed&_type=replies&blog_id=0&id=1293:-)
That is less biblical than what I meant… but it works too.tag:blogs.perl.org,2011:/users/damian_conway//875.2403#833762011-11-06T14:02:17ZAristotlehttp://plasmasturm.org/:-)

That is less biblical than what I meant… but it works too.

]]>
Actually p5-mop will not have a built in type constraint system, it will be able to support existing type constraint systems via the trait mechanism. This test shows an example of that.tag:blogs.perl.org,2014:/users/ovid//11.5747#13291642014-03-07T15:13:49ZStevan Little
Actually p5-mop will not have a built in type constraint system, it will be able to support existing type constraint systems via the trait mechanism. This test shows an example of that.
]]>
I honestly don't know why it's taken this long to even have them experimentally in the core.
Yeah? Well I know. And Ross Attrill said it:
Many of these modules seem to have many more features than the 5.19 proposal.
That’s why. Everybody wants lots of features in signatures, and everybody wants a different set. So every previous proposal suffered the same fate: people couldn’t quite accept a signature proposal that lacked just the one extra feature that seemed indispensable given the overall minimalism of the proposal in question, and invariably that feature (or two) would throw open a wide array of controversial design choices. Because it always seemed like the barest minimum was just too little, at least to someone, it kept meeting death by p5p megathread.
Quite why this one evaded that trap, I don’t know; whether it was solely Peter Martini’s commitment to stick to the simplest viable thing is not clear to me, since the discussion swayed dangerously and teetered close to doom territory several times. But somehow it emerged unscathed from every incident, possibly because they threads usually died down not long after they started to flirt with disaster – however that managed to happen. Somehow this was the proposal to negotiate all those mine fields and live to tell the tale.
Hard to believe sometimes how much luxury can be the enemy of comfort.tag:blogs.perl.org,2014:/users/ovid//11.5747#13292252014-03-07T19:59:31ZAristotlehttp://plasmasturm.org/

I honestly don't know why it's taken this long to even have them experimentally in the core.

Yeah? Well I know. And Ross Attrill said it:

Many of these modules seem to have many more features than the 5.19 proposal.

That’s why. Everybody wants lots of features in signatures, and everybody wants a different set. So every previous proposal suffered the same fate: people couldn’t quite accept a signature proposal that lacked just the one extra feature that seemed indispensable given the overall minimalism of the proposal in question, and invariably that feature (or two) would throw open a wide array of controversial design choices. Because it always seemed like the barest minimum was just too little, at least to someone, it kept meeting death by p5p megathread.

Quite why this one evaded that trap, I don’t know; whether it was solely Peter Martini’s commitment to stick to the simplest viable thing is not clear to me, since the discussion swayed dangerously and teetered close to doom territory several times. But somehow it emerged unscathed from every incident, possibly because they threads usually died down not long after they started to flirt with disaster – however that managed to happen. Somehow this was the proposal to negotiate all those mine fields and live to tell the tale.

Hard to believe sometimes how much luxury can be the enemy of comfort.

]]>
(Oh and btw, in case my comment seemed berating – it wasn’t supposed to be, not exactly: I was myself one of the people who, in a previous round, thought a minimal signature proposal really can’t work without just that one extra feature. And that’s after I’d seen a previous proposal die from being loaded with obviously too many features in the first place. So the next time around I thought I was arguing for the minimum… which was nonsense. So by the time Peter Martini showed up with his patch, I had finally swallowed my lesson: any viable proposal must have no features. And that’s what we got. And that’s why we got anything at all. Hooray! At long last…)tag:blogs.perl.org,2014:/users/ovid//11.5747#13295482014-03-09T04:16:41ZAristotlehttp://plasmasturm.org/
(Oh and btw, in case my comment seemed berating – it wasn’t supposed to be, not exactly: I was myself one of the people who, in a previous round, thought a minimal signature proposal really can’t work without just that one extra feature. And that’s after I’d seen a previous proposal die from being loaded with obviously too many features in the first place. So the next time around I thought I was arguing for the minimum… which was nonsense. So by the time Peter Martini showed up with his patch, I had finally swallowed my lesson: any viable proposal must have no features. And that’s what we got. And that’s why we got anything at all. Hooray! At long last…)
]]>
I only hit a problem with each recently (see http://www.martin-evans.me.uk/node/159). Using a hash in list context will use the iterator internally so simply assigning the hash you are iterating over to another hash will cause an infinite loop.
I now never use each. Even if you find the narrow safe cases someone else can come along and easily break your code.tag:blogs.perl.org,2014:/users/rurban//39.5878#13432732014-04-03T08:43:38Zmartin.j.evans
I only hit a problem with each recently (see http://www.martin-evans.me.uk/node/159). Using a hash in list context will use the iterator internally so simply assigning the hash you are iterating over to another hash will cause an infinite loop.

I now never use each. Even if you find the narrow safe cases someone else can come along and easily break your code.

]]>
I've also seen situations where each was called in a loop that short-circuits:
while( my ($key, $val) = each %hash ) {
last if $key =~ /foo/;
}
Then later on, each is used again without resetting the internal state, even though the programmer expected to iterate over the entire hash. With a hash stored globally (yes, this is bad in itself, but it happens) in a persistent environment like mod_perl, this can even happen across different requests in the same process.tag:blogs.perl.org,2014:/users/rurban//39.5878#13433842014-04-03T14:09:12ZTimm Murrayhttp://www.wumpus-cave.net
I've also seen situations where each was called in a loop that short-circuits:

while( my ($key, $val) = each %hash ) {
last if $key =~ /foo/;
}

Then later on, each is used again without resetting the internal state, even though the programmer expected to iterate over the entire hash. With a hash stored globally (yes, this is bad in itself, but it happens) in a persistent environment like mod_perl, this can even happen across different requests in the same process.

]]>
I wonder if there's some way to make the each op warn if the iterator isn't where it's expected to be.tag:blogs.perl.org,2014:/users/rurban//39.5878#13451292014-04-07T15:21:47ZTim Buncehttp://blog.timbunce.org
I wonder if there's some way to make the each op warn if the iterator isn't where it's expected to be.]]>
Unfortunately, glob is similarly broken:
perl -E 'for my $x (qw(* )) { print "$x: ", scalar glob($x), "\n"}'
tag:blogs.perl.org,2014:/users/rurban//39.5878#13816262014-05-15T14:01:31ZE. Chorobahttp://www.perlmonks.org/?node_id=832495
Unfortunately, glob is similarly broken:

]]>
Damian Conway
Thanks for your comment.
But the multi keyword doesn't provide static function overloading.
The multi keyword provides dynamic multiple dispatch.
I think is is not good because performance cost occur when type check is done at run-time,
and it increase launguage complexity.
Perl has already complex syntax. I don't hope more complexity.
For example, I like cpan-minus than cpan-plus. why? cpan-minus is fast, minimal and enough.
I like small aproach which can solve problems smart.
For the long time, Perl is complained for the dirty and complex syntax.
We should recognize more perl complexity is more week point of Perl language.
So the multi keyword is a perfectly appropriate addition to dynamic languages like Perl 6, and maybe even eventually to Perl 5.
I strongly oppose the mix of dynamic features and static features in one space.
It mix the week point of dynamic language and the week point of static language.
It don't mix the good point of dynamic language and the good point of static lanuage.
It is slow and complex things.
It is not simple and fast things.
My proposal is that "how about implementing real static features in static package?".
package Foo : static;
static package is optimised for performance, less memory, and parallelization.
Perl can call the method of static package.
golang is good example.
golang has many syntax limitaion.(not exception, not inheritance, not generics).
but the limitation is good for performance, compile speed, less memory, and parallelization.
I think Perl need the question "What limitation is good for us?".
tag:blogs.perl.org,2016:/users/yuki_kimoto//2020.7471#17057512016-05-10T08:12:26ZYuki Kimotohttp://blogs.perl.org/users/yuki_kimoto/2013/08/author-yuki-kimoto.html
Damian Conway

I think is is not good because performance cost occur when type check is done at run-time,
and it increase launguage complexity.
Perl has already complex syntax. I don't hope more complexity.

For example, I like cpan-minus than cpan-plus. why? cpan-minus is fast, minimal and enough.
I like small aproach which can solve problems smart.

For the long time, Perl is complained for the dirty and complex syntax.
We should recognize more perl complexity is more week point of Perl language.

So the multi keyword is a perfectly appropriate addition to dynamic languages like Perl 6, and maybe even eventually to Perl 5.

I strongly oppose the mix of dynamic features and static features in one space.
It mix the week point of dynamic language and the week point of static language.
It don't mix the good point of dynamic language and the good point of static lanuage.
It is slow and complex things.
It is not simple and fast things.

My proposal is that "how about implementing real static features in static package?".

package Foo : static;

static package is optimised for performance, less memory, and parallelization.
Perl can call the method of static package.
golang is good example.
golang has many syntax limitaion.(not exception, not inheritance, not generics).
but the limitation is good for performance, compile speed, less memory, and parallelization.