This can actually be much easier. In the editor you can toggle line number display on/off. You could have unicode identifiers on/off Decide unicode prefix like u or someting else. u followed by a number would be shown as that unicode when the toggle is on.
As an example you use in an expression: u9743=.2 +2 toggle unicode identifiers oon and that same sentence woulddisplay: <the unicode for 9743>=2 + 2 Then everyone can be happy On 8 Jul 2016 16:17, "Björn Helgason" <gos...@gmail.com> wrote: > Just thinking about this. > > The table would possibly need to have entries like the name, unicode, > unicode number, name of unicode font to use. > > Possibly best to require the name to have spaces before and after. > > Could possibly be interesting. > > Probably not very difficult to do. > > Could be more or less replace all. > > At least it would not affect J at all but give those that want/need this > something of interest. > On 8 Jul 2016 14:38, "Raul Miller" <rauldmil...@gmail.com> wrote: > >> Does this mean that you are interested in writing that display tool? >> >> If so, do you need anything documented better, to get it done? >> >> Thanks, >> >> -- >> Raul >> >> >> On Fri, Jul 8, 2016 at 2:41 AM, Björn Helgason <gos...@gmail.com> wrote: >> > I agree with you completely. >> > >> > What could be done is sort of have script with names used for J. >> > >> > Then have a rule script with those names exchanged in a toggle to >> unicode >> > set in a table. >> > >> > So in J the rule is use names. >> > >> > For display purposes one script version is with the names and another >> > script those names replaced for those who want the names displayed as >> > unicode. >> > >> > J would not have to bother with the unicode and the user can read it in >> > unicode or names as wanted/needed. >> > >> > Maybe only translate from names to unicode for display or toggle between >> > the two displays. >> > >> > Just create a separate display tool for scripts. >> > >> > The unicode script not valid in ijx only as ijs (possibly named iju or >> ijsu) >> > On 5 Jul 2016 21:50, "Eric Iverson" <eric.b.iver...@gmail.com> wrote: >> > >> >> We made the decision well more than a decade ago that unicode >> identifiers >> >> would be a mistake. That decision was unanimous within Jsoftware at >> that >> >> time. >> >> >> >> It would have been just as easy to add the support then as it is now. >> Has >> >> anything changed that would make us reconsider? >> >> >> >> I can only comment for myself. >> >> >> >> There are 3 main reasons I am against it: >> >> >> >> 1. It is a fringe area and does not warrant the effort it would take - >> very >> >> little bang for buck. >> >> >> >> 2. It is deceptively easy at first, but is a slippery slope. As is >> pretty >> >> much everything with unicode. European accented letters seem like a >> >> no-brainer. Then CJK. Then lots of others. Then lots of special guys. >> APL >> >> symbols. ETC. Glyphs that look exactly the same on paper, but that are >> >> different code points. This takes thought and (see 1) it just isn't >> >> warranted. >> >> >> >> 3. Ken left us with many fundamental ideas. One was that notation is a >> tool >> >> of thought. The correllary is that notation is a way of communication. >> If >> >> we limit J identifiers as they currently stand then algorithms can be >> >> easily and effectively be communicated around the entire world. Let in >> >> unicode identifiers and this would suffer enormously. >> >> >> >> Unicode is for data and the support there is pretty good. It serves no >> >> useful purpose in identifiers and would be a serious impediment to >> >> communication. >> >> >> >> For historical reasons the English alphabet has a privileged position >> in J >> >> identifiers. Perhaps this is wrong in some senses, but it is enormously >> >> practical when it comes to international communications. >> >> >> >> I'd be very happy to not talk about this again for another 10 years. >> >> >> >> On Mon, Jul 4, 2016 at 3:53 PM, Jose Mario Quintana < >> >> jose.mario.quint...@gmail.com> wrote: >> >> >> >> > On the one hand, Marshal asserts that Unbox allows the use of UTF-8 >> based >> >> > identifiers in a way that "is completely backwards-compatible with >> >> existing >> >> > J." which I find very appealing. >> >> > >> >> > On the other hand, you (Jsoftware) decided strongly against it >> because >> >> > "the disadvantages >> >> > strongly outweighed the advantages." >> >> > >> >> > Would you mind to elaborate on what the disadvantages are? >> >> > >> >> > >> >> > On Sun, Jun 12, 2016 at 4:38 PM, Eric Iverson < >> eric.b.iver...@gmail.com> >> >> > wrote: >> >> > >> >> > > We (Jsoftware) talked about unicode identifiers quite a bit years >> ago >> >> > when >> >> > > we added uft8 and utf16 support to J. We finally decided we were >> >> strongly >> >> > > against it. The disadvantages strongly outweighed the advantages. I >> >> don't >> >> > > think anything has changed in the interim. >> >> > > >> >> > > I doubt unicode names will be in official Jsoftware releases for a >> long >> >> > > time, if ever. >> >> > > >> >> > > On Sun, Jun 12, 2016 at 4:30 PM, Marshall Lochbaum < >> >> mwlochb...@gmail.com >> >> > > >> >> > > wrote: >> >> > > >> >> > > > Unbox has code to allow unicode identifiers in J, with the >> following >> >> > > > rules: >> >> > > > >> >> > > > - All code must be UTF-8. Invalid UTF-8 causes a spelling error. >> >> > > > - Any non-ASCII character is treated as alphabetic. Identifiers >> can >> >> use >> >> > > > these characters freely. >> >> > > > >> >> > > > This is completely backwards-compatible with existing J, and >> allows >> >> us >> >> > > > to use things like greek characters and code in other languages: >> >> > > > >> >> > > > π >> >> > > > |value error: π >> >> > > > π =: 1p1 >> >> > > > π >> >> > > > 3.14159 >> >> > > > π_1 >> >> > > > |value error: π_1 >> >> > > > >> >> > > > What do people think about this? Should it be added to jsource? >> >> Should >> >> > > > the rules be changed for some characters? >> >> > > > >> >> > > > Marshall >> >> > > > >> >> ---------------------------------------------------------------------- >> >> > > > 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 >> > ---------------------------------------------------------------------- >> > 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
