Re: foo.spec?

On Thursday, December 29, 2016 at 6:24:39 PM UTC-8, Jamie English wrote: > > I've spent some time over the holidays working on a Ruby port of > clojure.spec: ... > I'm delighted to hear this. One of the things I've been wondering about is how a Ruby API for spec would look. Could you provide

Re: foo.spec?

Hi Rich, I've spent some time over the holidays working on a Ruby port of clojure.spec: https://github.com/english/speculation. It's early days - I've mostly implemented validation/conforming, however no data generation - but I hope to have something close to feature parity with clojure.spec

[ANN] lein-codeindex 0.1.0 - Easy code indexing and referencing for Emacs, Vim and other editors

What is the benefit of tags over cider's go to definition functionality or docs functionality? -- 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

Re: Order preservation and duplicate removal policy in `distinct`

I was trying to understand part 2 of the OP’s question (per the piece I had quoted in my response). Part 1 of the OP’s question is pretty clear cut: the order of the result depends on which element is kept. Given that, if you *don’t* care about the order, you could use `set` instead of

Re: Order preservation and duplicate removal policy in `distinct`

How about a ticket for enhancement of the API documentation to clarify the nature of distinct's parameter (any seqable, even lazy)? That would distinguish it from, e.g., (dedupe (sort coll)). -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post

Re: Order preservation and duplicate removal policy in `distinct`

Wouldn't the order be different depending on wether you keep the first or the last? (distinct [1 2 1]) => [1 2] vs (distinct [1 2 1]) => [2 1] Erik. -- i farta > Den 29. des. 2016 kl. 22.32 skrev Sean Corfield : > > Can you provide a scenario when it matters? Given that

Re: Order preservation and duplicate removal policy in `distinct`

> f it helps anyone sleep better at night, were the behavior of distinct ever > to change in a way that breaks one's application, the original one is right > there in the git history, available for everyone's copying and use, with > whatever promises in the doc string you choose to add. I

Re: Order preservation and duplicate removal policy in `distinct`

Yeah. It is so hard to come up with a real use case here after I think about it that it is best to just let it be. It would only matter if identity mattered for something, but still hard to even contrive a scenario. So part (2) solved. -- You received this message because you are subscribed

Re: Order preservation and duplicate removal policy in `distinct`

On Thu, Dec 29, 2016 at 1:32 PM, Sean Corfield wrote: > > > I'm just guessing there the answer may just be "equal values are equal > and you should never care which one you get out". There are times to care > though, but then perhaps just don't use `distinct` or be sure to

Re: Order preservation and duplicate removal policy in `distinct`

If it helps anyone sleep better at night, were the behavior of distinct ever to change in a way that breaks one's application, the original one is right there in the git history, available for everyone's copying and use, with whatever promises in the doc string you choose to add. Andy On Thu,

Re: Order preservation and duplicate removal policy in `distinct`

> I'm just guessing there the answer may just be "equal values are equal and > you should never care which one you get out". There are times to care > though, but then perhaps just don't use `distinct` or be sure to have a test > on it. :P Can you provide a scenario when it matters? Given

Re: Order preservation and duplicate removal policy in `distinct`

Yeah, adding a test for undocumented behavior seems somewhat reasonable. I do wish the docs would be a bit clearer on these aspects of the contract. Without that it just doesn't seem that there is any real commitment to the Clojure implementation to not change later. I understand the general

Re: [ANN] data.xml 0.2.0-alpha1

2016-12-29 15:42 GMT+01:00 Francis Hitchens : > ... to generate my flattened representation of the XML document that I am > putting into a text table to allow testers to easily set values int the > documents as part of their testing... > For that use case, just put the

Re: [ANN] data.xml 0.2.0-alpha1

2016-12-29 15:42 GMT+01:00 Francis Hitchens : > Herwig, > > Thanks, I upgraded. The tip about the reader was very useful. So I can now > pass a string representation of my element tag like so and it works... > > (zx/xml1-> zipper >(zx/tag= (eval (read-string

foo.spec?

Does anyone know of efforts to port clojure.spec to other languages? I thought I had seen someone mention versions for Haskell and Scala, but I can't find any information on this. FWIW, my interest is in having elixir.spec and/or ruby.spec... -r -- You received this message because you are

Re: [ANN] data.xml 0.2.0-alpha1

Herwig, Thanks, I upgraded. The tip about the reader was very useful. So I can now pass a string representation of my element tag like so and it works... (zx/xml1-> zipper (zx/tag= (eval (read-string "::can/mqMessageHeader" Now I have another problem. With the 0.1.0 version that