I responded to this earlier, but I accidentally hit the 'reply to author' button instead of 'reply to post', and thus it went directly to Cedric rather than to the group. I'll respond here and quote the previous emails:
On Fri, Jan 13, 2012 at 8:57 PM, Anthony Grimes <disciplera...@gmail.com> wrote: > 4Clojure uses clojail for sandboxing behind the scenes. I didn't realize > that you may not be aware of that. On Friday, January 13, 2012 at 8:12 PM, Cedric Greevey wrote: > Indeed I wasn't, and I doubt much of the rest of its user base is either. On top of that, the *reason* for this is that it's an implementation detail. Implementation details do not excuse incorrect user-visible > behavior in an application. Figuring out how to make the application > do what it should, from the user's perspective, and how best to > implement it to do so is part of the developer's responsibility. Sandboxing is hard. Sacrifices have to be made. This is *not* just an implementation detail. Users are running their code inside of a sandbox. This can't be really be hidden. That said, you are absolutely correct. It is the developer's responsibility to make sure that all of this is as clean and easy as possible. I think Jack's suggestion below is a nice middleground. As a matter of fact, given a small patch to add a little pre-processing step to clojail (optional, of course), clojail could even throw a nice error message when a user tries to use 'for'. How does something like that sound to you? Would that be an okay compromise? There isn't much more that can be done beyond actually providing reasonable error messages for these failures. There are limitations to what can be done. On Friday, January 13, 2012 6:44:11 PM UTC-6, Cedric Greevey wrote: > > On Fri, Jan 13, 2012 at 6:47 PM, Anthony Grimes <discip...@gmail.com> > wrote: > > Clojail errs on the side of safety and not on the side of "Oh, well > maybe he > > wasn't trying to break the sandbox. Let's allow it anyway.". Treating > macros > > as opaque is just another hole in what is already difficult sandboxing. > > Macros are not even remotely close to functions. They *create* code. That > > code, just like any other explicitly written in your application, needs > to > > be sandboxed. It is much easier and safer to sandbox dangerous functions. > > The fact that expanded macro code that uses those functions is also > affected > > is less of a bug and more of a feature. > > You seem to be confused. We were discussing 4Clojure's rules, where > the stakes are at worst letting a person "cheat" slightly, not a > server security system or something, where the stakes would be > allowing hacking of some sort. Your concern is immensely out of > proportion to the consequences of someone cheating at 4Clojure's > learning game. > > > That said, of course it is unfortunate that things like this occur in > > 4Clojure for things as simple as for. But clojail and 4clojure are > separate > > projects. clojail is focused on being as safe as possible, which may > > sometimes clash with what would be most convenient in 4Clojure. > > Unclear here is what the two have to do with one another. There's no > obvious relevance of clojail's requirements for 4Clojure. Indeed, as > you seem to have realized, the requirements are distinct and sometimes > would conflict. > > -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
