> From: Robert Bernecky <[EMAIL PROTECTED]> > > As for the installed user base problem, the SAC approach appeals to me: > Implement a minimal core language, then define every other > language (e.g., structural verbs - transpose, > rotate, reverse, reshape...) in terms of that core, placing those > definitions in a standard library or include library. > > This approach offers several advantages to the all concerned: > > - non-conforming changes, such as the iota change above, can > be implemented by adding a NEW member to a library, or by > releasing a new library with a different name. > The installed user base can convert apps to the new semantics > at their leisure, or not at all, as they wish. > > - strong optimizations give the library code and user-defined code > the same power. > > - if you don't like the distributed version of, say, iota, you > can just change the definition of it in your library. At your > own peril, of course, if you use other people's code and want it to > work. > > - SAC also lets a user define new types, at no cost in run-time > efficiency, so you are not chained > to the design decisions of the language implementer.
SAC looks intriguing; but, for some of us, License Agreement ... Any use of this software with a commercial purpose or in a commercial environment is not granted by this license and requires explicit permission. makes it academic. > > Bob ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
