8 ms·

Why Perl 6 is different

152 points by fogus 17y ago

prog 17y ago
I use Python as my primary scripting language but I spent some time looking at Perl 6 in the context of Parrot and it really has a lot of good ideas that post mentions: - multi-methods - rules (builtin parsing capability) - macros - and a whole bunch of other good stuff. I really made me want to use Perl6 and Parrot. That said the only reason I couldn't what perhaps the same reason I use Python over Perl5. I somehow couldn't get myself to go with such a _rich_ syntax. But if Perl5 is your thing then Perl6 is something that you will definitely like.
- stcredzero 17y ago
  The industry as a whole errs too much on the side of syntax as the focus of the community. Syntax should fade out of the way. It should be infrastructure, not features. Libraries are the proper object of focus. Libraries can be modified, forked, debugged without dividing a language community. Doing that to a programming language syntax weakens and divides such communities. In contrast, those actions on libraries actually strengthen programming language communities.
  - torial 17y ago
    While I agree in general thrust with your focus on infrastructure -- one may argue that a lot of improvements of ignoring language have occurred. .Net allows for multiple languages on a single infrastructure, I believe Java VM does as well, and there is Parrot too. I do think that there is a healthy focus on syntax -- at least my own experience bears it out. It was the syntax of doing things the python way that allowed me to grok polymorphism and MVC despite programming in an OO language for .Net for years. I find that if I want to learn a concept, the syntax is extremely helpful. I also find that if I have to program quickly, syntax being close to how I think is also helpful, and will get frustrated having to make yet another translation of my thought into a syntax that wasn't well thought out. I would also bet that a lot of people find a different syntax to intuitive, and others counter-intuitive than I do. And I'm fine w/ that! Just because there is difference doesn't mean there has to be division!
  - loup-vaillant 17y ago
    Syntax has two problems: (1) it is the most visible thing in programming languages, and (2) there is only one per language. I believe we should be able to modify, fork, or debug syntax the same way we do libraries. So what about a syntax meant to be read by computer instead of by humans? # Factorial example, machine syntax fac -> int int \ 0 -> 1 n -> * n - n 1 It could be displayed in human readable form by an IDE or converted back and forth by suitable preprocessors: -- Factorial example, Haskell syntax fac :: int -> int fac 0 = 1 fac n = n * fac (n - 1) // Factorial example, C syntax int fac(int 0) { return 1; } int fac(int n) { return n * fac(n - 1); } No more quibbling over prefix vs infix, curly braces vs indentation, familiarity vs terseness… That would take a flame war away from language design and put it where it belongs: the IDE.
    - jimbokun 17y ago
      I'm pretty sure the C example will not compile with a C compiler. Which may seem like a nit, but the reason is because the semantics of Haskell and C are extremely different. Furthermore, the semantics strongly influence the design of the language. In Haskell, whitespace denotes function application, because the most common thing to do in Haskell is to apply a function. C has semicolon delimited statements, because imperatively executing statements one after the other is a very common thing to do in C programs. In Haskell, you cannot guarantee the exact order in which things happen without going to great lengths (monads, etc.). In short, I don't think offering a skinnable syntax buys much, and is likely to just generate greater confusion.
      - eru 17y ago
        > C has semicolon delimited statements, because imperatively executing statements one after the other is a very common thing to do in C programs. Actually that would be an argument for making newlines delimit statements, like in, say, Python. Instead of requiring extra work by the programmer.
        pyre 17y ago
  - arohner 17y ago
    Libraries are heavily influenced by the semantics of the language they're written in / designed for. It's quite easy to see this in the Clojure community today, by Java libraries are good from the clojure perspective. The goodness of a java library has little to do with syntax (because clojure can easily call any java library), but semantics. For instance, java commonly uses mutable state. A fundamental principle of Clojure is that data should be immutable. Immutability makes testing easier, it makes parallelization easier. Clojure was built to make pmap easy. If I have a java library where I have to remember that Foos are thread-safe, but Bars are not, that adds to the incidental complexity of my solution, and reduces my ability to bring Clojure's new tools to bear on the problem. As another commenter pointed out, syntax of a language is heavily influenced by the semantics of the language. A language starts with a few high level principles, and a favorite hammer or two. The syntax of the language is designed around making those common operations easy. Libraries written in that language will tend to follow those same principles. Having Java libraries available to Clojure is a huge advantage, but it's not the be-all end-all, because the semantics of those libraries may be incompatible with your new language. Instead, focus on semantics. Figure out which high level principles are good. What abstractions and design principles result in better, easier to understand solutions? From that follows your libraries and syntax.
