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

Reply via email to