5 ms·

You simply do not know Lisp. Lisp is a term to describe different dialects in a family of languages. For example : Common Lisp is a multi-paradigm Lisp that su

You simply do not know Lisp. Lisp is a term to describe different dialects in a family of languages. For example : Common Lisp is a multi-paradigm Lisp that supports dynamic typing AND static typing. Haskell has NO equivalent to Common Lisp's macros. Template Haskell is not equivalent Lisp's macros. Often a Common Lisp implementation will simply require type hints to be added to gain large performance improvements. Clojure(another Lisp dialect) is the same this way.

dons 17y ago
> Template Haskell is not equivalent Lisp's macros Well, Template Haskell is a compile time meta programming system based on quasi quotation and AST manipulation...
- jgrant27 17y ago
  They are not equivalent. In Lisp there is no distinction between the syntax and the AST. In Haskell the AST is modeled using explicit data types. http://www.haskell.org/bz/thdoc.htm http://www.haskell.org/bz/thdoc.htm : "In Template Haskell, ordinary algebraic data types represent Haskell program fragments. These types modeled after Haskell language syntax and represents AST (abstract syntax tree) of corresponding Haskell code. There is an Exp type to represent Haskell expressions, Pat – for patterns, Lit – for literals, Dec – for declarations, Type – for data types and so on. You can see definitions of all these types in the module Language.Haskell.TH.Syntax."
  - jrockway 17y ago
    This is a good thing, though. With Common Lisp, you have to emulate this via a code-walking library -- and because the code-walking library just uses heuristics, you can never be sure that your macro is right in all cases. With well-defined data types for each AST node, this problem goes away. The advantage that CL-style macros have is that they are much easier to use than TH. For me, anyway, writing a Lisp macro is a trivial thing that involves almost no thinking. Writing a TH macro takes some testing and debugging.
    - jgrant27 17y ago
      There's no need to 'emulate' anything 'via code-walking' and 'heuristics' when writing Lisp macros. This is a personal use case of your own. If you know how to write Lisp macros(i.e. experience) then they will be correct. Not all Lisp macros are trivial to implement even for the experienced Lisp hacker. Writing a Lisp macro requires testing and debugging. The difference is that Lisp inserts no 'airbags' between the language and the programmer. They are very powerful but you may 'hurt' yourself.
      - jrockway 17y ago
        The issue comes when transforming entire expressions; what parts are code to transform, and what parts are data? You can't know, you have to guess.
        jgrant27 17y ago
        There is no guessing. You get to answer that question for yourself based on the context of your application. Many Lisps provide as much(or as little) type checking that you might want in your application.
        jrockway 17y ago
        OK, and now we've hit on the main problem I've had with Common Lisp -- every library thinks it's the only library in the universe, and they don't compose well. Your comment exactly expresses the attitude of the Common Lisp community (as I see it) -- "you should write every single line of code in your app from scratch, just for you". No thanks. The less code I have to write, the better.
        jgrant27 17y ago
        It seems that you have a beef with a particular(or multiple) Common Lisp libraries. Fair enough. However, I never said that you should write every line of code in your app from scratch. I did say that you should OWN the decisions for YOUR app. I believe that this more accurately describes the attitude of the CL community (and that of many other languages too). My point was that meta-programming is more powerful in Lisp than Haskell(as far as I'm aware). That's pretty much it.
  - prodigal_erik 17y ago
    Does that mean it's impossible to use Template Haskell to add new syntax? It strikes me as a serious limitation if you could only specify different ways to evaluate code that is already well-formed Haskell.
    - dons 17y ago
      No, you can add new syntax, via quasi quotes.
gwern 17y ago
Type hints are not static proofs of type-correctness, though, unless SBCL's warnings have gotten ridiculously more intelligent.
- jgrant27 17y ago
  Your notion of 'type-correctness' seems fairly static and you don't know Common Lisp either. A type hint in Common Lisp is the same as a type declaration. Common Lisp just let's you declare the types optionally. If you declare a type for a value and then try to store a value of an incorrect type then SBCL(and many other CL compilers) will respond with a compiliation error(not a warning) : ; in: LAMBDA NIL ; (TYPE (SINGLE-FLOAT NODE)) ; ; caught ERROR: ; Bound is not *, a SINGLE-FLOAT or a list of a SINGLE-FLOAT: NODE ; ; compilation unit finished ; caught 1 ERROR condition debugger invoked on a SB-INT:COMPILED-PROGRAM-ERROR in thread #<THREAD "initial thread" RUNNING {1002A5A051}>: Execution of a form compiled with errors. Form: #'(NAMED-LAMBDA TRAVERSE-PRE-ORDER (NODE FUN) (DECLARE (TYPE (SINGLE-FLOAT NODE)) (IF NODE (PROGN (APPLY FUN (LIST NODE)) (IF (BTNODE-LEFT NODE) (TRAVERSE-PRE-ORDER (BTNODE-LEFT NODE) FUN)) (IF (BTNODE-RIGHT NODE) (TRAVERSE-PRE-ORDER (BTNODE-RIGHT NODE) FUN))))) (BLOCK TRAVERSE-PRE-ORDER)) Compile-time error: Bound is not *, a SINGLE-FLOAT or a list of a SINGLE-FLOAT: NODE Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE] Ignore runtime option --load "tree-traversal.lisp". 1: [ABORT ] Skip rest of --eval and --load options. 2: Skip to toplevel READ/EVAL/PRINT loop. 3: [QUIT ] Quit SBCL (calling #'QUIT, killing the process). ((LAMBDA ()))
eru 17y ago
What you say may be right --- but I guess you deserve the 0 points for your unwarranted smugness.
- jgrant27 17y ago
  How is it unwarranted when Lisp is THE greatest programming language ever known ?

dons 17y ago

> Template Haskell is not equivalent Lisp's macros Well, Template Haskell is a compile time meta programming system based on quasi quotation and AST manipulation...

jgrant27 17y ago
They are not equivalent. In Lisp there is no distinction between the syntax and the AST. In Haskell the AST is modeled using explicit data types. http://www.haskell.org/bz/thdoc.htm http://www.haskell.org/bz/thdoc.htm : "In Template Haskell, ordinary algebraic data types represent Haskell program fragments. These types modeled after Haskell language syntax and represents AST (abstract syntax tree) of corresponding Haskell code. There is an Exp type to represent Haskell expressions, Pat – for patterns, Lit – for literals, Dec – for declarations, Type – for data types and so on. You can see definitions of all these types in the module Language.Haskell.TH.Syntax."
- jrockway 17y ago
  This is a good thing, though. With Common Lisp, you have to emulate this via a code-walking library -- and because the code-walking library just uses heuristics, you can never be sure that your macro is right in all cases. With well-defined data types for each AST node, this problem goes away. The advantage that CL-style macros have is that they are much easier to use than TH. For me, anyway, writing a Lisp macro is a trivial thing that involves almost no thinking. Writing a TH macro takes some testing and debugging.
  - jgrant27 17y ago
    There's no need to 'emulate' anything 'via code-walking' and 'heuristics' when writing Lisp macros. This is a personal use case of your own. If you know how to write Lisp macros(i.e. experience) then they will be correct. Not all Lisp macros are trivial to implement even for the experienced Lisp hacker. Writing a Lisp macro requires testing and debugging. The difference is that Lisp inserts no 'airbags' between the language and the programmer. They are very powerful but you may 'hurt' yourself.
    - jrockway 17y ago
      The issue comes when transforming entire expressions; what parts are code to transform, and what parts are data? You can't know, you have to guess.
      - jgrant27 17y ago
        There is no guessing. You get to answer that question for yourself based on the context of your application. Many Lisps provide as much(or as little) type checking that you might want in your application.
        jrockway 17y ago
        OK, and now we've hit on the main problem I've had with Common Lisp -- every library thinks it's the only library in the universe, and they don't compose well. Your comment exactly expresses the attitude of the Common Lisp community (as I see it) -- "you should write every single line of code in your app from scratch, just for you". No thanks. The less code I have to write, the better.
        jgrant27 17y ago
        It seems that you have a beef with a particular(or multiple) Common Lisp libraries. Fair enough. However, I never said that you should write every line of code in your app from scratch. I did say that you should OWN the decisions for YOUR app. I believe that this more accurately describes the attitude of the CL community (and that of many other languages too). My point was that meta-programming is more powerful in Lisp than Haskell(as far as I'm aware). That's pretty much it.
- prodigal_erik 17y ago
  Does that mean it's impossible to use Template Haskell to add new syntax? It strikes me as a serious limitation if you could only specify different ways to evaluate code that is already well-formed Haskell.
  - dons 17y ago
    No, you can add new syntax, via quasi quotes.

gwern 17y ago

Type hints are not static proofs of type-correctness, though, unless SBCL's warnings have gotten ridiculously more intelligent.

jgrant27 17y ago
Your notion of 'type-correctness' seems fairly static and you don't know Common Lisp either. A type hint in Common Lisp is the same as a type declaration. Common Lisp just let's you declare the types optionally. If you declare a type for a value and then try to store a value of an incorrect type then SBCL(and many other CL compilers) will respond with a compiliation error(not a warning) : ; in: LAMBDA NIL ; (TYPE (SINGLE-FLOAT NODE)) ; ; caught ERROR: ; Bound is not *, a SINGLE-FLOAT or a list of a SINGLE-FLOAT: NODE ; ; compilation unit finished ; caught 1 ERROR condition debugger invoked on a SB-INT:COMPILED-PROGRAM-ERROR in thread #<THREAD "initial thread" RUNNING {1002A5A051}>: Execution of a form compiled with errors. Form: #'(NAMED-LAMBDA TRAVERSE-PRE-ORDER (NODE FUN) (DECLARE (TYPE (SINGLE-FLOAT NODE)) (IF NODE (PROGN (APPLY FUN (LIST NODE)) (IF (BTNODE-LEFT NODE) (TRAVERSE-PRE-ORDER (BTNODE-LEFT NODE) FUN)) (IF (BTNODE-RIGHT NODE) (TRAVERSE-PRE-ORDER (BTNODE-RIGHT NODE) FUN))))) (BLOCK TRAVERSE-PRE-ORDER)) Compile-time error: Bound is not *, a SINGLE-FLOAT or a list of a SINGLE-FLOAT: NODE Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE] Ignore runtime option --load "tree-traversal.lisp". 1: [ABORT ] Skip rest of --eval and --load options. 2: Skip to toplevel READ/EVAL/PRINT loop. 3: [QUIT ] Quit SBCL (calling #'QUIT, killing the process). ((LAMBDA ()))

eru 17y ago

What you say may be right --- but I guess you deserve the 0 points for your unwarranted smugness.

jgrant27 17y ago
How is it unwarranted when Lisp is THE greatest programming language ever known ?