- draegtun 17y ago
  And Perl5 already has some of those features: * multi-methods - There are two implementations on CPAN, Class::Multimethods (old) and MooseX::MultiMethods * rules - Ditto. Perl6::Rules (old) and Regexp::Grammars * macros - Have a look at Devel::Declare. Not Perl6 macros but still powerful stuff! * and a whole bunch of other good stuff - Lots have been backported to Perl5 (direct and into CPAN). For eg. smart match, given/when, Perl6::Junction, Perl6::Gather and also things like Moose & Class::MOP which are heavily influenced by Perl6
  - avar 17y ago
    For some value of "already": * multi-methods: MooseX::MultiMethods and MooseX::Method::Signatures add a lot of overhead to subroutine calls (blogged in http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/02/moosexmethodsignatures-is-really-slow.html http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/02/...). Sometimes this doesn't matter, but they're certainly not a replacement for having a native type system. All the magic is done at runtime. * rules: Perl6::Rules and Regexp::Grammars are both depended on by a grand total of 0 CPAN modules. They're interesting experiments but not something in use, and not a replacement of rules with its "your regex opcodes are a normal method" model. * macros: Devel::Declare and the B::* modules are usable but they're a long way away from the Lisp model of being able to easily write macros. TryCatch is 800 lines of Perl and C to implement try { ... } catch { ...}. In any Lisp this would be trivially done with a macro in under 50 lines. As for the other stuff pretty much anything except smart match (which is now in Perl 5 core), Class::MOP and Moose falls under the "neat but some combination of: underused, slow, unstable, epic hack nobody wants to use".
    - autarch 17y ago
      Huh, Moose is underused? There a lot of modules on CPAN using Moose, and a lot of modules extending Moose. Also, in what way is Moose unstable? Moose, and modules which use Moose, are used in production at a lot of places (if you use a recent Catalyst, you're using Moose). Edit: doh, totally misread the OP's sentence.
      - 17y ago
fogus 17y ago
I may have missed the point, but it seems to me that the gist of the post is, "Perl 6 is different because it's the same as Lisp".
- draegtun 17y ago
  Larry Wall himself said that: Perl 6 is Lisp with a decent syntax, and minus a lot of assumptions about how lists should be represented :) ref: http://irclog.perlgeek.de/perl6/2010-01-15#i_1905210 http://irclog.perlgeek.de/perl6/2010-01-15#i_1905210 He then goes onto to mention that despite all the trappings of OO, Perl 6 is fundamentally more in the FP camp
  - njharman 17y ago
    LWall > Lisp with a decent syntax I'm no Lisp guru, not even proficient but isn't saying that kind of missing a large point of Lisp in that code is data and data is a list/sexpresion or what ever it's called?
    - flogic 17y ago
      I think the point is "with rules you don't need everything to be and s-expression". I don't know how much to agree or not with that point. Currently I'm of the we'll see where is goes point of view.
      - rbanffy 17y ago
        > "with rules you don't need everything to be and s-expression" I am unsure if I would call it a feature.
        flogic 17y ago
        From a Perl point of view, I think it's the right way to go. There are a few "standard" tricks to simulate extending Perl5, but they often feel hackish. From my understanding this will be more flexible and explicit. I don't have the Lisp experience to compare the two. My guess is Lisp macros will still be more flexible but the gap will be significantly narrowed.
