[ANN] Serene - generate clojure.spec with GraphQL and extend GraphQL with clojure.spec

[Dom Kiva-Meyer]

 

https://github.com/paren-com/serene


Serene ingests GraphQL schemas and outputs Clojure specs. Serene is the 
easiest way to spec an entire API, whether internal or external.


These specs can be used for:

   - validating API input 
   - validating API output 
   - speccing resolvers 
   - speccing functions that receive or return API data 
   - generating mock data that conforms 
   - and anything else where you might use specs 


We announced Serene at Clojure/conj. Here is the video: 
https://www.youtube.com/watch?v=mgSSVTDZvkI


If you're using GraphQL, please give Serene a try.

-- 
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: [ClojureScript] ANN: ClojureScript 0.0-2496, cljs.test - a clojure.test port

[Dom Kiva-Meyer]

Thank you! This is awesome news.

On Wed, Dec 17, 2014 at 1:54 PM, David Nolen  wrote:
>
> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> New release version: 0.0-2496
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "0.0-2496"]
>
> The big change in this release is a port of the clojure.test namespace
> - cljs.test.
> It is largely compatible with clojure.test and implements enough
> functionality such
> that we could port all of the existing tests to it. It's also featureful
> enough
> to support a ClojureScript port of test.check that is underway.
> cljs.test is compatible
> with all of the optimization settings provided by the compiler including
> :none.
>
> Still cljs.test may not satisfy all the patterns that people have come to
> expect
> from clojure.test so feedback (and enhancement/fix patches) is very
> welcome.
>
> On the way we implemented changes to the compiler in order to make
> custom testing
> frameworks simpler to implement - this includes compiler support for
> :test metadata as well
> as introducing static vars.
>
> ClojureScript does not have vars, however there are var patterns that
> are largely
> static in nature and useful for metaprogramming and REPL interactions.
> Towards
> this end we've implemented the `var` special form and introduced very
> restricted
> functionality - metadata is the primary use case.
>
> (defn foo [])
> (meta #'foo) ;; will return the expected metadata
>
> cljs.test is implemented on top of this functionality as well as a new
> namespace
> cljs.analyzer.api which I think macro writers will find quite useful.
>
> Also there's a doc macro now in the cljs.repl namespace that works as
> expected.
> Patches welcome to bring all the useful bits of clojure.repl into
> cljs.repl.
>
> ## 0.0-2496
>
> ### Enhancements
> * cljs.test added, mirrors clojure.test
> * New cljs.analyzer.api namespace for easier access to analysis info from
> macros
> * New cljs.analyzer.api namespace for easier access to analysis info from
> macros
> * Support :test metadata on vars
> * Support static vars
> * cljs.source-map for client side source mapping
> * expose ClojureScript :warnings build option
> * CLJS-909: Add stable api for consumers of compiler data.
>
> ### Changes
> * convert all ClojureScript tests to cljs.test
> * add volatile! from Clojure 1.7
> * stateful transducers use volatile!
> * added `js-debugger` macro, compiles to "debugger;"
> * CLJS-892: Improve performance of compare-symbols/compare-keywords
> * CLJS-696: remove arguments usage from defrecord constructor
> * unroll `partial`, copy & pasted from Clojure core.clj
> * optimize clojure.string/join
>
> ### Fixes
> * fix `cljs.nodejs/enable-util-print!`, incorrectly monkey patched
> `cjls.core/string-print` instead of setting `cljs.core/*print-fn*`
> * cljs.reader bug, '/ incorrectly read
> * avoid emitting the same goog.require
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>

-- 
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: [ClojureScript] Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript

[Dom Kiva-Meyer]

Thanks for the experience reports, Dylan!

Colin, Silk is Ring-compatible and meant to be used as a single replacement
for both Compojure and Secretary (or any other server/browser routing
combination with incompatible syntax and semantics). But, as Dylan said,
it's totally fine to use it in conjunction with Compojure instead of
replacement. Silk should also work fine with all Ring middleware.
In the next version, Silk will have a more familiar and mostly
Compojure-compatible syntax for defining routes. My hope is that this will
make it easier to translate Compojure examples/code to Silk.


On Fri, Oct 10, 2014 at 9:25 AM, Dylan Butman  wrote:

> I’ve been using silk in conduction with compojure. Most middleware aren’t
> compojure specific, but I’ve just found it easier to stick with base level
> compojure routes and then pass uris to silk for pattern matching. This is
> mostly because there is such a wealth of documentation and examples to draw
> from with compojure. For example, session management, login flows with
> friends, etc have already been solved and there is plenty of code to strip.
> Silk wouldn’t complicated them (in some cases it might simplify), but when
> the wheel rolls, push it.
>
>
> I’ve been approaching silk solely as a library for pattern matching within
> the specific domain of urls, which it does very cleanly. More importantly,
> it’s currently the only one that does it in both clojure and clojurescript,
> which makes it possible to have the same routing code used on client and
> server, which is necessary if you want to do server rendering, or more
> complicated websocket updates.
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>

-- 
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: [ClojureScript] Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript

[Dom Kiva-Meyer]

Thanks for putting that together, Dylan. Looking forward to seeing what
you're building. :)

Olli, please feel free to reach out to me (email, Twitter, GitHub issue,
whatever) if you have any questions. Thanks for trying it out!

On Tue, Oct 7, 2014 at 12:05 PM, Dylan Butman  wrote:

> Sorry i don't have time to really explain any of this...
>
> but here's some code I pulled out of a recent project. maybe it'll be
> helpful to you. unfortunately I can't share the whole project.
>
> https://gist.github.com/pleasetrythisathome/7adbdc9c8b7ab689df45
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>

-- 
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 Videos (with options for Linux users)

[Dom Kiva-Meyer]

Thanks!

On Thu, Sep 18, 2014 at 6:45 PM, Timothy Baldridge 
wrote:

> Sure, send me an email asking for access and I'll set it up.
>
> Timothy
>
> On Thu, Sep 18, 2014 at 7:30 PM, Dom Kiva-Meyer  wrote:
>
>> Thanks for the videos and for making this option available. Is it
>> possible for existing subscribers to access the videos via Dropbox as well?
>>
>> On Thu, Sep 18, 2014 at 5:51 PM, Timothy Baldridge 
>> wrote:
>>
>>> Just wanted to throw this out there, but I've been making steady
>>> progress on my Clojure Tutorial Videos (
>>> https://tbaldridge.pivotshare.com). We're up to 43 videos with new
>>> episodes added at a rate of about 2-3 a week.
>>>
>>> Some users have expressed a desire for the raw MP4 files for use on
>>> Linux, or other platforms where flash is not optimal, so I'm also happy to
>>> announce that the videos are available via Dropbox. There's a link on the
>>> site, the price is the same, but the process is manual so there is a
>>> processing delay of 1-2 days.
>>>
>>> Thanks to everyone who's offered encouragement and feedback. And
>>> yes...transducer videos will be up *soon*. They're recorded, but you should
>>> really start by watching the video of Rich's Strange Loop talk, that he'll
>>> be giving tomorrow.
>>>
>>> 
>>>
>>> --
>>> 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.
>>
>
>
>
> --
> “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.
>

-- 
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 Videos (with options for Linux users)

[Dom Kiva-Meyer]

Thanks for the videos and for making this option available. Is it possible
for existing subscribers to access the videos via Dropbox as well?

On Thu, Sep 18, 2014 at 5:51 PM, Timothy Baldridge 
wrote:

> Just wanted to throw this out there, but I've been making steady progress
> on my Clojure Tutorial Videos (https://tbaldridge.pivotshare.com). We're
> up to 43 videos with new episodes added at a rate of about 2-3 a week.
>
> Some users have expressed a desire for the raw MP4 files for use on Linux,
> or other platforms where flash is not optimal, so I'm also happy to
> announce that the videos are available via Dropbox. There's a link on the
> site, the price is the same, but the process is manual so there is a
> processing delay of 1-2 days.
>
> Thanks to everyone who's offered encouragement and feedback. And
> yes...transducer videos will be up *soon*. They're recorded, but you should
> really start by watching the video of Rich's Strange Loop talk, that he'll
> be giving tomorrow.
>
> 
>
> --
> 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.

Clojurians in Prague

[Dom Kiva-Meyer]

I'm in Prague for a couple weeks. Any locals want to grab a beer and chat
about Clojure[Script]?

-- 
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: [ClojureScript] Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript

[Dom Kiva-Meyer]

Good stuff, Marc! Thanks for the feedback.

That behavior in `composite` is a bug. Thanks for reporting.

Sorting the query map seems reasonable. Good suggestion!

Thanks again, Marc.



On Sat, Aug 9, 2014 at 8:05 PM, marc  wrote:

> I've been playing and like Silk a lot!
>
> However the following I find curious as I'm wondering what the intended
> behaviour should be:
> user=> (silk/match (silk/composite ["user-" (silk/integer :id) "-fred" (
> silk/option :this "that") "s"]) "user-42-fredjs")
> {:id 42, :this "j"}
>
> user=> (silk/match (silk/composite ["user-" (silk/integer :id) "-fred" (
> silk/option :this "that") "s"]) "user-42-freds")
> nil
>
>
> I would have thought the last one would have produced:
> user=> (silk/match (silk/composite ["user-" (silk/integer :id) "-fred" (
> silk/option :this "that") "s"]) "user-42-freds")
> {:id 42, :this "that"}
>
>
>
> My only other suggestion, not worthy of a pull request, is the following:
>
> (defn domkm.silk/encode-query
>  "Takes a query map.
>  Returns a string of query pairs encoded and joined."
>  [query]
>  (->> query
>(apply into sorted-map) ; ensure consistent ordering to improve
> cache-ability of URLs...
>(map (fn [[k v]] (str (encode k) "=" (encode v
>(str/join "&")))
>
>
> Regards,
>
> Marc
>
>
> On Sunday, 10 August 2014 05:00:50 UTC+10, DomKM wrote:
>
>> Hi Allen,
>>
>> Thanks for the feedback!
>>
>> 1) This, and precompiling regexes where possible, is my intention with
>> Silk.
>>
>> 2) I'm not convinced that requiring fully-qualified routes would be a
>> feature. Let's say we have route A which should match "/foo/bar" and
>> route B which should match "/foo/*". If these routes are unordered, route B
>> would have to additionally be constrained with `(not= * "bar")`. It
>> seems like this could make route definition very painful when working in
>> a large application with many routes that match on multiple parts of the
>> URL.
>>
>>
>> On Sat, Aug 9, 2014 at 10:06 AM, Allen Rohner  wrote:
>>
>>> I'd like to thank everyone in the community for both Silk, and
>>> Secretary.
>>>
>>> I'll throw out some (uninvited) feature requests I'd love to see in a
>>> future route-matching library.
>>>
>>> 1) Make trie-based route dispatching possible. A feature pedestal
>>> has/will soon have, is to compile the routing table into trie, rather than
>>> the compojure-style wrapped functions. This can have a nice speedup on busy
>>> applications. I'm not asking anyone to write this code, just consider the
>>> design such that it's possible to add this behavior in the future.
>>>
>>> 2) I'll claim that making route definition order is a misfeature. Routes
>>> should always be fully qualified, such that re-arranging them doesn't
>>> affect routing behavior (and therefore, the route table should be an
>>> unordered collection, like a map or set, not a vector). One nice
>>> readability reason for this is that if your route order does matter, than
>>> at least one route definition is "lying" about which routes it actually
>>> dispatches on.
>>>
>>> Just things to consider :-)
>>>
>>> Thanks,
>>> Allen
>>>
>>>
>>> On Thursday, August 7, 2014 9:31:56 PM UTC-5, DomKM wrote:
>>>
 Thanks for your feedback, Dylan!

 If you define routes with :path and :query, will the route
> match/unmatch with undefined query keys? If so, how are they handled? If
> not, I'd suggest making query matching optional, where nils are 
> substituted.


 I'm not entirely sure what you mean, but I'll give it a shot. Please
 provide some example code if I answered the wrong question.

 `nil` is a pattern that matches anything. If your URL pattern query is
 `nil` then the URL query will not be checked.
 A map is a pattern that matches its values against the values of
 another map. Therefore, `nil` and `{}` are equivalent when used as a query
 pattern.
 You can make a query value pattern optional by wrapped it with
 `silk/option`.

 It's a little unclear how your matching functions relate to route. It
> looks like Silk always breaks at / in path and matches, is that correct?


 Yes. There is a URL type in Silk and matching is done against instances
 of it. The path is represented as a vector of segments.

 The readme is currently very deficient and I apologize for that.

 There are some really good things in secretary. What do you think about
> them?
> Splat, regex, format matchers.


 In terms of regex matching, Silk used to have a built-in regex pattern
 but I removed it when I made a big architectural change. I forget why I
 removed it, but I'll re-add it since it does seem like a very common
 requirement.

 Currently, part of Secretary's splat exists as a built-in Silk pattern.
 For example, `(silk/composite ["foo" :* "bar"])` would match
 "fooanythingbar" and return `{:* "anything"}`. The `:*` isn't special; it's
 

Re: [ClojureScript] Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript

[Dom Kiva-Meyer]

Hi Allen,

Thanks for the feedback!

1) This, and precompiling regexes where possible, is my intention with Silk.

2) I'm not convinced that requiring fully-qualified routes would be a
feature. Let's say we have route A which should match "/foo/bar" and route
B which should match "/foo/*". If these routes are unordered, route B would
have to additionally be constrained with `(not= * "bar")`. It seems like
this could make route definition very painful when working in a large
application with many routes that match on multiple parts of the URL.


