5 ms·

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".

by fogus 17y ago

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.
- plinkplonk 17y ago
  "Perl 6 is Lisp with a decent syntax," Calling perl syntax "decent", and by implication better than lisp syntax (such as there is) is mind bending.
  - gamache 17y ago
    Perl has a lot of syntax, and Lisp has almost none. Which one is better just depends on your opinion about syntax itself.
    - lispm 17y ago
      Lisp also has a lot of syntax, but it is ON TOP of s-expressions.
      - gamache 17y ago
        Hold Common Lisp next to Perl 5, and you tell me which one has "a lot" of syntax. I realize that Lisp has some syntax, and of course the fact that everything fits into S-exps is important, but I would not say that it has "a lot" of syntax compared to the vast majority of active languages.
        lispm 17y ago
        Let's just look at the syntax of Common Lisp's LOOP construct: loop [name-clause] {variable-clause}* {main-clause}* => result* name-clause::= named name variable-clause::= with-clause | initial-final | for-as-clause with-clause::= with var1 [type-spec] [= form1] {and var2 [type-spec] [= form2]}* main-clause::= unconditional | accumulation | conditional | termination-test | initial-final initial-final::= initially compound-form+ | finally compound-form+ unconditional::= {do | doing} compound-form+ | return {form | it} accumulation::= list-accumulation | numeric-accumulation list-accumulation::= {collect | collecting | append | appending | nconc | nconcing} {form | it} [into simple-var] numeric-accumulation::= {count | counting | sum | summing | } maximize | maximizing | minimize | minimizing {form | it} [into simple-var] [type-spec] conditional::= {if | when | unless} form selectable-clause {and selectable-clause}* [else selectable-clause {and selectable-clause}*] [end] selectable-clause::= unconditional | accumulation | conditional termination-test::= while form | until form | repeat form | always form | never form | thereis form for-as-clause::= {for | as} for-as-subclause {and for-as-subclause}* for-as-subclause::= for-as-arithmetic | for-as-in-list | for-as-on-list | for-as-equals-then | for-as-across | for-as-hash | for-as-package for-as-arithmetic::= var [type-spec] for-as-arithmetic-subclause for-as-arithmetic-subclause::= arithmetic-up | arithmetic-downto | arithmetic-downfrom arithmetic-up::= [[{from | upfrom} form1 | {to | upto | below} form2 | by form3]]+ arithmetic-downto::= [[{{from form1}}1 | {{{downto | above} form2}}1 | by form3]] arithmetic-downfrom::= [[{{downfrom form1}}1 | {to | downto | above} form2 | by form3]] for-as-in-list::= var [type-spec] in form1 [by step-fun] for-as-on-list::= var [type-spec] on form1 [by step-fun] for-as-equals-then::= var [type-spec] = form1 [then form2] for-as-across::= var [type-spec] across vector for-as-hash::= var [type-spec] being {each | the} {{hash-key | hash-keys} {in | of} hash-table [using (hash-value other-var)] | {hash-value | hash-values} {in | of} hash-table [using (hash-key other-var)]} for-as-package::= var [type-spec] being {each | the} {symbol | symbols | present-symbol | present-symbols | external-symbol | external-symbols} [{in | of} package] type-spec::= simple-type-spec | destructured-type-spec simple-type-spec::= fixnum | float | t | nil destructured-type-spec::= of-type d-type-spec d-type-spec::= type-specifier | (d-type-spec . d-type-spec) var::= d-var-spec var1::= d-var-spec var2::= d-var-spec other-var::= d-var-spec d-var-spec::= simple-var | nil | (d-var-spec . d-var-spec) I don't think there are many active languages with a more complex LOOP construct. Add to that, that some implementations have an extensible LOOP that allows to add even more syntax to it. The syntax for DEFCLASS: defclass class-name ({superclass-name}*) ({slot-specifier}*) [[class-option]] => new-class slot-specifier::= slot-name | (slot-name [[slot-option]]) slot-name::= symbol slot-option::= {:reader reader-function-name}* | {:writer writer-function-name}* | {:accessor reader-function-name}* | {:allocation allocation-type} | {:initarg initarg-name}* | {:initform form} | {:type type-specifier} | {:documentation string} function-name::= {symbol | (setf symbol)} class-option::= (:default-initargs . initarg-list) | (:documentation string) | (:metaclass class-name) there is much more of this.
