Somewhere on this list of videos https://www.youtube.com/user/ClojureTV/search?query=clojure.spec ...

I thought Rich had done a talk at a user group about clojure.spec but I’m not finding it there...

Ah, it may be this one https://vimeo.com/195711510

FWIW, I was one of the early skeptics who wanted :ret checked via instrument for example-based testing / regular execution. Rich’s arguments have persuaded me otherwise (along with other people elaborating on it).

@seancorfield : thanks for the resources

I'm having trouble with this code https://gist.github.com/olslash/4804c246b02e5a9e7237aed3ec41ed07 -- specifically the result that's being written is about 10MB bigger than if I let OSX unzip the file, and it's corrupt

i thought i might be doing something wrong with the io/ stuff

anyone able to help? that gunzip fn is from a stackoverflow post

looks like the fn works, i just had to untar as well 🙂

does anyone known how to convert scala.collection.immutable.HashMap$HashTrieMap to hash-map: when i transform it, throws ----- Don't know how to create ISeq from: scala.collection.immutable.HashMap$HashTrieMap

@jiyouyou125 I am imagining it would involve an extend-type to make the scala HashTrieMap support the ISeq interface, but never done that before...

@iku000888 thanks, i use JavaConversions.mapAsJavaMap to convert to java.util.HashMap, it’s scala world. 😂

hi guys

I was looking at a clj optimization/hackerrank problem my friend showed me

and I can’t seem to improve his version

its basically a trie, here’s the repo: https://github.com/tdantas/js-clj-challenge

do you have any ideas?

actually I dont think he did a trie, its just a hashmap

I'm trying to explore map composition, haskell type: fmap.fmap :: (Functor f, Functor g) => (a -> b) -> f (g a) -> f (g b) and I'm using (comp map map) but it's behaving unexpectedly... this is what I want: (fmap . fmap) (+1) [[1, 2], [3, 4]] => [[2,3],[4,5]] but this returns an obscure function: (((comp map map) inc [[1 2 3] [4 5 6]])) which takes an index, and returns the map incd vector at that index (IE [2 3 4] for 0) (this was if I did ((comp map map) inc) and applied that to a vector of vectors) what am I doing wrong? Is there a way to apply comp to map map, to see what that function is looking like/expanding to?

(like a macro-expand but for functions?)

Part of your problem here is that map can take one argument or many — and they mean different things. (map inc) is a transducer and transducers compose just fine but you can’t map a transducer over a collection, which is what you’re essentially trying to do.