On Sat, Aug 9, 2014 at 10:06 AM, Allen Rohner  wrote:

> I'd like to thank everyone in the community for both Silk, and Secretary.
>
> I'll throw out some (uninvited) feature requests I'd love to see in a
> future route-matching library.
>
> 1) Make trie-based route dispatching possible. A feature pedestal has/will
> soon have, is to compile the routing table into trie, rather than the
> compojure-style wrapped functions. This can have a nice speedup on busy
> applications. I'm not asking anyone to write this code, just consider the
> design such that it's possible to add this behavior in the future.
>
> 2) I'll claim that making route definition order is a misfeature. Routes
> should always be fully qualified, such that re-arranging them doesn't
> affect routing behavior (and therefore, the route table should be an
> unordered collection, like a map or set, not a vector). One nice
> readability reason for this is that if your route order does matter, than
> at least one route definition is "lying" about which routes it actually
> dispatches on.
>
> Just things to consider :-)
>
> Thanks,
> Allen
>
>
> On Thursday, August 7, 2014 9:31:56 PM UTC-5, DomKM wrote:
>
>> Thanks for your feedback, Dylan!
>>
>> If you define routes with :path and :query, will the route match/unmatch
>>> with undefined query keys? If so, how are they handled? If not, I'd suggest
>>> making query matching optional, where nils are substituted.
>>
>>
>> I'm not entirely sure what you mean, but I'll give it a shot. Please
>> provide some example code if I answered the wrong question.
>>
>> `nil` is a pattern that matches anything. If your URL pattern query is
>> `nil` then the URL query will not be checked.
>> A map is a pattern that matches its values against the values of another
>> map. Therefore, `nil` and `{}` are equivalent when used as a query pattern.
>> You can make a query value pattern optional by wrapped it with
>> `silk/option`.
>>
>> It's a little unclear how your matching functions relate to route. It
>>> looks like Silk always breaks at / in path and matches, is that correct?
>>
>>
>> Yes. There is a URL type in Silk and matching is done against instances
>> of it. The path is represented as a vector of segments.
>>
>> The readme is currently very deficient and I apologize for that.
>>
>> There are some really good things in secretary. What do you think about
>>> them?
>>> Splat, regex, format matchers.
>>
>>
>> In terms of regex matching, Silk used to have a built-in regex pattern
>> but I removed it when I made a big architectural change. I forget why I
>> removed it, but I'll re-add it since it does seem like a very common
>> requirement.
>>
>> Currently, part of Secretary's splat exists as a built-in Silk pattern.
>> For example, `(silk/composite ["foo" :* "bar"])` would match
>> "fooanythingbar" and return `{:* "anything"}`. The `:*` isn't special; it's
>> just a keyword. Format is just a specific case of composite:
>> `(silk/composite [:* "." :format])`. Unlike Secretary, Silk does not have a
>> built-in special syntax for string patterns. This is because special syntax
>> strings are not composable and, since Silk matches against unencoded
>> strings, who am I to say you can't have ":" or "*" in your URL paths? ;)
>>
>> Looking at the Secretary readme, there appear to be two ways to use splat
>> that Silk currently does not have built-in support for. In Secretary,
>> "/foo/*" would match "/foo/bar/baz" and return `{:* "bar/baz"}`. Also,
>> "/*/*" would match "/a/b" and return `{:* ["a" "b"]}`. I keep saying
>> "built-in" because, while multi-segment path patterns and binding the same
>> parameter key to multiple path segments does not currently exist in Silk,
>> it is very easy to extend Silk with that functionality. You could easily
>> create a pattern that did exactly what Secretary and Clout do by default
>> and use it to match a path instead of a vector. However, I do question the
>> utility of these two features. Are either of these common requirements and,
>> if so, could I see some examples of why they are necessary or helpful? This
>> isn't rhetorical; please let me know if Silk is missing something that is
>> within its scope and is useful to most consumers.
>>
>> protocol based render function for multiple arity "unmatching." this is
>>> really great.
>>
>>
>> I don't think I fully understand the use cases for this protocol. Do you
>> want to be able to look rout

