User:Dan Bron/Temp/PrimitivePrimitives
goal
If one of the primitives in the Vocabulary were missing, how would you reproduce its functionality? The goal is to get the definition of every primitive using other primitives.
motivation
Besides being a fun puzzle, the primary motivation is pedagogical. These definitions can be used to generate sets of 'primitive primitives': J words that can be used to describe all the rest of J, providing an easy path to learning J.
Another nice side effect will be that some phrases/idioms/compound-code-sequences which are often repeated will become obvious (for example i.@:#). These pieces of code could be treated as primitives in their own right, leading to even more ways of expressing J within J. And, as a bonus, these idioms might be optimized in the interpreter, or even assigned to true primitives (as I. =. # i.@:# was).
rules
1.#0 We'd like an __exact__ replacement for each primitive. Specifically, the replacement should produce identical results under nominal conditions (even in internal type) to the original, and produce the same errors under exceptional conditions.
1. However, subfunctional replacements are acceptable, as they can be combined to produce a fully functional replacement.
1. Tacit code is preferred, but the removal of the Trains Table from Appendix F of the DoJ in version 5 has made this harder. I doubt many operators (adverbs/conjunctions) will be expressible tacitly.
1. Try not to use replacements for primitives within the replacements themselves. For example, in the replacement of ~., use only #~ ~:, not #~ (i.@:# = i.~), (substituting for ~:), #~ (i.@:# = ((#@:[ (>:@:[ | <:@:-) (i.~ |.)~ ))~) (substituting for i.), etc. We'll have code that will automatically explore those relationships.
1. Try to be as simple and clear as possible. Try to minimize the number of unique primitives in each re-implementation.
1. New re-implementations should be meaningfully different from previous sumbmissions. Try always to take a different tack.
1. At a later point, we're going to have to think about inverses, identity functions, adverses, tolerance, and derivatives, too. Basically any other characteristic of the primtive built in to the interpreter (accesible via b., D., or !. ?).
1. If you see a phrase that is oft repeated, feel free to give it a name, and substitute the name for the code in the defitions. Be sure to document the definition of the name somewhere! An example might be count =. i.@:# and substituting #~ count = i.~ for #~ i.@:# = i.~ in the redefinition of ~..
conventions
Each primitive has its own subpage or collection of subpages. The primary subpage takes its name from the corresponding page name in the the Vocabulary. For example, the primitive {. is described at the page named d521 in the Vocabulary, and so its subpage is also called d521 here.
These primary subpages have a specific format and layout which take cues from the format and layout of Vocabulary pages. Each primary subpage provides a link to the corresponding canonical Vocabulary page, for the convenience of prospective re-implementors. Each primary subpage also provides a discussion section.
However, what the primary subpages do NOT provide is the actual J code that re-implements the primitive. Those go on secondary subpages, which are transincluded in a table at the top of the primary subpage, using the Wiki's Include() macro.
Each semantically different invocation of the primitive gets its own sub-page, and all sub-pages are transcluded in the table. A semantically different invocation is a way of calling (invoking) the primitive such that the call means something different. For example, all primitive verbs have two semantically different invocations: monadic and dyadic. Therefore each primitive verb will be represented by three different subpages: the re-implementation of the monad (if any), the re-implementation of the dyad (if any), and the primary subpage which collects, transcludes, and displays the other two. Other classes of primitives may have more or fewer subpages. For example, " has several semantically different invocations, whereas a: has only one.
The secondary subpages are named according to the informal names listed in the corresponding Vocabulary page. For example, for the primitive {., the monad is named "Head", and the dyad "Take", and so are the corresponding secondary subpages here: Head and Take .
The secondary subpages, like the primaries, also have specific formats, but these depend on the class of the primitive. However, all will include at least one table, with 3 columns: "replacement", the J code that emulates the primitive's behavior (in that specific semantic invocation), "domain", the domain for which the replacement guaruntees that its output will be identical to the primitive's, given identical input, "J version", the versions of J for which the replacement is valid, and "SIG", the signature of the re-implementor when he added the re-implementation. A domain of "Full" guaruntees that the replacement's output will be identical to the primitive's under all conditions (inputs).
The table can, of course, have more than one valid replacement, and each replacement may only cover one particular significant subdomain.
At a later point, each secondary subpage may have a section for test data -- characteristic (and, hopefully, comprehensive) test inputs and outputs, which will give re-implementors the opportunity to be confident that their replacement is valid.
Issue: Should un-re-implemented primitives not have subpages pre-created for them? The advantage to pre-creating the pages is that they're more likely to be put in the correct format. The advantage of NOT pre-creating is that un-re-implemented primitives will be red-linked from this page, making them stand out.