AndrewO 17y ago
It has been said that Ruby is Smalltalk with a perly syntax. Perl6 extends on that: Perl 6 is Lisp with a perly syntax. Interesting idea, but I would have loved to see some examples or comparisons. For all of the mindshare that Perl has, I haven't seen much content (especially code) about Perl 6 over the last couple of years.
- draegtun 17y ago
  Here are some links showing recent Perl6 content/code: * Perl6 advent calendar: http://perl6advent.wordpress.com/ http://perl6advent.wordpress.com/ * Moritz Lenz perl6 blog: http://perlgeek.de/blog-en/perl-6/ http://perlgeek.de/blog-en/perl-6/ * Carl Masak perl* blog & github projects: http://use.perl.org/~masak/journal/ http://use.perl.org/~masak/journal/ http://github.com/masak http://github.com/masak * Perl6 planet: http://planetsix.perl.org/ http://planetsix.perl.org/ * Perl6 book: http://github.com/perl6/book http://github.com/perl6/book * Perl6 examples: http://github.com/perl6/perl6-examples http://github.com/perl6/perl6-examples
  - AndrewO 17y ago
    Thanks—I'll check those out!
    - deleted 17y ago
      [deleted]
    - draegtun 17y ago
      You're very welcome. This link may also be of interest: http://transfixedbutnotdead.com/2010/01/14/anyone-for-perl-6-metaprogramming/ http://transfixedbutnotdead.com/2010/01/14/anyone-for-perl-6... From the links in the post you can find Perl5, Ruby, Javascript and Python comparative examples. Been playing a bit with Io (http://www.iolanguage.com/ http://www.iolanguage.com/) recently so was planning to add a comparative post for that as well. Update: I just copied over my Io example i had brewing into a gist (http://gist.github.com/372559 http://gist.github.com/372559)
  - perlgeek 17y ago
jerf 17y ago
There's a presentation that Larry Wall gave at Google that has a lot to do with the internals of Perl 6: http://www.youtube.com/watch?v=JzIWdJVP-wo http://www.youtube.com/watch?v=JzIWdJVP-wo Actually, to be honest, I don't recommend it, I found it surprisingly dull in delivery (sorry, Larry), but the contents were very interesting. I actually think describing Perl 6 as "having macros" is accurate, but gives the wrong impression. It doesn't "have" macros, it's made of macros. The whole language is made of macros and you are nearly begged to extend it with more grammar. Or you can throw theirs away and write your own for something. Or you can throw theirs away, take some of it as a base, and extend it. It's a wild, wacky experiment that needs to be done. Whatever happens, we'll learn a lot. My intuition says "collapses under its own complexity" (especially after trying to add a few grammar-modifying CPAN modules) is the most likely result, but I fully support with no sarcasm someone trying this out in case my intuition is wrong. It's not just Lisp redux, it's something new.
- dkarl 17y ago
  especially after trying to add a few grammar-modifying CPAN modules How do modules compose with respect to syntax? I remember encountering a big frustration in Common Lisp when I used two libraries that depended on defining '[' as a reader macro for pretty syntax. Whichever library I allowed to use the '[' reader macro, my usage of the other library became verbose and hard to read. Not to mention that neither altering a module's source nor depending on the sequence of module loading is scalable across many modules.
  - riffraff 17y ago
    they are lexically scoped, so as a non expert, I guess they are closer to scheme than to CL
- gaius 17y ago
  The whole language is made of macros and you are nearly begged to extend it with more grammar. Or you can throw theirs away and write your own for something. Or you can throw theirs away, take some of it as a base, and extend it. And people wonder why Perl is known as a "write-only" language!
thyrsus 17y ago
My understanding is that Perl 6 is the polar opposite of lisp, in this sense: In lisp, the code is always and everywhere already in a parse tree, and can be manipulated easily by, e.g., macros; Perl 5, on the other hand, is the most unparsable language possible: see http://www.perlmonks.org/?node_id=663393 http://www.perlmonks.org/?node_id=663393. What perl 6 does is own the parsing problem, and respond by incorporating super powerful parsing tools. Unfortunately, I believe that perl 6 retains its dynamic syntax, so parsing of perl 6 itself is still an uncertain adventure, and not something one can incorporate unconstrained into one's metaprogramming. I'd love to be wrong about that; am I? If so, can someone recommend a tutorial on perl 6 metaprogramming?
- Shorel 17y ago
  Well, I'm just learning Perl (work related) and it certainly feels like they tried to include a lot of ready-to-use lisp-like macros in an otherwise traditional syntax when inventing Perl. And Perl 5.12 has this jewel in its changelog: New experimental APIs allow developers to extend Perl with "pluggable" keywords and syntax.
  - draegtun 17y ago
    With Perl 5.12 comes a working test example already using the pluggable feature: http://search.cpan.org/dist/perl/ext/XS-APItest-KeywordRPN/KeywordRPN.pm http://search.cpan.org/dist/perl/ext/XS-APItest-KeywordRPN/K... Here is the code example from the docs: use XS::APItest::KeywordRPN qw(rpn calcrpn); $triangle = rpn($n $n 1 + * 2 /); calcrpn $triangle { $n $n 1 + * 2 / }
  - mst 17y ago
    Which is already doable from CPAN using Devel::Declare, hence Method::Signatures::Simple, Sub::Curried, MooseX::Method::Signatures etc. The stuff in core is, however, way, way more elegant than the way Devel::Declare currently does it - which was rather the point, Devel::Declare was "retrofit to existing perl5 VMs what will hopefully be core later".