Re: [ClojureScript] Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript

[Dom Kiva-Meyer]

Thanks for your feedback, Dylan!

If you define routes with :path and :query, will the route match/unmatch
> with undefined query keys? If so, how are they handled? If not, I'd suggest
> making query matching optional, where nils are substituted.


I'm not entirely sure what you mean, but I'll give it a shot. Please
provide some example code if I answered the wrong question.

`nil` is a pattern that matches anything. If your URL pattern query is
`nil` then the URL query will not be checked.
A map is a pattern that matches its values against the values of another
map. Therefore, `nil` and `{}` are equivalent when used as a query pattern.
You can make a query value pattern optional by wrapped it with
`silk/option`.

It's a little unclear how your matching functions relate to route. It looks
> like Silk always breaks at / in path and matches, is that correct?


Yes. There is a URL type in Silk and matching is done against instances of
it. The path is represented as a vector of segments.

The readme is currently very deficient and I apologize for that.

There are some really good things in secretary. What do you think about
> them?
> Splat, regex, format matchers.


In terms of regex matching, Silk used to have a built-in regex pattern but
I removed it when I made a big architectural change. I forget why I removed
it, but I'll re-add it since it does seem like a very common requirement.

Currently, part of Secretary's splat exists as a built-in Silk pattern. For
example, `(silk/composite ["foo" :* "bar"])` would match "fooanythingbar"
and return `{:* "anything"}`. The `:*` isn't special; it's just a keyword.
Format is just a specific case of composite: `(silk/composite [:* "."
:format])`. Unlike Secretary, Silk does not have a built-in special syntax
for string patterns. This is because special syntax strings are not
composable and, since Silk matches against unencoded strings, who am I to
say you can't have ":" or "*" in your URL paths? ;)

