2008-08-07
| 03:32 | cemerick | rhickey: a classpath-aware clojure.lang.Script patch is on the group now. I've actually come to be fond of the '@' notation, amazingly enough. |
| 03:38 | rhickey | cemerick: patch applied - thanks! |
| 03:39 | cemerick | rhickey: No, thank you :-) Q: what is the fate of the UTF-8 patch (or any other default encoding)? |
| 03:52 | rhickey | cemerick: going through it now - shouldn't loadResourceScript use UTF8 as well? |
| 03:53 | rhickey | cemerick: nevermind, got it |
| 03:55 | cemerick | rhickey: I was surprised by your message regarding preventing macros from being passed as arguments. |
| 03:55 | rhickey | cemerick: how so? |
| 03:56 | rhickey | people trying to apply or map macros is a common problem |
| 03:56 | cemerick | well, short of the wrongness of applying them, being able to pass macros around and use them as if they were regular functions is really, really useful |
| 03:56 | cemerick | well, then apply should check that |
| 03:56 | rhickey | that's not behavior you should depend upon, the fact that macros are functions is an implementation detail, could change |
| 03:57 | cemerick | oh, but what a glorious implementation detail! |
| 03:58 | cemerick | the alternative is to define foo-macro, and then a fn named foo that uses foo-macro, just so you can pass around foo. The current state of affairs is preferable, IMO. |
| 03:59 | cemerick | or, the current state of affairs, modulo some prevention of macro application |
| 03:59 | rhickey | cemerick: what's a real use case |
| 04:03 | rhickey | cemerick: UTF-8 is up |
| 04:05 | cemerick | rhickey: sorry, phone's going nuts already. Excellent. |
| 04:06 | cemerick | An acquaintence of mine is working on a logic programming "environment" in clojure that uses macros to define certain predicate operations, and I know he passes those around like mad. |
| 04:09 | cemerick | another use case are declarative "DSLs" where certain words are in function position as macros as well as used as arguments to other macros (so you can neatly reuse those definitions, etc) |
| 04:10 | cemerick | Not that you couldn't just use functions for these things -- just that being able to use macros, and treat them as functions (short of apply) makes for clearer, shorter implementations. |
| 04:35 | rhickey | cemerick: I would question whether that passing shouldn't be of the macro name rather than its value. Are they really calling the macros at runtime? Are the forms returned by the macros useful at runtime? Don't they want the evaluation of the expansion and not the expansion itself? |
| 04:36 | cemerick | In the case of the logic programming, yes, they're definitely being called at runtime. And yes, one would (almost) always want the evaluation of the expansion, which you get for free by treating it as a function (again, short of using apply). |
| 04:37 | cemerick | passing the macro name instead of the macro itself requires that the receiver either be a macro or know to eval the macro name. |
| 04:37 | rhickey | no you don't get the evaluation of the expansion by treating the macro as a function, you just get the expansion |
| 04:39 | rhickey | user=> (def andf (.get #'and)) |
| 04:39 | rhickey | #'user/andf |
| 04:39 | rhickey | user=> (andf 1 2) |
| 04:39 | rhickey | (clojure/let [and__179 1] (if and__179 (clojure/and 2) and__179)) |
| 04:48 | cemerick | rhickey: Given that, I'm stunned how the code that I have that uses import-static works at all. |
| 04:49 | cemerick | or, confused more than stunned, perhaps |
| 04:50 | cemerick | thinking about what a macro is (fn that returns forms), I'm not sure how it could possibly work. |
| 04:52 | rhickey | cemerick: I don't think it can: |
| 04:52 | rhickey | (import-static java.lang.Math floor) |
| 04:52 | rhickey | user=> (map (.get #'floor) [1 2 3]) |
| 04:52 | rhickey | ((. java.lang.Math (floor 1)) (. java.lang.Math (floor 2)) (. java.lang.Math (floor 3))) |
| 04:53 | cemerick | well, it's passing tests as we speak, so something very funky is going on |
| 04:53 | cemerick | obviously my problem, though |
| 04:55 | rhickey | thus the change - users that really do need this and are willing to risk the implementation-detail dependency can always use (.get macro-var) to get the macro fn |
| 08:57 | drewr | rhickey: You've been putting in some late nights. |
| 09:19 | rhickey | drewr: seems like more early mornings |
| 11:38 | Chouser | I haven't been paying attention for the past few days -- any further interest in gen-interface, or is it a boondoggle? |
| 11:39 | Chouser | And what about the test-case wiki? any progress or conclusions? |
| 11:46 | rhickey | Chouser: off to my semantic web talk - I think gen-interface will work out, will try to look at it tomorrow, no further word on test wiki |
| 11:47 | cemerick | Chouser: Hi there -- I ended up not using it, due to the javadoc requirement. Might come up again, tho. |
| 11:48 | Chouser | ok, thanks guys. |
| 13:11 | shoover | I'm interested in contributing to test.clj. I'm not too concerned if there's a wiki or not, as long as I can work in my normal dev environment and send patches. |
| 13:33 | Chouser | shoover: do you use a VCS currently? Subversion? |
| 13:33 | shoover | yep, Subversion and Mercurial |
| 13:34 | shoover | I do like the idea of a wiki, but someone like rhickey needs a file that's sitting there with his code so he can just run it. |
| 13:34 | Chouser | my current thought (which as usual is probably over-complicated) would be to provide a repo with one test per file, plus a pretty web front-end to view and even edit and run the tests. |
| 13:35 | shoover | It doesn't seem like the Clojure way to have lots of little files, but the web front end idea is interesting. Have you looked at FitNesse? |
| 13:35 | Chouser | if we put all the tests into one file and try to use a VCS, will have constant conflicts as people try to append their tests. |
| 13:36 | shoover | True re: conflicts. It depends on how many people work on tests. |
| 13:37 | Chouser | indeed -- and when they work on them. |
| 13:39 | albino | one test per file is way way better than one file for all tests |
| 13:39 | Chouser | hm, FitNesse clearly has a similar idea at work. |
| 13:39 | albino | or at least a suite of testcases per file |
| 13:40 | shoover | albino: Yes, suite per file is nice, once you have a body of tests and can see where to break it into suites. |
| 13:40 | Chouser | I was also thinking that tagging the tests might be useful, so you could search for, I dunno, "math" and get a bunch of guaranteed-to-work examples. |
| 13:41 | albino | are you guys going to write your own unit-test lib or just use junit? |
| 13:41 | albino | s/lib/lib or runner |
| 13:41 | Chouser | I don't know enough about junit to know if it's a good fit or not. |
| 13:42 | cemerick | junit is really painful to use in clojure, IMO |
| 13:42 | cemerick | contrib's test-is is really fantastic |
| 13:42 | albino | I'm sure one of you guys could whip up an equivalent basic functioning junit with clojure like feel pretty quick |
| 13:44 | albino | I'm used to python's nose where tests are grouped into classes and each class has a setup() method and teardown() method with test_*() methods in between |
| 13:44 | shoover | I've been meaning to check out the existing Clojure test options. I just saw this one in the wiki: http://gnufoo.org/clojure/unit-test/README.html |
| 13:44 | cemerick | albino: I think test-is is what you'd be looking for in that case, although junit's model (search for and run static impl's of TestCase and TestSuite) doesn't really map up with clojure |
| 14:54 | shoover | test-is looks nice. I like how it integrates with the rest of Clojure. If any var in any ns has a :test metadata, it gets tested by test-is/run-all-tests. |
| 14:54 | shoover | And tests defined with test-is/deftest work out of the box with clojure/test |
| 14:55 | shoover | Perhaps some of the output ideas from unit-test (linked above) could be ported to test-is. |