- megaman821 17y ago
jpablo 17y ago
It thankfully steals nothing from PHP I love this quote.
pg 17y ago
I don't know anything about Perl 6 (or much about earlier versions for that matter). Can someone explain how close it has gotten to Lisp? What macro facilities does it have? Can you munge the syntax tree after code is parsed?
- jules 17y ago
  Very close from what I gather from the web. It has macros similar to Lisp. They take an AST and return an AST. http://perlcabal.org/syn/S06.html#Macros http://perlcabal.org/syn/S06.html#Macros Do you think that Lisp style languages with sexps are the end in language design, or do you think that something better will be invented? (or has been invented)
  - pg 17y ago
    I would never say never, but I haven't been able to think of a better way to represent programs than s-expressions despite many years of thinking about the problem. I wouldn't be surprised if sexprs are the end in the sense that the integers are. I.e. you might go on to discover new things but they'd ultimately reduce to sexprs. Is there a textual representation for ASTs? Could you write programs directly in ASTs?
    - jules 17y ago
      To your question: yes, the Perl syntax (the macro system supports quasiquotation). This is exactly the same as in Lisp. The difference is that Lisp syntax looks more like how the data structures are represented in memory. I think you can also build up your programs with data constructors (i.e. like doing (list 'lambda (list 'x) (list '+ 'x 1)) in Lisp). But note that I haven't used Perl6, this is information from the web.
    - jey 17y ago
      "AST" is actually just compiler lingo for "tree representation of s-expr representation of parsed code". In other words: sure, you can write code directly in {ASTs, s-exprs}; it's called "Lisp". ;-)
- 17y ago
rjurney 17y ago
I love Perl. I am most fluent in Perl. I can hack things together in Perl using CPAN modules without pausing, without thinking, and I am most efficient using it. I am happiest hacking Perl at 3AM. I hate whats happened to Perl because Perl 6 has taken so long to ship. Perl 5 is outdated. Moose helps, but its gotten so bad for so long that I can't code in Perl and collaborate with anyone. I write clean Perl, but it doesn't matter - everyone else moved on years ago and disdains it. So I hack Ruby, Python, etc. because I have to. I hope Perl 6 changes that. Is it ready to use?
- bad_user 17y ago
  No, but this is a good time to play with it ... Rakudo Star should be released in the next 2-3 weeks or so. Problem with Perl 6 was that it's too ground-breaking, without having the resources of a huge company (like Sun, MS). But it doesn't matter because you can't find the combination of features it provides in other languages ... * full OOP * optional typing * multi-dispatch * macros * cool pattern matching * functional features ... map, fold are at home ;) * continuations / coroutines * transactional memory * eventually it will be compatible with every package on CPAN Personally I don't like Perl (either 5 or 6), I'm more interested in Parrot because what is widely viewed today as being general-purpose VMs (the JVM / .NET) are a poor choice for dynamic languages. Consider that the JVM and .NET are stack-based. Because of that efficient continuations passing style is impossible on top, and that's a PITA because you can build any control structure on top ... tail-calls, closures, coroutines, exceptions, green threads ... can all be implemented efficiently in terms of CPS. Another thing against the JVM / .NET is that they'll never earn optimizations for dynamic languages that could impact the performance of first-class citizens. You can forget about an efficient tracing-compiler on top of those, simply because such optimizations are not cheap and can impact the performance of Java / C#, and those VMs are not low-level enough to implement it at a higher level. And for instance, personally I'm skeptic that InvokeDynamic on the JVM will deliver that much performance. Yeah, it provides a mechanism for a monomorphic inline cache, and from there the JVM can do stuff like code-inlining of call-sites. But it doesn't do tracing of types, which means that code like the following ... sum = 0 for i in range(1000): sum += i will always pay for the price of boxing/unboxing of those primitives, an optimization that current Javascript VMs and LuaJIT 2 are doing. So if Parrot delivers, it will be one heck of an alternative. Either way, its interface is nice and you can use it right now for prototyping new languages.