Looking at the Secretary readme, there appear to be two ways to use splat
that Silk currently does not have built-in support for. In Secretary,
"/foo/*" would match "/foo/bar/baz" and return `{:* "bar/baz"}`. Also,
"/*/*" would match "/a/b" and return `{:* ["a" "b"]}`. I keep saying
"built-in" because, while multi-segment path patterns and binding the same
parameter key to multiple path segments does not currently exist in Silk,
it is very easy to extend Silk with that functionality. You could easily
create a pattern that did exactly what Secretary and Clout do by default
and use it to match a path instead of a vector. However, I do question the
utility of these two features. Are either of these common requirements and,
if so, could I see some examples of why they are necessary or helpful? This
isn't rhetorical; please let me know if Silk is missing something that is
within its scope and is useful to most consumers.

protocol based render function for multiple arity "unmatching." this is
> really great.


I don't think I fully understand the use cases for this protocol. Do you
want to be able to look routes up by types? If so, since route names in
Silk can be anything, you could use a type as a name. Anyway, I put
together this little gist
 of ways in which Silk
could be used similarly to how I *think* someone might use Secretary's
IRenderRoute. Do these cover the use cases for that protocol?


I also agree with everything in Joel's response and look forward to working
with him on improving the routing story. :)


On Thu, Aug 7, 2014 at 2:52 PM, Joel Holdbrooks 
wrote:

