4 ms·

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, t

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.
hga 10y ago
A good implementation also has total dynamic type checking, and the better allow you to relax that for run time speed (although it was nearly free on Lisp Machines and can be pretty cheap on out of order superscalar CPUs like Intels, as long as you don't enable Hyperthreading which tends to use up the otherwise free execution engines that get used for it).

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.

hga 10y ago

A good implementation also has total dynamic type checking, and the better allow you to relax that for run time speed (although it was nearly free on Lisp Machines and can be pretty cheap on out of order superscalar CPUs like Intels, as long as you don't enable Hyperthreading which tends to use up the otherwise free execution engines that get used for it).