4 ms·

Haskell, OCaml, probably F# too. Can also do 'bare metal' as well. I think the advantage to Lisp is that the programmer can generate and evaluate arbitrary ex

Haskell, OCaml, probably F# too. Can also do 'bare metal' as well. I think the advantage to Lisp is that the programmer can generate and evaluate arbitrary expression trees at run time. I'm not sure about the others but I recall Haskell has some difficulty with this. It's possible but it's not supported and not trivial to do.

mickduprez 7y ago
>> I think the advantage to Lisp is that the programmer can generate and evaluate arbitrary expression trees at run time. That's the one! Code is data - data is code. While this can be done in other languages, it isn't done without considerable effort or going 'off road' so to speak, macros are Lisp. cheers.
- moring 7y ago
  Isn't eval part of the cause of many security holes in other languages, e.g. Javascript? That is, not eval alone but combined with an unintended path from unvalidated user input to the snippet that gets eval'ed. Is there anything special Lisp does to prevent user input from getting into eval'ed data-code? Or any sandboxing provided by Lisp's eval?
  - fishmaster 7y ago
    You never ever eval user input.
    - moring 7y ago
      This rule is true for Javascript and PHP too, yet it happened all the time. If Lisp relies heavily on eval, what specific protection measures does it employ?
      - kazinator 7y ago
        Mainstream Lisp dialects do not "rely heavily" on eval. Its use is broadly discouraged in favor of other mechanisms like apply or macros. Newbies sometimes learn about backquote before learning about apply, and when they need too pass a dynamic list of arguments to a function, they end up writing (eval `(fun 1 2 ,@args)) instead of (apply fun 1 2 args). Or doing some metaprogramming using (eval `(defun ...)) in the middle of a function, instead of making a function-defining macro. In JavaScript and PHP, not to mention numerous other languages, eval is the only meta-programming you have. If you need to generate code, you end up using eval. Moreover, eval is textual. Textual code requires very careful escaping to avoid injection problems. Lisp's eval is AST-based, so it doesn't suffer from that. If I have a user-data variable that holds untrusted user data and put it into an evaluated code template, as in (eval `(list ... (some-api ',user-data) ...), I can completely trust that user-data will not "go live". It's inserted under a quote, and that's that. There is no way that content can bypass the quote, no matter what object it is.
    - FridgeSeal 7y ago
      I thought this was super common knowledge, yet I reviewed a co-workers pull request the other day and found files filled with eval (easily 30 usages) as well as global state (treated and mutated as if it was thread local). The most annoying part was that what they wanted to do didn’t even require eval and they refused to fix it even after I’d found a safe, non-eval way to do it.
SeanLuke 7y ago
> Haskell, OCaml, probably F# too. Lisp has macros, read-macros, and eval. These things enable DSLs. You're saying strongly-typed functional languages have features of equivalent power for this purpose?
- hopia 7y ago
  Writing EDSLs (E for embedded) is fairly common in Haskell. I don't know if it's as easy as with Lisp macros though since I have no exposure to that. Many DSLs are written on Haskell (Elm and Purescript come to mind) as well.
- pjmlp 7y ago
  Yes, for example F# has quotations, type expressions and type providers. Also .NET has attributes, compiler plugins and expression trees, which allow to do some kind of similar stuff even for C#, although not as straightforward as in Lisp. On the Java side, you also get the attributes (aka annotations), compiler plugins, AOP (yay CLOS interceptors). Haskell has Template Haskell and OCaml has ppx extensions.
  - fmakunbound 7y ago
    Those are so distant to what Lisp macros achieve. Also, I can't believe you brought up Java annotations in this discussion.
    - pjmlp 7y ago
      They are, but as they say back home, those who don't have dogs, hunt with cats.
- marcosdumay 7y ago
  Hum... Yes. Not exactly equivalent, but monad-based DSLs have almost the same power as Lisp macros. You can't escape the syntax restrictions, the same way you can't escape Lisp's syntax restrictions. And it's a bonus for Lisp (in power) that its syntax is much more flexible. But in semantics they are equivalent.

mickduprez 7y ago

>> I think the advantage to Lisp is that the programmer can generate and evaluate arbitrary expression trees at run time. That's the one! Code is data - data is code. While this can be done in other languages, it isn't done without considerable effort or going 'off road' so to speak, macros are Lisp. cheers.

moring 7y ago
Isn't eval part of the cause of many security holes in other languages, e.g. Javascript? That is, not eval alone but combined with an unintended path from unvalidated user input to the snippet that gets eval'ed. Is there anything special Lisp does to prevent user input from getting into eval'ed data-code? Or any sandboxing provided by Lisp's eval?
- fishmaster 7y ago
  You never ever eval user input.
  - moring 7y ago
    This rule is true for Javascript and PHP too, yet it happened all the time. If Lisp relies heavily on eval, what specific protection measures does it employ?
    - kazinator 7y ago
      Mainstream Lisp dialects do not "rely heavily" on eval. Its use is broadly discouraged in favor of other mechanisms like apply or macros. Newbies sometimes learn about backquote before learning about apply, and when they need too pass a dynamic list of arguments to a function, they end up writing (eval `(fun 1 2 ,@args)) instead of (apply fun 1 2 args). Or doing some metaprogramming using (eval `(defun ...)) in the middle of a function, instead of making a function-defining macro. In JavaScript and PHP, not to mention numerous other languages, eval is the only meta-programming you have. If you need to generate code, you end up using eval. Moreover, eval is textual. Textual code requires very careful escaping to avoid injection problems. Lisp's eval is AST-based, so it doesn't suffer from that. If I have a user-data variable that holds untrusted user data and put it into an evaluated code template, as in (eval `(list ... (some-api ',user-data) ...), I can completely trust that user-data will not "go live". It's inserted under a quote, and that's that. There is no way that content can bypass the quote, no matter what object it is.
  - FridgeSeal 7y ago
    I thought this was super common knowledge, yet I reviewed a co-workers pull request the other day and found files filled with eval (easily 30 usages) as well as global state (treated and mutated as if it was thread local). The most annoying part was that what they wanted to do didn’t even require eval and they refused to fix it even after I’d found a safe, non-eval way to do it.

SeanLuke 7y ago

> Haskell, OCaml, probably F# too. Lisp has macros, read-macros, and eval. These things enable DSLs. You're saying strongly-typed functional languages have features of equivalent power for this purpose?

hopia 7y ago
Writing EDSLs (E for embedded) is fairly common in Haskell. I don't know if it's as easy as with Lisp macros though since I have no exposure to that. Many DSLs are written on Haskell (Elm and Purescript come to mind) as well.
pjmlp 7y ago
Yes, for example F# has quotations, type expressions and type providers. Also .NET has attributes, compiler plugins and expression trees, which allow to do some kind of similar stuff even for C#, although not as straightforward as in Lisp. On the Java side, you also get the attributes (aka annotations), compiler plugins, AOP (yay CLOS interceptors). Haskell has Template Haskell and OCaml has ppx extensions.
- fmakunbound 7y ago
  Those are so distant to what Lisp macros achieve. Also, I can't believe you brought up Java annotations in this discussion.
  - pjmlp 7y ago
    They are, but as they say back home, those who don't have dogs, hunt with cats.
marcosdumay 7y ago
Hum... Yes. Not exactly equivalent, but monad-based DSLs have almost the same power as Lisp macros. You can't escape the syntax restrictions, the same way you can't escape Lisp's syntax restrictions. And it's a bonus for Lisp (in power) that its syntax is much more flexible. But in semantics they are equivalent.