> I'm in agreement that Silk is a step in the right direction. I've reached
> out to Dom and I think we can learn a lot from each other and work together
> to improve the routing story in Clojure overall.
>
> > There are some really good things in secretary. What do you think about
> them?
> > Splat, regex, format matchers.
> > protocol based render function for multiple arity "unmatching." this is
> really great.
>
> These are definitely nice things and I'm willing to bet Silk would be
> capable of supporting some of them.
>
> It's obvious to me to that if we can iron out the details with Silk,
> Secretary could built on top of it as a higher level interface while at the
> same time taking advantage of what Silk has to offer. It might mean some
> breaking changes in Secretary but those were already slated anyway.
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>

-- 
You received this message because you are subscribed to the Google
G

Re: [ClojureScript] Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript

[Dom Kiva-Meyer]

Hi Joel,

Thanks for your feedback. Off topic, but Garden is awesome and Ankha has
been indispensable when developing Om applications! Thanks for those.

I didn't complain or suggest a patch because, aside from Bidi, I didn't
find a Clojure or ClojureScript routing library that I could conceive of
fitting *my criteria* without fundamental, completely breaking alterations
-- alterations that warrant a new library, not a new version number. I care
about compatibility, extensibility, bidirectionally, purity, transparency,
and decoupling -- which is why I wrote Silk.

Since you brought up Secretary as a routing library that could potentially
be made isomorphic, I'll compare it to Silk as I did with Bidi. I am not as
familiar with Secretary as I am with Bidi, and it looks to have changed
since I last used it, so please do correct me if I say anything incorrect
or misleading.

In terms of commonalities with Silk, Secretary obviously works in
ClojureScript and has named routes. It is also somewhat extensible via
protocols.

In terms of differences, Secretary is obviously incompatible with Clojure,
couples route definition with route handling, uses a complex macro to
define routes instead of using data structures, can only match URL paths,
and is impure. While I value all of these features that Secretary lacks, I
think that last one, impurity, is the most significant.

I love Clojure's pragmatic philosophy; it is mostly pure but very
practical. Mutation is always possible, but uncontrolled mutation is
frowned upon and intentionally difficult. Where we draw the line between
functional purity and impurity is unclear and very open to interpretation,
but it is my strong opinion that route creation and matching should sit
firmly on the pure side.

The public interface for defining routes in Secretary is `defroute`, a
macro which only sometimes defines something but *always* mutates a global
atom. When using Secretary, how does one know the order in which routes are
matched? I assume it is in dependency order as determined by the Google
Closure compiler, but it is unclear to me. What about if Secretary is
ported to Clojure and you hot reload namespaces as you develop with it? You
could potentially change the routing order from what it would be at
runtime. Component  is extremely
useful for development and its popularity is well warranted, but
Secretary's design fundamentally precludes compatibility with Component or
anything that requires that mutation be limited and controllable.

