#clojure log - Mar 03 2008

The Joy of Clojure
Main Clojure site
Google Group
IRC
List of all logged dates

9:47 middayc: is clojure currently more as an experimental on in development language or it can it be used for practical use?

9:48 rhickey: I think it's practical, but as the author I'm biased

9:49 middayc: :) well as the author you know the best where the focus is

9:50 rhickey: it is in development, but most changes are for fixes, completeness, or new features, not experimentation

9:51 middayc: nice, I don't mind changes is language is still evolving

9:56 could I use something like LWJGL from clojure instead of java?

9:57 rhickey: I don't see why not

9:57 although you can't target applets due to a Java restriction

9:59 middayc: great.. well opengl applets are very unstable anyway

9:59 I mean in regards to general public

10:01 I used java for some things and in the meantime I got consumed into these FP langs and paradigms .. now I would need to do some jvm related things but programming in java does not intrigue me that much

10:01 clojure seems very interesting from what I saw

10:02 rhickey: lisp + fp + JVM

10:02 + stm

10:05 middayc: One use for java and lwjgl is for something like 2d action game... is clojure somewhere near java speedwise? I think I noticed somewhere groowy for example was quite slower at some tests (I think it was raytracing)

10:07 rhickey: The only place Clojure should be noticeably slower than Java is in numerics - all numbers are boxed in Clojure. But Clojure + a small Java vector lib should do the trick.

10:08 middayc: aha.. so I could write computational libs in java and use them in clojure

10:08 rhickey: right

10:09 middayc: cool :)

10:09 Chouser: rhickey: do you have an opinion on conditional forms that capture a name for the test result, like arc's aif, acond, etc.?

10:09 do you hate the idea?

10:09 rhickey: anaphorics - I dislike them

10:10 Chouser: ok

10:10 rhickey: I will be adding if-let and when-let, which will take the name of the thing to be bound

10:10 Chouser: ah! ok.

10:10 so the source of the dislike is the unspecified name showing up in the enclosed block?

10:11 rhickey: yes, they don't nest, cause problems for macros etc

10:11 too cute

10:11 Chouser: well, #() does that a bit now...

10:11 with similar problems, of course.

10:12 rhickey: yes, and should be reserved for the simplest cases

10:12 Chouser: ok

10:12 rhickey: nesting #() is bad style

10:12 Chouser: I'll be looking forward to when-let.

10:12 would a cond-let be too convoluted?

10:13 rhickey: one name for all conditions or a name per condition?

10:14 Chouser: hm... I hadn't thought of one name for all. That might be quite nice.

10:14 rhickey: a lot of conditions are just boolean, not much to bind

10:14 Chouser: I was thinking one name per condition would be pretty wordy.

10:14 yep, but isn't that generally true for all these (if-let, when-let, etc.)

10:16 rhickey: depends on how you use cond

10:16 Chouser: the syntax would be: (when-let bindform testexpr block) ?

10:16 rhickey: yes

10:16 Chouser: I could probably write that... ;-)

10:16 rhickey: 10 minutes tops

10:16 Chouser: Ok, anyway, thanks for the discussion.

10:17 Not sure about cond -- just poking around is all.

10:23 hmph. doto just betrayed me. I can't think of any easy way to run one of two different methods inside a doto block (based on some test).

10:24 I'll have to refactor into "let" and a bunch of (. foo blahs)

10:25 rhickey: it would have to be more of a code walker to find . calls inside of ifs etc

10:26 Chouser: yep. more magic.

10:26 It just suggests perhaps I shouldn't have used doto at all.

10:26 it seemed so nice at first. ;-)

10:26 rhickey: probably not

10:27 Chouser: I shouldn't complain, though. Making Java interop possible is hard enough. Demanding pretty is too much.

10:30 arbscht: clojure is reasonably pretty, even

10:31 (I say that having used Foil :-)

10:33 rhickey: doto is already more concise than the equivalent java

10:34 but I think the next level up is something like with-slots for Java objects

10:34 naming the object and its pieces

10:37 ericthorsen: Rich: I've come across a couple of scenarios where I need to return iterators / enumerations on clojure seqs to a java framework.

10:37 rhickey: all the collections are Iterable

10:37 ericthorsen: I wrote a simple wrapper that uses a ref to modify the state of a proxy since I always have to return the same reference back on the java side

10:37 hmm...

10:38 rhickey: there's also SeqIterator which turns any seq into an Iterator

