CHAMP an improvement on HAMT?

2017-08-14 Thread Didier
I think that paper is from 2015. Curious to hear what are people's thoughts as 
to why it didn't replace Clojure's HAMT. I wouldn't mind a free 3x performance 
boost and a reduced memory footprint. Is it just a matter of didn't have 
someone doing the work, or did it turn out that there was issues with CHAMP 
that would prevent Clojure's default core data structures from being migrated 
to it?

-- 
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] Specter 1.0.3

2017-08-14 Thread Nathan Marz
Specter supercharges your ability to query and manipulate regular Clojure 
data structures. https://github.com/nathanmarz/specter

1.0.3 includes navigators for navigating to the index of an element in a 
sequence, a so far unexplored area of the problem space. Some examples of 
the new functionality:

(setval (index-nav 3) 1 [:a :b :c :d :e])
;; => [:a :d :b :c :e]

(select INDEXED-VALS [:a :b :c])
;; => [[0 :a] [1 :b] [2 :c]]

(setval [INDEXED-VALS FIRST] 0 [:a :b :c :d])
;; => [:d :c :b :a]

(setval (before-index 2) :a '(0 1 2 3 4))
;; => (0 1 :a 2 3 4)


Full changelog:

* Added `before-index` navigator for inserting a single element into a 
sequence.
* Added `index-nav` navigator for moving an element in a sequence to a new 
index, shifting other elements in the process.
* Added `INDEXED-VALS` navigator for navigating to every element of a 
sequence as [index elem] pair. Transform on index portion works the same as 
`index-nav`.
* Workaround for ClojureScript regression that causes warnings for record 
fields named "var" or other reserved names

-- 
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: CHAMP an improvement on HAMT?

2017-08-14 Thread Timothy Baldridge
It came up today in the Clojurian's Slack mailing list, and it sounds like
the gist is that the papers did a bit of a apples-to-oranges comparison by
using a different hashing algorithm when comparing CHAMP to Clojure's
hashmaps. Once this difference is rectified the performance improvements
are much smaller, if they exist at all. Apparently CHAMP uses less memory,
and that might be a reason to switch, but I think the efforts to integrate
CHAMP mostly died when the fixed benchmarks failed to show significant
performance gains.

On Mon, Aug 14, 2017 at 3:00 AM, Didier  wrote:

> I think that paper is from 2015. Curious to hear what are people's
> thoughts as to why it didn't replace Clojure's HAMT. I wouldn't mind a free
> 3x performance boost and a reduced memory footprint. Is it just a matter of
> didn't have someone doing the work, or did it turn out that there was
> issues with CHAMP that would prevent Clojure's default core data structures
> from being migrated to it?
>
> --
> 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: Spec without global registry?

2017-08-14 Thread Mario T. Lanza
First of all, Clojure, core.async, spec, the whole of what you guys produce 
is fabulous.  I have nothing but respect for the work you're all doing. 
 It's Clojure's simple design that has me enjoying programming more than 
ever.

That said, I'd like to add a new perspective to the discussion Mark 
started.  It has a wider application than spec alone.

Baldridge in Core Async in Use  
(great talk!) exemplifies how to do apis that are asynchronous.  He 
encourages developers to avoid asynchronous code, pushing its necessary 
appearance to as few strategic points as possible.

This parallels the fundamental Clojure separation of identity from state. 
 It is by the nature of pushing the necessary manipulation of state to as 
few strategic points as possible that we can lean on pure functions.

Using globals reduces this separation and makes a design more imperative. 
 The possibility of fine-grained control is lost when state is pushed into 
globals.  I can appreciate that globals have a place in simplifying a 
public api, but why not fully expose the underlying data structures?  This 
was done with hierarchies.

Hierarchies (the defining of is-a relationships via `derive`) are directly 
related to spec as evidenced by the existence of `multi-spec`.  So if 
hiearchies, which have their own global counterpart, are exposed, it would 
appear consistent to expose the registry.  Both are related.  They're both 
used to define ontologies.

So while spec's use of a global registry suits most cases, it complicates 
things for those like me who want first-class schemas.  I am building a CMS 
where schemas are a core feature.  I need to manage their lifetimes and 
scopes at runtime.

I can't imagine it would have been much harder to implement spec using what 
what Gary Bernhardt refers to as a Functional Core, Imperative Shell 
.
 
 It's a good principle.  I find that it aligns  closely with idea of 
deferring the messy parts for later found in both Baldridge's talk and 
Clojure's state management strategy.

I've found that designing around a functional core increases possibilities. 
 It's what:

   - makes implementing undo/redo mostly trivial.
   - allows control over the lifetime and scope of constructs.
   - enables the use of single state atoms that host nested data structures
   
When we only have access to the imperative shell, these things are not 
possible.

To help illustrate, the following lines are listed in the order of 
increasing possibility.

(derive tag parent)
(derive h tag parent)
(swap! h (derive tag parent))

Only one of these options -- the one using a pure function -- accommodates 
all of the above possibilities.  The longer I've done Clojure, the closer 
I've come to a consistent use of this approach.

spec's design unnecessarily takes things off the table.

I know I'm being dogmatic, but why not consistently expose a functional 
core as a matter of principle?

Thanks for your consideration.

Mario

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


Blending the Functional Programming style (in Clojure, etc.) with Object-orientation.

2017-08-14 Thread Akram Ahmad
- Nothing earth-shattering, but I believe that many, perhaps all of you 
will enjoy taking a peek at an exploration of *blending the functional 
programming style with object-orientation*.
- Plenty of reference to Clojure, Lisp, and Scala.
- You can read at your leisure by visiting: When Object Orientation Met 
Functional Programming 

- Enjoy :)