Silk is also, in many ways, lower level than Secretary. Secretary could be
built on top of Silk without much additional effort since extending Silk to
match paths specified with Clout/Secretary syntax ("/path/to/:param") would
be trivial. On the other hand, building Silk on top of Secretary would be
extremely difficult.

It is not my intention to lambast Secretary and I hope it doesn't come
across that way. Solving front-end routing problems is difficult and is a
different beast altogether from back-end routing because it lacks the
established Ring model (adapters, requests, etc.) and even lacks the HTTP
request/response model. Secretary did a good job at solving these difficult
problems.

We share a desire to bring an end to the saturation of routing libraries. I
just don't think that retrofitting a library designed for one paradigm will
work without causing significant pain to users.  At some point, it just
makes sense to start fresh. Silk is designed from the ground up to work on
both platforms, be extremely extensible, and include all of the best parts
of the various routing libraries that I have used and examined. These
strict flexibility requirements led to a design which, I think, is very
simple and fairly low-level while remaining reasonably convenient.

I appreciate your invitation to help you work toward the goal of making
Secretary isomorphic and would be happy to talk to you about it. However, I
don't think that Secretary or any other routing library can easily replace
Silk. Therefore, I also invite you to help improve any deficiencies you see
in Silk. I would greatly appreciate constructive criticism. I'll take you
up on your offer to email you privately. :)

Cheers,
Dom



On Tue, Aug 5, 2014 at 7:35 PM, Joel Holdbrooks 
wrote:

> Awesome work. It's fantastic to see a library that's interested in
> targeting both the front-end and the back-end. This is the type of attitude
> I would love to see more often in the Clojure community.
>
> OTOH, it would have been awesome to have heard your thoughts WRT the
> concept of isomorphic routing on the Secretary issue tracker.
>
> You said you couldn't find something suitable, why didn't you complain or
> suggest a patch? We would have been happy to have supported your endeavor
> in making that possible and your ideas. In fact, we would have been willing
> to make breaking changes for them!
>
> Many of us want this!
>
> Originally, several people -

Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript

[Dom Kiva-Meyer]

Hi Craig,

Great question! Bidi  is a fantastic library
and was my favorite Clojure routing library prior to Silk. The design of
Silk was heavily influenced by that of Bidi.

In terms of commonalities, both Silk and Bidi are bidirectional, pure (no
side effects), based on data composition (not function/macro composition),
extensible via protocols, and decouple matching from handling.

In terms of differences, Bidi is (obviously) not compatible with
ClojureScript. Bidi's design is the most amenable to porting to
ClojureScript of any Clojure library that I've reviewed, but it still makes
many assumptions about using Ring and running in a server environment.
Bidi routes are defined in a tree structure that branches at URL path
segments. While Silk can match any part of a URL, Bidi can only match the
URL path due to its routes structure. I also think that Silk's route syntax
is a lot easier to read and programmatically manipulate than Bidi's, but
this is subjective.

Hope that helps. :)

Cheers,
Dom



On Mon, Aug 4, 2014 at 10:10 PM, Craig  wrote:

> How would you position Silk in relation to Bidi?
>
> Thanks for any insights.
>
> --
> 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.

[ANN] Silk, an isomorphic routing library for Clojure and ClojureScript

[Dom Kiva-Meyer]

I have recently been experimenting with isomorphic Clojure and
ClojureScript architecture
.
The goal is to make Clojure[Script] web applications that can share logic
for routing, rendering, and other functionality in order to be able run in
both server-side and browser-side environments.

I couldn't find a suitable routing library that worked in both Clojure and
ClojureScript nor could I find a routing library with a design that was
suitable for porting to the other platform, so I wrote one.

https://github.com/DomKM/silk


The core functionality of Silk is entirely compatible with both Clojure and
ClojureScript.

Silk is easily extensible, which is especially important for an isomorphic
library. For example, you may have routes that, on the server, should only
match GET requests, but which should also work in the browser where you are
not routing from an HTTP request. This functionality is trivial to add to
Silk (and, as a convenience, is built in).

In Silk, route matching and handling are decoupled. While this is an
important architecture concern anywhere, it is an essential feature for
isomorphism. Matching URLs on the server and browser will be very similar,
but what you do after will likely be entirely different. You can think of
routing in Silk as bidirectional (yes, routes are named) pure functions
that match URLs to extract parameters or take parameters to form URLs.

 If this sounds like it could be useful for you, please give it a try and
let me know what you think.

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: core.match incorrect docstring?

[Dom Kiva-Meyer]

No worries and thanks.

On Wed, May 28, 2014 at 7:19 AM, David Nolen  wrote:

