1. I know there is the xx operator for repeating strings. I also know you can use XX for repeating either closures, blocks, or subs; though I'm not sure which. Assuming you could use XX on a sub, how would you gather the results into an array?
@names = &get_next(...) XX 5;
Would this even be possible, or is it now?
2. Is anyone working on making a Win32 module for Perl6 yet, or porting over the p5 one? If not, I may be willing to make one, along with some help from friends.
If I do, does anyone have any pointers or suggestions for me when I begin the adventure? Specifically, how it should be organized, among other things.
> 1. I know there is the xx operator for repeating strings. I also know you > can use XX for repeating either closures, blocks, or subs; though I'm not > sure which. Assuming you could use XX on a sub, how would you gather the > results into an array? > @names = &get_next(...) XX 5;
I'm not sure the XX thing will happen, but if it does, it'd be most useful if it wouldn't treat a sub call differently.
In other words,
@random = { rand } XX 5;
would return 5 different random values, while
@random = { rand }() XX 5;
would do exactly the same as
@random = rand xx 5;
And your
@names = &get_next(...) XX 5; # Why the &, by the way?
I think should be
@names = { get_next(...) } XX 5;
or, if get_next doesn't take arguments,
@names = &get_next XX 5;
Note that if the ... should change each of the 5 times, then this should be done using map:
1..5 ==> map { get_next($_) } ==> @names;
or of course
@names = map { get_next($_) }, 1..5;
The XX was proposed mainly because the 1..5 part of map often does not make sense as a range, and in those cases you just abuse it for repetition.
> I'm not sure the XX thing will happen, but if it does, it'd be most > useful if it wouldn't treat a sub call differently.
I forgot rationale.
It shouldn't treat a sub call differently, so that a called sub can in a useful manner return a closure, which is then executed several times. The same annoying special syntax can be found in perl 5's goto, that can't go to a returned subref using "goto sub_that_returns_a_subref();".
> : It shouldn't treat a sub call differently, so that a called sub can in a > : useful manner return a closure, which is then executed several times. > : The same annoying special syntax can be found in perl 5's goto, that > : can't go to a returned subref using "goto sub_that_returns_a_subref();". > Doesn't this work in Perl 5? > goto &{sub_that_returns_a_subref()}; > If not, I'd say it's a bug.
Hm, it does. But it's not something I thought of when I needed it.
But it's one of those cases that have case-specific special syntax, and I think it's best to avoid that.
The same thing goes for all those places where a variable is expected that begins with $, like foreach. You can't easily use an lvalue sub. The workaround is like your goto workaround:
for ${\thatsub()} (1..10) { ... }
Although admittedly, I only encountered this when playing with a non-readonly undef ;) (This is something I can recommend to anyone: redefining true, false and undef leads to very spectacular code, where anything's possible, and defined(undef) can be a true that stringifies as "false".)
On Wed, Apr 20, 2005 at 07:17:14PM +0200, Juerd wrote:
: Juerd skribis 2005-04-20 19:09 (+0200): : > I'm not sure the XX thing will happen, but if it does, it'd be most : > useful if it wouldn't treat a sub call differently. : : I forgot rationale. : : It shouldn't treat a sub call differently, so that a called sub can in a : useful manner return a closure, which is then executed several times. : The same annoying special syntax can be found in perl 5's goto, that : can't go to a returned subref using "goto sub_that_returns_a_subref();".
Doesn't this work in Perl 5?
goto &{sub_that_returns_a_subref()};
If not, I'd say it's a bug.
: Which brings me to the following questions: : : Does goto LABEL still exist in Perl 6? : : Must LABEL be quoted/a normal string?
Hmm, well we do still have bare labels for loop control, so I'd probably still put goto LABEL into the same category. Overloading goto in Perl 5 for stack frame replacement was probably a mistake. These days that should probably be handled with &sub.tailcall(@_) or some such anyway so that we can confuse it with ordinary tailcall optimizations. In fact, that might just be what ordinary tailcall optimization compiles down to.
On Wed, Apr 20, 2005 at 07:17:14PM +0200, Juerd wrote:
: Must LABEL be quoted/a normal string?
Forgot to answer the more general question. Presuming we still have
next LABEL; last LABEL; redo LABEL; goto LABEL;
how do we parse something like this
goto join "", "L", { rand 10 } XX rand 10;
without doing inconsistent autoquoting or confusticating the current subroutine namespace with the label space? I think the answer is that those control keywords always autoquote the next identifier, and if you want to do something run-timeish, you have to say
goto(join "", "L", { rand 10 } XX rand 10);
or, slightly more problematically,
(join "", "L", { rand 10 } XX rand 10).goto;
(slightly more problematic insofar as .goto is presumably not a built-in method on Str, so you're relying on failover to MMD.)
Anyway, with these rules, goto LABEL and friends can just automatically quote the next identifier if there is one, and not worry about it otherwise, just as => only autoquotes its left side if it's an identifier.
Or did we open that up to general names like Foo::bar? I don't recall. Hmm. What would it mean to goto a class?
And if we write
Foo::Bar => 1, Str => 2,
do we care that class names are getting string typed in the pairs' keys, if you can use a string as a class name anywhere? Or maybe we don't care the other direction, insofar as, if the => autoquoter ignores predefined class names and types them as classes, but classes always stringify to their own name anyway, so it doesn't matter. Hmm. That's probably better, since with the first approach we'd have to make sure that Str supports class methods somehow, if only by failover to MMD.
It would be kind of nice if autoquoting policy were similar between => and goto, but maybe that's a foolish consistency. We've never allowed :: in labels before, whereas I can see lots of uses for class names on the left side of pairs.
I think I'm arguing myself out of autoquoting :: names. So in
Foo::Bar => 1, Str => 2,
I think it should autoquote Str only, and then if you really mean the class there instead of the autoquoted string, you should say
::Str => 2,
instead. And now we don't have a problem with consistency. Autoquoted labels are limited to bare identifiers also.
On Wed, Apr 20, 2005 at 02:15:20PM -0500, Patrick R. Michaud wrote:
: On Wed, Apr 20, 2005 at 12:00:22PM -0700, Larry Wall wrote: : > : Although admittedly, I only encountered this when playing with a : > : non-readonly undef ;) (This is something I can recommend to anyone: : > : redefining true, false and undef leads to very spectacular code, where : > : anything's possible, and defined(undef) can be a true that stringifies : > : as "false".) : > : > Perl 6 culture might feebly try to discourage the redefinition of truth. : : Hmm, and here I was thinking that the culture was rapidly evolving : towards "There Is More Than One Way To Define It". :-)
As long as it's still spelled TMTOWTDI. Or I suppose we could always recontextualize the meaning of "is" instead. There is prior art...
On Wed, Apr 20, 2005 at 12:00:22PM -0700, Larry Wall wrote: > : Although admittedly, I only encountered this when playing with a > : non-readonly undef ;) (This is something I can recommend to anyone: > : redefining true, false and undef leads to very spectacular code, where > : anything's possible, and defined(undef) can be a true that stringifies > : as "false".)
> Perl 6 culture might feebly try to discourage the redefinition of truth.
Hmm, and here I was thinking that the culture was rapidly evolving towards "There Is More Than One Way To Define It". :-)
On Wed, Apr 20, 2005 at 03:35:13PM -0400, Aaron Sherman wrote:
: On Wed, 2005-04-20 at 15:15, Patrick R. Michaud wrote: : > On Wed, Apr 20, 2005 at 12:00:22PM -0700, Larry Wall wrote: : : > > Perl 6 culture might feebly try to discourage the redefinition of truth. : > : > Hmm, and here I was thinking that the culture was rapidly evolving : > towards "There Is More Than One Way To Define It". :-) : : I would suggest that it's been more of, : : perl -nle 'push @{$x{uc substr($_,0,1)}}, $_;END{p("TMTOWTDI",\%x)}sub p {my $a=shift;my $h=shift; my $w=shift;$w=[] unless $w;my $letter = substr($a,0,1);$a=substr($a,1);foreach my $word (@{$h->{$letter}}){ if ($a) {p($a,$h,[@$w,$word])} else {print join " ", @$w, $word} }}' /usr/share/dict/words : : But, what do I know? ;-)
Dude, nowadays we're trying to make Perl 6 more Unicode aware, not less; /usr/share/dict/words is so, like, monocultural, and stuff.
On Wed, 2005-04-20 at 15:15, Patrick R. Michaud wrote: > On Wed, Apr 20, 2005 at 12:00:22PM -0700, Larry Wall wrote: > > Perl 6 culture might feebly try to discourage the redefinition of truth.
> Hmm, and here I was thinking that the culture was rapidly evolving > towards "There Is More Than One Way To Define It". :-)
I would suggest that it's been more of,
perl -nle 'push @{$x{uc substr($_,0,1)}}, $_;END{p("TMTOWTDI",\%x)}sub p {my $a=shift;my $h=shift; my $w=shift;$w=[] unless $w;my $letter = substr($a,0,1);$a=substr($a,1);foreach my $word (@{$h->{$letter}}){ if ($a) {p($a,$h,[@$w,$word])} else {print join " ", @$w, $word} }}' /usr/share/dict/words
But, what do I know? ;-)
-- Aaron Sherman <a...@ajs.com> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
On Wed, Apr 20, 2005 at 08:39:43PM +0200, Juerd wrote:
: The same thing goes for all those places where a variable is expected : that begins with $, like foreach. You can't easily use an lvalue sub. : The workaround is like your goto workaround: : : for ${\thatsub()} (1..10) { ... }
Yes, and that's one reason we intentionally broke most of those forced sigil syntaxes for Perl 6. You can say push($foo,$bar) in Perl 6 too.
: Although admittedly, I only encountered this when playing with a : non-readonly undef ;) (This is something I can recommend to anyone: : redefining true, false and undef leads to very spectacular code, where : anything's possible, and defined(undef) can be a true that stringifies : as "false".)
Perl 6 culture might feebly try to discourage the redefinition of truth.
On Wed, Apr 20, 2005 at 09:45:08PM +0200, Juerd wrote:
: Larry Wall skribis 2005-04-20 11:54 (-0700): : > goto(join "", "L", { rand 10 } XX rand 10); : : By the way -- Does this mean the XX operator is official now?
No. I just threw that in to see if anyone was awake.
: And what about X? It'd let you write the same thing without the join: : : goto("L" ~ { rand 10 } X rand 10)
But that doesn't mean I've ruled it out yet either. But it seems like there should be a way to get the same effect with x and xx with some option or context sensetivity. I just haven't thought about enough yet.
On Wed, Apr 20, 2005 at 04:50:38PM -0400, Matt Creenan wrote:
: To expand on this... : : How will you be able to access shared libraries with native code, such as : DLLs on windows? Is there a way to do this proposed for Perl6 yet?
On Wed, 20 Apr 2005 13:00:01 -0400, Matt <m...@weakmind.org> wrote:
> 2. Is anyone working on making a Win32 module for Perl6 yet, or porting > over the p5 one? If not, I may be willing to make one, along with some > help from friends.
> If I do, does anyone have any pointers or suggestions for me when I > begin the adventure? Specifically, how it should be organized, among > other things.
To expand on this...
How will you be able to access shared libraries with native code, such as DLLs on windows? Is there a way to do this proposed for Perl6 yet? If so, is it possible in PUGS?
On Wed, Apr 20, 2005 at 04:50:38PM -0400, Matt Creenan wrote: > To expand on this...
> How will you be able to access shared libraries with native code, such as > DLLs on windows? Is there a way to do this proposed for Perl6 yet? If > so, is it possible in PUGS?
It is possible in Pugs's Haskell backend by using the experimental, unspecced (and will probably be changed) eval_haskell() primitive to natively call Win32 DLLs.
Alternatively, you can write modules using the experimental, unspecced (and will probably be changed) syntax:
> Bringing the topic back to perl6-language, I'd like to inquire > how eval and inlining other languages works. Here's some thoughts: > eval('printf("Hello!")', :language<C>);
Is that comma needed?
> eval(:C('printf("Hello!")'));
Strange use of a pair - feels to me like you can provide alternatives:
eval( C => 'printf("Hello!")', Ruby => 'print "Hello!"', sh => 'echo Hello\!' );
> inline C => '...'; > inline C => =<foo.c>;
Syntactic sugar that was nice for Perl 5, but is probably better to be left alone.
eval(Str $code, +$lang) has my preference, syntax-wise, but that can perhaps only work with Parroty languages, of which I think C isn't one.
Sometimes you want to add a word in between terms for documentation. For this reason, I've always wanted the arguments for index to be the other way around, so I could think "index $needle, (in) $haystack".
It'd be fun to have a different spelling for comma (here I assume that leading comma is ignored and that because of the special new leading keyword, non-slurpy can come after slurpy), for example:
multi eval ($code, "using" ?$lang) { eval($code, :lang($lang)) } eval 'printf("Hello!")' using "C";
multi index ("of" $needle, "in" $haystack, +$offset) { index(...) } my $pos = index of "," in "Hello, world!";
multi join (*@strings, "on" $separator) { ... } my $joined = join @fields on ":";
The same thing can almost be done with pairs, but these words don't make good identifier names.
Can something like this be done without resorting to macros with hard to construct regexes?
On Thu, Apr 21, 2005 at 05:31:05AM +0800, Autrijus Tang wrote:
: Bringing the topic back to perl6-language, I'd like to inquire : how eval and inlining other languages works. Here's some thoughts: : : eval('printf("Hello!")', :language<C>); : eval(:C('printf("Hello!")')); : : inline C => '...'; : inline C => =<foo.c>; : : If there is some consensus on this, I'd like to change Pugs's : existing `eval_perl5()` and `inline` syntax to agree with it.
I think eval($str) is just syntactic sugar for
$?MYGRAMMAR.top($str).compile.run
or some such. We could just leave eval meaning that, and let people define their own shortcuts for other languages. If someone is going to do one eval in a different language, they're often going to a lot of them, so a syntax like:
eval('printf("Hello!")', :language<C>);
is going to be too heavyweight for that anyway, and people will write
sub eval_C ($proggie) { CGrammar.top($proggie).compile.link.run.dump.gdb }
or whatever. :-)
The other part we might want to replace is the .top, since .top is probably going to create a new lexical scope, whereas .statement or some such will presumably execute the new statement in the current scope, so we have some way of writing an interactive eval loop that doesn't throw away declarations.
Juerd writes: > It'd be fun to have a different spelling for comma (here I assume that > leading comma is ignored and that because of the special new leading > keyword, non-slurpy can come after slurpy), for example:
> multi eval ($code, "using" ?$lang) { eval($code, :lang($lang)) } > eval 'printf("Hello!")' using "C";
> multi index ("of" $needle, "in" $haystack, +$offset) { index(...) } > my $pos = index of "," in "Hello, world!";
> multi join (*@strings, "on" $separator) { ... } > my $joined = join @fields on ":";
> The same thing can almost be done with pairs, but these words don't make > good identifier names.
I believe this was an RFC at some point. And this probably can't be done without hard-to-construct regexes, but we'll leave that construction to the module author so it only need be done once. I don't actually expect that it would be *that* hard to do.
|
