5 ms·

Eval? The entire point of Lisp macros is toying around with evalulation in a safe fashion. It's other languages that do it so dangerously that gives eval a ba

• chvid 10y ago
  AFAIK macros in Lisp are turing complete and executed at compile time. This means (in principle) that there is no guarantee that a Lisp compile will ever terminate. I don't know why the OP is been down voted. Lisp is not for everyone and every application; I think that is a perfectly reasonable point of view.
  • pjc50 10y ago
    C++ templates are also turing complete, executed at compile time, and can result in extremely high compile times: http://cpptruths.blogspot.co.uk/2005/11/c-templates-are-turing-complete.html http://cpptruths.blogspot.co.uk/2005/11/c-templates-are-turi... I don't think that failure to terminate compiles is too big a problem in practice; treat it as just another form of compile-time error and fix your program.
    • chvid 10y ago
      It is a problem for tool support; one of the reasons why Java and C# has better editors.
      • sklogic 10y ago
        It's only a problem if your tools are done the wrong way. The proper tools can benefit from the macros instead. Of course, some discipline in how macros are implemented is required.
  • klibertp 10y ago
    The OP is being downvoted because he lies. Common Lisp does have strong and optional static typing. It does have namespaces. As for CL having `eval` - well, this is true at least. But I fail to see how in the world could that be a bad thing...
    • chvid 10y ago
      If a language has an eval construct it is hard/impossible to reason about types, security and correctness. It also makes it hard to compile it to machine code.
      • adwf 10y ago
        That would be true if we were talking about normal languages eval'ing strings. Lisp on the other hand treats the code as data and has the full compiler available at runtime. It can check types at both runtime and compile time, and it will still compile it down to nice machine code on the fly. Lisp eval is not the same as other languages, you use it implicitly all the time. Any occurence of macros or something like `(1 ,(+ 2 3) 4) is playing around with evaluation behind the scenes.
        • chvid 10y ago
          Parsing Lisp is not so hard, but as you said. It requires a JIT compiler or an interpreter. There are still some platforms/scenarios where that is not wanted.
          • sklogic 10y ago
            sbcl has `eval`, but it does not have a JIT compiler or an interpreter.
        • sklogic 10y ago
          Macros do not need to be implemented with eval, unless they're lexically scoped macros. They're just normal function, normally complied just like anything else. What is important is an incremental compilation, one top level statement at a time.
          • adwf 10y ago
            Yes, I didn't mean to imply that you needed to explicitly eval with macros. Rather that the nature of macros themselves is saying, eval this bit at compile time and that bit at run time. You are implicitly and safely doing what most languages would need an explicit eval call to do.
  • _ph_ 10y ago
    It is even better. Common Lisp macros are not a special macro language, but rather plain Lisp functions, which are run at compile time. This is important, because it means, you can write proper code in your development language for macro expansion instead of some obscure macro expansion language. This makes the process of writing macros rather robust and of course powerful. But of course, this means that like any program you write, you cannot guarantee that they terminate. For real-life macros that is rather a non-issue as they usually contain just a rather few lines of mostly simple code.