> Thanks for the report, docstring updated.
>
> David
>
>
> On Tue, May 27, 2014 at 5:16 PM, Dom Kiva-Meyer  wrote:
>
>> The clojure.core.match/match docstring states that it takes "...a vector
>> of occurrences, vars. Clause question-answer syntax is like `cond`.
>> Questions must be wrapped in a vector..."
>> https://github.com/clojure/core.match/blob/5429e20f5db8c398d745f15f7a85f65976f45397/src/main/clojure/clojure/core/match.clj#L1966-1976
>>
>> However, it seems to work without wrapping the occurrences and questions
>> in vectors.
>>
>> (match [{:a 1 :b 2}]   [{:a 1 :b x}] x);;=> 2(match {:a 1 :b 2}   
>> {:a 1 :b x} x);;=> 2
>>
>> Is the docstring outdated or are there circumstances that necessitate
>> wrapping the occurrence/s and question/s in vectors?
>>
>>
>>
>>  --
>> 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.

core.match incorrect docstring?

[Dom Kiva-Meyer]

The clojure.core.match/match docstring states that it takes "...a vector of
occurrences, vars. Clause question-answer syntax is like `cond`. Questions
must be wrapped in a vector..."
https://github.com/clojure/core.match/blob/5429e20f5db8c398d745f15f7a85f65976f45397/src/main/clojure/clojure/core/match.clj#L1966-1976

However, it seems to work without wrapping the occurrences and questions in
vectors.

(match [{:a 1 :b 2}]   [{:a 1 :b x}] x);;=> 2(match {:a 1 :b 2}
   {:a 1 :b x} x);;=> 2

Is the docstring outdated or are there circumstances that necessitate
wrapping the occurrence/s and question/s in vectors?

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

[Dom Kiva-Meyer]

Great changes! I have a question about #5.


> 5) New "some" operations
> Many conditional functions rely on logical truth (where "falsey"
> values are nil or false). Sometimes it is useful to have functions
> that rely on "not nilness" instead. These functions have been added to
> support these cases [CLJ-1343]:
> * some? - same as (not (nil? x))
> * if-some - like if-let, but checks (not (nil? test)) instead of test
> * when-some - like when-let, but checks (not (nil? test)) instead of test


It seems inconsistent to have "some" mean two very different things within
the same namespace, especially since the prior uses of "some" (`some`,
`some-fn`, etc.) are more in keeping with its primary definition of having
to do with amount (and operate on seqs or variadic arguments) while the new
functions have to do with existence (and operate on any single value). Why
not call these new functions `not-nil?`, `if-not-nil`, and `when-not-nil`?
Or, if "not-nil" is too unwieldy then what about "exists" (`exists?`,
`if-exists`, `when-exists`)?

Are these names up for discussion?

Cheers,
Dom


On Fri, Feb 14, 2014 at 11:04 AM, Alex Miller  wrote:

