I, too, am very fond of the APL characters but they are a mix of the
conceptually helpful - like ⍉ (transpose) - and ad-hoc obscurities - ⍴
(rho).
The J characters have a bit of ad-hockery about them but are extremely
well-integrated with respect to each other.
Just look across any line of the vocabulary page. My favorite is
- Negate • Minus -. Not • Less -: Halve • Match
Whenever I'm comparing a couple of things to see if they are the same or
how they differ, I find myself using numerous verbs from this line, e.g. if
two numeric tables don't match, is it because of small differences? If the
contents of two text files don't match, which lines are in one but not the
other?
I think the richness of the relations between the J characters outweighs
the aesthetic advantage of the APL characters.
On Tue, Feb 25, 2014 at 1:03 PM, Don Guinn <dongu...@gmail.com> wrote:
> Searching, counting characters etc. are easier to convert UTF-8 to Unicode
> (wide), doing whatever, then converting back to UTF-8.
>
>
> On Tue, Feb 25, 2014 at 9:10 AM, Björn Helgason <gos...@gmail.com> wrote:
>
> > a. and especially i. a. - looking up chars indexes used to be useful.
> >
> > It is not as easy anymore.
> >
> > The national chars are often not in there with a single number.
> >
> > Sometimes two or three.
> >
> > Reading files also sometimes with unicode markings.
> >
> > -
> > Björn Helgason
> > gsm:6985532
> > skype:gosiminn
> > On 25.2.2014 14:03, "Don Guinn" <dongu...@gmail.com> wrote:
> >
> > > I tried that a while back. I extended the table for ;: to treat the
> bytes
> > > for _128{.a to be treated as letters which made all multi-byte UTF-8
> > > treated as alphas. Statements were broken into tokens properly. But
> then
> > I
> > > found that the interpreter used the top half of a. internally. I
> > mentioned
> > > that in the forum a while back when someone noticed that some character
> > in
> > > there acted weird. Roger said that could be changed if needed. Might be
> > > easy for Roger to change that but it didn't look so easy to me.
> > >
> > > I looked at the tables for Unicode (wide characters) and in the form of
> > > UTF-8 and couldn't see any easy to distinguish the category of a
> > character.
> > > Those that one would consider an alpha were mixed in with graphics and
> > > controls. APL characters were not grouped together but scattered all
> over
> > > the place.
> > >
> > > For trying it out and seeing what happens shouldn't be too difficult to
> > see
> > > how it would work but there are a lot of questions to answer before
> > making
> > > it a production tool.
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Feb 24, 2014 at 10:11 PM, bill lam <bbill....@gmail.com>
> wrote:
> > >
> > > > This seems simpler. The first thing to do is build a prototype
> > > > implementaton,
> > > > and then we can see what are other problems out there.
> > > >
> > > > Пн, 24 фев 2014, Don Guinn писал(а):
> > > > > A middle ground might be to allow for some Unicode (UTF-8) to be
> > > > > considered letters like a-z,A-Z. Then one could name APL iota to
> > > > something
> > > > > like i. . In addition, it would allow non-English languages not be
> > > > > restricted to ASCII characters for names. Greek letters in
> > mathematics
> > > > > could be used as names making statements look a little more like
> > > > > traditional mathematics. It would be simpler to allow all Unicode
> > > > > characters be considered letters, but that might lend to other
> > > problems.
> > > > >
> > ----------------------------------------------------------------------
> > > > > For information about J forums see
> > http://www.jsoftware.com/forums.htm
> > > >
> > > > --
> > > > regards,
> > > > ====================================================
> > > > GPG key 1024D/4434BAB3 2008-08-24
> > > > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> > > > gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
> > > >
> ----------------------------------------------------------------------
> > > > 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
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
--
Devon McCormick, CFA
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
