After watching the first of (hopefully many) starry night movies, I really wished I could've teleported to why the lucky stiff's talk and immediately back afterwards. It also makes me wonder whether I should start producing Pugs-related web comics to spice up this journal. ;-)
brentdax's WWW::Kontent truly rocks. I feel so very happy seeing this:
# from WWW::Kontent::Store::NarrowDBI
# (slightly reformatted)
use perl5:DBI;
sub handles($p) {
my $dbh = DBI.connect(
$p, $p, $p
) || WWW::Kontent::error(
"Can't open database", :code(502)
);
$dbh=0;
...
}
The WWW::Kontent system is driven by a kontent-config.yaml file. It only takes one line to read it in:
%conf=eval slurp($conffile), :lang;
My feeling must resemble that of Stevan's - people are actually using the features I hacked in months ago! Props to Why's libsyck for the YAML part, and clkao's perl5 glue for the use perl5:DBI part.
On the subject of Perl5 interop, Heffalump from #haskell produced antibuddha, a much more robust Perl5 binding for GHC. Sadly, it currently requires a perl built with multiplicity. Once that restriction is lifted, I'll definitely consider switching. The curious name "antibuddha" is explained in its README:
Antibuddha is a Perl 5 binding for Haskell. It is so named because Buddha, a Haskell debugger, is a tool for removing bugs from your program, and it is expected that this binding will be an excellent way of introducing bugs to your program.
Although embedding perl5 is nice, it certainly means doom to any GC for non-object usage, as the symbol table is shared bothways, and neither side can know for sure the other side had not created a dangling reference. Additionally, with both sides offering tie, the four-fold boxed containers can really hurt performance. So eventually we will want a single runloop, instead of two runtimes glued together.
Obviously, there are three options:
According to andyr and alasdair, Nicholas thinks we can't easily compile Perl 6 code to Perl 5, as Perl 5's VM not modern enough -- both threads and Unicode were bolted on to Perl 5 almost as an after thought. So I talked to Nicholas on IRC about this:
<autrijus> Nicholas: hm, threads and unicode doesn't really stop compiling p6 to p5 :) after all, both works, just occasionally slow and leaky. in any case I'll still pursue that approach :)
<Nicholas> autrijus: :-) Word of my talk spread?
<autrijus> right :) the point is more that you can solve any vm mismatch via a layer of indirect emulation... but that's not the recipe for long term evolution or efficiency. still, it's often acceptable. that's why "perl6 cannot run on jvm/clr because they are not dynamic enough" is kind of bogus.
<Nicholas> yes, quite -- IronPython.
Stevan posted a 10k ft view for the perl5 version of Perl6::MetaModel. However, its use of nominal class types worries me, because it would not handle cases like this:
class Foo { ... };
my $x = Foo.new;
my $y = do { my class Foo { ... }; Foo.new };
We can see that $x and $y should belong to different classes, but a purely nominal system (such as Perl5's) cannot handle that.
After some discussion on #perl6, it looks that the Javascript edition of metamodel is already using a hard reference to the class in an object. Hence both the Perl5 and Haskell editions will align to that layout.
Stevan mentioned Perl 5 GC problems with the reference approach and hash-based objects. It looks like Damian's new Class::Std module may fix that problem. Std is the new Acme! (Or the new Simple, or the new More, or the new All...)
fglock offered to help getting the mysterious Lazy list going, based on his experience from writing Span.pm in Perl 6. Since my current priority is getting the OO and PIL2 going, it's very nice to see other lambdacamels actively addressing other shortcomings. :-)
Oh, and I also started learning OCaml. Its large arsenal of much-too-powerful tools certainly reminds me of Perl's TIMTOWTDI mentality. However, that also makes the code slightly harder to reason about, and more dependent on cultural idioms. One wonders if Perl6 can be made as fast as OCaml (i.e. often surpassing C++), given sufficient compile-time annotations, inferences, and a native code generator...