> Clojure 1.6.0-beta1 is now available.
>
> Try it via
> - Download:
> http://central.maven.org/maven2/org/clojure/clojure/1.6.0-beta1
> - Leiningen: [org.clojure/clojure "1.6.0-beta1"]
>
> Highlights below or see the full change log here:
> https://github.com/clojure/clojure/blob/master/changes.md
>
> We expect Clojure 1.6.0-beta1 to be close to a release candidate; no other
> big changes are planned. Please give us your feedback and final issues if
> you find them so we can do the final release!
>
> Clojure 1.6.0-beta1 has the following changes from 1.5.1:
>
> 1) Clojure now builds with Java SE 1.6 and emits bytecode requiring Java
> SE 1.6 instead of Java SE 1.5. [CLJ-1268]
>
> 2) The following features are no longer marked "Alpha" in Clojure:
>
> * Watches - add-watch, remove-watch
> * Transients - transient, persistent!, conj!, assoc!, dissoc!, pop!, disj!
> * Exception data - ex-info, ex-data
> * Promises - promise, deliver
> * Records - defrecord
> * Types - deftype
> * Pretty-print tables - print-table
>
> 3) The clojure.java.api package provides a minimal interface to bootstrap
> Clojure access from other JVM languages. Example:
>
> IFn map = Clojure.var("clojure.core", "map");
> IFn inc = Clojure.var("clojure.core", "inc");
> map.invoke(inc, Clojure.read("[1 2 3]"));
>
> 4) Map destructuring extended to support namespaced keys. [CLJ-1318]
>
> In the past, map destructuring with :keys and :syms would not work
> with maps containing namespaced keys or symbols. The :keys and :syms
> forms have been updated to allow them to match namespaced keys and
> bind to a local variable based on the name.
>
> Examples:
>
> (let [m {:x/a 1, :y/b 2}
>   {:keys [x/a y/b]} m]
>   (+ a b))
>
> (let [m {'x/a 1, 'y/b 2}
>   {:syms [x/a y/b]} m]
>   (+ a b))
>
> Additionally, the :keys form can now take keywords instead of symbols.
>  This provides support specifically for auto-resolved keywords:
>
> (let [m {::x 1}
>   {:keys [::x]} m]
>   x)
>
> 5) New "some" operations
>
> Many conditional functions rely on logical truth (where "falsey"
> values are nil or false). Sometimes it is useful to have functions
> that rely on "not nilness" instead. These functions have been added to
> support these cases [CLJ-1343]:
>
> * some? - same as (not (nil? x))
> * if-some - like if-let, but checks (not (nil? test)) instead of test
> * when-some - like when-let, but checks (not (nil? test)) instead of test
>
> 6) Hashing overhaul
>
> The Clojure hash algorithms have changed for many primitives and
> collections.
> Read the changelog and http://clojure.org/data_structures#hash for more
> detail
> and if you are building external collections.
>
> In general, this change creates better hash codes (better bit dispersion,
> fewer
> collisions) to improve performance of hashed collections (maps and sets).
> *NOTE:* One side effect may be that code currently relying on the
> arbitrary order
> of hashed elements in a collection (tests for example) may need to be
> fixed.
>
> 7) Other new things
>
> * unsigned-bit-shift-right - Java's >>>
> * clojure.test/test-vars - run a set of tests with fixtures
>
> 8) Printing enhancements
>
> * [CLJ-908](http://dev.clojure.org/jira/browse/CLJ-908)
>   Print metadata for functions when *print-meta* is true and remove errant
> space at beginning.
> * [CLJ-937](http://dev.clojure.org/jira/browse/CLJ-937)
>   pprint cl-format now supports E, F, and G formats for ratios.
>
> 9) Error messages
>
> * [CLJ-1248](http://dev.clojure.org/jira/browse/CLJ-1248)
>   Print type information in reflection messages to help diagnose problem.
> * [CLJ-1099](http://dev.clojure.org/jira/browse/CLJ-1099)
>   If non-seq passed where seq is needed, error message now is an
> ExceptionInfo with the instance value, retrievable via ex-data.

Re: What is "#" doing in " #+cljs [cljs.reader :as reader] "

[Dom Kiva-Meyer]

It's for the cljx preprocessor (https://github.com/lynaghk/cljx).


On Fri, Feb 7, 2014 at 7:46 PM, larry google groups <
lawrencecloj...@gmail.com> wrote:

>
> I am looking here:
>
> https://github.com/jkk/formative/blob/master/src/formative/parse.cljx
>
> and I see this line:
>
> #+cljs [cljs.reader :as reader]
>
> So I look here to see what the "#" is doing:
>
> http://clojure.org/reader
>
> and I read:
>
> Dispatch (#)
> The dispatch macro causes the reader to use a reader macro from another
> table, indexed by the character following #:
>
> However, this is not a set, a regex, a var-quote, an Anonymous function
> literal, nor a comment/ignore, so what is this exactly?
>
>
>  --
> 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/groups/opt_out.
>

-- 
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/groups/opt_out.

Re: Redefining the notion of S-EXP, and pattern matching S-EXPs in clojure

[Dom Kiva-Meyer]

I'm not sure if this is what you're looking for, but seqex (
https://github.com/jclaggett/seqex) might be of use.


On Sun, Jan 19, 2014 at 9:40 AM, Dave Tenny  wrote:

> As I try to reconcile my ancient past in writing common lisp code with a
> clojure learning exercise,
> I wonder whether clojure philosophy redefines the notion of an s-expression
> or whether it just  adds vectors and maps to s-expressions in without
> trying to define what an s-expression is.
>
> The question came up as I was looking for a certain capability in clojure
> libraries.
>
> Back in the day when lisps had only parenthesized collection types, there
> were lisp libraries
> (whose names I've long since forgotten) that would allow pattern matching
> of s-expressions,
> so that you could describe a pattern, match it to some tree, pick up
> matches and continue to match some more.
>
> Sort of like java.util.Matcher.find().
>
> However with every clojure program (and program output) being a huge set
> of lists, vectors, and maps
> I was looking for an s-exp matcher that would allow pattern expressions of
> and matching against paths of combinations of these data structures.
>
> Sort of like enlive/select can traverse a nasty list/vector/map output of
> enlive/html-resource with predicates that will match a sequence of nodes in
> the web page.
> (Only I don't think enlive/select returns matcher state that allows
> continuation from where you left off, maybe it does, and of course it's
> html oriented).
>
> Looking at the clojure.walk and clojure.zip stuff, I don't see anything
> other than low level tools for certain kinds of traversals.
>
> What libraries are there for higher level "reach in and grab patterns of
> data" abstractions that will work against a tree of lists/vectors/maps (and
> preferably any other walkable data structure in clojure)?
>
> Looking for suggestions, and whatever philosophy there is about
> s-expressions in clojure like reader environments.
>
> If I wanted lists, vectors, and maps with no zen, I'd be using python ;-)
>
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.