Tracy, I completely agree: strings as sequences of characters are an intuitive and highly manipulable data structure. One reason strings stand out in C, Haskell, and Lisp is that they are easy to map over because their interface (and often their underlying implementation) is an iterable collection. In contrast, Erlang treats strings as if they weren't made of letters at all but solid hunks of unsearchable data, and it needlessly makes programming that much harder.
Don, which information is more often relevant: that two strings are lt/gt/eq, or which characters differ and which are the same? Side note: Could we give longer formal names for each short function (e.g., numberToString =: > 'd' (8!:0))? It's incredibly hard to Google documentation for functions succinctly named. Cheers, Andrew Pennebaker www.yellosoft.us On Mon, Oct 31, 2011 at 12:23 AM, Tracy Harms <[email protected]> wrote: > Although Roger has already replied with strong example code that show how > this task is readily accomplished, and comments that explain why the > primary verbs have domains defined as they do, I'd like to add a bit more. > > The term "string" is common among programmers because it is a technical > term with particular meanings in many languages. There are, however, no > strings in J. We often can work with it in a casual way, but at some point > expectations about strings are things that come from other > languages--indeed, other language paradigms--and those expectations are > likely to clash with the way text is handled in J. This also explains why > "string" is missing as a term in J documentation. It not only is not a > J-specific term, as a word it can invite confusion. > > More and more, when I want the likes of "strings" in J it is symbols that > do the trick. Not always, but often enough for me to suggest that it may be > premature to evaluate how well J facilitates working with text if skill > with symbols has not been developed. > > Finally, I have found that J has brought me to think of literals in the > same way I think of numbers. There are, of course, many verbs for which > literals fall outside the domain, but thinking of text as lists of > characters allows me to approach text-manipulation problems in the same way > I approach number-manipulation problems. This kind of consistency is has > been highly valued in the development of array languages. It does mean that > it is not so easy to do various things with text that, say, > text-specialized languages make very easy to do. But it also means that > what is easy to do with text is just as easy to do with every other atomic > type. > > I'd enjoy seeing more material about working with text in J, at every skill > level. Eventually I may be able to contribute some, myself. Perhaps this > thread can initiate a conversation about which sorts of expanded > documentation would be most beneficial? > > --Tracy Harms > > > On Sun, Oct 30, 2011 at 10:35 PM, Alan Stebbens <[email protected]> wrote: > > > I get sad when I see both expert and new J programmers working hard to do > > simple string comparisons. J makes working with strings harder than it > > should to be. > > ... > > J can manage most (any?) programming tasks but common things like > > comparing strings ought to be easy. > > ... > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