- lispm 17y ago
  Whatever Larry is smoking, I don't want it.
lispm 17y ago
I'm also not sure if that will help Perl 6.
guelo 17y ago
I think you missed the point. The point is that Perl 6's "rules and grammars" are a profound innovation that will affect the future of language design.
- scott_s 17y ago
  I recognize that's the point the author made, I'm just not convinced of it. Show me the power through code. Right now it's just words.
- guelo 17y ago
  As far as I can tell grammars are a way of organizing a bunch of regexes together so you can run them against a document to match and extract all the data. It might make it easier to write parsers but that is a small, though admittedly annoying, subset of programming problems. It doesn't seem like a general enough feature to qualify as "profound".
  - mnemonicsloth 17y ago
    Parsers are already fairly easy to write in lispy languages. They just have a different name in that context -- "recursive functions". Pick a famous computer scientist, and the odds are better than even they've written a paper or two on this topic.
    - bad_user 17y ago
      I have no idea what you've just said, but it doesn't make any sense. Of course parsers are described by recursive functions, that's because recursive functions usually describe a push-down automata or a DFA, which you know, is needed for a parser. But describing a parser is not easy, even in lispy languages ... you still need a declarative syntax (like BNF or PEGs) for those rules, you still need a strategy (like LL(*) or LALR(1)), you still need to deal with context-dependent constructs, and you still need an AST that must be optimized. Text parsing is also not one of Lisp's strengths. Many implementations don't even have proper regexp engines ... but indeed, it's easy to translate any language to LISP as long as you're goal is not to generate something human readable.

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".

