Brad ,
I very much appreciate your well intentioned feedback .

After I get accounting in order the rest of this month , upgrading the documentation will be a priority .

CoSy has been brought this far as a solo effort ( upon the Reva Forth base ) despite some rather significant difficulties and with revenue which rounds to $0  .  It has been , first of all a matter of bushwhacking a path from open-to-the-chip ( x86 ) Forth to the dynamic lists of APL/K .

The CoSy.f you reference is the main CoSy script , and what order you see comes from order of definition as needed structures or vocabulary are defined . For instance  ` operators , aka adverbs , verbs which take ` ticked ( addresses of ) verbs , are defined pretty much together , eg: all the ` each adverbs : 'm 'd 'L 'R `( monadic dyadic Left Right )`  .  As are more everyday level definitions in furniture.f .  You will see a number of families of words ,  in APLs relegated to separate libraries like the venerable Finnish idiom list . I contend far more meaningful names can be created with Chuck Moore's brilliant simplicity of whitespace being the prime delimiter than trying to stuff everything useful into a rich but limited number of symbols . ( I like symbols otherwise I never would have gotten into APL ; I look forward to the openness of Unicode . ) K and J are a step backwards trying to make do with ASCII , but without the clarity of the whitespace rule .

For instance , the vocabulary which returns portions of lists before or after , either including or excluding the delimiter :

| 20190203 | \/ | vocabulary found useful over the years | \/ |
: prt<f ( str tok -- PaRT_Before_First ) 2p> ss1st L@ swap take 2P> ;
: prt<=f ( str tok -- PaRT_Before_Firstincluding )
   2p> ss1st R@ rho +i L@ swap take 2P> ;
: prt>=l 2p> ['] reverse on2 prt<=f reverse  2P> ; 
: prt>l 2p> ['] reverse on2 prt<f reverse  2P> ;

: prt>f  2p> ss1st R@ rho +i L@ swap cut 2P> ;
: prt>=f 2p> ss1st L@ swap cut 2P> ;
: prt<=l 2p> ['] reverse on2 prt>=f reverse  2P> ; 
: prt<l 2p> ['] reverse on2 prt>f reverse  2P> ;

 I think they are rather self-explanatory and such names are only possible in Forth . The alternative  would be names like part_before_including_first . If you want to make a set of such aliases be my guest .

There is no question programming in CoSy , even for me , is often finding the word which does some task rather than reinvent the process . 

Early on , when definitely still in K.CoSy , I made a table of all the Reva .Forth words , linked in the F1 help .  And definitely a cheat sheet is needed . I went to Antwerp to get one for K😉: https://cosy.com/language/index.html#K , https://cosy.com/views/APL94.txt :

        At his workshop, Arthur handed out a 2-sided, 8-panel, K
Language Summary card, which displays a remarkable breadth and depth of
understanding of the fundamental invariants of programming.

I'd contend that math notation in general just started out as " personal shorthand " , eg: Dirac bra and ket ( which I dislike ) . Donald McIntyre  in particular used to give talks at APL conferences on such things as the history of ` + .
I'm not against having more verbose aliases for anything found to be cryptic .  But having a set of related words like

 ` memb Words
(
 ~membv
 ~memb
 membv
 memb
 )

for membership , either returning booleans or values or their complements would get too prolix for me .
Ironically , if I could think of good mnemonic symbolic ` abbreviations for ` reverse and ` take I would have .

A couple of other words you mention , like VM  ( vector to matrix ) , are more historical idiosyncrasies .

Transliteration tables are trivial at the array level .

But while I think the fundamental notions underlying languages are best products of single heads , it then takes a community to winnow a most mutually understandable vocabulary .

I don't know that I would call APLs or K " domain specific " . One of the brilliances was to extend array structures to characters , and nests of arrays themselves . The idea of simplifying to lists-of-lists goes back at least to Backus . Their limitation is closing off " lower level " sequential item-by-item processing .  That's where CoSy  being simply a vocabulary in open Forth is in a class by itself .

What it needs now is more heads -- and the accounting structures to manage their contributions -- and calculate the vig for the governments  .

Current CoSy is only the trail bushwhacked from coast to coast . There's lots to be done before it's a smooth autobahn -- simply a facility available on the cloud or mated to particular hardware .

Thank you for your very useful and needed feedback .

Bob A

| --

Hi Bob,

Do you have or have you considered a cheat sheet for CoSy?

Something like this APL one.

When I've tried to decode your CoSy one liners, I find I end up having to traverse the whole dependency tree for each word.

(Usually throughout this file).

I think a frequent point of confusion, for me at least, is which words are meant to be at that APL level of abstraction and which are implementation details / type specific. I wonder if calling out the core operators might help with that?

As I think I told you once before, APL at least casually is easier for me to glean meaning from as the separate character set has a high percentage of operators that are trivially mnemonic. CoSy + K using multi-character operators makes it really hard to guess at the majority of operators. Having tooltips can help, but misses on the chance to have names stand on their own so to speak.

There may be some shared conventions in the names, but I've struggled to recognize them. Names like "reverse", "take", and "partition" are just so much easier to grasp than "membv", ">t1>", and "blVM" for someone that doesn't have the operator set burned in their head.

A point I managed to convey poorly in the meeting is I think while you're trying to aim for the pithy crisp set of operators in APL, you're ending up instead falling into what feels like a personal shorthand.

Historically I think a number of wise Forth-y folks have encouraged using real whole words over abbreviations for this reason (which is a danger with Forth code in general). This is why Forth standards are filled with fully spelled out words, even when they are long by the standards of other languages (e.g. VARIABLE, CONSTANT, IMMEDIATE, INVERT, VOCABULARY).

I think finding a clear + composible domain specific language for arrays in Forth is important for a lot of problems.

Please take my feedback as well intentioned.

I want to understand + follow along with how you're applying CoSy, but it's often a challenge and maybe something a small tweak in style could help with.

Cheers

-BradN

On Mon, Aug 28, 2023 at 8:04 PM Bob Armstrong <bob@cosy.com> wrote:

I've upload an answer to well taken questions , particularly by Don Golding on learning a ` strange vocabulary like CoSy .

https://www.cosy.com/CoSy/y23/SV-FIG_20230826_commentary.html

Also , it happens , I got a link to
 On why a vector database is essential to scale generative AI apps. Q&A with James Corcoran, Chief Growth Officer, KX

CoSy , as I've often mentioned , evolves from Arthur Whitney's K and thus has essentially the same data structures and much vocabulary .

The ability to " pick up " where I left off on the precursors of much of AI " in the `70s in notation succinct enough to fit my brain is a major motivation underlying CoSy .

And with the open mapping to hardware only Forth provides , CoSy is in a unique position to rapidly develop such algorithims .

Bob A

Peace thru Freedom
Honesty enforced thru Transparency ,

-- 28124 State Highway 67 Woodland Park CO 80863-9711

_______________________________________________
http://zork.net/mailman/listinfo/svfig
neither public nor private,
this membership of correspondence

_________________________________________

_______________________________________________
http://zork.net/mailman/listinfo/svfig
neither public nor private,
this membership of correspondence