Map Keys are functions, why not vector elements?

[Stephen Feyrer]

Hi there,

This is possibly a silly question (and may have been asked before but I
couldn't find earlier examples) so here it goes.

We start with a form which we're all familiar with:

user=> (:this {:this "is" :the "same"})
"is"


Then it's not a stretch to go to:

user=> (def the 1)
#'user/the
user=> (nth [1 "is" the :same] 1)

"is"


Here's where it gets tricky as we enter the land of make believe and
what-if?

I suggest a special form where vector elements could be treated like
functions in a manner similar to maps keys.  As this is purely
hypothetical there might be better ways of representing this:

Get the nth element of the vector

user=> (3 [1 "is" the :same])
:same


Get the nth element of the vector

user=> (2 [1 "is" the :same])
1


Get the nthiness of an element in the vector

user=> (::same [1 "is" the :same])
3


Get the nthiness of an element in the vector

user=> (:the [1 "is" the :same])
2


Get the nthiness of an element in the vector

user=> (:1 [1 "is" the :same])
(0 2)


Taking things further into the realms of really you should have stopped
there!

Get the these element of the vector

user=> ((1 3) [1 "is" the :same])
("is" :same)


Just for fun I tried:

user=> ((:this :the) {:this "is" :the "same"})


NullPointerException   user/eval786 (NO_SOURCE_FILE:1)



I may be barking up the wrong tree or possibly just barking...  I hope what
I'm asking makes some sort of sense.  By way of apology to the reader, when
I began writing this question it was ill thought out and seemed a lot
simpler.  As a disclaimer, I can't think of direct examples how this would
improve readability or such or even necessarily be useful.  Though, that
being said, I do believe that there people who'd make good use of such a
feature, though I don't know who they are either but I'm hoping you're
reading this ;)

