Clojure.core: Batteries Almost Included | Hacker News Reader

Clojure.core: Batteries Almost Included

adambard.com

134 pointsmichaelochurch26 comments

Why did the author mention core.typed, but leave out core.contracts?

https://github.com/clojure/core.contracts

I started writing a bit on contracts, but it was 2am and I really wanted to be done. (I thought I had a little more time between then and HN front page.) You're right, though, I should at least give it a shout and let people know about it.

There is now a (mildly half-assed) blurb on contracts, not that fogus was likely to feel left out otherwise.

Nice writeup, wish this existed back when I worked with Clojure. The migration away from clojure.contrib caused quite the mess. Back then (about a year ago), looking for a function you want (things you would expect in the standard library) was like this:

00:05 Found it in clojure.contrib

01:05 Figured out which standalone library it has moved to (or conclude that it has disappeared)

01:15 Figured artefact/group ID and current version out

That was a bit annoying.

The core.match example uses python-style triple quotes. Is that actually possible in clojure? I would be enormously excited if it is.

I don't think clojure has triple-quoted strings. Something like

    """
    a
    """

parses as three strings, two of which are empty: "", "\na\n", and "". (Clojure strings are allowed to contain literal newlines.)

Hah, so it is. It was pretty late when I finished this one off, sorry about that.

I tried it at a REPL in version 1.5.1 and it didn't work for me. I don't think standard Clojure has triple-quote strings.

why? in clojure strings can be multiline already. so there is no point in triple quotes.

So you don't have to escape internal quotes.

Triple quotes tend to come up for two purposes:

1. Long regular expression strings that have quote marks involved. I'm not a fan of large, complex regexes, but a lot of people dislike the line-noise added by escaping.

2. Docstrings that may have quotes in them.

It's to remove the string escaping that makes literals look different from the strings they describe.

Thanks.

Thinking about it, I guess triple-quoted strings also facilitate doctests involving strings that would otherwise be really awkward to read/write.

No, it's not, my bad. Not that there's a need for them, as it turns out.

I often find myself having to spend more time than necessary to track down how to add these libraries to the dependencies of my leiningen projects.

I think this post would be a lot more useful if it included a link to clojars for each one of these libraries.

They're not on Clojars; the Maven repository they use is build.clojure.org. The project source code for all the contrib libraries is on Github at https://github.com/clojure

Thanks for clarifying !

I was thinking about including the Leiningen dependency line, but I don't want someone including the wrong version later because I didn't update it. Install info is usually pretty prominent on the github pages of the projects (which I've linked to).

I still have no idea what core.unify does.

It is a subset of core.logic's functionality. It allows you to use unification in your code without the full logic engine of core.logic.

This comment assumes I know what core.logic does.

True, but your comment gave no indication of context, your knowledge level of clojure, awareness of logic programming, or an actual question. So, I had no basis to give a response that answered the question you did not ask. I honestly thought you were just trolling.

Give it two patterns with some unknowns and it tries to get values for the unknowns via pattern-matching. That's all it does! It's one of those things that humans do very well but computers have trouble with, so I'm afraid it doesn't look too impressive.

You mean like those problems that prolog is good at solving? Such as those describe here? http://dangoldin.com/2013/06/07/fun-with-prolog-priceonomics...

Cool, thanks!

Quite an awesome whirlwind tour. Didn't know about core.unify, which seems quite impressive.

I suspect core.logic is the more practical library in many cases. I wrote a disproportionate amount on core.unify because I couldn't find any official docs that approached it from the perspective of someone (e.g. me) who didn't already know all about Prolog and unification in general.

Reply on news.ycombinator.com