by 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.
plinkplonk 17y ago
"Perl 6 is Lisp with a decent syntax," Calling perl syntax "decent", and by implication better than lisp syntax (such as there is) is mind bending.
- gamache 17y ago
  Perl has a lot of syntax, and Lisp has almost none. Which one is better just depends on your opinion about syntax itself.
  - lispm 17y ago
    Lisp also has a lot of syntax, but it is ON TOP of s-expressions.
    - gamache 17y ago
      Hold Common Lisp next to Perl 5, and you tell me which one has "a lot" of syntax. I realize that Lisp has some syntax, and of course the fact that everything fits into S-exps is important, but I would not say that it has "a lot" of syntax compared to the vast majority of active languages.
      - lispm 17y ago
        Let's just look at the syntax of Common Lisp's LOOP construct: loop [name-clause] {variable-clause}* {main-clause}* => result* name-clause::= named name variable-clause::= with-clause | initial-final | for-as-clause with-clause::= with var1 [type-spec] [= form1] {and var2 [type-spec] [= form2]}* main-clause::= unconditional | accumulation | conditional | termination-test | initial-final initial-final::= initially compound-form+ | finally compound-form+ unconditional::= {do | doing} compound-form+ | return {form | it} accumulation::= list-accumulation | numeric-accumulation list-accumulation::= {collect | collecting | append | appending | nconc | nconcing} {form | it} [into simple-var] numeric-accumulation::= {count | counting | sum | summing | } maximize | maximizing | minimize | minimizing {form | it} [into simple-var] [type-spec] conditional::= {if | when | unless} form selectable-clause {and selectable-clause}* [else selectable-clause {and selectable-clause}*] [end] selectable-clause::= unconditional | accumulation | conditional termination-test::= while form | until form | repeat form | always form | never form | thereis form for-as-clause::= {for | as} for-as-subclause {and for-as-subclause}* for-as-subclause::= for-as-arithmetic | for-as-in-list | for-as-on-list | for-as-equals-then | for-as-across | for-as-hash | for-as-package for-as-arithmetic::= var [type-spec] for-as-arithmetic-subclause for-as-arithmetic-subclause::= arithmetic-up | arithmetic-downto | arithmetic-downfrom arithmetic-up::= [[{from | upfrom} form1 | {to | upto | below} form2 | by form3]]+ arithmetic-downto::= [[{{from form1}}1 | {{{downto | above} form2}}1 | by form3]] arithmetic-downfrom::= [[{{downfrom form1}}1 | {to | downto | above} form2 | by form3]] for-as-in-list::= var [type-spec] in form1 [by step-fun] for-as-on-list::= var [type-spec] on form1 [by step-fun] for-as-equals-then::= var [type-spec] = form1 [then form2] for-as-across::= var [type-spec] across vector for-as-hash::= var [type-spec] being {each | the} {{hash-key | hash-keys} {in | of} hash-table [using (hash-value other-var)] | {hash-value | hash-values} {in | of} hash-table [using (hash-key other-var)]} for-as-package::= var [type-spec] being {each | the} {symbol | symbols | present-symbol | present-symbols | external-symbol | external-symbols} [{in | of} package] type-spec::= simple-type-spec | destructured-type-spec simple-type-spec::= fixnum | float | t | nil destructured-type-spec::= of-type d-type-spec d-type-spec::= type-specifier | (d-type-spec . d-type-spec) var::= d-var-spec var1::= d-var-spec var2::= d-var-spec other-var::= d-var-spec d-var-spec::= simple-var | nil | (d-var-spec . d-var-spec) I don't think there are many active languages with a more complex LOOP construct. Add to that, that some implementations have an extensible LOOP that allows to add even more syntax to it. The syntax for DEFCLASS: defclass class-name ({superclass-name}*) ({slot-specifier}*) [[class-option]] => new-class slot-specifier::= slot-name | (slot-name [[slot-option]]) slot-name::= symbol slot-option::= {:reader reader-function-name}* | {:writer writer-function-name}* | {:accessor reader-function-name}* | {:allocation allocation-type} | {:initarg initarg-name}* | {:initform form} | {:type type-specifier} | {:documentation string} function-name::= {symbol | (setf symbol)} class-option::= (:default-initargs . initarg-list) | (:documentation string) | (:metaclass class-name) there is much more of this.
lispm 17y ago
Whatever Larry is smoking, I don't want it.

lispm 17y ago

I'm also not sure if that will help Perl 6.

guelo 17y ago

I think you missed the point. The point is that Perl 6's "rules and grammars" are a profound innovation that will affect the future of language design.

scott_s 17y ago
I recognize that's the point the author made, I'm just not convinced of it. Show me the power through code. Right now it's just words.
guelo 17y ago
As far as I can tell grammars are a way of organizing a bunch of regexes together so you can run them against a document to match and extract all the data. It might make it easier to write parsers but that is a small, though admittedly annoying, subset of programming problems. It doesn't seem like a general enough feature to qualify as "profound".
- mnemonicsloth 17y ago
  Parsers are already fairly easy to write in lispy languages. They just have a different name in that context -- "recursive functions". Pick a famous computer scientist, and the odds are better than even they've written a paper or two on this topic.
  - bad_user 17y ago
    I have no idea what you've just said, but it doesn't make any sense. Of course parsers are described by recursive functions, that's because recursive functions usually describe a push-down automata or a DFA, which you know, is needed for a parser. But describing a parser is not easy, even in lispy languages ... you still need a declarative syntax (like BNF or PEGs) for those rules, you still need a strategy (like LL(*) or LALR(1)), you still need to deal with context-dependent constructs, and you still need an AST that must be optimized. Text parsing is also not one of Lisp's strengths. Many implementations don't even have proper regexp engines ... but indeed, it's easy to translate any language to LISP as long as you're goal is not to generate something human readable.