Paul -- that was one of my first feelings watching this thread. Thanks to my mundane experience of training materials involving both APL and J, I was drawn into the problem of productively typing J code with APL comments. This drove me to produce these tools:
An APL to J Phrasebook http://www.jsoftware.com/jwiki/APL2JPhraseBook An APL palette for on-screen "typing" of APL chars http://www.jsoftware.com/jwiki/IanClark/AplPalette There's also work-in-progress on a script to convert APL )OUT -output into rough-and-ready J code to help me port a host of my ancient APL+Win wss into J. This tool takes a line of an APL fn, eg: c←a⌹b and converts it to: c=. a %. b NB. c←a⌹b No, it won't ever handle everything, but even now it gives me a flying start, flagging where it fails. It depends for its usefulness on the fact that most (of my practical) APL wss are corny, with only a line here and there doing anything smart. If anyone else has a consuming need for such a tool, tell me, and I'll up its priority to tart it up and release it. On Tue, Apr 9, 2013 at 1:15 AM, Paul Jackson <[email protected]> wrote: > There are several modern APL products which support unicode input and > output. While several approachs to input have been developed, most > operating systems support display and printing of APL characters in a > couple of fonts which are widely available. They are > Apl385.ttf and SImPL medium APL.ttf > > Paul > On Apr 8, 2013 11:10 AM, "John Baker" <[email protected]> wrote: > > > General symbols will slowly creep back into dozens of programming > languages > > in the coming years. We are already seeing this in Mathematica and > Unicode > > based APL's. > > > > Unicode is a sprawling beast but it has clearly addressed the symbol > > encoding issue. What it has not addressed is the usable font issue. While > > you can find all the traditional mathematical symbols, APL and much more > in > > Unicode you will find little help displaying and printing them without > > designing and implementing your own fonts. The hard stuff is always left > as > > an exercise for the user. > > > > Despite this problem stick to Unicode code points for your symbols and > > don't limit yourself to the characters found in established fonts. I'd > also > > ignore keyboard issues. Keyboards are already virtual on phones and > tablets > > and before long QWERTYUIOP keyboards will join card punches in the ever > > expanding warehouse of obsolete computer memorabilia. > > > > > > On Mon, Apr 8, 2013 at 12:21 AM, Greg Borota <[email protected]> wrote: > > > > > As a proof of concept for what we were talking about, I could have > > saltire > > > and obelus included in my VS based J interactive (term) window. For > > these I > > > don't need much specialized fonts and such, I think. Also we can have > the > > > dot bigger indeed, such a great but simple idea. These can be some > > simpler > > > changes on which further ones could be built incrementally later on, if > > so > > > decided. I can't wait to have this stuff working. > > > > > > Thank you so much for giving this background. It's always better to > learn > > > from the experience of the wise and not repeat previous mistakes. > > > > > > > > > On Sun, Apr 7, 2013 at 10:17 PM, neville holmes <[email protected] > > > >wrote: > > > > > > > I have been following the Symbols thread with somewhat > > > > mixed feelings. > > > > > > > > My first acquaintance with APL was in the mid '60s > > > > when the original box notation was used with spectacular > > > > success to formally describe the System/360 (see the IBM > > > > Systems Journal, Vol.3, No.3, 1964). > > > > > > > > My first use of APL was with the IBM 2741 terminal run > > > > from a 360/67 in the early '70s. The golf-ball print > > > > head on the 2741 made use of the APL symbols easy, but > > > > when the 2260 screen terminal came in, the IBM developers > > > > at Kingston needed a great amount of pressure before they > > > > would support APL. > > > > > > > > When I retired from IBM and went to Tasmania to teach, > > > > I reluctantly switched to J only because I couldn't get > > > > the APL interpreter to work on the PCs available to me. > > > > However I soon realised that J was easier to get over > > > > to students, partly because of the ASCII character set > > > > usage, partly because of using scripts instead of > > > > workspaces, partly because of the possibilities of > > > > tacit encoding. > > > > > > > > This background perhaps explains why the elaborate > > > > changes being discussed seem to me to be unwise if there > > > > is any serious hope of (a) keeping existing users all > > > > happy, and (b) making it easier to bring in new users. > > > > Also, my 30 years experience as a systems engineer > > > > taught me that success comes with improvements that > > > > are incrementally and compatibly introduced. This > > > > is a general observation that politicians and bureaucrats > > > > choose to ignore. > > > > > > > > All that said, one improvement I would very much like to > > > > see in J is the introduction of the saltire and obelus > > > > (how do I get these symbols into plain text here?) as > > > > alternatives to the * and % symbols. That J was forced > > > > into using * and % instead of the traditional symbols is > > > > a condemnation of the people who left them out of ASCII. > > > > Disgraceful !!! > > > > > > > > Note that compatibility would be preserved by retaining > > > > the * and % symbols, but perhaps automatically replacing > > > > them in displayed J expressions. > > > > > > > > This small modification would make it much easier to get > > > > schoolchildren and other ordinary potential users into > > > > using J for everyday calculations. > > > > > > > > Oh, and someone complained that using the . and : to > > > > expand the primitive symbol set was bad because they > > > > are too small to see easily. Alright then, why not > > > > simply display them as larger dots when used in primitive > > > > function symbols? Mind you, the same problem arises > > > > with the use of . as a decimal point. > > > > > > > > > > > > Neville Holmes > > > > > > > > > ---------------------------------------------------------------------- > > > > For information about J forums see > http://www.jsoftware.com/forums.htm > > > > > > > ---------------------------------------------------------------------- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > > > > > > > -- > > John D. Baker > > [email protected] > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
