no support for definitions in AO/ABC?

33 views
Skip to first unread message

Robert Majewski

unread,
Dec 2, 2013, 8:35:57 AM12/2/13
to reactiv...@googlegroups.com
Hi,

I' ve question about lacking of definitions in AO language. I appreciate ability to view stream of AO words grouped according to "local user dictionary" and other usefull properties mentioned in AboutAO/AboutABC documents. Different users could have different dictionaries and the same "program" will have personalized look.
(well, in  AO/ABC documents not local, but "shared global, wiki style" dictionary is mentioned, but I think my doubts remain valid)

What about editing a word definition? Does it mean that we are editing all occurences of the word (or rather its representation as substream) in all libraries? Or maybe we don't change the stream at all, only grouping of visible words will be affected and we have to edit each occurence by hand? Or maybe I don't understand lacking of definitions at all :-) ?

Br,
Robert

David Barbour

unread,
Dec 2, 2013, 10:23:45 AM12/2/13
to reactiv...@googlegroups.com
Hi, Robert. I'm not sure I understand your question, since AO does have definitions. I'll make a few stabs at answering, though. Please let me know whether any points hit.

Definitions in AO are at a flat, global, dictionary level. AO has no separate notion of "libraries". There is just one, global dictionary. Though, of course, we could model libraries as something akin to patches on a dictionary. If we edit a word's definition in the dictionary, we are changing the meaning of all words in the dictionary whose definitions use that word. The generated code associated with a word will be different. This kind of maintenance is half the point of using words with definitions instead of, for example, naming ABC subprograms by secure hash.

If we use an AO dictionary to parse an ABC stream - i.e. treating dictionary as a grammar - then changing a definition would only change the view, not the original stream. Presumably, we would need to re-parse the stream under the updated grammar. If we 'capture' an ABC stream as a new word, then we could refactor and edit the new word or its constituents, but after editing it wouldn't be the same stream anymore. We could compile the updated stream back to ABC and share it again.

What AO does not have is a built-in syntax for defining words. Different programming environments may offer different mechanisms for managing the relationship between each word and its definition. I just yesterday designed a dictionary file format to help bootstrap (implementation starts today!), which looks like:

        imports before first definition
        @word1 definition1 using word2 word3
        @word2 definition2
        definitions can use multiple lines
        @word3 definition3

In this design, dictionary files are understood as concatenative 'patches' on a tacit dictionary. The last definition of a given word retroactively replaces earlier definitions. Imports can name a series of such patches. At the top level, the dictionary starts empty, but patches don't need to assume an empty dictionary. This file format perhaps places AO closer to traditional languages, albeit with a non-conventional namespace model. 

The `.ao` format is intended as a bootstrap layer for bigger things, such as building a compiler for AO and ABC within AO, or a wiki-based programming environment with rich automatic visualization of typeful structure (trees, zippers, stacks, etc.). However, historically, such layers tend to stick around forever and be used beyond their original purpose. I designed the `.ao` format to follow AO's design philosophies: flat global namespace, tacit concatenative structure, potential streaming of definition updates for live programming.

ABC also has a way to name code for caching, compression, structure sharing, and separate compilation:

        {#secureHashOfABCSequence}

Here, the 'name' is a secure hash of the content. By nature a secure hash will prevent cyclic definitions, separate the update/versioning concern, ensure names are location independent, and even act as a securable capability - all great properties. The only weakness is that these 'names' are large and illegible to humans (but pet names could help). It is possible to 'parse' a large ABC stream relative to a known library of software components. Unlike AO, we cannot edit the definition for an ABC subprogram named by secure hash. But we can transform ABC streams by global pattern search and replace.

Please let me know whether my answer helped, confused you further, or whatever. 

Best,

Dave



--
You received this message because you are subscribed to the Google Groups "reactive-demand" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reactive-dema...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Robert Majewski

unread,
Dec 2, 2013, 12:27:26 PM12/2/13
to reactiv...@googlegroups.com
hi,
thanks a lot for clarificafions. I've wrongly attributed self-contaiment of ABC to AO. I think that part of the reason for it is a lack of bigger examples of ABC or AO code yet.
I wish you will have no problems with implementation and soon we could see all your exciting ideas working for all programmers good!
br,
robert
Reply all
Reply to author
Forward
0 new messages