152 points by fogus 17y ago

prog 17y ago

I use Python as my primary scripting language but I spent some time looking at Perl 6 in the context of Parrot and it really has a lot of good ideas that post mentions: - multi-methods - rules (builtin parsing capability) - macros - and a whole bunch of other good stuff. I really made me want to use Perl6 and Parrot. That said the only reason I couldn't what perhaps the same reason I use Python over Perl5. I somehow couldn't get myself to go with such a _rich_ syntax. But if Perl5 is your thing then Perl6 is something that you will definitely like.

stcredzero 17y ago
The industry as a whole errs too much on the side of syntax as the focus of the community. Syntax should fade out of the way. It should be infrastructure, not features. Libraries are the proper object of focus. Libraries can be modified, forked, debugged without dividing a language community. Doing that to a programming language syntax weakens and divides such communities. In contrast, those actions on libraries actually strengthen programming language communities.
- torial 17y ago
  While I agree in general thrust with your focus on infrastructure -- one may argue that a lot of improvements of ignoring language have occurred. .Net allows for multiple languages on a single infrastructure, I believe Java VM does as well, and there is Parrot too. I do think that there is a healthy focus on syntax -- at least my own experience bears it out. It was the syntax of doing things the python way that allowed me to grok polymorphism and MVC despite programming in an OO language for .Net for years. I find that if I want to learn a concept, the syntax is extremely helpful. I also find that if I have to program quickly, syntax being close to how I think is also helpful, and will get frustrated having to make yet another translation of my thought into a syntax that wasn't well thought out. I would also bet that a lot of people find a different syntax to intuitive, and others counter-intuitive than I do. And I'm fine w/ that! Just because there is difference doesn't mean there has to be division!
- loup-vaillant 17y ago
  Syntax has two problems: (1) it is the most visible thing in programming languages, and (2) there is only one per language. I believe we should be able to modify, fork, or debug syntax the same way we do libraries. So what about a syntax meant to be read by computer instead of by humans? # Factorial example, machine syntax fac -> int int \ 0 -> 1 n -> * n - n 1 It could be displayed in human readable form by an IDE or converted back and forth by suitable preprocessors: -- Factorial example, Haskell syntax fac :: int -> int fac 0 = 1 fac n = n * fac (n - 1) // Factorial example, C syntax int fac(int 0) { return 1; } int fac(int n) { return n * fac(n - 1); } No more quibbling over prefix vs infix, curly braces vs indentation, familiarity vs terseness… That would take a flame war away from language design and put it where it belongs: the IDE.
  - jimbokun 17y ago
    I'm pretty sure the C example will not compile with a C compiler. Which may seem like a nit, but the reason is because the semantics of Haskell and C are extremely different. Furthermore, the semantics strongly influence the design of the language. In Haskell, whitespace denotes function application, because the most common thing to do in Haskell is to apply a function. C has semicolon delimited statements, because imperatively executing statements one after the other is a very common thing to do in C programs. In Haskell, you cannot guarantee the exact order in which things happen without going to great lengths (monads, etc.). In short, I don't think offering a skinnable syntax buys much, and is likely to just generate greater confusion.
    - eru 17y ago
      > C has semicolon delimited statements, because imperatively executing statements one after the other is a very common thing to do in C programs. Actually that would be an argument for making newlines delimit statements, like in, say, Python. Instead of requiring extra work by the programmer.
      - pyre 17y ago
- arohner 17y ago
  Libraries are heavily influenced by the semantics of the language they're written in / designed for. It's quite easy to see this in the Clojure community today, by Java libraries are good from the clojure perspective. The goodness of a java library has little to do with syntax (because clojure can easily call any java library), but semantics. For instance, java commonly uses mutable state. A fundamental principle of Clojure is that data should be immutable. Immutability makes testing easier, it makes parallelization easier. Clojure was built to make pmap easy. If I have a java library where I have to remember that Foos are thread-safe, but Bars are not, that adds to the incidental complexity of my solution, and reduces my ability to bring Clojure's new tools to bear on the problem. As another commenter pointed out, syntax of a language is heavily influenced by the semantics of the language. A language starts with a few high level principles, and a favorite hammer or two. The syntax of the language is designed around making those common operations easy. Libraries written in that language will tend to follow those same principles. Having Java libraries available to Clojure is a huge advantage, but it's not the be-all end-all, because the semantics of those libraries may be incompatible with your new language. Instead, focus on semantics. Figure out which high level principles are good. What abstractions and design principles result in better, easier to understand solutions? From that follows your libraries and syntax.
