Re: reader conditional not handling defmacro?

I can't reply to the thread on the Dev list, but here's my take. Unless I'm missing something, it seems to me that most these issues could be resolved by having a dynamic var that gets set during macro expansion according to the target platform. For instance, *compiler-target* is set to :clj

Re: Cells aka Dataflow aka FRP now pure CLJC

On Wednesday, May 25, 2016 at 2:00:14 AM UTC-4, Keith Irwin wrote: > > I remember you from the olden days as a colorful personality on > comp.lang.lisp. > We sure had some fun over there. Still the best tech forum I know of. > > Having spent this time with Clojure the language, and the

Re: Avoiding nested ifs...

On Thu, May 26, 2016 at 1:29 PM, John Szakmeister wrote: > > Yeah, cond is definitely useful here, but not in general. > > cond *is* useful in general, just not the cond that is built-in to Clojure. About 5 years ago, Christophe Grand pointed out in a blog post that cond,

Re: Avoiding nested ifs...

Not being good at reading other peoples mind, I’ll give my guess as to what Timothy was trying to suggest: If you define your input as a map with keys such as: {:type :switched ; can be :switched :dual or :something :pos 54} You can make something like: (defmulti verify-pos-for :type)

Re: Avoiding nested ifs...

(sorry for the repeat Nathan, this was meant to go to the list too) On Thu, May 26, 2016 at 1:43 PM, Nathan Davis wrote: > First off, I should say that you should first consider alternative > approaches before considering the options below. For example, cond

Re: Avoiding nested ifs...

On Thu, May 26, 2016 at 2:12 PM, Timothy Baldridge wrote: > I would suggest reviewing your data model a bit. One of the problems you > are experiencing is that you are overloading the inputs to your function. > And since they are overloaded you have to create a state

Re: Avoiding nested ifs...