10:38 ericthorsen: That's much nicer of course...but I needed an Enumeration

10:39 rhickey: for what?

10:39 ericthorsen: it does bring up a general question about plugging java objects into existing frameworks implemented in clojure

10:39 TreeNode.children returns an Enumeration

10:41 rhickey: aargh - I wish they had gotten it right the first time

10:41 ericthorsen: i know...

10:42 rhickey: 2 'standard' iterators is silly

10:42 I can provide equivalent bridges to/from Enumeration

10:43 ericthorsen: it would be useful since everyone is going to come up against this

10:44 In cases where I'm handing off a java object to a framework that is expecting side effects to change the state of the object, the model would be to use references and transactions in the proxy yes?

10:48 rhickey: that's one way.

10:49 it would allow those objects to participate in enclosing transactions

10:52 SeqEnumeration is up

10:57 ericthorsen: thanks!

10:58 what is another way ?

10:58 no transactions?

10:59 rhickey: without transactions you devolve into Java's mutable state model, can just use clojure.lang.Box - don't call me with problems :)

10:59 ericthorsen: i know that...that is why I asked what is another way? I did not think that is one you were referring to

11:01 rhickey: that's pretty much it, safety or not, there's not really a per-thread-binding notion in normal Java objects, so no advantage of Var over Box

11:01 ericthorsen: ...shy or storing the state somewhere else I mean...I'm fine with this option. I was just curious as to whether there was another option you had in mind for this scenario

11:01 ok

11:03 rhickey: EnumerationSeq and support for Enumerations in seq is up

11:09 Chouser: (let [[foo bar] [1]]) --> java.lang.IndexOutOfBoundsException

11:09 was it silly for me to expect bar to be nil?

11:11 rhickey: it is documented to use nth, which is documented to throw on out-of-bounds

11:11 Chouser: ok

11:12 rhickey: if you might have more stuff, you can use &

11:12 Chouser: yep, thanks.

11:13 rhickey: (let [[foo & [bar]] [1]] [foo bar])

11:13 Chouser: I have a cond-let working, with a single binding form. But so far I'm only using it like an "if", so I'm not sure yet if a single binding form makes sense in general or not.

11:13 rhickey: [1 nil]

11:13 Chouser: oh! fantastic.

11:15 rhickey: full destructuring is available for the & parameter

11:16 Chouser: makes sense, just not an idiom I had thought of. nice.

12:19 arbscht: does it make sense to define a multimethod with no args?

12:22 would it be too non-functional to have arbitrary dispatching functions rather than only functions of the args? as it is that's possible for args>0

14:20 rhickey: dispatching function of no args? does it call rand or something?

14:33 arbscht: or something

14:33 let's say it depends on a mutable variable

14:35 there's nothing stopping me defining a dispatching function with non-zero arity and ignoring the arguments to do something like that

14:36 rhickey: or put an ordinary function in front of it, that reads var, passes something to multimethod

14:36 arbscht: right, that's how I've got it now

14:36 rhickey: probably easier for the next guy to understand that way

14:39 arbscht: maybe. my first instinct was to try it with no-arg multimethods, but that might just be me

19:41 rhickey: sets are coming, any syntax preference:

19:41 #[a b c]

19:42 #{a b c}

19:42 something else?

21:40 Chouser: Running out of brackets... <a b c>

21:41 rhickey: still haven't decided to take away <, >

21:41 Chouser: yeah.

21:42 #[] isn't bad. # is starting get pretty diluted.

21:43 rhickey: ever used CL?

21:43 Chouser: [|a b c|]

21:43 not really. I "learned" lisp in CL from "On Lisp", but never wrote more than a few functions in it.

21:43 rhickey: I think the double chars are tricky for editors

21:43 Chouser: ah, good point.

21:44 I was thinking | suggests alternation which is sorta related to sets.

21:44 |[ ]

21:44 or maybe not.

21:46 ^[]

21:46 rhickey: right now it's #{a b c}

21:47 #[a b c] seemed to imply that nth would work, to me

21:49 Chouser: ok

21:49 also (make-set a b c) or something?

21:49 rhickey: hash-set, sorted-set, contains?, conj, disj, count etc

21:50 it's up now

21:51 Chouser: so fast. makes my head spin.

22:19 albino: in python they had to go to a more literal translation set()

22:19 {} for dictionarys [] for lists and () for tuples

23:22 Chouser: I'm so used to using hashes for that, I just forget to reach for sets.

Logging service provided by n01se.net