Perl 6 hands-on tutorial – A small introduction to a big language [pdf](jnthn.net)
jnthn.net
Perl 6 hands-on tutorial – A small introduction to a big language [pdf]
http://jnthn.net/papers/2015-spw-perl6-course.pdf
6 comments
As someone who is relatively new to perl, I think perl 6 is definitely a positive direction. It removes lots of inconsistencies, while providing a clean base for future expansion. For something like the sigils, what's more important - to know that a variable is a scalar, or that it's some kind of hash/array? The second would definitely be less confusing when learning the language.
There are also definitely some good things coming out of perl 6, like this https://www.youtube.com/watch?v=JpqnNCx7wVY
There are also definitely some good things coming out of perl 6, like this https://www.youtube.com/watch?v=JpqnNCx7wVY
Name some things that they changed for "no meaningful reason".
As you state, Perl 5 has added a number of things that Perl 6 promised. So why would you want Perl 6 to just be what Perl 5 has become? They're two completely separate languages with some shared syntax/semantics.
As you state, Perl 5 has added a number of things that Perl 6 promised. So why would you want Perl 6 to just be what Perl 5 has become? They're two completely separate languages with some shared syntax/semantics.
I mean, if Perl 6 didn't want to be confused with being the same language as Perl 5, it didn't have to increment the version number by one and keep the name. As far as why one would want Perl 6 to just be Perl 5 plus some new stuff, that's really how most languages handle keeping the same name and incrementing the version by one. People who have Perl 5 code and want to keep writing in the same language but with more whathaveyou probably want Perl 6 The Completely Separate Language to go away so that Perl can get the kind of Perl 6 any other language would've gotten by now.
From an outside perspective, the distinction between Perl 5 and Perl 6 is confusing.
Are they literally separate languages?
Did Perl 5 come after Perl 6?
Are they literally separate languages?
Did Perl 5 come after Perl 6?
Perl 6 started around when perl 5.8 was released. Then Perl 5 went stagnant while most of the core language developers were working on Perl 6. After a few years where there were competing implementations of perl 6, and still some wild ideas being tested, folks that still were using Perl 5 watched the rest of the languages develop, and the growing buglist against perl 5, and starting poaching ideas from Perl 6, ruby, python, and improving the Perl 5 runtime.
Eventually, The Perl 5 camp committed to regular releases, and continued renewed development in the engine, and it is still pretty good. But the damage has been done @ this point -- a lot of the community has wandered off to other 'cool' languages and frameworks.
The confusion will continue, especially since it's become clear Perl 6 is quite the departure from Perl 5, and there is a LOT of code in the wild using Perl 5. I've seen some talk of the Perl 5 folks asking Larry Wall to rename Perl 6, but he's declined to do so.
With perl6's grammar support, some folks are working on importing the perl5 grammar into perl6[0]. Fortunately, there's a very rich testing environment(in the form of CPAN) to ensure this effort will be stable.
[0] https://github.com/rakudo-p5/v5/
Eventually, The Perl 5 camp committed to regular releases, and continued renewed development in the engine, and it is still pretty good. But the damage has been done @ this point -- a lot of the community has wandered off to other 'cool' languages and frameworks.
The confusion will continue, especially since it's become clear Perl 6 is quite the departure from Perl 5, and there is a LOT of code in the wild using Perl 5. I've seen some talk of the Perl 5 folks asking Larry Wall to rename Perl 6, but he's declined to do so.
With perl6's grammar support, some folks are working on importing the perl5 grammar into perl6[0]. Fortunately, there's a very rich testing environment(in the form of CPAN) to ensure this effort will be stable.
[0] https://github.com/rakudo-p5/v5/
> a lot of the community has wandered off to other 'cool' languages and frameworks
I am just one such. Half my career was writing Perl. But these days, most of my work is in Ruby and as a longtime fan of Erlang (but never having had the opportunity to use it in production), I'm taking a long look at Elixir+Phoenix. This tutorial wasn't enough to entice me back to Perl, and I'm wondering if there is anything at all that could.
In general we choose a language for their applicability to the problem domain. The focus on text manipulation in Perl 4, and then extension of this with an object framework in Perl 5, made it a shoo-in in the 90s and early C21 when we all needed form parsing, HTML template stuffing, and email mangling tools. In these days of dynamic DOM manipulation and event-driven microservices, it doesn't seem so relevant; whilst Node and Go and Elixir look entirely on point.
If you go look at the Perl 6 FAQ, there's a section, "Why should I learn Perl 6?". It lists a grab-bag of language features, rather than a set of problems that Perl 6's new design can solve. As a result it feels much like a solution in search of a problem. That wasn't even ever true of JavaScript, even though JS took years to come of age.
If I was designing a language today, and I am not, but if I were, I would look at how dominant Java seems to be in the big data community and try knocking it off that perch with appropriate language primitives, constructs and libraries. It seems to me this is the modern problem domain homologous to the bulk text mangling for which Perl originally became famous.
I am just one such. Half my career was writing Perl. But these days, most of my work is in Ruby and as a longtime fan of Erlang (but never having had the opportunity to use it in production), I'm taking a long look at Elixir+Phoenix. This tutorial wasn't enough to entice me back to Perl, and I'm wondering if there is anything at all that could.
In general we choose a language for their applicability to the problem domain. The focus on text manipulation in Perl 4, and then extension of this with an object framework in Perl 5, made it a shoo-in in the 90s and early C21 when we all needed form parsing, HTML template stuffing, and email mangling tools. In these days of dynamic DOM manipulation and event-driven microservices, it doesn't seem so relevant; whilst Node and Go and Elixir look entirely on point.
If you go look at the Perl 6 FAQ, there's a section, "Why should I learn Perl 6?". It lists a grab-bag of language features, rather than a set of problems that Perl 6's new design can solve. As a result it feels much like a solution in search of a problem. That wasn't even ever true of JavaScript, even though JS took years to come of age.
If I was designing a language today, and I am not, but if I were, I would look at how dominant Java seems to be in the big data community and try knocking it off that perch with appropriate language primitives, constructs and libraries. It seems to me this is the modern problem domain homologous to the bulk text mangling for which Perl originally became famous.
For event-driven microservices, I think Perl 6 is actually a great choice. I have experience writing some small things in Go and Node.js, but Perl 6 offers much more powerful high-level features for handling async, concurrency, and parallelism.
Promise combinators are built into the language to provide composable concurrency. But unlike using something like Q in Node.js, you can truly perform tasks across promises in parallel (and with static typing to boot!)
Perl 6 has channels for when you want Go style semantics, but you also have Supplies for when you want their dual: instead of pushing events through channels you pull them reactively. This allows you to write highly declarative code; see https://gist.github.com/muraiki/222814d5928f648be3c1
I think that P6 will also be awesome for data munging. Here's a pipeline that processes text from a file with 4 parallel workers.
I've used Elixir before. It has some great features and having the power of BEAM and OTP is quite awesome. But sometimes the actor model is not what you want. I think that Perl 6 will be not just a great glue language, but also a powerful language for writing multi-paradigm applications that meet the demands of modern systems.
Promise combinators are built into the language to provide composable concurrency. But unlike using something like Q in Node.js, you can truly perform tasks across promises in parallel (and with static typing to boot!)
Perl 6 has channels for when you want Go style semantics, but you also have Supplies for when you want their dual: instead of pushing events through channels you pull them reactively. This allows you to write highly declarative code; see https://gist.github.com/muraiki/222814d5928f648be3c1
I think that P6 will also be awesome for data munging. Here's a pipeline that processes text from a file with 4 parallel workers.
my $lines = open('foo.json', :r).lines.hyper(batch => 20, degree => 4)
my $filter = $lines.grep: -> $line { $line ~~ /someregex/ };
my $json = $filter.map: &from-json;
my $foos = $json.grep: *<some_property> == 'foo';
say $foos.list[8];
I've used Elixir before. It has some great features and having the power of BEAM and OTP is quite awesome. But sometimes the actor model is not what you want. I think that Perl 6 will be not just a great glue language, but also a powerful language for writing multi-paradigm applications that meet the demands of modern systems.
Fyi, Jonathan recently wrote:
> Also, the name channel is evocative of the concept in Go, but our channels aren't like that. They don't block senders until the receiver is ready, for example. While a blocking queue is a very useful thing to have in a language, and we should keep it, we may want to stop calling it Channel, to avoid confusion (and keep the name free for something that has the Go-ish semantics).
(from https://gist.github.com/jnthn/a56fd4a22e7c43080078)
(note that most of the changes mentioned in the gist have since been implemented)
> Also, the name channel is evocative of the concept in Go, but our channels aren't like that. They don't block senders until the receiver is ready, for example. While a blocking queue is a very useful thing to have in a language, and we should keep it, we may want to stop calling it Channel, to avoid confusion (and keep the name free for something that has the Go-ish semantics).
(from https://gist.github.com/jnthn/a56fd4a22e7c43080078)
(note that most of the changes mentioned in the gist have since been implemented)
>>I'm wondering if there is anything at all that could.
Ok, I've been following Perl 6 for quite a while and learning it these days. So that I could use it for my day to day work after its production release in Christmas.
If you liked Perl in the past, and like Ruby. You will absolutely love Perl 6. It has a lot more cleaned up syntax. And the language as such is very Perlish. You will enjoy grammars and macros. And please don't think arrival of JSON and XML has solved and eliminated all text processing problems on earth. If anything arrival of any standard format, only emphasizes the importance of good text processing tools. One size fits all approach doesn't work for common place problems. Sooner or later you will see people shoe horning all kinds of solutions into problem domains they don't belong. The net result looks more like a kludge, than a real solution. This is the whole problem facing people today, because we are forced to use solutions which were not invented to solve the problems they were designed to solve.
>>In general we choose a language for their applicability to the problem domain.
Perl 6 is a language designed to provide you tools to work with any problem domain, while adopting without breaking backwards compatibility. If this is your concern, then you only have good news to listen.
>>As a result it feels much like a solution in search of a problem.
iPhone, Unix, C, the original perl itself were all solutions in search of a problem. None of them had prior users or had well marketed audience to begin with. Sometimes people don't know what they want unless they are shown the solution. Tools are not designed based on survey results. Else we wouldn't have cars today, only faster horse carriages.
>>I would look at how dominant Java seems to be in the big data community and try knocking it off that perch with appropriate language primitives, constructs and libraries.
Java as a benchmark is worst design point you can start with. Only reason why Java is even surviving today is because of its enterprise inertia, and unlimited supply of cheap programmers. At some point in time a massive reset to Java way of doing things is imminent. Language as a whole is old, the original platform-independent goal is now common place in all tools. They can't seem to add anything new or useful without breaking backwards compatibility and the power is falling in the face of newer and powerful languages.
Ok, I've been following Perl 6 for quite a while and learning it these days. So that I could use it for my day to day work after its production release in Christmas.
If you liked Perl in the past, and like Ruby. You will absolutely love Perl 6. It has a lot more cleaned up syntax. And the language as such is very Perlish. You will enjoy grammars and macros. And please don't think arrival of JSON and XML has solved and eliminated all text processing problems on earth. If anything arrival of any standard format, only emphasizes the importance of good text processing tools. One size fits all approach doesn't work for common place problems. Sooner or later you will see people shoe horning all kinds of solutions into problem domains they don't belong. The net result looks more like a kludge, than a real solution. This is the whole problem facing people today, because we are forced to use solutions which were not invented to solve the problems they were designed to solve.
>>In general we choose a language for their applicability to the problem domain.
Perl 6 is a language designed to provide you tools to work with any problem domain, while adopting without breaking backwards compatibility. If this is your concern, then you only have good news to listen.
>>As a result it feels much like a solution in search of a problem.
iPhone, Unix, C, the original perl itself were all solutions in search of a problem. None of them had prior users or had well marketed audience to begin with. Sometimes people don't know what they want unless they are shown the solution. Tools are not designed based on survey results. Else we wouldn't have cars today, only faster horse carriages.
>>I would look at how dominant Java seems to be in the big data community and try knocking it off that perch with appropriate language primitives, constructs and libraries.
Java as a benchmark is worst design point you can start with. Only reason why Java is even surviving today is because of its enterprise inertia, and unlimited supply of cheap programmers. At some point in time a massive reset to Java way of doing things is imminent. Language as a whole is old, the original platform-independent goal is now common place in all tools. They can't seem to add anything new or useful without breaking backwards compatibility and the power is falling in the face of newer and powerful languages.
Having somehow avoided much Perl for most of my working life, I've recently done quite a bit of it (Perl 5 this is), and I have found it, syntactically, a painful experience when compared to Ruby and Python. The one thing I have loved compared to those two though is the performance. If Perl 6 retains that performance edge it may gather mindshare, but otoh my impression of Perlists that I work with is that they are quite content with Perl 5's warts, so I am not convinced that 6 will have much of an impact.
If I have one piece of advice for people coming from other languages into Perl 5, it's to not be fooled by some similar looking syntax into thinking it should be used like C or any other C-like language. I find assumptions in that vein are often what leads people to painful assumptions about the language.
If I had time for a second piece of advice, it would to be sure you understand context in Perl 5[1]. Everything is based around context, and to not be aware of how it factors in to the current expression often leads to befuddlement (at best) or anger. On the flip side, context is often where Perl shines. I recommend Chromatic's excellent Modern Perl: The Book[1] if you feel any of this might apply to you.
Finally, Perl can be a very Lispy language. Avoiding those parts (map, grep, etc) is sort of like consciously avoiding every even gear when driving a car. Possible, but much more painful than using it as designed.
Edit: Oh, you probably want that reference I implied up above.
1: http://modernperlbooks.com/books/modern_perl_2014/ covers context in multiple sections.
If I had time for a second piece of advice, it would to be sure you understand context in Perl 5[1]. Everything is based around context, and to not be aware of how it factors in to the current expression often leads to befuddlement (at best) or anger. On the flip side, context is often where Perl shines. I recommend Chromatic's excellent Modern Perl: The Book[1] if you feel any of this might apply to you.
Finally, Perl can be a very Lispy language. Avoiding those parts (map, grep, etc) is sort of like consciously avoiding every even gear when driving a car. Possible, but much more painful than using it as designed.
Edit: Oh, you probably want that reference I implied up above.
1: http://modernperlbooks.com/books/modern_perl_2014/ covers context in multiple sections.
The alternative to v5 is Inline::Perl5[1], which instead of defining a mode that understands Perl 5 syntax and maps it to the underlying Perl 6 runtime, actually embeds a Perl 5 interpreter and handles all the back and forth automatically. The benefit of this approach is that XS modules still work (you can use Per 5's DBI in Perl 6 using Perl 6 syntax).
1: https://github.com/niner/Inline-Perl5
1: https://github.com/niner/Inline-Perl5
> With perl6's grammar support, some folks are working on importing the perl5 grammar into perl6[0].
If someone just wants to run Perl 5 code, especially from CPAN, Inline::Perl5 is the answer, not v5.
If someone just wants to run Perl 5 code, especially from CPAN, Inline::Perl5 is the answer, not v5.
> But the damage has been done @ this point -- a lot of the community has wandered off
Do you think the Perl community should have tried to slow down or reverse the exodus?
Do you think the Perl community should have tried to slow down or reverse the exodus?
Perl 6 is like Python 3, but they decided early on that if it wasn't going to be backwards compatible they might as well go wild with enhancements and fixes to earlier mistakes. As such, while Perl 6 is seen as a successor to Perl 5, it doesn't obsolete Perl 5. There's still plenty of active development and new features happening in Perl 5 (after a lull in development, likely because of Perl 6).
It's widely accepted at this point that the name could and would have been better off as something else, like Perl NG (there is good reason to want to retain some Perl mindshare, it is very related at a language level) or something, but by the point that was realized the damage was done. People still argue over whether they should change it to clear this issue up for the layman, but there are good reasons to not want to give up the long past associated with the Perl 6 name.
It's becoming slightly less important now that Perl 6 can now inline a lot of Perl 5 code and modules (including modules with compiled code)[1].
1: https://github.com/niner/Inline-Perl5
It's widely accepted at this point that the name could and would have been better off as something else, like Perl NG (there is good reason to want to retain some Perl mindshare, it is very related at a language level) or something, but by the point that was realized the damage was done. People still argue over whether they should change it to clear this issue up for the layman, but there are good reasons to not want to give up the long past associated with the Perl 6 name.
It's becoming slightly less important now that Perl 6 can now inline a lot of Perl 5 code and modules (including modules with compiled code)[1].
1: https://github.com/niner/Inline-Perl5
An old but informative article on Perl 6: http://www.perl.com/pub/2006/01/12/what_is_perl_6.html
And a brief blurb from the Perl 6 FAQ that helps explain it a bit:
> Perl 6 is still a very perlish language, following the same underlying ideas as previous versions (sigils for mini-namespaces, There Is More Than One Way To Do It, caring about both manipulexity and whipuptitude, taking many ideas from natural language (like disambiguation through context))
> Perl 6 code feels very perlish. A Perl 5 program using Moose or a similar object system feels closer to Perl 6 than to Perl 1 code
> "Perl" is still a strong brand name, which we don't want to throw away lightly
> It is very hard to find a good alternative name. And no, "camelia" and "rakudo" are not good names for a programming language (even if they are fine for our mascot and the leading compiler)
> Even if Perl 6 changed its name, an incremental update to Perl 5 likely couldn't claim the version 6, because the name Perl 6 sticks in people's head, and will long be associated with what it is today
And a brief blurb from the Perl 6 FAQ that helps explain it a bit:
> Perl 6 is still a very perlish language, following the same underlying ideas as previous versions (sigils for mini-namespaces, There Is More Than One Way To Do It, caring about both manipulexity and whipuptitude, taking many ideas from natural language (like disambiguation through context))
> Perl 6 code feels very perlish. A Perl 5 program using Moose or a similar object system feels closer to Perl 6 than to Perl 1 code
> "Perl" is still a strong brand name, which we don't want to throw away lightly
> It is very hard to find a good alternative name. And no, "camelia" and "rakudo" are not good names for a programming language (even if they are fine for our mascot and the leading compiler)
> Even if Perl 6 changed its name, an incremental update to Perl 5 likely couldn't claim the version 6, because the name Perl 6 sticks in people's head, and will long be associated with what it is today
Are you talking about changing $foo[0] to @foo[0] ?
"Try 0.1 + 0.2 == 0.3 in some other language, then try it in Perl 6."
Whoa, wtf python:
Whoa, wtf python:
$ python
Python 3.4.3 (default, Jul 13 2015, 12:18:23)
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 0.1 + 0.2 == 0.3
False
>>>Why is this surprising? Floats are defined by the hardware essentially, not the language.
And this is how they work: they're binary, not decimal. Computers are binary, not decimal. 0.1 can't be represented exactly as binary.
Python has a decimal type, if that's what you want: https://docs.python.org/2/library/decimal.html
I consider it a basic point of computer literacy to understand this.
And this is how they work: they're binary, not decimal. Computers are binary, not decimal. 0.1 can't be represented exactly as binary.
Python has a decimal type, if that's what you want: https://docs.python.org/2/library/decimal.html
I consider it a basic point of computer literacy to understand this.
>>Why is this surprising?
Because it goes against intuition?
The whole point of a higher level language is an abstraction over these kind of problems anyway.
Because it goes against intuition?
The whole point of a higher level language is an abstraction over these kind of problems anyway.
Like I said, cue the sophomoric replies about IEEE floating point number representation.
> I consider it a basic point of computer literacy to understand this.
Which statement does, by itself, a pretty good job of explaining why nobody even bothers to ask themselves if they are computer literate these days.
Which statement does, by itself, a pretty good job of explaining why nobody even bothers to ask themselves if they are computer literate these days.
While defaulting to floats for rational numbers may be the default for many languages, it is by no means the only way to store them, which is why we're talking about them. In Perl 6 they are often stored as a numerator and denominator within the Rat type, and converted for display.
For example...
Welcome to DrRacket, version 6.2 [3m].
Language: racket; memory limit: 128 MB.
> (= (+ 0.1 0.2) 0.3)
#f
> (= (+ 1/10 2/10) 3/10)
#tHow come a LISP allows you to write 1/10 instead of (/ 1 10)? Is it a special case for entering fractions, or does Racket allow arbitrary arithmetic expressions with infix operators?
1/10 is a literal. It denotes the value one tenth. The expression (/ 1 10) will at runtime calculate 1 divided by 10.
Most programming languages have syntax for writing all available numbers as literals.
Racket do not have builtin syntax for infix arithmetic - but there are various packages available for infix expressions.
Most programming languages have syntax for writing all available numbers as literals.
Racket do not have builtin syntax for infix arithmetic - but there are various packages available for infix expressions.
Do you know if there was ever any public discussion about whether to represent decimal fractions (0.1 etc.) as an exact rational or inexact float?
Take a look that the rrrs mailing list archive.
Thanks!
Looks like bingo with my first search (a google for 'rrrs mailing list rational fraction float'):
https://groups.csail.mit.edu/mac/ftpdir/scheme-mail/HTML/rrr...
I've loved lisp's power since I first encountered it in the early 80s and also admired the great care put in to various aspects of Common Lisp (which is mentioned as the foundation for scheme's number decisions). Great stuff and still very relevant.
:)
Looks like bingo with my first search (a google for 'rrrs mailing list rational fraction float'):
https://groups.csail.mit.edu/mac/ftpdir/scheme-mail/HTML/rrr...
I've loved lisp's power since I first encountered it in the early 80s and also admired the great care put in to various aspects of Common Lisp (which is mentioned as the foundation for scheme's number decisions). Great stuff and still very relevant.
:)
> I consider it a basic point of computer literacy to understand this.
Yes, but just because fractional notation defaults to a floating point representation in most languages does not mean that the option of defaulting to decimal/rational notation at the language level should be ruled out generally.
Yes, but just because fractional notation defaults to a floating point representation in most languages does not mean that the option of defaulting to decimal/rational notation at the language level should be ruled out generally.
> Floats are defined by the hardware essentially, not the language.
Floats are storage formats for approximations of numbers.
Floats are, by definition, not relevant if one wants to store an exact number exactly.
> 0.1 can't be represented exactly as binary.
1 can be represented exactly as binary.
And so can 10.
And thus 1 (numerator) divided by 10 (denominator) can be represented by two (binary -- or any-other-ary-for-that-matter) numbers.
This isn't about (just) decimals. The same thing applies to non-decimal fractions like 1/3 or 56,123 / 7329.
Some languages prefer to store exact representations of rational numbers. Perl 6 is by no means the first.
Floats are storage formats for approximations of numbers.
Floats are, by definition, not relevant if one wants to store an exact number exactly.
> 0.1 can't be represented exactly as binary.
1 can be represented exactly as binary.
And so can 10.
And thus 1 (numerator) divided by 10 (denominator) can be represented by two (binary -- or any-other-ary-for-that-matter) numbers.
This isn't about (just) decimals. The same thing applies to non-decimal fractions like 1/3 or 56,123 / 7329.
Some languages prefer to store exact representations of rational numbers. Perl 6 is by no means the first.
> Floats are storage formats for approximations of numbers. Floats are, by definition, not relevant if one wants to store an exact number exactly.
Floats can store integer values exactly up to an upper limit (2^24 IIRC), which is often useful. And they can store binary fractions exactly up to a point.
No number representation can represent all numbers exactly. Each can store some subset of all numbers exactly.
Floats can store integer values exactly up to an upper limit (2^24 IIRC), which is often useful. And they can store binary fractions exactly up to a point.
No number representation can represent all numbers exactly. Each can store some subset of all numbers exactly.
Fwiw I can't tell if you're being pedantic for fun or not. I'm going to stick with fun...
> Floats can store integer values exactly up to an upper limit (2^24 IIRC)
You're right, for relatively small integers of 8 digits or so.
Here's a fun place to note that on the machine I just tried the Rakudo Perl 6 compiler will happily exactly store integers with hundreds of thousands of digits.
> which is often useful.
As in you've written such code in dozens of programs?
> And [floats] can store binary fractions exactly up to a point.
0.1 is already "past" that point which is even less impressive than 8 digit integers.
> No number representation can represent all numbers exactly. Each can store some subset of all numbers exactly.
Well duh. No computer can compute all computable things. Each can compute some things. My machine became unhappy when I asked it to store a number that would require a terabyte of RAM. Are these sorts of thing really worth mentioning when the starting point is just 0.1 + 0.2 == 0.3?
> Floats can store integer values exactly up to an upper limit (2^24 IIRC)
You're right, for relatively small integers of 8 digits or so.
Here's a fun place to note that on the machine I just tried the Rakudo Perl 6 compiler will happily exactly store integers with hundreds of thousands of digits.
> which is often useful.
As in you've written such code in dozens of programs?
> And [floats] can store binary fractions exactly up to a point.
0.1 is already "past" that point which is even less impressive than 8 digit integers.
> No number representation can represent all numbers exactly. Each can store some subset of all numbers exactly.
Well duh. No computer can compute all computable things. Each can compute some things. My machine became unhappy when I asked it to store a number that would require a terabyte of RAM. Are these sorts of thing really worth mentioning when the starting point is just 0.1 + 0.2 == 0.3?
> You're right, for relatively small integers of 8 digits or so.
For doubles (more common than floats) it is up to 2^53, which is quite a usable range.
> As in you've written such code in dozens of programs?
As in every JavaScript program ever written that uses a for loop and integer indices does this.
> 0.1 is already "past" that point which is even less impressive than 8 digit integers.
0.1 is not a binary fraction. A binary fraction can be expressed in the form a/2^b for some a and b.
Decimal representations have the same limitation (can only express decimal fractions), it just seems more exact because we write numbers in decimal.
> Are these sorts of thing really worth mentioning when the starting point is just 0.1 + 0.2 == 0.3?
It's worth mentioning when you say untrue things like "Floats are, by definition, not relevant if one wants to store an exact number exactly." Double precision floating point has more exact integer range than int32.
For doubles (more common than floats) it is up to 2^53, which is quite a usable range.
> As in you've written such code in dozens of programs?
As in every JavaScript program ever written that uses a for loop and integer indices does this.
> 0.1 is already "past" that point which is even less impressive than 8 digit integers.
0.1 is not a binary fraction. A binary fraction can be expressed in the form a/2^b for some a and b.
Decimal representations have the same limitation (can only express decimal fractions), it just seems more exact because we write numbers in decimal.
> Are these sorts of thing really worth mentioning when the starting point is just 0.1 + 0.2 == 0.3?
It's worth mentioning when you say untrue things like "Floats are, by definition, not relevant if one wants to store an exact number exactly." Double precision floating point has more exact integer range than int32.
I think you guys are arguing at cross-purposes. I'm not sure anyone is arguing that an integer is better than a double for integer representation, but that storing a pair of numeric values (whether they be integers or floating point of some type) allows for more natural expression of numeric values in a high level language, with more fidelity.
> > Floats are, by definition, not relevant if one wants to store an exact number exactly.
> Floats can store integer values exactly up to an upper limit (2^24 IIRC), which is often useful. And they can store binary fractions exactly up to a point.
If you have some knowledge about the number you are storing, such as that it is an integer, then you can use the fact that floats can represent integers exactly to large values. If you need a general purpose numeric type of which you can't assume it's an integer, and it needs to be stored exactly, then I think it's valid to say that floating point numbers are not relevant, at least not as the entirely of the underlying storage container.
> No number representation can represent all numbers exactly. Each can store some subset of all numbers exactly.
Yes. So we are talking about storage mechanisms that allow for more fidelity than plain floats and doubles can achieve.
> > Floats are, by definition, not relevant if one wants to store an exact number exactly.
> Floats can store integer values exactly up to an upper limit (2^24 IIRC), which is often useful. And they can store binary fractions exactly up to a point.
If you have some knowledge about the number you are storing, such as that it is an integer, then you can use the fact that floats can represent integers exactly to large values. If you need a general purpose numeric type of which you can't assume it's an integer, and it needs to be stored exactly, then I think it's valid to say that floating point numbers are not relevant, at least not as the entirely of the underlying storage container.
> No number representation can represent all numbers exactly. Each can store some subset of all numbers exactly.
Yes. So we are talking about storage mechanisms that allow for more fidelity than plain floats and doubles can achieve.
If you search back to the comment that started this subthread you'll find it began:
"Try 0.1 + 0.2 == 0.3 in some other language, then try it in Perl 6."
Do you agree with all of the next sentence or not? Please start with a plain yes or no before getting in to details.
The three individual literal decimal numbers shown above are not integers, they're not binary fractions, they're not floats, they are rational numbers, they are exact numbers, they are easily stored exactly on a computer, and whether or not they are stored exactly on a computer is a choice made by a programming language.
"Try 0.1 + 0.2 == 0.3 in some other language, then try it in Perl 6."
Do you agree with all of the next sentence or not? Please start with a plain yes or no before getting in to details.
The three individual literal decimal numbers shown above are not integers, they're not binary fractions, they're not floats, they are rational numbers, they are exact numbers, they are easily stored exactly on a computer, and whether or not they are stored exactly on a computer is a choice made by a programming language.
No, because I think that "easily stored on a computer" is too vague and reductive.
I apologize if I have been too unclear about my point. My point is that your position is unfair. Your position seems to be that rational arithmetic is an obvious choice that other languages have been too lazy or stupid to adopt as their default. My point is that rational arithmetic is a fine choice for many things, but it is not a strict improvement over other number representations. Yes it can handle 0.1 + 0.2 = 0.3, but your implied conclusion that it is an obvious "default" choice is not accurate. It is not as perfect, and floating point is not as bad, as you seem to think.
Yes, doubles have lots of values they can't represent perfectly, but so do rationals. Like sqrt(2), sin(1), pi, or any calculations involving numbers like these.
Yes rationals can represent lots of numbers perfectly, but if you're keeping everything exact these can start to take lots of memory. Some slides I found about Perl 6 indicate that Rat values lose precision if the denominator gets too big, to avoid using too much memory. If this is true, the Rat type shouldn't be thought of as an "exact" type any more than double -- it could cease to be exact even if you stay away from inherently non-rational number like I listed above.
What I'm disagreeing with overall is the dichotomy you are trying to create of: double=approximate, Perl 6 number=exact. Neither of those are really very true. There are cases where double is exact and cases where Perl 6 is not exact.
I apologize if I have been too unclear about my point. My point is that your position is unfair. Your position seems to be that rational arithmetic is an obvious choice that other languages have been too lazy or stupid to adopt as their default. My point is that rational arithmetic is a fine choice for many things, but it is not a strict improvement over other number representations. Yes it can handle 0.1 + 0.2 = 0.3, but your implied conclusion that it is an obvious "default" choice is not accurate. It is not as perfect, and floating point is not as bad, as you seem to think.
Yes, doubles have lots of values they can't represent perfectly, but so do rationals. Like sqrt(2), sin(1), pi, or any calculations involving numbers like these.
Yes rationals can represent lots of numbers perfectly, but if you're keeping everything exact these can start to take lots of memory. Some slides I found about Perl 6 indicate that Rat values lose precision if the denominator gets too big, to avoid using too much memory. If this is true, the Rat type shouldn't be thought of as an "exact" type any more than double -- it could cease to be exact even if you stay away from inherently non-rational number like I listed above.
What I'm disagreeing with overall is the dichotomy you are trying to create of: double=approximate, Perl 6 number=exact. Neither of those are really very true. There are cases where double is exact and cases where Perl 6 is not exact.
> "easily stored on a computer" is too vague and reductive.
Fwiw, from the compiler source code:
Yes. Rational storage and rational arithmetic is an obvious choice for storing and processing rational numbers. (Alongside the other obvious choice -- using floats.)
> other languages have been too lazy or stupid
I'm extolling what I consider a minor Perl 6 virtue. Where have I been negative toward other languages?
> rational arithmetic is a fine choice for ...
... doing rational arithmetic.
> it is not a strict improvement over other number representations.
For representing Integers? Sure. Irrationals? Agreed. Complex numbers? Gotchya. Number crunching where absolute exactness is not necessary? Use floats.
But if exactness is required and a formula only involves rational numbers (and integers) then rational storage and processing is a strict improvement over use of floats.
> [rationals are] not as perfect, and floating point is not as bad, as you seem to think.
When did I suggest floats are bad? The general number type in Perl 6 is a float. Floats are awesome! But floats are by design not exact for arbitrary rational numbers. Their awesomeness derives directly from them being inexact in this way.
When did I suggest storing rationals is perfect? They use up more memory than floats and processing can become pathologically slow if the denominators get big enough. This problem derives directly from them being exact.
> doubles have lots of values they can't represent perfectly, but so do rationals. Like sqrt(2), sin(1), pi
Those are explicitly defined in mathematics as numbers that are not rational. Rational storage and arithmetic is for representing and processing numbers that are rational!
One can't exactly store an irrational number. The Perl 6 compiler defines a constant for the irrational number `pi`:
> Some slides I found about Perl 6 indicate that Rat values lose precision if the denominator gets too big, to avoid using too much memory.
The numerator of a default rational (a non-parameterized Rat) can be arbitrarily large but if the denominator exceeds 64 bits (20 decimal digits) then the compiler converts the number to a float.
If you don't like that then you can use a rational with a larger denominator, with the extreme being a FatRat that has an arbitrary sized denominator as well as arbitrary sized numerator.
> If this is true, the Rat type shouldn't be thought of as an "exact" type any more than double
I think that view misses something very important. This is indeed where the discussion could get interesting. We shall see. It seems we needed to get past a lot of misunderstanding first.
> What I'm disagreeing with overall is the dichotomy you are trying to create of: double=approximate, Perl 6 number=exact.
I've never said that. What I have said is that, for storing and processing rational numbers, doubles are approximate (and they are); that it's possible to be exact instead (and it is); and that Perl 6 returns True for the expression `0.1 + 0.2 == 0.3` because by default it processes rationals as exact rationals.
> There are cases where double is exact
Not for rational numbers (I'm ignoring silly examples like 1/1 and others that happen to work out because the denominator and numerators are powers of two or whatever).
> and cases where Perl 6 is not exact.
Not for rational numbers, if you choose to have them be exact.
Fwiw, from the compiler source code:
my role Rational[::NuT, ::DeT] does Real {
has NuT $.numerator;
has DeT $.denominator;
Yes. Rational storage and rational arithmetic is an obvious choice for storing and processing rational numbers. (Alongside the other obvious choice -- using floats.)
> other languages have been too lazy or stupid
I'm extolling what I consider a minor Perl 6 virtue. Where have I been negative toward other languages?
> rational arithmetic is a fine choice for ...
... doing rational arithmetic.
> it is not a strict improvement over other number representations.
For representing Integers? Sure. Irrationals? Agreed. Complex numbers? Gotchya. Number crunching where absolute exactness is not necessary? Use floats.
But if exactness is required and a formula only involves rational numbers (and integers) then rational storage and processing is a strict improvement over use of floats.
> [rationals are] not as perfect, and floating point is not as bad, as you seem to think.
When did I suggest floats are bad? The general number type in Perl 6 is a float. Floats are awesome! But floats are by design not exact for arbitrary rational numbers. Their awesomeness derives directly from them being inexact in this way.
When did I suggest storing rationals is perfect? They use up more memory than floats and processing can become pathologically slow if the denominators get big enough. This problem derives directly from them being exact.
> doubles have lots of values they can't represent perfectly, but so do rationals. Like sqrt(2), sin(1), pi
Those are explicitly defined in mathematics as numbers that are not rational. Rational storage and arithmetic is for representing and processing numbers that are rational!
One can't exactly store an irrational number. The Perl 6 compiler defines a constant for the irrational number `pi`:
my constant pi = 3.14159_26535_89793_238e0;
> Some slides I found about Perl 6 indicate that Rat values lose precision if the denominator gets too big, to avoid using too much memory.
The numerator of a default rational (a non-parameterized Rat) can be arbitrarily large but if the denominator exceeds 64 bits (20 decimal digits) then the compiler converts the number to a float.
If you don't like that then you can use a rational with a larger denominator, with the extreme being a FatRat that has an arbitrary sized denominator as well as arbitrary sized numerator.
> If this is true, the Rat type shouldn't be thought of as an "exact" type any more than double
I think that view misses something very important. This is indeed where the discussion could get interesting. We shall see. It seems we needed to get past a lot of misunderstanding first.
> What I'm disagreeing with overall is the dichotomy you are trying to create of: double=approximate, Perl 6 number=exact.
I've never said that. What I have said is that, for storing and processing rational numbers, doubles are approximate (and they are); that it's possible to be exact instead (and it is); and that Perl 6 returns True for the expression `0.1 + 0.2 == 0.3` because by default it processes rationals as exact rationals.
> There are cases where double is exact
Not for rational numbers (I'm ignoring silly examples like 1/1 and others that happen to work out because the denominator and numerators are powers of two or whatever).
> and cases where Perl 6 is not exact.
Not for rational numbers, if you choose to have them be exact.
This all started when you said:
> Floats are storage formats for approximations of numbers. Floats are, by definition, not relevant if one wants to store an exact number exactly.
This is setting up a dichotomy of float=approximate, and the implied contrast is that Perl 6 rationals are exact.
Float is "by definition, not relevant if one wants to store an exact number exactly."
You didn't say "an exact rational," you said "an exact number." Your implication is that other representations are relevant if one wants to store an exact number exactly. You don't say rational, so you imply that other representations can represent an arbitrary number exactly.
If you try to advertise Perl 6 as "exact", in comparison to those messy floats, you're going to get people who are very unhappy when they find out that 2pi / 2 isn't exactly pi.
And you're also shortchanging people who use eg. JavaScript doubles as exact integer indices every day. X/1 isn't a "silly" case, integers are extremely relevant across all kinds of calculations.
People who want to truly understand this landscape need to understand the contrasts between various number representations and the pros and cons of each. No representation can represent every real number perfectly, so everyone is going to run up against inexactness in their calculations unless they know how to restrict the domain of their calculations to numbers that can be perfectly represented with their chosen number representation.
> Floats are storage formats for approximations of numbers. Floats are, by definition, not relevant if one wants to store an exact number exactly.
This is setting up a dichotomy of float=approximate, and the implied contrast is that Perl 6 rationals are exact.
Float is "by definition, not relevant if one wants to store an exact number exactly."
You didn't say "an exact rational," you said "an exact number." Your implication is that other representations are relevant if one wants to store an exact number exactly. You don't say rational, so you imply that other representations can represent an arbitrary number exactly.
If you try to advertise Perl 6 as "exact", in comparison to those messy floats, you're going to get people who are very unhappy when they find out that 2pi / 2 isn't exactly pi.
And you're also shortchanging people who use eg. JavaScript doubles as exact integer indices every day. X/1 isn't a "silly" case, integers are extremely relevant across all kinds of calculations.
People who want to truly understand this landscape need to understand the contrasts between various number representations and the pros and cons of each. No representation can represent every real number perfectly, so everyone is going to run up against inexactness in their calculations unless they know how to restrict the domain of their calculations to numbers that can be perfectly represented with their chosen number representation.
> You didn't say "an exact rational," you said "an exact number."
You were right the first time you said that. You're still right. I immediately said as much in my first response to you. I don't understand what more you could want. :<
I do know what I want. I would like you to acknowledge that you are basically ignoring the direct context of my commentary, namely chubot's "0.1 can't be represented exactly [using a computer]" and natch's "wtf" about `0.1 + 0.2 == 0.3`.)
> If you try to advertise Perl 6 as "exact"
That would be absurd.
> integers are extremely relevant across all kinds of calculations.
In the context of discussing rational storage and arithmetic, integers seem to me to be primarily relevant to the extent one is talking of numerators and denominators and primarily irrelevant to the extent one is talking about floats. Do you disagree?
> People who want to truly understand this landscape need to understand the contrasts between various number representations and the pros and cons of each.
Sure.
But one has to start somewhere within a confusing landscape and try not to get lost by paying attention to details that don't yet matter. In this case natch started with the issue of exact rational calculation, chubot's wording suggested that rationals couldn't ever be stored accurately on a computer, and I tried to get floats out of the conversation until we'd cleared that confusion up. But you immediately took issue with me omitting a qualification that I thought obvious from context ("rationals"), then followed that by ignoring (afaict) my acknowledgement of your correction, and then we ended up here, with disappointingly little light shone on the very issue we both find interesting. :<
Perhaps our exchange was entirely futile. Who knows? And maybe we'll meet again and do better. Here's hoping. :)
You were right the first time you said that. You're still right. I immediately said as much in my first response to you. I don't understand what more you could want. :<
I do know what I want. I would like you to acknowledge that you are basically ignoring the direct context of my commentary, namely chubot's "0.1 can't be represented exactly [using a computer]" and natch's "wtf" about `0.1 + 0.2 == 0.3`.)
> If you try to advertise Perl 6 as "exact"
That would be absurd.
> integers are extremely relevant across all kinds of calculations.
In the context of discussing rational storage and arithmetic, integers seem to me to be primarily relevant to the extent one is talking of numerators and denominators and primarily irrelevant to the extent one is talking about floats. Do you disagree?
> People who want to truly understand this landscape need to understand the contrasts between various number representations and the pros and cons of each.
Sure.
But one has to start somewhere within a confusing landscape and try not to get lost by paying attention to details that don't yet matter. In this case natch started with the issue of exact rational calculation, chubot's wording suggested that rationals couldn't ever be stored accurately on a computer, and I tried to get floats out of the conversation until we'd cleared that confusion up. But you immediately took issue with me omitting a qualification that I thought obvious from context ("rationals"), then followed that by ignoring (afaict) my acknowledgement of your correction, and then we ended up here, with disappointingly little light shone on the very issue we both find interesting. :<
Perhaps our exchange was entirely futile. Who knows? And maybe we'll meet again and do better. Here's hoping. :)
Floating point hardware storing integers is useful indeed. Look up JavaScript.
A language storing big numbers in non-native formats, like your Rakudo example, is irrelevant to the parent's point.
0.1 isn't past any "point" (whatever that means). It just isn't representable without recurrence in base 2 much like 1/3 isn't in base 10.
Your post could do without 'duh' and the like as well.
A language storing big numbers in non-native formats, like your Rakudo example, is irrelevant to the parent's point.
0.1 isn't past any "point" (whatever that means). It just isn't representable without recurrence in base 2 much like 1/3 isn't in base 10.
Your post could do without 'duh' and the like as well.
> A language storing big numbers in non-native formats, like your Rakudo example, is irrelevant to the parent's point.
I thought being able to store an up to 8 digit integer in a float was an interesting tidbit. I already knew it but others might not. However, it was also completely irrelevant to a discussion of why 0.1 + 0.2 equals 0.3 in Perl 6 and, imo, even to my (slight over) emphasis that a float is for (efficient) storage and processing of approximations, not exact numbers.
> 0.1 isn't past any "point" (whatever that means).
Precisely. I was directly responding to "And [floats] can store binary fractions exactly up to a point." What does that mean? "up to a point" is highly ambiguous. The fact that 0.1 isn't stored exactly is completely unambiguous.
> It just isn't representable without recurrence in base 2 much like 1/3 isn't in base 10.
So what? It is representable without recurrence in a pair of base 2 numbers, eg 1 (numerator) and 11 (denominator) for 1/3.
> Your post could do without 'duh'
OK. I considered that and thought it was OK, all things considered, given that it wasn't prominent and succinctly expressed my reaction. But I hear you that even such a gentle 'duh' is problematic and will be even more careful about how I express myself at HN in future.
> and the like as well.
Would you be willing to be specific? While I recognize the 'duh' is edgy, I've reread the rest of what I wrote and don't understand what you think I got wrong.
I thought being able to store an up to 8 digit integer in a float was an interesting tidbit. I already knew it but others might not. However, it was also completely irrelevant to a discussion of why 0.1 + 0.2 equals 0.3 in Perl 6 and, imo, even to my (slight over) emphasis that a float is for (efficient) storage and processing of approximations, not exact numbers.
> 0.1 isn't past any "point" (whatever that means).
Precisely. I was directly responding to "And [floats] can store binary fractions exactly up to a point." What does that mean? "up to a point" is highly ambiguous. The fact that 0.1 isn't stored exactly is completely unambiguous.
> It just isn't representable without recurrence in base 2 much like 1/3 isn't in base 10.
So what? It is representable without recurrence in a pair of base 2 numbers, eg 1 (numerator) and 11 (denominator) for 1/3.
> Your post could do without 'duh'
OK. I considered that and thought it was OK, all things considered, given that it wasn't prominent and succinctly expressed my reaction. But I hear you that even such a gentle 'duh' is problematic and will be even more careful about how I express myself at HN in future.
> and the like as well.
Would you be willing to be specific? While I recognize the 'duh' is edgy, I've reread the rest of what I wrote and don't understand what you think I got wrong.
That decimal literals represent binary floating point numbers is defined by the language, not the hardware.
I consider it a basic point of language design literacy that exact decimal literals without some other indicators should not represent an inexact type that isn't designed to represent decimal data.
Infuriatingly, very few languages get that right. But perl 6 isn't unique in doing so; Scheme had been doing it right for decades.
I consider it a basic point of language design literacy that exact decimal literals without some other indicators should not represent an inexact type that isn't designed to represent decimal data.
Infuriatingly, very few languages get that right. But perl 6 isn't unique in doing so; Scheme had been doing it right for decades.
(Actually, Scheme doesn't quite get this right: decimals are inexact by default and only rationals expressed as divisions of integers are exact, though it is less cumbersome to specify an exact decimal than in most popular language -- its a literal modifier, not a function call.)
e.g.:
e.g.:
0.2
#e0.2
The use of an annotative '#e' to get an exact number contrasts with Perl 6's choices for the default interpretation of number literals. The Perl 6 choice adopts scientific notation to correspond to floats:
200000000000000000000 # exact (integer) 2 * 10 ** 20
0.00000000000000000002 # exact (rational) 2 * 10 ** -20
0.2e-19 # inexact (float) 2 * 10 ** -20
2e20 # inexact (float) 2 * 10 ** 20People have also very often been freaked out by
You might get what you want from
>>> 1/2
0
>>> 2/3
0
You might get what you want from
>>> import decimal
>>> decimal.Decimal('0.1') + decimal.Decimal('0.2') == decimal.Decimal('0.3')
True
It's great that this is available (haven't worked through it yet).
Two major show-stoppers for me right now though:
* In the Perl 6 repl, I can't use my up/down arrows, or ^p/^n to get at previous lines I typed, nor ^a/^e and alt-B/alt-F to navigate on the line.
* In the repl, I can't do `doc(some-func)` to get at docstrings.
Two major show-stoppers for me right now though:
* In the Perl 6 repl, I can't use my up/down arrows, or ^p/^n to get at previous lines I typed, nor ^a/^e and alt-B/alt-F to navigate on the line.
* In the repl, I can't do `doc(some-func)` to get at docstrings.
> In the Perl 6 repl, I can't use my up/down arrows, or ^p/^n to get at previous lines I typed, nor ^a/^e and alt-B/alt-F to navigate on the line.
Really? In they version I have access to arrow keys and ^p/^n/^a/^e all function.
I've just been informed that what you need is "panda install Linenoise" to install the Linenoise module to get this functionality.
I agree documentation in the language would be nice. A module could handle that nicely.
Really? In they version I have access to arrow keys and ^p/^n/^a/^e all function.
I've just been informed that what you need is "panda install Linenoise" to install the Linenoise module to get this functionality.
I agree documentation in the language would be nice. A module could handle that nicely.
I think this kind of stuff should be available out of the box. I'm learning Perl 6 too, Inability to use the arrow keys has almost left the REPL unusable to me.
I'm just writing programs in proper files and executing them.
I'm just writing programs in proper files and executing them.
I agree. Maybe rakudobrew should have a target that hits install, panda and p6doc and that being the default for new setups.
FYI, you can install p6doc with "panda install p6doc", which is the Perl 6 equivalent of perldoc. I don't believe it has in-language methods yet, but I imagine it wouldn't be that hard. For now, it's a CLI tool.
FYI, you can install p6doc with "panda install p6doc", which is the Perl 6 equivalent of perldoc. I don't believe it has in-language methods yet, but I imagine it wouldn't be that hard. For now, it's a CLI tool.
# p6doc Str.tclc
routine tclc
multi sub tclc(Str:D ) returns Str:D multi method tclc(Str:D:)
returns Str:D
Turns the first character to title case, and all other characters to lower case
(not implemented in Niecza)Thanks. Tried installing but got errors.
==> Fetching p6doc
==> Building p6doc
==> Testing p6doc
# Failed test 'empty blocks argument gives undefined content'
# at t/pod-convenience.t line 31
# Looks like you failed 1 test of 7
# Failed test 'pod-with-title'
# at t/pod-convenience.t line 23
t/pod-convenience.t ..
Failed 2/10 subtests
t/pod-htmlify.t ...... ok
Method 'super' not found for invocant of class 'Array'
in sub visit at /home/me/.panda-work/1441386381_4/lib/Perl6/TypeGraph.pm:89
in sub visit at /home/me/.panda-work/1441386381_4/lib/Perl6/TypeGraph.pm:89
in method topo-sort at /home/me/.panda-work/1441386381_4/lib/Perl6/TypeGraph.pm:92
in method parse-from-file at /home/me/.panda-work/1441386381_4/lib/Perl6/TypeGraph.pm:82
in method new-from-file at /home/me/.panda-work/1441386381_4/lib/Perl6/TypeGraph.pm:30
in block <unit> at t/typegraph.t:8
t/typegraph.t ........
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 8/8 subtests
$ perl6 -v
This is perl6 version 2015.07.1-728-g9c5cb50 built on
MoarVM version 2015.07-108-g7e9f29eThat's odd. I just built Perl 6, panda and installed p6doc right before that comment. I didn't use rakudobrew for the Perl 6 install though (git clone + Configure, make, make install), and I have a slightly different version.
You aren't still running the glr branch are you? Method 'super' not found for invocant of class 'Array' sounds to me suspiciously like a bug in that work-in-progress branch, as glr stands for Great List Refactor and the error has to do with Array. If so, you might have better luck with building the moar backed version with rakudobrew.
Edit: Sorry, just noticed where you said you built with moar. I'll try to replicate on my end and see what I get.
You aren't still running the glr branch are you? Method 'super' not found for invocant of class 'Array' sounds to me suspiciously like a bug in that work-in-progress branch, as glr stands for Great List Refactor and the error has to do with Array. If so, you might have better luck with building the moar backed version with rakudobrew.
Edit: Sorry, just noticed where you said you built with moar. I'll try to replicate on my end and see what I get.
This is likely a regression from the glr branch being merged into the main branch this morning. Hopefully any issues with the Perl 6 ecosystem will we worked out shortly. Actually, in the IRC channel[1], I see some module authors already making commits to adapt to the changes.
1: If you just want to lurk, or catch up on a past day, you can view the log at http://irclog.perlgeek.de/perl6/today
1: If you just want to lurk, or catch up on a past day, you can view the log at http://irclog.perlgeek.de/perl6/today
Hmm.
I'm using my account on the Perl 6 community dev server hack.p6c.org.
I used rakudobrew to rebuild rakudo last night:
This is perl6 version 2015.07.1-215-ge6f3602 built on MoarVM version 2015.07-108-g7e9f29e
I just ran `panda install p6doc` and it worked fine for me.
What do you get when you run `perl6 -e '$*DISTRO.say'?
Investigating...
I'm using my account on the Perl 6 community dev server hack.p6c.org.
I used rakudobrew to rebuild rakudo last night:
This is perl6 version 2015.07.1-215-ge6f3602 built on MoarVM version 2015.07-108-g7e9f29e
I just ran `panda install p6doc` and it worked fine for me.
What do you get when you run `perl6 -e '$*DISTRO.say'?
Investigating...
This is on Debian Testing:
$ perl6 -e '$*DISTRO.say'
debian (3.16.0.4.amd.64)
I rebuilt everything... and p6doc failed to build.
It turns out that the glr branch got merged about 5 hours ago (about the time you started commenting). I'm posting this now, before I catch up with the irc backlog, to give you a heads up, but I'd expect p6doc to be working again within a few days at the outside and quite likely by the end of today. (In the meantime you can use the web version at http://doc.perl6.org.)
It turns out that the glr branch got merged about 5 hours ago (about the time you started commenting). I'm posting this now, before I catch up with the irc backlog, to give you a heads up, but I'd expect p6doc to be working again within a few days at the outside and quite likely by the end of today. (In the meantime you can use the web version at http://doc.perl6.org.)
> In the Perl 6 repl, I can't use my up/down arrows, or ^p/^n to get at previous lines I typed, nor ^a/^e and alt-B/alt-F to navigate on the line.
Try:
Try:
panda install Linenoise
I installed via rakudobrew (`rakudobrew build glr`), but have no `panda` in my ~/.rakudobrew/bin directory.
Ah. glr is 1) a very recent in-development branch that 2) only includes the compiler so 3) panda (the module installer) isn't included and 4) it may not work even if you download and manually install a copy of it.
You might want to visit the freenode IRC channel #perl6 to straighten things out.[1] In the meantime I'm going to install the glr branch and see what I find. It might be a few hours (at most a day I think) before I can get back to you.
[1] https://kiwiirc.com/client/irc.freenode.net/#perl6
You might want to visit the freenode IRC channel #perl6 to straighten things out.[1] In the meantime I'm going to install the glr branch and see what I find. It might be a few hours (at most a day I think) before I can get back to you.
[1] https://kiwiirc.com/client/irc.freenode.net/#perl6
Ok. Command-line history/editing works now. I wiped out ~/.rakudobrew and started over:
rakudobrew build moar
rakudobrew build-panda
panda install Linenoise
If you type rakudobrew by itself, the usage shows it is capable of a "rakudobrew build-panda" which is probably a good place to start. Panda is the Perl 6 package manager, in case that wasn't clear.
Thanks, kbenson; missed that. Works now!
[deleted]
stopped reading on slide 7. What do you think this does:
say 1.WHAT;
integer?
yes. Maybe it's more reasonable than I thought (or I gave more information than reasonable - I've now removed some.)
I don't think "say 1.WHAT" is reasonable syntax in the slightest.
I don't think "say 1.WHAT" is reasonable syntax in the slightest.
Well, "1.WHAT.say" is also available.
But Perl 6 is designed to put code smells in capital letters. EVAL, for example. WHAT shouldn't be used in normal code, but it's useful as a teaching tool or for debugging. If you want to test if something is an integer, you'll want "1 ~~ Int" instead.
But Perl 6 is designed to put code smells in capital letters. EVAL, for example. WHAT shouldn't be used in normal code, but it's useful as a teaching tool or for debugging. If you want to test if something is an integer, you'll want "1 ~~ Int" instead.
Let me get this straight - the first example in the tutorial is code that you shouldn't write. Got it.
By the way guys, string concatenation isn't . or + or a comma or something. It's a tilde: ~
'a' ~ 'b' to get 'ab'.
Because it looks like a "piece of string" ... that ties ... strings together, apparently.
By the way guys, string concatenation isn't . or + or a comma or something. It's a tilde: ~
'a' ~ 'b' to get 'ab'.
Because it looks like a "piece of string" ... that ties ... strings together, apparently.
> Let me get this straight - the first example in the tutorial is code that you shouldn't write. Got it.
If you read a little farther you might have seen this: Note: .VAR and .WHAT are code smells. They’re useful to understand the language and debug, but testing against what they return is nearly always the wrong approach.
> Because it looks like a "piece of string" ... that ties ... strings together, apparently.
You're mistaking a mnemonic for the reasoning. The reasoning is most likely because using a period for string concatenation is likely to cause problems when it's also used for method calls and strings can have methods, and when methods can be quotes. E.g. "foo"."chars"(), which might be useful with string interpolation.
As for why it's not +, that's covered as well. Perl takes the stance that operators should be different for different operation types. What does foo + bar mean in python? You need to know the types of foo and bar to know that. In Perl 5 and Perl 6, you know whether you are adding numeric types or concatenating (not adding) strings.
It's easy to assume no thought went into the development[1], but it's been very well thought out and been baking for a very long time. They spent that time actually testing their ideas, and making changes when reality didn't match expectations.
1: for that matter, a lot of people think that about Perl 5, which is untrue, it just has different design goals than many languages
If you read a little farther you might have seen this: Note: .VAR and .WHAT are code smells. They’re useful to understand the language and debug, but testing against what they return is nearly always the wrong approach.
> Because it looks like a "piece of string" ... that ties ... strings together, apparently.
You're mistaking a mnemonic for the reasoning. The reasoning is most likely because using a period for string concatenation is likely to cause problems when it's also used for method calls and strings can have methods, and when methods can be quotes. E.g. "foo"."chars"(), which might be useful with string interpolation.
As for why it's not +, that's covered as well. Perl takes the stance that operators should be different for different operation types. What does foo + bar mean in python? You need to know the types of foo and bar to know that. In Perl 5 and Perl 6, you know whether you are adding numeric types or concatenating (not adding) strings.
It's easy to assume no thought went into the development[1], but it's been very well thought out and been baking for a very long time. They spent that time actually testing their ideas, and making changes when reality didn't match expectations.
1: for that matter, a lot of people think that about Perl 5, which is untrue, it just has different design goals than many languages
I have two trite one-liners about perl(5) in comparison and to other languages these days.
1. Python helps you think more like the computer does. Perl helps the computer think more like you.
2. Modern Perl is C# for hippies.
1. Python helps you think more like the computer does. Perl helps the computer think more like you.
2. Modern Perl is C# for hippies.
Have you seen https://www.youtube.com/watch?v=JpqnNCx7wVY?
Yeah because we can't possibly have languages which diverge in syntax... I mean I don't use any languages every day where the concat operator is || for example which is short circuit OR for most people. cough PgSQL cough
JavaScript overloading + to mean addition and string concatenation was the worst decision ever given the use case of JS. 1 + '1' * 1 is not the same as '1' + 1 * 1 good job. That definitely wont be evil once the values are in a more complex equation with variables coming from some server side JSON string... at all. Definitely wont lead to any unusual bugs when something like the following happens 1 + '000001'. You might not notice 2 being 12 for a while but your customer will likely notice 2 suddenly becoming 1000001.
At least '~' joins two different string together when writing. Makes a lot more sense than '+' to me ~ Ulti 2015
JavaScript overloading + to mean addition and string concatenation was the worst decision ever given the use case of JS. 1 + '1' * 1 is not the same as '1' + 1 * 1 good job. That definitely wont be evil once the values are in a more complex equation with variables coming from some server side JSON string... at all. Definitely wont lead to any unusual bugs when something like the following happens 1 + '000001'. You might not notice 2 being 12 for a while but your customer will likely notice 2 suddenly becoming 1000001.
At least '~' joins two different string together when writing. Makes a lot more sense than '+' to me ~ Ulti 2015
That's because . is a method call, + is addition, and comma is a list separator. Which of those would you give up? So yes, the ~ is a little unique to Perl6, but at least they were thoughtful enough to pick something with more than one easy mnemonic.
I guarantee you, most people new to the language would be much more put-off by keeping perl5's -> for method calls. Perl lost that battle, it's over. They're making the best of it.
Also, any language with a self-reflective object system is going to show that off to beginners to help them explore, even if it wouldn't be used in production code much. That's like complaining about a language tutorial showing off the REPL to start out, even though you don't use it in production code.
I guarantee you, most people new to the language would be much more put-off by keeping perl5's -> for method calls. Perl lost that battle, it's over. They're making the best of it.
Also, any language with a self-reflective object system is going to show that off to beginners to help them explore, even if it wouldn't be used in production code much. That's like complaining about a language tutorial showing off the REPL to start out, even though you don't use it in production code.
Getting the type of a value is useful to beginners and belongs in a tutorial. The one time I tried Perl 6 was a few weeks ago, and it took a while to find out how to do this exact thing.
But Perl is unityped so I don't think it'd be useful there. :V
That's gotta be a joke but I'm missing it -- can you spare a hint?
The article you've linked is about unityped languages. Perl 6 is not unityped.
To quote the conclusion of the article you linked:
> Why should you care? Because, I argue, that a fully expressive language is one that supports the delicate interplay between static and dynamic techniques. Languages that force only one perspective on you ... hobble you; languages that admit both modes of reasoning enable you and liberate you from the tyranny of a single type.
It would seem he ought to love Perl 6.
"Getting beyond static vs dynamic" may be of interest:
* HN discussion https://news.ycombinator.com/item?id=9089259
* Youtube: https://www.youtube.com/watch?v=id4pDstMu1s
To quote the conclusion of the article you linked:
> Why should you care? Because, I argue, that a fully expressive language is one that supports the delicate interplay between static and dynamic techniques. Languages that force only one perspective on you ... hobble you; languages that admit both modes of reasoning enable you and liberate you from the tyranny of a single type.
It would seem he ought to love Perl 6.
"Getting beyond static vs dynamic" may be of interest:
* HN discussion https://news.ycombinator.com/item?id=9089259
* Youtube: https://www.youtube.com/watch?v=id4pDstMu1s
the use of + for string concatenation is not exactly compelling either, since string concatenation, unlike addition, is not commutative
> I don't think "say 1.WHAT" is reasonable syntax in the slightest.
The syntax is basically the same as Ruby or Python:
The syntax is basically the same as Ruby or Python:
# Ruby:
puts 1.class
# Python:
print 1L.__type__
yes, class and __type__ seem very reasonable keywords to me, a yelling WHAT does not. the syntax is the same, except the choice of WHAT. I guess I'm the only one who considers it hopelessly odd. if "object1.class == object2.class" seems like something you might think of. But "object1.WHAT == object2.WHAT" is something that wouldn't occur to me in a million years, and makes me laugh even now that I've written it. I suppose you might disagree.
__type__ I can understand, but .class seems likely to conflict in those cases where you want a method named class. __class__ seems more consistent to me.
In Perl 6, special meta method built-ins are always all caps, specifically because it's not a very reasonable name to choose in most cases, similarly to how python surrounds a name with double underscores. They are special and different, and should appear as such.
> But "object1.WHAT == object2.WHAT" is something that wouldn't occur to me in a million years
Well, that's good,because you aren't really supposed to be doing that. Rather than getting upset at how Perl 6 looks weird when you map operations directly to how you would do them in another language, it might be better to see if that case actually comes up at all. Maybe the language has other features that support different, possibly better, idioms (or at least better for that language)?
Just because Perl 6 and Python are both dynamic languages and have some features doesn't mean you should assume it functions or should be programmed in the same way. I doubt you would make that mistake for something that looked obviously different, like racket, so why jump to those conclusions here just because they look similar in certain aspects.
In Perl 6, special meta method built-ins are always all caps, specifically because it's not a very reasonable name to choose in most cases, similarly to how python surrounds a name with double underscores. They are special and different, and should appear as such.
> But "object1.WHAT == object2.WHAT" is something that wouldn't occur to me in a million years
Well, that's good,because you aren't really supposed to be doing that. Rather than getting upset at how Perl 6 looks weird when you map operations directly to how you would do them in another language, it might be better to see if that case actually comes up at all. Maybe the language has other features that support different, possibly better, idioms (or at least better for that language)?
Just because Perl 6 and Python are both dynamic languages and have some features doesn't mean you should assume it functions or should be programmed in the same way. I doubt you would make that mistake for something that looked obviously different, like racket, so why jump to those conclusions here just because they look similar in certain aspects.
class and __type__ are no keywords here. They are just the names chosen for those attributes/methods.
I was just pointing out that what you considered unreasonable syntax was actually pretty common syntax. That the function/method names could be better, I agree. But that's an entirely different matter.
I was just pointing out that what you considered unreasonable syntax was actually pretty common syntax. That the function/method names could be better, I agree. But that's an entirely different matter.
> That the function/method names could be better, I agree.
Are you referring to python's choices, ruby's, Perl 6's, or all of them? If you think .WHAT could be better, is it the all caps you dislike or is it use of the word 'what' or both? What would you suggest instead?
Are you referring to python's choices, ruby's, Perl 6's, or all of them? If you think .WHAT could be better, is it the all caps you dislike or is it use of the word 'what' or both? What would you suggest instead?
to epidemian, yes, it's what I was referring to, sorry I wasn't more clear.
raiph: we're talking about perl 6's two choices for the things you've brought up, that it's in all-caps and that it consists of the contextually nonsense word 'what'.
The word "what" is one of the most common English words - so the opposite of a better, explicit choice, like type, class, classtype, etc - and doesn't even mean "what-is" if you read it out loud. 3.WHAT doesn't sound like "What 3 is" - it sounds like "3 - I didn't hear you" or if you're being very generous it means "What is 3?" (asking for its value).
You asked what I would suggest? If you want to be really cute and grammatical while sounding like a natural language, here is a suggestion. Instead of WHAT my suggestion is the word STYPE, and read it as though the preceding word had an apostrophe at the end: 3.STYPE, thiswindow.STYPE and so forth. (3's type, thiswindow's type, etc). anyway you asked for a suggesiton, there you have it. I woudn't use it myself though.
raiph: we're talking about perl 6's two choices for the things you've brought up, that it's in all-caps and that it consists of the contextually nonsense word 'what'.
The word "what" is one of the most common English words - so the opposite of a better, explicit choice, like type, class, classtype, etc - and doesn't even mean "what-is" if you read it out loud. 3.WHAT doesn't sound like "What 3 is" - it sounds like "3 - I didn't hear you" or if you're being very generous it means "What is 3?" (asking for its value).
You asked what I would suggest? If you want to be really cute and grammatical while sounding like a natural language, here is a suggestion. Instead of WHAT my suggestion is the word STYPE, and read it as though the preceding word had an apostrophe at the end: 3.STYPE, thiswindow.STYPE and so forth. (3's type, thiswindow's type, etc). anyway you asked for a suggesiton, there you have it. I woudn't use it myself though.
> the contextually nonsense word 'what'.
I don't buy that it's contextually nonsense. I suspect you had a bad reaction to it and have gotten caught up in that initial reaction. I could be wrong about that but your stated perspective is noticeably extreme and unique about a relatively tiny point.
> if you're being very generous it means "What is 3?" (asking for its value).
I don't think that's being especially generous. But yes, please be generous. :)
I don't think it's asking for its value.
What is Belgium? (Country) What is HN? (Time Sink) What is `4 -3i` ? (Complex Number). What is $age? (Int)
If you want a value you just write something like:
Well I intended my comment for epidemian, but OK. :)
> If you want to be really cute
Perl 6 explicitly incorporates fun but also explicitly avoids "you think that's cute today" mistakes.
I like the choice of names for the pseudo method mop macros: what, which, where, who, why, how, etc. But that's partly because: I find them easy to remember as a group; I found them easy to understand once I'd encountered them once; and I've not seen anyone react negatively to any of them the way you have.
----
Anyhoo, I hope you won't let your dislike for the rarely used .WHAT et al to unduly color your view of Perl 6. I don't expect the tutorial that's the topic of this HN to impress anyone but that's because it deliberately sticks to absolute basics. Instead, I urge you to wait until next year, and then take another look; I think you'll see there's a lot to like.
I don't buy that it's contextually nonsense. I suspect you had a bad reaction to it and have gotten caught up in that initial reaction. I could be wrong about that but your stated perspective is noticeably extreme and unique about a relatively tiny point.
> if you're being very generous it means "What is 3?" (asking for its value).
I don't think that's being especially generous. But yes, please be generous. :)
I don't think it's asking for its value.
What is Belgium? (Country) What is HN? (Time Sink) What is `4 -3i` ? (Complex Number). What is $age? (Int)
If you want a value you just write something like:
say 3; # 3
say $age; # 55
Well I intended my comment for epidemian, but OK. :)
> If you want to be really cute
Perl 6 explicitly incorporates fun but also explicitly avoids "you think that's cute today" mistakes.
I like the choice of names for the pseudo method mop macros: what, which, where, who, why, how, etc. But that's partly because: I find them easy to remember as a group; I found them easy to understand once I'd encountered them once; and I've not seen anyone react negatively to any of them the way you have.
----
Anyhoo, I hope you won't let your dislike for the rarely used .WHAT et al to unduly color your view of Perl 6. I don't expect the tutorial that's the topic of this HN to impress anyone but that's because it deliberately sticks to absolute basics. Instead, I urge you to wait until next year, and then take another look; I think you'll see there's a lot to like.
I'm sorry, but that seems somewhat arbitrary to me. When I want to know what an object is, it's very obvious to use .WHAT after you've been exposed to it in my opinion.
# perl6 -e 'class Person { has $!initials }; my $p = Person.new( :initials<KAB> ); say $p.WHAT' (Person)
As for why all capitals, you can just as easily ask Python why double underscores. In the end, it's all language convention (explained here[1]). Denigrating something just because it's different is not a position I think has merit. If down the line we discover that these were bad choices, at least then there will hopefully be some evidence to point to.
> The word "what" is one of the most common English words - so the opposite of a better, explicit choice, like type, class, classtype, etc - and doesn't even mean "what-is" if you read it out loud. 3.WHAT doesn't sound like "What 3 is" - it sounds like "3 - I didn't hear you" or if you're being very generous it means "What is 3?" (asking for its value).
If you think WHAT in a programming language is likely to be interpreted as "What? I didn't hear you." then I submit that you are using libraries with very poorly named cutesy methods that the author should have really known better than to use if it ends up in in production. Given the context of a programming language, when would you ever need to call a built in metamethod (because it's all caps...) that meant "I didn't hear you" ?
Even when "what" is used in the context of "I didn't hear you" it actually is asking for information (to be repeated), and the "I didn't hear you" is the implicit part (otherwise why would you ask for the same thing be said again?).
1: http://doc.perl6.org/language/mop#Metamethods
# perl6 -e 'class Person { has $!initials }; my $p = Person.new( :initials<KAB> ); say $p.WHAT' (Person)
As for why all capitals, you can just as easily ask Python why double underscores. In the end, it's all language convention (explained here[1]). Denigrating something just because it's different is not a position I think has merit. If down the line we discover that these were bad choices, at least then there will hopefully be some evidence to point to.
> The word "what" is one of the most common English words - so the opposite of a better, explicit choice, like type, class, classtype, etc - and doesn't even mean "what-is" if you read it out loud. 3.WHAT doesn't sound like "What 3 is" - it sounds like "3 - I didn't hear you" or if you're being very generous it means "What is 3?" (asking for its value).
If you think WHAT in a programming language is likely to be interpreted as "What? I didn't hear you." then I submit that you are using libraries with very poorly named cutesy methods that the author should have really known better than to use if it ends up in in production. Given the context of a programming language, when would you ever need to call a built in metamethod (because it's all caps...) that meant "I didn't hear you" ?
Even when "what" is used in the context of "I didn't hear you" it actually is asking for information (to be repeated), and the "I didn't hear you" is the implicit part (otherwise why would you ask for the same thing be said again?).
1: http://doc.perl6.org/language/mop#Metamethods
I was referring to Perl's choice, and yes, mostly because of the all caps. Python's choice i also find quite distasteful, but i understand that users are supposed to use type(thing) instead of thing.__type__, which is usually the case with these magic methods.
I personally prefer Ruby's stance of making built-in methods look like normal user-defined ones (no special double underscore or all caps convention or anything like that). But this is a small quibble; i wouldn't ditch an entire language for such a minor thing (i've used Perl and regularly use Python and have found both to be quite pleasant languages to use :)
I personally prefer Ruby's stance of making built-in methods look like normal user-defined ones (no special double underscore or all caps convention or anything like that). But this is a small quibble; i wouldn't ditch an entire language for such a minor thing (i've used Perl and regularly use Python and have found both to be quite pleasant languages to use :)
[deleted]
> I don't think "say 1.WHAT" is reasonable syntax in the slightest.
1 is an integer. In Perl 6 integers are objects and have methods. The method calls are distinguished by periods, as has become the most common way to call methods in programming languages.
Is your main complaint that it just looks weird? Is there something you would expect it to be other than a method on an integer or numeric type? Personally, while yes, it does look somewhat weird, the uniformity of knowing you can call .WHAT on anything is nice.
You get one guess as to what 1.23.WHAT does.
1 is an integer. In Perl 6 integers are objects and have methods. The method calls are distinguished by periods, as has become the most common way to call methods in programming languages.
Is your main complaint that it just looks weird? Is there something you would expect it to be other than a method on an integer or numeric type? Personally, while yes, it does look somewhat weird, the uniformity of knowing you can call .WHAT on anything is nice.
You get one guess as to what 1.23.WHAT does.
hi - my complaint was over the choice of specifically the word WHAT (and not a different word), and in capitals.
I also don't think the addition of a more mainstream object system is a positive thing, but that's a debate for another time.
Edit: And it's not just about sigils, but about changing things for no meaningful reason, especially things that set Perl apart and make it what it is.