Re: foo.spec?

2016-12-29 Thread Rich Morin 
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 a *precis* (e.g., 
some simple cases, annotated for noobs, in both clojure.spec and 
speculation)?

-r

 

-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: foo.spec?

2016-12-29 Thread Jamie English 
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 
within the next couple of months.

Cheers,
Jamie

On Thursday, 29 December 2016 18:17:47 UTC, Rich Morin wrote:
>
> 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 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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2016-12-29 Thread Daniel 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2016-12-29 Thread Sean Corfield 
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 
`distinct`, it could reasonably be argued that `distinct` should indeed provide 
an ordering guarantee. Note that part 2 of the OP’s question would still hold 
for calling `set`.

 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

On 12/29/16, 3:46 PM, "Erik Assum"  wrote:

 

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 you had two immutable, 
equal values in a collection, when would it matter which one was discarded and 
which one was kept?

 

 

-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2016-12-29 Thread Matching Socks 
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 to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2016-12-29 Thread Erik Assum 
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 you had two immutable, 
> equal values in a collection, when would it matter which one was discarded 
> and which one was kept?
>  
> 

-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2016-12-29 Thread Mike Rodriguez 
> 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 understand it is easy to just fix it once it breaks. The point I had is just 
that without a guarantee it's an assumption. And if you don't think about it 
and it later changes, it can be subtle and hard to find. 

This actually came up as a discussion with my coworkers one day.  Someone 
mentioned Clojure doesn't seem to have any clear contract around if distinct 
preserves order or not. And I had a hard time arguing that you can "just trust 
it" since it doesn't really state that it does. 

So the main suggestion I'm getting is to just write my own test for this sort 
of assumption to avoid issues. I'd prefer some sort of doc or a generalized 
idea that all seq consuming, lazy seq returning functions build in a order 
preserving way. If that makes any sense. (I'm thinking like map and filter and 
so on relate to this idea). 

It's not really a big deal. Just a discussion I had come up "in the wild 
before". 

-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2016-12-29 Thread Mike Rodriguez 
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 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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2016-12-29 Thread Mark Engelberg 
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 have a
> test on it.  :P
>
>
> Can you provide a scenario when it matters? Given that you had two
> immutable, equal values in a collection, when would it matter which one was
> discarded and which one was kept?
>
>
They may have different metadata, or some objects may already have cached
hash values while others do not, or they may be complex enough objects that
for a later part in the program it matters that certain equal objects meet
the equality test quickly by actually being identical objects, not just
equal.

-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2016-12-29 Thread Andy Fingerhut 
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, Dec 29, 2016 at 1:15 PM, Mike Rodriguez  wrote:

> 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 idea of "it is the most natural way to implement
> it".  However, that is shaky grounds to rely on.  It also makes me question
> if I've really thought it through to know "there isn't any other way to do
> it".  In the case of `distinct` I can be fairly sure it won't reorder them.
>
> Also, it still isn't clear if it keeps the first or later duplicates or
> not.  That was the (2) part of the question.  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
>
> I asked this question mostly out of curiosity and to see what others
> thought.  Also, to bring up the issue of if the docs are sufficient.
>
>
> On Wednesday, December 28, 2016 at 3:38:03 PM UTC-6, tbc++ wrote:
>>
>> This is one of those odd questions where the answer of what "could"
>> happen and what "will most likely happen" are completely different. There
>> is no reason why `distinct` should reorder or which item will be preserved.
>> However there's really only one logical way to implement this (the way it's
>> currently implemented) and in that case the answer would be "the first
>> duplicate is used", and "items are not reordered".
>>
>> So all that to say, there's nothing in the docs that specify this is the
>> way it has to be, but it is the way it is now, is most likely not going to
>> change. So if you're really concerned about it, I'd say write a test around
>> distinct and wait for it to break someday if Clojure changes the undefined
>> behavior.
>>
>> On Wed, Dec 28, 2016 at 9:55 AM, Michael Blume 
>> wrote:
>>
>>> Also, I'm assuming distinct uses .equals semantics which might be worth
>>> calling out in the doc
>>>
>>> On Wed, Dec 28, 2016, 11:22 AM Mike Rodriguez  wrote:
>>>
 The doc for `distinct` is:
 "Returns a lazy sequence of the elements of coll with duplicates
 removed.
   Returns a stateful transducer when no collection is provided."

 (1) In the lazy sequence case, I've thought that maybe it is assuemd
 there is a guarantee that the order of the input seq is preserved.
 However, this isn't stated.  Is this an assumption to rely on for
 `distinct` and, more generally, the Clojure seq-based API functions?

 (2) In either case, when there are duplicates, there do not seem to be
 any guarantees on which one of the duplicates will be preserved.  Should
 this be stated?  I'm thinking that maybe this is about Clojure's design
 philosophy being that equal values to not ever need to be distinguished
 between, so the API doesn't explicitly support this concern.  However,
 there are times when identity relationships can matter - performance would
 be one that comes to mind.
 - This has some relationship to the Scala question @
 http://stackoverflow.com/questions/6735568/scala-seqlike-
 distinct-preserves-order

 There have been a few occasions where I relied on (or wanted to rely
 on) (1).  I haven't had many cases where (2) matters, but I could see it
 coming up on perhaps rare occasions.

 --
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clo...@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to clojure+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group

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