draegtun 17y ago
And Perl5 already has some of those features: * multi-methods - There are two implementations on CPAN, Class::Multimethods (old) and MooseX::MultiMethods * rules - Ditto. Perl6::Rules (old) and Regexp::Grammars * macros - Have a look at Devel::Declare. Not Perl6 macros but still powerful stuff! * and a whole bunch of other good stuff - Lots have been backported to Perl5 (direct and into CPAN). For eg. smart match, given/when, Perl6::Junction, Perl6::Gather and also things like Moose & Class::MOP which are heavily influenced by Perl6
- avar 17y ago
  For some value of "already": * multi-methods: MooseX::MultiMethods and MooseX::Method::Signatures add a lot of overhead to subroutine calls (blogged in http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/02/moosexmethodsignatures-is-really-slow.html http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/02/...). Sometimes this doesn't matter, but they're certainly not a replacement for having a native type system. All the magic is done at runtime. * rules: Perl6::Rules and Regexp::Grammars are both depended on by a grand total of 0 CPAN modules. They're interesting experiments but not something in use, and not a replacement of rules with its "your regex opcodes are a normal method" model. * macros: Devel::Declare and the B::* modules are usable but they're a long way away from the Lisp model of being able to easily write macros. TryCatch is 800 lines of Perl and C to implement try { ... } catch { ...}. In any Lisp this would be trivially done with a macro in under 50 lines. As for the other stuff pretty much anything except smart match (which is now in Perl 5 core), Class::MOP and Moose falls under the "neat but some combination of: underused, slow, unstable, epic hack nobody wants to use".
  - autarch 17y ago
    Huh, Moose is underused? There a lot of modules on CPAN using Moose, and a lot of modules extending Moose. Also, in what way is Moose unstable? Moose, and modules which use Moose, are used in production at a lot of places (if you use a recent Catalyst, you're using Moose). Edit: doh, totally misread the OP's sentence.
    - 17y ago

fogus 17y ago

I may have missed the point, but it seems to me that the gist of the post is, "Perl 6 is different because it's the same as Lisp".

draegtun 17y ago
Larry Wall himself said that: Perl 6 is Lisp with a decent syntax, and minus a lot of assumptions about how lists should be represented :) ref: http://irclog.perlgeek.de/perl6/2010-01-15#i_1905210 http://irclog.perlgeek.de/perl6/2010-01-15#i_1905210 He then goes onto to mention that despite all the trappings of OO, Perl 6 is fundamentally more in the FP camp
- njharman 17y ago
  LWall > Lisp with a decent syntax I'm no Lisp guru, not even proficient but isn't saying that kind of missing a large point of Lisp in that code is data and data is a list/sexpresion or what ever it's called?
  - flogic 17y ago
    I think the point is "with rules you don't need everything to be and s-expression". I don't know how much to agree or not with that point. Currently I'm of the we'll see where is goes point of view.
    - rbanffy 17y ago
      > "with rules you don't need everything to be and s-expression" I am unsure if I would call it a feature.
      - flogic 17y ago
        From a Perl point of view, I think it's the right way to go. There are a few "standard" tricks to simulate extending Perl5, but they often feel hackish. From my understanding this will be more flexible and explicit. I don't have the Lisp experience to compare the two. My guess is Lisp macros will still be more flexible but the gap will be significantly narrowed.

AndrewO 17y ago

It has been said that Ruby is Smalltalk with a perly syntax. Perl6 extends on that: Perl 6 is Lisp with a perly syntax. Interesting idea, but I would have loved to see some examples or comparisons. For all of the mindshare that Perl has, I haven't seen much content (especially code) about Perl 6 over the last couple of years.

