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 reto
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 chang
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 getti
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
> 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 comp
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:
:
:
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 a
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
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 agai
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 ex
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
> 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 Pickax
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
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
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)
> 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
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
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 $
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.
> With this simple mech
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 no
20 matches
Mail list logo
