3 ms·

I'm not a Lisp guy, but the amazing thing I see in Lisp that is missing from other languages is that due to the extremely simple syntax, code is data and data i

I'm not a Lisp guy, but the amazing thing I see in Lisp that is missing from other languages is that due to the extremely simple syntax, code is data and data is code. That lets you do some amazing things (Cf. SICP). On the other hand, isn't one lesson from modern computing that treating data as code is really dangerous? I have yet to see this addressed by Lisp advocates.

skylan_q 14y ago
The way in which code is modified in Lisp is generally in the source code itself, and overtly in the run-time environment or binaries. The latter might be what you're alluding to. Allowing code to be treated as data is a very powerful thing when it comes to programming. But of course, with more power there is more danger.
pavelludiq 14y ago
Define dangerous? Are you concerned with security? In which case, don't eval untrusted code, and you're fine. Maintainability? If done right "code is data" could improve the maintainability, or decrease it drastically, just like any other feature. If you have 80 lines of comments for every 10 lines of code, you've decreased your maintainability, comments are dangerous by that logic.
- pjungwir 14y ago
  Yes, by "dangerous" I mean prone to security exploits. I've got nothing against Lisp--I think it's a beautiful language, and I've dabbled in CL, Scheme, and Clojure--but whenever I hear about using data as code I get a warning tingle in the back of my head. One of the lessons of the recent Ruby YAML debacle is that an executable data format will get used for untrusted input eventually somewhere or other. (Edit: For example I can totally imagine the digital circuits simulator from SICP 3.3.4 saving/reading Lisp code as an input document.) Maybe the power of Lisp's data-as-code is worth the risk. We don't stop using string concatenation because of SQL injection. It's just that I've never even read so much as a warning about this feature, and I'm curious what Lisp users have to say about it.
  - pavelludiq 14y ago
    eval("dangerous python code here") As I pointed out, it is a problem in any language that has eval. The way you deal with it, is you never eval anything untrusted, which is actually extremely easy to do. I don't believe I've ever used eval ever. In CL specifically, because the reader can evaluate code as well, every time you use the read function, you should know these two things: 1) never use it for user input. 2) bind read-eval to nil. You'll be fine, or more accurately, no worse than anybody else :) On the other hand macros, and having a json style serialization format that is much more powerful and actually extensible is a big plus :)
    - sdkmvx 14y ago
      Is it actually dangerous to use read for user input? (defun read-data () (let ((data (let ((*read-eval* 'nil)) (read)))) (mapcar (lambda (x) (format 't "~a: ~a~%" (car x) (cdr x))) data))) Then I can (read-data) (("a" . 1) ("b" . 2) ("c" . (funcall (lambda () (princ "I ran code!"))))) And the following will print. a: 1 b: 2 c: (FUNCALL (LAMBDA () (PRINC I ran code!))) But of course unless I eval the code, arbitrary code will not run (assuming I haven't forgotten some aspect of the reader).
  - betterunix 14y ago
    "It's just that I've never even read so much as a warning about this feature" ...have you really looked? Here is a warning, in the section titled, "Reader Security:" http://letoverlambda.com/index.cl/guest/chap4.html http://letoverlambda.com/index.cl/guest/chap4.html
    - pjungwir 14y ago
      > have you really looked? To be fair, no. I'm not a practicing Lisp programmer; I just admire the language. But I've read a fair number of Lisp tutorials, as well as SICP, and I don't recall it being mentioned. I'm glad it's out there somewhere!
  - spacemanaki 14y ago
betterunix 14y ago
Code as data is dangerous, sure, but: 1. Python, Perl, Ruby, and even Java have support for code as data. If this makes Lisp a risky language, then you should be very worried about all of the above. 2. It is easier to disable code-as-data primitives (eval for example) than it is to add them to a language that lacks such support. I use Lisp for code that is not public-facing; the ability to extend the program at runtime can be very useful when security is not an issue. Languages that lack support for such things are harder to work with for cases like mine. 3. Code-as-data in Lisp is primarily a compile time feature, not a run time feature. Most Lisp programmers are using this feature via the macro system, rather than having programs that compute new functionality based on their inputs. You can disable all runtime support for treating code as data, and still take advantage of it at compile time.

skylan_q 14y ago

The way in which code is modified in Lisp is generally in the source code itself, and overtly in the run-time environment or binaries. The latter might be what you're alluding to. Allowing code to be treated as data is a very powerful thing when it comes to programming. But of course, with more power there is more danger.

pavelludiq 14y ago

Define dangerous? Are you concerned with security? In which case, don't eval untrusted code, and you're fine. Maintainability? If done right "code is data" could improve the maintainability, or decrease it drastically, just like any other feature. If you have 80 lines of comments for every 10 lines of code, you've decreased your maintainability, comments are dangerous by that logic.

pjungwir 14y ago
Yes, by "dangerous" I mean prone to security exploits. I've got nothing against Lisp--I think it's a beautiful language, and I've dabbled in CL, Scheme, and Clojure--but whenever I hear about using data as code I get a warning tingle in the back of my head. One of the lessons of the recent Ruby YAML debacle is that an executable data format will get used for untrusted input eventually somewhere or other. (Edit: For example I can totally imagine the digital circuits simulator from SICP 3.3.4 saving/reading Lisp code as an input document.) Maybe the power of Lisp's data-as-code is worth the risk. We don't stop using string concatenation because of SQL injection. It's just that I've never even read so much as a warning about this feature, and I'm curious what Lisp users have to say about it.
- pavelludiq 14y ago
  eval("dangerous python code here") As I pointed out, it is a problem in any language that has eval. The way you deal with it, is you never eval anything untrusted, which is actually extremely easy to do. I don't believe I've ever used eval ever. In CL specifically, because the reader can evaluate code as well, every time you use the read function, you should know these two things: 1) never use it for user input. 2) bind read-eval to nil. You'll be fine, or more accurately, no worse than anybody else :) On the other hand macros, and having a json style serialization format that is much more powerful and actually extensible is a big plus :)
  - sdkmvx 14y ago
    Is it actually dangerous to use read for user input? (defun read-data () (let ((data (let ((*read-eval* 'nil)) (read)))) (mapcar (lambda (x) (format 't "~a: ~a~%" (car x) (cdr x))) data))) Then I can (read-data) (("a" . 1) ("b" . 2) ("c" . (funcall (lambda () (princ "I ran code!"))))) And the following will print. a: 1 b: 2 c: (FUNCALL (LAMBDA () (PRINC I ran code!))) But of course unless I eval the code, arbitrary code will not run (assuming I haven't forgotten some aspect of the reader).
- betterunix 14y ago
  "It's just that I've never even read so much as a warning about this feature" ...have you really looked? Here is a warning, in the section titled, "Reader Security:" http://letoverlambda.com/index.cl/guest/chap4.html http://letoverlambda.com/index.cl/guest/chap4.html
  - pjungwir 14y ago
    > have you really looked? To be fair, no. I'm not a practicing Lisp programmer; I just admire the language. But I've read a fair number of Lisp tutorials, as well as SICP, and I don't recall it being mentioned. I'm glad it's out there somewhere!
- spacemanaki 14y ago

betterunix 14y ago

Code as data is dangerous, sure, but: 1. Python, Perl, Ruby, and even Java have support for code as data. If this makes Lisp a risky language, then you should be very worried about all of the above. 2. It is easier to disable code-as-data primitives (eval for example) than it is to add them to a language that lacks such support. I use Lisp for code that is not public-facing; the ability to extend the program at runtime can be very useful when security is not an issue. Languages that lack support for such things are harder to work with for cases like mine. 3. Code-as-data in Lisp is primarily a compile time feature, not a run time feature. Most Lisp programmers are using this feature via the macro system, rather than having programs that compute new functionality based on their inputs. You can disable all runtime support for treating code as data, and still take advantage of it at compile time.