February 08, 2010
Help! I'm getting the error "invoke() not implemented in class 'Undef'" in my large application. What did I do wrong?
You've mistyped a class name which sits inside a namespace.
How am I supposed to figure that out?
I didn't say it was a particularly good error message.
It's like this: if you mistype a class name which is not in a namespace, you'll get an informative error message:
$ perl6 -e 'A.foo'
Could not find non-existent sub A
in Main (file src/gen_setting.pm, line 324)
However, if you mistype a class name which is in a namespace, you will get an uninformative error message:
$ perl6 -e 'A::B.foo'
invoke() not implemented in class 'Undef'
in Main (file <unknown>, line <unknown>)
So there's your error message. Linking it to the actual cause is something which you'll learn by experience.
So in that case, I don't get the name of the class which was mistyped in my program?
Correct.
And I don't get the line number of my typo?
Indeed not.
Or the file?
Right. You'll get no information about the location of the typo.
Is that intentional?
Well, no. As you see from the error message above, the information is meant to be printed, but it comes out as (file <unknown>, line <unknown>) instead.
Why?
Rakudo is built on top of Parrot. Usually, Rakudo generates its own error messages, but in some cases, Parrot will also generate an error. The error invoke() not implemented in class 'Undef' is such a case. When a Parrot-internal error like this one occurs, Rakudo will not be able to extract the annotation information required to provide a sensible line number and file.
I... I see.
Yeah. Sorry about that.
Are you able to pick up the irony in the fact that when I use namespaces to help mitigate the complexity of my project, I end up with an error message that in fact makes it harder for me to manage the complexity of my project?
Hold on.
Yes. We are able to pick up the irony in that. Quite easily, in fact.
Consider not using namespaces at the present juncture. They are very useful, but they are also known as a frequent source of annoyances like this.
By the way, I couldn't help but note that the line number and file information in your first example doesn't make any sense either. What the heck is src/gen_setting.pm and line 324?
Well, uh, that's the last line of internal Rakudo code that actually has a working line-and-file annotation. It's nothing that should reach the user, really.
So that's kinda broken, too?
Annotations are currently broken, yes. Apologies.
Back to my mistyped type name. My program is distributed over fifteen modules and ten thousand lines of code. How do you propose I find my typo?
First off, we recommend that you compile often. That way, the diff from the last working code will not be too large, and you will not have to visually scan so much text hunting for your typo.
Secondly, it's often useful to have your project in a version tracker such as Git, so that you can do git diff to see the changes against the index, or against the latest commit.
Thirdly, when all else fails, you can always insert print statements into your code, to try to bisect the origin of the error.
So in other words, Rakudo is no help whatsoever when this occurs?
Now, that's not quite fair. Rakudo tells you that the error occurs. That's actually useful information.
And you consider that adequate?
No, I didn't say that! No-one is happy about this situation. It's just the way things are.
So it can't be fixed?
Theoretically, yes. But not easily. Remember that the error occurs in Parrot.
Don't Rakudo and Parrot developers confer with each other?
Oh, sure we do. Do not assume that we're deliberately causing this situation. It's just that the current way Rakudo and Parrot are welded together makes the situation non-trivial to rectify.
So this problem is going to go away with the advent of the new ng branch?
There's nothing to indicate that this would be the case. In ng, you currently get a Null PMC access:
$ ./perl6 -e 'A::B.foo' # ng branch
Null PMC access in invoke()
current instr.: '_block14' pc 29 (EVAL_1:0)
called from Sub '!UNIT_START' pc 984 (src/glue/run.pir:17)
called from Sub 'perl6;PCT;HLLCompiler;eval' pc -1 ((unknown file):-1)
called from Sub 'perl6;PCT;HLLCompiler;command_line' pc 1489 (src/PCT/HLLCompiler.pir:794)
called from Sub 'perl6;Perl6;Compiler;main' pc -1 ((unknown file):-1)
To its credit, Rakudo ng does provide more information in this case, but unfortunately the information is of a kind which was concealed from the user in Rakudo master about a year ago (because it tended to be very uninformative).
Just to summarize: this all sucks, right?
That would be a succinct description of the state of this particular error message, yes.
I heard that the Perl 6 community has adopted very high standards with respect to error messages. There's talk about "awesome error messages", and last summer I was in the audience when Larry Wall demonstrated how good Perl 6 was at reporting error messages to the user. How does this error message square with all of that?
The awesome error messages are like a platonic ideal towards which all implementations aspire. Rakudo, being rooted in our imperfect physical world, doesn't always get all the way. Yet.
I'm about to go visually scan ten thousand lines of code, looking for where my error message might have originated. Any last words?
We value your efforts as an early adopter of Rakudo. Your feedback is important to us. Have a nice day.
February 08, 2010 12:54
February 06, 2010
Today plenty happened in Rakudo land - in fact, it was my most active day's Rakudo hacking in quite a while. colomon++ also made some great commits, and between us a lot of things moved forward today. For my part, hashes and pairs are in much better shape.
I wrote before that I'd got some Rakudo days left to write up; there are two of them, but I'll cover them both in this post, since some of the work crossed the two of them anyway. Here's what I got up to between them.
- Filled out attribute composition logic for role application. A good chunk of this was written in NQP - in fact, all of the role appliers are. :-) Along the way I brought roles up to speed with the attribute part of the meta-object protocol - I'd forgotten that when doing it for classes, though since we couldn't compose attributes at that time it wasn't so interesting anyway. The end result was that we could pass S14-role/attributes.t again.
- The specification states that if in a role you do inheritance, then this is just passed on to the class that the role is eventually composed in to, and added to that class's parents. We never had any support for this in master; with a neat meta-model approach it became rather easier to get it in place in ng.
- Got BUILD/CREATE fixed up a bit and added back support for "has $.answer = 42" style declarations, again through the new attribute sub-protocol.
- Got us handling non-block where blocks again, and added Block.ACCEPTS back - in Perl 6.
- We had various "helpers" to let us do some of the low-levelish stuff in PIR. This is mostly for the places where we need those things in place in order to be able to compile the rest of the built-ins that are written in Perl 6. However, a couple of these helpers knew too much about Parrot and too little about the meta-model, which abstracts it away. So, I re-wrote some of those in terms of the meta-model. Much cleaner.
- Before we relied entirely on Parrot for our "do we do this role" checks. However, given the unfortunate semantic mis-match between Parrot's built-in role support and what we need for Perl 6 (I did try and influence things in a different direction back when we were doing Parrot's role support, but failed), I've been gradually working us towards not relying on those for Perl 6's role support. (In master, it felt to me like we have almost as much code working around the semantics of Parrot roles as we'll need to have to not use them.) Anyways, the divorce isn't quite complete yet, and it's not even a goal for the ng branch. However, I did make a notable step towards it by getting our .does checks implemented entirely in terms of the meta-model. In the long run, I'm hoping we may be able to write the entire role implementation in NQP, which helps with the even-longer-run dreams I have of Rakudo having additional backends. But that's for The Future. :-)
- Cleaned up and re-enabled sigil based type checking in signatures.
Thanks to Vienna.pm for sponsoring me to hack on Rakudo, not only for these two days, but also throughout 2009!
February 06, 2010 22:45
Several days before Christmas, encouraged by my mum asking, "when you're going to start your Christmas break", I stopped working and hacking on stuff and started relaxing. Until then, I hadn't realized just how tired I was. I slept quite a few ten hour nights in the following week, and had an enjoyable Christmas break. I'd figured I'd maybe take a week or so's break, and then get straight back to things, but a week on I had no motivation or energy to dig in again whatsoever. So, I decided my break would go on through New Years. New Year's celebrations this year involved curry - something I certainly wouldn't mind it involving again.
Early January brought several days in Sweden, part of planning for an upcoming refactoring of my work/location - there's details on my personal blog, but the short version is that I've accepted a job at a Swedish startup and will be moving there in March. It's not full time, so I'll continue to have time for Perl 6 development. They know about and, happily, are supportive of my involvement in Perl 6 and my continued attendance of Perl conferences.
I spent a weekend in Prague on the way home. I did it by train rather than flying, which was enjoyable. It snowed almost my entire time in Prague, and I caught a cold in the following week, but it was kinda worth it to wander around this beautiful city. Didn't bother studying Czech at all, and sorta got by with speaking Slovak, though some folks heard me speak and immediately concluded English would be easier. :-) Somehow it kinda felt like I was back somewhere I belonged, even though I'd never been there before. I love central Europe, and excited as I am about Sweden, I know I'll miss this part of the world a lot.
Anyway, I eased back into some work in January, but mostly took it quite easy. The happy result is that, come February, I'm finding myself recharged and ready to dig back into things again. I got some nice commits done to Rakudo yesterday, and today I meant to, but instead participated on an interesting thread on p6l and did some other useful meta stuff (like this post). Tomorrow should have plenty of hacking time though, and I'm looking forward to it. I also have a couple of blog posts to do about Vienna.pm-funded Rakudo Days I did in December, but never got around to writing up; thankfully I did make notes on what I did on them. :-) My main focuses from here on will be on:
- Continuing to get Rakudo's ng branch into shape - we'll make it master soon. A lot is missing, but things are going back fast and often very neatly. It's easy to focus on what it doesn't yet do that master does, but it has many things right that master does not - now including laziness!
- Finishing up my signatures grant. I really, really want to do that within the next couple of weeks.
Anyway, that's what's been up with me. If you take away anything, it's that you may not realize how much you need a break from something until you take it, and if it's not the only thing putting food on the table, then it's probably better to take the needed amount of break and come back revitalized. I guess the other option is to dig back in regardless, but I suspect that's the path to burnout, something I'm quite keen to avoid.
More technical blabbering here soon. :-)
February 06, 2010 00:31
February 04, 2010
SF took my challenge to heart and started producing a "modern Perl 6" version of the example code in E02. His thought process can be seen here, and here.
After being a bystander for a few hours, I coulndn't restrain myself anymore: I produced my own version. I should say at once that it's quite different from SF's: while he keeps close to the original E02 (which, in turn, sets out to prove that Perl 6 is/was not very different from Perl 5), my version is a bit more liberal in its interpretation. I do mix in some of my personal preferences into it. Some examples:
- We don't do
$ARGS prompts("Search? ") anymore, but there's a nice &prompt function which I used instead, together with a while loop. - The
&show function now uses gather/take, rather than printing directly. - Also, I avoided the statement-modifying mess from the original E02
&show code. - Also, E02's
&show makes a point of using a slurpy @_ rather than naming the paramters. I don't. (Neither does SF.) - It just makes sense to use a
given/when construct in the &insert function. To its credit, E02 tantalizingly hints of it, but then does a MIB mind-wipe. (You don't recall that bit? Oh well...) - In the same function, E02 puts
undef to initiate the child nodes to some empty value. Both SF and I independently realized that just any undefined value won't work if &insert is to have %tree in the signature, because %tree only binds to an Associative value. SF solved it by putting Hash (an undefined Hash type object) in the child nodes, and changed it to Hash.new in the later version. I used {}, which should be equivalent to Hash.new, but IMHO more idiomatic. - The whole traits business hadn't solidified in 2002, but I believe that the end result is both more realiable, more useful, and prettier. You'll have to judge for yourself.
I believe rewriting the exigeses in modern form is a very worthy activity. I hope we'll see more of that. Perl 6 suffers a bit from stale, outdated documentation, and having these in new versions would be valuable.
It's also a very interesting historical activity to read the old apocalypses and exigeses, as I increasingly find. Perl 6 has come a long, long way since 2001.
February 04, 2010 14:47
February 01, 2010
Yes my November edits are on halt so I gave the
TPF Perl 6 wiki some love. Repeatedly that Wiki gets spammed. Unfornunately i didn't found the admin, so had to deleted all spam by hand. If anybody reading that, please help to tighten this socialtext instalation.
February 01, 2010 23:54
[This notice is going out a bit late; the release was indeed
produced on time, but I was delayed in sending out this notice.
With apologies for the delay... --Pm]
On behalf of the Rakudo development team, I'm pleased to announce the
January 2010 development release of Rakudo Perl #25 "Minneapolis".
Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine
(see http://www.parrot.org). The tarball for the January 2010 release
is available from http://github.com/rakudo/rakudo/downloads .
Rakudo Perl follows a monthly release cycle, with each release
code named after a Perl Mongers group. The January 2010 release
is code named "Minneapolis" for Minneapolis.pm, hosts of the annual
Frozen Perl Workshop [1]. In 2009 the Frozen Perl Workshop featured a
one-day hackathon for Perl 6 and Rakudo development, which ultimately
informed the design and implementation of the current build system.
(The 2010 Frozen Perl Workshop will be on February 6, 2010, for those
interested in attending.)
Shortly after the October 2009 (#22) release, the Rakudo team began a new
branch of Rakudo development ("ng") that refactors the grammar to much more
closely align with STD.pm as well as update some core features that have been
difficult to achieve in the master branch [2, 3]. We had planned for
this release to be created from the new branch, but holiday vacations
and other factors conspired against us. This is absolutely the final
release from the old development branch; we expect to make the new branch
the official "master" branch shortly after this release.
This release of Rakudo requires Parrot 2.0.0. One must still
perform "make install" in the Rakudo directory before the "perl6"
executable will run anywhere other than the Rakudo build directory.
For the latest information on building and using Rakudo Perl, see the
README file section titled "Building and invoking Rakudo".
Some of the specific changes and improvements occuring with this
release include:
* Rakudo is now passing 31,957 spectests, or 85.7% of the available
test suite. This is roughly the same level as the December 2009
release (because most effort has taken place in the "ng" branch
as described above).
* Rakudo's calling conventions have been updated to match changes
in Parrot 2.0.0's calling and context structures.
The Perl 6 language specification is still in flux. Please take note of the
following changes, which might affect your existing programs. In the next
release of Rakudo, the deprecated features will likely be gone.
* The root of the object hierarchy has been changed from 'Object' to 'Mu'.
The type 'Object' goes away.
* The term 'undef' is gone. You can replace it with other constructs,
depending on context:
- 'Nil' is undefined in item context, and the empty list in list context
- 'Mu' is the most general undefined value which does not flatten in list
context
- as a smart matching target, you can replace '$obj ~~ undef'
by '$obj ~~ *.notdef'
* Builtin classes will derive from 'Cool' (which itself derives from 'Any').
Most of the builtin methods on these classes will be defined in the
'Cool' class instead of 'Any'. See Synopsis 2 for more details.
* Starting with the next release, we will likely switch to using
"YYYY.MM" instead of "YYYY-MM" (dot instead of hyphen) as release
identifiers. This is intended to simplify building and packaging
for other distribution systems.
The development team thanks all of our contributors and sponsors for
making Rakudo Perl possible. If you would like to contribute,
see http://rakudo.org/how-to-help , ask on the perl6-compiler@perl.org
mailing list, or ask on IRC #perl6 on freenode.
The next release of Rakudo (#26) is scheduled for February 18, 2010.
A list of the other planned release dates and codenames for 2010 is
available in the "docs/release_guide.pod" file. In general, Rakudo
development releases are scheduled to occur two days after each
Parrot monthly release. Parrot releases the third Tuesday of each month.
Have fun!
[1] http://www.frozen-perl.org/
[2] http://use.perl.org/~pmichaud/journal/39779
[3] http://use.perl.org/~pmichaud/journal/39874
February 01, 2010 09:41
January 29, 2010
The Perl 6 design team met by phone on 27 January 2010. Larry, Allison, Patrick, and chromatic attended.
Larry:
- tweaked definition of when a series operator is considered infinite
- nailed down more list assignment semantics with respect to interators
- clarified how
($a, $b, @a) = 1..* works -
KeyWeight deletion criterion kept consistent with other KeyHash types - negative keyweights are allowed to fail at pick time
- "mostly eager" now assumes unknown closure generators are probably infinite
- random whackage on
List, Seq, Parcel, Capture, Iterator, Nil etc. -
List is now simply the iterator role, and doesn't do Positional -
Seq takes over Positional duties for reified (or reifiable) value lists - think of
Seq now as a constant Array (but also lazy like Array) -
Iterable now means you can ask for an iterator, but doesn't do List -
Array, Seq, etc do Iterable, but not List - only actual iterators do
List -
Nil is defined as a suitable sentinel for both list and slice iterators - continued to rethink that with pmichaud++ et al
- we'll probably end up with an
EMPTY special exception object to be the iterator sentinal - proposed an
E operator to go with it to make testing for EMPTY across multiple iterators very fast - other than that, mostly just bug whacking, no major refactors
- still thinking about doing real LTM for STD
- did lazify
Cursor's fnum->fate translations for shorter LTM candidates in preparation for smarter LTM - we don't need special objects for the items that get matches
- we do need to think more about the hyper cases
- how to do list processing using balanced trees of delegated sub refs
- don't want to build in serial assumptions where we don't need them
Patrick:
- made the Rakudo #25 release last week
- it was much easier to make the release than explain what we were planning to do instead
- also working on iterators and lists
- NG branch is blocking on that
- worked on the design in my head for three weeks
- realized that we were doing iterators completely wrong the other night
- Larry's making some useful changes to the spec in response
- there are still some unclear spots in the spec
- we need an implementation to figure those out
- my biggest question is the relationship between
List, Parcel, Itertor, and array - as of this morning, I think I have it
- that code seems to be working and efficient
- so far it's working well
- continuing with that
- wrote a very short range iterator prototype that colomon has used
- also write a
map iterator that works - coming up with examples for the
zip operator was nice - good ideas for what we need to be able to do
- objects that can iterate have a
.iterator() method - to interpolate that into a list,
.list() returns a flat Parcel for that iterator -
Parcels know how to generate Iterators - those know how to handle
Iterators of Iterators - I suspect that's how we do hyper iteration
- change
Parcels to understand that - adding pieces back into the ng branch
- next I have to fix slurpy parameters
- many of our builtins need that
- need to figure out Jonathan's code to do that
- after that, I'll do arrays
- that should remove the blockers on the ng branch
Allison:
- working on Pynie
- Francois has helped greatly to update it for Plumage
c:
- still working on the TT #389 fix
- think I have the right design, just need time to implement it
- working on a potential new time for #parrotsketch
Allison:
- thinking about hackathons
- would be nice to have a Rakudo hackathon at YAPC::NA
c:
- Parrot will come up; didn't it come up about half the time last year?
Patrick:
Allison:
- you'll have an influx of Rakudo interest two months after Rakudo Star
Patrick:
- probably will have one before then
- but can tell people "Go to YAPC; we'll show you how to help in person there"
January 29, 2010 21:00
According to my
modus operandi I wrote the first 2 articles in the november wiki about
Pugs and
Parrot. Next will follow but please participate, get an account from masak (we have a channel at irc://irc.freenode.org/november-wiki) or write me your suggestion to lichtkind@cpan.org and i wrap text around it.
January 29, 2010 19:44
Not all of Perl 6 is Rakudo. Well, when I use Perl 6, it is. But I'm hoping 2010 will change that. We have a few other implementations out there, which fall in the "small but promising" category.
Mildew
From the README:
- Mildew is an experimental implemention of Perl 6, written mainly in Perl
5. It is named in the tradition of 'yeast', 'slime' and 'mold', which
were/are related projects.
I can't say I've ever understood the idea behind naming projects after icky things, but I like the projects as such. They seem to generate a kind of "basic research" which strengthens the foundations of Perl 6. The decade-old project has always been about attacking the enormously big task of implementing Perl 6 from different angles — and I like the angle pmurias++ and ruoso++ are taking.
- Mildew uses the 'viv' parser and the STD.pm grammar to convert Perl 6
source code into an Abstract Syntax Tree. An AST is a data structure
that describes what the Perl 6 program is meant to do. Mildew contains
various experimental backends selected by the -B and -C switches to
export or to execute the code in the AST.
Mildew targets both SMOP (written mostly in C) and the Google V8 JavaScript compiler.
Sprixel
From the README:
- sprixel (anagram of perlsix): viv and STD.pm parse Perl 6 source,
emitting an Abstract Syntax Tree in YAML, then sprixel walks the
AST using its trampolined, stackless, continuation passing style
interpreter written in JavaScript and executed by Google's V8
JavaScript compiler and runtime engine.
I know diakopter++ is playing around with both JavaScript and C♯ implementations of Perl 6 rule engines. That is also an area which excites me, and where I'm glad people are making headway.
Vill
From the README:
- 'vill' is the ugly temporary name of this project that connects 'viv' as
Perl 6 front end to LLVM as code generating back end. It sounds too
much like 'vile', or mock German 'will', but it fits.
Heh.
- Unlike other Perl
implementations such as Pugs, Rakudo, Sprixel and Mildew-js, 'vill'
produces native executable files. [...]
Whoa! That's potentially very attractive.
- The slowest part of 'vill' is 'viv', because that runs as a separate
Perl 5 child process. The medium term plan will be to use the STD.pm
grammar, but replace the 'viv' parser with a new one to be written in C.
[...] If the dependency on 'viv' can be removed, the ugly 'vill' name will no
longer be appropriate, and it will be time to think of a better one
[...]
I'm actually hoping I might be able to help with the C-based parser.
Conclusion
Rakudo is the implementation that shows up on the radar of most outsiders right now. (And with good reason.) But much exciting work is going on in the background, with implementations like mildew, sprixel and vill.
I'm sure this will come off as almost self-evident, but I'll say it anyway: the moment an alternative implementation will cross a threshold into the area of the really interesting, is when it provides a significant chunk of Rakudo's functionality (which is saying quite a lot), together with some feature that Rakudo doesn't have. Given Rakudo/Parrot's current performance, the most obvious feature would be speed. But it might also be something else, such as a bridge to Perl 5, or a very solid metamodel. The more ground-shaking the new feature, the less important will be the delta between the alternative implementation and Rakudo.
At the very least, I think one of the above implementations will pass through the Mach 1 barrier in 2010, and attract a serious user base, and more developers. I'd love for Rakudo (and Pugs) to have some company up there among the "big" implementations.
Exciting times!
January 29, 2010 13:54
January 28, 2010
The Perl 6 design team meet by phone on 20 January 2010. Allison, Patrick, Will, and chromatic attended.
Allison:
- did distro testing on Ubuntu and the Mac
- set up a Hardy chroot; Parrot works just fine there
- have a feeling we missed some deprecations, but we have a lot in there
- enough to work on for three months
c:
- I added the STRING idea, to give us the possibility of the value semantics change
Allison:
- less stressful to have three months at a time
- otherwise working on class assignments
Patrick:
- family illness knocked me out for a few days
- we'll postspone the January release for up to a week
- going to make the Rakudo-ng branch the master branch
- that won't take more than a week
- we'll release by Thursday of next week
- also need to make the -ng branch build with Parrot 2.0.0
- need to merge some outstanding patches to make that work
c:
- are you going to stick with 2.0.0?
Patrick:
- unless we need a change in Parrot that we can't live without, yes
Will:
- we could do a point release if you need one
Patrick:
- that's up to Parrot
- from Rakudo's perspective, that's not terribly important
- we're shifting everything around for the -ng branch
- we'll definitely stick the February release to Parrot 2.1
- I'll post messages to the list about the new release plan shortly
Will:
- working on the one_make branch in Parrot
- trying to mark dependencies properly in a single Makefile
- get some of that out of the configure system
- we should be able to merge to trunk in a day or two
- there's still more work to do, but we're at a merge point soon
c:
- released Parrot 2.0.0 yesterday
- sending out release announcements soon, but the code is out
- Stephen Weeks helped me fix up PGE not to fetch methods from namespaces
- should be able to merge the TT #389 fix branch to trunk very soon
- will take a look at other Rakudo blockers after that
January 28, 2010 00:10
January 26, 2010
The Perl 6 design team met by phone on 13 January 2010. Larry, Patrick, and chromatic attended.
Larry:
- made constant declarations more consistent with type declaration syntax
- removed various spec fossils regarding the old
:by modifier - reworked
KeyHash docs to make the semantics clearer - refactored regex AST methods out of Cursor
- symbol table files are now compiled into their own subdirectory
- STD can now use modules defined in the test suite
- testing STD against the test suite now produces many fewer warnings about missing modules
- STD now specifically disallows forms like
:!foo(0) and :5bar[42] that supply unexpected args - STD now tracks 'of' types in declarations and prevents spurious 'of' types
- STD treats anon enums, subsets, and constants etc more consistently
- removed old type slot from constant declarator, now uses more standard type slots
- random bug fixing
- errors with expectation lists are less noisy, no longer reporting lookaheads and whitespace
Patrick:
- lots of thinking
- looking at Rakudo-ng today
- plan to do lists tomorrow
- want to get those out of the way
- Jonathan and I think we can merge it for the January release
- should know more after the weekend
c:
- working on TT #389
-
:method should not add entries to NameSpace - PGE/TGE have problems
- will not land for 2.0
- may add (and immediately deprecate) an experimental op to help migration
January 26, 2010 22:54
January 24, 2010
I'm back, english-hackin on
November. it was planned to make november the month to push november foreward, but maybe this will happen now in february. currently just pushing some content around, to make smaller, better readable pages. The content will become also better linkable.
I'm delighted that viklung and masak solved the more pressing half of the issues i filled in the november tracker, but 5 min ago I filed a new one.
as i currently preparing an article about the upcoming rakudo star, its easier for me to fill more conent in the p6 related wikis.
January 24, 2010 00:24
January 23, 2010
The Perl 6 design team met by phone on 06 January 2010. Larry, Allison, Patrick, Will, and chromatic attended.
Larry:
- in Spec Land, renamed
p{} to qp{} to avoid using up another common single letter - bare
say/print is now just a warning - Carl Mäsak dug up fossilized restriction on hash literals, which I removed
- since the insides of blocks are now parsed as statements, there is no longer an inconsistency in line-ending curlies
- refined the picking vs grabbing semantics with respect to immutable vs mutable bags and such
- to avoid legacy confusion, renamed
break/continue to succeed/proceed - clarified that an implicit
succeed returns the value of the whole when block - it is not somehow magically inserted around the last statement
- renamed
true to so to avoid confusion of the predicate with the True enum value - at the suggestion of moritz++, split
Any up into Any and Cool types -
Cool stands for Convenient OO Loopbacks, or any other acronym you'd like - the built-in types derived from
Cool are the ones that do Perlish dwimmy coercions - user types still derive from
Any by default, so aren't born with gazillions of methods - conjecturally, also keep "last-resort" multis in
Cool package - responded non-explosively to a potentially explosive rant/twitter
- clarified various things in response
- it is not necessary that all implementations be equally good at everything
- there will be a minimal Perl 5ish grammar alongside STD that any VM can support as a well-behaved subset
- it is also acceptable to support bug-for-bug compatibility with Perl 5
- the language designer is neither omniscient nor omnipotent
- the design process is therefore convergent on the part of all parties involved
- the rate of convergence is an emergent property, and is to be forced
- convergence is deemed to be positive as long as anyone is still working on Perl 6
- the solidification of the spec is also part of the convergence, and depends on proven implementation
- unproven parts of the spec are to be considered implicitly conjectural
- as implementations converge on specs, we can throw out or delay parts of the spec that as yet unproven
- everyone is allowed to panic once.
- on to implementation, found fencepost precedence error inside list prefix
- moved the default initparse method from STD into Curso so other grammars don't have to define it
- added quote modifier
:p (aka :path) so we can form the qp{} path literal - installed better warnings about bare
say/print - generalized the
say/print warning to anything a p5er might try that might be in p6 without the defaulting - STD and CORE now support recent renamings to
so, succeed, and proceed - no longer reports "Bogus statement" when "Missing term" is more accurate
- now catches
/\b/ and advises to use an appropriate p6 word boundary assertion instead - emits better message when an intended reduce is interpreted as composer
- detects most attempts to use postfix after whitespace, and suggests omitting whitespace
- now parses tick-less embedded comment syntax as line-end comment (but still warns for now)
Patrick:
- took the last couple of weeks off
- keeping up with things, but not much writing code
- read the S01 changes with great interest
- glad to see them
- answered some PGE questions for Carl
Larry:
- we've talked about them all along
- they weren't written down in an obvious place
Will:
- working on Parrot
- trying to move as much out of the configure process into a Makefile as possible
- intended to improve the build
- attempting to remove recursive makes
- avoid unnecessary rebuilds
- improve dependency tracking in the build
- probably ready after 2.0
Patrick:
- I'm impressed
- thanks for taking that on; we needed it
Allison:
- working on deprecation notices
- we've talked about a lot of things over the past six months
- not sure they're all in the file appropriately
c:
- working on bugfixes
- also working on deprecations
Patrick:
- I intend to merge the ng branch before the January release
- some people are antsy, but I have a lot of confidence
- we'll probably pass about 70% of the test suite
- it looks like a regression, but we have different features added now
- lazy lists work, for example
- lots of things fudged in the previous version work now
January 23, 2010 00:12
January 22, 2010
I don't know what kept me away from generating code for so long. Fear and prejudice, perhaps.
I've been trying it the last few days, and I have two things to say. First, it's like learning to program all over again. Remember that sense of power from the early days, when just picking up coding? "Hey, I can program this piece of code to do whatever I want." Well, guess what? That feeling comes back when one starts down on the path to madn... erm, to code generation. Only it's stronger. "Hey, I can program this piece of code to program that piece of code to do whatever it wants!" I think I've just discovered meta-hubris. Most likely, I'm not the first to do so.
Second, there's a flip-side to the feeling of power. That other feeling is how you feel when you knit your brows and wish that your neurons would line up a bit better so you could think more clearly about the problem at hand. Who would have thought, that feeling is also stronger when you're suddenly writing two different, entwined and related programs at the same time, in the same file. In my case, the knitted brows turn into an empty stare and a jaw left slackly agape, as I sit there wishing that I was better at context-switching between runloops.
Honestly, I think I expected eval to be the source of much programmer confusion, but I have to confess that it seems I underestimated the vistas it opens up when you buy into the idea of generating exactly the piece of code you need for the task (from an AST, say), and then eval it into a closure. That's what the back end of a compiler ends up doing, so maybe I shouldn't be so surprised that it's a versatile technique.
Lately, I've been in the business of squeezing every drop of juice out of the already implemented control flow constructs already implemented in Rakudo. I'm writing a p6regex→p6 compiler, you see. (Yes, that's a rather crazy notion; thanks for asking.) Along the way, I've often felt the need for not-yet-implemented control flow. This has led me to this hope-inducing maxim:
Every type of control flow in programming languages is just convenient sugar for if statements and while loops.
ifs and whiles are the stone soup to which all the rest of our control flow can be added as seasoning. ifs let you conditionally skip ahead in code, and whiles allow you to conditionally skip back. That's all you need.
Here are some examples.
- Switch statements are just sugar for chained
if/elsif/else statements. Even Perl 6's given/when constructs. - The variants
next, last and redo, either with or without a label to affect a less-than-innermost loop, can be desugared to sad boolean-ish variables, plus some if statements to appropriately regulate the expression of the code inside the loop. (Yes, go ahead and twitch just thinking of it. That sugar is there for a reason.) - Subroutines and subroutine calls can be simulated with the appropriate use of a switch statement and an explicit call stack stored in an array variable.
- Even exceptions, or more generally continuations, can be desugared in this way. As soon as you have total control of the call stack, you're free to save and rewind to some previous state to your heart's content.
Aside from the switch statements and unlabeled next etc, which already work very well in Rakudo, I've been doing the whole list of desugarings in GGE (the regex compiler). The part with the continuations was especially fun. I needed them for backtracking, at least as long as the compiler was only an interpreter.
But then, during a fruitful discussion with diakopter++, I was told how to emulate (delimited) gotos with a switch and a loop. The idea is quite obvious in retrospect: just keep the current 'label' in a variable, and switch on it in each iteration. Presto! I should have thought of that. I don't even need to flee to PIR any more.
I took the idea and generalized it to delimited gosubs: instead of keeping the current label in a scalar, keep it at the top of a stack. Define macro-like constructs to push to (local-branch) and pop from (local-return) the stack. Suddenly I don't need continuations as much.
Result: this. We send in the regex /<[a..b]> | <[b..e]>/ on the top line, along with the target string c to match on. The program generates an AST, an anonymous subroutine which executes the regex in atomic Perl 6 operations, and finally a match object which indeed finds c to be a match.
Here's a similar but slightly more involved example. And here's one doing captures and backreferences inside a quantified non-capturing group. Isn't that exquisite? (Ok, bad choice of word. Sorry.)
As I said, I wrote most of with a feeling of being not just in over my head, but of being in over my head twice. I'm still a bit surprised it works. The runtime compilation seems to introduce a bit of a speed penalty, but (1) it's a one-time cost, since you can re-use the regex object, and (2) I told you it would be slow.
The code-generating work still resides only in a local branch on my computer. I'll push it to master as soon as I'm done bringing GGE back to its former capabilities. (Update 2010-01-24: Done, and done.)
Code writing code. What a concept!
January 22, 2010 16:41
The Perl 6 design team met by phone on 16 December 2009. Allison, Patrick, Jerry, and chromatic attended.
Patrick:
- finished my Hague Grant
- sent the final report to Jesse to wild approval
- drafted a new version of PDD 31 on HLL interop
- write some code to implement part of that in NQP's HLLCompiler
- added various tests
- need to get languages using that now
- Rakudo will use that
- it's the basis for Rakudo's
use and import - if it works for Rakudo, it should follow for other languages which use HLLCmpiler
- had a few comments about missing pieces and corrections
- it's still a draft spec, but we need iteration to finish the spec
- working on little bits of code here and there
- adding features for projects which use NQP
- trying to return to using Rakudo and updating the -ng branch
Allison:
- working on the Pynie refresh this week
- started over with the Python 3 grammar
- have that translated into NQP-rx
- it compiles and can parse a few things
- working my way through the grammar
- no actions set up yet
Patrick:
- there is a
.DEBUG rule - call it on a subrule to turn on tracing from that rule down
- that saves you from having to put in
panic statements
Allison:
- is there a good NQP-rx tutorial for actions?
Patrick:
- working on it
- is your work in the Pynie repo?
Allison:
- it's in Mercurial on bitbucket.org under project pynie
- that's what Python 3 uses
- also the Parrot roadmap session went very well
Jerry:
- we still have some actions to take based on that work
- need to convert our priority list into Trac tickets and wiki items
- Parrot's goal for every month until Rakudo * is to support Rakudo * and HLLs in general
Allison:
- that's valuable
- it changes our priorities in the next year
- it moves things between "would be nice" and "necessary"
c:
- worked on the roadmap session
- helping with the Context/CallSignature merge
- will do a dry run of the Rakudo release today
January 22, 2010 01:52
January 21, 2010
MiniPerl6 (mp6) is a subset of Perl 6, which was designed as a light
bootstrapping language.
Changelog for version 3.0:
- Go language backend; using Go: http://golang.org/
- Java-class backend; using Rhino: http://www.mozilla.org/rhino
- util/mp6.pl - compiler command line script written in MiniPerl6
- new repository at http://github.com/fglock/Perlito
- new web page at http://www.perlito.org/ created by nferraz (Nelson Ferraz)
Enjoy!
- Flávio S. Glock (fglock)
January 21, 2010 09:01
The Perl 6 design team met by phone on 09 December 2009. Larry, Allison, Patrick, Will, and chromatic attended.
Will:
- some work on NQP port of Partcl
- Patrick has been very helpful
- sent a message to the Parrot list about the planning meeting this Sunday
- initiated a community document to discuss those plans
Allison:
- implemented large chunks of obscure C code to perform fast string matching using the FFT
- wondering if that'd be useful in Parrot
- maybe we do our indexing operations by character set in the NFG form
- also does very basic pattern matching by leaving out optional characters
- could be useable in the core tests, where it's tricky to depend on PGE
- this was my final assignment before the Christmas break
- have a month off to work on Parrot stuff then
- I'll show off my assignment when I submit it
Patrick:
- finished my final report for my Hague grant
- haven't quite finished the grant, but left TODO items
- rather than trying to finish everything and then write the report, I'd draft the report and keep notes on what I needed to finish
- need to work on HLL interop
- enable Perl 6 and other Parrot languages to load libraries from other HLLs
- will work on that over the next few days
- had several coversations about optimizations, constants, and inferior runloops
- made minor PAST improvements
- integer constants can automatically promote to num constants without going through a PMC
- updated NQP to make it easier to write custom operator subs, if you're using the operator precedence parser
- implemented the beginnings of smart matching
- not full Perl 6 smart match
- makes sense in the Parrot context
- can match against regexes, tokens, rules, and any types with protoobjects
- code looks more like Perl 6
- not much on Rakudo besides answering questions
- will get back to the Rakudo-ng merge after finishing my grant work
- also worked on Partcl
- updated its regex syntax, particularly for enumerated character classes
- fixed it to handle unquoted, non-word characters in regexes
- previously it only handled barewords as literal matches
- it's closer to the Perl 5 syntax now
Larry:
- didn't like the name
PairValSet, renamed it EnumMap - likewise
PairSet is now PairMap, and PairVal is just Enum - so individual constant pairs now called "enums"
- we distinguish pairs, which have read-write values, from enums, which are constant in the value
- you can now do
.enums on hashes and arrays as well as enumerations - differs from
.pairs, which give reference semantics into the values of the original data structure -
.enums gives you a constant snapshot - David Green suggested renaming
Enum.name to Enum.key, and he was right, since they're constant pairs - trying to be consistent about calling the whole type an "enumeration" and referring to the bits as "enums", even though the keyword is
enum - thought people would rebel at typing the long name
- clarified that the anonymous
enum is compile-time evaluated as an anonymous list of constants - you can always cast to an
EnumMap at run time for the other behavior - simplifying conditional semantics
- STD parser now parses a
WHENCE closure as part of the typename, rather than relying on subscript parse - block escape within a closure within a string used to parse as a normal block by responding to comments outside of the block
- already fixed the embedded block in the regex syntax
- made that usable by strings and regexes now
- blocks in regular code try to figure out if they're at the end of a statement
- look for the trailing curly
- inside a string or regex, there are no statements
- it makes no sense to look for the end of the statement there
- the obsolescence messages were still in the old framework that upsets some Perl 5 people
- changed the wording to "Unsupported use of ..."
- #perl6 found a precedence inconsistency in parsing of list prefixes vs list infixes in NG
- turned out to be wrong in STD first, and NG copied it
- I fixed it in STD, Patrick fixed it in NG
- otherwise last week was rather too ADD-ish, so mostly did Q&A on IRC
c:
- fixed some bugs
- made some optimizations
- think I've fixed most constant PMCs in PBC now, which should help NQP and Rakudo
Patrick:
- it'll take a while before Jonathan and I can take advantage of that
- Allison, when you
push_eh an ExceptionHandler onto an array in a context, it creates an RPA - does that hold other things besides an EH?
Allison:
- potentially
- events get stored in the scheduler
- only EHs are scoped to a context
- the old
pushmark/popmark stuff to do actions used that same global array - it may have changed to use the same array
- that's deprecated though
- they won't use that array for long
Patrick:
- I need something to replace
pushaction and popaction before they go away - when we handle
LEAVE semantics, we want to avoid generating an exception to leave that scope for caching - I don't want to generate and rethrow actions to go up the stack
- those ops let me do that without generating exceptions
Allison:
- we do need singleton exception objects for
FAIL and RETURN - no extra information needed
- right now, you can insert anything you want in that array
- the
local_branch and local_return uses that array
Patrick:
- it shouldn't
-
bsr and ret may have - I provide my own there
Allison:
- oh right
- I might not have checked in that code
Patrick:
- by the way, NQP doesn't use
local_branch or local_return
January 21, 2010 04:41
The Beyond and below are like a deep of ocean, and we the creatures that swim in the abyss. We're so far down that the beings on the surface superior though they are can't effectively reach us. Oh, they fish, and they sometimes blight the upper levels with points we don't even understand. But the abyss remains a relatively safe place.
Vernor Vinge, A Fire Upon the Deep
On behalf of the Parrot team, I'm proud to announce Parrot 2.0.0 "Inevitable." Parrot is a virtual machine aimed at running all dynamic languages.
Parrot 2.0.0 is available on Parrot's FTP site, or follow the download instructions. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on our source code repository to get the latest and best Parrot code.
Parrot 2.0.0 News:
-
Features
- Context PMCs now support attribute-based introspection
- Context and CallSignature PMCs merged into CallContext
- .lex directive throws exceptions when used with incorrect register types
-
Platforms
- Packaging improved for free OS distributions
- PPC, PPC64, and ARM now tested when running Linux
-
Performance
- Minor improvements to the profiling runcore
- Improvements from the CallContext PMC merge
-
New deprecations
- In/out parameters in STRING modification functions
- Void handling in NCI signatures
- Parameter passing opcodes order in PBC
-
Tests
- Continued migration of core tests from Perl 5 to PIR
-
Tools
- dependency checker improved
-
Miscellaneous
- Deprecation cycle length changed to three months from six
- GC accuracy improved
- PMC freeze improvements; much more reliable
- Makefile improvements for dependency handling
Thanks to all our contributors for making this possible, and our sponsors
for supporting this project. Our next release is 16 February 2010.
Enjoy!
January 21, 2010 04:37
January 20, 2010
The Beyond and below are like a deep of ocean, and we the creatures
that swim in the abyss. We're so far down that the beings on the
surface -- superior though they are -- can't effectively reach us.
Oh, they fish, and they sometimes blight the upper levels with
points we don't even understand. But the abyss remains a relatively
safe place.
-- Vernor Vinge, A Fire Upon the Deep
On behalf of the Parrot team, I'm proud to announce Parrot 2.0.0
"Inevitable." Parrot (http://parrot.org/) is a virtual machine aimed
at running all dynamic languages.
Parrot 2.0.0 is available on Parrot's FTP site, or follow the download
instructions at http://parrot.org/download. For those who would like to
develop on Parrot, or help develop Parrot itself, we recommend using
Subversion
on the source code repository to get the latest and best Parrot code.
Parrot 2.0.0 News:
- Features
+ Context PMCs now support attribute-based introspection
+ Context and CallSignature PMCs merged into CallContext
+ .lex directive throws exceptions when used with incorrect register types
- Platforms
+ Packaging improved for free OS distributions
+ PPC, PPC64, and ARM now tested when running Linux
- Performance
+ Minor improvements to the profiling runcore
+ Improvements from the CallContext PMC merge
- New deprecations
+ In/out parameters in STRING modification functions
+ Void handling in NCI signatures
+ Parameter passing opcodes order in PBC
- Tests
+ Continued migration of core tests from Perl 5 to PIR
- Tools
+ dependency checker improved
- Miscellaneous
+ Deprecation cycle length changed to three months from six
+ GC accuracy improved
+ PMC freeze improvements; much more reliable
+ Makefile improvements for dependency handling
Many thanks to all our contributors for making this possible, and our sponsors
for supporting this project. Our next scheduled release is 16 February 2010.
Enjoy!
January 20, 2010 20:00
January 19, 2010
The other day, I remembered this old piece of #perl6 backlog from 2005:
<masak> question: what are good ways in p5 and p6 respectively, to reverse a string?
<masak> the easiest way i found in p5 was join '', reverse split // $string
<masak> doesn't look very nice, now does it?
<integral> *blink*
<integral> $string = reverse $string
It feels odd to realize this five years later, but it seems that in 2005 I didn't have a firm grip on how reverse worked in Perl 5. Chances are, dearest reader, that you do. But if not, the rest of the refreshingly frank discussion will explain it.
Meanwhile, five years earlier, I persist in my innocent ignorance:
<masak> nope
<masak> doesn't work :(
<masak> reverse only reverses lists... i think
Reading this from the perspective of five years' work with Perl 5 and 6 is... enlightening, in a slightly cathartic way. Sure, it could have been that I'm the first to discover that reverse in Perl 5 doesn't in fact reverse strings, despite thousands of people using it daily for that purpose. But the chances of that are astronomically small. My peers on the channel tell me this.
<PerlJam> masak: clearly you are insane.
<integral> perl -le '$string = "abc"; $string = reverse $string; print $string'
<integral> masak: the manual *clearly* explains all the stuff about context
<integral> and the faq
They do, you know.
<PerlJam> masak: in perl6 it would be $string.=reverse probably.
This was true in 2005, but nowadays we have flip for strings, reverse for lists, and invert for hashes. The need for different functions falls out naturally from the fact that Perl 6 doesn't depend as heavily on context as Perl 5 does.
Back in the log, I'm still trying to reintegrate into reality.
<masak> integral: your example worked, thx
<masak> but nothing worked for me
<masak> apparently i am insane :P
PerlJam and integral are one step ahead of me.
<integral> no, you don't understand scalar context. perl -le 'print scalar reverse shift' foobar
<PerlJam> masak: you were probably saying "print reverse $string"
<masak> no, but maybe something of the sort
<masak> and that doesn't work, because...?
<integral> masak: print's prototype is (@), ie list context. It's a rightwards named list operator
<PerlJam> masak: context.
* masak thinks he sees it now
These explanations are actually very good, but just in case, let me restate them in my own words: reverse has two main behaviours. Either it reverses a list of things, or it reverses a string of characters. It switches between these two behaviours based on something. You might think that this something is what type of thing you send in (a scalar or a list), but that isn't so. Instead, reverse responds to its surroundings and figure out what they expect. $string = reverse $string is a scalar assignment, and expects a scalar. print reverse $string, as integral explains, puts reverse in list context, so it reverses the list of one thing ($string), i.e. doing nothing.
Steve Yegge has this to say, in a vitriolic critique of Perl:
Perl also has "contexts", which means that you can't trust a single line of Perl code that you ever read.
I would say that it's actually not that bad, and the idea of context can be unintuitive at times, in many cases it's actually very natural and useful. reverse, in my humble opinion, is not one of those cases. I'm glad it's split up into different methods in Perl 6.
At the end, we learn that I had actually Read The Faithful Manual already, I just hadn't read it carefully:
<PerlJam> masak: perldoc -f reverse
<masak> thx, integral and PerlJam
<masak> PerlJam: I read the perldoc entry but apparently not carefully enough
* masak reads it again
<masak> ah
<masak> "In scalar context, concatenates the elements of LIST and returns a string value with all characters in the opposite order."
<masak> this somehow went past me as something i didn't want :/
In summary, I mostly wrote this blog post because I like to make myself squirm. 哈哈
But I guess there's also a moral to it all. We all start somewhere, and in a way it's reassuring to find five-year old proof of this fact. A newbie is just on a part of the learning curve you've already visited; they haven't had a chance to tweak their keyboard and developing environment to maximum efficiency yet, and they sometimes forget that the manual is there, or misread it in some way. So, don't hesitate to be be kind to them, and help them connect to the goodness that is perldoc, PerlMonks and Planet Iron Man so that they can grow and bloom into experienced wielders of Perl.
But don't hesitate to call them insane, either, when the situation calls for it.
January 19, 2010 09:26
January 16, 2010
A class hierarchy of expression nodes: it's so much the prototypical use case for run-time method polymorphism that it's almost a cliché. One can close one's eyes and picture the way parts of the expression tree interact in rich, complex ways, shaped by the very types of the nodes themselves, in a dynamic dance of late bindings and virtual methods. Switch statmement, get thee behind me. Et cetera.
I'm building one. And I'm having almost too much fun doing it. In between trying to use the strengths of Perl 6 and keeping true to the original program I'm porting, I've discovered an important thing: Ovid is right about roles.
Specifically, I'm having trouble picturing how I would cram all the type information into my expression node class hierarchy, were I not using roles. The roles definitely help manage complexity in my case.
Here's a pretty diagram of my class hierarchy.
It's a flat beast. Apart from everything deriving from Exp, I have only one case of old-skool inheritance in the diagram. And even that one is more making a point than actually shortening the code.
Then there's all the colorful dots, representing the roles I'm mixing into my types. Some are for convenience (like the blue ones), others are vital for my program (like the green ones), and the rest are somewhere in between on the convenient/vital scale.
I even have a case of inheritance between two of the roles! Which means, in practice, that those classes with an orange dot also act as if they had a red dot. Very handy.
During the infancy of Rakudo, I've gotten used to learning to live without various features. Were I to do what I'm doing here without using roles, I could use two other mechanisms. The first is regular inheritance. The very thought gives me a bit of vertigo; I don't think I'd be able to turn the colored dots into base classes. Definitely not all of them at once; I'd have to choose. And that choice would affect the entire design of the program, probably resulting in loss of clarity.
The second way I could compensate for not having roles would be by using .can a lot. The presence of a given role in a class is isomorphic to the presence of a given method in a class. So that would definitely work, but I don't think I would like it as much. There's something to be said for declaring is and does relationships at the very top of the class declaration.
All in all, I'm very happy about the way things work. I'm wondering whether, had I not read all of Ovid's posts on managing the complexity of class hierarchies with roles, I would have come up with this design myself. Maybe, maybe not. But anyway: thanks, Ovid! This rocks!
A still-open question for me is whether the topmost type, Exp, should be a class or a role. Synopsis 12 has this to say about when to use roles:
Classes are primarily for instance management, not code reuse.
Consider using C when you simply want to factor out
common code.
I am using Exp for code reuse, and for giving all of the other classes in the hierarchy a common base type. So I guess I could indeed turn it into a role. But it's just that... I don't see a reason to do so, and I still feel instinctively reluctant about it. Maybe I'm a bit hung up about it being a class hierarchy.
This point has come up before on IRC, and I've yet to hear a satisfactory way to resolve it: when faced with making a base type a class or a role, which way should one go?
January 16, 2010 17:38
