It's time to get Clojure ready for Google Summer of Code 2017!

2017-02-02 Thread Daniel Solano Gómez 
Hello, all,

There is just under a week left for us to apply to participate in Google 
Summer of Code 2017  as a mentoring 
organisation.  This is a fantastic program that helps grow open source 
communities by paying students from around the world to work on open source 
projects over the course of the summer.  Clojure participated from 
2012–2015, and many notable projects have benefited as a result, include 
Clojure in Clojure, ClojureScript, Type Clojure(Script), Clojure/Android, 
Incanter, and more.  Not just that, many past students have spoken at 
conferences about their work and continue to make important contributions 
to the community.

I would love to see Clojure participate again this year.  In order to do 
so, we need to prepare our application.  For our application to be a 
success, we need widespread involvement from the community to prepare a 
strong project ideas page . 
 You can also review the ideas from the past 
 
several  years 
 to help you 
come up with new ideas.

Please add your project ideas to the page at <
https://github.com/clojars/clojure-gsoc-2017/blob/master/project-ideas.md>. 
 At this point, you are not committing to anything—we just need your ideas. 
 We are trying something a bit new this year where you can submit your 
ideas via a pull request.  You can also post to the mailing list using [GSoC 
Idea] in the subject line, and one of the administrators will add it for 
you.  If you prefer, you can also drop into the #gsoc channel on the 
Clojurians slack and talk about your ideas there.

If you would like to review the answers to the application 
 and our profile 
, we would appreciate the input. 

The application deadline the 9th of February at 17:00 UTC.

A big thanks to everyone who has participated in previous years as 
administrators, mentors, and students.  I hope that this will be another 
successful Google Summer of Code for Clojure.

Sincerely,

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: Clojure.spec, maps, restrict valid keywords, easier way?

