Larry Wall wrote:
: of course, that analogy isn't going to work for "true" functions, which : returns the same all the time, for some given set of arguments.
Oh, well, we pissed off the mathematicians long ago. :-)
At least we had the sense to call them subroutines instead of functions. Of course, that also upset the mathematicians, who wanted to call them functions anyway. Go figure.
That might be because the mathematicians haven't heard of a variant of a function which is allowed to have side effects yet.
Thank goodness the functional programming people have, otherwise Haskell would be pretty useless.
: $fh(:chomp)
Yes, but in general I think an autochomper layer should be applied to the handle/iterator at open/construction time, not at evaluation time.
That seems like a sensible approach. I see it as unlikely that I'm going to want to read a file in a mixture of chomped and not-chomped modes, so I'm going to want to set chomping on the filehandle. However that's done.
And if I *do* ever want to do mixed-chomping on a read, I should just open the file in non-chomped mode and chomp manually when I know I want to do it, because Perl won't be able to figure it out for me except in some really really weird circumstances I don't really want to be thinkinga bout.
: # what about making &foo( :bar ) the same as : # &foo.assuming( :bar) ? ah, that not gonna work.. but I : # think that feature definitely wants something more short : # than .assuming; maybe even some special syntactic honey. : # because it's fun(ny|ctional)
We made it long on purpose for readability. You can always use a macro to obfuscate it. What we're *not* going to do is autocurry missing parameters like Haskell. That just screws up all the compiler's expectations on return types. If I forget to supply an argument, I want an error, not a function pointer. I can add in the .assuming myself when I decide I need it. All autocurrying does is sweep the dirt under the carpet for someone else to deal with.
Yes, not really a Perlish thing is it? Haskell programmers cope with it because the entire type system explodes if you return a function instead of a value somewhere (by leaving out one or more arguments), but Perl's unlikely to do that with quite the same level of reliability, I would think. While I'm pleased that Perl allows me to pass functions around with almost the same ease as I get in Haskell, because Perl isn't a pure functional language, the thought of making it behave like that is quite scary.
: class Foo { : has $.counter; : # multi postcircumfix:<( )> makes me sick :(
Not sure it needs to be multi. Generally a reference tells you exactly who you're dispatching to.
: method bar is default {
: $.counter++;
: }
: }
: : # emulating 10...
: $a = new Foo :counter(10);
: say $a.bar;
: say $a();
Probably want to handle list context as well.
I'm sorry, but from a C++ background, overriding postcircumfix:<( )> feels far more natural to me than setting 'is default' on some method. What if you do 'is default' on two methods? Compile-time error? What if you're opening up someone else's class and want to override the existing default (okay, so you shouldn't be doing that in an OOP world, but what if you are? What if you're like me and like Perl's delightful mishmash of paradigms while simultaneously liking other languages for their purity? What if I actually talk about something relevant?)
: # other thingies:
: : sub foo { ... };
: @array = @&foo # all the results of foo, lazily.
Don't see the need for that when
@array := foo()
does laziness implicitly already. Maybe even
@array = foo()
maintains laziness if it sees an infinite iterator in the return value of foo(). Or maybe it blows up and tells you to use ":=" to avoid trying to make a copy. That's probably cleaner.
This is going to take me a while to get my head round... Does this particular foo() return an iterator? Or is it something which is iterated? Have I missed a bit of a synopsis or apocalypse which would make all this clear to me or are we still in handwaving mode?
Exceptions should not be used for something so mundane as running out fo values.
Amen to that! One reason I ran screaming from Java was having to catch ArrayOutOfBoundsException all the time. And all those exceptions which the compiler forces you to catch. They're handy, but there is a limit. I prefer return values which can indicate if they're valid or not. undef is excellent for that :-)
A string pretending to be undef can be even better. Can we still do that? I seem to recall it being in something at some point along the way.
If that's necessary to keep the Lazy from blocking when it runs out of values. Just like an ordinary array, a Lazy has to be aware of when it is out of values, and when it should call into some meta-Lazy for more iterator values. And I suppose that meta-Lazy could in turn have a meta-meta-Lazy, which could have a meta-meta-meta-Lazy, and now my brane hurts.
And soon your entire program consists of code which may or may not ever be evaluated. Welcome to Haskell :-)