draegtun 17y ago
Here are some links showing recent Perl6 content/code: * Perl6 advent calendar: http://perl6advent.wordpress.com/ http://perl6advent.wordpress.com/ * Moritz Lenz perl6 blog: http://perlgeek.de/blog-en/perl-6/ http://perlgeek.de/blog-en/perl-6/ * Carl Masak perl* blog & github projects: http://use.perl.org/~masak/journal/ http://use.perl.org/~masak/journal/ http://github.com/masak http://github.com/masak * Perl6 planet: http://planetsix.perl.org/ http://planetsix.perl.org/ * Perl6 book: http://github.com/perl6/book http://github.com/perl6/book * Perl6 examples: http://github.com/perl6/perl6-examples http://github.com/perl6/perl6-examples
- AndrewO 17y ago
  Thanks—I'll check those out!
  - deleted 17y ago
    [deleted]
  - draegtun 17y ago
    You're very welcome. This link may also be of interest: http://transfixedbutnotdead.com/2010/01/14/anyone-for-perl-6-metaprogramming/ http://transfixedbutnotdead.com/2010/01/14/anyone-for-perl-6... From the links in the post you can find Perl5, Ruby, Javascript and Python comparative examples. Been playing a bit with Io (http://www.iolanguage.com/ http://www.iolanguage.com/) recently so was planning to add a comparative post for that as well. Update: I just copied over my Io example i had brewing into a gist (http://gist.github.com/372559 http://gist.github.com/372559)
- perlgeek 17y ago

jerf 17y ago

There's a presentation that Larry Wall gave at Google that has a lot to do with the internals of Perl 6: http://www.youtube.com/watch?v=JzIWdJVP-wo http://www.youtube.com/watch?v=JzIWdJVP-wo Actually, to be honest, I don't recommend it, I found it surprisingly dull in delivery (sorry, Larry), but the contents were very interesting. I actually think describing Perl 6 as "having macros" is accurate, but gives the wrong impression. It doesn't "have" macros, it's made of macros. The whole language is made of macros and you are nearly begged to extend it with more grammar. Or you can throw theirs away and write your own for something. Or you can throw theirs away, take some of it as a base, and extend it. It's a wild, wacky experiment that needs to be done. Whatever happens, we'll learn a lot. My intuition says "collapses under its own complexity" (especially after trying to add a few grammar-modifying CPAN modules) is the most likely result, but I fully support with no sarcasm someone trying this out in case my intuition is wrong. It's not just Lisp redux, it's something new.

dkarl 17y ago
especially after trying to add a few grammar-modifying CPAN modules How do modules compose with respect to syntax? I remember encountering a big frustration in Common Lisp when I used two libraries that depended on defining '[' as a reader macro for pretty syntax. Whichever library I allowed to use the '[' reader macro, my usage of the other library became verbose and hard to read. Not to mention that neither altering a module's source nor depending on the sequence of module loading is scalable across many modules.
- riffraff 17y ago
  they are lexically scoped, so as a non expert, I guess they are closer to scheme than to CL
gaius 17y ago
The whole language is made of macros and you are nearly begged to extend it with more grammar. Or you can throw theirs away and write your own for something. Or you can throw theirs away, take some of it as a base, and extend it. And people wonder why Perl is known as a "write-only" language!

thyrsus 17y ago

My understanding is that Perl 6 is the polar opposite of lisp, in this sense: In lisp, the code is always and everywhere already in a parse tree, and can be manipulated easily by, e.g., macros; Perl 5, on the other hand, is the most unparsable language possible: see http://www.perlmonks.org/?node_id=663393 http://www.perlmonks.org/?node_id=663393. What perl 6 does is own the parsing problem, and respond by incorporating super powerful parsing tools. Unfortunately, I believe that perl 6 retains its dynamic syntax, so parsing of perl 6 itself is still an uncertain adventure, and not something one can incorporate unconstrained into one's metaprogramming. I'd love to be wrong about that; am I? If so, can someone recommend a tutorial on perl 6 metaprogramming?

Shorel 17y ago
Well, I'm just learning Perl (work related) and it certainly feels like they tried to include a lot of ready-to-use lisp-like macros in an otherwise traditional syntax when inventing Perl. And Perl 5.12 has this jewel in its changelog: New experimental APIs allow developers to extend Perl with "pluggable" keywords and syntax.
- draegtun 17y ago
  With Perl 5.12 comes a working test example already using the pluggable feature: http://search.cpan.org/dist/perl/ext/XS-APItest-KeywordRPN/KeywordRPN.pm http://search.cpan.org/dist/perl/ext/XS-APItest-KeywordRPN/K... Here is the code example from the docs: use XS::APItest::KeywordRPN qw(rpn calcrpn); $triangle = rpn($n $n 1 + * 2 /); calcrpn $triangle { $n $n 1 + * 2 / }
