5:59 I have a Java method with the signature: blah(String�a, String�e, long�i, boolean�o); am I calling it wrong by calling it like (.blah ClassName "a" "e" (* 1000 (.currentTimeMillis System)) false)?

8:01askentask: but as programsize grows id like help on that verification by a program. mostly it is the simple stuff i need to get fixed. like if forget to change something somewher eand it says "1" + 4, those are the things a static system would fo better than me

8:02 tWip: i find the ghci haskell repl to be quite good(ebven if it doesnt allow the whole ghc)

8:03philscotted: tWip: Right. Redefining functions on the fly, for instance. You can't do that with ghci.

8:05tWip: especially good with server software that has a long startup

8:15philscotted: askentask: In practice, I haven't found those sort of type errors to dominate, and I certainly haven't found them to be a big deal. Besides, with a decent Lisp allow interactive testing and allow you to rebind functions at the toplevel and have the effects propagate properly (unlike Python, say),

8:16 In practice, I haven't found those sort of type errors to dominate, and I certainly haven't found them to be a big deal. Besides, with a decent lisp you can interactively test your functions to iron out those sorts of errors, and when you can rebind functions at the toplevel and have the effects propagate properly (unlike Python, say) you can get rid of those errors pretty quickly.

8:17 In the end, I find the advantages of a dynamic language to be far greater. And in something like Common Lisp, the combination of a debugger and condition system may allow you to correct any missed errors on the fly and continue running the program as if nothing had ever happened.

8:24philscotted: In Python, when I redefine a class at the toplevel, existing instances of that class are unaffected. This is really annoying for interactive testing and debugging.

8:25askentask: i like also like in haskell i can do: :type f and it tells me specifially what it does rather than jus the variable name. if i do in clojure: (defn update [coll index newlist]...) i want to do :type update and get: [[a]] -> Int -> [a] -> [[a]]

8:26 i see about servers yes, so instead of restarting the program you can change things at runtime, that wouldbe a great advantage yes

8:26philscotted: askentask: Not sure how Clojure behaves on this one. But CLOS will call change-class on all instances when you redefine classes.

8:36Pupeno-G: I'd like clojure-mode to change between different possible tab levels when tab is pressed again, like the python mode (for semantic purposes) or that cool javascript mode (for extra coolness and because Javascript is a mess).

8:38 it would be okay if I had to modify the tab to change it, but I tend to hit tab randomly on lines to make sure they're indented properly

8:38gnuvince: You just need to remember not to try and code like you have a dynamically typed language when you're using a statically typed language and vice-versa

8:39philscotted: Ocaml's static duck typing is another matter though. Here, an object is automatically typed by an implicit interface which includes precisely those functions which are actually *required*. It allows for a lot more flexibility, heterogenous collections (without the headache of defining variant types). However, it's part of the OO extensions (which I tend to avoid anyway), is restricted to single-dispatch. Oh, and it's Ocaml.

8:39H4ns: Pupeno-G: with lisp, there usually is one (1) correct indentation for every line.

8:39Pupeno-G: duck1123: the first tab should leave it where it is if it's a valid tab.

8:43H4ns: Pupeno-G: certainly - i would prefer the first, but i always stick to what the editor does for me. that is the only way to get consistent indentation. reasonable editors provide you with hooks to control your indentation.

8:43Pupeno-G: H4ns: but clojure-mode gives you the second, and it doesn't have any way to know you want the first.

8:43duck1123: I tend to fiddle with my code to get it to look the way I want

8:58askentask: hmmim rewriting my clojure-oo-system. used refs from the start but yesterday someone said just pass along the updates without refs might be better. I want it o to fit in with clojure-style programming. and i want something a bit more elaborate than defstruct.

9:04 hmm im wondering should i have refs in the class or refs or soemthinc classes get assigned to later. i must separate the definition of a class from the creation.

9:05rhickey: askentask: If you really want to do an object system for Clojure, you need to totally understand this: http://clojure.org/state

