#clojure logs

2014-08-22

00:01danielcomptonI had a surprise using lein release today, I used lein release :minor and expected that it would release a new minor version from 0.5.5-SNAPSHOT to 0.6 but it bumped to 0.5.5, pushed a release, then bumped to 0.6.0-SNAPSHOT.
00:02danielcomptonSo if I want to bump a minor release, am I expected to know in advance?
00:11danielcomptonOr should I manually bump to 0.6 in my project.clj and then run lein release :patch?
00:11sm0keis there a way to do exclusion in lein by organisation like [.. :exclusion [org.slf4j]] ?
00:15justin_smithsm0ke: with all due respect, that's weird
00:16sm0kewhy do you think that?
00:18sm0kealso that was an example.. i may have multiple deps with common org
00:19justin_smithexcluding by org instead of dependency seems odd to me
00:19danielcomptonyou can't pull dependencies by org
00:19sm0kewhich can be painful to exclude .. i am little confused though
00:20sm0kewait a sec i think i hit a bug
00:20justin_smithalso, it's :exclusions not :exclusion
00:21sm0keyep, sorry for the typo
00:21sm0kebut yea it doesnt work that way?
00:21sm0kei am not sure what is the reason for not having this
00:22justin_smithbecause org is hardly a meaningful grouping for deps?
00:25sm0kealso i think although undocumented :exclusion also works
00:26sm0kehurm no it doesnt
00:34sm0keoh i think lein by default assumes if i have something like :exclusion [abc] it is expanded to abc/abc
00:34sm0kethat is why it seems to be working at some places for me
00:35sm0kei wish exclusions could also take a #""
00:35justin_smithyeah, with one name, it is assumed to be both org and project name
00:36justin_smithbut it's only incidental if it means blocking the org - excluding "foo" will exclude "foo/foo" but not "foo/bar"
00:39sm0kehow about special handling of abc/* ?
00:41arrdemrandom brainfiring.... does anyone here use symbols as values?
00:41arrdemoutside of macro writing
00:43sm0ke:p never even though about it! why can you use keywords instead
00:43sm0kecant*
00:44justin_smithyeah, I have always found it more convenient to use keywords
00:45sm0ke,{:a 'a :b 'b}
00:45clojurebot{:b b, :a a}
00:46arrdemright. traditionally in a Lisp, you don't have keywords and strings are "expensive" so quoted symbols are how you have programmer significant values.
00:46arrdemI'm just thinking that if the "common case" of Symbols is syntactic bindings, and the common case of Keywords is values, that it may be reasonable to eliminate Symbols entirely (or almost entirely) as legal runtime values because Keywords should be used instead.
00:47sm0ke,((:a {:a 'inc :b 'str}) 1)
00:47clojurebotnil
00:47sm0ke,((resolve (:a {:a 'inc :b 'str})) 1)
00:47clojurebot2
00:47sm0kei guess its safe
00:48joshuafcole_Is there a simple way to get a list of the symbols in a namespace for exploratory purposes?
00:48arrdemjoshuafcole_: ns-publics
00:49joshuafcole_ah cool thanks
00:49sm0kearrdem: is this for oxcart?
00:49joshuafcole_ahh, shoot. Looks like a difference between clojurescript and clojure. Guess that makes sense, the whole concept of ns's is different there. I'll poke into #clojurescript about it
00:49arrdemsm0ke: oxlang. oxcart is explictly clojure only
00:51sm0kethe oxlnag landing page says about difficulty of porting clojure to other hosts? Do you think CinC would address that?
00:51sm0keoxlang*
00:52arrdemmaybe. I'm really just researching existing work and sketching ideas at this stage.
00:52arrdemat a high level I don't like that Clojure is implementation defined.
00:52arrdemthis makes porting to other hosts a pain.
00:52arrdemI also don't like the way namespaces are implemented or the var structure. They're mutable implementation details that should be cleaned up or hidden.
00:52Claricehuh?
00:53Clarice"implementation defined". I don't know what you mean by that.
00:53sm0ketrue, but also i think 80% of clojure is written in clojure
00:53justin_smiththe definition is the implementation
00:53Clariceclojure-clr is actually chugging along quite well! I haven't heard much about clojurec.
00:53arrdemClarice: there is no hard spec for what "clojure" is.
00:53Claricearrdem: Boohoo
00:53Clariceboodle: Hickey and co are the BD(s)FL
00:53arrdemClarice: you try writing a port when you have to replicate implementation insanity..
00:53sm0keAlthough reimplementing the remaining 20% is still mamoth task
00:53arrdemsm0ke: right. that's the issue.
00:53Clariceerrr that last one was for ^arrdem
00:54arrdemClarice: I have no issue with Rich and co being BD(s)FL, the lack of spec obstructs ports to other platforms. period.
00:54justin_smithClarice: arrdem put a lot of work into helping clojure be faster to boot, and smaller to deploy - I think his concerns about the definition of clojure (or lack thereof) are worth paying attention to
00:54arrdemClarice: compare clojure vs clojurescript. two totally different languages that share a bunch of semantics.
00:55sm0kebeleive me clojure is far better than scala in terms of driving forces
00:55Claricejustin_smith: Oh! Didn't know that.
00:55Claricearrdem: My apologies :P
00:55arrdemClarice: :P no worries
00:55ClariceClojure isn't really at a point where the language is stable, though
00:55arrdemI hope I'm being relatively well reasoned in all this anyway.
00:55sm0keClarice: really?
00:56arrdemI'd tend to disagree, but that's my oppinion.
00:56Claricesm0ke: Well, I mean, all the core data structures are being redesigned to work with transducers, right?
00:56ClariceThat's a clear semantic change.
00:57justin_smithare the semantics of the core data structures actually changing? I would understand refining the impl for transducers, but changing the semantics seems odd
00:57arrdemsure, but to my spec point it's not one that comes with any associated documentation/spec changes. it's Rich going "here guys, new core.clj for you... adds a bunch of arities... have fun!"
00:57sm0keare the datastructures being changes? i though only functions operarting on them got new arrity
00:57arrdemsm0ke: no datastructure changes I know of.
00:57ClariceOh! I was mistaken.
00:57arrdembut I also didn't check very carefully.
00:58Claricearrdem: Starting a specification project would hampen Rich's ability to extend and change the language, wouldn't it?
00:59arrdem2a09172e0c3285ccdf79d1dc4d399d190678b670 is the Transducers commit
00:59Claricearrdem: Unless you made a spec just for 1.7.
00:59arrdemadds LazyTransformer and touches a bunch of other stuff, but no datastructure changes.
00:59ClariceGotcha, my mistake then.
01:00sm0kei have found clojure to be very peaceful to work with across version bumps
01:00justin_smithI think it's been particularly smooth since 1.2 / 1.3 or so
01:00arrdemClarice: sure it would, but it also represents stability for potential language implementers like myself who want people to be able to run more or less the same code on different platforms or Clojure implementations.
01:00sm0ketry scala sometimes, everything will break for a minor version change, dont know about kotlin though
01:01arrdemjustin_smith: 1.3.0 was the last breaking change, and I suspect will be the last one ever but I may yet be wrong about that.
01:01Claricearrdem: Well, my question is: what's stable, what's not?
01:02justin_smithwell, as he mentions, 1.3 was the last breaking change, 1.7 is the version that is coming up... it's been at least a couple of years with no breaking changes to the language
01:02ClariceThat is true.
01:02arrdemClarice: as far as I can tell (and I can't tell very far, I'm new to clojure in the last two years) the language core has reached a fixed point and is unlikely to see major change. It's fast _enough_, it works, and further features like Transducers, EDN, host expressions and soforth aren't breaking. they're feature supersets which provide a safe upgrade path.
01:03arrdemidk
01:03sm0kei agree
01:03sm0keit would be like throing everything away, and hickey is too smart to do that
01:04ClariceOkay. Then I don't think there's any obstacle to defining a Clojure Implementation Reference that could act as a de-facto standard since nothing quite like that exists right now.
01:04Claricearrdem: Were you working on something along those lines? I joined late in whatever conversation this was.
01:05arrdemClarice: sorta kinda. Working on my optimizing compiler over the summer I got frustrated at the lack of such a document and it started me thinking about what Clojure 2.0 could/would look like. this conversation was me spitballing the idea that keywords completely replace symbols as runtime values.
01:05justin_smithhttps://github.com/oxlang/oxcart
01:05Claricearrdem: Oh, that last sentence makes me fidget a tad bit. What are you talking about?
01:05arrdem&'foo
01:05lazybot⇒ foo
01:06arrdem&:foo
01:06lazybot⇒ :foo
01:06arrdemwith the former I quoted the symbol "foo", so I could use it as a symbolic value rather than resolving it as an environment binding.
01:07arrdemwith the latter I created a keyword :foo, which is self-evaluating and has no meaning besides itself whereas the symbol could be an environment binding
01:07arrdem&(resolve 'clojure.core/conj)
01:07lazybotjava.lang.SecurityException: You tripped the alarm! resolve is bad!
01:07justin_smith,(resolve 'conj)
01:07clojurebot#'clojure.core/conj
01:07arrdemthanks justin
01:08justin_smith:)
01:08Claricearrdem: How do you namespace keywords?
01:08arrdem&::foo
01:08lazybot⇒ :clojure.core/foo
01:08arrdem&:user/foo
01:08lazybot⇒ :user/foo
01:08justin_smith,::foo
01:08clojurebot:sandbox/foo
01:08arrdem&(namespace :user/foo)
01:08lazybot⇒ "user"
01:08arrdem&(name :user/foo)
01:08lazybot⇒ "foo"
01:09Claricearrdem: In Clojure, what is the difference between the implementation of a keyword and that of a symbol on an object level?
01:09arrdemClarice: clojure.lang.Keyword vs. clojure.lang.Symbol, both implement clojure.lang.Named
01:10arrdemit may be INamed it's been a week since I looked at this stuff last
01:10caternarrdem: what is the benefit of replacing symbols with keywords?
01:10arrdemcatern: clarity. keywords are values, symbols are bindings.
01:10ClariceWhat if I want to talk about the symbol that has a particular function value?
01:11arrdemcatern: the downside is that symbols are often values in macros, so this doesn't really work.
01:11caternarrdem: that's what I was going to say for why you shouldn't replace symbols with keywords
01:11caternarrdem: it's more clear to have the two uses strictly separate
01:11arrdemcatern: eh... I think it'd be reasonable to define ' on symbols only in a macro context...
01:12caternarrdem: what would that do?
01:12arrdemcatern: the idea is just that you create a syntactic distinction between anything that could be a value and anything that could be an environment resolved binding/value.
01:12arrdemthis makes more sense in the context of an Oxcart or clojurescript like Clojure dialect where there is no repl, only compiled code.
01:13caternare you saying that's how it is currently, or that's how you want it to be?
01:13arrdemI'm proposing that that's how it could be and trying to get feedback on whether this is just silly
01:13caternkeywords are self-evaluating
01:13caternthat is the feature I like of them
01:15Claricearrdem: You only have this redundancy in Clojure where you can namespace keywords. In Common Lisp, you cannot. keywords all reside in their own namespace where they resolve to themselves.
01:16arrdemClarice: interesting. I didn't know that.
01:17caternarrdem: I mean, there's already a syntactic distinction, right? and also a distinction in value/type/whatever. wait, are you proposing just removing symbols?
01:17caternI see, interesting
01:17Claricearrdem: Historically it was observed that people were throwing around symbols just to mean literally whatever the symbol referred to, without needing a value associated with it. But this cluttered the symbol space, so they devised a namespace specifically for this purpose.
01:17arrdemcatern: essentially.
01:17arrdemClarice: right. exactly what I'm driving at here.
01:17catern(I thought you were proposing, like, (eval :conj) gives you the conj function)
01:18catern(I was very confused about why you would want that :) )
01:18arrdemcatern: nah. I'm saying that in general the overwhelming majority of symbols will be resolved to local bindings or to defs, so why have this stupid value case when keywords do that job just as well.
01:18caternright
01:19caternI don't see how that can possibly be workable when macros exist, though
01:19ClariceIt can't.
01:19ClariceAnd if you could make it work, it would become anti-lispy. Excuse me if that sounds zealous or religious or whatever.
01:19arrdemit cant _if_ macros run in the true runtime environment.
01:20ClariceWhich they should.
01:20arrdemif you have some interpreted compile time environment, then this could be possible.
01:20arrdemClarice: how so? that's how it's traditionally done for sure.
01:21arrdemfor context: I really am just trying to explore the design space of lisps with this oxlang project. hell I'm exploring type system enforced purity haskell style and a static typechecker.
01:23Claricearrdem: What I was getting at was that if you somehow came up with a way for macros to work without referring to the same symbols that are being bound to functions or variables, you'd probably use keywords (which is wht you're suggesting of course: using only keywords for "values"). But 1) then you've tied the keyword symbols to the regular symbols in some way and 2) you haven't really done anything neat.
01:24Claricearrdem: Oh, I am, too, actually. But I've gotten stuck on type inference for subtypes. :)
01:25ClariceSome folks have helped me with automatically deriving variance rules for a finite set of type constructors. But I've also shot myself in the foot a little bit because I've designed my type system to just be a DAG you associate with functions at compile time, with the whole languaeg available in its construction. Godelian knot, incoming.
01:25arrdemClarice: I guess I'd disagree with 1, and 2 is really just a design simplification of the language/compier, but yes nothing neat.
01:25arrdemhehe
01:26Claricearrdem: Anyway, like I said, because you can namespace keywords in Clojure, quoting symbols and using keywords symbols do exactly the same thing.
01:27ClariceWhich is also what you said
01:27ClariceBut you shouldn't remove quoting of symbols, even if you could 'fix' macros.
01:27arrdemClarice: so... keywords are liked to namespaces in Clojure... but the namespace of a keyword need not exist.
01:27arrdem&:my-synthetic-namespace.quxx/foo
01:27lazybot⇒ :my-synthetic-namespace.quxx/foo
01:28arrdemaaaand I can't demonstrate that keywords respect require aliasing on namespaces because hiredman is a dick.
01:28arrdemjustin_smith: help? <3
01:28Claricearrdem: If anything, you should remove the namespacing of keywords and turn it into its own privileged namespace like common lisp does. :P
01:29arrdemI'll look into how keywords get used in CL, but I like the way that Clojure's keywords behave.
01:29ClariceWhy?
01:29clojurebothttp://clojure.org/rationale
01:30arrdemlol @ clojurebot
01:30ClariceNo, seriously, why? If ns1/keyword and ns2/keyword resolve to the same thing, why are they namespaced apart from each other?
01:30arrdemthey don't "resolve" to anything.
01:30arrdem&(= :ns1/foo :ns2/foo)
01:30lazybot⇒ false
01:31arrdemnor are they equal
01:31arrdemthe common case of keywords, non-namespaced keywords, technically have a nil namespace and this do reside in a "privilaged" namespace.
01:31ClariceWhen would you compare the two?
01:32arrdem&(= :fn (:op {:op :fn})) ;; paraphrased code from Oxcart
01:32lazybot⇒ true
01:32justin_smitharrdem: sorry, what?
01:33arrdem&(:ox/static {:static true}) ;; paraphrased code from Oxcart
01:33lazybot⇒ nil
01:33arrdemClarice: if :static == :X/static, the above would work
01:33justin_smith,(:ox/static {:statuc true})
01:33clojurebotnil
01:34arrdemjustin_smith: oh. I was asking you to do something along the lines of (do (require '[clojure.zip :as z]) :z/foo)
01:34justin_smith,(do (require '[clojure.zip :as z]) :z/foo)
01:34clojurebot#<SecurityException java.lang.SecurityException: denied>
01:34justin_smitherr
01:34arrdemAFAIK that will give you :clojure.zip/foo
01:34justin_smithI seem to remember that working with clojurebot...
01:34justin_smithbut yeah, that would
01:35arrdemoh well
01:35justin_smith(do (require '[clojure.string :as string]) :string/foo)
01:35justin_smith,(do (require '[clojure.string :as string]) :string/foo)
01:35clojurebot:string/foo
01:35arrdemClarice: did I answer the question?
01:35Claricearrdem: No, I still don't see why you need to namespace keywords.
01:35justin_smiththere we go
01:35Clarice:(
01:35justin_smithbut that should have said :clojure.string/foo
01:35justin_smith,(do (require '[clojure.string :as string]) ::string/foo)
01:35clojurebot:clojure.string/foo
01:35justin_smithet voila!
01:35justin_smithwe were close
01:35arrdem(inc justin_smith)
01:35lazybot⇒ 62
01:37arrdemClarice: it's not a "need to" it's a "want to". as a matter of convenience it's frequently useful to have a set of keywords which are "local" to some namespace. Say I wanted to use :ox/* for compiler analysis tagging, because I wanted to use some keywords like :static which are used "raw" in clojure.core and I don't want a keyword such that it equals the "raw" :static clojure.core uses.
01:38arrdemthe :: notation and namespace concept really isn't namespacing, it's syntactic sugar for getting a different or qualified value.
01:38ClariceBut it wouldn't matter if they equaled each other.
01:38arrdemhow so?
01:39ClariceBecause there's no csse where you'd ever want to compare the two keywords and desire them to be not equal.
01:39ClariceOr differentiable, rather.
01:39justin_smiththe metadata map would be in error, because it can't have two identical keys
01:39justin_smithand :static is alreayd used, but :ox/static is different
01:39arrdemyeah. what justin_smith said. sorry Clarice that makes no sense.
01:40Clarice._.
01:40ClariceI didn't think about metadata.
01:40ClariceI actually wanted to keep talking about a clojure standard
01:40ClariceOr implementation reference, rather
01:40arrdemmetadata is just this example case.
01:41arrdemClojure.core has ^{:static true} on a lot of symbols. my compiler proves that things can be static. I needed a way to annotate symbols (okay fine vars/defs) as static, so I used a namespaced keyword. this worked because of what justin_smith described. hence I like keyword namespacing.
01:42ClariceYeah, for maps that can be useful.
01:42justin_smithanother example: a request map in ring is used to carry values as various middleware and then the handler are applied. If I use namespaced keywords as keys in that request map, I am less likely to break someone else's middleware
01:42ClariceOk, you win.
01:42arrdem:P
01:42arrdemRich wins
01:42arrdemnot me
01:43arrdemClarice: if you've got a writeup of what you're working on I'd be happy to see it. mailto:me@arrdem dot com
01:44ClariceNo writeup :'(
01:44arrdemಠ_ಠ
01:44arrdemつ ◕_◕ ༽つ GIVE DOCS つ ◕_◕ ༽つ
01:45ClariceHahahah
01:45arrdemin fairness writing docs is hard. I sat down to start putting oxlang ideas in a buffer this evening hence the spam
01:46Claricearrdem: I wouldn't use keywords for the keys in Common Lisp if my map was being thrown across different parts of my code
01:47arrdemClarice: right. that's what I think makes namespaced keywords valuable... they provide "hiding" in that information can be nicely domain/provider localized but without some "real" hiding concept.
01:47ClariceNo
01:48Claricearrdem: I'd use a quoted namespaced symbol
01:48arrdemor that... idk. you could, it just doesn't buy you anything.
01:48arrdem*/more
01:49Claricewhat would be represented in clojure as {'ns1:key val1 'ns2:key val2}
01:49arrdemyou could write the exact same thing {:ns1/key 1 :ns2/key 2}
01:49arrdem: vs '
01:49arrdemmod :: and aliased imports
01:50arrdemin which case ::alias/key could be a lot nicer than :my-ungodly-source-namespace/key
01:50ClariceRight! They're redundant when you can namespace keywords! You can't in CL, so no redundanch and no loss of functionality :)
01:50arrdem:P
01:51ClariceHahahah
01:51Claricearrdem: Anyway. I'm interested in starting this project with you if you're really serious.
01:51arrdem$google mikera kiss
01:52lazybot[mikera/kiss · GitHub] https://github.com/mikera/kiss
01:52arrdem^ is the only existing work besides my oxlang spec draf(s).
01:52arrdem$google bbloom eclj
01:52lazybot[brandonbloom/eclj · GitHub] https://github.com/brandonbloom/eclj
01:52arrdem^ related but more of a clojure interpreter in clojure
01:53ClariceWith extensible effects! Neat!
01:53arrdemI have a _lot_ of background reading to do on type system prior art and soforth before I'm willing to commit to building a hardcore fork of Clojure. I've been dragging my feet on mikera for exactly that reason.
01:53ClariceI wish Haskell would adopt effects as THE way to combine side effects
01:53ClariceInstead of monadT garbage
01:53arrdemalso I'm an unpaid undergrad with classes to pass :P
01:53ClariceWell so am I
01:54arrdemwelcome to the undergrad clojurist club... you me and Bronsa are the only known members :P
01:54ClariceBut fortunately, cs has a really low barrier of entry compared to every other discipline out there
01:54ClariceI say that half in jest.
01:58arrdemClarice: what's your background for being interested in this stuff?
01:58ClariceWhat stuff? We've talked about a million things
01:58arrdemLisps/language architecture
01:58Claricearrdem: I like Lisp. A lot more than I like amy other languahe.
01:58ClariceHeh, typos. I'm on my phone, I apologize.
01:59Claricearrdem: As for language architecture, I'm just a systems junkie. I like the nitty gritty of how things are designed.
02:01arrdemClarice: :D nitty gritty is a lot of fun imo. always where I've been happiest.
02:02Claricearrdem: I'm the local common lisp troll, anyway.
02:02arrdemgoddamnit... 1am, school resumes in ten days and there're drunks singing in the building already
02:02arrdem(dec college)
02:02lazybot⇒ -1
02:03arrdemClarice: good luck with that :P the zen of #clojure when faced with trolls is legendary, second only to that of #haskell.
02:03Claricearrdem: I badger #haskell, too :P
02:04arrdemlol
02:04ClariceOnce asked how to associate documentation with a function
02:04Clarice"Just write a // comment under the type signature"
02:04ClariceTotally missed the point of what I was saying.
02:06arrdem(do-rant "y we no documentation markup language built in")
02:06ClariceMeant --
02:07arrdemseriously. even having markdown as a defacto format would be better than nothing..
02:08ClariceNo, I disagree. If markup is to be used, then the schema should be pluggable through a map or something.
02:09Claricearrdem: Standardizing a language to be cross platform is tricky. You need to figure out what's implementation defined and what's not, and that's harder than you think.
02:11arrdemI think it would be reasonable to annotate the markup type/style of a docstring, sure
02:17TEttingerlifenoodles, is your nick an Earthbound reference?
02:17arrdemanyway. I'm gonna turn in.. I'd be curious to see a writeup even of general ideas should such a thing come to exist. interesting chatting with you.
02:18TEttingerarrdem, have you seen the Wat language and Kernel stuff?
02:18TEttingeralso, Clarice
02:18ClariceAlso
02:18ClariceOh
02:18ClariceNo
02:18TEttingerit's sorta a different evolutionary tack on Lisp
02:19TEttingerthere's no intro here but http://axisofeval.blogspot.com/2011/09/kernel-underground.html
02:20arrdemTEttinger: don't think I have
02:20ClariceOh, uh, that John Shutt business
02:20TEttingerhttps://github.com/manuel/wat-js it looks pretty lispy
02:20arrdemlol @ that haskell picture
02:21TEttingerI think this was 40 lines in an earlier version, green threads in the browser with Wat https://github.com/manuel/wat-js/blob/master/modules/fibers.wat
02:24TEttingerhttp://axisofeval.blogspot.com/2013/05/green-threads-in-browser-in-20-lines-of.html 20 apparently, in the old hideous syntax
02:25arrdemholy crap this paper is 416 pages long...
02:25arrdemanother day
02:30arrdemTEttinger: thanks for the link, interesting reading
02:32TEttingernp, I hope something cool comes out of it
02:32ClariceNothing will
02:32ClariceFexprs are dumb
02:42arrdemis the lambda the ultimate forum a thing? I thought it was inactive...
03:41zeebrahaxis of eval is such a cool name for a blog