Re: a practical question
Richard Nabil Hainsworth [EMAIL PROTECTED] writes: But I want to start doing real things. Which for me requires gui toolkits. I have used Tk with perl5 and I am looking at WxWidgets. WxWidgets (and the more commercial Qt) exist as C++ classes, although WxPerl is a set of wrappers around WxWidgets for perl5. So how to write an application in perl6 that uses (for the sake of illustration) WxWidgets? I don't think there's a big knowledge base beside what the current Pugs hackers know. But if I were you, I would start a small step before, especially with experimenting with the use perl5:Some::Lib;-features and generally the current ways of intermixing Perl5 and Perl6. I would love to see a Pugs Use Perl5 - First Blood article somewhere, made from users for users. It's on my personal TODO list too and I will help you with experimenting, but I'm currently, erm, well, occupied with @otherstuff (the same excuse as every year). If you start experimenting and writing down something, expect me to follow you. If we know and document something in an easy understandable form, wxWidgets or any other lib can be the next step. GreetinX Steffen -- Steffen Schwigon [EMAIL PROTECTED] Dresden Perl Mongers http://dresden-pm.org/
[perl #40225] Making Makefiles...
# New Ticket Created by Will Coleda
# Please include the string: [perl #40225]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40225
I'd like to add a few features to the genfile() code when generating
makefiles...
1) allow inclusion of other makefile.in files: this will allow us to
break up root.in into more maintainable chunks.
2) create a directive that expands to a list of files that match a
certain filter. something like:
@FILES path to dir from root glob to match files@
so, in tcl's makefile, I might have something like:
@FILES languages/tcl runtime/builtin/*.pir
which would use the full path (languages/tcl/runtime/builtin/*.pir)
to actually find the files from parrot root, but then generate the
list in the makefile relative to the tcl directory (where the
makefile is going to be used.)
I'm posting to see if anyone has any syntax suggestions or previous
art I should be looking at first. I'm tempted to leave @@ to mean
items from config only and perhaps have something else for these
more meta directives. (back to ${}? something else?)
Thoughts?
--
Will Coke Coleda
[EMAIL PROTECTED]
Re: [perl #40225] Making Makefiles...
This was not intended to be a bug report. I blame my mailer. =-) Feedback still welcome, might as well leave it as a ticket now.
Re: [perl #40225] Making Makefiles...
Am Mittwoch, 23. August 2006 16:38 schrieb Will Coleda: I'd like to add a few features to the genfile() code when generating makefiles... A general note: instead of inventing more and more custom make extensions, which all needs post-processing, I'm proposing to use a few needed gmake extensions. If gmake is not available, we would process the files like now and resolve custom syntax by some (probably) perl equivalents. If gmake is available, no processing is needed at all (given that some config include file was generated during Configure.pl time). Instead of creating more and more config-time stuff, which needs more and more re-configs, we should put such operations just where they belong: into the Makefile. We might even be able run 'make -j8' eventually, when all the config dependencies are resolved. 1) allow inclusion of other makefile.in files: this will allow us to break up root.in into more maintainable chunks. include other_makefile 2) create a directive that expands to a list of files that match a certain filter. something like: @FILES path to dir from root glob to match files@ The necessity of having root based file paths ist just coming from the separation of make and config, where the former is running in the targetdir (e.g. languages/tcl but the latter is running in parrot root). We should first get rid of that anomaly, then we have: FILES = $(wildcard runtime/builtins/*.pir) Proposal: 1) all dirs (which need some make support) contain GNUmakefile - generated parts are .included - if gmake is available, this file is the prefered makefile and will be run - if arch doesn't have gmake GNUmakefile is processed to create Makefile 2) we define a few usable extensions - include file - $(wildcard ..) - ifeq / else / endif [1] - a few more 3) the generation of makefiles should be split from Configure.pl into a separated process, which is invoked by Configure.pl as a last step, but should also be runnable standalone and for one language. leo [1] we use that already with this syntax: #CONDITIONED_LINE(SVN_ENTRIES):[EMAIL PROTECTED]@ #INVERSE_CONDITIONED_LINE(SVN_ENTRIES):SVN_ENTRIES=
Re: [perl #40225] Making Makefiles...
On Aug 23, 2006, at 1:46 PM, Leopold Toetsch via RT wrote: Am Mittwoch, 23. August 2006 16:38 schrieb Will Coleda: I'd like to add a few features to the genfile() code when generating makefiles... A general note: instead of inventing more and more custom make extensions, which all needs post-processing, I'm proposing to use a few needed gmake extensions. If gmake is not available, we would process the files like now and resolve custom syntax by some (probably) perl equivalents. If you mean inventing more syntax, I fully agree. I'm currently working on stealing the gmake syntax you've pointed out on IRC. Thanks. If there are any current transformations that we're doing that could be done in gmake, open a ticket and I'll change the syntax we use. But we still need these extensions, since gmake is *NOT* always going to be available, to the best of my knowledge. Some kind of processing of the makefiles needs to occcur - even if we don't allow things like $(wildcard), we still need to process @FOO@ expansions. If gmake is available, no processing is needed at all (given that some config include file was generated during Configure.pl time). My only concern about that (after dealing with the relative paths issue you address below) is that we might end up with different behavior from gmake vs. our own handrolled version - obviously due to separate code paths, but also potentially due to subtle changes due to when the code is being executed. (at build time vs. at config time). This might also be impacted by the very old get rid of make ticket - but in that case, we can just always fallback to our handrolled version. Instead of creating more and more config-time stuff, which needs more and more re-configs, we should put such operations just where they belong: into the Makefile. We might even be able run 'make -j8' eventually, when all the config dependencies are resolved. This is a red herring. Make dependencies need to be improved for this to happen. Whether we use build time vs. config-time constructs doesn't really matter. I think the syntax I'm adding here (which is now based on gmake!) should actually make it *easier* to document the dependencies, since we'll now be able to do it more declaratively, and cross-platform to boot. 1) allow inclusion of other makefile.in files: this will allow us to break up root.in into more maintainable chunks. include other_makefile This is fine for static sections, as we discussed on IRC. I think there's still a maintenance win to having multiple .in's that can get folded into a single constructed Makefile (as opposed to having multiple .in's transformed into multiple makefiles which then include each other at make time; and as opposed to a single monolithic .in) 2) create a directive that expands to a list of files that match a certain filter. something like: @FILES path to dir from root glob to match files@ The necessity of having root based file paths ist just coming from the separation of make and config, where the former is running in the targetdir (e.g. languages/tcl but the latter is running in parrot root). We should first get rid of that anomaly, then we have: FILES = $(wildcard runtime/builtins/*.pir) Proposal: 1) all dirs (which need some make support) contain GNUmakefile - generated parts are .included - if gmake is available, this file is the prefered makefile and will be run - if arch doesn't have gmake GNUmakefile is processed to create Makefile 2) we define a few usable extensions - include file - $(wildcard ..) - ifeq / else / endif [1] - a few more 3) the generation of makefiles should be split from Configure.pl into a separated process, which is invoked by Configure.pl as a last step, but should also be runnable standalone and for one language. #3 is the last item blocking http://rt.perl.org/rt3/Ticket/ Display.html?id=31633 from getting resolved, I think. This is not a bad proposal - I'd extract it from this ticket and have it considered on its own merits. leo [1] we use that already with this syntax: #CONDITIONED_LINE(SVN_ENTRIES):[EMAIL PROTECTED]@ #INVERSE_CONDITIONED_LINE(SVN_ENTRIES):SVN_ENTRIES= To sum up: for now, I'm working on being able to support: $(addprefix runtime/builtin,$(notdir $(wildcard languages/tcl/ runtime/builtin/*.pir))) Which looks like gmake, but will be expanded at config time: once we fixup where/when language makefiles are generated, this will simplify to: $(wildcard runtime/builtin/*.pir) And going forward, we might disable the config-time expansion of this depending on what make we're using, so that gmake does it instead of Configure. (but this way it should work out of the gate on nmake, and whatever else folks are building with.) Regards. -- Will Coke Coleda [EMAIL PROTECTED]
Re: LLVM and HLVM
On 8/22/06, John Siracusa [EMAIL PROTECTED] wrote: Has anyone looked at LLVM lately? Yes, actually, I was looking at it just the other day. I couldn't get it to build on x86-64, but I talked to some of the developers over in their IRC channel, and they told me that this would be forthcoming (in two weeks or so), so I'm going to hold off for a while and then try it then. On the other hand, Parrot built quite nicely on x86-64, although I think I like the 32-bit build (which also built just fine, albeit without ICU) better due to the excellent JIT support. http://llvm.org/ It seems to be making a lot of progress lately with the support of Apple (which is using LLVM for its own purposes in Mac OS X). Is there anything there Parrot can steal? Would it make sense for Parrot to target LLVM bytecode and let LLVM do further optimization and native code generation? I don't know that there'd be much benefit in directly targeting LLVM, but I do know that it'd be a lot easier to just try using one of their gcc front-ends to compile parrot. Maybe I'll try that out in a few weeks, provided that the x86-64 support is there. There's also the predictably named HLVM: http://hlvm.org/ Now that looks interesting, if totally pre-alpha; thanks for mentioning it! which looks vaguely Parrot-ish. Check out the comparison chart: http://hlvm.org/docs/FAQ.html Anyway, I'm just thinking out loud, here. Sorry if it's all old news to the Parrot dev gurus. It probably is, and I'm no guru, but as projects change and develop, I don't think it hurts to compare and re-evaluate now and then. :) -John -- Peter
Same-named arguments
Hi,
I'm just starting with Perl 6. I was reading through Perl 6 and Parrot
Essentials (finally arrived yesterday from Amazon; very happy) and I was
wondering what would happen if you had a parameter list that included
variables of a different type but the same name (ie, $foo, @foo). I wrote a
little test script and ran it through pugs. Here's what I got:
Script:
use v6;
sub mysub($foo, @foo, %foo) {
say Starting mysub;
say Printing scalar;
say $foo;
say Printing array;
say @foo;
say Printing hash;
say %foo;
say Leaving mysub\n;
}
my $foo = 'foo';
my @foo = qw|foo bar|;
my %foo = ( foo = 'bar', foo2 = 'bar2' );
mysub($foo, @foo, %foo);
mysub(:foo($foo), :foo(@foo), :foo(%foo));
Output:
Starting mysub
Printing scalar
foo
Printing array
foobar
Printing hash
foo barfoo2 bar2
Leaving mysub
Starting mysub
Printing scalar
foo
Printing array
Printing hash
Leaving mysub
Just wondering if the language is meant to work that way, or if it's a pugs
feature.
Thanks,
Michael
Re: Same-named arguments
Michael Snoyman skribis 2006-08-23 12:10 (-0700):
sub mysub($foo, @foo, %foo) {
I hope this is a compile time failure. If not, I'd expect a warning, at
least.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Same-named arguments
Juerd (), Michael Snoyman ():
sub mysub($foo, @foo, %foo) {
I hope this is a compile time failure. If not, I'd expect a warning, at
least.
Why? It looks reasonable IMHO.
// Carl
Re: Same-named arguments
Carl Mäsak skribis 2006-08-23 21:54 (+0200):
Juerd (), Michael Snoyman ():
sub mysub($foo, @foo, %foo) {
I hope this is a compile time failure. If not, I'd expect a warning, at
least.
Why? It looks reasonable IMHO.
Because arguments are passed without sigil, and here you'd be forcing
positional arguments. I think that's bad.
sub do_something ($foo) { ... }
do_something [ 1, 2 ];
do_something foo = [ 1, 2 ];
do_something :foo([ 1, 2 ]);
sub do_something (@foo) { ... }
do_something [ 3, 4 ];
do_something foo = [ 3, 4 ];
do_something :foo([ 3, 4 ]);
sub do_something ($foo, @foo) { ... }
do_something [ 1, 2 ], [ 3, 4 ];
# But how do you pass named arguments now?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: LLVM and HLVM
On 8/23/06, Aaron Sherman [EMAIL PROTECTED] wrote: On 8/23/06, peter baylies [EMAIL PROTECTED] wrote: On 8/22/06, John Siracusa [EMAIL PROTECTED] wrote: Has anyone looked at LLVM lately? [...] On the other hand, Parrot built quite nicely on x86-64, although I think I like the 32-bit build (which also built just fine, albeit without ICU) better due to the excellent JIT support. Not sure if the list will let this through, since I'm subscribed under another account, but here's the problem with that: llvm is a very light layer, but it's yet another layer. To put it between parrot and hardware would mean that parrot is JITing to LLVM byte-code, which is JITing to machine code. Not really ideal. That's a good point--at least on platforms where JIT is already supported for Parrot, it'd probably be desirable to bypass or not use LLVM for that. However, it shouldn't matter to me at all when I do try building Parrot on top of LLVM on x86-64. :) -- Aaron Sherman Senior Systems Engineer and Toolsmith [EMAIL PROTECTED] or [EMAIL PROTECTED]
Re: LLVM and HLVM
On 8/23/06, peter baylies [EMAIL PROTECTED] wrote: On 8/22/06, John Siracusa [EMAIL PROTECTED] wrote: Has anyone looked at LLVM lately? [...] On the other hand, Parrot built quite nicely on x86-64, although I think I like the 32-bit build (which also built just fine, albeit without ICU) better due to the excellent JIT support. Not sure if the list will let this through, since I'm subscribed under another account, but here's the problem with that: llvm is a very light layer, but it's yet another layer. To put it between parrot and hardware would mean that parrot is JITing to LLVM byte-code, which is JITing to machine code. Not really ideal. -- Aaron Sherman Senior Systems Engineer and Toolsmith [EMAIL PROTECTED] or [EMAIL PROTECTED]
Re: [perl #40225] Making Makefiles...
On Wed, Aug 23, 2006 at 02:24:45PM -0400, Will Coleda wrote: To sum up: for now, I'm working on being able to support: $(addprefix runtime/builtin,$(notdir $(wildcard languages/tcl/ runtime/builtin/*.pir))) Which looks like gmake, but will be expanded at config time: once we fixup where/when language makefiles are generated, this will simplify to: $(wildcard runtime/builtin/*.pir) I think it's a mistake to use a make-like syntax. That's just going to lead to maintenance confusion down the road. Someone, someday is going to change it thinking that's it's just GNU make syntax. Why don't you just embed blocks of Perl code instead of inventing a new syntax? -J -- pgpDHqnqy4gPJ.pgp Description: PGP signature
Re: [perl #40225] Making Makefiles...
On Aug 23, 2006, at 4:10 PM, Joshua Hoblitt wrote: On Wed, Aug 23, 2006 at 02:24:45PM -0400, Will Coleda wrote: To sum up: for now, I'm working on being able to support: $(addprefix runtime/builtin,$(notdir $(wildcard languages/tcl/ runtime/builtin/*.pir))) Which looks like gmake, but will be expanded at config time: once we fixup where/when language makefiles are generated, this will simplify to: $(wildcard runtime/builtin/*.pir) I think it's a mistake to use a make-like syntax. That's just going to lead to maintenance confusion down the road. Someone, someday is going to change it thinking that's it's just GNU make syntax. I agree, that could be an issue, but we can easily have this syntax generate an exception if an unexpected keyword is generated. I'll see if I can add that to my work in progress. This particular tradeoff of maintenance confusion on makefiles is a step in the right direction, IMO. Why don't you just embed blocks of Perl code instead of inventing a new syntax? The whole point of using the gmake syntax is that it is the opposite of inventing a new syntax. It is reusing the portions we need from an existing syntax. As to just using perl: that makes it more complicated for the people who have to maintain the rules, by requiring more code to do the same thing, and then duplicating that code across N uses in M makefiles. That said, I don't particularly care about the actual syntax as long as I can declare these sorts of things with a minimal fuss. But in place of a decision from Chip, I'll go with this for now. Regards. -- Will Coke Coleda [EMAIL PROTECTED]
Re: LLVM and HLVM
On 8/23/06 4:09 PM, Aaron Sherman wrote: here's the problem with that: llvm is a very light layer, but it's yet another layer. To put it between parrot and hardware would mean that parrot is JITing to LLVM byte-code, which is JITing to machine code. Not really ideal. ...unless LLVM does a much better job of native code generation than the existing Parrot code, that is. Optimization seems to be LLVM's thing. -John
pugs: rw block parameters
Sorry if this is a known question, but I didn't see it mentioned in the
recent archive or FAQ.
for ($a, $b) { $_ = ... }
gives me a Can't modify constant item: VRef Scalar. Making it
explicitly rw doesn't help:
for ($a, $b) - $x is rw { $x = ... }
Is this a haven't gotten around to rw parameters in blocks yet or a
regression?
--
Mark J. Reed [EMAIL PROTECTED]
Ponie has been put out to pasture
Over the past several years, one key aspect of the migration plan to Perl 6 has been the Ponie project, a fusion of the Perl 5 runtime with Parrot. Sponsored by Fotango, Artur Bergman and Nicholas Clark did a heroic job cleaning up Perl's internals to make it possible to replace some components of Perl 5 with Parrot, one piece at a time, while still keeping the core of the Perl 5 runtime intact with 100% bug-for-bug compatibility. Along the way, Nicholas ported several significant Perl core improvements from Ponie back to the Perl 5.9 tree. Ponie never really became a community project. All significant work was done as part of Fotango's sponsorship. When it had good momentum and sponsored developers, it needed a number of Parrot features that weren't yet available. At this point, Ponie has not been in active development for almost half a year and it's my unhappy duty to declare the project dead. Norman Nunley is currently working to do a final extraction of unharvested improvements from the Ponie code before we put it out to pasture. Lots of good came out of Ponie, just not the good things we expected. A number of very talented hackers are currently exploring multiple strategies to enable most Perl 5 code to run seamlessly along side Perl 6 in Parrot. Folks have already demonstrated a proof-of-concept Parrot VM embedded in the Perl 5 runtime. Work is underway on a Perl 5 to Perl 6 translator and the existing Perl 6 compiler on Parrot is the proof of concept for a similar implementation of a regularized Perl 5. At this point, it wouldn't be reasonable to bless any one right way forward but each of these techniques (and possibly others) could play a part in whatever 5 on 6 scheme we end up with. No matter what happens, we're committed to making your Perl 5 code play well with new Perl 6 code. - Jesse Perl 6 Project Manager PGP.sig Description: This is a digitally signed message part
Ponie has been put out to pasture
Over the past several years, one key aspect of the migration plan to Perl 6 has been the Ponie project, a fusion of the Perl 5 runtime with Parrot. Sponsored by Fotango, Artur Bergman and Nicholas Clark did a heroic job cleaning up Perl's internals to make it possible to replace some components of Perl 5 with Parrot, one piece at a time, while still keeping the core of the Perl 5 runtime intact with 100% bug-for-bug compatibility. Along the way, Nicholas ported several significant Perl core improvements from Ponie back to the Perl 5.9 tree. Ponie never really became a community project. All significant work was done as part of Fotango's sponsorship. When it had good momentum and sponsored developers, it needed a number of Parrot features that weren't yet available. At this point, Ponie has not been in active development for almost half a year and it's my unhappy duty to declare the project dead. Norman Nunley is currently working to do a final extraction of unharvested improvements from the Ponie code before we put it out to pasture. Lots of good came out of Ponie, just not the good things we expected. A number of very talented hackers are currently exploring multiple strategies to enable most Perl 5 code to run seamlessly along side Perl 6 in Parrot. Folks have already demonstrated a proof-of-concept Parrot VM embedded in the Perl 5 runtime. Work is underway on a Perl 5 to Perl 6 translator and the existing Perl 6 compiler on Parrot is the proof of concept for a similar implementation of a regularized Perl 5. At this point, it wouldn't be reasonable to bless any one right way forward but each of these techniques (and possibly others) could play a part in whatever 5 on 6 scheme we end up with. No matter what happens, we're committed to making your Perl 5 code play well with new Perl 6 code. - Jesse Perl 6 Project Manager PGP.sig Description: This is a digitally signed message part
Pair of lists = list of pairs?
Suppose I have two arrays @k and @v and I want to declare and initialize a hash %h such that %h.keys eqv @k and %h.values eqv @v. I could use a direct translation of the P5 idiom: my %h; [EMAIL PROTECTED] = @v; But is there an easy way in Perl6 to do it all in one go? Should this work? my %h = @k [=] @v; -- Mark J. Reed [EMAIL PROTECTED]
Re: Pair of lists = list of pairs?
On Wed, Aug 23, 2006 at 05:43:48PM -0400, Mark J. Reed wrote: But is there an easy way in Perl6 to do it all in one go? Should this work? my %h = @k [=] @v; You want a zip: my %h = @k ¥ @v; my %h = @k Y @v; # ASCII fallback my %h = zip(@k, @v); # or maybe zip(@k; @v) this week? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Pair of lists = list of pairs?
On Wed, Aug 23, 2006 at 05:43:48PM -0400, Mark J. Reed wrote: : Suppose I have two arrays @k and @v and I want to declare and initialize a : hash %h such that %h.keys eqv @k and %h.values eqv @v. : : I could use a direct translation of the P5 idiom: : : my %h; : [EMAIL PROTECTED] = @v; : : But is there an easy way in Perl6 to do it all in one go? Should this work? : : my %h = @k [=] @v; Reduce operators only turn infix into list operators. What you really want here is a hyper-fatarrow: my %h = @k »=« @v; Larry
Re: Pair of lists = list of pairs?
Mark J. Reed skribis 2006-08-23 17:43 (-0400): But is there an easy way in Perl6 to do it all in one go? Should this work? my %h = @k [=] @v; Hyper is not [], but . And = works perfectly in Pugs, and does exactly what you describe. [] is for reduction, and is prefix: [+] 1,2,3 Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Pair of lists = list of pairs?
: my %h; : [EMAIL PROTECTED] = @v; : : But is there an easy way in Perl6 to do it all in one go? Should this work? : : my %h = @k [=] @v; Reduce operators only turn infix into list operators. What you really want here is a hyper-fatarrow: my %h = @k »=« @v; Gaal pointed out using zip. What would be the difference then between a hyper-fatarrow and zip in this case? Michael
Re: Pair of lists = list of pairs?
On Thu, Aug 24, 2006 at 12:51:04AM +0300, Gaal Yahas wrote: : On Wed, Aug 23, 2006 at 05:43:48PM -0400, Mark J. Reed wrote: : But is there an easy way in Perl6 to do it all in one go? Should this work? : : my %h = @k [=] @v; : : You want a zip: : : my %h = @k ¥ @v; : my %h = @k Y @v; # ASCII fallback That would have worked back when zip merely interleaved, but now it makes sublists, and so we would have to teach hash assignment to transform [$k, $v] into ($k,$v) or $k=$v. Might not be a bad idea. : my %h = zip(@k, @v); # or maybe zip(@k; @v) this week? It would be zip(@k;@v). zip(@k,@v) would only have one dimension, so would just concatenate the two lists and put each element into its own sublist. Alternately, for the old zip semantics we have each(@k;@v), which makes a list with interleaved keys and values. It's just there's no operator like ¥ for it (yet). But I'd still probably use a hyper-fatarrow for this case rather than relying on interleaving. Larry
clarifying the spec for 'ref'
I noticed in pugs, 'ref' does not return 'HASH' and 'ARRAY' as Perl5
does, but returns values including 'Hash', 'Array' and 'Array::Const'.
I don't find meaningful mentions of 'HASH' and 'ARRAY' by grep'ing
docs/Perl6 (or even ref!), so I wanted to check in here about the
meaningfulness of this change.
Personally, I dislike the change from HASH to 'Hash' because it seems to
be change without a significant benefit. It's annoyingly different.
The ARRAY case is worse, because it seems I now need to write this:
if ref $a eq any('Array','Array::Const') {
If you are interested, here's code which illustrates cases when
'Array' is returned, versus 'Array::Const'
my $a = [a];
my $b = \@('b');
say ref $a;
say ref $b;
I'd like for 'HASH' and 'ARRAY' to keep working, or for the Perl6 docs
to justify the change.
Mark
Re: Pair of lists = list of pairs?
Reduce operators only turn infix into list operators. What you really want here is a hyper-fatarrow: my %h = @k »=« @v; Ah, right. Silly me. I got hyper and reduce confused. Thanks! Gaal pointed out using zip. What would be the difference then between a hyper-fatarrow and zip in this case? Effectively none. But I think the hyper-notation is clearer here. Both ¥ and = make pairs, but at least to me, = conveys more explicitly that it's not just any old pair but specifically a key/value pair. (Even though = also creates Pairs of the any old kind.) -- Mark J. Reed [EMAIL PROTECTED]
Re: Pair of lists = list of pairs?
On Wed, Aug 23, 2006 at 03:19:22PM -0700, Larry Wall wrote: : But I'd still probably use a hyper-fatarrow for this case rather than : relying on interleaving. Another reason for preferring hyper is that it makes promises about parallelizability, whereas the zip/each solutions would tend to assume the input streams must be processed in order, albeit lazily. (Probably doesn't make much difference until someone actually attempts to vectorize Perl though, and even when that happens, it's not clear what the exact sequence of events would be if you feed a lazy pipe to a hyper...) Larry
My first functional perl6 program
To get my feet wet, I thought I'd translate my silly little cryptogram
helper. It turned out like this:
#!/usr/local/bin/pugs
#==
# Braindead cryptogram assistant with hard-coded key.
#--
my %key =
(
a = 'f', b = 'o', e = 'n', f = 'w', g = 'd', h = 'a', j = 'm',
k = 'i', l = 's', m = 'l', n = 'c', o = 'g', q = 'r', r = 'h',
s = 'k', t = 'u', u = 'p', v = 't', w = 'j', x = 'e', y = 'v',
);
# Start by mapping all letters to question marks so the as-yet-undeciphered
# letters will stand out. Then add the letters from the key, making sure to
# get both lowercase and uppercase forms
my %trans = ('a'..'z') »=« ('?' xx 26);
%trans{%key.keys.map({.lc,.uc})} = %key.values.map({.lc,.uc});
for = { say(.trans(%trans)) }
Surprisingly terse. I wonder if there a more elegant way to do that
hash assignment?
It was especially convenient that String#trans accepts a Hash for the
mapping; my Perl5 and Ruby versions also store the key in a hash, but
then use keys+join and values+join to get tr-friendly strings out of
it. This was much more natural.
(Speaking of which, pugs apparently doesn't have Ctr as a global
function, only the .trans method)
It does sadden me somewhat that the say() requires the parens (or an
explicit $_ etc). But I'll live. :)
(The key above is for today's Order of the Stick, btw.)
--
Mark J. Reed [EMAIL PROTECTED]
Re: My first functional perl6 program
On 8/23/06, Mark J. Reed [EMAIL PROTECTED] wrote:
my %trans = ('a'..'z') »=« ('?' xx 26);
Also, correct me if I'm wrong, but I should theoretically be able to
use xx * there, thus creating a lazily-evaluated infinitely-long list
of question marks?
--
Mark J. Reed [EMAIL PROTECTED]
Re: clarifying the spec for 'ref'
On Wed, Aug 23, 2006 at 06:20:55PM -0400, Mark Stosberg wrote:
: I noticed in pugs, 'ref' does not return 'HASH' and 'ARRAY' as Perl5
: does, but returns values including 'Hash', 'Array' and 'Array::Const'.
Well, first of all, ref is going away entirely, since there's no such
thing as a reference in Perl 6 (or everything is a reference, looking
at it the other way), so in a boolean context it would be trivially
true (or false) for everything. Its use to return the type of the
referent is then completely misnamed.
And even for that use, returning a string is wrong. It should return
the type itself, and that should stringify to the type name if you use
it in string context. Which mostly you don't want to.
Anyway, .ref is likely to end up with a name like .what or .WHAT
instead. (And .SKID is probably changing to .WHO or .WHICH at the
same time. And maybe .META gets renamed .HOW while we're at it.
Maybe .WHERE gives you the memory address, or the url, or something.
As for .WHY, well, .WHYNOT? :-)
: I don't find meaningful mentions of 'HASH' and 'ARRAY' by grep'ing
: docs/Perl6 (or even ref!), so I wanted to check in here about the
: meaningfulness of this change.
It's meaningful. There is no longer a distinction between fake types
naming internal forms and real types. So we renamed the formerly fake
types to look more like real types, because they are.
: Personally, I dislike the change from HASH to 'Hash' because it seems to
: be change without a significant benefit. It's annoyingly different.
Oh, if that's your smallest annoyance, please count yourself lucky. :)
: The ARRAY case is worse, because it seems I now need to write this:
:
: if ref $a eq any('Array','Array::Const') {
You're in P5-think here in assuming that type names are merely strings.
In P6-think you just want to treat the type as a first class object. In
particular, smart match already does what you want and handles inheritance
for you. Instead of saying
if ref $a eq 'ARRAY' {
you really want:
if $a ~~ Array {
and that also matches Array::Const, assuming it's derived from Array.
: If you are interested, here's code which illustrates cases when
: 'Array' is returned, versus 'Array::Const'
:
: my $a = [a];
: my $b = \@('b');
:
: say ref $a;
: say ref $b;
:
: I'd like for 'HASH' and 'ARRAY' to keep working, or for the Perl6 docs
: to justify the change.
The justifications are mostly off in the Apocalypses. Use of
types in smartmatching is mostly discussed in A04, for instance.
But the synopses are primarily intended contain just the changes,
not the rationale for the changes.
Larry
Re: My first functional perl6 program
On Wed, Aug 23, 2006 at 06:49:06PM -0400, Mark J. Reed wrote:
: On 8/23/06, Mark J. Reed [EMAIL PROTECTED] wrote:
: my %trans = ('a'..'z') »=« ('?' xx 26);
:
: Also, correct me if I'm wrong, but I should theoretically be able to
: use xx * there, thus creating a lazily-evaluated infinitely-long list
: of question marks?
Yes, that should work eventually, given that hypers are supposed to stop
after the longest *finite* sequence. In theory you could even say
my %trans = ('a'..*) »=« ('?' xx *);
but we haven't tried to define what the semantics of a lazy hash would be...
Larry
Re: My first functional perl6 program
On Wed, Aug 23, 2006 at 06:39:52PM -0400, Mark J. Reed wrote: : It does sadden me somewhat that the say() requires the parens (or an : explicit $_ etc). But I'll live. :) Strange, this works for me: $_ = foo; say .uc FOO Seems to work with .uc() as well. Larry
Re: My first functional perl6 program
On 8/23/06, Larry Wall [EMAIL PROTECTED] wrote: Strange, this works for me: $_ = foo; say .uc FOO Maybe that was fixed in 6.2.12, then. I'm still running 6.2.11, and at least on Cygwin, I get this: $ pugs -e '$_ = foo; say .uc' $ No output. And if I try .trans: $ pugs -e '$_ = foo; say .trans(o=0)' *** No compatible subrountine found: trans at -e line 1, column 13-31 But in any clase I'm glad it's merely an implementation bug rather than specced behavior. -- Mark J. Reed [EMAIL PROTECTED]
Re: LLVM and HLVM
John Siracusa wrote: On 8/23/06 4:09 PM, Aaron Sherman wrote: here's the problem with that: llvm is a very light layer, but it's yet another layer. To put it between parrot and hardware would mean that parrot is JITing to LLVM byte-code, which is JITing to machine code. Not really ideal. ...unless LLVM does a much better job of native code generation than the existing Parrot code, that is. Optimization seems to be LLVM's thing. Keep in mind that you're not talking about some HLL generating LLVM bytecode. You're talking about Parrot reading in Parrot byte code, JITing to LLVM and then going through that dance again. The amount of lossage in those layers of translation simply cannot be worth whatever the difference is between LLVM optimization and Parrot's JIT, since Parrot will already have generated code that makes it MORE difficult to optimize. I'll buy it if I see numbers, but I'm highly skeptical.
Re: clarifying the spec for 'ref'
On 8/23/06, Larry Wall [EMAIL PROTECTED] wrote:
you really want:
if $a ~~ Array {
and that also matches Array::Const, assuming it's derived from Array.
Well, actually Array would be a subtype of Array::Const, not t'other
way round. That is a little bit disconcerting, because when you say
$a ~~ Array, you probably want the const ones too. I'm not in a state
of mind to resolve the issue at the moment, but I'll happily point it
out. :-)
Luke