9:10philscotted: rhickey: Actually, just testing out that evaluation order stuff. If I do (import '(java.io PrintStream)) and then "(defn foo [PrintStream] PrintStream)" shouldn't foo return the java class rather than its argument?

9:12rhickey: philscotted: no, argument will hide it when used as a value like that

9:46askentask: i have this confusion. so i need to define general methods for a class that can then be called by each instance. so i need some from of "self". so should each instance carry a dict with {:my-personall-attributes some-values :general-class-spec spec} where personal-attributes correspond to something n general-class-epc

9:48 meh i need some better teaches, did high school suck for you guys too? we do so much pointless stuff but i have noone to discuss or go to for programming. seriously i have to memorize 80 different fookin birds for a biology class but when i want to learn programming i cant get any help

9:51Pupeno-G: askentask: if you want to really learn programming, go through SICP, at least, the lectures.

9:51Chouser: askentask: I sympathize. But at least in my experience, one is generally encouraged if not forced to specialize as you get older. It may be hard to think of it this way, but right now you have an opportunity to learn about birds, history, etc. that may be hard to come by later.

9:53 We had no programming courses at my high-school, or anyone around that could help in that area. Books were it. (No internet then either, at least for me.)

9:58Chousuke: askentask: your instances could contain a reference to the class object, a map of attributes, and maybe some metadata. the class object then could contain a map of functions defined for that class.

9:58rzezeski: SICP is teaching me loads though, awesome that you can get such a great resource for free!

9:59Chousuke: However, I don't see a reason to make anything that complicated. Though it might be good practice if you want to try and understand the concepts.

10:03philscotted: rzezeski: SICP really makes me embarrassed about the quality of teaching at my university. Not sure if that is just a rare jewel of MIT, or whether they have consistently good teaching material.

10:17philscotted: Chouser: Right. I suspect, then, I would very much disagree with his metric. I'm not even sure Java is halfway to Smalltalk.

10:20askentask: hmm i cant by the problem that i have a hard time doing this without defs. i could if letting the class-specification being a ref that all instances refer to. instance being a map to :spec and :instance-attributes

10:24philscotted: If we get indexed HTML documentation for Clojure functions, it might be cool to have a :see-also tag on function and macro symbols, pointing to the web page (or general URI resource).

10:25 Users could then add their own see-also tags which can be used by developer tools.

10:25 rhickey: By the way, I really like the documentation strings and metadata system.

10:31duck1123: I would like to see people using markdown or something similar in documentation strings

10:38askentask: if you need a graph datastructure, how would you create one? here is where Clojure clashes with my brain. in Python I could make a class for Node, Edge etc and specify their behaviour. but what would you use n Clojure?

10:39cemerick: duck1123: the syntax requires rote memorization. For the small amount of formatting that docs generally require, it's a whole lot easier to just use html

10:40 philscotted: Given that clojure is jvm-centric, I think conforming to the javadoc conventions and then somehow injecting docstrings into the javadoc tool would be ideal, especially given AOT compilation being a good vehicle to provide public APIs.

10:43duck1123: cemerick: I would love to see clojure code produce actual javadoc documentation.

10:43 I hate the format of javadocs, but there are plenty of tools to make it better

10:43cemerick: duck1123: I think it'll happen, but we'll probably have to generate java source containing the docstrings in order to run javadoc over them.

10:43philscotted: cemerick: But it would be good to use sexpr to represent the javadoc documentation, and then have clojure manipulate it for consumption by the javadoc tools.

10:44cemerick: philscotted: how would you represent javadoc docs using sexprs? It's fundamentally HTML, with type/method/field references here and there.

10:46Chouser: clojure docs are already represented in clojure data structures (namespaces of vars with map metadata), so consuming that and spewing whatever javadoc needs seems like it should be straightforward.

10:46philscotted: cemerick: There are loads of ways you could do it. Are there not standard tools to convert javadoc comments to XML? There are standard tools to convert from and between XML and sexpr. So we probably wouldn't need to do anything.

10:47philscotted: Chouser: At the moment though, the docs are just strings. There is no explicit documentation for individual function arguments, for instance.

10:47cemerick: philscotted: javadoc comments are strings that are interpreted by the javadoc tool to produce HTML. I'm sure there's tools out there to emit XML instead (and pdf's, etc), but they all work with Java source files.

10:48 philscotted: That's what the standard javadoc annotations are for (@param, etc)

10:53philscotted: cemerick: For instance, when writing a form, Slime could spit out the documentation for each function argument as I type it, by inspecting the metadata.

10:55 cemerick: Generally, I want the possibility of doing such things.

10:55cemerick: philscotted: Yes, that might be cool, but getting there with sexprs makes all of the common use-cases more complicated. To start, every fn would need two forms of docs -- a docstring, as well as a metadata map with an :arg-doc entry

10:56 Just grepping the docstring for pairs of @param annotations seems a lot better on all fronts.

10:59 defn's looking for a vector or a list that begins with a vector for the function args and body. So anything else can have new meaning -- plain string is :doc, plain symbol followed by string could be an :arg-doc

11:00 I think I like the plain symbols, because then keywords could be used for other things. perhaps :returns "the result of doing foo things"

11:16 would you assume they're all impure except for those listed in some sort of global pureness set?

11:18philscotted: Chouser: Everything could be assumed impure unless stated otherwise, I guess. I'm not sure this system could ever be used for static guarantees in things like transactional code, but it could be used to emit warnings.

11:24wabash: Oh, they are not original songs, only remakes with new lyrics...

11:25albino: philscotted: I figured the same concept would apply. Marking a function side-effect free means it could be passed to any other function which was also marked side-effect free

11:25wabash: Once I have a strong enough mastery of clojure to appreciate it, I'll write an original song about clojure or something.

11:29philscotted: albino: Yeah, but suppose you want to pass a side-effecting function to list. List is side-effect free, and has no intention of invoking its arguments, so we would still want this to work.

11:32duck1123: philscotted: are you saying evaluate the function and pass it to list, or pass the functions symbol to list

11:33 if it's the first, then list is no longer side-effect free because the false bubbles up

11:33philscotted: duck: I'm saying to pass the function to list. Suppose the function is foo and it is side-effecting. (list foo) has no side-effects.

11:33duck1123: if it's the latter, then it's not really a function, it's data

11:36philscotted: duck1123: More concretely: (defn foo [bar] (bar)) defines a function which takes a function and will have side effects iff bar has side effects. But (defn foo [bar] (list bar)) is pure whatever.

11:42philscotted: duck1123: Right. So rather than having a simple boolean, we could capture the conditional in some actual code. I'm not sure how much benefit any of this will actually give. It might just end up being overhead.

11:45duck1123: presumably, it would be much easier to identify the arguments that can change the side-effect status :side-effects (maybe [bar])

11:49philscotted: duck1123: I suspect it would be easy to get carried away. My intuition is that you could pick an arbitrary predicate of the arguments, and find *some* function for which that predicate expresses the dependence between the pureness of the arguments and the pureness of the main function, meaning that no simple system would be sufficient.

11:55duck1123: philscotted: I agree some functions might be difficult to pin down, but a lot of functions (those that don't take IFn's as an arg) would be relatively simple to say true or false. (defn + :side-effects false ...)

11:59philscotted: Chouser: The website. I'm happy to go through the documentation there again looking for them.

11:59Chouser: I can't speak for him of course, but generally when people have noted mistakes he's responded positively.

12:00drewr: He'd probably love to have corrections for stuff like that.

12:01 I haven't ever seen him respond unfavorably to genuine efforts to improve the project.

12:01philscotted: Well for my purposes, I want Clojure to look as awesome as possible, and it would be great if the website was completely free of typos for that.

12:01drewr: He's even kind to the cargo-cult lispers that come in complaining about stuff.

12:03duck1123: Chouser: in response to your earlier question, doall would be considered side-effect free. That status can be tainted by the sub-forms it contains, but it itself doesn't produce any side-effects, nor does it accept any unevaluated IFn's that could change that.

13:27phil: rhickey: I'm still trying to grok your "On State and Identity" article. Am I right in thinking the "state/identity" distinction is the same as the "reference/meaning" "extensional/intensional" distinction?

13:28Chouser: hiredman: essentially, yes. You don't get to provide your own constructor, but you can pass the super's constructors whatever values you want.

13:32phil: rhickey: Okay, yes. I perhaps need to rephrase. I'm wondering if the points you are making can be nicely explained in those terms. For instance, something I might do in a program is say (the list of) Jill's friends is the (list of) Jack's friends. The problem in most imperative languages is that lists are mutable, so if Jack drops one of her friends, it will affect Jill. What's happened here is we've stated that "Jack's frie

13:32 nds" is intensionally the same as "Jill's friends", so any change to one affects the other.

13:33phil: What we wanted to say was that Jack's friends and Jill's friends happen to refer to the same list, which *never* changes. At some point in the future, Jack may acquire a *different* list of friends, but this cannot affect Jill.

13:35Chouser: hiredman: frequently when using proxy I end up with a fn that acts a bit like a constructor and may provide instance data. It then calls proxy (with appropriate constructor args) and my methods close over the instance data.

13:38Pupeno: Any better/shorter way to write (symbol (format "%s-bleh" 'blah))?

13:38rhickey: phil: yes, but also that Jill may retain a persisting reference to Jack, names aside, and ask for his current list of friends at any time, so there's the list itself and the association of the list with an identity

13:42phil: Chousuke: I didn't quite get that. I consider "today" to be

13:42Chousuke: even if tomorrow "today" will be 22-11-2008 that doesn't mean 21-11-2008 has changed. it just lost its association with the identity "today".

13:43 21-11-2008 is itself an identity though. but a much more stable one than "today"

13:43phil: I consider "today" to be merely an indexical, like "me" or "you", its meaning determined by context. Perhaps my understanding has been coloured by other subjects, which is why I was after an explanation in terms I was more familiar with.

14:55clojurebot: With no args, returns the empty string. With one arg x, returns x.toString(). (str nil) returns the empty string. With more than one arg, returns the concatenation of the str values of the args.

15:50craigmcd: Chouser: thanks for the hint on the new gen-class. But why does this work fine: (.main my.Hello (into-array ["Bizarro"])), while this syntax doesn't: (my.Hello/main (into-array ["Bizarro"]))

15:55craigmcd: and I can call this main method using "java.." from the command line and it works. and I checked the class with slime inspector, and main is really static

15:57Chouser: ok, I don't really understand -- it should work. But here's what little I know...

15:58 (.foo bar) expands to (. bar foo) without exception. But (foo/bar) has to figure out if foo is a class or not (at read time). If foo is a class, then it also becomes (. foo bar), otherwise it's resolved as a var in the foo namespace.

15:59 so it's acting as those it doesn't know at read time that there's a class named my.Hello

16:25Lau_of_DK: Blackdog has done some advanced stuff on the webfront, hes the guy to informed me about JSon in the first place

16:37askentask: Chousuke: lets say i create a function spec-class that take [classname parent methods] where methods is a vector of vectors with name-functionlist pairs. how would i use -> then? i tired adding a for-comprehension but i get wrong nbr of args to for.

20:00technomancy: oh, is there no way to state dependencies on specific versions then?

20:00Chousuke: technomancy: avoids a whole lot of problems by being explicit.

20:01 technomancy: you specify the appropriate versions in your classpath and there is no problem.

20:01powr-toc: technomancy: jar files in and of themselves; don't know what they depend on.

20:03technomancy: to me it all just sounds like, "make the user do the work the computer normally does". but... I'm just getting used to it, maybe once I start using it things will make sense.

20:03Chouser: technomancy: your instincts are rational. I had a similar conversation several months ago.

20:04Chousuke: technomancy: it's still possible to have a system-wide classpath

20:04technomancy: I'll just try to keep my dependencies on Java code to a minimum. Sounds like a headache.

20:04Chousuke: technomancy: but as said before, that might break things.

20:04Chouser: technomancy: I was arguing with Rich (which is a bad sign in itself) and ended up dropping it not because I was convinced java is right but because I trusted the people that had the opposing opinion.

20:05Chousuke: technomancy: that helps. or you can be lazy and wrap all the deps in a single .jar :/

20:05technomancy: Chouser: yeah, my first day trying clojure/java is not a good time for me to get in an argument about this kind of thing.

20:05Chouser: I'm still not fully convinced -- it seems odd to me every time I write an app and have to adjust my clojure command-line to set up the dependencies on .jar's I've already apt install'ed.

20:06Chouser: but it's not so terrible to work around, and having just built my first stand-alone jar with all the deps bundled inside, I'm wodering if I'm getting closer to the 'goodness'.

20:07technomancy: worse still, the users will think to themselves: "I've run an apt-get upgrade to pull in the new versions, so I shouldn't be vulnerable", but the bundled versions don't get touched.

20:07Chousuke: technomancy: the bundled versions are inside your own .jar. you need to make a new release.

20:08powr-toc: Chouser: I can't speak for clojure so much, but in Java I tend to throw all my apps jars into a single directory, and use a shell script to pull all *.jar's in and build the classpath string dynamically

20:08technomancy: Chousuke: right, but that's the kind of problem a package manager is designed to avoid.

20:08Chousuke: technomancy: or you can make your software so that it sets it classpath properly.

20:15powr-toc: Chousuke: they can be relative though, and in java classes can be loaded in at runtime... and not necessarily from the filesystem... I'd imagine clojure makes use of this to provide compilation from the repl etc...