Val migration
The primary difficulty in moving over to the new internals are that it's hard to make a huge all-encompassing change in a project. We're not just changing the internal representation of strings from one form to another. Encapsulation and type inference would make that task certainly manageable. The present change affects virtually all Perl types, obsoletes the widely-used VRef, and changes the way AST expressions are strung together.
Another problem is that the new AST is much more detailed than the old one, and putting all its definitions in one file makes it hard to maintain/understand all at once. Also, although this AST definition should be shared by all Perl 6 implementations, the native value representations are backend-specific.
Armed with techniques from this paper, we can address both issues at the same time. Instead of a closed datatype for Val (starting from values instead of expressions makes migration easier), we make use of typeclasses where appropriate. A new (:>:) class lets us stipulate subset relationships cleanly, so a single cast method convers (old) Strings to (new) ByteStrings, but also a value to its Id when in Id context.
The work is going along nicely. We've added a VV node type in the old AST, and already we can construct newstyle values from pugs by casting them with the interim vv prim. This helps to keep us honest, as our code comes under constant scrutiny of the type checker and actually gets to be executed.
pugs> vv "Moose"
VPure (MkStr "Moose") # look, not VStr!
pugs> vv 42
VPure (IFinite 42)
pugs> vv 3.1415
VPure (NRational (6283%2000))
pugs> vv "22"/7
VPure (NDouble 3.142857142857143)
Thanks for the update. Speaking of "Moose", I'm looking forward to object.meta.class_precendence_list working. :)
That's the one missing feature I've noticed that I need for the port of CGI::Application to Perl6.
Posted by: Mark Stosberg | 2006.08.12 at 07:14 AM
Mark: Which tests in t/ tests that? :-)
Posted by: Audrey T | 2006.08.13 at 11:00 AM