…Freudian slip there. For 'threat' read 'thread'. On Tue, 1 Feb 2022 at 20:35, Ian Clark <earthspo...@gmail.com> wrote:
> 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
