On Wed, Oct 22, 2008 at 4:30 AM, Brett Morgan <[EMAIL PROTECTED]> wrote: > > I understand the lisp way is to use the reader plus macros to interpret the > incoming data stream. This is hella cool in that it seriously cuts down on > the amount of development work I have to do. The reader is already done, and > using macros to build the tree walker? And have them applied to a stm core? > Very lightweight in comparison to what I'd do traditionally. Very cool.
I think that if you use "read" rather than "load" or "eval" on the incoming s-expressions, you'll have a lot less to worry about. Without the eval step there's no need to try to block arbitrary function calls and such, because they'll never be evaluated in the first place -- any symbols that match function call names will simply be returned from the reader as symbols. If you then want to call macroexpand on them to help process the expressions (I've got no sense of whether this would be a useful approach or not) then the only code being run would be your own macro. There'd be no way for the incoming s-expressions to define new macros or functions. Perhaps you'd still want to audit the LispReader.java code for security vulnerabilities and/or run the reader in some sort of Java sandbox, but I wouldn't be surprised if neither of these is actually necessary. --Chouser --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
