Your suggestions have merit and I have been working on related problems (database 1/2/4 byte ints) vs J basic types that would benefit from extensions in the areas you suggest. However, I dont' think any changes in this area are imminent. The important change that would make a lot of these things fall into place would be for J to natively handle 1/2/4 byte ints and that is a bigger project and perhaps is a prereq.
On Mon, Mar 23, 2015 at 9:36 AM, Raul Miller <[email protected]> wrote: > I think that the contrast between > > http://www.jsoftware.com/help/user/call_procedure.htm and > http://www.jsoftware.com/help/user/memory_management.htm is worth > calling out. > > The call procedure supports these types: > > c J character (1 byte) > w J unicode (2 byte) (see u:) > s short integer (2 byte) > i integer (4 byte) > l long integer (8 byte) > x J integer (4 byte or 8 byte depending on 32/64) > f short float (4 byte) > d J float (8 byte) > j J complex (16 byte - 2 d values) (pointer only, not as result or scalar) > * pointer > n no result (result, if any, is ignored and 0 is returned) > > The memory management system instead supports these types: > > type parameter is 2 4 8 or 16 for char integer float or complex. The > default is 2. > > Now... there's a certain amount of flexibility available by treating > memory as bytes and doing all the translations in J. And, of course, > you can use the integer/floating conversions documented at > http://www.jsoftware.com/help/dictionary/dx003.htm for this. > > Still... this is a bit awkward. > > So, questions: > > (1) Would it be reasonable to define dyadic cases for the 15!:n > foreigns, where the left hand argument is a type specifying character? > > (2) Would it be reasonable to support an analogous mechanism for 3!:n > conversion foreigns? > > (3) Would it be reasonable to support sequences of characters for > reading structures? > > The purpose would be reading memory (or possibly files) written by > foreign languages. > > Obviously, no rush, and of course any example problem can easily > become open-ended. > > But it's something to think about. > > Thanks, > > -- > Raul > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
