Re: Perl6 perlplexities
Rob Kinyon [EMAIL PROTECTED] writes: First-class blocks make continuations and coros almost neglible to implement from an API perspective. Almost makes me wonder how much trouble it would be to implement this in P5 ... Um... tosh. Seriously. Full continuations need some fairly serious retooling of the call stack if they are to work properly. And one shot continuations are the next best thing to useless. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/
Re: Perl6 perlplexities [was: Re: $1 change issues...]
On Fri, 4 Nov 2005, Juerd wrote: Whatever, the new system by contrast seems to me to be at least 400% more complex, but it won't buy me 400% more functionality. It will buy you 400% in saving typing, 4000% in less debubbing and 4% in maintainability(==readability). Of course drawing any figure on such loose terms as I did in the first place is not serious and I didn't meant it to be, using them more for illustrational purposes reflecting my own perception. But the point is: are you sure that you have a 40k% gain in readability? That's quite a number!! And the impression I have, that I'm trying to stress once more (but the last time!) is that trying to stuff everything in the signature system is not increasing it any more and that a _slightly_ simpler one would do instead. On Fri, 4 Nov 2005, Rob Kinyon wrote: So, for a bit of extra complexity, I get peace of mind for myself and my users. The point being, and I'm stressing it once again but no more than once, that maybe we're adding two bits of extra complexity, whereas just one bit not only would have been enough, but would have bought you even more peace of mind. Then again: this is a _feeling_ I got e.g. by reading the appearently endless discussions about the specifications of sub parameters, which seem to ensue inherent technical difficulties having to do with the attempt _conciliate_ too many different paradigms. Michele -- If memory serves, Prof. Hermann Zapf considered using Palatino for his wedding invitation (but reconsidered and used one of his wife's designs instead --- there's a lesson in that I guess). - William Adams in comp.text.tex, Re: Simple Wedding Invitations in LaTeX2e
Re: Perl6 perlplexities [was: Re: $1 change issues...]
On 11/7/05, Michele Dondi [EMAIL PROTECTED] wrote: On Fri, 4 Nov 2005, Rob Kinyon wrote: So, for a bit of extra complexity, I get peace of mind for myself and my users. The point being, and I'm stressing it once again but no more than once, that maybe we're adding two bits of extra complexity, whereas just one bit not only would have been enough, but would have bought you even more peace of mind. Then again: this is a _feeling_ I got e.g. by reading the appearently endless discussions about the specifications of sub parameters, which seem to ensue inherent technical difficulties having to do with the attempt _conciliate_ too many different paradigms. Honestly? I skip about 50% of the discussions on this list. I don't care about most of the syntax discussions and I don't care about sub signatures. Well, I -DO- care, just not enough to wrangle about it. All I care about is Can I do what I want to do in an easy fashion? That's why I spent so much time on roles and why I've released Perl6::Roles to CPAN. (Well, that was for DBI-2, but I can claim it was for me, right?) The point is that I will not use a lot of the features in Perl6, just like I didn't use alot of the features in Perl5. I doubt I'll ever use PGE directly (though macros will be nice, once I figure out where I'd use them). Same with most of the subroutine types. Though, I do find the complexity reassuring. I like having the options, even though I will never use them. The alternative is Perl5, where you can do (almost) anything you could want, except you have you jump through lots of hoops and you end up with something that works, but really really slowly. No-one wants that. Rob
Re: Perl6 perlplexities [was: Re: $1 change issues...]
On Monday 07 November 2005 09:26 am, Rob Kinyon wrote: On 11/7/05, Michele Dondi [EMAIL PROTECTED] wrote: On Fri, 4 Nov 2005, Rob Kinyon wrote: So, for a bit of extra complexity, I get peace of mind for myself and my users. The point being, and I'm stressing it once again but no more than once, that maybe we're adding two bits of extra complexity, whereas just one bit not only would have been enough, but would have bought you even more peace of mind. Then again: this is a _feeling_ I got e.g. by reading the appearently endless discussions about the specifications of sub parameters, which seem to ensue inherent technical difficulties having to do with the attempt _conciliate_ too many different paradigms. [...] Though, I do find the complexity reassuring. I like having the options, even though I will never use them. The alternative is Perl5, where you can do (almost) anything you could want, except you have you jump through lots of hoops and you end up with something that works, but really really slowly. No-one wants that. But it's not such a black-and-white thing. If 1 bit of complexity covers 90% of cases, 10 bits gets you 99%, 100 bits gets you 99.9%, and so on, where do you stop? Where do you say okay, I think we're doing good enough, let's not add more complexity ? Especially when that complexity isn't optional. I think that's really a common fear, that Perl 6 is going well beyond that point of sensibility. If you want to get into personal beliefs, I think that function signatures are such a complexity quagmire -- and that they're line-noise ugly to boot. Andrew
Re: Perl6 perlplexities [was: Re: $1 change issues...]
On 2005-11-07 1:30 PM, Andrew Rodland [EMAIL PROTECTED] wrote:
Especially when that complexity isn't optional. I
think that's really a common fear, that Perl 6 is going well beyond that
point of sensibility.
If you want to get into personal beliefs, I think that function signatures are
such a complexity quagmire -- and that they're line-noise ugly to boot.
But the ugly and complex bits of function signatures are completely
optional. In the usual case, you can just say
sub foo($x, $y) { do stuff with $x and $y }
Or
method foo($x, $y) { default invocant name used to do stuff with $x and $y }
And not have to worry about it.
Re: Perl6 perlplexities [was: Re: $1 change issues...]
Andrew Rodland skribis 2005-11-07 13:30 (-0500):
If you want to get into personal beliefs, I think that function signatures
are
such a complexity quagmire -- and that they're line-noise ugly to boot.
The nice thing about signatures is that they let you write what you
mean. This saves you an entire translation from what you mean to some
Perl code that manipulates @_. This translation is hard, and error
prone, as is the code that comes from it.
I think that even without any introduction to the subtleties of
signatures, any newbie with some programming experience will instantly
understand the essence of:
sub my_join ($sep, [EMAIL PROTECTED]) {
foo($sep, @elems);
}
and
method connect ($host, $port = 80) { ... }
While this isn't quite so clear:
sub my_join {
my $sep = shift;
foo($sep, @_);
}
sub connect {
croak ... if @_ 1;
croak ... if @_ 2;
my ($host, $port) = @_;
$port = 80 if not defined $port;
...
}
Or let's take this simple example:
sub convert (:$from, :$to, :$thing) { ... }
That isn't quite my %args = @_;. Yes, that works, but the only real
way we keep doing it is that the full solution sucks in plain Perl 5:
sub convert {
croak ... if (@_ % 2) != 0;
my %args = @_;
croak ... if not exists $args{from};
croak ... if not exists $args{to};
croak ... if not exists $args{thing};
my $from = delete $args{from};
my $to= delete $args{to};
my $thing = delete $args{thing};
croak ... if keys %args;
...
}
before you shout that I'm doing something wrong, yeah, I've been out of
this game for a while. Which only strengthens my point: it's hard to do
it right in Perl 5!
So, the typical answer is: use a module! Good idea, really, but that
still doesn't fix the problem. There are several modules out there that
handle argument parsing, that in practice you need to know the
subtleties of each of them. And none lets you combine scalar and list
context, because only prototypes can do that. I don't have to explain
why prototypes suck, and I think you can guess why combining them with a
parsing module sucks too.
For fun, one example with Params::Check:
use Params::Check qw(check);
sub convert {
croak ... if (@_ % 2 ) != 0;
my %args = @_;
check(
{
from = { required = 1, store = \my $from },
to= { required = 1, store = \my $to },
thing = { required = 1, store = \my $thing },
},
\%args,
1,
);
...
}
And oh boy, would this all have been VERY different if I wanted to
simulate this instead:
sub convert (:$from, :$to, :$thing is rw) { ... }
I think the complexity of signatures is much less than that of doing the
same things without them, with the extra benefit that even beginners
will (almost) instantly understand most of it!
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Perl6 perlplexities [was: Re: $1 change issues...]
On Mon, Nov 07, 2005 at 09:51:39PM +0100, Juerd wrote:
: Or let's take this simple example:
:
: sub convert (:$from, :$to, :$thing) { ... }
:
: That isn't quite my %args = @_;. Yes, that works, but the only real
: way we keep doing it is that the full solution sucks in plain Perl 5:
:
: sub convert {
: croak ... if (@_ % 2) != 0;
: my %args = @_;
: croak ... if not exists $args{from};
: croak ... if not exists $args{to};
: croak ... if not exists $args{thing};
: my $from = delete $args{from};
: my $to= delete $args{to};
: my $thing = delete $args{thing};
: croak ... if keys %args;
: ...
: }
:
: before you shout that I'm doing something wrong, yeah, I've been out of
: this game for a while. Which only strengthens my point: it's hard to do
: it right in Perl 5!
Okay, I won't shout (not even on PerlMonks :-), but named parameters
default to optional, so you'd have to write that as
sub convert (:$from!, :$to!, :$thing!) { ... }
in the current scheme of things.
Larry
Re: Perl6 perlplexities [was: Re: $1 change issues...]
Okay, I won't shout (not even on PerlMonks :-), but named parameters
default to optional, so you'd have to write that as
sub convert (:$from!, :$to!, :$thing!) { ... }
in the current scheme of things.
Either way, the point is still that the benefits FAR outweigh any
additional complexity. Ruby could benefit from this, too. (While
first-class blocks rock my world, the weird subroutine signature stuff
most certainly doesn't.)
Rob
Re: Perl6 perlplexities [was: Re: $1 change issues...]
On Monday 07 November 2005 03:51 pm, Juerd wrote: Andrew Rodland skribis 2005-11-07 13:30 (-0500): If you want to get into personal beliefs, I think that function signatures are such a complexity quagmire -- and that they're line-noise ugly to boot. The nice thing about signatures is that they let you write what you mean. This saves you an entire translation from what you mean to some Perl code that manipulates @_. This translation is hard, and error prone, as is the code that comes from it. Sorry, I wasn't clear here, so I hope you don't mind my cutting you off. What I meant wasn't signatures are too much complexity -- they're not; they're simply doing something useful -- but rather too much complexity is getting thrown into signatures to the point where the gain isn't so much, but the complexity starts creeping in, and you need a book just for everyday tasks. Combined with what seems to me like a thoroughly unreadable syntax, function signatures are starting to look like a brand new version of the regex mess that p6 ditched in favor of the more consistent, more readable patterns. I'm going to stop going on about this one way or another, but I just wanted to make myself clear first. Andrew
Re: Perl6 perlplexities [was: Re: $1 change issues...]
On Mon, Nov 07, 2005 at 04:46:06PM -0500, Andrew Rodland wrote: Sorry, I wasn't clear here, so I hope you don't mind my cutting you off. What I meant wasn't signatures are too much complexity -- they're not; they're simply doing something useful -- but rather too much complexity is getting thrown into signatures to the point where the gain isn't so much, but the complexity starts creeping in, and you need a book just for everyday tasks. Combined with what seems to me like a thoroughly unreadable syntax, function signatures are starting to look like a brand new version of the regex mess that p6 ditched in favor of the more consistent, more readable patterns. Well, just to point out that we didn't know a priori that the regexp syntax was a mess until we got extensive experience with it and with what we wanted from it. In the early 1990s, perl and its regular expressions were the coolest stuff ever. :-) I think the same holds for signature syntax. @Larry are doing the best juggling act they can to get it worked out such that once it's set in stone, the signature syntax will be intuitive, sensible, unobtrusive, etc. There may be complexity, but most times you shouldn't see it unless you want to do something strange and wonderous and magical. The only reason it looks like there's complexity now is because we're pushing and prodding the signature syntax to see what works and what doesn't. (At this point, I'm *really* glad the language design is taking years) Because of this there will be times when all of the guts are exposed, but I don't think that it'll always be that way. By the time perl 6.0.0 rolls around, the guts should be tucked away nicely. my two cents, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Perl6 perlplexities [was: Re: $1 change issues...]
Larry Wall skribis 2005-11-07 13:20 (-0800):
Okay, I won't shout (not even on PerlMonks :-), but named parameters
default to optional, so you'd have to write that as
sub convert (:$from!, :$to!, :$thing!) { ... }
in the current scheme of things.
Ah, thanks.
I hadn't noticed this change, but I like it.
I've updated the PM node :)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Perl6 perlplexities [was: Re: $1 change issues...]
On Thu, 20 Oct 2005, Nate Wiger wrote:
just to be sure we're on the same page: You say that the thing that
is going to hinder migration to Perl 6 is the fact that it's different
from Perl 5.
Intentionally trite oversimplification. My problem is that it's
different in some ways which are not truly useful, and that cause
unnecessary relearning/rewriting/incompatibilities.
I've waited long before answering this mail because I wanted to see more
along the way of the Perl6 fears thread.
Now the observation above gives me a chance to express my own
perlplexities. I'm not bothered by the changes in themselves nor am I
concerned by the necessary (or not)
relearning/rewriting/incompatibilities.
thepoint
But there's an observation I can't help doing: it seems to me that the
ratio of increase in the complexity of (some aspects of) the language _is_
_much_ _bigger_ than that in the functionality such complexity is supposed
to provide.
/thepoint
Let me explain: we all know that Perl5 has a very simple parameter passing
mechanism for subs and an even more rudimentary {prototyping,signature}
mechanism that one actually seldom uses. With this simple mechanism one
can implement or fake quite a lot of parameter passing paradigms.
It seems to me that this covers at least 90% of one's common needs. But
for simple subs in Perl6 I will probably still use @_; err... that or the
new pointy subs which are indeed so cool! Whatever, the new system by
contrast seems to me to be at least 400% more complex, but it won't buy me
400% more functionality.
Quite similarly the old OO support was so light to the point of being
immaterial, so that many people even thin it plainly sucks. But in
retrospect it was amazing to note how many OO paradigms and techniques one
coudl get out of simple, tiny, appearently innocent function called
bless()! Of course these implied lots of workarounds and hacks, be them
damn sexy hacks, but hacks: ok, granted! But the new system is what? 10k%
more complex? The question is: does this buy me all that 10k% more
functionality, or would have been a _simpler_ design, say only 1k% more
complex be enough?
It is always amazing, both in a programming language (or CS) context and
in totally unrelated ones, when from a simple scheme you can draw a rich,
huge set of consequences. But of course is not in Perl's nature an aim for
extreme simplicity; nothing to say... Perl5 is full of inconsistencies
in the form ad hoc dwimmeries and magic, while Perl6 already cures them by
trying to make them into structural magic of a globally more coherent
and consistent framework. But it's still my impression that it's pushing
in quite _too_ much structural complexity as well.
This is fundamentally the _only_ perlplexity about Perl6 I have...
Of course this is only a meditation and I know that I'm not knowledgeable
enough to be fully aware of all the implications of some aspects I've
touched upon in this writing, and thus I'm not expecting it to change or
influence the direction of evolution of language (re-)design. Just wanted
to let you all know.
Michele
--
Ira Kane: You wouldn't understand.
Dr. Allison Reed: No, how could I? I'm just a humorless ice queen in
desperate need of a good humping.
Ira Kane: Oh... you heard that, huh?
Dr. Allison Reed: Loud and clear.
- Evolution, Ivan Reitman
Re: Perl6 perlplexities [was: Re: $1 change issues...]
Michele Dondi skribis 2005-11-04 14:58 (+0100):
Let me explain: we all know that Perl5 has a very simple parameter
passing mechanism for subs and an even more rudimentary
{prototyping,signature} mechanism that one actually seldom uses.
It is unused because it sucks. /blunt
With this simple mechanism one can implement or fake quite a lot of
parameter passing paradigms.
And it is a lot of work to do so.
for simple subs in Perl6 I will probably still use @_
You'd be a fool to do so, with the sole exception of list manipulation,
which at least in my codebase isn't used quite that much, and almost
never listens to the qualification simple sub.
Compare:
sub dosomething { @_[0] blah @_[1] }
sub dosomething ($a, $b) { $a blah $b }
sub dosomething { $^a blah $^b }
The @_ solution is really the most ugly and hard to type of the three
possibilities.
err... that or the new pointy subs which are indeed so cool!
Cool, but probably not a good idea for named subs, if only for style.
our dosomething ::= - $a, $b { $a blah $b }
Not really a winner in any perspective.
Whatever, the new system by contrast seems to me to be at least 400%
more complex, but it won't buy me 400% more functionality.
It will buy you 400% in saving typing, 4000% in less debubbing and
4% in maintainability(==readability).
But the new system is what? 10k% more complex? The question is: does
this buy me all that 10k% more functionality, or would have been a
_simpler_ design, say only 1k% more complex be enough?
I love the OO system, and although it adds to complexity, I believe the
functionality gained is much greater. However, I do not see why we need
to add three ugly operators for features that I suspect almost nobody
will use: .?, .* and .+
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Perl6 perlplexities [was: Re: $1 change issues...]
On Fri, 4 Nov 2005, Juerd wrote:
for simple subs in Perl6 I will probably still use @_
You'd be a fool to do so, with the sole exception of list manipulation,
[snip]
Compare:
sub dosomething { @_[0] blah @_[1] }
sub dosomething ($a, $b) { $a blah $b }
sub dosomething { $^a blah $^b }
Ouch! I take back my words... (should've thought of it better!)
The @_ solution is really the most ugly and hard to type of the three
possibilities.
I currently only rarely use @_ *directly*. I Cshift and assign a lot
instead. Indeed both are still unnecessarily complex and I once gain take
back my word.
I'm still convinced my remark _partly_ applies in the sense that the
overall impression is that a vast majority of most common needs is
addressed by a *subset* of the current features and trying to stuff all
them in has brought in quite a lot of discussions of which I'm not even
sure if they've all settled down.
Michele
--
[are there] Any areas of mathematical knowledge or skills that we lost?
Yes, but I don't remember what they are.
- Kevin Foltinek in sci.math [edited]
Re: Perl6 perlplexities [was: Re: $1 change issues...]
On 11/4/05, Michele Dondi [EMAIL PROTECTED] wrote:
I'm still convinced my remark _partly_ applies in the sense that the
overall impression is that a vast majority of most common needs is
addressed by a *subset* of the current features and trying to stuff all
them in has brought in quite a lot of discussions of which I'm not even
sure if they've all settled down.
I think a good comparison can be made to Ruby. For work, I've been
learning Ruby this past week (we're going to try out Rails to see if
we like it). As my colleague put it, Ruby has all the P6 features we
want and it's usable now.
Ruby's OO system is 1000% more complex that Perl5's. Yet, it's still a
net win. For one thing, I don't have to write the following anymore
(lifted from a CPAN module I am working on):
sub children {
my $self = shift;
if ( caller-isa( __PACKAGE__ ) || $self-isa( scalar(caller) ) ) {
return wantarray ? @{$self-{_children}} : $self-{_children};
}
else {
return @{$self-{_children}};
}
}
This is in a vain attempt to implement a protected subroutine. In
fact, I really want a private writing accessor with a public reading
accessor, but have absolutely no way to implement that.
Why do I want such a beast? Because I want to GUARANTEE in an absolute
kind of way that, unless my user truly intended to do so, he's not
going to be able to accidentally screw up my internal state.
And, no, I don't want to use inside-out classes. They're cool (in
all the good and bad senses of the word), don't play well with other
P5 solutions, and STILL don't provide the necessary granularity. The
problem isn't with $object-{foo} = 3; The problem is with the
subroutines that aren't real methods with correct protection
mechanisms.
So, for a bit of extra complexity, I get peace of mind for myself and my users.
(Oh, and Ruby has first-class block. W00T!)
Rob
Re: Perl6 perlplexities [was: Re: $1 change issues...]
It will buy you 400% in saving typing, 4000% in less debubbing and 4% in maintainability(==readability). I think this is the main point here. With @_ and bless() you could do cool things, but again it happened at the expense of repetition and all those other buzzwords (maintainability, et al). As long as p6 isn't taking away from any of the functionality or DWIMery I won't have any objections - Sebastian
Re: Perl6 perlplexities [was: Re: $1 change issues...]
On Fri, Nov 04, 2005 at 03:49:05PM +0100, Juerd wrote:
sub dosomething { $^a blah $^b }
I think the $^ variables are only allowed in bare (or -) blocks. (As a
guard against san.. er, madness.)
--
Ilmari Vacklin (wolverian)
Re: Perl6 perlplexities
Juerd [EMAIL PROTECTED] writes:
Michele Dondi skribis 2005-11-04 14:58 (+0100):
Let me explain: we all know that Perl5 has a very simple parameter
passing mechanism for subs and an even more rudimentary
{prototyping,signature} mechanism that one actually seldom uses.
It is unused because it sucks. /blunt
With this simple mechanism one can implement or fake quite a lot of
parameter passing paradigms.
And it is a lot of work to do so.
for simple subs in Perl6 I will probably still use @_
You'd be a fool to do so, with the sole exception of list manipulation,
which at least in my codebase isn't used quite that much, and almost
never listens to the qualification simple sub.
Compare:
sub dosomething { @_[0] blah @_[1] }
sub dosomething ($a, $b) { $a blah $b }
sub dosomething { $^a blah $^b }
The @_ solution is really the most ugly and hard to type of the three
possibilities.
err... that or the new pointy subs which are indeed so cool!
Cool, but probably not a good idea for named subs, if only for style.
our dosomething ::= - $a, $b { $a blah $b }
Not really a winner in any perspective.
And the return semantics of pointy blocks are different, you have to be careful
about doing an explicit return in them because that returns to the caller of
the lexical scope in which they were defined (otherwise for ... - ... {...}
wouldn't work)
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
Re: Perl6 perlplexities
Rob Kinyon [EMAIL PROTECTED] writes:
On 11/4/05, Michele Dondi [EMAIL PROTECTED] wrote:
I'm still convinced my remark _partly_ applies in the sense that the
overall impression is that a vast majority of most common needs is
addressed by a *subset* of the current features and trying to stuff all
them in has brought in quite a lot of discussions of which I'm not even
sure if they've all settled down.
I think a good comparison can be made to Ruby. For work, I've been
learning Ruby this past week (we're going to try out Rails to see if
we like it). As my colleague put it, Ruby has all the P6 features we
want and it's usable now.
Ruby's OO system is 1000% more complex that Perl5's. Yet, it's still a
net win. For one thing, I don't have to write the following anymore
(lifted from a CPAN module I am working on):
The thing about Ruby (and Perl 6's) OO system is that the complexity is in the
right place -- tucked away where most people don't have to worry about it until
they want to do something complex.
sub children {
my $self = shift;
if ( caller-isa( __PACKAGE__ ) || $self-isa( scalar(caller) ) ) {
return wantarray ? @{$self-{_children}} : $self-{_children};
}
else {
return @{$self-{_children}};
}
}
This is in a vain attempt to implement a protected subroutine. In
fact, I really want a private writing accessor with a public reading
accessor, but have absolutely no way to implement that.
Why do I want such a beast? Because I want to GUARANTEE in an absolute
kind of way that, unless my user truly intended to do so, he's not
going to be able to accidentally screw up my internal state.
And when your user does want to, essentially say Nah, you screwed up designing
that object protocol, children shouldn't've been protected. it's the work of a
moment to write:
thing.send(:children, *args)
(Oh, and Ruby has first-class block. W00T!)
And continuations. But continuations are scary. Good scary, but still scary.
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
Re: Perl6 perlplexities
And when your user does want to, essentially say Nah, you screwed up designing that object protocol, children shouldn't've been protected. it's the work of a moment to write: thing.send(:children, *args) I told you I'm still learning. I hadn't gotten to that part of the Pickaxe. :-/ (Oh, and Ruby has first-class block. W00T!) And continuations. But continuations are scary. Good scary, but still scary. First-class blocks make continuations and coros almost neglible to implement from an API perspective. Almost makes me wonder how much trouble it would be to implement this in P5 ... Rob
