Is this a good idea? (merging let, cond and ->)
I was developing this project of mine, which has an intricate business logic, and I wrote a macro that makes programming this kind of stuff more comfortable. It's called "ilet", which stands for "implicit let". The name is probably no longer appropriate, since I added more features to it, but I can't make up anything better right now. I'd really appreciate it if you could dissuade (or persuade) me from posting this to clojure-dev for inclusion in contrib. I need to know if this could be useful to someone besides me. Here's the rationale of the ilet macro. (Warning: the examples are silly. See below for a real world example.) We have "->" in Clojure because it lets you do dataflow-programming- like manipulations. The first version of ilet was used in a similar way, but it simply bound a symbol ($). It works like "->" but it's more flexible, because you can put the value of the previous expression wherever you want (e.g., see http://pastebin.com/g7k8wK4a). This is nice, but it's often useful to bind symbols explicitly. Using a "let" inside an "ilet" is clunky, so I added this capability inside "ilet" itself. If you write [symbol] [expression], ilet interprets that as an explicit binding (see http://pastebin.com/2VJ8D738). Finally, I wanted to be able to interrupt this kind of calculations. Unfortunately, Clojure doesn't provide any return-like constructs: you'd need to use if's and cond's. So I added a new syntax to ilet: "<" [condition] [expression] where if [condition] is true, the value of the whole ilet expression is just [expression] (see http://pastebin.com/np2M9kZr). I hope my explanation was clear, in spite of my poor English. This is the definition of the ilet macro: http://pastebin.com/nHLifsu3 And this is a real world example, straight from my repository: http://pastebin.com/xGQT1c5h Thank you all for your input! -- 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
Re: Is there a way to make a symbol throw an exception, when it's referenced?
Thank you for your insights. You guys seem to think I'm doing something wrong, and you may be right. I'll see if I can come up with an alternative solution. Damn bone-head of mine. -- 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
Is there a way to make a symbol throw an exception, when it's referenced?
I'm writing a macro that defines a symbol through let, but I also needs to unbind (unlet?) it, so that further uses of that symbol throw an exception. I hoped I could use symbol-macrolet, but local symbols are protected from expansion Thanks! -- 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
Re: A multiple-inheritance prototype system
> It looks like you're trying to group together different functionality > in one place. Idiomatic Clojure tends to encourage separating > functionality out into independent components. Thanks for the tip. My system doesn't provide validation, it just differentiates between "nil" and "undefined but mandatory". It also checks to see if there's a conflict betweeb inherited values, but this is something any system with multiple inheritance must do. Finally, it keeps track of objects' ancestors, so that I can see that a :smartphone is-a :phone and is-a :pc, and so on. -- 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
A multiple-inheritance prototype system
Hi clojure developers! I recently wrote an alternative datatype system for a project of mine, because requirements were a little odd and I couldn't find anything appropriate. My questions are: 1) Was this necessary at all? Can my requirements be fulfilled with off-the-shelf clojure libraries or components? Requirements include the ability to merge objects as shown below. 2) Do you think this system would be useful to the clojure community? Should I clean it up and publish it? The best way to show how it works is with an example: ; This create a product "class". The "mandatory" function ; returns a special value which throws an ; exception when it's read. ; Sort of like a pure virtual method. (defobject :product [] :name (mandatory) :price (mandatory) :warranty (mandatory)) ; PC's have 1 year of warranty by default in our shop (defobject :pc [:product] :cpu (mandatory) :ram (mandatory) :warranty 1) ; Mobiles instead get 3 (defobject :mobile [:product] :battery-idle-time (mandatory) :warranty 3) ; This FAILS: the system tries to inherit the :warranty property ; from both parents but a conflict occurs (because the values are different) (defobject :smartphone [:pc :mobile]) ; We must override the :warranty property. This works: (defobject :smartphone [:pc :mobile] :warranty 2) ; Then we can create an "instance"... (defobject :zamzun-universe [:smartphone] :cpu :z80 :ram "1GB" :battery-idle-time "300h") ; ...and use it (fetch (object :zamzun-universe) :warranty) ; -> 2 -- 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
Re: Possible bug in with-symbol-macros, interacts badly with case
I digged a little and I have a patch. I modified the case* parser in
Compiler.java, so the patch shouldn't affect anything else: I prefer
keeping safe since my knowledge of Clojure internals is limited, but a
more radical solution might be desirable.
The problem seems caused by the way case* gets constructed. The 7th
parameter is a hash-map that is passed directly to the compiler
(Compiler.java). The values of this hash-map are instances of the
MapEntry class.
When a case call is macroexpanded, those MapEntry instances get
printed out as vectors. When they are read back and evaluated, they
become instances of PersistentVector and the compiler barfs. Since
case* arguments are not evaluated there's no way, as far as I know, to
pass a MapEntry object to case* by calling it directly since there's
no such thing as a MapEntry literal.
My patch modifies case* so that it can handle a PersistentVector and
make a new MapEntry from it.
I'll post the patch here directly, since it's only a few lines long. I
hope it's not too rude. It's against git master branch.
--- Compiler.java.orig 2010-09-11 14:35:07.0 +0200
+++ Compiler.java 2010-09-13 12:12:12.033621364 +0200
@@ -7445,7 +7445,13 @@
{
Map.Entry e = (Map.Entry) o;
Integer minhash =
((Number)e.getKey()).intValue();
- MapEntry me = (MapEntry) e.getValue();
+ MapEntry me = null;
+ if (e.getValue() instanceof
PersistentVector) {
+ PersistentVector pv =
(PersistentVector) e.getValue();
+ me = new MapEntry(pv.nth(0),
pv.nth(1));
+ } else {
+ me = (MapEntry) e.getValue();
+ }
--
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
Re: Possible bug in with-symbol-macros, interacts badly with case
I found a workaround: (use 'clojure.contrib.macro-utils) (defsymbolmacro one 1) (defn bug1 [] (with-symbol-macros (bug2))) (defn bug2 (case 0 0 one))) The "one" symbol macro is there just to show that everything works as expected. -- 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
Possible bug in with-symbol-macros, interacts badly with case
I wrote a test case: (use 'clojure.contrib.macro-utils) (defn bug? [] (with-symbol-macros (case 0 0 1))) The REPL prints: java.lang.ClassCastException: clojure.lang.PersistentVector cannot be cast to clojure.lang.MapEntry (NO_SOURCE_FILE:4) Can anyone confirm this, please? -- 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
Re: Generating functions programmatically
Yes, Kent's solution is spot on! Thank you all for your insights, I believe we have a winner. -- 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
Re: Generating functions programmatically
Hi Btsai, thank you for your offer for help. As I said before I *could* use literals but it wouldn't be convenient. I have a big structure which contains information about "types" (they are types of domain-specific objects). I would like to extract the "methods" I need from this structure and define them programmatically. Previous solutions to this problem (both by me and other helpful posters) required to pass keywords as literals. While I could do that, maintaining a separate list would be a hassle. Right now I'm using: (doseq [t (an-expession-which-extracts-a-list-of-keywords)] (eval `(defobjecttype ~t))) So the problem is solved for me, although I have to use eval. I'm not sure exactly how dirty this trick is and especially *why* it is considered a "smell". I read it on Paul Graham's "On Lisp" and he vehemently opposes its use but he doesn't explain why or where it is acceptable. Note that he also considered Common Lisp "let*" a smell, which is standard practice in Clojure (and in fact there's no equivalent of Common Lisp "let"). So maybe we are just making too much a big deal of this "eval" thing. I feel however that this problem should be addressed by the macro system somehow (although maybe that's not possible by design). If someone could find a solution which doesn't involve eval it would definitely be more elegant. -- 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
Re: Generating functions programmatically
You are mostly right in your assumptions: I could dump the keywords in the clj as literals but it would be tedious and not elegant at all. Eval's not pretty but it works; plus it's there for a reason, like working around the shortcomings of the language (and of my brain). I was about to post my solution but I won't, since it looks exactly like yours. Thank you guys for your efforts! -- 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
Re: Generating functions programmatically
Yes, I think I'll have to pass the keywords as literals. I don't think there's a way around that (other than using eval, as per Alan's solution). I was too excited about Hubert's hint and I found myself in the exact same problem with the second macro. -- 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
Re: Generating functions programmatically
I agree: eval never looks pretty. -- 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
Re: Generating functions programmatically
Yeah, I guess I could use a macro to generate the "call" to the other macro in a way similar to how you used it. Thank you, that should definitely work. I'll try it right now. -- 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
Re: Generating functions programmatically
Alan, thank you for your reply. Unfortunately your solution is very similar to mine and it suffers from the same problem (maybe I'm using it incorrectly, I don't know). If I write: (doseq [x '(:a :b)] (make-fn x)) it defines a single function "synthetic-x". Is there a way to make this work? I tried everything but both eval and var-get don't work for local bindings. Thanks again. -- 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
Generating functions programmatically
Hi, I'm developing a small DSL with Clojure and I need to define many similar functions. I'd like to do that programmatically, of course. My solution (involving a simple macro) doesn't work, so I won't bother you with it. I'll post it if anyone asks. Basically what I need is: given a list of keywords, for each keyword x i need to define a function whose name is (str "prefix-" (name x)). The function has a very short body which uses x in one place (something like (fn [n] (= n x))). Can you help me please? I've been banging my head against this for over four hours and I'm getting a little frustrated. Thanks. -- 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
Lisp indenter for Kate
I wrote a Kate script to make lisp development on Kate a little more pleasant. It was written primarily with Clojure in mind, so it should work best with this language, but it's pretty generic. If you use Kate, please try it and feel free to add a comment to the kde bug report (see below). You can find the script here (read my first comment carefully): http://bugs.kde.org/show_bug.cgi?id=207002 Just place it under ~/.kde4/share/apps/katepart/script (you might need to create this directory) and choose "LISP" from "Tools > Indentation". This overrides the default lisp indenter. Thanks! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Tight loop performance
@Christophe: thanks, your hint helped. @B Smith-Mannschott: > Questions about how best to optimize clojure code to approach java > performance have come up with fair regularity in the past. You might > find some good ideas if you search through the archives a bit. I see. As I said before (OP), I believe that the docs, to a certain extent, imply that Clojure is (or should be) as performant as Java. If the same level of performance cannot be obtained (at least in some cases) it should be pointed out. This would set up more realistic expectations for Clojure's users and avoid unneeded discussion. Otherwise you end up thinking you're doing something wrong because your code is so slow and you write posts trying to understand how to write better code. > This isn't always possible though, but that's where Clojure's Java > interop and a little pragmatism comes in: You've got there a nice > piece of Java code that does what you need and it's fast too. If you > want that speed from your Clojure code, don't waste time optimizing > the Clojure, just call the java implementation. > (I guess I'm not much of a purist.) That's exactly my solution. But, again, I believe the docs should be corrected so that people don't waste their time trying to hopelessly optimize their code. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Tight loop performance
Nicholas, thank you for your reply. I applied the change you suggested. Unfortunately it skimmed only about 50ms from each exectuion. Even though I'm using aset, java.lang.reflect.Array.setByte *still* uses ~25% of execution time. This means two things: A) Reflection is still used for this code. B) Even if we could reduce reflection to zero, Clojure would still be the underdog, by far. Undated benchmark: "Elapsed time: 465.620154 msecs" "Elapsed time: 5.256433 msecs" "Elapsed time: 465.751133 msecs" "Elapsed time: 3.377667 msecs" "Elapsed time: 472.59319 msecs" "Elapsed time: 3.117197 msecs" "Elapsed time: 478.251893 msecs" "Elapsed time: 3.422244 msecs" --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Tight loop performance
Hello!
First of all, let me congratulate with the devs for their great work:
I've been using Clojure for just a couple of weeks and I had a lot of
fun learning it and experimenting with it.
I'm starting a concurrency-heavy project and I feel Clojure is gonna
be a great choice!
I'm thinking about opening a ticket but I'm not really sure. Let me
explain.
Both clojure.org and the
Pragmatic Bookshelf book seem to imply that Clojure's performance is
equivalent to Java.
If you need an example just look here:
http://clojure.org/java_interop, under "Support for Java Primitives".
Clojure's performance is great (much better than many other Lisps) but
I hit a "performance wall" in one of my functions.
This was not tragic at all: I just wrote a few lines of Java and I
built a new Java class.
It might be a problem with my code, but I read all performance-related
articles I
could find and I cannot improve things much more than this.
Basically, I want to convert a short[] to a byte[], a common need when
dealing with audio. In Clojure I wrote:
(defn shorts-to-bytes [#^shorts src #^bytes dst words]
(loop [src-offset (int 0)
dst-offset (int 0)]
(when (< src-offset words)
(let [sample (short (aget src src-offset))]
(aset-byte dst dst-offset (byte sample))
(aset-byte dst (inc dst-offset) (byte (bit-shift-right sample
8
(recur (inc src-offset) (unchecked-add 2 dst-offset)
Adding type coercions helped a bit but it's still too slow. In Java
I wrote this method:
public static void shortsToBytes(short[] src, byte[] dst, int len)
{
int idx = 0;
short s;
while (len-- > 0) {
s = src[idx];
dst[idx*2] = (byte)s;
dst[idx*2+1] = (byte)(s>>>8);
idx++;
}
}
Then I timed them under both Clojure 1.0 and 1.1.0-SNAPSHOT and got
similar results.
[...]
(doseq [n (range 5)]
(time (shorts-to-bytes a b 512000))
(time (ArrayConverter/shortsToBytes a b 512000))
(println))
"Elapsed time: 516.527512 msecs"
"Elapsed time: 32.316904 msecs"
"Elapsed time: 472.034037 msecs"
"Elapsed time: 5.096593 msecs"
"Elapsed time: 437.755411 msecs"
"Elapsed time: 4.10872 msecs"
"Elapsed time: 535.864767 msecs"
"Elapsed time: 3.106442 msecs"
"Elapsed time: 880.127444 msecs"
"Elapsed time: 3.124339 msecs"
So Java outperforms Clojure by two orders of magnitude.
Is there anything wrong with my code? I've been fine-tuning this code
for a couple of days now, to no avail.
Thank you and keep up!
Matt.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Newbie - the method I cannot call
On Aug 25, 5:51 pm, tmountain wrote: > Clojure 1.1.0-alpha-SNAPSHOT Maybe it was a bug and they fixed it. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Newbie - the method I cannot call
Hey, this works! Thanks!! I was wondering... why doesn't casting work? i.e. (.open (cast SourceDataLine sdl) fmt (* 48000 2 2)) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Newbie - the method I cannot call
On Aug 25, 4:50 pm, tmountain wrote: > I'm pretty sure your issue is that format is a function inside > clojure.core, so it's causing a conflict. I renamed it, and the code > seems to work on my machine. Using another name, unfortunately, doesn't fix the problem here. But the fact the my program works for you is interesting in itself. I'm using clojure v1.0.0 and openjdk6 v1.5.1. Can you tell me what versions you're using, please? Maybe it's just a bug. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Newbie - the method I cannot call
Hi, I've been struggling with this problem for some time and I don't understand why this doesn't work. I'm trying to call the "open" method of a javax.sound.sampled class but it throws the following exception: No matching method found: open for class com.sun.media.sound.DirectAudioDevice$DirectSDL. Please give it a look and tell me what you think. The code is not robust and might fail on your system for other reasons (probably harware-related). DirectSDL extends SourceDataLine. The method I'm trying to call is documented here: http://java.sun.com/j2se/1.4.2/docs/api/javax/sound/sampled/SourceDataLine.html#method_summary Using the commented line, which casts everything explicitly, yields the same result. Calling the method without parameters (Line class) works, but that's not what I need. Also, I know the method exists because it shows up when I extract the object's methods: # Here's the code: (import '(javax.sound.sampled AudioSystem AudioFormat DataLine DataLine $Info SourceDataLine TargetDataLine AudioInputStream)) (def format (AudioFormat. 48000 16 2 true false)) (def sdl-info (DataLine$Info. SourceDataLine format)) (when (not (AudioSystem/isLineSupported sdl-info)) (throw (RuntimeException. "Unsupported format."))) (def sdl (AudioSystem/getLine sdl-info)) (.open sdl format (* 48000 2 2)) ;(. (cast SourceDataLine sdl) open (cast AudioFormat format) (int (* 48000 2 2))) Thanks for your help. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