My parting shot, I have a guess as to why things are the way they are but
that is completely in substantiated and lacks in even the most basic
rationality as I also guess as to why my guess might not be true... :(


--
Warning!  If you question everything the answer you'll get is "EVERYTHING!"

Stephen.

-- 
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: Map Keys are functions, why not vector elements?

[Alex Miller]

Regarding the title, this is incorrect. Map keys are not functions; 
keywords are functions that take an associative data structure and will 
look themselves up in it. So, the premise here is not even correct to start.

Usually we prefer to work by starting from a problem and consider 
alternatives, but as you state below, you don't have a problem in mind.


On Monday, November 13, 2017 at 3:49:41 AM UTC-6, Stephen Feyrer wrote:
>
> Hi there,
>
> This is possibly a silly question (and may have been asked before but I 
> couldn't find earlier examples) so here it goes.
>
> We start with a form which we're all familiar with:
>
> user=> (:this {:this "is" :the "same"}) 
> "is"
>
>
> Then it's not a stretch to go to:
>
> user=> (def the 1) 
> #'user/the 
> user=> (nth [1 "is" the :same] 1) 
>
> "is"
>
>
> Here's where it gets tricky as we enter the land of make believe and 
> what-if?
>
> I suggest a special form where vector elements could be treated like 
> functions in a manner similar to maps keys.  As this is purely 
> hypothetical there might be better ways of representing this:
>
> Get the nth element of the vector
>
> user=> (3 [1 "is" the :same])
> :same
>
>
>
Note that you can do something similar now with:

([1 "is" the :same] 3)

Whereas in the situation with maps, keywords (a specific common key type) 
are functions, here you are implying that anything could implicitly be 
invokable as a lookup function on an associative data structure. This 
doesn't make a lot of sense to me and would undoubtedly have performance 
effects. Maybe there is some case like `(map 1 [[:a 0] [:b 1] [:c 2]])` 
where this would make sense. But this doesn't make sense for all indexed 
data structures, just those indexed by longs. Layering invocability on 
longs would require special handling in the compiler (Keywords are a type 
that embeds this by implementing IFn naturally, so it's not a special case).
 

> Get the nth element of the vector
>
> user=> (2 [1 "is" the :same])
> 1
>
>
> Get the nthiness of an element in the vector
>
> user=> (::same [1 "is" the :same])
> 3
>
>
This is something completely different - a linear search for a match. 
Clojure has considered and rejected making linear searching easier multiple 
times. It's almost always a sign that you are using the wrong data 
structure in the first place and should be using a hashed data structure 
instead. There is no chance we would do something like this.
 

>
> Get the nthiness of an element in the vector
>
> user=> (:the [1 "is" the :same])
> 2
>
>
> Get the nthiness of an element in the vector
>
> user=> (:1 [1 "is" the :same])
> (0 2)
>
>
I don't even understand what is intended here.
 

> Taking things further into the realms of really you should have stopped 
> there!
>
> Get the these element of the vector
>
> user=> ((1 3) [1 "is" the :same])
> ("is" :same)
>
>
> Just for fun I tried:
>
> user=> ((:this :the) {:this "is" :the "same"}) 
>
>
>   
>
> NullPointerException   user/eval786 (NO_SOURCE_FILE:1)
>
>
>
> I may be barking up the wrong tree or possibly just barking...  I hope 
> what I'm asking makes some sort of sense.  
>

Not particularly.
 

> By way of apology to the reader, when I began writing this question it was 
> ill thought out and seemed a lot simpler.  As a disclaimer, I can't think 
> of direct examples how this would improve readability or such or even 
> necessarily be useful.  
>

Seems like that should have been a sign. :)
 

> Though, that being said, I do believe that there people who'd make good 
> use of such a feature, though I don't know who they are either but I'm 
> hoping you're reading this ;)
>
> My parting shot, I have a guess as to why things are the way they are but 
> that is completely in substantiated and lacks in even the most basic 
> rationality as I also guess as to why my guess might not be true... :(
>
>
> --
> Warning!  If you question everything the answer you'll get is "EVERYTHING!"
>
> Stephen.
>

-- 
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: Map Keywords are functions, why not vector elements?

[Stephen Feyrer]

Updating subject to make it make more sense, hopefully.

On 13 November 2017 at 14:15, Alex Miller  wrote:

> Regarding the title, this is incorrect. Map keys are not functions;
> keywords are functions that take an associative data structure and will
> look themselves up in it. So, the premise here is not even correct to start.
>
> Usually we prefer to work by starting from a problem and consider
> alternatives, but as you state below, you don't have a problem in mind.
>
>
Normally, I don't offer possible solutions when I enquiring about a
problem.  Maybe with forethought context and or constraints...

This is  more of a solution (based on a lack of understanding) without a
problem.  If you like the problem I'm hoping to address is to reduce my
lack of understanding.



>
> On Monday, November 13, 2017 at 3:49:41 AM UTC-6, Stephen Feyrer wrote:
>>
>> Hi there,
>>
>> This is possibly a silly question (and may have been asked before but I
>> couldn't find earlier examples) so here it goes.
>>
>>
>
>> Get the nth element of the vector
>>
>> user=> (3 [1 "is" the :same])
>> :same
>>
>>
>>
> Note that you can do something similar now with:
>
> ([1 "is" the :same] 3)
>

This works for me :)


>
> Whereas in the situation with maps, keywords (a specific common key type)
> are functions, here you are implying that anything could implicitly be
> invokable as a lookup function on an associative data structure. This
> doesn't make a lot of sense to me and would undoubtedly have performance
> effects. Maybe there is some case like `(map 1 [[:a 0] [:b 1] [:c 2]])`
> where this would make sense. But this doesn't make sense for all indexed
> data structures, just those indexed by longs. Layering invocability on
> longs would require special handling in the compiler (Keywords are a type
> that embeds this by implementing IFn naturally, so it's not a special case).
>
>>
>> Get the nthiness of an element in the vector
>>
>> user=> (::same [1 "is" the :same])
>> 3
>>
>>
> This is something completely different - a linear search for a match.
> Clojure has considered and rejected making linear searching easier multiple
> times. It's almost always a sign that you are using the wrong data
> structure in the first place and should be using a hashed data structure
> instead. There is no chance we would do something like this.
>

Perhaps, I'm not understanding vectors properly.  A vector is a set of
ordered elements, I think that is right.  Then at some point you might want
to get one of those elements picking it out by its index.  Equally, this is
probably where I've lost the plot you might want to know where in a vector
your element is residing.

Get the nthiness of an element in the vector
>>
>> user=> (:1 [1 "is" the :same])
>> (0 2)
>>
>>
> I don't even understand what is intended here.
>
>
You've already covered this above but I'll explain what I meant (just to be
clear).

user=> (nth [1 "is" the :same] 2)
1

And

user=> ([1 "is" the :same] 0)
1

Therefore, a lookup of value '1' would return the indices for both
occurrences in a list.



> Taking things further into the realms of really you should have stopped
>> there!
>>
>> Get the these element of the vector
>>
>> user=> ((1 3) [1 "is" the :same])
>> ("is" :same)
>>
>>
>> Just for fun I tried:
>>
>> user=> ((:this :the) {:this "is" :the "same"})
>>
>>
>>
>> NullPointerException   user/eval786 (NO_SOURCE_FILE:1)
>>
>>
>>
The thought here was the same as the above only with a list of invocations
to return a list of values.



>
>> I may be barking up the wrong tree or possibly just barking...  I hope
>> what I'm asking makes some sort of sense.
>>
>
> Not particularly.
>
>
>> By way of apology to the reader, when I began writing this question it
>> was ill thought out and seemed a lot simpler.  As a disclaimer, I can't
>> think of direct examples how this would improve readability or such or even
>> necessarily be useful.
>>
>
> Seems like that should have been a sign. :)
>

That was one yes, the other was the suggestion that this might be a silly
question.  In hindsight, I think the question I'm looking at now maybe
quite different to the one I thought I had when I started.

At this point I think I would ask, how do you find the indices of elements
within a vector for a certain value?  Or perhaps, should you be needing to
obtain the positional component of a value, what would be the correct data
structure to use?

For example, you're given a list (in an unspecified form) of horses from a
race in their finishing order.

Carrot
Colonel Mustard
Sugar

Binky

Mr. Ned
Go Faster Stripes
Stick
Scary Monster Not Technically A Horse

Binky


Then (using Clojure) you're asked to get the positional value of 'Go Faster
Stripes' or 'Binky'?



--
Go forth and apply trigonometry in real world applications

Stephen.

-- 
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 

Re: [ANN] Clojure 1.9.0-RC1

[Shantanu Kumar]

The coercion (byte \a) works fine in Clojure 1.8, but it fails with 
`ClassCastException java.lang.Character cannot be cast to java.lang.Number` 
in 1.9.0-RC1. Is this by design?


Shantanu

On Monday, 13 November 2017 07:32:00 UTC+5:30, Alex Miller wrote:
>
> Hi David, 
>
> Clojure 1.9 now depends on two external dependencies (spec.alpha and 
> core.specs.alpha) so the instructions listed there will no longer work. We 
> are evaluating whether and how to update those instructions in the readme 
> right now.
>
> Most Clojure users work with Clojure through a project manager like 
> Leiningen or Boot (where simply declaring a dependency on 
> org.clojure/clojure "1.9.0-RC1" will automatically pull in its new 
> dependencies). We also have a new command line tool, `clj` that you can use 
> to start a repl with 1.9 (see https://clojure.org/guides/deps_and_cli).
>
> Alex
>
>
>
> On Sunday, November 12, 2017 at 7:51:26 PM UTC-6, David Kinzer wrote:
>>
>> I'm getting an error when I follow the instructions in the readme.txt, am 
>> I missing something?
>>
>> java -cp clojure-1.9.0-RC1.jar clojure.main
>> Exception in thread "main" java.lang.ExceptionInInitializerError
>> at java.base/java.lang.Class.forName0(Native Method)
>> at java.base/java.lang.Class.forName(Class.java:375)
>>
>> same instructions work for 1.8, though
>>
>>
>

-- 
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: Deps Versions - Add badges to spot when your dependencies are out of date

[Daniel Compton]

Hi folks

I’m pleased to announce Deps Versions (https://versions.deps.co/). Deps
Versions is a service that shows you when your dependencies are outdated.
You can add badges to your OSS Clojure/ClojureScript GitHub projects that
will check if your dependencies are up to date.

I hope to add support for more languages and tools (like tools.deps) soon,
and for users to be able to subscribe to notifications when new versions
are available.

I wrote a blog post  at
the Deps blog explaining the background a bit more.

Deps Versions is open source  on
GitHub, so you can open issues and pull requests there for improvements and
bug fixes.

Thanks, Daniel.

-- 
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] Clojure 1.9.0-RC1

[Alex Miller]

Works for me in 1.9.0-RC1. I don't know of anything that changed in this
area.

Clojure 1.9.0-RC1
user=> (byte \a)
97

On Mon, Nov 13, 2017 at 1:09 PM, Shantanu Kumar 
wrote:

> The coercion (byte \a) works fine in Clojure 1.8, but it fails with
> `ClassCastException java.lang.Character cannot be cast to java.lang.Number`
> in 1.9.0-RC1. Is this by design?
>
>
> Shantanu
>
>

-- 
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: Map Keywords are functions, why not vector elements?

[Alex Miller]

On Monday, November 13, 2017 at 11:40:10 AM UTC-6, Stephen Feyrer wrote:
>
> Updating subject to make it make more sense, hopefully. 
>
> On 13 November 2017 at 14:15, Alex Miller  wrote:
>
>> Regarding the title, this is incorrect. Map keys are not functions; 
>> keywords are functions that take an associative data structure and will 
>> look themselves up in it. So, the premise here is not even correct to start.
>>
>> Usually we prefer to work by starting from a problem and consider 
>> alternatives, but as you state below, you don't have a problem in mind.
>>
>>
> Normally, I don't offer possible solutions when I enquiring about a 
> problem.  Maybe with forethought context and or constraints...
>
> This is  more of a solution (based on a lack of understanding) without a 
> problem.  If you like the problem I'm hoping to address is to reduce my 
> lack of understanding.
>
>  
>
>>
>> On Monday, November 13, 2017 at 3:49:41 AM UTC-6, Stephen Feyrer wrote:
>>>
>>> Hi there,
>>>
>>> This is possibly a silly question (and may have been asked before but I 
>>> couldn't find earlier examples) so here it goes.
>>>  
>>>
>>
>>> Get the nth element of the vector
>>>
>>> user=> (3 [1 "is" the :same])
>>> :same
>>>
>>>
>>>
>> Note that you can do something similar now with:
>>
>> ([1 "is" the :same] 3)
>>
>
> This works for me :)
>

The important thing here is that thing being invoked is the vector (which 
is a custom Clojure type that implements the IFn invocation interface). 
Putting arbitrary types in the operator position of a call is where the 
issues lie.
 

>  
>
>>
>> Whereas in the situation with maps, keywords (a specific common key type) 
>> are functions, here you are implying that anything could implicitly be 
>> invokable as a lookup function on an associative data structure. This 
>> doesn't make a lot of sense to me and would undoubtedly have performance 
>> effects. Maybe there is some case like `(map 1 [[:a 0] [:b 1] [:c 2]])` 
>> where this would make sense. But this doesn't make sense for all indexed 
>> data structures, just those indexed by longs. Layering invocability on 
>> longs would require special handling in the compiler (Keywords are a type 
>> that embeds this by implementing IFn naturally, so it's not a special case).
>>
>>>
>>> Get the nthiness of an element in the vector
>>>
>>> user=> (::same [1 "is" the :same])
>>> 3
>>>
>>>
>> This is something completely different - a linear search for a match. 
>> Clojure has considered and rejected making linear searching easier multiple 
>> times. It's almost always a sign that you are using the wrong data 
>> structure in the first place and should be using a hashed data structure 
>> instead. There is no chance we would do something like this.
>>
>
> Perhaps, I'm not understanding vectors properly.  A vector is a set of 
> ordered elements, I think that is right. 
>

More importantly, vectors are indexed (you can look up an element by index) 
and this property is extended to make vectors associative where you 
associate a key (the index) with the value (the element at the index). This 
operation is fast (what we call "effectively constant" time as it's 
O(log32(n)) which is a function that grows very slowly compared to O(n)).
 

> Then at some point you might want to get one of those elements picking it 
> out by its index.  Equally, this is probably where I've lost the plot you 
> might want to know where in a vector your element is residing.
>

These two sentences are talking about two different kinds of operations, 
but I think you believe they are the same kind of operation. The first 
sentence is a fast (effectively constant time) lookup by key (the index). 
The second sentence is a slow (linear time) search through the vector. 
Generally, if your program is doing a lot of the latter, you should change 
it so it does more of the former. :)
 

>
> Get the nthiness of an element in the vector
>>>
>>> user=> (:1 [1 "is" the :same])
>>> (0 2)
>>>
>>>
>> I don't even understand what is intended here.
>>
>>
> You've already covered this above but I'll explain what I meant (just to 
> be clear). 
>
> user=> (nth [1 "is" the :same] 2) 
> 1
>
> And
>
> user=> ([1 "is" the :same] 0) 
> 1
>
> Therefore, a lookup of value '1' would return the indices for both 
> occurrences in a list.
>

Both cases here are the fast lookup operation - both of these can go pluck 
out the i-th element without examining any other elements, just like you 
were instead doing:

(nth {0 1, 1 "is", 2 the, 3 :same} 0) or 
({0 1, 1 "is", 2 the, 3 :same} 0)
 

>
>  
>
>> Taking things further into the realms of really you should have stopped 
>>> there!
>>>
>>> Get the these element of the vector
>>>
>>> user=> ((1 3) [1 "is" the :same])
>>> ("is" :same)
>>>
>>>
>>> Just for fun I tried:
>>>
>>> user=> ((:this :the) {:this "is" :the "same"}) 
>>>
>>>
>>> 
>>>  

Re: Map Keywords are functions, why not vector elements?

[Didier]

Yo are looking for indexOf (.indexOf vector value).

(.indexOf ["a" "b"] "b")
=> 1

(.indexOf ["a" "b" "b"] "b")
=> 1

Note how indexOf searches for the index of the first value which matches value.

To do what you ask, is a query over a vector, which requires a search on each 
element. This will take O(N) time. For a small list like in your example its 
probably good enough and not an issue.

If you want the name of the horse in a given position, that's a key lookup, 
which is ~O(1) time. You can use get:

(get ["a" "b"] 1)
=> "b"

If you really needed performance, you would need to combine a LinkedList and a 
map. Some datastructures do it for you under the hood, like Apache LinkedMap, 
amalloy ordered, java LinkedHashMap, etc.

Its possible to also just use sorted-map-by in a closure. But this only works 
if you're not going to add/update things to the datastructure after first 
creation.

See the example on clojuredocs: 
https://clojuredocs.org/clojure.core/sorted-map-by#example-542692d5c026201cdc327094

-- 
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.

Something that has a spec is said to be ???

[Didier]

Hey all,

I'm facing a naming problem, I can't decide how I want to call something 
that has a spec.


   1. Something that has a spec is said to be *specced.*
   2. Something that has a spec is said to be *speced.*
   3. Something that has a spec is said to be *specified.*
   
I'm leaning towards number 3. What does the community think?

Also, is there any plan to later add a predicate for this? And if so, would 
it be called any of these? Like specified? I want to start and use a common 
vocabulary.

Thanks.

-- 
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: Something that has a spec is said to be ???

[Shawn Rasheed]

spec'ed appears to be the term used in the guides,
https://clojure.org/guides/spec

Cheers

On Tue, Nov 14, 2017 at 11:17 AM, Didier  wrote:

> Hey all,
>
> I'm facing a naming problem, I can't decide how I want to call something
> that has a spec.
>
>
>1. Something that has a spec is said to be *specced.*
>2. Something that has a spec is said to be *speced.*
>3. Something that has a spec is said to be *specified.*
>
> I'm leaning towards number 3. What does the community think?
>
> Also, is there any plan to later add a predicate for this? And if so,
> would it be called any of these? Like specified? I want to start and use a
> common vocabulary.
>
> Thanks.
>
> --
> 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.
>



-- 
---sr

-- 
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: Clojurists Together - Funding critical Clojure open source projects

[Daniel Compton]

Hi folks

Today we are incredibly excited to announce Clojurists Together
. The goal of Clojurists Together is to
support important Clojure projects, by pooling donations from companies and
individuals in the Clojure community and then funding project maintainers.

The Clojurists Together model is based off the successful Ruby Together
 project, which has been running for 2.5 years
now. It is run by a committee  of
Clojure community members and lives under the Clojars organisation. Being
part of Clojars allows us to accept 501(c)3 charitable donations via the SFC
. We’ve been (slowly) working on this for more
than a year now, and are looking forward to getting your feedback on it.

The announcement post
 has
more details, but briefly, there are two sides to Clojurists Together:
Companies
and individuals, and open source maintainers.

*Companies and individuals*

Companies and individuals sign up for a monthly donation to support
Clojurists Together at a tier they choose. Different tiers afford different
benefits. Company tiers are here ,
individual tiers are here .
Every quarter, companies are surveyed to find out which tools, libraries,
and areas of the Clojure ecosystem they think could be improved, or are
important to them. We then compile that information and use it to help us
pick projects that will have the biggest impact.

*Open Source Maintainers*

Every quarter open source maintainers can submit their project for funding
for the next quarterly funding period. You can see more on the application
here . We look through the
applications, and pick the projects that can make the biggest impact. We
fund projects based on the amount of support we get. The more support we
get from companies and individuals, the more projects we can support, and
the more hours we can pay them for.

*What now?*

   - Encourage your managers to sign up for a company membership
   . For the next month, any
   company or person that signs up will be marked as a founding member.
   - If you are an open source maintainer, consider applying for funding
   .
   - If you are an individual developer, consider signing up for a developer
   membership .
   - Spread the word to other people you know that use Clojure commercially.
   - If you're a designer, and have some time to help us improve the site
   design, logo, e.t.c. that would be incredible. Please contact us off list
   for more on this.

*Questions?*

There may be some mistakes or things that don’t look right in there. Please
let us know if you have any questions, either here, or off-list at
h...@clojuriststogether.org. This project is for the Clojure community, so we
want your input on this. What works well, what doesn’t work for you, what
would you like to see?

Thanks, from the Clojurists Together Committee
:
Toby Crawley, Bridget Hilyer, Maria Geller, Devin Walters, Daniel Solano
Gómez, Larry Staton Jr., Daniel Compton.

-- 
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] data.xml 0.2.0-alpha5

[Herwig Hochleitner]

data.xml is a Clojure contrib library that parses and emits XML.

Github: https://github.com/clojure/data.xml
Changelog: https://github.com/clojure/data.xml/blob/master/CHANGES.md

Information on updating the dependency is here
.

0.2.0-alpha5 fixes a bug with emitting attributes in the builtin `xml:`
namespace. In the process, there was a lot of clean-up work, removing
various partial implementations of the recently introduced pu-map.

Michael Blume got rid of reflection warnings. This should also remove the
"illegal reflection" warning (CLJ-2066) on jdk >= 1.9

Thanks to @MichaelBlume and all data.xml contributors!

-- 
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: Something that has a spec is said to be ???

[Robert Levy]

Spec'd also seems to be the most conventional past tense form of spec as a
verb beyond the narrow context of clojure.spec as well.

http://www.dictionary.com/browse/spec-d

On Mon, Nov 13, 2017 at 2:23 PM, Shawn Rasheed  wrote:

> spec'ed appears to be the term used in the guides,
> https://clojure.org/guides/spec
>
> Cheers
>
> On Tue, Nov 14, 2017 at 11:17 AM, Didier  wrote:
>
>> Hey all,
>>
>> I'm facing a naming problem, I can't decide how I want to call something
>> that has a spec.
>>
>>
>>1. Something that has a spec is said to be *specced.*
>>2. Something that has a spec is said to be *speced.*
>>3. Something that has a spec is said to be *specified.*
>>
>> I'm leaning towards number 3. What does the community think?
>>
>> Also, is there any plan to later add a predicate for this? And if so,
>> would it be called any of these? Like specified? I want to start and use a
>> common vocabulary.
>>
>> Thanks.
>>
>> --
>> 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.
>>
>
>
>
> --
> ---sr
>
> --
> 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: Map Keywords are functions, why not vector elements?

[Stephen Feyrer]

Hi Alex, Didier,

Thanks for your patience.

That covers everything which I can think of and a fair bit more :)  I have
a bit of reading and thinking to do now.

Again, thank you.


--
Rule of thumb simple question, complicated answer

Stephen.

On 13 November 2017 at 22:09, Didier  wrote:

> Yo are looking for indexOf (.indexOf vector value).
>
> (.indexOf ["a" "b"] "b")
> => 1
>
> (.indexOf ["a" "b" "b"] "b")
> => 1
>
> Note how indexOf searches for the index of the first value which matches
> value.
>
> To do what you ask, is a query over a vector, which requires a search on
> each element. This will take O(N) time. For a small list like in your
> example its probably good enough and not an issue.
>
> If you want the name of the horse in a given position, that's a key
> lookup, which is ~O(1) time. You can use get:
>
> (get ["a" "b"] 1)
> => "b"
>
> If you really needed performance, you would need to combine a LinkedList
> and a map. Some datastructures do it for you under the hood, like Apache
> LinkedMap, amalloy ordered, java LinkedHashMap, etc.
>
> Its possible to also just use sorted-map-by in a closure. But this only
> works if you're not going to add/update things to the datastructure after
> first creation.
>
> See the example on clojuredocs: https://clojuredocs.org/
> clojure.core/sorted-map-by#example-542692d5c026201cdc327094
>
> --
> 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: [ANN] data.xml 0.2.0-alpha5

[Alan Thompson]

I seem to still be getting the JDK 1.9 reflection warning:


~/tupelo > grep data.xml project.clj
[org.clojure/data.xml "0.2.0-alpha5"]

> lein test
lein test tst.tupelo._bootstrap

-
   Clojure 1.9.0-RC1Java 9.0.1
-

lein test tst.tupelo.array

lein test tst.tupelo.async

lein test tst.tupelo.dev

lein test tst.tupelo.forest

lein test tst.tupelo.forest-examples
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by clojure.lang.Reflector
(file:/home/alan/.m2/repository/org/clojure/clojure/1.9.0-RC1/clojure-1.9.0-RC1.jar)
to method
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(org.xml.sax.InputSource,org.xml.sax.helpers.DefaultHandler)
WARNING: Please consider reporting this to the maintainers of
clojure.lang.Reflector
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release





On Mon, Nov 13, 2017 at 3:47 PM, Herwig Hochleitner 
wrote:

> data.xml is a Clojure contrib library that parses and emits XML.
>
> Github: https://github.com/clojure/data.xml
> Changelog: https://github.com/clojure/data.xml/blob/master/CHANGES.md
>
> Information on updating the dependency is here
> .
>
> 0.2.0-alpha5 fixes a bug with emitting attributes in the builtin `xml:`
> namespace. In the process, there was a lot of clean-up work, removing
> various partial implementations of the recently introduced pu-map.
>
> Michael Blume got rid of reflection warnings. This should also remove the
> "illegal reflection" warning (CLJ-2066) on jdk >= 1.9
>
> Thanks to @MichaelBlume and all data.xml contributors!
>
> --
> 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: Something that has a spec is said to be ???

[Sean Corfield]

Also, is there any plan to later add a predicate for this? And if so, would it 
be called any of these? Like specified? I want to start and use a common 
vocabulary.

Currently I think you’d have to use s/get-spec to determine whether something 
is a registered spec or not. I saw s/spec? but that only checks that the 
argument is a “spec object”, i.e., instance? clojure.spec.alpha.Spec

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


From: clojure@googlegroups.com  on behalf of Didier 

Sent: Monday, November 13, 2017 2:17:17 PM
To: Clojure
Subject: Something that has a spec is said to be ???

Hey all,

I'm facing a naming problem, I can't decide how I want to call something that 
has a spec.


  1.  Something that has a spec is said to be specced.
  2.  Something that has a spec is said to be speced.
  3.  Something that has a spec is said to be specified.

I'm leaning towards number 3. What does the community think?

Also, is there any plan to later add a predicate for this? And if so, would it 
be called any of these? Like specified? I want to start and use a common 
vocabulary.

Thanks.

--
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: Map Keywords are functions, why not vector elements?

[Sean Corfield]

I don’t think anyone addressed your question about finding all the indices in a 
vector where the element matches a given search value?

There are a number of ways to tackle that (given it’s going to be a linear 
search). Since you want the indices, you are either going to need to track them 
directly or use map-indexed to produce them automatically.

(defn indices [x l] ; produces a vector
  (loop [i 0 l l r []]
(if (seq l)
  (recur (inc i) (rest l) (if (= x (first l)) (conj r i) r))
  r)))

(defn indices [x l] ; produces a lazy sequence
  (keep identity (map-indexed (fn [i v] (when (= x v) i)) l)))

(defn indices [x l] ; produces a vector
  (transduce (comp (map-indexed vector)
   (filter (comp (partial = x) second))
   (map first))
 conj
 []
 l))

Hopefully that’ll give you some options to think about…

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


From: clojure@googlegroups.com  on behalf of Stephen 
Feyrer 
Sent: Monday, November 13, 2017 5:19:32 PM
To: clojure@googlegroups.com
Subject: Re: Map Keywords are functions, why not vector elements?

Hi Alex, Didier,

Thanks for your patience.

That covers everything which I can think of and a fair bit more :)  I have a 
bit of reading and thinking to do now.

Again, thank you.


--
Rule of thumb simple question, complicated answer

Stephen.

On 13 November 2017 at 22:09, Didier 
mailto:didi...@gmail.com>> wrote:
Yo are looking for indexOf (.indexOf vector value).

(.indexOf ["a" "b"] "b")
=> 1

(.indexOf ["a" "b" "b"] "b")
=> 1

Note how indexOf searches for the index of the first value which matches value.

To do what you ask, is a query over a vector, which requires a search on each 
element. This will take O(N) time. For a small list like in your example its 
probably good enough and not an issue.

If you want the name of the horse in a given position, that's a key lookup, 
which is ~O(1) time. You can use get:

(get ["a" "b"] 1)
=> "b"

If you really needed performance, you would need to combine a LinkedList and a 
map. Some datastructures do it for you under the hood, like Apache LinkedMap, 
amalloy ordered, java LinkedHashMap, etc.

Its possible to also just use sorted-map-by in a closure. But this only works 
if you're not going to add/update things to the datastructure after first 
creation.

See the example on clojuredocs: 
https://clojuredocs.org/clojure.core/sorted-map-by#example-542692d5c026201cdc327094

--
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.

-- 
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] Clojure 1.9.0-RC1