2016-12-29 Thread Sean Corfield 
> 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 that you had two immutable, 
equal values in a collection, when would it matter which one was discarded and 
which one was kept?

 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

On 12/29/16, 1:15 PM, "Mike Rodriguez"  wrote:

 

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 idea of "it is the most natural way to implement it".  
However, that is shaky grounds to rely on.  It also makes me question if I've 
really thought it through to know "there isn't any other way to do it".  In the 
case of `distinct` I can be fairly sure it won't reorder them.

 

Also, it still isn't clear if it keeps the first or later duplicates or not.  
That was the (2) part of the question.  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

 

I asked this question mostly out of curiosity and to see what others thought.  
Also, to bring up the issue of if the docs are sufficient.  

 

 

-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2016-12-29 Thread Mike Rodriguez 
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 idea of "it is the most natural way to implement 
it".  However, that is shaky grounds to rely on.  It also makes me question 
if I've really thought it through to know "there isn't any other way to do 
it".  In the case of `distinct` I can be fairly sure it won't reorder them.

Also, it still isn't clear if it keeps the first or later duplicates or 
not.  That was the (2) part of the question.  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

I asked this question mostly out of curiosity and to see what others 
thought.  Also, to bring up the issue of if the docs are sufficient.  


On Wednesday, December 28, 2016 at 3:38:03 PM UTC-6, tbc++ wrote:
>
> This is one of those odd questions where the answer of what "could" happen 
> and what "will most likely happen" are completely different. There is no 
> reason why `distinct` should reorder or which item will be preserved. 
> However there's really only one logical way to implement this (the way it's 
> currently implemented) and in that case the answer would be "the first 
> duplicate is used", and "items are not reordered". 
>
> So all that to say, there's nothing in the docs that specify this is the 
> way it has to be, but it is the way it is now, is most likely not going to 
> change. So if you're really concerned about it, I'd say write a test around 
> distinct and wait for it to break someday if Clojure changes the undefined 
> behavior. 
>
> On Wed, Dec 28, 2016 at 9:55 AM, Michael Blume  > wrote:
>
>> Also, I'm assuming distinct uses .equals semantics which might be worth 
>> calling out in the doc
>>
>> On Wed, Dec 28, 2016, 11:22 AM Mike Rodriguez > > wrote:
>>
>>> The doc for `distinct` is:
>>> "Returns a lazy sequence of the elements of coll with duplicates removed.
>>>   Returns a stateful transducer when no collection is provided."
>>>
>>> (1) In the lazy sequence case, I've thought that maybe it is assuemd 
>>> there is a guarantee that the order of the input seq is preserved.  
>>> However, this isn't stated.  Is this an assumption to rely on for 
>>> `distinct` and, more generally, the Clojure seq-based API functions?
>>>
>>> (2) In either case, when there are duplicates, there do not seem to be 
>>> any guarantees on which one of the duplicates will be preserved.  Should 
>>> this be stated?  I'm thinking that maybe this is about Clojure's design 
>>> philosophy being that equal values to not ever need to be distinguished 
>>> between, so the API doesn't explicitly support this concern.  However, 
>>> there are times when identity relationships can matter - performance would 
>>> be one that comes to mind.
>>> - This has some relationship to the Scala question @ 
>>> http://stackoverflow.com/questions/6735568/scala-seqlike-distinct-preserves-order
>>>
>>> There have been a few occasions where I relied on (or wanted to rely on) 
>>> (1).  I haven't had many cases where (2) matters, but I could see it coming 
>>> up on perhaps rare occasions. 
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com 
>>> 
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> “One of the main causes of the fall of th

