Reader + Macros on untrusted S Expressions: Security considerations?
Hi all, I am thinking about a potential architecture for a webapp where in the server gets s expressions posted from an ajax web client. >From a security standpoint, the s expressions are coming from an untrusted computer, and thus are in need of careful vetting. With my java dev hat on, i'd move forward by building a lexer, a parser, and a tree walker to interpret the incoming datastream, with careful consideration to the various potential attacks a malicious user can submit. 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. My concern is, what are the security considerations of this architectural choice? Do I have to worry about people submitting malformed s expressions? Submitting s expressions that contain data that expands out reader macros? Do I have to watch for any particular bad code practices in constructing the macros? How do I go about error recovery and reporting on bad input? Thanks in advance. -- Brett Morgan http://brett.morgan.googlepages.com/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Reader + Macros on untrusted S Expressions: Security considerations?
If your untrusted S-expressions are expected to be pure functions on some input to some output, then you can use the existing java sandboxing features[1] to execute/read/whatever them in threads that are locked down tight. Then after sanitizing the output (which should be raw data), and you're done. That's what I think, at least. [1]: http://java.sun.com/javase/6/docs/api/java/lang/SecurityManager.html On Wed, Oct 22, 2008 at 10:30 AM, Brett Morgan <[EMAIL PROTECTED]> wrote: > Hi all, > > I am thinking about a potential architecture for a webapp where in the > server gets s expressions posted from an ajax web client. > > From a security standpoint, the s expressions are coming from an untrusted > computer, and thus are in need of careful vetting. > > With my java dev hat on, i'd move forward by building a lexer, a parser, and > a tree walker to interpret the incoming datastream, with careful > consideration to the various potential attacks a malicious user can submit. > > 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. > > My concern is, what are the security considerations of this architectural > choice? Do I have to worry about people submitting malformed s expressions? > Submitting s expressions that contain data that expands out reader macros? > Do I have to watch for any particular bad code practices in constructing the > macros? How do I go about error recovery and reporting on bad input? > > Thanks in advance. > > -- > > Brett Morgan http://brett.morgan.googlepages.com/ > > > > -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Reader + Macros on untrusted S Expressions: Security considerations?
I was honestly thinking of using S expressions purely as a replacement for the current trend to use JSON for everything. JSON basically is S expressions, except using hashmaps as the base type. The advantage being that I get a parser and tree walker language for free. On Wed, Oct 22, 2008 at 9:04 PM, Christian Vest Hansen <[EMAIL PROTECTED] > wrote: > > If your untrusted S-expressions are expected to be pure functions on > some input to some output, then you can use the existing java > sandboxing features[1] to execute/read/whatever them in threads that > are locked down tight. Then after sanitizing the output (which should > be raw data), and you're done. > > That's what I think, at least. > > [1]: http://java.sun.com/javase/6/docs/api/java/lang/SecurityManager.html > > On Wed, Oct 22, 2008 at 10:30 AM, Brett Morgan <[EMAIL PROTECTED]> > wrote: > > Hi all, > > > > I am thinking about a potential architecture for a webapp where in the > > server gets s expressions posted from an ajax web client. > > > > From a security standpoint, the s expressions are coming from an > untrusted > > computer, and thus are in need of careful vetting. > > > > With my java dev hat on, i'd move forward by building a lexer, a parser, > and > > a tree walker to interpret the incoming datastream, with careful > > consideration to the various potential attacks a malicious user can > submit. > > > > 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. > > > > My concern is, what are the security considerations of this architectural > > choice? Do I have to worry about people submitting malformed s > expressions? > > Submitting s expressions that contain data that expands out reader > macros? > > Do I have to watch for any particular bad code practices in constructing > the > > macros? How do I go about error recovery and reporting on bad input? > > > > Thanks in advance. > > > > -- > > > > Brett Morgan http://brett.morgan.googlepages.com/ > > > > > > > > > > > -- > Venlig hilsen / Kind regards, > Christian Vest Hansen. > > > > -- Brett Morgan http://brett.morgan.googlepages.com/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Reader + Macros on untrusted S Expressions: Security considerations?
On Oct 22, 1:30 pm, "Brett Morgan" <[EMAIL PROTECTED]> wrote: > Hi all, > > I am thinking about a potential architecture for a webapp where in the > server gets s expressions posted from an ajax web client. > > From a security standpoint, the s expressions are coming from an untrusted > computer, and thus are in need of careful vetting. > > With my java dev hat on, i'd move forward by building a lexer, a parser, and > a tree walker to interpret the incoming datastream, with careful > consideration to the various potential attacks a malicious user can submit. > > 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. > > My concern is, what are the security considerations of this architectural > choice? Do I have to worry about people submitting malformed s expressions? > Submitting s expressions that contain data that expands out reader macros? > Do I have to watch for any particular bad code practices in constructing the > macros? How do I go about error recovery and reporting on bad input? > > Thanks in advance. > Hi Brett, Yes, being able to use the clojure reader directly is really neat. Some things you could do are: - use a separate namespace for evaluation the expressions and provide a clear interface between the core and the sexpressions that you get. - have a black or white list, and allow or reject the s-expression based on this. For example you might want to disallow namespace switching functions. E.g. below, I can't clobber defn as I am in the 'user' namespace and 'defn' is in the clojure ns. user=> (def defn :somethig-bad) java.lang.Exception: Name conflict, can't def defn because namespace: user refers to:#=(var clojure/defn) (NO_SOURCE_FILE:1) user=> Some other things you may want to reject expressions based on are java interop and file IO. This should basically be a find operation for a bunch of symbols on the list before you give it to the reader 'read' - Recently the #= reader macro was added. This makes the reader do the evaluation before using the value. You may want to disable this. E.g. user=> #=(+ 1 1) 2 I am not sure how to disable this. There is a similar thing #. in CL and it is important to disable it before reading potentially unsafe expressions. Maybe Rich or someone else can comment on how to disable this. I suppose a lot of this is dictated by what you want to do with the s-expressions. Parth > -- > > Brett Morganhttp://brett.morgan.googlepages.com/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Reader + Macros on untrusted S Expressions: Security considerations?
On Oct 22, 3:42 pm, Parth Malwankar <[EMAIL PROTECTED]> wrote: > On Oct 22, 1:30 pm, "Brett Morgan" <[EMAIL PROTECTED]> wrote: > > - Recently the #= reader macro was added. This makes the reader > do the evaluation before using the value. You may want to > disable this. E.g. > > user=> #=(+ 1 1) > 2 > > I am not sure how to disable this. There is a > similar thing #. in CL and it is important to disable it before > reading potentially unsafe expressions. Maybe Rich or someone > else can comment on how to disable this. > Oops. The example I meant to give was: user=> `(+ 1 1) (clojure/+ 1 1) user=> `#=(+ 1 1) 2 Parth --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Reader + Macros on untrusted S Expressions: Security considerations?
On Wed, Oct 22, 2008 at 9:54 PM, Parth Malwankar <[EMAIL PROTECTED]>wrote: > > > > On Oct 22, 3:42 pm, Parth Malwankar <[EMAIL PROTECTED]> wrote: > > On Oct 22, 1:30 pm, "Brett Morgan" <[EMAIL PROTECTED]> wrote: > > > > - Recently the #= reader macro was added. This makes the reader > > do the evaluation before using the value. You may want to > > disable this. E.g. > > > > user=> #=(+ 1 1) > > 2 > > > > I am not sure how to disable this. There is a > > similar thing #. in CL and it is important to disable it before > > reading potentially unsafe expressions. Maybe Rich or someone > > else can comment on how to disable this. > > > > Oops. The example I meant to give was: > user=> `(+ 1 1) > (clojure/+ 1 1) > user=> `#=(+ 1 1) > 2 > That's actually exactly the style of security breach capability that i was worried about. Thank you =) > > Parth > > > > -- Brett Morgan http://brett.morgan.googlepages.com/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [EMAIL PROTECTED]
I second the thanks. The presentation was perfectly timed. The presentations that preceded it built the perfect mood. The idea in the air was that Lisp was about innovation and making programming easier. That Common Lisp was never meant to be the end. That Lisp needs something new. And here comes Clojure. I look forward to working on Clojure. Eric On Oct 21, 11:38 am, Dustin Withers <[EMAIL PROTECTED]> wrote: > Rich, > > I just wanted to thank you for your presentation at Lisp50. The > excitement that was created from your presentation was amazing. I > believe that this is the beginning of a resurgence of Lisp in the > market and I think Clojure is leading the way. After last nights > events I hope to see more people coming in with diverse interests and > abilities. > > Again, thank you for the presentation and thank you for Clojure! > > -dustin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
LispCast's assessment of Lisp50
Very positive about Clojure! http://www.lispcast.com/drupal/node/77 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Data types in Clojure
Hi everyone, I recently discovered Clojure (largely by accident) and investigated a bit by reading the on-line material and playing around with simple expressions (I have used other Lisps in the past, but never seriously). I am quite impressed with what I have seen - this looks like the first Lisp I might be willing to use in real life. However, there is one point that is not clear to me: how does Clojure deal with data types in general, and abstract data types in particular? How would one implement a library for tree operations, a graph library, or a numerical library for operations on complex numbers? In OO languages, one would uses classes and interfaces for that. In functional languages of the ML family, one would use algebraic data types and modules/packages to hide a particular implementation. In standard Lisps, everything would be represented by cons nodes, with little to no abstraction. Clojure knows about abstractions and interfaces, but all I have seen until now is the use of interfaces on the client side, with data types already implemented. I can also see how one would implement classes and interfaces in Java and use them from Clojure. But who would one define interfaces and concrete implementations in Clojure itself? Greetings from Paris, Konrad. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Data types in Clojure
Hi everyone, I recently discovered Clojure (largely by accident) and investigated a bit by reading the on-line material and playing around with simple expressions (I have used other Lisps in the past, but never seriously). I am quite impressed with what I have seen - this looks like the first Lisp I might be willing to use in real life. However, there is one point that is not clear to me: how does Clojure deal with data types in general, and abstract data types in particular? How would one implement a library for tree operations, a graph library, or a numerical library for operations on complex numbers? In OO languages, one would uses classes and interfaces for that. In functional languages of the ML family, one would use algebraic data types and modules/packages to hide a particular implementation. In standard Lisps, everything would be represented by cons nodes, with little to no abstraction. Clojure knows about abstractions and interfaces, but all I have seen until now is the use of interfaces on the client side, with data types already implemented. I can also see how one would implement classes and interfaces in Java and use them from Clojure. But who would one define interfaces and concrete implementations in Clojure itself? Greetings from Paris, Konrad. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [EMAIL PROTECTED]
I second the thanks. The Clojure presentation was perfectly timed. After a whole day of talking about how Lisp was always about innovation. That Common Lisp was never supposed to be an end---it was a practical compromise not a technical ideal. That Lisp needs something new. Then you talked about Clojure. And the older Lisp guys were feeling the buzz of excitement. I felt that they passed the baton. Good luck. Eric On Oct 21, 11:38 am, Dustin Withers <[EMAIL PROTECTED]> wrote: > Rich, > > I just wanted to thank you for your presentation at Lisp50. The > excitement that was created from your presentation was amazing. I > believe that this is the beginning of a resurgence of Lisp in the > market and I think Clojure is leading the way. After last nights > events I hope to see more people coming in with diverse interests and > abilities. > > Again, thank you for the presentation and thank you for Clojure! > > -dustin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: offtopic - where are you come from? (poll)
Wellington, New Zealand "since 1989" --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Data types in Clojure
Hi Konrad, On 22 Okt., 12:49, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > However, there is one point that is not clear to me: how does Clojure > deal with data types in general, and abstract data types in > particular? How would one implement a library for tree operations, a > graph library, or a numerical library for operations on complex > numbers? > > In OO languages, one would uses classes and interfaces for that. In > functional languages of the ML family, one would use algebraic data > types and modules/packages to hide a particular implementation. In > standard Lisps, everything would be represented by cons nodes, with > little to no abstraction. > > Clojure knows about abstractions and interfaces, but all I have seen > until now is the use of interfaces on the client side, with data types > already implemented. I can also see how one would implement classes > and interfaces in Java and use them from Clojure. But who would one > define interfaces and concrete implementations in Clojure itself? Well on the one hand you can define interfaces "by documentation". Define the interface in the documentation and export the functions which do things as advertised from your namespace. Private helper functions can be declared and are not exported (defn vs. defn-). Whatever the functions return should be treated opaque. As long as the opaqueness is respected you can change the underlying implementation without customer impact. An example is the interface of clojure.zip. It returns a "location" in the tree, which is sufficiently vague to tell you "Leave your hands off!". Of course you may inspect a location and change it as you like (it's a normal vector). But well, don't complain afterwards. If you are more the "Give a programmer a tree and rope and he will use them!" type, you can use gen-class from clojure itself and gen-interface from clojure.contrib to define an opaque interface and a class implementing the interface. I think the later is good idea when you expect different implementations to be plugged in at run-time, which may also come from the user of your library. If it's just the implementation of the library's functionality I would go with the first way. Just my 0.02$ Sincerely Meikel --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: offtopic - where are you come from? (poll)
Milano, Italy On Oct 17, 11:27 am, "Rastislav Kassak" <[EMAIL PROTECTED]> wrote: > Hello Clojurians, > > I think after 1st year of Clojure life it's good to check how far has > Clojure spread all over the world. > > So wherever are you come from, be proud and say it. > > I'm from Slovakia. :) > > RK --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [EMAIL PROTECTED]
Rich, Was this presentation recorded? Any chance you can upload the slides and/or video for those of us that didn't participate in Lisp50. Thanks - Karl --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Testing Clojure (was Re: Bug? Strange set equality (r1075))
Hello Stuart, On 21 Okt., 16:37, Stuart Halloway <[EMAIL PROTECTED]> wrote: > Since there is now a movement afoot to write a comprehensive test > suite, I want to re-post the spike I did earlier on ClojureCheck. > > It would be cool to use check-style tests for at least part of the > Clojure suite. If there is interest in this, I hope to have time to > work on this in late November, or would be delighted if someone else > picks up the idea and runs with it. I am working on a TAP implementation[1] for Clojure. For this I would really like to have a ClojureCheck (as there is LectroTest for Perl). And as stated in the original ClojureCheck thread I will work on this. Unfortunately, (not= de.kotka.tap clojure/test clojure.contrib.test- is) but I think the basic machinery like arbitrary definition etc. can be reused. I will hopefully soon post a first draft of the implementation. Sincerely Meikel [1]: http://kotka.de/projects/clojure/tap.html (Not up-to-date, though) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Testing Clojure (was Re: Bug? Strange set equality (r1075))
> Run tests with: > >(require 'clojure.contrib.test-clojure) I don't see clojure.contrib.test-clojure. Are you going to be committing that? Thanks, - J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Reader + Macros on untrusted S Expressions: Security considerations?
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 -~--~~~~--~~--~--~---
Re: offtopic - where are you come from? (poll)
Aarhus, Denmark On 17 Okt., 11:27, "Rastislav Kassak" <[EMAIL PROTECTED]> wrote: > Hello Clojurians, > > I think after 1st year of Clojure life it's good to check how far has > Clojure spread all over the world. > > So wherever are you come from, be proud and say it. > > I'm from Slovakia. :) > > RK --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Reader + Macros on untrusted S Expressions: Security considerations?
Would you have S-expressions going from the server back to the client as well? Bill --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Reader + Macros on untrusted S Expressions: Security considerations?
On Wed, Oct 22, 2008 at 6:55 AM, Brett Morgan <[EMAIL PROTECTED]> wrote: > > > On Wed, Oct 22, 2008 at 9:54 PM, Parth Malwankar <[EMAIL PROTECTED]> > wrote: >> >> >> >> On Oct 22, 3:42 pm, Parth Malwankar <[EMAIL PROTECTED]> wrote: >> > On Oct 22, 1:30 pm, "Brett Morgan" <[EMAIL PROTECTED]> wrote: >> > >> > - Recently the #= reader macro was added. This makes the reader >> > do the evaluation before using the value. You may want to >> > disable this. E.g. >> > >> > user=> #=(+ 1 1) >> > 2 >> > >> > I am not sure how to disable this. There is a >> > similar thing #. in CL and it is important to disable it before >> > reading potentially unsafe expressions. Maybe Rich or someone >> > else can comment on how to disable this. >> > >> >> Oops. The example I meant to give was: >> user=> `(+ 1 1) >> (clojure/+ 1 1) >> user=> `#=(+ 1 1) >> 2 > > That's actually exactly the style of security breach capability that i was > worried about. Thank you =) > There will be a flag to disable #= while reading. Rich --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Reader + Macros on untrusted S Expressions: Security considerations?
On Wed, Oct 22, 2008 at 9:41 AM, Randall R Schulz <[EMAIL PROTECTED]> wrote: > > On Wednesday 22 October 2008 06:27, .Bill Smith wrote: >> Would you have S-expressions going from the server back to the client >> as well? > > If that client is a Web browser, then presumably it would require an > S-Expression reader written in JavaScript to decode them. > > That would be a nice thing to have. Is anybody aware of one? Or write a JSON writer in Clojure. That would probably run faster and be more fun to create. Although I think such things already exist. --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 -~--~~~~--~~--~--~---
Re: Reader + Macros on untrusted S Expressions: Security considerations?
On Wednesday 22 October 2008 06:27, .Bill Smith wrote: > Would you have S-expressions going from the server back to the client > as well? If that client is a Web browser, then presumably it would require an S-Expression reader written in JavaScript to decode them. That would be a nice thing to have. Is anybody aware of one? > Bill Randall Schulz --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ikvm and .NET
Steps for running clojure as a .NET app and instantiating .NET types.
- I converted the clojure.jar to clojure.dll: ikvmc -target:library c:
\path\to\clojure.jar (this creates clojure.dll)
- Convert mscorlib.dll to mscorlib.jar: ikvmstub mscorlib.dll
- Create a .net c# console app, and add reference to clojure.dll
- Change Main to this:
static void Main(string[] args)
{
clojure.lang.Repl.main(new string[] {});
}
- Run console app (Repl) and add mscorlib.jar to classpath via
clojure: (add-classpath file://c:.)
Now you can instantiate .net types
(def i (new cli.System.Int32))
(def s (new cli.System.String nil))
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Data types in Clojure
Hi Meikel, thanks for your comments! > Well on the one hand you can define interfaces "by documentation". > Define the interface in the documentation and export the functions > which do things as advertised from your namespace. For interfaces with a single implementation, this sounds fine. And closure/zip is a fine example. But assume I wanto to provide two implementations for such an interface, in two separate namespaces. Can I then write client code that will work with either one? I would have to pass it the namespace as an argument. I wonder if the client code would still remain readable. Perhaps some clever macro would help... Next, assume that I need to use two or more implementations of my interface in parallel, in the same code, just as I can use lists and vectors indifferently with client routines using the seq interface. I guess that is impossible using the "interface-by-documentation" approach, right? > If you are more the "Give a programmer a tree and rope and he will > use them!" type, you can use gen-class from clojure itself and > gen-interface from clojure.contrib to define an opaque interface > and a class implementing the interface. I just looked at gen-class. It looks more like a Java interfacing tool than like a Lispish language construct, but I guess it would do the job. Are there any published examples for using gen-class and/or gen- interface that I could look at for inspiration? Preventing programmers from doing bad things isn't the main issue for me; I am mostly a Python programmer at the moment, and I am fine with Python's "we are all consenting adults" attitude. What I do care about is modularity: being able to write code based on an interface specification and being able to plug in different implementations. A related question concerns the interfaces that Clojure already uses: ISeq and Number, for example. Can I implement my own data structure in Clojure that supports the ISeq interface? Can I implement a new number type and have it work with +, -, etc.? Konrad. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: ikvm and .NET
hmmm, the .NET String thing isn't quite working for some reason.
Seems like it converts to the java string. I can work with
StringBuilder though:
(def sb (new cli.System.Text.StringBuilder))
(. sb (Append "asdf"))
On Oct 22, 11:30 am, Mark J P <[EMAIL PROTECTED]> wrote:
> Steps for running clojure as a .NET app and instantiating .NET types.
>
> - I converted the clojure.jar to clojure.dll: ikvmc -target:library c:
> \path\to\clojure.jar (this creates clojure.dll)
> - Convert mscorlib.dll to mscorlib.jar: ikvmstub mscorlib.dll
> - Create a .net c# console app, and add reference to clojure.dll
> - Change Main to this:
> static void Main(string[] args)
> {
> clojure.lang.Repl.main(new string[] {});
> }
> - Run console app (Repl) and add mscorlib.jar to classpath via
> clojure: (add-classpath file://c:.)
>
> Now you can instantiate .net types
> (def i (new cli.System.Int32))
> (def s (new cli.System.String nil))
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Data types in Clojure
On Wed, Oct 22, 2008 at 12:07 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > For interfaces with a single implementation, this sounds fine. And > closure/zip is a fine example. > > But assume I wanto to provide two implementations for such an > interface, in two separate namespaces. Can I then write client code > that will work with either one? Don't dismiss clojure/zip to easily. The functions defined there largely defer to functions stored in metadata on the object. This means a new type of zip tree can be provided by anyone in any namespace, simply by returning an object with the appropriate metadata. This technique could be extended in other contexts, and there may be other ways to solve similar problems. > A related question concerns the interfaces that Clojure already uses: > ISeq and Number, for example. Can I implement my own data structure in > Clojure that supports the ISeq interface? Can I implement a new number > type and have it work with +, -, etc.? In order to implement Java interfaces such that clojure/seq and such builtin functions work, you do need to implement a Java class. This can be done with 100% Java code by gen-class and possibly the easier-to-use proxy function. --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 -~--~~~~--~~--~--~---
Re: Data types in Clojure
Hi, > But assume I wanto to provide two implementations for such an > interface, in two separate namespaces. Personally, I'd define multimethods as the “interface“, in a single namespace, and implement them for any set of data structures that I wanted to support. At least, this is the CLOS way, so to speak (CLOS = the Common Lisp Object System). Which, by the way, means that when you say, > In standard Lisps, everything would be represented by cons nodes, with > little to no abstraction you're wrong. Thank God! :) (Note: As I'm not yet very familiar with idiomatic Clojure style and (at least for the time being) much more of a Common Lisper, I'd suggest sticking to what the others say if in any doubt. My posting is to be read merely as a hint, not as a recommendation.) Matthias --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: ikvm and .NET
Forgot to include this step:
Add a reference to IKVM.OpenJDK.ClassLibrary.dll in the .NET Project
On Oct 22, 11:30 am, Mark J P <[EMAIL PROTECTED]> wrote:
> Steps for running clojure as a .NET app and instantiating .NET types.
>
> - I converted the clojure.jar to clojure.dll: ikvmc -target:library c:
> \path\to\clojure.jar (this creates clojure.dll)
> - Convert mscorlib.dll to mscorlib.jar: ikvmstub mscorlib.dll
> - Create a .net c# console app, and add reference to clojure.dll
> - Change Main to this:
> static void Main(string[] args)
> {
> clojure.lang.Repl.main(new string[] {});
> }
> - Run console app (Repl) and add mscorlib.jar to classpath via
> clojure: (add-classpath file://c:.)
>
> Now you can instantiate .net types
> (def i (new cli.System.Int32))
> (def s (new cli.System.String nil))
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Data types in Clojure
Hi Konrad, On 22 Okt., 18:07, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > But assume I wanto to provide two implementations for such an > interface, in two separate namespaces. Can I then write client code > that will work with either one? I would have to pass it the namespace > as an argument. I wonder if the client code would still remain > readable. Perhaps some clever macro would help... Ok stupid example (don't think to much about the sense, just for demonstration): you use a message digest to identify things. The interface is easy: it's a single function which you pass a thing and it tells you the id. Let's call it identify Say, you have two implementations one using MD5, one using SHA1. I see the following scenarios: - The user wants to choose the implementation. So provide an identical interface: (ns com.identity.MD5) (defn identify [x] (do-md5-things-to x)) and (ns com.identity.SHA1) (defn identify [x] (do-sha-things-to x)) The user can then use: (use 'com.identity.MD5) (identify x) or he can assign an alias: (require '[com.identity.MD5 :as identificator]) (identificator/identify x) In both cases you don't have to change the code. Just import the different namespace. - You want to choose the implementation, transparent for the user. Provide a facade in com.identity forwarding the request or have another structure for your source: (if (some-condidition-holds) (require '[com.identity.MD5 :as digest]) (require '[com.identity.SHA1 :as digest])) (defn identity [x] (digest/identify x)) or replay with the same idea for your lib internally: (defn identity [x] (digest/do-digest-things-to x)) > Next, assume that I need to use two or more implementations of my > interface in parallel, in the same code, just as I can use lists and > vectors indifferently with client routines using the seq interface. I > guess that is impossible using the "interface-by-documentation" > approach, right? For this you probably want multimethods, since the implementations are "active" at the same time. So you need some way to distinguish what you got passed. > A related question concerns the interfaces that Clojure already uses: > ISeq and Number, for example. Can I implement my own data structure in > Clojure that supports the ISeq interface? Can I implement a new number > type and have it work with +, -, etc.? I'm not sure about the numbers but for ISeq (and other interfaces) one can use proxy. (defn rev-vector-seq [v] (when (< 0 (count v)) (proxy [clojure.lang.ISeq] [] (seq [] this) (first [] (peek v)) (rest [] (rev-vector-seq (pop v)) Hope this helps. Sincerely Meikel --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: ikvm and .NET
On Wed, Oct 22, 2008 at 8:30 AM, Mark J P <[EMAIL PROTECTED]> wrote: > > Steps for running clojure as a .NET app and instantiating .NET types. > > - I converted the clojure.jar to clojure.dll: ikvmc -target:library c: > \path\to\clojure.jar (this creates clojure.dll) > - Convert mscorlib.dll to mscorlib.jar: ikvmstub mscorlib.dll > - Create a .net c# console app, and add reference to clojure.dll By the way, this is great for embedding Clojure in your .NET app. If all you want is a REPL, you can skip the C# app step and use the -target:exe switch to get a clojure.exe. The topic has also been explored in a past thread: http://groups.google.com/group/clojure/browse_thread/thread/e48b64f3dc1f09fb/09919e06ebe95d85?lnk=gst . Shawn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Testing Clojure (was Re: Bug? Strange set equality (r1075))
On Oct 22, 2008, at 8:22 AM, J. McConnell wrote: > >> Run tests with: >> >> (require 'clojure.contrib.test-clojure) > > I don't see clojure.contrib.test-clojure. Are you going to be > committing that? It's up now. Once your CA is in to Rich, I'll be happy to accept patches to extend its nascent testing reach: user=> (require 'clojure.contrib.test-clojure :reload-all) Testing # Ran 22 tests with 10 assertions. 0 failures, 0 exceptions. nil user=> Thanks, --Steve --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Currying for Clojure
I would like to suggest to improve currying. Right now Clojure already comes with a nice way to do something that is nearly as good as currying, but still not fully. In a very functional programming style this makes sense to have good currying support. Here is my proposal for extending the #(...) notation, and I would like to give some examples too: 1. Leave out all arguments after the last specific one was given. This means we need to rewrite the curry notation into one that uses apply. Examples: #(< 5) instead of #(< 5 %) or #(< 5 %&) #(< 5) ==> (fn [& args] (apply + 5 args)) If foo has arity 11: #(foo 10 20) instead of #(foo 10 20 %&) or, for those insisting on correct arity even #(foo 10 20 %1 %2 %3 %4 %5 %6 %7 %8 %9) #(foo 10 20) ==> (fn [& args] (apply foo 10 20 args)) 2. If the value of an argument is not important use an underscore. This will free us of uses of %1, %2, ... Examples: Create a function that will produce blue colors: #(rgb _ _ 255) instead of #(rgb %1 %2 255) #(rgb _ _ 255) ==> (fn [arg1 arg2 & args] (apply rgb arg1 arg2 255 args)) Making use of point 1., now for creating green objects: #(rgb _ 250) instead of #(rgb %1 250 %2) #(rgb _ 250) ==> (fn [arg1 & args] (apply rgb arg1 250 args)) 3. Let's keep the possibility to list specific arguments as %1, %2, ... So we still want to have a function to square its argument: #(* %1 %1) ==> (fn [arg1 & args] (apply * arg1 arg1 args)) 4. Possibly allowing nested curries, where only the outer one is allowed to list specific arguments %1, %2, %3, ... All inner ones may only use the underscore syntax: #(map #(+ 3) %1 %1) ==> (fn [arg1 & args] (apply map (fn [& args] (apply + 3 args)) arg1 arg1)) As I see it the reader macro #(...) is right now implemented in Assemb... in Java. So I can't give a patch for that, but instead I hacked up this code fast, and it basically wraps the idea into a macro: (defn replace-placeholders [body] ((fn [args new-body [f & r :as b]] (if (not b) [(seq args) (seq new-body)] (cond (= f '_) (let [gensym (gensym)] (recur (conj args gensym) (conj new-body gensym) r)) :default (recur args (conj new-body f) r [] [] body)) (defn applyify [args body] `(fn [EMAIL PROTECTED] & args#] (apply [EMAIL PROTECTED] args#))) (defmacro § [& body] (let [[args body] (replace-placeholders body)] (applyify args body))) user> (filter (§ < _ 9) (range 20)) (0 1 2 3 4 5 6 7 8) user> (map (§ * 3) (range 10)) (0 3 6 9 12 15 18 21 24 27) I couldn't name the macro # as the reader would obviously try to consume it first. So, if implemented as a reader macro we could say §(< _ 9) or §(* 3) and such. This version of replace-placeholders still misses the numbered args %1, %2, .. as the reader would also steal those from me. In the end the #(..) macro would do it, instead of §. I would like to hear/read your opinions about support for currying and extending the #() macro. One thing I see as possibly critical is that my suggestion for always using apply could potentially slow down code. apply would have to do some extra work that is not needed when a function is called directly. How true is that, Rich? I imagine situations where we (map #(* 5) collection-of-10-million-numbers) and get the apply runtime hit 10 mio times. One way to improve this a little is to have all functions from the standard Clojure lib that take a fixed number of args and treat them differently, and compile into code that makes no use of apply. In such a case the 11-ary function foo would give us for #(foo _ 10 20) ==> (fn [a1 a2 a3 a4 a5 a6 a7 a8 a9] (foo a1 10 20 a2 a3 a4 a5 a6 a7 a8 a9)) ; a direct call This could be done only for the functions that come with Clojure as those are guaranteed to always do the same and can't be over- written by the user. (defn + ...) is not possible ==> java.lang.Exception: Name conflict, can't def + because namespace: user refers to:#=(var clojure/+) So, all functions written by the user must be called via apply if we curry arguments away, even if the user provided function has a fixed number of args, as the user could always exchange his old function with a new one. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Currying for Clojure
On 22 Okt., 23:24, André Thieme <[EMAIL PROTECTED]> wrote:
> This version of replace-placeholders still misses the numbered
> args %1, %2, .. as the reader would also steal those from me.
> In the end the #(..) macro would do it, instead of §.
So what I just did was extending it for this demostration by using
$1, $2, .. instead.
First we need two little helpers:
(defn digit-char? [char]
({\0 0 \1 1 \2 2 \3 3 \4 4 \5 5 \6 6 \7 7 \8 8 \9 9} char))
(defn numbered-arg? [arg]
(let [[$ & nums] (str arg)]
(and (= $ \$)
(every? digit-char? nums
Btw, something like digit-char? would be nice for the boot.clj
And now caring for the $n case:
(defn replace-placeholders2 [body]
((fn [args num-args new-body [f & r :as b]]
(if (not b)
[(seq args) (seq new-body)]
(cond (= f '_) (let [gensym (gensym)]
(recur (conj args gensym)
num-args
(conj new-body gensym)
r))
(numbered-arg? f) (if-let val (get num-args f)
(recur args num-args (conj new-body
val) r)
(let [gensym (gensym)]
(recur (conj args gensym)
(assoc num-args f gensym)
(conj new-body gensym)
r)))
:default (recur args num-args (conj new-body f) r
[] {} [] body))
As I see it this might even support nested currying if only the outer
one uses $1, $2, $3, ...
Example: #(map #(+ 3) %1 %1)
Translated §(map §(+ 3) $1 $1) and moved the § inside:
user> ((§ map (§ + 3) $1 $1) (range 1 10) (range 200 300) (range 5000
6000))
(5205 5209 5213 5217 5221 5225 5229 5233 5237)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Reader + Macros on untrusted S Expressions: Security considerations?
I was heading in the direction of generating javascript on the server for page generation, so it makes some sense to keep using that technique for communication as well. In this model the webclient is trusting the javascript the server is generating, so I have to be diligent in my code generation not to allow external untrusted input become inline code. This gives me the power of macros to generate the boilerplate js and html that is required to build out a full UI. =) On Thu, Oct 23, 2008 at 12:27 AM, .Bill Smith <[EMAIL PROTECTED]>wrote: > > Would you have S-expressions going from the server back to the client > as well? > > Bill > > > > -- Brett Morgan http://brett.morgan.googlepages.com/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Currying for Clojure
You can get most of the functionality you're looking for with partial
(map (partial * 3) (range 10)) => (0 3 6 9 12 15 18 21 24 27)
(map (partial apply max 0) (partition 3 1 (range -5 5))) => (0 0 0 0 1
2 3 4)
On Oct 22, 5:40 pm, André Thieme <[EMAIL PROTECTED]> wrote:
> On 22 Okt., 23:24, André Thieme <[EMAIL PROTECTED]> wrote:
>
> > This version of replace-placeholders still misses the numbered
> > args %1, %2, .. as the reader would also steal those from me.
> > In the end the #(..) macro would do it, instead of §.
>
> So what I just did was extending it for this demostration by using
> $1, $2, .. instead.
>
> First we need two little helpers:
> (defn digit-char? [char]
> ({\0 0 \1 1 \2 2 \3 3 \4 4 \5 5 \6 6 \7 7 \8 8 \9 9} char))
>
> (defn numbered-arg? [arg]
> (let [[$ & nums] (str arg)]
> (and (= $ \$)
> (every? digit-char? nums
>
> Btw, something like digit-char? would be nice for the boot.clj
>
> And now caring for the $n case:
> (defn replace-placeholders2 [body]
> ((fn [args num-args new-body [f & r :as b]]
> (if (not b)
> [(seq args) (seq new-body)]
> (cond (= f '_) (let [gensym (gensym)]
> (recur (conj args gensym)
> num-args
> (conj new-body gensym)
> r))
> (numbered-arg? f) (if-let val (get num-args f)
> (recur args num-args (conj new-body
> val) r)
> (let [gensym (gensym)]
> (recur (conj args gensym)
> (assoc num-args f gensym)
> (conj new-body gensym)
> r)))
> :default (recur args num-args (conj new-body f) r
> [] {} [] body))
>
> As I see it this might even support nested currying if only the outer
> one uses $1, $2, $3, ...
>
> Example: #(map #(+ 3) %1 %1)
>
> Translated §(map §(+ 3) $1 $1) and moved the § inside:
>
> user> ((§ map (§ + 3) $1 $1) (range 1 10) (range 200 300) (range 5000
> 6000))
> (5205 5209 5213 5217 5221 5225 5229 5233 5237)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Currying for Clojure
On 23 Okt., 00:28, wwmorgan <[EMAIL PROTECTED]> wrote: > You can get most of the functionality you're looking for with partial Yes sure. The thing is that currying is nothing but syntactical sugar. It's not the functionality I am missing, but it’s brevity which makes sense in functional programming style. And partial doesn't allow me to have a simplified syntax for going over specific arguments, which makes sense, so having this throw-away underscore is nice IMO. Also partial can't repeat arguments, what we now can do with %1, %1. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Data types in Clojure
On Oct 22, 6:45 pm, Chouser <[EMAIL PROTECTED]> wrote:
> Don't dismiss clojure/zip to easily. The functions defined there
> largely defer to functions stored in metadata on the object. This
> means a new type of zip tree can be provided by anyone in any
> namespace, simply by returning an object with the appropriate
> metadata.
That looks pretty smart indeed...
This leads me to a more down-to-earth question: what is the right way
to use clojure/zip in a program? First I tried
(use 'clojure.zip)
but this complains about "replace" which exists already in the clojure
namespace. After studying the doc, I decided to try renaming:
(use 'clojure.zip :verbose :rename '{replace zip-replace})
This leads to an error message that I don't understand at all:
user=> java.lang.ClassCastException: java.lang.Boolean
java.lang.ClassCastException: java.lang.Boolean
at clojure.refer__1051.doInvoke(boot.clj:1969)
at clojure.lang.RestFn.applyTo(RestFn.java:144)
at clojure.apply__135.doInvoke(boot.clj:364)
...
Who is casting which Boolean to what there? And, more importantly,
what do I need to fix in my code line?
> In order to implement Java interfaces such that clojure/seq and such
> builtin functions work, you do need to implement a Java class. This
> can be done with 100% Java code by gen-class and possibly the
> easier-to-use proxy function.
Proxy looks useful indeed, thanks!
Konrad.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