[Shantanu Kumar]

Sorry, I did not specify the problem completely earlier. The coercion fails 
only when *uncheked-math* is set to truthy in 1.9.0-RC1.

user=> (byte \a)
97
user=> (set! *unchecked-math* true)  ; or :warn-on-boxed
true
user=> (byte \a)

ClassCastException java.lang.Character cannot be cast to java.lang.Number  
clojure.lang.RT.uncheckedByteCast (RT.java:1376)


Shantanu

On Tuesday, 14 November 2017 01:27:36 UTC+5:30, Alex Miller wrote:
>
> Works for me in 1.9.0-RC1. I don't know of anything that changed in this 
> area.
>
> Clojure 1.9.0-RC1
> user=> (byte \a)
> 97
>
> On Mon, Nov 13, 2017 at 1:09 PM, Shantanu Kumar  > wrote:
>
>> The coercion (byte \a) works fine in Clojure 1.8, but it fails with 
>> `ClassCastException java.lang.Character cannot be cast to java.lang.Number` 
>> in 1.9.0-RC1. Is this by design?
>>
>>
>> Shantanu
>>
>>

-- 
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] Clojure 1.9.0-RC1

[Andy Fingerhut]

I see the same behavior in Clojure 1.7.0 and 1.8.0 as you see in 1.9.0-RC1.

