Re: Lazy lists and optimizing for responsiveness
TSa wrote: IIRC, $Larry has mentioned a Pipe type which to me seems to be just the generic type where you configure the buffer/queue size. In multi-threaded (or connected processes) applications the buffer size needs tuning to balance responsiveness with throughput. Thus your gather proposal could just be a :buffer($size) adverb/trait in the slurpy list declaration and some auto-threading behaviour of the pipe operators ==> and <==. Would the named adverbs for gather work in other contexts as well? Would you suggest this mechanism for specifying the buffering behavior for IO operations? Tim Bray recently wrote about wanting a language that would be smarter about IO buffering by default. Will perl6 be such a language? From "Radical New Language Idea" (http://www.tbray.org/ongoing/When/200x/2005/09/13/Buffering) "I had this program that was running slow and fixed the problem by fixing the I/O buffering. If I had a quarter for every time I’ve done this over my career, I’d have, well, two or three bucks. I think the language-design community ought to take notice. Currently, they cook up new languages so object-oriented that each individual bit has a method repertoire, languages so concurrent that threads execute in incommensurable parallel universes, languages so functional that their effects are completely unobservable... How about a radical new language where the runtime system is hyperaggressive about ensuring that all of its I/O primitives are by default buffered unless the programmer specifically requests otherwise? I’ve heard that there’s something called “COBOL” that has this capability, I’ll have to check it out." Apologies if I've misunderstood things so badly as to make my questions senseless, or worse yet, irrelevant. /au
Re: Ways to add behavior
Larry Wall wrote: Of course, there are other words that are somewhat synonymous with "class", Unfortunately "sort" is already hosed. Maybe "kind". Then evolutionists could make jokes about the K(T) boundary, and creationists could make jokes about "reproducing after their kind". Some of us could make either kind of joke. But perhaps it wouldn't be kind. Which (sort of) takes us back to TSa's (non)sign-off note from 10/5, wherein he suggested: > I've always taken the 'what type of expression' approach to > programming languages and thus have an affinity to type systems and > type theory. > With 'type' in general and 'data type' in particular beeing too > misleading or used in too many different meanings in other programming > languages I propose to coin the notion of 'kind' which has the nice > double meaning of nice and sort. And as such gives the nice pun > > Perl 6, the kind language > > with the two "meanings" > > Perl 6, a kind of language >, the language of kind(ness) I don't know if this is a good sign or a bad one, but the jokes started before you even made the suggestion! :) /au
implicitly doing a role
Hello!
If roles are interfaces, do we want any class that provides an interface
consistent with a role to implicitly do the role? That is, if a class
fulfills all of the interface requirements of a role without actually
saying it does the role, does it do the role anyway?
role Documented {
has $.documentation;
}
class Foo does Documented { ... }
# I don't know why Bar isn't declared as doing Documented
# but it meets all the requirements of doing Documented...
class Bar {
has $.documentation;
}
my $baz = Foo.new( $documentation => "q to quit" );
my $qux = Bar.new( $documentation => "enter to continue" );
sub show_docs ( $obj.does( Documented ) ) { # or $obj ~~ Documented
say $obj.documentation;
}
show_docs( $baz ); # "q to quit"
show_docs( $qux ); # "enter to continue" -or-
# error because Bar doesn't explicitly do
# Documented?
I guess we don't really need implicit doing of roles to get both of
those objects to print their documentation, as we could have something like
sub show_docs ( $obj ) {
if ( defined $obj.documentation ) {
say $obj.documentation;
}
else {
die "Should have included a documentation string"
}
}
Should roles that are implicitly done pass tests like .does and ~~ ?
What are the reasons that they should or shouldn't?
Thanks,
/au
Re: Problem with dwimmery
Luke Palmer wrote:
> However, what do we do about:
>
> while $x-- && some_condition($x) {}
>
> Here, while is being passed a hash, not a do-nothing code. Should we
> force people to write:
>
> while $x-- && some_condition($x) {;}
Do we still have a yada yada yada? Could it be used to differentiate
between the two cases?
while $x-- && some_conditions( $x ) {...}
but
my $hashref = {};
Thanks,
/au
relationship between slurpy parameters and named args?
Hello all! In reading S06 from the svn repository I had some questions about the use of prefix:<*> in different contexts. When used in an argument list, it forces pairs to be interpreted as named args. When used in a parameter list, it causes slurpiness. It seems to me like these are related contexts-- arguments to a sub are supposed to fulfill its parameter list. This makes the overloading of prefix:<*> confusing to me. I'm pretty sure we don't need slurpiness in argument lists, and I don't know if the prefix:<*> notation for named arguments would be useful in parameter lists. But just because I can reason that, for example, prefix:<*> in an argument list can't mean slurpiness, that doesn't make it clear to me what prefix:<*> _does_ mean in that context. I think I understand that prefix:<*> is available outside of parameter lists because that's the only place we need it to mean slurpiness. This particular overloading, however, seems like one that I'm likely to forget or mess up because I don't see the connection between the two different meanings. So, is there a conceptual connection between imposing named argument interpretation on pairs in an arg list and slurping up the end of a parameter list? Are there other meanings of prefix:<*> that relate to one or the other of these two meanings? Any explanations are appreciated! Thanks, /au
Re: Smooth or Chunky?
On Tue, Jan 23 2007, Larry Wall wrote:
> ... Basically, this is the inverse of [;], which turns LoA into a
> CoC.
>
> [;] chunky mumble()
>
> But "chunky" is clunky, and I'm wondering what syntactic relief we
> can give ourselves here. ...
>
> (That almost suggests it should be another metaoperator. Let's all
> shudder together now...but not rule out the possibility.) ...
>
> The possibilities are endless, and I don't doubt that you can think of
> a few more...
To the horror of parsers everywhere, we could make the inverse of [;]
the "outverse" of [;]. What about this?
];[ mumble()
];[ map { $_, $_ * 10 }, 1..3
];[ zip(1,2;3,4)
There's already some precedent for bracketing pairs being pointed the
wrong way, as in (1,1,2,3,5) »+« (1,2,3,5,8). Also, ];[ kind of
looks like a butterfly, which I count as a point in its favor.
In true metaoperator form, you could presumably throw other operators
between the backwards brackets for other chunky operators. I haven't
really thought through what I would want multislice addition ( ]+[ )
or multislice equality testing ( ]==[ ) to mean, though.
Thanks,
/au
--
Austin Frank
http://aufrank.net
GPG Public Key (D7398C2F): http://aufrank.net/personal.asc
pgpnPTTAX4DTv.pgp
Description: PGP signature
