4 ms·
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 ma
by 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 agoWell, 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 agoWith 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 agoWhich 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 agoI have one simple test to determine is something is a Lisp. Does it fit the statement "The program is the data"? It is a simple statement that implies a whole lot of power in a language, like the ability for a program to create a new program.
- draegtun 17y agoNeither Io & Ioke are Lisp but both fit the statement The program is the data Also I think the the ability for a program to create a new program (I assume you mean on the fly) is probably inherent in all dynamic languages.
- avar 17y ago"Ability" doesn't imply "first-class support" or "good idea". In languages that aren't Lisp this usually ends up being done by passing a raw string to eval() which is extremely error prone. It's not something you do lightly. Constructing macros in Lisp however /is/ something you do lightly. A typical lisp program might have a 20/80 division of macros/functions. You aren't going to see a sane program in other languages that do the same thing.
- bad_user 17y ago> Constructing macros in Lisp however /is/ something you do lightly For all the ease with which one can create macros in LISP, I haven't seen anything comparable to LINQ yet. And while I've seen useful macros here and there, I haven't seen anything groundbreaking ... macros are mostly used when you need laziness. Powerful? Yes. Easy to use? No.
- lispm 17y agoIf you haven't seen anything, did you actually look around? Common SQL : http://www.lispworks.com/documentation/sql-tutorial/index.html http://www.lispworks.com/documentation/sql-tutorial/index.ht... (loop for columns being the records of [select [*] :from [SpeciesList] :where aardvark] do (print columns)) Common SQL provides some kind of embedded SQL that gets expanded with read macros and macros to more low-level Lisp code.
- deleted 17y ago[deleted]
- deleted 17y ago[deleted]
- deleted 17y ago[deleted]
- deleted 17y ago[deleted]
- bad_user 17y agoYou don't have to parse Perl 6 's grammar ... the parser is written for you. How it goes ... you add rules for new syntax, and your macro-handler receives a syntax tree. And you transform that into a regular AST that the interpreter can understand ... more or less as in LISP. The difference is that in LISP you work directly with ASTs ... while in Perl you can access the compiler's pipeline. This idea is not new ... for instance it's also implemented in Boo (boo.codehaus.org) ... although I don't know how effective is.