Andy

On Mon, Nov 13, 2017 at 9:48 PM, Shantanu Kumar 
wrote:

> Sorry, I did not specify the problem completely earlier. The coercion
> fails only when *uncheked-math* is set to truthy in 1.9.0-RC1.
>
> user=> (byte \a)
> 97
> user=> (set! *unchecked-math* true)  ; or :warn-on-boxed
> true
> user=> (byte \a)
>
> ClassCastException java.lang.Character cannot be cast to java.lang.Number
> clojure.lang.RT.uncheckedByteCast (RT.java:1376)
>
>
> Shantanu
>
> On Tuesday, 14 November 2017 01:27:36 UTC+5:30, Alex Miller wrote:
>>
>> Works for me in 1.9.0-RC1. I don't know of anything that changed in this
>> area.
>>
>> Clojure 1.9.0-RC1
>> user=> (byte \a)
>> 97
>>
>> On Mon, Nov 13, 2017 at 1:09 PM, Shantanu Kumar 
>> wrote:
>>
>>> The coercion (byte \a) works fine in Clojure 1.8, but it fails with
>>> `ClassCastException java.lang.Character cannot be cast to java.lang.Number`
>>> in 1.9.0-RC1. Is this by design?
>>>
>>>
>>> Shantanu
>>>
>>> --
> 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: [ANN] Clojure 1.9.0-RC1

