Why do you not like ": and what does >@(8!:0~&'d') offer that's better
than (":"0)?Thanks, -- Raul On Mon, Oct 31, 2011 at 12:52 AM, Andrew Pennebaker <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
