One problem solved, next problem introduced (compiler can't find the matching todictionary):
(let [^System.Int32 b 2
a [1]]
(System.Linq.Enumerable/ToDictionary
^|System.Collections.Generic.IEnumerable`1[[System.Object]]| a
(sys-func [System.Object System.Int32] [x] b)
(sys-func [System.Object System.Int32] [x] b))))I think I can solve the problem more simply with small changes to existing mechanisms. Please take a look at https://github.com/dmiller/clojure-clr-next/discussions/6. (I'll post a general announcement for this in moment.)
Well, I found "a" solution, although it works by luck (sort of). My use-case is that I have a persistent map and need to provide a dictionary to C-sharp code. ToDictionary seems to be the goto for converting the clojure object to object dictionary to something that is typed. With a vector, and simple object, I can get it to work. But not with a dictionary and keyvaluepairs. But what does work, is to give type-args. Unfortunatly type-args are checked to be equal in count to the arguments. And with the to-dictionary default call, the number is 1 more. So luckely, the todictionary can be provided with a comparer object (which does not introduce a new type).
(let [a {:a 2}]
(System.Linq.Enumerable/ToDictionary
(type-args
|System.Collections.Generic.KeyValuePair`2[[System.Object],[System.Object]]|
System.Int32
System.Int32)
a
(sys-func [|System.Collections.Generic.KeyValuePair`2[[System.Object],[System.Object]]| System.Int32] [x] (int 3))
(sys-func [|System.Collections.Generic.KeyValuePair`2[[System.Object],[System.Object]]| System.Int32] [x] (int 4))
(|System.Collections.Generic.EqualityComparer`1[System.Int32]|/get_Default))))Next step, is to put in more realistics types (in my case a "Tuple" type)
Glad to do it (my real world usage is even worse). In the end I decided to simply create a dictionary and use run! to fill it from the clojure map and not use the "ToDictionary" function.
BTW, as to the "new type naming syntax", I also use some normal clojure parsing on the files (for formatting and form detection). I now need to have a regexp to transform every |...| symbol to something the passes in these tools and then regexp it back, very dirty.
That sounds unfortunate.
There is no question any alternative syntax for types will have characters that cannot be read as symbols by the standard Clojure reader. So I'm wondering if tagged literals are the way to go. That way we can use strings to hold the type syntax and let the associated reader translate that to a symbol. That would work even in Clojure(JVM) -- as long as you didn't try to translate the symbol to the actual type.
Something like:
#cljr/type "Dictionary<int,DnsEndPoint>"
Where we would allow (a) the special type symbols already in use in Clojure (`int`, ints, etc.). (b) no longer need to specify the number of generic arguments as currently is required, (c) pick up imported type names (assuming in the example that System.Net.EndPoint was imported. But this is going to require careful attention to where symbol-to-type mapping is done, maybe use metadata on the symbol so that the symbol is translated properly by the printer (with different results depending on the value of "print-dup", etc., etc.)
That the reader and type-mapping semantics. The actual syntax would also have to be defined. C# could be used for guidance here.
I'll take a look later today. Would you like to be added to the "new type naming syntax" committee? After typing all that, I'd think you'd be on board. (I'm not actually joking. It's big on my wish list.)