Re: [ANN] data.xml 0.2.0-alpha1

2016-12-29 Thread Herwig Hochleitner 
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 namespace URI into your text tables. If
your testers cannot handle that, you'll have to devise your own aliasing
scheme, sorry.

-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] data.xml 0.2.0-alpha1

2016-12-29 Thread Herwig Hochleitner 
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 "::can/mqMessageHeader"
>

Here, you're using eval to interact with the alias map of *ns* at runtime.
Please don't do that! It will break in extremely random ways.
For runtime processing, don't use the reader at all. Use constructors and
accessors provided by data.xml. See below.

Now I have another problem. With the 0.1.0 version that used the
> javax.xml.namespace.QName representation of the tag, I could use the
> .getPrefix and .getLocalPart methods 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...
>
> | tag
>| value |
> | "::can/mqMessageHeader>::can/messageHeaderVersion" | "1" |
> | "::can/mqMessageHeader>::can/serviceName" | "getSubBasicInfoBt" |
> | "::can/mqMessageHeader>::can/serviceVersion" | "1" |
> | "::can/mqMessageHeader>::can/dialogTypeCode" | "2" |
> | "::can/mqMessageHeader>::can/dialogSubTypeCode" | "1" |
> | "::can/mqMessageHeader>::can/dialogReference" | "DSA-MSG" |
> | "::can/mqMessageHeader>::can/applicationGroup" | "99S" |
> | "::can/mqMessageHeader>::can/componentGroup" | "Subscription" |
> | "::can/mqMessageHeader>::can/componentName" |
> "querySubscriberBasicInfoBt" |
> | "::can/mqMessageHeader>::can/reqSentDateTime" | "2016-12-19T01:54:09" |
> | "::can/mqMessageHeader>::can/applicationUserId" | "DSAUSER" |
> | "Data>Info>ptn"  | "4094335396" |
> | "Data>AddressInfo" | "true" |
> | "Data>DetailInfo" | "true" |
>
> Now the tag is represented as a keyword :xmlns.http%3A%2F%2Fin
> tegration.sprint.com%2Fv2%2Fcommon%2FCanonicalDataModel.xsd/mqMessageHeader
> which as you pointed out does not have the alias representation.
>
> I think I am still missing something on how I can interact with the xmlns
> namespace. I am aliasing the uri, but I don't know how to reverse that, and
> I found that I still needed to alias the namespace with the new version.
> Did I misunderstand how that was auto setup?
>

You don't need to reverse anything. Aliases are a purely a _read-time_
convenience for use in source code. If you're processing qnames at runtime,
just use uris, like so:

(qname "http://integration.sprint.com/v2/common/CanonicalDataModel.xsd";
"mqMessageHeader")
=> :xmlns.http%3A%2F%2Fintegration.sprint.com
%2Fv2%2Fcommon%2FCanonicalDataModel.
xsd/mqMessageHeader

(qname-uri :xmlns.http%3A%2F%2Fintegration.sprint.com
%2Fv2%2Fcommon%2FCanonicalDataModel.
xsd/mqMessageHeader)
=> "http://integration.sprint.com/v2/common/CanonicalDataModel.xsd";