On Thu, May 26, 2016 at 1:47 PM, Sean Corfield wrote: [snip] > A pattern that I’ve also started using is something like this: > > (defn guarded-process [data] > (some-> data > first-guard > second-guard > (another-guard :with “parameters”) >

Re: Avoiding nested ifs...

I use a little short circuited threading macro to deal with this. Here's a gist with the macro named short-> and how I would write out your first 2 validation steps. https://gist.github.com/mikeball/10cc64fe97c119671918fb2d1d8b4118 The new spec stuff looks really interesting, haven't had a

Re: clojure.spec

I'm in a similar position to you Wesley, I'm all for generative testing, but sometimes I prefer not to spec out the full depth of the tree (ie some input leaves with s/Any) and just turn on validation in staging and see what happens. The cpu-time wasted there doesn't matter much to me. Looking

Re: [ANN] Clojure 1.9.0-alpha1

On 5/26/16, 1:43 AM, "Glen Mailer" wrote: >Is the plan that any lib which adds specs will force the rest of the running >system up to 1.9, or is it possible to keep the specs in a different namespace >and not blow up? I would expect

Re: Avoiding nested ifs...

On 5/26/16, 7:50 AM, "John Szakmeister" wrote: >def verify_position(pos, type): ># It's acceptable to have a None value--it just means don't ># change the position for the axis. >if pos is None: >return True > >#

Re: Avoiding nested ifs...

First off, I should say that you should first consider alternative approaches before considering the options below. For example, cond seems well-suited for this particular case: (defn verify-position[pos type] (cond (nil? pos) true (or (> pos 90) (< pos 0)) false

Re: Avoiding nested ifs...

Ah, yea, having a 'data spec' specifically for validation is above and beyond what I meant, which was having your domain contained within a single data structure that can be validated using a number of possible techniques. That validation would be separate from the code that's pulling it apart

Re: Avoiding nested ifs...

On Thu, May 26, 2016 at 10:55 AM, Gary Trakhman wrote: > I think the idiomatic way to handle this in clojure is to do all your > validation upfront on a single descriptive data structure, perhaps in a > single function, then bail early. That has the added advantage of

Re: clojure spec fdef

I've tweaked that section of the doc to try to make that more explicit. On Thursday, May 26, 2016 at 10:12:43 AM UTC-5, Alex Miller wrote: > > I think the connection is that you are (always) describing function > arguments using regex ops. Maybe that could be made clearer. > > On Thursday, May

Re: clojure spec fdef

I think the connection is that you are (always) describing function arguments using regex ops. Maybe that could be made clearer. On Thursday, May 26, 2016 at 9:23:43 AM UTC-5, Sven Richter wrote: > > Do you refer to this section? > > "When regex ops are combined, they describe a single sequence.

Re: [ANN] Clojure 1.9.0-alpha3

The spec guide has been updated to reflect all changes as of alpha3: http://clojure.org/guides/spec On Thursday, May 26, 2016 at 9:05:54 AM UTC-5, Alex Miller wrote: > > Clojure 1.9.0-alpha3 is now available. > > Try it via > - Download: >

Avoiding nested ifs...

I'm very much a fan of bailing out early in imperative programming as it helps to avoid a bunch of nested if conditions that are to follow and read. This typically comes up when checking arguments to ensure that they're valid (in range, of acceptable values, etc). One of the major stumbling

Re: Avoiding nested ifs...

I think the idiomatic way to handle this in clojure is to do all your validation upfront on a single descriptive data structure, perhaps in a single function, then bail early. That has the added advantage of being able to report multiple errors, instead of just the first, and is well supported by

Re: [ANN] Clojure 1.9.0-alpha3

I'm still running into check-var returning nil: https://gist.github.com/tvanhens/28b7f744d799910750d8ae3942680997 On Thursday, May 26, 2016 at 10:05:54 AM UTC-4, Alex Miller wrote: > > Clojure 1.9.0-alpha3 is now available. > > Try it via > - Download: >

Re: clojure.spec possible bug

This was fixed for alpha 3 > On May 26, 2016, at 10:08 AM, Georgi Danov wrote: > > I am trying to match sequences with fixed start and end but varying content. > After lots of experiments I start to suspect there is either bug, or severe > misunderstanding on my side.

Re: clojure spec fdef

Do you refer to this section? "When regex ops are combined, they describe a single sequence. If you need to include a nested sequential collection, you must use an explicit call to spec to start a new nested regex context. For example to describe a sequence like [:names ["a" "b"] :nums [1 2

clojure.spec possible bug

I am trying to match sequences with fixed start and end but varying content. After lots of experiments I start to suspect there is either bug, or severe misunderstanding on my side. Here is one example that behaves illogical to me (sp/conform (sp/cat :start #{1} :mid (sp/+

[ANN] Clojure 1.9.0-alpha3

Clojure 1.9.0-alpha3 is now available. Try it via - Download: https://repo1.maven.org/maven3/org/clojure/clojure/1.9.0-alpha3 - Leiningen: [org.clojure/clojure "1.9.0-alpha3"] 1.9.0-alpha3 includes the following changes since 1.9.0-alpha2: - Macro fdef specs should no longer spec the implicit

Re: clojure.spec

Thanks Rich, for this and your work in general. After 15 years of working with Java, it has been a real joy to find clojure (let's face it, that pun alone is pure gold!). I might try my hand at the macrology you describe as an exercise... everybody stand well back On Thursday, 26 May

Re: clojure.spec

If you name (register) your (sub)specs with s/def and you can reuse them as much as you like. (s/def ::argi (s/cat :i integer?)) (s/def ::fnii (s/fspec :args ::argi :ret integer?)) (s/conform ::fnii +) (s/valid? ::argi '(42)) However you are talking about calling ‘instrument’ so I don’t think

Re: clojure.spec

> > spec is not a contract system. > Forgive me for I am about to sin :). I have a little RPC framework that I use to do simple remoting between clojurescript in the browser and ring based web services. I'm currently using schema to validate arguments received from clients and return

Re: clojure spec fdef

There is an example like this in the Sequence section and a bit on this issue in particular. On Thursday, May 26, 2016 at 7:08:44 AM UTC-5, Sven Richter wrote: > > Ah thanks, that worked, not quite as I expected. Up until this point it > was pretty straightforward for me, thats been my fist

Re: clojure.spec

Well, I think it depends on what you want to accomplish. For instance, there’s no saying that the best way to generate a custom version of a recursive spec is via overrides of its constituent parts. You could supply a new root level spec that generated compatible instances in a completely

Re: clojure spec fdef

Ah thanks, that worked, not quite as I expected. Up until this point it was pretty straightforward for me, thats been my fist bummer. Do you have an example for this in the guide? I did not fully read it, but I think I scrolled through everything that used fdefs. Best Regards, Sven Am

Re: clojure spec fdef

It's a little tricky but you want: (s/fdef remove-autoinc-columns :args (s/cat :cols (s/spec ::columns))) Here the args data is ([{:foo "some_t"}]) and while you have an s/cat for :args and an s/cat in ::columns, those will be combined into the same regex so that's basically the same thing as

Re: [ANN] Clojure 1.9.0-alpha1

Thanks for this explanation. I think that cleared up some of this for me more. I'm certainly excited about this new addition. I should have started off with that. On Wednesday, May 25, 2016 at 8:01:49 PM UTC-5, Rich Hickey wrote: > > I’d advise everyone concerned/confused about the

clojure spec fdef

Hi, I already asked this in the spec channel on slack, but got no response yet. I have this simple spec definition: (s/def ::foo string?) ​ (s/def ::column (s/keys :req-un [::foo])) ​ (s/def ::columns (s/cat :col (s/* (s/spec ::column ;(s/def ::columns (s/cat :col (s/* ::column))) ​

Re: [ANN] Clojure 1.9.0-alpha1

Is the plan that any lib which adds specs will force the rest of the running system up to 1.9, or is it possible to keep the specs in a different namespace and not blow up? Would it be reasonable to release something for 1.8 which contains all the spec vars but no-ops them? -- You received

Re: clojure.spec

I'm reading clojure.spec documentation, and I want to know more about how and where a similar module is to be used. What is, say, a java equivalent to this functionality? Any examples in some existing project? Thank you in advance -- You received this message because you are subscribed to the

Re: clojure.spec

Thank you Rich, here is why I wasn't at ease with generating all paths: *recursion-limit* is documented as being a soft limit, so I don't know even a lower bound or when to stop generating paths Suffix match wouldn't be a panacea, it's just a (bad) quickfix. Paths form a regular language so