0:55slyrus: chouser: earlier we were talking about the "type" that extend takes and you said that it's a type/class/interface. can it extend a protocol?

1:31 ok, here's the situation I find myself in repeatedly. I define a protocol. I have some "low-level" issues that are handled by, say, a defrecord, then I want to define some operations that work on objects that implement that protocol. I can just have these operations be defns, or I can extend the original protocol and the defrecord to match. Is there anything "in between", like defining...

1:57mmarczyk: as I said above, the ^EdgeSet type hint is actually misleading the compiler

1:57Lajla: mmarczyk, accordingly Sigmund freud your hooking up of that bot to ignore me is the manifestation of a subconscious desire of yours to ban me, hit me and tell me that I'm insane and should have a talk with Signund Freud.

1:57slyrus: my puny brain is still wired for CLOS' defgeneric and defmethod.

1:58mmarczyk: because type hints have to do with Java types and reflection

1:58* slyrus treats java like he treats CLASSPATH. if he ignores it long enough, it will go away :)

2:43slyrus: Ok, here's an issue. I've got a protocol, I extend-protocol a primitive type (IPersistentMap) and I want to have a function/method that works on that. Then I have a different defrecord, I want the same-named function/method to work on that. In this case it's the neighbors function. How can I do that?

2:47Chousuke: slyrus: just implement the protocol directly in the record definition

2:48 slyrus: it should be preferred over the more generic implementation

10:38raek: dnolen_: I think your clj script fills the gap between leiningen project management and launching scripts from the command line pretty well

10:39Raynes: rhudson: sexpbot apologizes. -> is the new code-evaluation prefix. It's the only thing I could think of that's easy to remember and type that nobody will type in a channel and set it off accidentally. Guess I failed on the latter though. But that has only happened just this once so far. ;)

10:39mfex: lozh: I was hoping to find something called "best" or something that combines sort-by and first, to no avail so far

11:36Kaali: Hi everyone, I made a small web form validation library as a practice project on Clojure. http://github.com/Kaali/pour -- I wanted to use assert-args included in Clojure, but it's a private fn. Was it okay for me to copy it to a file with the copyright from Clojure's core.clj included and also Rich Hickey's copyright included in the README?

12:19Kaali: I actually tried to remove them, but partition converted them to a list, which somehow broke it; but that's just me being a Clojure newbie.

12:19raek: (*if* your goal is to mimic clojure syntax as closely as possible, then :password [required "Password is required" (minimum-length 5) "Password should be at least 5 chars long"] could be considered)

12:33jli: are there many people here who are more used to strongly-typed functional languages? common lisp was my first functional language, but I've been doing OCaml and Haskell for the past couple of years, and I'm just learning Clojure now

12:35Kaali: raek: Yeah, it seems to be a cleaner version of what I do with map all the time.

13:03rhudson: jli, it seems to be partly a matter of temperament and taste. It's always a little embarrassing to find something in initial testing that a type system would have caught. But my experience is that very very few lingering bugs in dynlang code I've written are things that a stronger type system would have pointed out.

13:04jli: rhudson: I think the advantage of strong typing is much stronger when you have a huge code base. the compiler/type system does its error checking over the whole world every time you compile. it's kind of scary to me that you can have obvious bugs in dynamic code that you don't know about just because it's down a code path that is rarely used

13:05Kaali: raek: If the library gets users, I guess the feedback will say if this problem needs a solution.

13:11rhudson: jli, I won't really argue that point, except to say that I've seen people get a false sense of security on big code bases because it all compiles. :)

13:11 I do have a sense that Clojure 1.2's protocols and datatypes will help in large code bases. "Types when you need them."

13:13Kaali: It's true that required validator is more like not-empty validator right now. My first hunch would be to fetch the fields and give a default value of nil for the missing fields. This would force the validator evaluation, but this would require some way to short-circuit the validators for optional but nil values.

13:13jli: rhudson: yeah, it can absolutely deceive you, like with polymorphic functions in OCaml like compare and equal. Haskell does this better, with its typeclasses, but there are certainly still lots of bugs that aren't catchable with type systems

14:15qbg: I believe there are some methods that let you do that in clojure.lang.RT

14:15rhudson: TakeV: One way is an implementation of javax.script interfaces ScriptEngine{,Factory}. (also known as "JSR-223". ScriptEngine provides facilities to bind variables on the Java side and retrieve the results. I've seen a couple of implementations around github etc.; dunno if they're current

15:43raek: paredit will close with the "right" parent, no matter which one you try to write

15:45lpetit: qed: I guessed this one. Now please, assume paredit.el is smarter than today, and that unbalanced things are not a problem. Which behaviour would you like in this precise case ? I have 2 interesting ideas:

15:45 qed: 1. jump to the end of the string, just after the closing square bracket

15:56qed: I'm not saying I wouldn't use your version and give it a fair shake, but black/white is sort of the point for me

15:56lpetit: I'm currently enhancing my clojure grammar so that even not-well balanced things get you some behaviour. E.g. if you have "([)]" it's analysed as two nested "weird" (chimera) forms. You can stil use the form selection commands on it, it parses correctly so you still have correct auto-indentation ...

16:04lpetit: hmmm, the fact is I'm partly focusing on this because I've implemented all paredit commands on top of the hypothesis that I have a parse tree. For example if at the end of the buffer there's a problem which makes the parser return no parse tree, it's currently impossible to have auto-indentation even between the first and second line

17:03lpetit: why wouldn't you want it to be able to recognize bar and select it ? What if bar were a more complex expression, and you don't care for this malformed ] yet. Same if ] is the end of the line.

17:04 From the recent conversation in the ml post I started, there seems to be a lot of people who do not want to be restricted to working with always good looking code.

18:00rhall: anyone got any thoughts on why swank.core/break shows "No Locals"? I've searched through clojure-log and found that I need to upgrade to 1.2.0 and clojure mast and contrib... did that... still "No Locals"