-- 
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: Question about transitivity in MultiFn.prefers() --- possible bug

2017-08-14 Thread John Alan McDonald
A related but slightly different issue: is prefer-method supposed to be 
transitive?
That is,  (prefer-method f a b) and  (prefer-method f b c) implies 
(prefer-method f a c)?
Here is a unit test that checks for transitivity (which fails in Clojure 
1.8.0):

(test/deftest transitive
  (derive ::transitive-d ::transitive-a)
  (derive ::transitive-d ::transitive-c)
  (defmulti transitive identity)
  (defmethod transitive ::transitive-a [x] [::transitive-a x]) 
  (defmethod transitive ::transitive-c [x] [::transitive-c x]) 
  (prefer-method transitive ::transitive-a ::transitive-b)
  (prefer-method transitive ::transitive-b ::transitive-c)
  (test/is (= [::transitive-a ::transitive-d] 
  (transitive ::transitive-d


-- 
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: CHAMP an improvement on HAMT?

2017-08-14 Thread Colin Fleming
Previous discussion from Zach Tellman about his CHAMP implementation
(bifurcan): https://groups.google.com/d/topic/clojure/1m_I7IrDGb0/discussion

It seems that Clojure's hashing and in particular equality semantics are
relatively expensive, and this accounts for most of the performance
difference. Zach's implementation does offer some advantages (faster
iteration, lower memory usage and some improved operations specific to each
data structure) but if you're stuck with Clojure's hashing and equality the
gains are not as significant.

On 15 August 2017 at 03:23, Timothy Baldridge  wrote:

> It came up today in the Clojurian's Slack mailing list, and it sounds like
> the gist is that the papers did a bit of a apples-to-oranges comparison by
> using a different hashing algorithm when comparing CHAMP to Clojure's
> hashmaps. Once this difference is rectified the performance improvements
> are much smaller, if they exist at all. Apparently CHAMP uses less memory,
> and that might be a reason to switch, but I think the efforts to integrate
> CHAMP mostly died when the fixed benchmarks failed to show significant
> performance gains.
>
> On Mon, Aug 14, 2017 at 3:00 AM, Didier  wrote:
>
>> I think that paper is from 2015. Curious to hear what are people's
>> thoughts as to why it didn't replace Clojure's HAMT. I wouldn't mind a free
>> 3x performance boost and a reduced memory footprint. Is it just a matter of
>> didn't have someone doing the work, or did it turn out that there was
>> issues with CHAMP that would prevent Clojure's default core data structures
>> from being migrated to it?
>>
>> --
>> 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.


Vote for Clojure support in Natural Docs

2017-08-14 Thread Mark Engelberg
Back in the day, I used to use Natural Docs to build great docs for my
projects.  There's a new version out, and the author of the project is
asking people about what languages to support.  I encourage you to upvote
the Clojure suggestion:
https://www.reddit.com/r/NaturalDocs/comments/6trhdo/which_languages_do_you_want_to_see_supported_in_21/

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