Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I couldn't help myself... https://xkcd.com/1172/ -- 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.

taking my clojure game to a higher level

I started programming with Racket 2 years ago and i decided i want to use a Lisp with more libraries at my disposal. So i have made some headway into Clojure and am familiar with core functions like map, reduce, filter, loop, for, doseq, some, every?, apply. I make use of macros like ->, ->>,

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I'd prefer getting rid of the symbol option. Some kind of deprecation warning for a version or two might be an idea though. On Sat, Aug 20, 2016, 10:51 PM Sean Corfield wrote: > Or keep the stricter compiler and: > > 1. People who want to port to clojurescript will incur

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Or keep the stricter compiler and: 1. People who want to port to clojurescript will incur exactly the same cost as they do now. **2. People who don’t want to port to clojurescript and don’t want to move to Clojure 1.9 will incur no additional cost. 3. Clojurescript maintainers will incur no

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On 8/20/16, 7:13 PM, "Colin Fleming" wrote: > in this case it seems like the change breaks a lot of existing code I disagree. Compared to the vast amount of Clojure code out there, I would contend that this breaks very little

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

What about a compromise where you could opt-in or opt-out of checking macro specs at compile time (via a compiler option)? It seems worth preserving the correctness of the spec, without forcing all of the breakage. Andrew Oberstar On Sat, Aug 20, 2016 at 9:13 PM Colin Fleming

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I think there's considerable scope to produce better error messages automatically than what spec produces, and I hope that can happen for 1.9. The error message produced by the code I demoed at the conj last year would be: Unexpected symbol 'require' at while parsing namespace clauses. Expected

Re: [ANN] Clojure 1.9.0-alpha11

I have two questions about spec and ns. In clojure/core/specs.clj: * both ::ns-require and ::prefix-list use s/cat. * ::refer uses s/coll-of. So both list and vector could be used, right? i.e. the following ns declarations work in 1.9.0-alpha11: * (ns n (:require [clojure.set :refer

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

With respect to preserving undocumented behaviour, while in general I'm in favour of making compilers stricter, in this case it seems like the change breaks a lot of existing code in ways that are impossible for library consumers to fix themselves - they have to wait for an update to the library,

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

> On Aug 20, 2016, at 6:30 PM, Timothy Baldridge wrote: > > Brian, let's make it more concrete then...why should the Clojure compiler > continue to support undocumented features that make code unportable? Because: 1. People who want to port to clojurescript will incur

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Brian, let's make it more concrete then...why should the Clojure compiler continue to support undocumented features that make code unportable? On Sat, Aug 20, 2016 at 4:48 PM, Brian Marick wrote: > > On Aug 20, 2016, at 5:26 PM, s...@corfield.org wrote: > > I disagree

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

> On Aug 20, 2016, at 5:26 PM, s...@corfield.org wrote: > > I disagree (strongly) with your position here Brian. I’ll try to explain > clearly why but first a little background… I too have felt the pain of having to maintain backward compatibility. However, I’m reminded, in this case, of Mark

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

As a side note to this conversation, I hit this (require) vs (:require) thing almost a year ago when porting a file to CLJS. ClojureScript has been enforcing these keyword regulations for some time, as well as only allowing a single :require, not allowing anything but :require, :use, etc. On Sat,

RE: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I disagree (strongly) with your position here Brian. I’ll try to explain clearly why but first a little background… At World Singles, we’ve always done multi-version testing against the stable version of Clojure that we plan to use in production and also against the very latest master

Parsing namespaced XML with clojure.data.xml

The future is XML-with-namespaces: POM files and whatnot. Such cases are tricky because more than one notation is possible. You need a namespace-enabled parser to figure out what the XML text really means. Luckily, a contributed project, clojure.data.xml, can read XML-with-namespaces, and

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On Saturday, August 20, 2016 at 9:58:14 AM UTC-5, Brian Marick wrote: > > > On Aug 20, 2016, at 9:03 AM, Alex Miller wrote: > > We discussed this before releasing the specs and decided to start on the > strict side. That said, this is still an alpha and there is plenty of

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On Saturday, August 20, 2016 at 9:40:21 AM UTC-5, Brian Marick wrote: > > > On Aug 20, 2016, at 9:03 AM, Alex Miller wrote: > > You left out this next important line too since it points you to exactly > the file and line where the error occurs: > > ,

Re: Generate a million file from a template

I think you should move the future inside do times, since then you’ll get a future for each write. Also, I don’t think you need to put your json-template in an atom: (ns jsonworker.foo (:require [cheshire.core :refer :all ])) (defn parse-json [file-loc] (parse-stream

Generate a million file from a template

Hello, I am trying to generate lot of files using futures but it hasn't sped up the process that hoped for. Here is the code I am using. Can someone point what I am doing wrong? (ns jsonworker.core (:require [cheshire.core :refer :all ])) (defn parse-json [file-loc] (parse-stream

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

> On Aug 20, 2016, at 9:03 AM, Alex Miller wrote: > > We discussed this before releasing the specs and decided to start on the > strict side. That said, this is still an alpha and there is plenty of time to > change our minds prior to official release of 1.9 if that ends

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

> On Aug 20, 2016, at 9:03 AM, Alex Miller wrote: > > You left out this next important line too since it points you to exactly the > file and line where the error occurs: > > , compiling:(such/sequences.clj:1:1) This is interesting. Here’s why I missed it. I attach the

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On Saturday, August 20, 2016 at 5:17:59 AM UTC-5, Brian Marick wrote: > > Yesterday, a bug was filed against Suchwow under 1.9alpha11. It turns out > to have been a use of `ns …(require…` instead of `(ns …(:require`. Not in > Suchwow, but in Midje. Unfortunately, the Suchwow file the bug

Re: [ANN] Clojure 1.9.0-alpha11

alias is not included and I have yet to find code using it in the wild. That said, it exists in the gray area as well. If it becomes an issue and/or Rich thinks it should be added, that could be done. I suspect that if we have any changes related to aliasing non-existing namespaces (for

Re: [ANN] Clojure 1.9.0-alpha11

On Saturday, August 20, 2016 at 2:32:29 AM UTC-5, Colin Fleming wrote: > > (ns ... (require ...) (import ...) ) instead of (ns ... (:require ...) >> (:import ...) ) > > > Is this not intended to be allowed? The docstring implies no but it has > always worked fine - I wouldn't call the code

Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Yesterday, a bug was filed against Suchwow under 1.9alpha11. It turns out to have been a use of `ns …(require…` instead of `(ns …(:require`. Not in Suchwow, but in Midje. Unfortunately, the Suchwow file the bug report pointed at *also* had that typo - apparently I am prone to it - so adding the

Re: [ANN] Clojure 1.9.0-alpha11

I've used `:alias` to alias clojure.core in the past, I've seen it being used in more than one project On 20 Aug 2016 8:32 a.m., "Colin Fleming" wrote: > (ns ... (require ...) (import ...) ) instead of (ns ... (:require ...) >> (:import ...) ) > > > Is this not

Re: [ANN] Clojure 1.9.0-alpha11

> > (ns ... (require ...) (import ...) ) instead of (ns ... (:require ...) > (:import ...) ) Is this not intended to be allowed? The docstring implies no but it has always worked fine - I wouldn't call the code broken. Does the spec also limit the refs to

Re: [ANN] Clojure 1.9.0-alpha11

That is what I figured/suspected but wasn't sure. Thanks for filing those pull requests so quickly! Alan On Fri, Aug 19, 2016 at 10:32 PM, Alex Miller wrote: > system also depends on the latest released version of monger, which has an > invalid defn in it (:or [ ] instead