[Shantanu Kumar]

Sorry, my bad. I can see the same behavior in previous Clojure versions 
too. I discovered this in the middle of moving to 1.9.0-RC1 in one of 
the projects and somehow got it all mixed up.


Shantanu

On Tuesday, 14 November 2017 11:36:30 UTC+5:30, Andy Fingerhut wrote:
>
> I see the same behavior in Clojure 1.7.0 and 1.8.0 as you see in 1.9.0-RC1.
>
> Andy
>
> On Mon, Nov 13, 2017 at 9:48 PM, Shantanu Kumar  > wrote:
>
>> Sorry, I did not specify the problem completely earlier. The coercion 
>> fails only when *uncheked-math* is set to truthy in 1.9.0-RC1.
>>
>> user=> (byte \a)
>> 97
>> user=> (set! *unchecked-math* true)  ; or :warn-on-boxed
>> true
>> user=> (byte \a)
>>
>> ClassCastException java.lang.Character cannot be cast to 
>> java.lang.Number  clojure.lang.RT.uncheckedByteCast (RT.java:1376)
>>
>>
>> Shantanu
>>
>> On Tuesday, 14 November 2017 01:27:36 UTC+5:30, Alex Miller wrote:
>>>
>>> Works for me in 1.9.0-RC1. I don't know of anything that changed in this 
>>> area.
>>>
>>> Clojure 1.9.0-RC1
>>> user=> (byte \a)
>>> 97
>>>
>>> On Mon, Nov 13, 2017 at 1:09 PM, Shantanu Kumar  
>>> wrote:
>>>
 The coercion (byte \a) works fine in Clojure 1.8, but it fails with 
 `ClassCastException java.lang.Character cannot be cast to 
 java.lang.Number` 
 in 1.9.0-RC1. Is this by design?


 Shantanu

 -- 
>> 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 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: Something that has a spec is said to be ???

[James]

Great question!

The word spec is an informal abbreviation of the word specification. We have a 
word in English for something that has a specification and that is specified 
(the C is soft as in species).

I have a small library that asserts a namespace is well specified, so I know of 
at least one real world use of specified.

https://dictionary.cambridge.org/dictionary/english/spec
https://en.wikipedia.org/wiki/Spec

-- 
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.