Perl6 Pi and continued fractions

I was looking through the code of the Rakudo implementation of Perl6 where I noticed that it defines pi as my constant pi = 3.14159_26535_89793_238e0; ( with an alias my constant π := pi; )
I immediately remembered that for a subset of fractional numbers Perl6 has a type that stores them without the loss of precision that generally accompanies floating point math. That type is of course the Rat (and FatRat) type. So of course I type pi.Rat into the REPL, it then prints 3.141593 which is obviously nowhere near as precise as the result of just typing pi into the REPL 3.14159265358979.
I wanted to see the numerator and denominator values that Perl chose to use so I typed pi.Rat.perl and got <355/113>, which is nowhere near as precise as the Rat type is capable of handling. That was just the entrance to the rabbit hole.

Perl 6 and D separated at birth

When I first learned of Perl6 and D, They seemed to me to have similar sensibilities.

One of the motto’s of the Perl community is to “Make easy things easy and hard things possible”. I find it interesting that D actually does that to some extent. It has built-in resizeable arrays, and associative arrays for example.

Perl has always tried to shield the programmer from memory management. D also does that by having a garbage collector built into the language.

Neither language has been designed for complete backwards compatibility, because it has proven limiting in their respective ancestry. ( Perl4 -> Perl5 and C -> C++ )

Both Larry Wall and Walter Bright decided that different things should look different. This helps the compiler to parse them, but also helps the programmer to tell the difference.

I suggest that everyone who wants to learn a new programming language, learns both of them. Even though there is a large overlap in design ethos, they don’t have much overlap in actual design.


Of all the new languages, these two are the only ones that don’t feel like toys, or minor improvements of earlier languages.

  • Go
  • Coffee Script
  • Dart
  • C#
  • F#

Strings: Characters vs Data

I’ve been thinking, why is it that Character strings, and Binary strings are mostly the same in Perl. If you read in a binary file, why would you want it to behave as if it were a Character file?

The main difference currently, is that Unicode Character strings have the utf8 bit set. There isn’t really any difference between ASCII Character strings, and Data strings. It also presents a challenge if you want to read in Data strings that have Character strings in them, especially if the encoding of the Character strings is anything other than UTF8.

There are some historical reasons for this conflagration, Perl was originally designed to work with ASCII Character strings. Since there was almost no difference between the 8 bit ASCII, and 8 bit data; there wasn’t any real need to separate the two. Unfortunately the world (of programming) is no longer this simple, Perl needed to change to handle Character data that wouldn’t fit in a single 8-bit byte.

The way this was done was by adding a flag to the string type. When it is set, it means the Character string may have characters that are larger than could fit in a single byte. When the utf8 flag is not set, it means there probably isn’t any characters larger than 1 byte. Unfortunately it could also mean that the string is actually a binary Data string.

All of that is ignoring the fact that there are actually quite a few other ways to store Character strings than just UTF8. Currently the only way to handle them is to convert them to UTF8 Character strings, and setting the utf8 flag.


Unfortunately the way this has been implemented, makes it more difficult to handle Data strings. - You have to be careful when appending strings to them, otherwise it could get the utf8 flag incorrectly applied to it. - You also have to carefully construct your regular expressions, to avoid matching something other than what you intended. - You will also have to use pack and unpack to convert the binary data to numbers, and to convert them back.


The only real way out of this mess is to actually have separate, or mostly separate implementations of Character strings, and Data strings. Unfortunately this is a lot easier to say than it would be to implement. It would probably require incompatible changes, which would hinder backwards compatibility. There are probably many places in the code that rely on how strings are currently implemented. There is also a question about how you would control the behavior from the Perl language itself. Also how would the IO system have to be modified to handle this correctly?

This change would also go a long way towards having more than one internal encoding to handle Character strings.


I’m not endorsing any of the ideas above, I just want you to consider the possibilities.