Hi all, just nit picking about Clojure's String API.
I've been comparing it with Java's
http://www.tutorialspoint.com/java/java_strings.htm, and I noticed that
(not surprisingly) they are very similar.
There are just 2-3 functions that exist in Java but don't have an
equivalent in Clojure. I
Backstory:
I modified the cljs.repl/repl to instead of pulling characters from *in*,
but to use core.async channels, and to !! on an input-channel. When an
input is received, a StringReader with the input is created and evaluation
continues until either an error or printed output occur.
Pierre:
I maintain the cheatsheet, and I put .indexOf and .lastIndexOf on there
since they are probably the most common thing I saw asked about that is in
the Java API but not the Clojure API, for strings. There are also links to
whole Java classes and their entire API, e.g. for file I/O, for
Andy,
How much of this reasoning do you think changes when we starting
thinking about being hosted on multiple platforms (I'm thinking
specifically clojure/clojurescript and cljx)?
cheers,
Bruce
On Sat, Jul 19, 2014 at 4:17 PM, Andy Fingerhut
andy.finger...@gmail.com wrote:
Pierre:
I
I would have to defer that question to someone who makes decisions
regarding what goes into Clojure/ClojureScript, and what does not.
Of course, anyone else is free to create libraries that try to make
portability between those two platforms easier. Perhaps someone has
already taken a go at
Thank you for your insight Andy :-)
Interesting question Bruce.
-- Pierre Masci
On 19 July 2014 16:49, Andy Fingerhut andy.finger...@gmail.com wrote:
I would have to defer that question to someone who makes decisions
regarding what goes into Clojure/ClojureScript, and what does not.
Of
What does `empty` do for non-collection types?:
(empty 1) = nil
(empty 123) = nil
(empty :abc) = nil
(empty (clojure.lang.MapEntry. a 1))
So it is actually very consistent.
On Fri, Jul 18, 2014 at 6:06 PM, Brian Craft craft.br...@gmail.com wrote:
hm, looks even more broken in the context of
MapEntry is a collection:
(coll? (clojure.lang.MapEntry. a 1))
;= true
(ancestors (class (clojure.lang.MapEntry. a 1)))
;= (a set that includes clojure.lang.IPersistentCollection)
The docstring for empty implies it would return an empty MapEntry. But
perhaps since MapEntry is a special
As Mike points out, it does seem that MapEntry is considered a collection
and is designed to emulate a vector so that you don't really have to worry
about whether you have a MapEntry or a two-element vector (and as he points
out, in ClojureScript there really is no distinction between a MapEntry
While the c.l.MapEntry is a persistent vector, there is no such thing as an
empty MapEntry persistent vector. Returning empty HAMT persistent vector
instead is not a good solution, as 2 elements HAMT vector does not
implement IMapEntry interface.
One approach on how to solve this is in Zach's
I've been bitten by all three of these things in the past:
1) A MapEntry looks like a vector, but isn't.
2) Two element vectors can't be used as map entries.
3) Applying empty to a MapEntry returns nil.
On Saturday, July 19, 2014 4:04:13 PM UTC-4, Jozef Wagner wrote:
While the c.l.MapEntry is
Elastisch [1] is a minimalistic feature rich Clojure client for
ElasticSearch.
2.1 has multiple improvements in the native client, including
the long awaited aggregations support:
http://blog.clojurewerkz.org/blog/2014/07/20/elastisch-2-dot-1-0-beta4-is-released/
1.
You cannot have an empty MapEntry though, because map entries always have
just one size, a key and a value. I can definitely see how it can be
confusing though.
On Sat, Jul 19, 2014 at 4:42 PM, Brandon Bloom brandon.d.bl...@gmail.com
wrote:
I've been bitten by all three of these things in the
I understand that, but the issue that bothers me is that MapEntry prints
like a vector and satisfies the clojure.core/vector? predicate. If you call
first or seq or something like that on a map, your REPL will lie to you.
Worse, you might even be 100% aware that you have a MapEntry instead of a
I did a little “code archaeology” in an attempt to elucidate what Rich may
had been thinking:
In mid 2007, some of the persistent collection implementations had an EMPTY
value defined. [1, 2]. (But, of course, no such EMPTY value was defined for
MapEntrys.)
Around a year later, MapEntrys were
In *Clojure Programming* (Emerick, Carper, Grand) a swap-pairs function is
defined in the section describing how empty allows you to write functions
against abstractions. That function operates on sequentials, and,
importantly, is carefully designed (invoking empty) so that its return type
is
Is there a reason you want an (empty some-map-entry) to implment IMapEntry?
You can already do ordinary modifications on it where it loses the type.
Not sure why empty should be an exception. IMapEntry only provides key,
val, and java.util.Map.MapEntry, and probably if you're modifying map
It's worth mentioning that ClojureScript does not have a MapEntry type.
Vectors implement IMapEntry using nth:
https://github.com/clojure/clojurescript/blob/master/src/cljs/cljs/core.cljs#L3601-L3605
And empty returns an empty vector:
ClojureScript:cljs.user (empty (first {:a 1}))
[]
On
18 matches
Mail list logo