(qname-local :xmlns.http%3A%2F%2Fintegration.sprint.com
%2Fv2%2Fcommon%2FCanonicalDataModel.
xsd/mqMessageHeader)
=> "mqMessageHeader"

(xml/alias-uri 'v1 "http://integration.sprint.com/integration/interfaces/
> getSubBasicInfoBt/v1"
>'can "http://integration.sprint.com/v2/common/
> CanonicalDataModel.xsd")
>

That alias is just so that you can use a short form to denote the full uri
in _clojure source code_:

::can/mqMessageHeader => :xmlns.http%3A%2F%2Fintegration.sprint.com
%2Fv2%2Fcommon%2FCanonicalDataModel.
xsd/mqMessageHeader

It's intended to be a one-way avenue, just like prefixes in xml. The alias
cannot ever make it past read time, because that would be semantically
unsound (who decides what ::can/ would mean outside of a clojure namespace?)

-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

foo.spec?

2016-12-29 Thread Rich Morin 
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 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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] data.xml 0.2.0-alpha1

2016-12-29 Thread 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 "::can/mqMessageHeader"

Now I have another problem. With the 0.1.0 version that used the
javax.xml.namespace.QName representation of the tag, I could use the
.getPrefix and .getLocalPart methods 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...

| tag
 | value |
| "::can/mqMessageHeader>::can/messageHeaderVersion" | "1" |
| "::can/mqMessageHeader>::can/serviceName" | "getSubBasicInfoBt" |
| "::can/mqMessageHeader>::can/serviceVersion" | "1" |
| "::can/mqMessageHeader>::can/dialogTypeCode" | "2" |
| "::can/mqMessageHeader>::can/dialogSubTypeCode" | "1" |
| "::can/mqMessageHeader>::can/dialogReference" | "DSA-MSG" |
| "::can/mqMessageHeader>::can/applicationGroup" | "99S" |
| "::can/mqMessageHeader>::can/componentGroup" | "Subscription" |
| "::can/mqMessageHeader>::can/componentName" |
"querySubscriberBasicInfoBt" |
| "::can/mqMessageHeader>::can/reqSentDateTime" | "2016-12-19T01:54:09" |
| "::can/mqMessageHeader>::can/applicationUserId" | "DSAUSER" |
| "Data>Info>ptn"  | "4094335396" |
| "Data>AddressInfo" | "true" |
| "Data>DetailInfo" | "true" |

Now the tag is represented as a keyword :xmlns.http%3A%2F%
2Fintegration.sprint.com%2Fv2%2Fcommon%2FCanonicalDataModel.xsd/mqMessageHeader
which as you pointed out does not have the alias representation.

I think I am still missing something on how I can interact with the xmlns
namespace. I am aliasing the uri, but I don't know how to reverse that, and
I found that I still needed to alias the namespace with the new version.
Did I misunderstand how that was auto setup?


(xml/alias-uri 'v1 "
http://integration.sprint.com/integration/interfaces/getSubBasicInfoBt/v1";
   'can "
http://integration.sprint.com/v2/common/CanonicalDataModel.xsd";)

Thanks again.

regards, Francis.

On Sat, Dec 24, 2016 at 10:41 PM, Herwig Hochleitner  wrote:

> Sorry for the late response, I had to finish 0.2.0-alpha2, in order to
> present you with the final API for constructing qnames.
> Please upgrade.
>
> ​::can/mqMessageHeader is a purely syntactic shorthand, which gets
> expanded by the reader to whatever 'can aliases to in the current
> namespace. Apparently this feature is undocumented in the clojure
> reference. It is, however documented for clojurescript
> http://cljs.github.io/api/syntax/keyword-qualify and I'm going to file a
> clojure ticket for this.
>
> Since keyword representation is fully unified in 0.2.0 and there is no
> more prefix lookup, there is no way around storing the uri into the
> keywords themselves. If you want to construct them, please use the qname
> constructor.
>
> --
> 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.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/tlIHHR58Vqs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.