5 ms·

> That seems less like "avoid eval" and more like "avoid gets". Assuming that by `gets` you mean Ruby's `gets`, this is not quite right. `read` (and `read-stri

> That seems less like "avoid eval" and more like "avoid gets". Assuming that by `gets` you mean Ruby's `gets`, this is not quite right. `read` (and `read-string`) are not just generic IO functions. They are parsers for Clojure code. There are plenty of other varied forms of reading input to a string, but `read` does more.

pjungwir 14y ago
Sorry, by "gets" I meant gets(3) from C, which probably seems like a perfectly valid way to read input to a new programmer, but is a sure way to give yourself a buffer overflow. My point was that some innocuous-seeming functions are traps, and it's important that knowledge of those traps become part of a language's cultural knowledge, in hopes that it reaches more developers. But whether Ruby or C, I take your point that Clojure's read is not just an IO function. It's not really the IO-ness of gets that I'm trying to parallel, but its apparent safety. But perhaps to a Clojure programmer, read is not as surprising as gets because it's more clearly an evaling call. Do you think that'd be clear to a first-year Clojure dev?
- fogus 14y ago
  > Do you think that'd be clear to a first-year Clojure dev? It better be. One of the very first topics that a Lisp programmer must know is the implications of separate read/compile/eval phases.
- spacemanaki 14y ago
  > Sorry, by "gets" I meant gets(3) from C... Ah ok, that makes much more sense. I can't really speak to what is clear or not for a first-year Clojure dev. When I first learned Clojure, I had already dabbled in Lisps and Schemes for a while. The very first time I ran across `read`, probably in Scheme, it was obvious to me that it was special. Did I understand and appreciate the security implications? Probably not. Hopefully the security issues will be clear to a new Clojure dev since at least the ClojureDocs site steers you away from read and towards EDN. Maybe the official docs should be more stern and clear about it, but they do make a note of the security issue: http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/read http://clojure.github.com/clojure/clojure.core-api.html#cloj...

pjungwir 14y ago

Sorry, by "gets" I meant gets(3) from C, which probably seems like a perfectly valid way to read input to a new programmer, but is a sure way to give yourself a buffer overflow. My point was that some innocuous-seeming functions are traps, and it's important that knowledge of those traps become part of a language's cultural knowledge, in hopes that it reaches more developers. But whether Ruby or C, I take your point that Clojure's read is not just an IO function. It's not really the IO-ness of gets that I'm trying to parallel, but its apparent safety. But perhaps to a Clojure programmer, read is not as surprising as gets because it's more clearly an evaling call. Do you think that'd be clear to a first-year Clojure dev?

fogus 14y ago
> Do you think that'd be clear to a first-year Clojure dev? It better be. One of the very first topics that a Lisp programmer must know is the implications of separate read/compile/eval phases.
spacemanaki 14y ago
> Sorry, by "gets" I meant gets(3) from C... Ah ok, that makes much more sense. I can't really speak to what is clear or not for a first-year Clojure dev. When I first learned Clojure, I had already dabbled in Lisps and Schemes for a while. The very first time I ran across `read`, probably in Scheme, it was obvious to me that it was special. Did I understand and appreciate the security implications? Probably not. Hopefully the security issues will be clear to a new Clojure dev since at least the ClojureDocs site steers you away from read and towards EDN. Maybe the official docs should be more stern and clear about it, but they do make a note of the security issue: http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/read http://clojure.github.com/clojure/clojure.core-api.html#cloj...