I would prefer to leave the funding and resource issues for another time. But I would keep in mind that there's a lot of student out there, looking for opportunities to learn. I would expect code generated by students to be well below professional standards, but mixed in with the clutter would be some really incredible work. So my ideal of a development process would engage the academic community, to help research and understand the issues and would back that up with some professional support. DARPA might have some interest here, also, if you are looking for seed money - but even more important would be finding interested academics.
The type promotion/demotion issues are a much more interesting issue, from my point of view. My take here is that each of the primitive types (integer, float, ..) would be a potential type of the type system, and also that some "tagged union types" (number, character, ...) would also be potential types of the type system. (But a first version might support only one type or only a limited subset of types.) This leaves us with another problem: how do we indicate which type(s) to be used in the compiled code. One possibility uses a cookbook set of assert. statements. If an assert statement forces an error for all but one type, we can decide that all code after that point involving that variable are constrained to that type. Similarly, a complete lack of asserts might be taken as meaning that that data element is the generic array type we know and love as a J noun. We would have to come up with terminology to distinguish this case from the more constrained case. Another issue, of course, is declaring the rules for result types from supported verbs. You'd need a whole set of rules that would need to be supported by the code. Or, you would need to write the code and then extract the rules. Or maybe build a big chart of all the cases and then attempt to refine that down to a concise set of memorable quips. I'd also be targeting RTL (http://gcc.gnu.org/onlinedocs/gccint/RTL.html) rather than C. As for bigints, I'm not sure if the best approach would be to incorporate GMP (https://gmplib.org/) or if it's better to implement support directly. Any decision is going to have a cost, and - especially in the early stages of development - we'd have to understand that we may eventually want to jettison both the costs and the benefits of some of this exploration. It seems to me that the hard part involves engaging interest of other people. My above sketch assumes that academics and students would have some interest in the language and its possibilities. And to get there, I think we need to do a better job of demonstrating the capabilities of the language and, at the same time, I think we also need to do a better job of demonstrating how well J can work with other languages. And I think both of those are well within reach. Of course, this kind of thing will also tend to kick up a fair bit of noise and odd problems, so we will need to tolerate some of that also. Thanks, -- Raul On Wed, Feb 5, 2014 at 10:57 AM, Robert Bernecky <[email protected]> wrote: > The APEX APL to SAC/SISAL/D compiler, as a proof of concept, > should convince you that creating a J subset compiler that obtains > excellent serial and parallel performance is definitely feasible. > > There are some hard decisions to be made, though, e.g.: > > - automatic type promotion(e.g., Boolean -> integer -> double) > is a non-starter in most compiled languages that care about > performance. > > - automatic type demotion, too: floor(double), for example, either > must always produce a double or always produce an int. > You can't do the dance of "Well, this one is too big for an int, > so we'll make the result a double." > > - Execute and its buddies are also out the door, of course. > > - How do you propose to implement data types that are > not native to C? [E.g., bigints] The SAC approach here, which > I think works very well, is via modules and libraries, in > which the new data type support is written in SAC. > > - Who is going to fund the work? I think the place to start > is with those people who will benefit materially from > having high-performance J-based applications. > > Bob > > On 14-02-04 02:48 PM, Raul Miller wrote: > ... >> >> Mostly what I want for J is a compiler for a limited subset of the >> language. This would let us address a variety of performance issues, >> and would also introduce some new problems. Problems, though, that we >> should welcome. >> >> Hypothetically speaking, J (or subsets) could be a language for use on >> GPU clusters, on large distributed clusters, and for a variety of >> other contexts. There's no technical reason we couldn't have process >> management vocabularies in the language. But if we go there we'd need >> to support the resulting user community, and that needs someone to >> pilot it and support it. Lots of people, potentially. It's not just >> about the job possibilities - we'd need textbooks for teaching people >> and drawing connections to interesting topics, we'd need to support >> the academics who found some relevance in our approaches and we'd have >> to do that while managing to trim back some of the suggestions. >> >> It seems to me that we could have a J subset targeted at just the >> features needed to implement LAPACK and wired into gcc for code >> generation. >> >> >> Thanks, >> > > > -- > Robert Bernecky > Snake Island Research Inc > 18 Fifth Street > Ward's Island > Toronto, Ontario M5J 2B9 > > [email protected] > tel: +1 416 203 0854 > > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