- mst 17y ago
  Which is already doable from CPAN using Devel::Declare, hence Method::Signatures::Simple, Sub::Curried, MooseX::Method::Signatures etc. The stuff in core is, however, way, way more elegant than the way Devel::Declare currently does it - which was rather the point, Devel::Declare was "retrofit to existing perl5 VMs what will hopefully be core later".
megaman821 17y ago

jpablo 17y ago

It thankfully steals nothing from PHP I love this quote.

pg 17y ago

I don't know anything about Perl 6 (or much about earlier versions for that matter). Can someone explain how close it has gotten to Lisp? What macro facilities does it have? Can you munge the syntax tree after code is parsed?

jules 17y ago
Very close from what I gather from the web. It has macros similar to Lisp. They take an AST and return an AST. http://perlcabal.org/syn/S06.html#Macros http://perlcabal.org/syn/S06.html#Macros Do you think that Lisp style languages with sexps are the end in language design, or do you think that something better will be invented? (or has been invented)
- pg 17y ago
  I would never say never, but I haven't been able to think of a better way to represent programs than s-expressions despite many years of thinking about the problem. I wouldn't be surprised if sexprs are the end in the sense that the integers are. I.e. you might go on to discover new things but they'd ultimately reduce to sexprs. Is there a textual representation for ASTs? Could you write programs directly in ASTs?
  - jules 17y ago
    To your question: yes, the Perl syntax (the macro system supports quasiquotation). This is exactly the same as in Lisp. The difference is that Lisp syntax looks more like how the data structures are represented in memory. I think you can also build up your programs with data constructors (i.e. like doing (list 'lambda (list 'x) (list '+ 'x 1)) in Lisp). But note that I haven't used Perl6, this is information from the web.
  - jey 17y ago
    "AST" is actually just compiler lingo for "tree representation of s-expr representation of parsed code". In other words: sure, you can write code directly in {ASTs, s-exprs}; it's called "Lisp". ;-)
17y ago

rjurney 17y ago

I love Perl. I am most fluent in Perl. I can hack things together in Perl using CPAN modules without pausing, without thinking, and I am most efficient using it. I am happiest hacking Perl at 3AM. I hate whats happened to Perl because Perl 6 has taken so long to ship. Perl 5 is outdated. Moose helps, but its gotten so bad for so long that I can't code in Perl and collaborate with anyone. I write clean Perl, but it doesn't matter - everyone else moved on years ago and disdains it. So I hack Ruby, Python, etc. because I have to. I hope Perl 6 changes that. Is it ready to use?

bad_user 17y ago
No, but this is a good time to play with it ... Rakudo Star should be released in the next 2-3 weeks or so. Problem with Perl 6 was that it's too ground-breaking, without having the resources of a huge company (like Sun, MS). But it doesn't matter because you can't find the combination of features it provides in other languages ... * full OOP * optional typing * multi-dispatch * macros * cool pattern matching * functional features ... map, fold are at home ;) * continuations / coroutines * transactional memory * eventually it will be compatible with every package on CPAN Personally I don't like Perl (either 5 or 6), I'm more interested in Parrot because what is widely viewed today as being general-purpose VMs (the JVM / .NET) are a poor choice for dynamic languages. Consider that the JVM and .NET are stack-based. Because of that efficient continuations passing style is impossible on top, and that's a PITA because you can build any control structure on top ... tail-calls, closures, coroutines, exceptions, green threads ... can all be implemented efficiently in terms of CPS. Another thing against the JVM / .NET is that they'll never earn optimizations for dynamic languages that could impact the performance of first-class citizens. You can forget about an efficient tracing-compiler on top of those, simply because such optimizations are not cheap and can impact the performance of Java / C#, and those VMs are not low-level enough to implement it at a higher level. And for instance, personally I'm skeptic that InvokeDynamic on the JVM will deliver that much performance. Yeah, it provides a mechanism for a monomorphic inline cache, and from there the JVM can do stuff like code-inlining of call-sites. But it doesn't do tracing of types, which means that code like the following ... sum = 0 for i in range(1000): sum += i will always pay for the price of boxing/unboxing of those primitives, an optimization that current Javascript VMs and LuaJIT 2 are doing. So if Parrot delivers, it will be one heck of an alternative. Either way, its interface is nice and you can use it right now for prototyping new languages.