The present threat seems to be proving useful to Henry. I didn't mean to divert it off-topic into a discussion of syntax coloring per-se. I offered it as a case-study to inform the design of a serviceable dictionary feature for J.
On Tue, 1 Feb 2022 at 19:49, Hauke Rehr <hauke.r...@uni-jena.de> wrote: > Personally, I’m fine with the little syntax highlighting I get in vim. > Much could be improved but I don’t feel I need it. > But there doesn’t seem to be a pygments lexer for J. > I find an APL lexer, though [1] > Has anyone tried to provide one already? > > @Michal: could you talk about the way you did your > syntax highlighting? > > [1] https://pygments.org/docs/lexers/#lexers-for-apl > > > Am 01.02.22 um 20:27 schrieb Ian Clark: > > To respond to Henry (…I guess) > > > > I wrote: > >> Swift boasts a me-too *dictionary* à-la Python, but I've never found a > > use for it. > > > > I need to eat my words. I may indeed have an important use for > *Dictionary* in > > Swift. > > > > I'm just about to implement syntax coloring in j901 for iOS (and – no I > > can't use Qt / Cairo because it won't get past App Store review). How > about > > storing the different-colored J words in dictionaries, one for each > color? > > Otherwise I'll need to implement the defaulted x-argument of Words (;:) > in > > Swift using nested case-statements, stepping thru the J script > > line-by-line, then character by character. I shy away from doing this > > because Swift's implementation of colored characters (so-called > "attributed > > strings") is so head-banging I expect it to be s-l-o-w. > > > > I already have an implementation in J, but there are one or two gotchas > > which Swift handles as a matter of course. As ever, the devil is in the > > detail. Things like: what if the J user wants to preserve redundant > spaces? > > Or have strings or comments in Arabic, or embedded emojis? If you're > > writing an IDE, as distinct from a domain-specific app, you really have > to > > field whatever the user throws at you – or recover gracefully. > > > > My test-piece is stdlib.ijs (2658 lines) or maybe dissect.ijs (17068 > > lines). The editor should color the entire script in under 2 seconds. My > > solution will be based not only on which technique is fastest, but which > > requires the fewest patchups and special cases. > > > > The speed of the *Dictionary* solution will boil down to hashing, as I > > think Henry is predicting. Have the Apple gnomes done the job thoroughly > > and implemented hashing for Arabic keys, or whatever global writing > system > > Unicode supports? I'll soon find out. > > > > On Tue, 1 Feb 2022 at 17:33, 'Pascal Jasmin' via Programming < > > programm...@jsoftware.com> wrote: > > > >> unique keys is a pretty important aspect of dictionaries. > >> > >> It permits SET (or Alex's merge) functionality to determine whether it > is > >> an update or an append. Where users appreciate this > "auto-functionality". > >> Without unique keys, the user must determine if they want update vs > append, > >> and if it is update "1 record" have a means to select (somehow) which of > >> the duplicate keyed records they want to update. > >> > >> without duplicate keys, this is an associative array. ie 2 unrestricted > >> regular J arrays. > >> > >> > >> > >> > >> On Tuesday, February 1, 2022, 10:19:50 a.m. EST, Henry Rich < > >> henryhr...@gmail.com> wrote: > >> > >> > >> > >> > >> > >> This discussion is important. I'd like to continue from this post. > >> > >> To respond to Ian, who asked Who really needs this anyway? I say that I > >> got great use from C++ classes for ordered_map and unordered_map. The > >> operations can be done in J, but the speed advantage of hashing for > >> lookups is so significant as to make the difference between tolerable > >> and intolerable performance. > >> > >> I would change the definition to: > >> > >> A Dictionary is a collection of key/value pairs, where the keys and > >> values can have any type and shape. Keys are not necessarily unique. > >> Keys and values may be given as unboxed but they will be boxed > >> immediately before going into the Dictionary. > >> > >> Supported operations: > >> > >> Dic =: ~. Dic discard kvs for duplicate keys > >> Dic =: Dic , k,v add a KV > >> k { Dic read value[s] > >> Dic =: v k} Dic replace kv > >> k e. Dic How many times does key exist? > >> {."1 Dic list of all keys > >> {:"1 Dic list of all values > >> > >> ?? delete key > >> > >> Rob: what needs to be added to make the dictionary type as useful as it > >> is in K? > >> > >> Henry Rich > >>> To answer Henry's questions: > >>> > >>> My definition of a dictionary is: > >>> A collection where data is organized by key, where keys can be symbols, > >>> strings, or numbers (or possibly other data types) and values can be > >>> arbitrary J data. > >>> > >>> Essential dictionary operations are: > >>> - create/read/update/delete by key > >>> - query if key exists > >>> - enumerate all keys (returns an array of boxed keys) > >>> - enumerate all values (returns an array of boxed values) > >>> - merge two dictionaries e.g. (Z=: X merge Y) and if X and Y share any > >> key, > >>> then Z gets the key/value pair from Y > >>> > >>> Nice features to have, but not necessary: > >>> - keys are stored in J's sorting order > >>> - dictionaries can be serialized/deserialized for persistent disk > storage > >>> or for sending to other processes > >>> > >>> > >> > >> > >> -- > >> This email has been checked for viruses by AVG. > >> https://www.avg.com > >> > >> > >> ---------------------------------------------------------------------- > >> 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 > > -- > ---------------------- > mail written using NEO > neo-layout.org > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
