https://twitter.com/jdegoes/status/924521037496188928 this kind of reasoning makes me wonder if this typing debate isn't just a huge waste of time

It is. It's the new vi vs emacs

would there be any interest in opening up some of the non-core libraries to PR style development on github? logic, match, avl, rrb, etc?

I know there is great benefit to the workflow in core and the compiler, just wondering if this was also still the case for some of these libraries that haven't been touched in a while

@dpsutton: is the current model for this "Stuart Hallloway reads every line of code" ?

I meant more of the roles and eyes that it goes through before acceptance. Was wondering if some of that wasn't needed for the libs

in my experience, when clojure versions update, 1. my code never breaks and 2. the libs I depend on rarely breaks; I'm not sure if this is related to 'core contrib being slow moving', but the stability is really nice

@dpsutton To be honest, I don't know that you'd see any more contribution to those libs if there outside of Contrib so I'm not sure what the benefit would be?

i was thinking there would be more with a more easy model of code change.

The JIRA / patch process really isn't onerous. People love to complain about it.

The main issue is IP rights and copyright protection for companies that use Clojure.

I've been through license audits with the legal team at a large corp. That sort of stuff is very important to them.

The GitHub / PR process is fine for "random" libraries out there that companies can pick or choose, but not always for libraries that a (large) company needs to build its products on.

fair enough. it was just a thought

I've done a lot of open source stuff over close to 25 years now. For most projects it's really hard to get contributors, no matter what the process. And there's always lots of folks who use your software and tell you that you should run your project differently 🙂

Clojure has a lot of people who've signed a CA now. The core team did a big push on that at the conferences, encouraging attendees to sign the forms then and there. And they've provided e-signing now to make it easier for non-US folks. The barrier is pretty low.

And back in the day, open source contributions were always done with patches. We didn't have Git back then! waves his stick around

I don't mean to be a downer @dpsutton...

no not at all!

Trust me, I want to see more contributors to open source projects. It's always frustrating.

A lot of people say "Oh, I'd contribute if only X or Y..." but usually if you do X or Y they don't contribute anyway. They come up with a new excuse.

Folks who will contribute tend to contribute almost no matter what the process is. Because the process isn't why they do or don't contribute, when it comes down to it.

in parsing algorithms for expressions (shunting yard, pratt's parser, top down precedence), what happens when 1. operator +foo+ and operator +bar+ both have same precedence level 2. one is left-associative and one is right-associative ?

A +foo+ B +bar+ C foo is LEFT, and wants (A +foo+ B) +bar+ C bar is RIGHT, and wants A +foo+ (B +bar+ C) and foo/bar are both on the same precedence level

isn't that called a shift/reduce conflict?

@noisesmith: I never drew the connection between hift/reduced (which I believe is for general CFG) and parsing math expressions (which is very limited grammar over VARs + OPs, and the only issue is a matter of precedence)

I might be misapplying it

isn't that just an ambiguity that needs to be solved with a rule in your parser?

I think I'm going to enforce the following rule: for each level of precedence, all ops in that level must be all LEFT or all RIGHT

doesn't that mean you've hit incorrect input? you need parentheses in that case

is there any language where on the same precedence level there are both left and right associative ops ?

I can't think of any off the top of my head

but yes, parens would solve it