Congratulations on implementing []cse as a means of accessing C# directly.

However:

- Getting []cse is NOT intuitive. I had downloaded this as soon as it appeared. At that time, it prompted me for a password (which was not supplied). I downloaded it again today & installed it by trial and error. Hence my comment: 'NOT' intuitive.- I am informed that I have 23 days to complete the evaluation. I think this time span is just too short to put []cse through its paces.- I think []cse implements a COM Object. I like COM but in the context of C# scripting, I think it introduces undesirable features: see below.

Example 1: COM Coercion - in C#, dt is an object but []cse returns a scalar value (n time units from a reference point, I believe)

The issue with an interface between C# and APL+Win is that APL+Win only has Int32, double, and string data types, whereas C# has many more data types, including custom types which can be programmer created. There is no intention with the availability of the CSE to add all these C# data types to APL+Win. If one needs that there is VisualAPL.

In APL+Win the CSE 'GetValue' method will return a value when querying the value of a C# DateTime variable because the Microsoft Com interface makes that translation, but it is not what I would suggest doing. Instead if via the CSE 'Exec' method one defines 'DateTime dt = DateTime.Now;' for example, then use []CSE 'GetValue' 'dt.Year' or []cse 'GetVaue' 'dt.millisecond' for example. The programmer using the CSE needs to be aware of the limitations of APL+Win and understand the underlying object model of 'complex' C# data types which in the end reduce to the C# value types, some of which have analogous APL+Win data types.

Ajay noted: COM Transposition - in C# array is of shape 2 3 but []cse turns it into an array of shape 3 2

This transposition is the result of differences in the row and column orientation between APL+Win and most other programming languages. Basically APL+Win is not going to change C# and C# is not going to change APL+Win, so the programmer venturing into both spheres of influence has to be aware of these differences. In a recent version of APL+Win the 'deep transpose' system function (⎕dtr) was implemented to help with this particular difference. See the attached pdf-format document for an example.

Check out the CSE 'transpose' property which the APL+Win programmer can set their preference for implicit (automatic) or explicit (non-automatic) deep transpose of APL+Win arrays passed across the APL+Win and CSE interface.