good point, I did try too: (comp #(map %1 %2) #(map %1 %2))

but I'm getting a bit lost

in what the fns are doing

comp expects to work with functions of a single argument.

should I curry the maps then?

(map (partial map inc) [[1 2] [3 4]]) should work.

hm, my exercise is to play with composition, and i wanted to try next composing 3 maps...

(I'm trying to play with lenses, a la: https://github.com/ekmett/lens/wiki/Derivation)

Clojure != Haskell.

sure, but the data access pattern that lenses allow interests me, since it's so composable

But you perhaps need to look at transducers which might get you closer?

I love transducers and hadn't considered them as an alternative to lenses...

basically, I want to create a protocol that allows a uniform data access interface that I can extend to databases, datascript, clojure maps, or anything really, even API endpoints

lenses seem to afford me the composition I need if this protocol should work

Sounds like Specter…?

if I recall, specter is largely built from macros, which I would imagine suffer when it comes to composing them, and I flat out don't know how to implement them as a protocol that could be extended... a slightly sideways question that would help me solve this, it's tough when clojure evals something to, eg: #function[clojure.core/comp/fn--3483] to know whats going on...

do you know of a way to "function expand", short of doing it by hand?

The only way I can think of is to name all your anonymous function sub-expressions...

@josh.freckleton the core of specter is a simple protocol for navigation

it composes extremely well, that's the whole point of the library

your example in specter is just (transform [ALL ALL] inc [[1 2 3] [4 5 6]]) => [[2 3 4] [5 6 7]]

@nathanmarz could you show me the same example in spectre using composition? like, I might expect: (comp (transform [ALL]) (transform [ALL] inc))

the composition is just done by making a sequence

if you want a navigator which goes into sequence of sequences, just do (def my-nav (comp-paths ALL ALL))

then you could do (transform my-nav inc [[1 2 3] [4 5 6]])

awesome, thank you! I think this looks like a useful way of data nav, but I'm wondering if I can't bring into clojure some of the mathy/generalized goodness of haskell/category theory

let me know if I'm misguided and just not seeing that yours really is my answer 😉

Remember, Clojure != Haskell 😆

i personally find haskell's lenses overly complicated

Seriously tho’, that’s why I thought of Specter in the first place.

there's no reason to have a distinction between "Lens" and "Traversal"

BTW @nathanmarz do you have a highlight / alert for the word “specter” in here? 🙂

yea :)

Heh, didn’t mean to invoke you during the holidays!

thanks to both of you for jumping in to help! sorry if I'm a bit bull-headed about bringing in haskell idioms. I like their "promises" that their generalities offer

I really think you’re going to create more pain for yourself trying to write Haskell in Clojure — the idioms are completely different.

and you can't guarantee nearly as much

and you can't make polymorphic constants

ok, maybe I should reconsider. what I'm trying to do is this: for web apps, I notice a huge cost in repeating oneself at the db layer, api, frontend api access, UI, etc., but data essentially remains "the same" wherever it is... I don't want to need to SELECT from a db, and GET from an endpoint, and (get ...) from a map, so I was hoping to abstract that and lenses seemed like a fruitful direction to search in... Imagine if you had 2 SELECTs you wanted to perform, and could compose them intelligently together, instead of needing to write and maintain ad hoc SQL?!

or two http GETs for that matter!?

I went down that path recently … and gave it up as soon as I tried to use in the production code 🙂

interesting, you wouldn't have written up about your adventure, would you have? 🙂

No, not yet.

I’d talked about it here ages ago… or maybe on the mailing list? When I was first thinking of going that route… and everyone tried to dissuade me from it… They were right, it was clumsy and painful.

Basically, without a type system like Haskell’s, this stuff is virtually impossible to use in real world code.

^

in haskell, "if it compiles, it works"

but there's lots of steps where it seems like it should compile

imagine if you just got back from ghc "no"

hm... I'm not sufficiently dissuaded, because this sounds so powerful if it existed! I just tried to search for your old conversations, would you be able to point me to them, or in a direction you think would shed light on why this isn't possible, or why I should reconsider?

@dpsutton I'm not sure I understand how that relates... sure haskell has a killer compiler, and type system, clojure's lack of those tools precludes this idea from working?

my point was just that I can't imagine being lost in types in haskell without the type system itself

trying to reason that without any guidance, like in a dynamic language, would be painful

my coworker is big on type theory and lenses

and if he describes them as "magic", I can't imagine trying to wade through that without a very persnickety compiler

that was my point

ah, thank you 🙂

ya, that makes sense too

it certainly could be done

That language would be Prolog 🙂 https://clojurians.slack.com/archives/clojure/p1482861333006757

I think idiomatic use of the language is radically different between Haskell and Clojure https://clojurians.slack.com/archives/clojure/p1482861511006760

The efforts to try to create Haskell versions of Clojure’s transducers showed that well…

Clojure’s transducers are simply not idiomatic in Haskell — you’d naturally take a different approach (an approach that would be non-idiomatic in Clojure).

What is the state of art in Clojure parsing? OMeta? Peg/SquarePeg? Parsec/Parsatron?

Instaparse is pretty snazzy https://github.com/Engelberg/instaparse

It's handled all the parsing needs I've come across, so I've never researched what else might be available

@josh.freckleton Have you seen this? http://calmm-js.github.io/partial.lenses/ - it's an attempt to bring lenses to JavaScript, and as such, one answer to the question of what lenses should look like in a dynamic language. To me, it looks a lot like Specter.

@geoffs: I feel like "generate all possible parses" is the wrong solution to the "possible ambigious grammer" problem

I don't believe it does that by default

You can ask for all parse trees

with the idea being that making unambiguous grammars could be really tricky

but you normally get only one

@miikka (thanks for pointing that out to me, I'll check it out)

> Optionally produces lazy sequence of all parses (especially useful for diagnosing and debugging ambiguous grammars).

Generally, ambiguous grammars = slow grammars

(in my experience)

But insta/parses can expose most ambiguity issues.

Yeah, so one of the nice things about Peg is that rules have priority ==> no ambiguity. similarly with Parsec.

Well, the reason ambiguous grammars are slow is that the parser churns trying to generate and branch out from many possibilities. So introducing priority won't necessarily solve that, just change the order in which things are tried.

(btw, there's an #instaparse channel if you'd like to sidebar on this)

Example of parses NOT properly exposing ambiguity:

(def p (insta/parser "S = 'b' <A> <A> <A> <A> <A> <A> 'b'; A = 'a'+"))
(time (count (insta/parses p "baaaaaaaaaaaaaaaaaaaaaaaaaaaaaab")))
"Elapsed time: 2608.163607 msecs"
1

(FWIW, we’re a happy Instaparse customer at World Singles: we use it to allow Customer Service to enter search rules in “English” and it parses them into criteria and dimensions for the Discovery search engine)

So, pseudo-English -> Clojure data -> JSON -> search engine -> results 🙂

is core.match still being maintained? is it (1) it's ditched or (2) it's so complete that it no longer needs changes?

@qqq I wonder consider it mature and “complete” at present.

@seancorfield : thanks for confirmintg, the lastest I ee is 0.3.0-alpha4, and the alpha4 did not provide confidence on it being completed

(even tho’ there are 33 open issues logged against it in JIRA)

FYI http://dev.clojure.org/jira/secure/IssueNavigator.jspa?sorter/field=updated&sorter/order=DESC

These are the unreleased changes since 0.3.0-alpha4 https://github.com/clojure/core.match/compare/cf99094494050629285fcb83915af02fdc8162b4...master

Regarding the “alpha” label, a lot of the contrib libraries tend to be pretty stable even in alpha, i.e., safe to use in production unless they explicit say not to do so.

dnolen came in a week or two ago when i asked the same question

maybe his answer is still in history

tools.namespace, data.xml, java.jdbc are all currently offering “alpha” versions and we use all three of those in production — along with Clojure 1.9 (alpha 14 in production)

basically he said he has new ideas but no time to work on them, that it's stable, and being used in production

got it; I'm just suggesting people would be slightly more comfortable if it was 0.3.1 instead of 0.3.0-alpha4 🙂

@olslash The 10,000 message limit here means we get less than a week of archives, I’m afraid.

yeahi thought as much

i asked about "alpha" as well -- he said it was basically a meaningless marker

“alpha” just means the API may still change before the next “gold” release.

But any individual version is just fine to use. You usually only have problems shifting across versions (which you could have anyway, even with non-alpha versions).

Although that may change after Rich’s “Spec-ulation” keynote at Clojure/conj 😸

That all reminds me, I need to nail down java.jdbc and get a “beta” release out! 🙂

its unoptimized in js

and is fine in java

it uses try/catch which is a goto in java but unfortunately removes all optimizations in js

he considers it stable but has a few things he wants to do before releasing a non beta version

per conversation at conj

I've submitted one pull request to it and I'm still working my way through the paper on how to go from a back tracking automata to the decision tree style compiler

but any core projects are extremely stable in the sense that they do not change without great contemplation