As often the case , Brad Nelson's talk , Ruminations on Forth Text Processing , resonates with me .
CoSy's highest value is maintaining a parsable log in some sense written in itself . The current interface is defined in http://cosy.com/4thCoSy/CoSy/Tui.f and interfaces the Reva Forth to a very stale version of http://www.tecgraf.puc-rio.br/iup/ . closing that loop so I could type the line and execute
saving the text I'm writing to the R Root list then save R with my current keystrokes reliably to a flat file . And then put the whole save process on ctrl_s . That appears to have occurred by 2006 8 7 3 29 34 .
I remember Perlis from my first APL conference , Rochester NY , 1979 . The conference probably had at least 400 attendees . They were big in those days . Perlis was old and skinny and bald and in a wheel chair and clearly among the demi-gods . Guy Steele and Alan Kay were also there .
One of 3 quotes at the top of my CoSy.com/CoSy/ page is Perlis's about it being best to have a rich vocabulary on one data structure .
To me there's no alternative to just biting the bullet from the single address space ( n iota ) within which Forths build themselves to objects in their own dynamically allocated and released address spaces .
In 4th.CoSy there's just 1 fundamental type of object : reference counted lists of lists with leafs of arbitrary types , currently char , integer , float , and symbol . In fact , because of modulo indexing the topology is actually rings of rings of rings . Each object has a 4 cell header .
Given that remembering what you've done is such a focus of CoSy , text parsing and searching vocabularies are a priority focus . There's still a bunch to be fleshed out , but here's some relevant vocabulary :
s" toksplt " CShelpFor instance , to count the lines in the current text :
And to count the number of words in each :
T0 ' VMbl 'm ' rho 'm ,/Consider how many individual strings just got created and freed . But the cycles are for me to use to make things simple for me . And it must be pretty similar in any dynamic object language .
Brad's interest in counting occurrences of words immediately made me think of one of K's most sophisticated functions which I've not yet implemented and it would be great if someone else got interested in fleshing out . It's very useful in a number of accounting tasks . Here's the description from the Kref.pdf :
GroupFor example , if I execute
Q : = VMs @ ,/ text / Ravel text ( which is a list of lines ) , split on spaces , and group .on the root K.CoSy text , it ( instantly ) returns a 3870 item very ragged array of the indices of all the unique "words" . I can't think of any simple way to show this array , but the count of each of the first few items looks like this :
#:' QSo this little bit of code returns essentially a histogram of each unique word which sounds rather like what Brad was wanting .
Sorry to go off on my own tangent . But as I say , Brad's talks tend to strike major chords in my own interests .
Peace thru Freedom ,
-- 4th.CoSy Document your life in open Forth APL --
Here's a followup [ corrected ] :
-------- Forwarded Message --------
Actually K dictionaries , to use the term Dennis Shasha of NYU pushes , are 3 item lists of correlated ( symbols ; values ; attributes ) lists , essentially "associative arrays" . I initially copied Arthur's structure but found the navigating between correlated entries in the 3 lists clunky so added a meta cell to CoSy headers to hold attributes . Thus my dictionaries , like the R root dictionary I mentioned are just 2 "column" ( names ; values ) lists . I have yet to feel the need to assign them a separate type . But they are the top of the hierarchy of "types" for the most common triumvirate of functions building on Forth's ( addr ; @ ; ! ) where the address is generally just implicitly understood .
In 4th.CoSy for lists , the verbs are at and at! indexed by integer . For dictionaries , they are vx v@ and v! indexed by name .
All current APLs have generalized , non-homogenous , lists , "enclosed arrays" which allow elements to be arbitrary types including generalized lists . ( A few old APLers like Bob Bernecky insist that lists of lists languages aren't real APLs , but -- who cares . I thought it the ( nearly ) obvious path since first reading Backus's 1977 Turing lecture which probably had a lot to do with Iverson getting it two years later . ( I think everyone reading this will agree that ACM's failure so far to award the Turing to Chuck Moore reflects poorly on the ACM . ) ) Objects in 4th.CoSy are generally either homogeneous lists ( treated as leafs ) , or general lists -- essentially lists of pointers . General lists are of type 0 , ie , the first cell of the header is 0 .
Sam , some of your comments on J reflect why I eschewed it for Arthur's K . And in fact why I split from other traditional APLs such as John Scholes ( et al ) Dyalog or Jim Brown's IBM APL2 . K is conceptually simpler and its structure transparent .
I've not looked into the details of JSON , but , like XML , it seemed to be rather straight-forwardly transformable to a nested list structure . ( BTW : How do you know Steve Apter ? He's an old ( redundant ) NY K friend . )
I'm rather curious about Lua . The IUP crowd seem to be big on it .
Finally , it occurred to me that the range function mentioned in the K doc of group is worth noting . In most APLs it's a very common toolbox idiom unique .
RangeI believe Iverson called this "nub" . group evolved from several related notions .
-- 4th.CoSy Document your life in open Forth APL ----
On 2016-04-26 09:22, Samuel Falvo II wrote:
On Tue, Apr 26, 2016 at 12:39 AM, Brad Nelson <firstname.lastname@example.org> wrote:I've long harbored the suspicion that the "JSON" types are a sort of strange