Enhancement proposals from Dunaj

[Jozef Wagner]

Dear Clojure team,

I've created Dunaj [1] to test some big ideas I had, mainly a reducers first approach and using protocols for built-in abstractions. I'm fairly happy with the result, as it is (subjectively) simple to use, and the implementation is more performant than Clojure nearly everywhere. The introduction of batched reductions enabled the creation of data formatters and resources that are very fast and can be used for real world cases.

I did not have enough time to implement each small or big idea separatedly so that it would be easy to merge into Clojure. Current Dunaj is rather a testbed for new ideas rather than something that can be merged into Clojure. If you consider some of Dunaj's features worth of adding into Clojure, please let me know and I'll try to prepare smaller library more focused on a specific feature.

Moreover, I'm not at all happy that I had to fork Clojure and I've tried really hard to minimize the number of changes there. If some of changes I've made have a chance to be included into Clojure, I can create feature tickets with respective patches and feature enhancement wiki pages for more focused discussion.

This is the list of changes I've made in Clojure:

* support for :api declaration in ns, which customizes what gets referred automatically (supersedes :refer-clojure)

* support for qualified specials. Unqualified specials keep working as usual.

* a per ns option to turn off support for unqualified specials

* support for more primitive types in fn args and return values

* iloop macro that does not cast int constants to long automatically

* speed improvements for satisfies?

* map-like deftype instance similar to what defprotocol does now

* ability to create protocol on top of existing interface, or its part

If any of these are in line with Clojure's direction and goals, please let me know and I'll prepare a ticket/patch.

Thanks,

Jozef Wagner

[1] http://www.dunaj.org/

[Herwig Hochleitner]

Hi Jozef,

Dunaj is a very interesting project. It implements a lot from clojure's future and there are a lot of things in it, that make sense to me.

I sincerely hope that core takes you up on it.

Maybe it would help to identify a minimal set of changes necessary to clojure, such that dunaj could exist as a library.

kind regards

[Jozef Wagner]

Hi,

Dunaj was designed from the beginning to be as much compatible with Clojure as possible. I've released today a library-only version of Dunaj called Dunaj lite. [1] 

The Clojure changes Dunaj would benefit the most are the qualified specials, more primitive types (and iloop macro) and the addition of :api declaration in ns macro. With these additions, Dunaj is faster and simpler to use.

Best,

Jozef

[1] http://lite.dunaj.org/

[Herwig Hochleitner]

Of the changes, that you propose for clojure, I do like the interface-protocol one as well as well as handling primitive types (reservation: the work there should be towards good support for value types in general).

I'm especially interested in that :api key, that you propose. I've wondered many times, about how more explicit control over the default setup of the namespace could look like. I think :api is a pretty good shot. It not only supports non-standard namespace layouts (like DSL files), packaging tools could also use the mechanism to provide different versions of an api to different namespaces within the same runtime.

I'd care for a ticket on how such a namespace setup hook could look like in clojure.