2017-02-02 Thread Michael Gardner 
What would be the Right Way to deal with typos like (fetch-important-data 
{:encypt true}), where the :encrypt key is optional? Timothy mentions 
auto-complete, which is better than nothing but doesn't feel like a real 
solution (especially to those who don't use auto-complete).

> On Feb 2, 2017, at 16:37, Alex Miller  wrote:
> 
> Ugh, don't do that. Introducing layers that add no value is a bad idea. Just 
> use the keyword directly. 
> 
> -- 
> 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: spec and à la carte conformance of map vals (and maybe a bug)

2017-02-02 Thread Josh Tilles 
Sean,
Thank you for sharing your input and code! Although I am interested by what
you shared about your team’s usage of spec, I don’t believe it addresses my
original problem of wanting to omit conformers when registering specs, yet
later opt in to use a conformer when *consuming* the specs.


--
Josh Tilles
[image: Signafire logo]
79 Madison Ave, 4th Floor
New York, New York 10016

Tel: (646) 685-8379 <+16466858379>
signafire.com 
--

On Sat, Jan 14, 2017 at 8:03 PM, Sean Corfield  wrote:

> At World Singles, we use clojure.spec for that scenario: conforming /
> validating string input data and producing non-string conformed values.
>
>
>
> For each string-to-non-string type, we write a conformer that accepts the
> string and either produces the valid, parsed non-string valid or produces
> ::s/invalid. If we need further constraints on the non-string value, we use
> s/and to combine those.
>
>
>
> We also have generators for all of these: we use gen/fmap of a
> non-string-to-string formatter over a (custom) generator for the non-string
> values.
>
>
>
> Here’s an example, for string input representing dates:
>
>
>
> (defn coerce->date
>
>   "Given a string or date, produce a date, or throw an exception.
>
>   Low level utility used by spec predicates to accept either a
>
>   date or a string that can be converted to a date."
>
>   [s]
>
>   (if (instance? java.util.Date s)
>
> s
>
> (-> (tf/formatter t/utc "/MM/dd" "MM/dd/"
>
>   "EEE MMM dd HH:mm:ss zzz ")
>
> (tf/parse s)
>
> (tc/to-date
>
>
>
> (defn ->date
>
>   "Spec predicate: conform to Date else invalid."
>
>   [s]
>
>   (try (coerce->date s)
>
>(catch Exception _ ::s/invalid)))
>
>
>
> (defmacro api-spec
>
>   "Given a coercion function and a predicate / spec, produce a
>
>   spec that accepts strings that can be coerced to a value that
>
>   satisfies the predicate / spec, and will also generate strings
>
>   that conform to the given spec."
>
>   [coerce str-or-spec & [spec]]
>
>   (let [[to-str spec] (if spec [str-or-spec spec] [str str-or-spec])]
>
> `(s/with-gen (s/and (s/conformer ~coerce) ~spec)
>
>(fn [] (g/fmap ~to-str (s/gen ~spec))
>
>
>
> (s/def ::dateofbirth (api-spec ->date #(dt/format-date % "MM/dd/")
> inst?))
>
>
>
> 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 1/13/17, 9:56 PM, "Josh Tilles"  j...@signafire.com> wrote:
>
>
>
> Alex,
>
>
>
> Thank you for your reply! (I apologize for the delay in my own.)
>
>
>
> I’ll first address your final point (regarding what spec is buying me vs.
> just using normal functions): I’m still trying to figure that out myself!
>  I.e., the boundaries of spec’s applicability/appropriateness are not
> yet apparent to me.
>
>
>
> Second, your suggestion of an explicit coercion step *before* using spec
> to validate the map indicates to me that we were envisioning different
> things, although perhaps I’ve misunderstood the role of spec’s conformers.
> I was thinking about a situation like processing maps of named timestamps
> that originated as JSON sent over HTTP. The maps’ JSON origins force the
> timestamp values to be strings, but it would be a lot more convenient for
> downstream processing if the timestamps were in a format more structured
> than a string, like a map (akin to how s/cat specs conform, perhaps with
> :year, :month and :day components) or even an org.joda.time.DateTime
> instance. Hence, in this hypothetical code, I’d like to ensure the strings
> nested in the maps look properly timestamp-y before preparing the data for
> downstream processing by converting the strings to the more-structured
> format. So the coercions I had in mind would make more sense as a *post*-step
> to validation, but does this seem like an inappropriate application of
> conformers to you? I’d thought that s/conform was meant for this kind of
> validate-then-convert behavior, but I see how coercion *before* validation
> would be valuable in a different way, enabling more-granular specification,
> with more-focused predicate implementations and more-precise error
> reporting.
>
>
>
> Ultimately, I’m trying to discern which of the following scenarios is the
> case:
>
> · I’m misusing spec by trying to “opt in” to using conformers on
> map values.
>
> · I’m using spec appropriately and the ability to specify
> conformance à la carte is a feature worthy of consideration.
>
> · I’m using spec appropriately and the inability to specify
> conformance à la carte is unfortunate yet tolerable & unlikely to change.
>
>
>
> From what you wrote before, it seems likely that either the first or the
> third is true, but I wanted

Re: Clojure.spec, maps, restrict valid keywords, easier way?

2017-02-02 Thread Timothy Baldridge 
A good editor should auto-complete your keywords for you. Since using this
feature in Cursive (same sort of thing is available in other editors) the
cases where I've mis-spelled a keyword have dropped dramatically. It's a
lot harder to mis-spell a keyword when you can just do: :egg/th and
the rest is auto-filled.

On Thu, Feb 2, 2017 at 5:37 PM, Alex Miller  wrote:

> Ugh, don't do that. Introducing layers that add no value is a bad idea.
> Just use the keyword directly.
>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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: Clojure.spec, maps, restrict valid keywords, easier way?

2017-02-02 Thread Alex Miller 
Ugh, don't do that. Introducing layers that add no value is a bad idea. Just 
use the keyword directly. 

-- 
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: Clojure.spec, maps, restrict valid keywords, easier way?

2017-02-02 Thread Matching Socks 
Keyword literals are inherently misspellable and trying to solve that 
problem with Spec does not really hit the nail on the head. But there is a 
solution: You do not have to use keyword literals very much!  

Instead of using, say, :egg/thunder throughout your program, def a var as 
:egg/thunder and then use the var.  Misspell the var and the compiler will 
bark at you.  If the var is egg/thunder then every part of the program can 
use it with not much loss of readability.  

If you mark the var as const, is it as efficient too as the keyword literal?

-- 
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: What’s next for Clojars in 2017?

2017-02-02 Thread Alex Miller 
How is your signing proposal different than the signing process already 
available in Maven and in use in (for example) Maven Central repository 
(and in use for Clojure itself and contrib releases)?

-- 
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: Clojure.spec, maps, restrict valid keywords, easier way?

2017-02-02 Thread Mikhail Gusarov 

Hello Alex,

The idea is (as I understand it) that every function should accept any
map and pick keys which it understands. If some keys are critical, then
they should be marked as such in the spec.

Function might iterate over keys and raise an error if there are keys
which belong to the namespace function cares about, but the names are
not known, but it is outside of spec's functionality and ought to be
done manually.

Best regards,
Mikhail.

On 2 Feb 2017, at 18:27, Dave Tenny wrote:


On Thursday, February 2, 2017 at 10:07:31 AM UTC-5, Alex Miller wrote:


We don't encourage you to do this, but I don't have an easier 
solution

than this.



Yes, and from the general standpoint of map handling I understand 
that.


From the standpoint of functions that take options and don't pass 
option
maps through to other functions, I disagree with the clojure 
philosophy
here.  So many bugs could be caught if we flagged unexpected map keys 
when
they're used as options to functions.  Of course use and validation 
via

clojure.spec helps too, but from a general bug catching standpoint I
believe there's a huge value to flagging inputs to functions that 
aren't

recognized by the functions.

--
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: (System/console) is nil?

2017-02-02 Thread Anh Tuấn Trần 
(System/console) is only available when you run the compiled app or when 
using "lein trampoline run".

On Thursday, February 2, 2017 at 11:48:14 AM UTC+13, Mark Reed wrote:
>
> Trying to write a CLI that will prompt for a password, and it's failing 
> because (System/console) always returns nil (whether in a compiled app or 
> inside the REPL).
>
> Is this expected behavior? Is there any other portable way to read a line 
> without echo in Cojure?
>
> I've confirmed that System.console() is not null when I compile a Java 
> test app in the same environment.
>
> This is Lein 2.7.1 in Java 1.8.0 on macOS Sierra 10.12.2.
>

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

What’s next for Clojars in 2017?

2017-02-02 Thread Daniel Compton 
Hi folks

In 2016, thanks to the generous sponsors on our Bountysource program and
open source contributors, Clojars was able to:

* Move our hosting from Linode to servers sponsored by Rackspace
* Define the server on Rackspace with Ansible so it is easy to rebuild
* Validate deploys are correct and complete
* Store JARs in Rackspace Cloudfiles for greater reliability
* Serve JARs from a Fastly CDN (sponsored). This takes the Clojars servers
completely out of the critical path of serving files, and should result in
Clojars being very highly available
* Switch from Yeller to Sentry for exception tracking
* Make many smaller improvements as well

As we look towards 2017, there are a number of issues on the Clojars issue
tracker, but most of them are of low priority. We're interested in feedback
from you the community as to where you see problems or room for
improvements to Clojars.

There is one major issue which I think has the potential to greatly improve
security in the Clojure community: JAR signing. Previously Clojars required
JAR signing to promote releases into a special repository. This only served
to confuse most people, not many people promoted their artifacts, and there
were minimal security benefits from signing the JARs, as people didn't have
a web of trust to validate that the GPG signatures actually chained to
people that they trusted.

Clojars is in a very privileged position in your infrastructure, as many of
you use it to directly download JARs to run on your production machines and
developer infrastructure. It would be great if there was an option for
security conscious organisations to be able to validate that all of the
JARs they are using came from developers that they trusted. It would also
be a goal that even if Clojars was compromised, clients would reject
malicious code that didn't come from their expected sources.

I feel that this would be useful for the Clojure (and wider JVM) ecosystem.
However doing this will require a fair amount of time and effort, and it's
only worth doing if people are interested and want a higher security option
available to them. If you are interested, I encourage you to contribute to
https://github.com/clojars/clojars-web/issues/562,
https://github.com/clojars/clojars-web/issues/560, or this thread to share
your perspective, requirements, and threat models that you think we should
be working with.

We're also interested in hearing what else you think is valuable for
Clojars to focus on in 2017. Please reply on this thread with your thoughts.

Thanks, Toby and Daniel.
-- 

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: Clojure.spec, maps, restrict valid keywords, easier way?

2017-02-02 Thread Dave Tenny 
On Thursday, February 2, 2017 at 10:07:31 AM UTC-5, Alex Miller wrote:
>
> We don't encourage you to do this, but I don't have an easier solution 
> than this.
>

Yes, and from the general standpoint of map handling I understand that.

>From the standpoint of functions that take options and don't pass option 
maps through to other functions, I disagree with the clojure philosophy 
here.  So many bugs could be caught if we flagged unexpected map keys when 
they're used as options to functions.  Of course use and validation via 
clojure.spec helps too, but from a general bug catching standpoint I 
believe there's a huge value to flagging inputs to functions that aren't 
recognized by the functions. 

-- 
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: Documentation for namespace aliased keywords (particularly relevant for clojure.spec use)

2017-02-02 Thread Alex Miller 


On Wednesday, February 1, 2017 at 6:12:35 PM UTC-6, Dave Tenny wrote:
>
> Looking at the documentation for keywords under 
> https://clojure.org/reference/reader#_literals
> there is no mention for the syntax for namespace aliased keywords, and 
> this is very important it you want to manage your keywords for clojure.spec.
>

Agreed! This is definitely under doc'ed. I've added an issue to the site 
repo and I will work on that. Track 
at https://github.com/clojure/clojure-site/issues/164

I do want to clarify some terms. Keywords start with a ":". Auto-resolved 
keywords start with a "::". Generally, I prefer saying a keyword is 
"qualified" when has a namespace part. There is an unfortunate overlap in 
terms here where the namespace part of a keyword may or may not refer to an 
actual Clojure namespace, so it can be confusing to use the word 
"namespace" in this context (as it might imply more than it should). So I 
would say your question is really primarily about qualified auto-resolved 
keywords.
 

> I only know about it because google turned up some clojure.spec notes on 
> it, but it seems it should be in the mainline clojure docs too.
> I certainly didn't know about it until today.
>

Auto-resolved and qualified auto-resolved keywords have been part of 
Clojure since very early days (pre 1.0 I believe) and have not really 
changed much if at all since then. 
 

> Say we have this namespace:
>
> (ns foo 
>   (:require [clojure.spec :as s]))
> (s/def ::specific-even-number #(= 1000 %))
>
>
>
>
> And then in the user namespace:
>
> (ns user)
> (require '[clojure.spec :as s])
> (require '[foo :as f])
>
>
> (s/valid? :f/specific-even-number 1000) 
> ;; Exception Unable to resolve spec: :f/specific-even-number  clojure.spec
> /reg-resolve! (spec.clj:70)
>
> What is needed is the extra colon, as if we're saying use the current 
> namespace, only that isn't what happens.
> (s/valid? ::f/specific-even-number 1000)
> ;; true
>
 
You also could have done (which is just what the above resolves to):

   (s/valid? :foo/specific-even-number 1000)

There are two (or maybe three depending how you look at it) kinds of 
auto-resolved keywords:

1) Unqualified (or simple) auto-resolved keywords like "::foo". These 
keywords are automatically resolved using the current *ns* into a qualified 
keyword, such as :user/foo (note that context matters).
2) Qualified auto-resolved keywords like "::a/foo". In this case the 
qualifier ("a") is resolved in terms of the namespace mappings of the 
current *ns*, so "a" will resolve to whatever "a" is aliasing (or an error 
if it is not a valid alias).
3) Kind of a special case of #2 is that qualifiers that are actual 
namespaces will also resolve in keywords like "::clojure.string/foo" which 
will resolve to ":clojure.string/foo". This is kind of weird and not 
something people typically do intentionally (so I'd recommend against it).

Perhaps the clojure docs are correctly stating the use of this kind of 
> keyword my interpretation is just flawed, but it certainly wasn't obvious 
> to me, and nobody in my team knew that we could do this either.  The result 
> was some namespace unfriendly code to avoid typing in long namespaces on 
> clojure spec keywords.  Now that we know ::ns-alias/keyword we can do 
> better on our clojure.spec use.
>
> (The above tested in clojure 1.8.0).
>
> While I'm here, I want to say that I am _deeply_ disappointed that 
> clojure.spec def/fdef forms don't support documentation strings.  I upvoted 
> the issue in the bug tracker, but there were only 27 votes including mine 
> when I checked on this half-year-plus old issue.
> http://dev.clojure.org/jira/browse/CLJ-1965
>

Well, no reason to be disappointed yet - spec is still a work in progress. 
That's actually one of the top voted issues in the whole system so I am 
well aware of it. I share the desire to see docstrings for specs (which we 
could leverage in "doc" - btw, you can (doc :foo/specific-even-number) now) 
and it's something Rich suggested to me in the early days of spec. The big 
question is how to implement it. There is not currently a good place to 
stash it so it just needs some analysis. It also opens up questions about 
other meta for specs (like we currently have some file/attributes in some 
cases that could be used to make "source" work with it - that would be 
handy if it always worked).

I also have to wonder why keyword namespaces aren't processed like other 
> symbol namespaces, that is, to interpret the namespace portion before a '/' 
> with alias consideration.
> No doubt there's a good answer, but it seems anachronistic that keywords 
> need special syntax contortions to recognize namespace aliases when other 
> symbols do not.
> (Yes, clojure keywords may not be thought of as symbols, still, the rules 
> for alias recognition are inconsistent).


Regular keyword namespaces *are* processed like symbol namespaces and this 
(importantly) makes them _values_ that can be

Re: Clojure.spec, maps, restrict valid keywords, easier way?

2017-02-02 Thread Alex Miller 
We don't encourage you to do this, but I don't have an easier solution than 
this.

On Thursday, February 2, 2017 at 7:05:37 AM UTC-6, Dave Tenny wrote:
>
> I want to specify in clojure spec that only declared keywords are 
> permitted in function calls.
> This is to catch what are usually mis-spelled or mis-cased keywors passed 
> via option maps in function calls.
>
> In the fdefs below, the second fdef will catch an invalid call, e.g. 
> (f 1 {:a 2 :B 3})
> but the first fdef will not.
>
> Is there an easier way to specify the more restrictive spec without having 
> to add my own 'every' and enumeration of the keys?
> (or build my own version of s/keys that does this automatically, which I'm 
> guessing is the answer).
>
> (require '[clojure.spec :as s])
> (require '[clojure.spec.test :as stest])
>
>
> (s/def ::x (fn [x] true))   ;for lack of any?
>
>
> ;; Will not catch invalid keywords
> (s/fdef f
>   :args (s/cat :x ::x
>:options (s/keys :opt-un [::a ::b]))
>   :ret nil?)
>
>
> ;; Will catch invalid keywords, but is there an easier way?
> (s/fdef f
>   :args (s/cat :x ::x
>:options (s/and (s/keys :opt-un [::a ::b])
>#(every? #{:a :b} (keys %
>   :ret nil?)
>
>
> (defn f [x {:keys [a b]}])
>
>
> (stest/instrument `f)
>
>
>
>
>
>

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

Clojure.spec, maps, restrict valid keywords, easier way?

2017-02-02 Thread Dave Tenny 
I want to specify in clojure spec that only declared keywords are permitted 
in function calls.
This is to catch what are usually mis-spelled or mis-cased keywors passed 
via option maps in function calls.

In the fdefs below, the second fdef will catch an invalid call, e.g. 
(f 1 {:a 2 :B 3})
but the first fdef will not.

Is there an easier way to specify the more restrictive spec without having 
to add my own 'every' and enumeration of the keys?
(or build my own version of s/keys that does this automatically, which I'm 
guessing is the answer).

(require '[clojure.spec :as s])
(require '[clojure.spec.test :as stest])


(s/def ::x (fn [x] true))   ;for lack of any?


;; Will not catch invalid keywords
(s/fdef f
  :args (s/cat :x ::x
   :options (s/keys :opt-un [::a ::b]))
  :ret nil?)


;; Will catch invalid keywords, but is there an easier way?
(s/fdef f
  :args (s/cat :x ::x
   :options (s/and (s/keys :opt-un [::a ::b])
   #(every? #{:a :b} (keys %
  :ret nil?)


(defn f [x {:keys [a b]}])


(stest/instrument `f)





-- 
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: Documentation for namespace aliased keywords (particularly relevant for clojure.spec use)

2017-02-02 Thread Dave Tenny 
I also have to wonder why keyword namespaces aren't processed like other 
symbol namespaces, that is, to interpret the namespace portion before a '/' 
with alias consideration.
No doubt there's a good answer, but it seems anachronistic that keywords 
need special syntax contortions to recognize namespace aliases when other 
symbols do not.
(Yes, clojure keywords may not be thought of as symbols, still, the rules 
for alias recognition are inconsistent).


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