Improved type naming

[dmiller]

The current mechanism for specifying types using Symbols is cumbersome. It follows the CLR conventions, which are not user-friendly.

|System.Collections.Generic.Dictionary`2[System.Int32, System.String]|

The goal: To be able to write something like

|Dictionary[int, String]|

This would require some type of import statement that would map the name Dictionary to the desired class.

[dmiller]

There is a fairly general mechanism for constructing types already in place in ClojureCLR. Check out ClrTypeSpec. This code has no problem parsing a string such as

|Dictionary[int, String]|

This would be parsed as a type named Dictionary that is generic with two generic type arguments, int and String.
The problem comes in the Resolve method that tries to construct a type based on this information. There are several problems.

• Generic types require the backquote-count. Even something like

|System.Collections.Generic.Dictionary[System.Int32, System.String]|

fails because of the missing `2 after Dictionary.

• Namespace-qualified names are required. We cannot use just Int32 for the generic argument, as in

|System.Collections.Generic.Dictionary[Int32, String]|

This seems odd because they do work at the REPL directly:

user=> Int32
System.Int32
user=> (class Int32)
System.RuntimeType

• We cannot use the type aliases allowed in type hints. These are symbols such as int, long, double, ints, etc. It seems appropriate to be able to write

|Dictionary[int, ints]|

At minimum, our improved type naming system should address each of these problems.

What else would you like to see?

[dmiller]

Given that I have to code any solution we come up with, I'd like to minimize that effort. :)
So I'll start with a proposal that should be fairly easy to implement and solves the problems listed above.
For your consideration.

Let's start with the second problem above, as that is the simplest to solve. (And the solution to this one will have an effect when it comes to solving the first problem above.)

• Namespace-qualified names are required. We cannot use just Int32 for the generic argument, as in

|System.Collections.Generic.Dictionary`2[Int32, String]|

Why does this work at the REPL?

user=> Int32
System.Int32
user=> (class Int32)
System.RuntimeType

The reason is that namespaces have mappings from symbols to values. When eval sees a symbol, it looks up, among other actions it looks up the mapping of the symbol in the current namespace. Most of the mappings in a namespace are from Symbol to Var. If you eval

(def v 7)

in the current namespace, a mapping is established from the Symbol v to a Var that has 7 as its value. When you evaluate

v  ; => 7

eval looks up v in the namespace mapping, finds the Var and evaluates it, which yields the value stored in that Var.

Why does

user=> Int32
System.Int32

work? When a namespace is created, it is set up with set of default mappings. The code runs through loaded assemblies and looks for all public classes/interfaces/value-types with a namespace of System (with a few other restrictions) and maps the basic type name (no namespace qualifier) to the type. Thus the symbol Int32 gets mapped to the type System.Int32. (NB: in the original days, the list of types was curated by hand. When we went from Framework to also supporting Core, we wrote code to navigate all assemblies to find the types to map into the namespace.)

The simplest solution to our problem is to have the method ClrTypeSpec.Resolve first check the current namespace's mappings and use the mapped type if it exists. Thus, when resolving the generic type argument Int32 in the expression

|System.Collections.Generic.Dictionary`2[Int32, String]|

we would find and use System.Int32.

We could precede this lookup by comparing the typename against the small list of bespoke type-hint symbols: int, double, long, and the rest. Thus we could handle

|System.Collections.Generic.Dictionary`2[int, long]|

This solves Problem #3 in the list above.

To implement this is the addition of just a few lines of code.

[dmiller]

Let's look at the first problem: Instead of

|System.Collections.Generic.Dictionary`2[System.Int32, System.String]|

we'd like to write

|Dictionary[int, String]|

If we implement our solution to problem #2 -- looking up symbols in the namespace mapping -- all we really need to do is find way to map from the symbol Dictionary to the generic type System.Collections.Generic.Dictionary`2.

We can almost do this already. The import directive, either as an :import clause in the ns declaration or as a directly call to the import function, will create a mapping. Just not quite the one we want. At present, one can evaluate

(import '[System.Collections.Generic |Dictionary`2|])

and |Dictionary`2| will be mapped to the generic type. But we want Dictionary to be mapped. Unfortunately, the code for import uses the typename and in CLR-land that includes the backquote-count suffix. Even worse,

(import `[System.Collections.Generic |Dictionary`2[System.Object,System.String]|])

will also (try to) map to the type using |Dictionary`2| ("try to" -- it will fail if we have already done the previous mapping).

I hesitate to change the current behavior of import. I propose two (alternative) solutions.

Solution #1: provide a new function for introducing type aliases into the current namespace.

(add-type-alias 'Dictionary  |System.Collections.Generic.Dictionary`2| )
(add-type-alias 'Dictionary  |System.Collections.Generic.Dictionary`2|  some-namespace)

BTW, this would allow a sequence such as this:

(add-type-alias 'Dictionary  |System.Collections.Generic.Dictionary`2| )
(add-type-alias 'DictObjStr' |Dictionary[Object,String]|)
(add-type-alias 'DictObjObj' |Dictionary[Object,Object]|)

Then you could do something like:

(.Add ^DictObjObj mydict "help" "me")

Note: this is quite easy to implement.

(defn add-type-alias
   ([sym type]  (add-type-alias sym type *ns*))
   ([sym type ns] (.importClass #^clojure.lang.Namespace ns sym type)))

Solution #2: provide some additional syntactic sugaring to import.

Note: if we modify import, we automatically get the goodness in the :import in ns.

(import `[System.Collections.Generic  [ |Dictionary`2| :as Dictionary ])

Rather than using the (unqualified) typename, we provide the alias by wrapping the entry in brackets and adding a :as clause.

Though this is possible, I really hesitate to make any changes to import. For example, we run the risk of breaking code analysis programs that rely on the current syntactic structure of import in ns declarations.