Accept two quoted programs, run the first and expect a Boolean
+value, if it's true pop it and run the second program
+(which should also return a Boolean value) otherwise pop the second
+program (leaving false on the stack.)
Accept two quoted programs, run the first and expect a Boolean
+value, if it’s false pop it and run the second program
+(which should also return a Boolean value) otherwise pop the second
+program (leaving true on the stack.)
+
[A] [B] ||
+---------------- A -> false
+ B
+
+
+ [A] [B] ||
+---------------- A -> true
+ true
+
Given a quoted program on TOS and anything as the second stack
+item run the program without disturbing the stack and replace the
+two args with the first result of the program.
+
... x [Q] app1
+---------------------------------
+ ... [x ...] [Q] infra first
+
Unlike app1, which is essentially an alias
+for unary, this function is not the same as
+binary. Instead of running one program using
+exactly two items from the stack and pushing one result (as
+binary does) this function takes two items
+from the stack and runs the program twice, separately for each of
+the items, then puts both results onto the stack.
+
This is not currently implemented as parallel processes but it
+can (and should) be done.
... xN ... x2 x1 x0 [Q] n . appN
+--------------------------------------
+ ... [xN ...] [Q] . infra first
+ ...
+ [x2 ...] [Q] infra first
+ [x1 ...] [Q] infra first
+ [x0 ...] [Q] infra first
+
+
Definition
+
+
[[grabN]] [codi] [map] [disenstacken]
+
+
Discussion
+
This function takes a quoted function Q and an
+integer and runs the function that many times on that many stack
+items. See also [app2].
Compute the average of a list of numbers. (Currently broken
+until I can figure out what to do about "numeric tower" in
+Thun.)
+
Definition
+
+
[[sum]] [[size]] [cleave] [/]
+
+
Discussion
+
Theoretically this function would compute the sum and the size
+in two separate threads, then divide. This works but a compiled
+version would probably do better to sum and count the list once, in
+one thread, eh?
+
As an exercise in Functional Programming in Joy it would be fun
+to convert this into a catamorphism. See the Recursion
+Combinators notebook.
+
+
b
+
Combinator
+
Run two quoted programs
+
[P] [Q] b
+---------------
+ P Q
+
+
Definition
+
+
[[i]] [dip] [i]
+
+
Discussion
+
This combinator may seem trivial but it comes in handy.
Convert the item on the top of the stack to a Boolean value.
+
Discussion
+
For integers 0 is false and any other number is
+true; for lists the empty list is false
+and all other lists are true.
+
Crosslinks
+
[not]
+
+
branch
+
Basis Combinator
+
Use a Boolean value to select and run one of two quoted
+programs.
+
false [F] [T] branch
+--------------------------
+ F
+
+ true [F] [T] branch
+-------------------------
+ T
+
+
Definition
+
+
[rolldown] [choice] [i]
+
+
Discussion
+
This is one of the fundamental operations (although it can be
+defined in terms of [choice] as above). The more common
+"if..then..else" construct [ifte] adds a predicate function that is
+evaluated [nullary].
+
Crosslinks
+
[choice] [ifte] [select]
+
+
ccccons
+
Function
+
a b c d [...] ccccons
+---------------------------
+ [a b c d ...]
+
+
Do [cons] four times.
+
Definition
+
+
[ccons] [ccons]
+
+
Crosslinks
+
[ccons] [cons] [times]
+
+
ccons
+
Function
+
a b [...] ccons
+---------------------
+ [a b ...]
+
+
Do [cons] two times.
+
Definition
+
+
[cons] [cons]
+
+
Crosslinks
+
[cons] [ccons]
+
+
choice
+
Basis Function
+
Use a Boolean value to select one of two items.
+
a b false choice
+----------------------
+ a
+
+ a b true choice
+---------------------
+ b
+
+
Definition
+
+
[[pop]] [[popd]] [branch]
+
+
Discussion
+
It's a matter of taste whether you implement this in terms of
+[branch] or the other way around.
+
Crosslinks
+
[branch] [select]
+
+
clear
+
Basis Function
+
Clear everything from the stack.
+
Definition
+
+
[stack] [bool] [[pop] [stack] [bool]] [loop]
+
+
Crosslinks
+
[stack] [swaack]
+
+
cleave
+
Combinator
+
Run two programs in parallel, consuming one additional item, and
+put their results on the stack.
+
... x [A] [B] cleave
+------------------------
+ ... a b
+
Take two values and three quoted programs on the stack and run
+one of the three depending on the results of comparing the two
+values.
+
a b [G] [E] [L] cmp
+------------------------- a > b
+ G
+
+ a b [G] [E] [L] cmp
+------------------------- a = b
+ E
+
+ a b [G] [E] [L] cmp
+------------------------- a < b
+ L
+
+
Discussion
+
This is useful sometimes, and you can [dup] or [dupd] with two
+quoted programs to handle the cases when you just want to deal with
+[<=] or [>=] and not all three possibilities, e.g.:
+
[G] [EL] dup cmp
+
+[GE] [L] dupd cmp
+
+
Or even:
+
[GL] [E] over cmp
+
+
Crosslinks
+
TODO: link to tree notebooks where this was used.
+
+
codi
+
Combinator
+
Take a quoted program from the stack, [cons] the next item onto
+it, then [dip] the whole thing under what was the third item on the
+stack.
+
a b [F] . codi
+--------------------
+ b . F a
+
+
Definition
+
+
[cons] [dip]
+
+
Discussion
+
This is one of those weirdly specific functions that turns out
+to be useful in a few places.
+
Crosslinks
+
[appN] [codireco]
+
+
codireco
+
Combinator
+
This is part of the [make_generator] function. You would not use
+this combinator directly.
This combinator works like a case statement. It expects a single
+quote on the stack that must contain zero or more condition quotes
+and a default quote. Each condition quote should contain a quoted
+predicate followed by the function expression to run if that
+predicate returns true. If no predicates return
+true the default function runs.
Specialist function (that means I forgot what it does and
+why.)
+
Definition
+
+
[dip] [infrst]
+
+
+
dip
+
Basis Combinator
+
The dip combinator expects a quoted program on the
+stack and below it some item, it hoists the item into the
+expression and runs the program on the rest of the stack.
+
... x [Q] . dip
+---------------------
+ ... . Q x
+
Note that the item that was on the top of the stack
+(x in the example above) will not be treated specially
+by the interpreter when it is reached again. This is something of a
+footgun. My advice is to avoid putting bare unquoted symbols onto
+the stack, but then you can't use symbols as "atoms" and also use
+dip and infra to operate on compound
+datastructures with atoms in them. This is a kind of side-effect of
+the Continuation-Passing Style. The dip combinator
+could "set aside" the item and replace it after running
+Q but that means that there is an "extra space" where
+the item resides while Q runs. One of the nice things
+about CPS is that the whole state is recorded in the stack and
+pending expression (not counting modifications to the
+dictionary.)
+
Crosslinks
+
[dipd] [dipdd] [dupdip] [dupdipd] [infra]
+
+
dipd
+
Combinator
+
Like [dip] but expects two items.
+
... y x [Q] . dipd
+-------------------------
+ ... . Q y x
+
+
Discussion
+
See [dip].
+
Crosslinks
+
[dip] [dipdd] [dupdip] [dupdipd] [infra]
+
+
dipdd
+
Combinator
+
Like [dip] but expects three items. :
+
... z y x [Q] . dip
+-----------------------------
+ ... . Q z y x
+
+
Discussion
+
See [dip].
+
Crosslinks
+
[dip] [dipd] [dupdip] [dupdipd] [infra]
+
+
disenstacken
+
Function
+
The disenstacken function expects a list on top of
+the stack and makes that the stack discarding the rest of the
+stack.
Note that the order of the list is not changed, it just looks
+that way because the stack is printed with the top on the right
+while lists are printed with the top or head on the left.
(Note that this definition includes the genrec
+symbol itself, it is self-referential. This is possible because the
+definition machinery does not check that symbols in defs are in the
+dictionary. genrec is the only self-referential
+definition.)
"The genrec combinator takes four program parameters in addition
+to whatever data parameters it needs. Fourth from the top is an
+if-part, followed by a then-part. If the if-part yields true, then
+the then-part is executed and the combinator terminates. The other
+two parameters are the rec1-part and the rec2-part. If the if-part
+yields false, the rec1-part is executed. Following that the four
+program parameters and the combinator are again pushed onto the
+stack bundled up in a quoted form. Then the rec2-part is executed,
+where it will find the bundled form. Typically it will then execute
+the bundled form, either with i or with app2, or some other
+combinator."
+
+
The way to design one of these is to fix your base case
+[then] and the test [if], and then treat
+rec1 and rec2 as an else-part
+"sandwiching" a quotation of the whole function.
+
For example, given a (general recursive) function
+F:
+
F == [I] [T] [R1] [R2] genrec
+
+
If the [I] if-part fails you must derive
+R1 and R2 from: :
+
... R1 [F] R2
+
+
Just set the stack arguments in front, and figure out what
+R1 and R2 have to do to apply the quoted
+[F] in the proper way. In effect, the
+genrec combinator turns into an [ifte] combinator with
+a quoted copy of the original definition in the else-part:
Accept a quoted program and a list on the stack and run the
+program with the list as its stack. Does not affect the stack
+(below the list.)
+
... x y z [a b c] [Q] infra
+---------------------------------
+ c b a Q [z y x ...] swaack
+
+
Definition
+
+
[swons] [swaack] [[i]] [dip] [swaack]
+
+
Discussion
+
This is one of the more useful combinators. It allows a quoted
+expression to serve as a stack for a program, effectively running
+it in a kind of "pocket universe". If the list represents a
+datastructure then infra lets you work on its internal
+structure.
Does [infra] and then extracts the [first] item from the
+resulting list.
+
Definition
+
+
[infra] [first]
+
+
+
inscribe
+
Create a new Joy function definition in the Joy dictionary. A
+definition is given as a quote with a name followed by a Joy
+expression.
+
Example
+
[sqr dup mul] inscribe
+
+
Discussion
+
This is the only function that modifies the dictionary. It's
+provided as a convenience, for tinkering with new definitions
+before entering them into the defs.txt file. It can be
+abused, which you should avoid unless you know what you're
+doing.
+
+
le
+
Basis Function
+
Less-Than-or-Equal-to comparison of the two items on the top of
+the stack, replacing them with a Boolean value.
+
a b le
+-------------
+ Boolean
+ (a <= b)
+
+
Crosslinks
+
[cmp] [eq] [ge] [gt] [lt] [ne]
+
+
loop
+
Basis Combinator
+
Expect a quoted program Q and a Boolean value on
+the stack. If the value is false discard the quoted program,
+otherwise run a copy of Q and loop
+again.
This, along with [branch] and [fork], is one of the four main
+combinators of all programming. The fourth, sequence, is implied by
+juxtaposition. That is to say, in Joy F G is like
+G(F(...)) in a language bassed on function
+application. Or again, to quote the Joy
+Wikipedia entry#Mathematical_purity),
+
+
In Joy, the meaning function is a homomorphism from the
+syntactic monoid onto the semantic monoid. That is, the syntactic
+relation of concatenation of symbols maps directly onto the
+semantic relation of composition of functions.
+
+
Anyway, [branch], [fork], amd [loop] are the fundamental
+combinators in Joy. Just as [branch] has it's more common and
+convenient form [ifte], [loop] has [while].
Given a list of items and a quoted program run the program for
+each item in the list (with the rest of the stack) and replace the
+old list and the program with a list of the results.
Like [getitem] but [swap]s the order of arguments.
+
Example
+
2 [a b c d] of
+--------------------
+ c
+
+
Definition
+
+
[swap] [getitem]
+
+
Crosslinks
+
[getitem]
+
+
or
+
Basis Function
+
Logical bit-wise OR.
+
Crosslinks
+
[and] [xor]
+
+
over
+
Function
+
[dup] the second item on the stack over the
+first.
+
a b over
+--------------
+ a b a
+
+
Definition
+
There are many many ways to define this function.
+
+
[swap] [tuck]
+
[[pop]] [nullary]
+
[[dup]] [dip] [swap]
+
[unit] [dupdip]
+
[unit] [dupdipd] [first]
+
+
And so on...
+
Discussion
+
A fine old word from Forth.
+
Crosslinks
+
[tuck]
+
+
pam
+
Combinator
+
Take a list of quoted functions from the stack and replace it
+with a list of the [first] results from running those functions (on
+copies of the rest of the stack.)
The primrec combinator expects two quoted programs in addition
+to a data parameter. For an integer data parameter it works like
+this: If the data parameter is zero, then the first quotation has
+to produce the value to be returned. If the data parameter is
+positive then the second has to combine the data parameter with the
+result of applying the function to its predecessor.
+
5 [1] [*] primrec
+
Then primrec tests whether the top element on the stack
+(initially the 5) is equal to zero. If it is, it pops it off and
+executes one of the quotations, the [1] which leaves 1 on the stack
+as the result. Otherwise it pushes a decremented copy of the top
+element and recurses. On the way back from the recursion it uses
+the other quotation, [*], to multiply what is now a factorial on
+top of the stack by the second element on the stack.
+
+
0 [Base] [Recur] primrec
+------------------------------
+ Base
+
+ n [Base] [Recur] primrec
+------------------------------------------ n > 0
+ n (n-1) [Base] [Recur] primrec Recur
+
+
Discussion
+
Simple and useful specialization of the [genrec] combinator from
+the original
+Joy system.
+
Crosslinks
+
[genrec] [tailrec]
+
+
product
+
Function
+
Just as [sum] sums a list of numbers, this function multiplies
+them together.
+
Definition
+
+
1 [swap] [[mul]] [step]
+
+
Or,
+
+
[1] [[mul]] [primrec]
+
+
+
quoted
+
Function
+
"Quote D" Wrap the second item on the stack in a list.
+
a b quoted
+----------------
+ [a] b
+
+
Definition
+
+
[[unit]] [dip]
+
+
Discussion
+
This comes from the original Joy stuff.
+
Crosslinks
+
[unit]
+
+
range
+
Function
+
Expect a number n on the stack and replace it with
+a list: [(n-1)...0].
+
Example
+
5 range
+-----------------
+ [4 3 2 1 0]
+
+ -5 range
+--------------
+ []
+
+
Definition
+
+
[0 \<=] [1 - [dup]] [anamorphism]
+
+
Discussion
+
If n is less than 1 the resulting list is
+empty.
+
Crosslinks
+
[rangetozero]
+
+
rangetozero
+
Function
+
Take a number n from the stack and replace it with
+a list [0...n].
Expects an item on the stack and a quote under it and removes
+that item from the the quote. The item is only removed once. If the
+list is empty or the item isn't in the list then the list is
+unchanged.
Take a list and a number n from the stack, take
+n items from the top of the list and [shunt] them onto
+a new list that replaces the number n on the top of
+the stack.
+
Crosslinks
+
[split_list]
+
+
split_list
+
Function
+
Split a list (second on the stack) at the position given by the
+number on the top of the stack such that [concat] would reconstruct
+the original list.
This function works as a kind of "context switch". It's used in
+the definition of [infra].
+
Crosslinks
+
[infra]
+
+
swap
+
Basis Function
+
Swap the top two items on the stack.
+
a b swap
+--------------
+ b a
+
+
Crosslinks
+
[swapd]
+
+
swapd
+
Function
+
Swap the second and third items on the stack.
+
a b c swapd
+-----------------
+ b a c
+
+
Definition
+
+
[[swap]] [dip]
+
+
Crosslinks
+
[over] [tuck]
+
+
swoncat
+
Function
+
[concat] two lists, but [swap] the lists first.
+
Definition
+
+
[swap] [concat]
+
+
Crosslinks
+
[concat]
+
+
swons
+
Function
+
Like [cons] but [swap] the item and list.
+
[...] a swons
+-------------------
+ [a ...]
+
+
Definition
+
+
[swap] [cons]
+
+
+
tailrec
+
Combinator
+
A specialization of the [genrec] combinator.
+
Definition
+
+
[[i]] [genrec]
+
+
Discussion
+
Some recursive functions do not need to store additional data or
+pending actions per-call. These are called "tail recursive"
+functions. In Joy, they appear as [genrec] definitions that
+have [i] for the second half of their recursive branch.
Expect a quoted program and an integer n on the
+stack and do the program n times.
+
... n [Q] . times
+----------------------- w/ n <= 0
+ ... .
+
+ ... 1 [Q] . times
+-----------------------
+ ... . Q
+
+ ... n [Q] . times
+------------------------------------- w/ n > 1
+ ... . Q (n-1) [Q] times
+
+
Definition
+
+
[-- dip] cons [swap] infra [0 >] swap while pop :
+
+
Discussion
+
This works by building a little [while] program and running
+it:
+
1 3 [++] • [-- dip] cons [swap] infra [0 >] swap while pop
+ 1 3 [++] [-- dip] • cons [swap] infra [0 >] swap while pop
+ 1 3 [[++] -- dip] • [swap] infra [0 >] swap while pop
+ 1 3 [[++] -- dip] [swap] • infra [0 >] swap while pop
+ dip -- [++] • swap [3 1] swaack [0 >] swap while pop
+ dip [++] -- • [3 1] swaack [0 >] swap while pop
+ dip [++] -- [3 1] • swaack [0 >] swap while pop
+ 1 3 [-- [++] dip] • [0 >] swap while pop
+ 1 3 [-- [++] dip] [0 >] • swap while pop
+ 1 3 [0 >] [-- [++] dip] • while pop
+
+
This is a common pattern in Joy. You accept some parameters from
+the stack which typically include qouted programs and use them to
+build another program which does the actual work. This is kind of
+like macros in Lisp, or preprocessor directives in C.
[a ...] unswons
+---------------------
+ [...] a
+
+
Definition
+
+
[uncons] [swap]
+
+
+
void
+
Basis Function
+
True if the form on TOS is void otherwise False.
+
Discussion
+
A form is any Joy expression composed solely of lists. This
+represents a binary Boolean logical formula in the arithmetic of
+the "Laws of Form", see The
+Markable Mark
+
+
warranty
+
Basis Function
+
Print warranty information.
+
+
while
+
Combinator
+
A specialization of [loop] that accepts a quoted predicate
+program P and runs it [nullary].
+
[P] [F] while
+------------------- P -> false
+
+ [P] [F] while
+--------------------- P -> true
+ F [P] [F] while
+
+
Definition
+
+
[swap] [nulco] [dupdipd] [concat] [loop]
+
+
Crosslinks
+
[loop]
+
+
words
+
Basis Function
+
Print all the words in alphabetical order.
+
Discussion
+
Mathematically this is a form of [id].
+
Crosslinks
+
[help]
+
+
x
+
Combinator
+
Take a quoted function F and run it with itself as
+the first item on the stack.
+
+
diff --git a/docs/html/index.html b/docs/html/index.html
index 62a6077..ae68769 100644
--- a/docs/html/index.html
+++ b/docs/html/index.html
@@ -86,7 +86,10 @@ coordinate pair in a square spiral (like the kind used to construct an
This implementation is meant as a tool for exploring the programming model and method of Joy. Python seems like a great implementation language for Joy for several reasons. We can lean on the Python immutable types for our basic semantics and types: ints, floats, strings, and tuples, which enforces functional purity. We get garbage collection for free. Compilation via Cython. Glue language with loads of libraries.
The <-top marker points to the top of the (initially empty) stack. You can enter Joy notation at the prompt and a trace of evaluation will be printed followed by the stack and prompt again:
In Joy, in addition to the types Boolean, integer, float, and string, there is a single sequence type represented by enclosing a sequence of terms in brackets [...]. This sequence type is used to represent both the stack and the expression. It is a cons list made from Python tuples.
The joy() function is extrememly simple. It accepts a stack, an expression, and a dictionary, and it iterates through the expression putting values onto the stack and delegating execution to functions it looks up in the dictionary.
+
Each function is passed the stack, expression, and dictionary and returns them. Whatever the function returns becomes the new stack, expression, and dictionary. (The dictionary is passed to enable e.g. writing words that let you enter new words into the dictionary at runtime, which nothing does yet and may be a bad idea, and the help command.)
The joy() function accepts a "viewer" function which it calls on each iteration passing the current stack and expression just before evaluation. This can be used for tracing, breakpoints, retrying after exceptions, or interrupting an evaluation and saving to disk or sending over the network to resume later. The stack and expression together contain all the state of the computation at each step.
A viewer records each step of the evaluation of a Joy program. The TracePrinter has a facility for printing out a trace of the evaluation, one line per step. Each step is aligned to the current interpreter position, signified by a period separating the stack on the left from the pending expression ("continuation") on the right.
One day I thought, What happens if you rewrite Joy to use CSP? I made all the functions accept and return the expression as well as the stack and found that all the combinators could be rewritten to work by modifying the expression rather than making recursive calls to the joy() function.
The parser is extremely simple, the undocumented re.Scanner class does most of the tokenizing work and then you just build the tuple structure out of the tokens. There's no Abstract Syntax Tree or anything like that.
The Joy library of functions (aka commands, or "words" after Forth usage) encapsulates all the actual functionality (no pun intended) of the Joy system. There are simple functions such as addition add (or +, the library module supports aliases), and combinators which provide control-flow and higher-order operations.
!= % & * *fraction *fraction0 + ++ - -- / // /floor < << <= <> = > >= >> ? ^ _Tree_add_Ee _Tree_delete_R0 _Tree_delete_clear_stuff _Tree_get_E abs add anamorphism and app1 app2 app3 at average b binary bool branch ccons choice clear cleave cmp codireco concat cond cons dinfrirst dip dipd dipdd disenstacken div divmod down_to_zero drop dup dupd dupdd dupdip dupdipd enstacken eq first first_two flatten floor floordiv fork fourth gcd gcd2 ge genrec getitem gt help i id ifte ii infra inscribe le least_fraction loop lshift lt make_generator map max min mod modulus mul ne neg not nullary of or over pam parse pick pm pop popd popdd popop popopd popopdd pow pred primrec product quoted range range_to_zero rem remainder remove rest reverse roll< roll> rolldown rollup round rrest rshift run second select sharing shunt size sort sqr sqrt stack step step_zero stuncons stununcons sub succ sum swaack swap swoncat swons tailrec take ternary third times truthy tuck unary uncons unique unit unquoted unstack unswons void warranty while words x xor zip •
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Many of the functions are defined in Python, like dip:
+
+
+
+
+
+
+
+
+
+
In [12]:
+
+
+
importinspect
+
+
+
+
+
+
+
+
+
+
+
+
+
In [13]:
+
+
+
print(inspect.getdoc(joy.library.dip))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The dip combinator expects a quoted program on the stack and below it
+some item, it hoists the item into the expression and runs the program
+on the rest of the stack.
+::
+
+ ... x [Q] dip
+ -------------------
+ ... Q x
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The code (I was using inspect.getsource() here to automatically print the souce but it was not as nice-looking that way due to lack of syntax highlighting and the docstring being too long for the width of the element and wrapping in an ungainly way. SO now, instead, I'm just including it as a Python cell in the notebook):
Some functions are defined in equations in terms of other functions. When the interpreter executes a definition function that function just pushes its body expression onto the pending expression (the continuation) and returns control to the interpreter.
+
(Note that the embedded joy.library.definitions is going away in favor of a def.txt file that would be read in at start-time. See
+Ticket: thun-der#7)
Currently, there's no function to add new definitions to the dictionary from "within" Joy code itself. (Actually there is, it's called inscribe, but don't use it, eh? :) Adding new definitions remains a meta-interpreter action. You have to do it yourself, in Python, and wash your hands afterward.
+
It would be simple enough to define one, but it would open the door to name binding and break the idea that all state is captured in the stack and expression. There's an implicit standard dictionary that defines the actual semantics of the syntactic stack and expression datastructures (which only contain symbols, not the actual functions. Pickle some and see for yourself.)
Which brings me to talking about one of my hopes and dreams for this notation: "There should be only one." What I mean is that there should be one universal standard dictionary of commands, and all bespoke work done in a UI for purposes takes place by direct interaction and macros. There would be a Grand Refactoring biannually (two years, not six months, that's semi-annually) where any new definitions factored out of the usage and macros of the previous time, along with new algorithms and such, were entered into the dictionary and posted to e.g. IPFS.
+
Code should not burgeon wildly, as it does today. The variety of code should map more-or-less to the well-factored variety of human computably-solvable problems. There shouldn't be dozens of chat apps, JS frameworks, programming languages. It's a waste of time, a fractal "thundering herd" attack on human mentality.
If you read over the other notebooks you'll see that developing code in Joy is a lot like doing simple mathematics, and the descriptions of the code resemble math papers. The code also works the first time, no bugs. If you have any experience programming at all, you are probably skeptical, as I was, but it seems to work: deriving code mathematically seems to lead to fewer errors.
+
But my point now is that this great ratio of textual explanation to wind up with code that consists of a few equations and could fit on an index card is highly desirable. Less code has fewer errors. The structure of Joy engenders a kind of thinking that seems to be very effective for developing structured processes.
+
There seems to be an elegance and power to the notation.
A viewer records each step of the evaluation of a Joy program. The TracePrinter has a facility for printing out a trace of the evaluation, one line per step. Each step is aligned to the current interpreter position, signified by a period separating the stack on the left from the pending expression ("continuation") on the right. I find these traces beautiful, like a kind of art.
This is what I like to call the functions that just rearrange things on the stack. (One thing I want to mention is that during a hypothetical compilation phase these "stack chatter" words effectively disappear, because we can map the logical stack locations to registers that remain static for the duration of the computation. This remains to be done but it's "off the shelf" technology.)
"Swap stack" swap the list on the top of the stack for the stack, and put the old stack on top of the new one. Think of it as a context switch. Niether of the lists/stacks change their order.
+==== Help on app1 ====
+
+Given a quoted program on TOS and anything as the second stack item run
+the program and replace the two args with the first result of the
+program.
+::
+
+ ... x [Q] . app1
+ -----------------------------------
+ ... [x ...] [Q] . infra first
+
+---- end (app1)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In [90]:
+
+
+
J('10 4 [sqr *] app1')
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
10 160
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In [91]:
+
+
+
J('10 3 4 [sqr *] app2')
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
10 90 160
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In [92]:
+
+
+
J('[app2] help')
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+==== Help on app2 ====
+
+Like app1 with two items.
+::
+
+ ... y x [Q] . app2
+ -----------------------------------
+ ... [y ...] [Q] . infra first
+ [x ...] [Q] infra first
+
+---- end (app2)
+
+
+
From the original Joy docs: "The cleave combinator expects two quotations, and below that an item x
+It first executes [P], with x on top, and saves the top result element.
+Then it executes [Q], again with x, and saves the top result.
+Finally it restores the stack to what it was below x and pushes the two
+results P(X) and Q(X)."
+
Note that P and Q can use items from the stack freely, since the stack (below x) is restored. cleave is a kind of parallel primitive, and it would make sense to create a version that uses, e.g. Python threads or something, to actually run P and Q concurrently. The current implementation of cleave is a definition in terms of app2:
+==== Help on genrec ====
+
+General Recursion Combinator.
+::
+
+ [if] [then] [rec1] [rec2] genrec
+ ---------------------------------------------------------------------
+ [if] [then] [rec1 [[if] [then] [rec1] [rec2] genrec] rec2] ifte
+
+From "Recursion Theory and Joy" (j05cmp.html) by Manfred von Thun:
+"The genrec combinator takes four program parameters in addition to
+whatever data parameters it needs. Fourth from the top is an if-part,
+followed by a then-part. If the if-part yields true, then the then-part
+is executed and the combinator terminates. The other two parameters are
+the rec1-part and the rec2-part. If the if-part yields false, the
+rec1-part is executed. Following that the four program parameters and
+the combinator are again pushed onto the stack bundled up in a quoted
+form. Then the rec2-part is executed, where it will find the bundled
+form. Typically it will then execute the bundled form, either with i or
+with app2, or some other combinator."
+
+The way to design one of these is to fix your base case [then] and the
+test [if], and then treat rec1 and rec2 as an else-part "sandwiching"
+a quotation of the whole function.
+
+For example, given a (general recursive) function 'F':
+::
+
+ F == [I] [T] [R1] [R2] genrec
+
+If the [I] if-part fails you must derive R1 and R2 from:
+::
+
+ ... R1 [F] R2
+
+Just set the stack arguments in front, and figure out what R1 and R2
+have to do to apply the quoted [F] in the proper way. In effect, the
+genrec combinator turns into an ifte combinator with a quoted copy of
+the original definition in the else-part:
+::
+
+ F == [I] [T] [R1] [R2] genrec
+ == [I] [T] [R1 [F] R2] ifte
+
+Primitive recursive functions are those where R2 == i.
+::
+
+ P == [I] [T] [R] tailrec
+ == [I] [T] [R [P] i] ifte
+ == [I] [T] [R P] ifte
+
+---- end (genrec)
+
+
+
+==== Help on step ====
+
+Run a quoted program on each item in a sequence.
+::
+
+ ... [] [Q] . step
+ -----------------------
+ ... .
+
+
+ ... [a] [Q] . step
+ ------------------------
+ ... a . Q
+
+
+ ... [a b c] [Q] . step
+ ----------------------------------------
+ ... a . Q [b c] [Q] step
+
+The step combinator executes the quotation on each member of the list
+on top of the stack.
+
+---- end (step)
+
+
+
Implements Laws of Formarithmetic over quote-only datastructures (that is, datastructures that consist soley of containers, without strings or numbers or anything else.)
If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.
+
+Find the sum of all the multiples of 3 or 5 below 1000.
+
+
+
+
+
+
+
+
+
+
+
In [1]:
+
+
+
fromnotebook_preambleimportJ,V,define
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Let's create a predicate that returns True if a number is a multiple of 3 or 5 and False otherwise.
+
+
+
+
+
+
+
+
+
+
In [2]:
+
+
+
define('P [3 % not] dupdip 5 % not or')
+
+
+
+
+
+
+
+
+
+
+
+
+
In [3]:
+
+
+
V('80 P')
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
• 80 P
+ 80 • P
+ 80 • [3 % not] dupdip 5 % not or
+80 [3 % not] • dupdip 5 % not or
+ 80 • 3 % not 80 5 % not or
+ 80 3 • % not 80 5 % not or
+ 2 • not 80 5 % not or
+ False • 80 5 % not or
+ False 80 • 5 % not or
+ False 80 5 • % not or
+ False 0 • not or
+ False True • or
+ True •
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Given the predicate function P a suitable program is:
+
PE1 == 1000 range [P] filter sum
+
+
+
This function generates a list of the integers from 0 to 999, filters
+that list by P, and then sums the result.
+
Logically this is fine, but pragmatically we are doing more work than we
+should be; we generate one thousand integers but actually use less than
+half of them. A better solution would be to generate just the multiples
+we want to sum, and to add them as we go rather than storing them and
+adding summing them at the end.
+
At first I had the idea to use two counters and increase them by three
+and five, respectively. This way we only generate the terms that we
+actually want to sum. We have to proceed by incrementing the counter
+that is lower, or if they are equal, the three counter, and we have to
+take care not to double add numbers like 15 that are multiples of both
+three and five.
+
This seemed a little clunky, so I tried a different approach.
+
Consider the first few terms in the series:
+
3 5 6 9 10 12 15 18 20 21 ...
+
+
+
Subtract each number from the one after it (subtracting 0 from 3):
You get this lovely repeating palindromic sequence:
+
3 2 1 3 1 2 3
+
+
+
To make a counter that increments by factors of 3 and 5 you just add
+these differences to the counter one-by-one in a loop.
+
To make use of this sequence to increment a counter and sum terms as we
+go we need a function that will accept the sum, the counter, and the next
+term to add, and that adds the term to the counter and a copy of the
+counter to the running sum. This function will do that:
This form uses no extra storage and produces no unused summands. It's
+good but there's one more trick we can apply. The list of seven terms
+takes up at least seven bytes. But notice that all of the terms are less
+than four, and so each can fit in just two bits. We could store all
+seven terms in just fourteen bits and use masking and shifts to pick out
+each term as we go. This will use less space and save time loading whole
+integer terms from the list.
Here's our joy program all in one place. It doesn't make so much sense, but if you have read through the above description of how it was derived I hope it's clear.
+
PE1.1 == + [+] dupdip
+PE1.2 == [3 & PE1.1] dupdip 2 >>
+PE1.3 == 14811 swap [PE1.2] times pop
+PE1 == 0 0 66 [7 PE1.3] times 4 PE1.3 pop
+
It's a little clunky iterating sixty-six times though the seven numbers then four more. In the Generator Programs notebook we derive a generator that can be repeatedly driven by the x combinator to produce a stream of the seven numbers repeating over and over again.
Now we can use PE1.1 to accumulate the terms as we go, and then pop the generator and the counter from the stack when we're done, leaving just the sum.
+
+
+
+
+
+
+
+
+
+
In [28]:
+
+
+
J('0 0 PE1.terms 466 [x [PE1.1] dip] times popop')
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
233168
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
A little further analysis renders iteration unnecessary.¶
Consider finding the sum of the positive integers less than or equal to ten.
Since there are sixty-six blocks and we are pairing them up, there must be thirty-three pairs, each of which sums to 6945. We also have these additional unpaired terms between 990 and 1000:
+
993 995 996 999
+
+
+
So we can give the "sum of all the multiples of 3 or 5 below 1000" like so:
+
+
+
+
+
+
+
+
+
+
In [35]:
+
+
+
J('6945 33 * [993 995 996 999] cons sum')
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
233168
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
It's worth noting, I think, that this same reasoning holds for any two numbers $n$ and $m$ the multiples of which we hope to sum. The multiples would have a cycle of differences of length $k$ and so we could compute the sum of $Nk$ multiples as above.
+
The sequence of differences will always be a palidrome. Consider an interval spanning the least common multiple of $n$ and $m$:
+
| | | | | | | |
+| | | | |
+
+
+
Here we have 4 and 7, and you can read off the sequence of differences directly from the diagram: 4 3 1 4 2 2 4 1 3 4.
+
Geometrically, the actual values of $n$ and $m$ and their lcm don't matter, the pattern they make will always be symmetrical around its midpoint. The same reasoning holds for multiples of more than two numbers.
[Given] a sequence of digits (your puzzle input) and find the sum of all digits that match the next digit in the list. The list is circular, so the digit after the last digit is the first digit in the list.
+
For example:
+
+
1122 produces a sum of 3 (1 + 2) because the first digit (1) matches the second digit and the third digit (2) matches the fourth digit.
+
1111 produces 4 because each digit (all 1) matches the next.
+
1234 produces 0 because no digit matches the next.
+
91212129 produces 9 because the only digit that matches the next one is the last digit, 9.
+
+
+
+
+
+
+
+
+
+
+
In [1]:
+
+
+
fromnotebook_preambleimportJ,V,define
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
I'll assume the input is a Joy sequence of integers (as opposed to a string or something else.)
+
We might proceed by creating a word that makes a copy of the sequence with the first item moved to the last, and zips it with the original to make a list of pairs, and a another word that adds (one of) each pair to a total if the pair matches.
With Joy a great deal of the heuristics from Forth programming carry over nicely. For example, refactoring into small, well-scoped commands with mnemonic names...
...find the only two numbers in each row where one evenly divides the other - that is, where the result of the division operation is a whole number. They would like you to find those numbers on each line, divide them, and add up each line's result.
+
For example, given the following spreadsheet:
+
5 9 2 8
+9 4 7 3
+3 8 6 5
+
+
+
+
In the first row, the only two numbers that evenly divide are 8 and 2; the result of this division is 4.
+
In the second row, the two numbers are 9 and 3; the result is 3.
+
In the third row, the result is 2.
+
+
In this example, the sum of the results would be 4 + 3 + 2 = 9.
+
What is the sum of each row's result in your puzzle input?
Q should either leave the result and False, or the rest and True.
+
[a b c d] Q
+-----------------
+ result 0
+
+ [a b c d] Q
+-----------------
+ [b c d] 1
+
+
+
+
+
+
+
+
+
+
+
+
+
This suggests that Q should start with:
+
[a b c d] uncons dup roll<
+[b c d] [b c d] a
+
+
+
Now we just have to pop it if we don't need it.
+
[b c d] [b c d] a [P] [T] [cons] app2 popdd [E] primrec
+[b c d] [b c d] [a P] [a T] [E] primrec
+
+
+
+
w/ Q == [% not] [T] [F] primrec
+
+ [a b c d] uncons
+ a [b c d] tuck
+[b c d] a [b c d] uncons
+[b c d] a b [c d] roll>
+[b c d] [c d] a b Q
+[b c d] [c d] a b [% not] [T] [F] primrec
+
+[b c d] [c d] a b T
+[b c d] [c d] a b / roll> popop 0
+
+[b c d] [c d] a b F Q
+[b c d] [c d] a b pop swap uncons ... Q
+[b c d] [c d] a swap uncons ... Q
+[b c d] a [c d] uncons ... Q
+[b c d] a c [d] roll> Q
+[b c d] [d] a c Q
+
+Q == [% not] [/ roll> popop 0] [pop swap uncons roll>] primrec
+
+uncons tuck uncons roll> Q
+
Now we need a word that uses G on each (head, tail) pair of a sequence until it finds a (non-zero) result. It's going to be designed to work on a stack that has some candidate n, a sequence of possible divisors, and a result that is zero to signal to continue (a non-zero value implies that it is the discovered result):
+
n [...] p find-result
+---------------------------
+ result
+
+
+
It applies G using nullary because if it fails with one candidate it needs the list to get the next one (the list is otherwise consumed by G.)
The base-case is trivial, return the (non-zero) result. The recursive branch...
+
n [...] p roll< popop uncons [G] nullary find-result
+[...] p n popop uncons [G] nullary find-result
+[...] uncons [G] nullary find-result
+m [..] [G] nullary find-result
+m [..] p find-result
+
+
+
The puzzle states that the input is well-formed, meaning that we can expect a result before the row sequence empties and so do not need to guard the uncons.
In order to get the thing started, we need to sort the list in descending order, then prime the find-result function with a dummy candidate value and zero ("continue") flag.
You come across an experimental new kind of memory stored on an infinite two-dimensional grid.
+
Each square on the grid is allocated in a spiral pattern starting at a location marked 1 and then counting up while spiraling outward. For example, the first few squares are allocated like this:
While this is very space-efficient (no squares are skipped), requested data must be carried back to square 1 (the location of the only access port for this memory system) by programs that can only move up, down, left, or right. They always take the shortest path: the Manhattan Distance between the location of the data and square 1.
+
For example:
+
+
Data from square 1 is carried 0 steps, since it's at the access port.
+
Data from square 12 is carried 3 steps, such as: down, left, left.
+
Data from square 23 is carried only 2 steps: up twice.
+
Data from square 1024 must be carried 31 steps.
+
+
How many steps are required to carry the data from the square identified in your puzzle input all the way to the access port?
I freely admit that I worked out the program I wanted to write using graph paper and some Python doodles. There's no point in trying to write a Joy program until I'm sure I understand the problem well enough.
+
The first thing I did was to write a column of numbers from 1 to n (32 as it happens) and next to them the desired output number, to look for patterns directly:
We can figure out the pattern for a row of the pyramid at a given "rank" $k$:
+
$2k - 1, 2k - 2, ..., k, k + 1, k + 2, ..., 2k$
+
or
+
$k + (k - 1), k + (k - 2), ..., k, k + 1, k + 2, ..., k + k$
+
This shows that the series consists at each place of $k$ plus some number that begins at $k - 1$, decreases to zero, then increases to $k$. Each row has $2k$ members.
+
+
+
+
+
+
+
+
+
+
+
+
Let's figure out how, given an index into a row, we can calculate the value there. The index will be from 0 to $k - 1$.
+
Let's look at an example, with $k = 4$:
+
0 1 2 3 4 5 6 7
+7 6 5 4 5 6 7 8
+
+
+
+
+
+
+
+
+
+
+
In [1]:
+
+
+
k=4
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Subtract $k$ from the index and take the absolute value:
+
+
+
+
+
+
+
+
+
+
In [2]:
+
+
+
forninrange(2*k):
+ print(abs(n-k),)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
4
+3
+2
+1
+0
+1
+2
+3
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Not quite. Subtract $k - 1$ from the index and take the absolute value:
(I'm leaving out details of how I figured this all out and just giving the relevent bits. It took a little while to zero in of the aspects of the pattern that were important for the task.)
Now that we can compute the desired output value for a given rank and the offset (index) into that rank, we need to determine how to find the rank and offset of a number.
+
The rank is easy to find by iteratively stripping off the amount already covered by previous ranks until you find the one that brackets the target number. Because each row is $2k$ places and there are $4$ per rank each rank contains $8k$ places. Counting the initial square we have:
+
$corner_k = 1 + \sum_{n=1}^k 8n$
+
I'm not mathematically sophisticated enough to turn this directly into a formula (but Sympy is, see below.) I'm going to write a simple Python function to iterate and search:
+
+
+
+
+
+
+
+
+
+
In [7]:
+
+
+
defrank_and_offset(n):
+ assertn>=2# Guard the domain.
+ n-=2# Subtract two,
+ # one for the initial square,
+ # and one because we are counting from 1 instead of 0.
+ k=1
+ whileTrue:
+ m=8*k# The number of places total in this rank, 4(2k).
+ ifn<m:
+ returnk,n%(2*k)
+ n-=m# Remove this rank's worth.
+ k+=1
+
defrow_value(k,i):
+ returnabs(i-(k-1))+k
+
+
+defrank_and_offset(n):
+ n-=2# Subtract two,
+ # one for the initial square,
+ # and one because we are counting from 1 instead of 0.
+ k=1
+ whileTrue:
+ m=8*k# The number of places total in this rank, 4(2k).
+ ifn<m:
+ returnk,n%(2*k)
+ n-=m# Remove this rank's worth.
+ k+=1
+
+
+defaoc20173(n):
+ ifn<=1:
+ return0
+ k,i=rank_and_offset(n)
+ returnrow_value(k,i)
+
Using e.g. Sympy we can find the rank directly by solving for the roots of an equation. For large numbers this will (eventually) be faster than iterating as rank_and_offset() does.
First solve() for $E - n = 0$ which has two solutions (because the equation is quadratic so it has two roots) and since we only care about the larger one we use max() to select it. It will generally not be a nice integer (unless $n$ is the number of an end-corner of a rank) so we take the floor() and add 1 to get the integer rank of $n$. (Taking the ceiling() gives off-by-one errors on the rank boundaries. I don't know why. I'm basically like a monkey doing math here.) =-D
+
It gives correct answers:
+
+
+
+
+
+
+
+
+
+
In [18]:
+
+
+
fornin(9,10,25,26,49,50):
+ print(n,rank_of(n))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
9 1
+10 2
+25 2
+26 3
+49 3
+50 4
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
And it runs much faster (at least for large numbers):
+
+
+
+
+
+
+
+
+
+
In [19]:
+
+
+
%time rank_of(23000000000000) # Compare runtime with rank_and_offset()!
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
CPU times: user 27.8 ms, sys: 5 µs, total: 27.8 ms
+Wall time: 27.3 ms
+
+
+
+
+
+
Out[19]:
+
+
+
+
+
+$\displaystyle 2397916$
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In [20]:
+
+
+
%time rank_and_offset(23000000000000)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
CPU times: user 216 ms, sys: 89 µs, total: 216 ms
+Wall time: 215 ms
+
After finding the rank you would still have to find the actual value of the rank's first corner and subtract it (plus 2) from the number and compute the offset as above and then the final output, but this overhead is partially shared by the other method, and overshadowed by the time it (the other iterative method) would take for really big inputs.
+
The fun thing to do here would be to graph the actual runtime of both methods against each other to find the trade-off point.
+
+
+
+
+
+
+
+
+
+
+
+
It took me a second to realize I could do this...¶
Sympy is a symbolic math library, and it supports symbolic manipulation of equations. I can put in $y$ (instead of a value) and ask it to solve for $k$.
+
+
+
+
+
+
+
+
+
+
In [21]:
+
+
+
y=symbols('y')
+
+
+
+
+
+
+
+
+
+
+
+
+
In [22]:
+
+
+
g,f=solve(E-y,k)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The equation is quadratic so there are two roots, we are interested in the greater one...
(Note the sneaky way the sign changes from $k(k + 1)$ to $k(k - 1)$. This is because we want to subract the $(k - 1)$th rank's total places (its own and those of lesser rank) from our $n$ of rank $k$. Substituting $k - 1$ for $k$ in $k(k + 1)$ gives $(k - 1)(k - 1 + 1)$, which of course simplifies to $k(k - 1)$.)
+
+
+
+
+
+
+
+
+
+
In [32]:
+
+
+
offset_of(23000000000000,2397916)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Out[32]:
+
+
+
+
+
+$\displaystyle 223606$
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
So, we can compute the rank, then the offset, then the row value.
k i row_value
+-------------------
+ n
+
+abs(i - (k - 1)) + k
+
+k i over -- - abs +
+k i k -- - abs +
+k i k-1 - abs +
+k i-k-1 abs +
+k |i-k-1| +
+k+|i-k-1|
+
...a list of the offsets for each jump. Jumps are relative: -1 moves to the previous instruction, and 2 skips the next one. Start at the first instruction in the list. The goal is to follow the jumps until one leads outside the list.
+
In addition, these instructions are a little strange; after each jump, the offset of that instruction increases by 1. So, if you come across an offset of 3, you would move three instructions forward, but change it to a 4 for the next time it is encountered.
+
For example, consider the following list of jump offsets:
+
0
+3
+0
+1
+-3
+
+
+
Positive jumps ("forward") move downward; negative jumps move upward. For legibility in this example, these offset values will be written all on one line, with the current instruction marked in parentheses. The following steps would be taken before an exit is found:
+
+
(0) 3 0 1 -3 - before we have taken any steps.
+
(1) 3 0 1 -3 - jump with offset 0 (that is, don't jump at all). Fortunately, the instruction is then incremented to 1.
+
2 (3) 0 1 -3 - step forward because of the instruction we just modified. The first instruction is incremented again, now to 2.
+
+
+
2 4 0 1 (-3) - jump all the way to the end; leave a 4 behind.
+
+
+
2 (4) 0 1 -2 - go back to where we just were; increment -3 to -2.
+
For now, I'm going to assume a starting state with the size of the sequence pre-computed. We need it to define the exit condition and it is a trivial preamble to generate it. We then need and index and a step-count, which are both initially zero. Then we have the sequence itself, and some recursive function F that does the work.
+
size index step-count [...] F
+-----------------------------------
+ step-count
+
+F == [P] [T] [R1] [R2] genrec
+
+
+
Later on I was thinking about it and the Forth heuristic came to mind, to wit: four things on the stack are kind of much. Immediately I realized that the size properly belongs in the predicate of F! D'oh!
+
index step-count [...] F
+------------------------------
+ step-count
+
R1 == get the value at index
+ increment the value at the index
+ add the value gotten to the index
+ increment the step count
+
+
+
The only tricky thing there is incrementing an integer in the sequence. Joy sequences are not particularly good for random access. We could encode the list of jump offsets in a big integer and use math to do the processing for a good speed-up, but it still wouldn't beat the performance of e.g. a mutable array. This is just one of those places where "plain vanilla" Joypy doesn't shine (in default performance. The legendary Sufficiently-Smart Compiler would of course rewrite this function to use an array "under the hood".)
+
In the meantime, I'm going to write a primitive function that just does what we need.
+
+
+
+
+
+
+
+
+
+
In [1]:
+
+
+
fromnotebook_preambleimportD,J,V,define
+fromjoy.libraryimportSimpleFunctionWrapper
+fromjoy.utils.stackimportlist_to_stack
+
+
+@SimpleFunctionWrapper
+defincr_at(stack):
+ '''Given a index and a sequence of integers, increment the integer at the index.
+
+ E.g.:
+
+ 3 [0 1 2 3 4 5] incr_at
+ -----------------------------
+ [0 1 2 4 4 5]
+
+ '''
+ sequence,(i,stack)=stack
+ mem=[]
+ whilei>=0:
+ term,sequence=sequence
+ mem.append(term)
+ i-=1
+ mem[-1]+=1
+ returnlist_to_stack(mem,sequence),stack
+
+
+D['incr_at']=incr_at
+
This is by far the largest program I have yet written in Joy. Even with the incr_at function it is still a bear. There may be an arrangement of the parameters that would permit more elegant definitions, but it still wouldn't be as efficient as something written in assembly, C, or even Python.
[a F] x
+[a F] a F
+
+[a F] a swap [C] dip rest cons
+a [a F] [C] dip rest cons
+a C [a F] rest cons
+a C [F] cons
+
+w/ C == dup G
+
+a dup G [F] cons
+a a G [F] cons
+
+w/ G == dup max [index_of] nullary distribute
+
+
+
+
+
+
+
+
+
+
+
In [12]:
+
+
+
define('direco dip rest cons')
+
+
+
+
+
+
+
+
+
+
+
+
+
In [13]:
+
+
+
define('G [direco] cons [swap] swoncat cons')
+
+
+
+
+
+
+
+
+
+
+
+
+
In [14]:
+
+
+
define('make_distributor [dup dup max [index_of] nullary distribute] G')
+
You have to have a little discontinuity when going from a symbol to a literal, because you have to pick out the stack from the arguments to push the literal(s) onto it before you continue chaining function calls.
Call-chaining results in code that does too much work. For functions that operate on stacks and only rearrange values, what I like to call "Yin Functions", we can do better.
+
We can infer the stack effects of these functions (or "expressions" or "programs") automatically, and the stack effects completely define the semantics of the functions, so we can directly write out a two-line Python function for them. This is already implemented in the joy.utils.types.compile_() function.
All Yin functions can be described in Python as a tuple-unpacking (or "-destructuring") of the stack datastructure followed by building up the new stack structure.
There are times when you're deriving a Joy program when you have a stack effect for a Yin function and you need to define it. For example, in the Ordered Binary Trees notebook there is a point where we must derive a function Ee:
+
[key old_value left right] new_value key [Tree-add] Ee
+------------------------------------------------------------
+ [key new_value left right]
+
+
+
While it is not hard to come up with this function manually, there is no necessity. This function can be defined (in Python) directly from its stack effect:
+
[a b c d] e a [f] Ee
+--------------------------
+ [a e c d]
+
+
+
(I haven't yet implemented a simple interface for this yet. What follow is an exploration of how to do it.)
+
+
+
+
+
+
+
+
+
+
In [ ]:
+
+
+
fromjoy.parserimporttext_to_expression
+
+
+
+
+
+
+
+
+
+
+
+
+
In [ ]:
+
+
+
Ein='[a b c d] e a [f]'# The terms should be reversed here but I don't realize that until later.
+Eout='[a e c d]'
+E='[%s] [%s]'%(Ein,Eout)
+
+printE
+
Symbolic Logic in the Laws of Form ○ Python Expressions to Represent Forms ○ Reify Forms in an Environment ○ Building Circuits ○ Simplifying Expressions ○ SAT Solver ○ A Model of Computation
In 1969 George Spencer-Brown (GSB) published "Laws of Form" which presented a logical system based on a single action, a distinction, that is both an operation and a value. This notebook describes a Python implementation that mimics the Laws of Form notation and uses it to develop a model of computer circuits.
I call these three laws the Bricken Basis after William Bricken who figured out that the third law is complete with the other two. GSB had the first two laws and "Each Way" as the basis. (TODO: Find and include the references for all this.)
+
(If anything here is unclear read The Markable Mark. George Burnett-Stuart has done a fantastic job there explaining the Laws of Form.)
+
+
+
+
+
+
+
+
+
+
+
+
Python Sets and Strings as Laws of Form Calculus Expressions¶
We can use data structures made solely out of Python frozenset and string objects to represent the forms of the Laws of Form notation. I'm going to use the terms "expression" and "form" interchangably in this document.
+
+
+
+
+
+
+
+
+
+
In [1]:
+
+
+
classForm(frozenset):
+
+ def__str__(self):
+ # Because frozenset is immutable, and the contents are all string or frozenset,
+ # we can cache the string repr of a form.
+ try:
+ returnself._str
+ exceptAttributeError:
+ self._str='(%s)'%' '.join(sorted(map(str,self)))
+ returnself._str
+
+ __repr__=__str__
+
+
+defF(*terms):
+ '''Create a Form from terms.'''
+ returnForm([
+ termifisinstance(term,(basestring,Form))elseF(*term)
+ forterminterms
+ ])
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Define a few variable names.
+
+
+
+
+
+
+
+
+
+
In [2]:
+
+
+
a,b,c='abc'
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Some examples of forms.
+
+
+
+
+
+
+
+
+
+
In [3]:
+
+
+
A=F(a,b,c)
+A
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Out[3]:
+
+
+
+
+
+
(a b c)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In [4]:
+
+
+
B=F(a,(b,(c,)))
+B
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Out[4]:
+
+
+
+
+
+
(((c) b) a)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Forms like a b c must be enclosed in a pair of nested containers like so (( a b c )), this lets us treat them as a single (Python) object without inverting the logical value of the form.
+
+
+
+
+
+
+
+
+
+
In [5]:
+
+
+
C=F((a,b,c))
+C
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Out[5]:
+
+
+
+
+
+
((a b c))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Duplicate terms in a form are automatically removed by frozenset.
+
+
+
+
+
+
+
+
+
+
In [6]:
+
+
+
F(a,(b,),a,(b,))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Out[6]:
+
+
+
+
+
+
((b) a)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Order is irrelevant, again due to frozenset.
+
+
+
+
+
+
+
+
+
+
In [7]:
+
+
+
F(b,a,c)==F(a,b,c)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Out[7]:
+
+
+
+
+
+
True
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
It's prefectly okay to create forms out of other forms (not just strings.)
Given forms with string variable names in them we want to be able to substitute values from an environment. If these values are Mark or Void the result will be a pure arithmentic form.
The void() function returns a Boolean value (Python True or False), for convenience let's write a function that returns the Mark or Void value of a form.
For $n$ variables there are $2^n$ possible assignments of the two values of Mark and Void. If we generate environments that each contain one of the possible assignments of names to the base value we can evaluate an expression containing those names and compute its value.
This is a bit hard to read, so let's define a helper function to convert an environment to a string format.
+
+
+
+
+
+
+
+
+
+
In [18]:
+
+
+
defformat_env(env,m='()',v=' '):
+ return' '.join((v,m)[notenv[k]]forkinsorted(env))
+
+# Note that Mark is an empty frozenset so in a Boolean context in Python it is False,
+# likewise Void is a set with one member, so Python considers it True in a Boolean context.
+# The `not` in the expression is just to force such a Boolean context, and we compensate
+# by putting `v` in the zero-is-False position in the indexed tuple.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Now we can print out the environments in a table. Notice that it looks just like a list of the eight three-bit binary numbers.
+
+
+
+
+
+
+
+
+
+
In [19]:
+
+
+
print'i a b c i in Binary'
+fori,envinenumerate(envs):
+ printi,format_env(env,v='--'),'%3s'%(bin(i)[2:],)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
i a b c i in Binary
+0 -- -- -- 0
+1 -- -- () 1
+2 -- () -- 10
+3 -- () () 11
+4 () -- -- 100
+5 () -- () 101
+6 () () -- 110
+7 () () () 111
+
deftruth_table_3(expression):
+ printexpression
+ print' a b c | Value'
+ print'---------+------'
+ forEinenvs:
+ e=reify(expression,E)
+ printformat_env(E),'|',value_of(e,m='()',v='')
+
+
+
+
+
+
+
+
+
+
+
+
+
In [22]:
+
+
+
truth_table_3(B)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
(((c) b) a)
+ a b c | Value
+---------+------
+ | ()
+ () |
+ () | ()
+ () () | ()
+() |
+() () |
+() () |
+() () () |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
This makes it clear that each expression in Laws of Form calculus is describing a digital Boolean circuit. The names are its inputs and its Void/Mark value is its output. Each boundary is a multi-input NOR gate, known as the Peirce arrow or Quine dagger (See Sheffer stroke and NOR gate.) Instead of two Boolean values there is only one value and non-existance.
In order to work with expressions as digital circuits, let's define some helper functions that will create logic circuits out of simpler forms. The names of the functions below reflect the choice of Mark as Boolean True but this is just a convention.
+
+
+
+
+
+
+
+
+
+
In [23]:
+
+
+
nor=lambda*bits:F(*bits)
+or_=lambda*bits:F(bits)
+and_=lambda*bits:Form(F(bit)forbitinbits)
+nand=lambda*bits:nor(and_(*bits))
+nxor=eqiv=lambdaa,b:F((a,(b,)),((a,),b))
+xor=lambdaa,b:F(nxor(a,b))
+
+# To build logical expressions with Void as Boolean True use these functions.
+anti_nor=nand
+anti_or=and_
+anti_and=or_
+anti_nand=nor
+anti_eqiv=xor
+anti_xor=eqiv
+
Sometimes we will have a function for which we know the behavior (truth table) but not an expression and we want the expression. For example, imagine that we didn't just create the expression for this table:
+
a b c | Value
+---------+------
+ |
+ () |
+ () |
+ () () | ()
+() |
+() () | ()
+() () | ()
+() () () |
+
+
To write an expression for this table, first we should understand that each row can be represented as an expression.
+
⟶ ( a b c )
+ () ⟶ ( a b (c))
+ () ⟶ ( a (b) c )
+ () () ⟶ ( a (b) (c))
+() ⟶ ((a) b c )
+() () ⟶ ((a) b (c))
+() () ⟶ ((a) (b) c )
+() () () ⟶ ((a) (b) (c))
+
+
+
Each of the above expressions will be true (Mark-valued) for only one possible combination of the three input variables. For example, let's look at the sixth expression above:
+
+
+
+
+
+
+
+
+
+
In [33]:
+
+
+
e6=F((a,),b,(c,))
+truth_table(e6)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
((a) (c) b)
+ a b c | Value
+---------+------
+ |
+ () |
+ () |
+ () () |
+() |
+() () | ()
+() () |
+() () () |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
To make an expression that is Mark-valued for just certain rows of the table, pick those rows' expressions,
+
() () | ( a (b) (c))
+() () | ((a) b (c))
+() () | ((a) (b) c )
+
+
We can demonstrate this equivalence by evaluating the expression formed by eqiv() from these two.
+
For every environment (from the set of possible values for the variables) if both expressions have the same value when evaluated then the eqiv() of those expressions will be Mark-valued (true in our chosen context.)
+
+
+
+
+
+
+
+
+
+
In [35]:
+
+
+
truth_table(eqiv(E1,E2))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
(((((((((a) (b)) ((a) (c)) ((b) (c))))) ((((a) (b) (c)))))) ((((a) (b) c) ((a) (c) b) ((b) (c) a)))) (((((((a) (b)) ((a) (c)) ((b) (c))))) ((((a) (b) (c))))) (((((a) (b) c) ((a) (c) b) ((b) (c) a))))))
+ a b c | Value
+---------+------
+ | ()
+ () | ()
+ () | ()
+ () () | ()
+() | ()
+() () | ()
+() () | ()
+() () () | ()
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The truth table above shows that the equivalence expression is true (Mark-valued by our current convention) for all possible assignments of Mark/Void to the three variables a, b, and c. This indicates that the expression is a tautology.
If you have two binary digits ("bits") and you are interested in the (binary) sum of these digits you will need two circuits, one for the "ones place" and one for the "twos place" or "carry bit".
+
Consider:
+
a b | c s
+----+----
+0 0 | 0 0
+0 1 | 0 1
+1 0 | 0 1
+1 1 | 1 0
+
+
+
Treating each output column ('c' for carry, 's' for sum) as a single expression, it's easy to see that the carry bit is just AND and the sum bit is just XOR of the two input bits.
In order to add two multi-bit binary numbers we need adder circuits that are designed to work with three input bits: the two bits to add together and a carry bit from the previous addition:
Looking back at our table of three-variable expressions:
+
⟶ ( a b c )
+ () ⟶ ( a b (c))
+ () ⟶ ( a (b) c )
+ () () ⟶ ( a (b) (c))
+() ⟶ ((a) b c )
+() () ⟶ ((a) b (c))
+() () ⟶ ((a) (b) c )
+() () () ⟶ ((a) (b) (c))
+
+
+
We can easily determine expressions for sum and carry:
+
Sum = (a b (c)) (a (b) c) ((a) b c) ((a) (b) (c))
+
+Cout = (a (b) (c)) ((a) b (c)) ((a) (b) c) ((a) (b) (c))
+
The Form Python datastructure is based on frozenset so duplicate terms are automatically removed and order of terms is irrelevant just as we would prefer. But we want to be able to automatically simplify forms beyond just that. Ideally, we would like a function that applies the rules of the calculus automatically:
+
A((B)) = AB
+A() = ()
+A(AB) = A(B)
+
+
+
I'm going to specify the behaviour of the desired function in a unittest.
A single string in a form (a) should also be returned unchanged:
+
+
+
+
+
+
+
+
+
+
In [49]:
+
+
+
classUnwrapTest1(unittest.TestCase):
+
+ deftestNegatedLeaf(self):
+ a=nor('a')
+ self.assertEqual(a,simplify(a))
+
+
+defsimplify(form):
+
+ # Three easy cases, for strings, Mark, or Void, just return it.
+ ifisinstance(form,basestring)orforminBASE:
+ returnform
+
+ # We know it's a Form and it's not empty (else it would be the Mark and
+ # returned above.)
+
+ # Let's just recurse.
+ returnForm(simplify(inner)forinnerinform)
+
+
+if__name__=='__main__':
+ unittest.main(argv=['ignored','UnwrapTest1'],exit=False)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
.
+----------------------------------------------------------------------
+Ran 1 test in 0.001s
+
+OK
+
So far, so good. But what about ((a))? This should be returned as just a. And ((a b)) should remain ((a b)) because we can't represent just a b as a single Python object, so we have to retain the outer pair of containers to hold them without inverting the Mark/Void value (if we just used one container.)
+
+
+
+
+
+
+
+
+
+
In [50]:
+
+
+
classUnwrapTest2(unittest.TestCase):
+
+ deftestUnwrapLeaf(self):
+ '''((a)) = a'''
+ a=or_('a')
+ self.assertEqual('a',simplify(a))
+
+ deftestDoNotUnwrapTwoLeaves(self):
+ '''((a b)) = ((a b))'''
+ a=or_('a','b')
+ self.assertEqual(a,simplify(a))
+
+
+defsimplify(form):
+
+ # Three easy cases, for strings, Mark, or Void, just return it.
+ ifisinstance(form,basestring)orforminBASE:
+ returnform
+
+ # We know it's a Form and it's not empty (else it would be the Mark and
+ # returned above.)
+
+ # Let's just recurse.
+ result=Form(simplify(inner)forinnerinform)
+
+ # Check for ((a)) and return just a.
+ # If there is more than one item in the inner container ((a b..))
+ # then we must keep the outer containers.
+ iflen(result)==1:
+ inner,=result# inner = (a)
+ ifisinstance(inner,Form)andlen(inner)==1:
+ a,=inner
+ returna
+
+ returnresult
+
+
+if__name__=='__main__':
+ unittest.main(argv=['ignored','UnwrapTest2'],exit=False)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
..
+----------------------------------------------------------------------
+Ran 2 tests in 0.002s
+
+OK
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Does it work for (((a))) = (a) and ((((a)))) = a and so on?
+
+
+
+
+
+
+
+
+
+
In [51]:
+
+
+
classUnwrapTest3(unittest.TestCase):
+
+ deftestMultiUnwrapLeaf(self):
+ A='a'
+ B=nor(A)
+ a=nor(B)
+ self.assertEqual(A,simplify(a))
+ a=nor(a)
+ self.assertEqual(B,simplify(a))
+ a=nor(a)
+ self.assertEqual(A,simplify(a))
+ a=nor(a)
+ self.assertEqual(B,simplify(a))
+ a=nor(a)
+ self.assertEqual(A,simplify(a))
+ a=nor(a)
+ self.assertEqual(B,simplify(a))
+
+ deftestMultiDoNotUnwrapTwoLeaves(self):
+ e=F('a','b')
+ f=a=nor(e)
+ self.assertEqual(f,simplify(a))
+ a=nor(a)
+ self.assertEqual(e,simplify(a))
+ a=nor(a)
+ self.assertEqual(f,simplify(a))
+ a=nor(a)
+ self.assertEqual(e,simplify(a))
+ a=nor(a)
+ self.assertEqual(f,simplify(a))
+ a=nor(a)
+ self.assertEqual(e,simplify(a))
+
+# Technically, several of the tests above are redundant,
+# I'm not willing to figure out the right point ot stop
+# right now, so I just do extra tests.
+
+if__name__=='__main__':
+ unittest.main(argv=['ignored','UnwrapTest3'],exit=False)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
..
+----------------------------------------------------------------------
+Ran 2 tests in 0.003s
+
+OK
+
But now let's trick our function, it can't handle (a ((b c))) = (a b c) yet. This is going to require an auxiliary helper function that is similar to simplify() but that yields terms into an outer context.
+
+
+
+
+
+
+
+
+
+
In [52]:
+
+
+
classUnwrapTest4(unittest.TestCase):
+
+ deftestMultiUnwrapLeaf(self):
+ a,b,c='abc'
+ f=F(a,((b,c),))
+ e=F(a,b,c)
+ self.assertEqual(e,simplify(f))
+
+ deftestMulti_blah_Leaf(self):
+ a,b,c='abc'
+ f=F(a,(((b,c),),),)
+ e=F(a,(b,c))
+ self.assertEqual(e,simplify(f))
+
+ deftestMulti_blah_blah_Leaf(self):
+ a,b,c,d='abcd'
+ f=F(a,((((b,c),),d),))
+ e=F(a,b,c,d)
+ self.assertEqual(e,simplify(f))
+
+
+defsimplify(form):
+
+ # Three easy cases, for strings, Mark, or Void, just return it.
+ ifisinstance(form,basestring)orforminBASE:
+ returnform
+
+ # We know it's a Form and it's not empty (else it would be the Mark and
+ # returned above.)
+
+ result=[]
+ forinnerinsimplify_gen(form):# Use the generator instead of recursing into simplify().
+ result.append(inner)
+ result=Form(result)
+
+ # Check for ((a)) and return just a.
+ # If there is more than one item in the inner container ((a b..))
+ # then we must keep the outer containers.
+ iflen(result)==1:
+ inner,=result# inner = (a)
+ ifisinstance(inner,Form):
+ iflen(inner)==1:
+ a,=inner
+ returna
+ else:
+ # len(inner) cannot be 0, because that means form is Void
+ # and would already have been returned.
+ assertlen(inner)>1,repr(inner)
+
+ # What to do here?
+ # We cannot yield the items in inner into the containing context
+ # because we don't have it (or even know if it exists.)
+ # Therefore we need a different simplify() generator function that yields
+ # the simplified contents of a form, and we have to call that instead
+ # of recurring on simplify() above.
+ pass
+
+
+ returnresult
+
+
+defsimplify_gen(form):
+
+ forinnerinform:
+
+ inner=simplify(inner)
+ # Now inner is simplified, except for ((a b...)) which simplify() can't handle.
+
+ # Three easy cases, strings, Mark, or Void.
+ ifisinstance(inner,basestring):
+ yieldinner
+ continue
+
+ ifinner==Mark:
+ yieldinner
+ assertFalse# The simplify() function will not keep iterating after this.
+ return# Partial implementation of ()A = ().
+
+ ifinner==Void:
+ continue# Omit Void. Implementation of (()) = .
+
+ # We know it's a Form and it's not empty (else it would be the Mark and
+ # yielded above.)
+
+ # Check for ((...)) and return just ... .
+ iflen(inner)>1:# (foo bar)
+ yieldinner
+ continue
+
+ assertlen(inner)==1,repr(inner)# Just in case...
+
+ inner_inner,=inner
+ ifisinstance(inner_inner,Form):# inner_inner = (...)
+ forinner_inner_innerininner_inner:
+ yieldinner_inner_inner
+ continue
+
+ #else: # inner_inner = foo ; inner = (foo)
+
+ yieldinner
+
+
+if__name__=='__main__':
+ unittest.main(argv=['ignored','UnwrapTest4'],exit=False)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
...
+----------------------------------------------------------------------
+Ran 3 tests in 0.005s
+
+OK
+
If the Mark occurs in a sub-form it should Occlude all sibling sub-forms, rendering its container form Void.
+
+
+
+
+
+
+
+
+
+
In [53]:
+
+
+
classMarkTest0(unittest.TestCase):
+
+ deftestMarkOccludes0(self):
+ a,b,c='abc'
+ f=F(a,(),b,c)
+ self.assertEqual(Void,simplify(f))
+
+ deftestMarkOccludes1(self):
+ a,b,c='abc'
+ f=F(a,(b,c,()))
+ e=F(a)
+ self.assertEqual(e,simplify(f))
+
+ deftestMarkOccludes2(self):
+ a,b,c='abc'
+ f=F(a,(b,((),c)))
+ e=F(a,(b,))
+ self.assertEqual(e,simplify(f))
+
+
+defsimplify(form):
+
+ # Three easy cases, for strings, Mark, or Void, just return it.
+ ifisinstance(form,basestring)orforminBASE:
+ returnform
+
+ # We know it's a Form and it's not empty (else it would be the Mark and
+ # returned above.)
+
+ result=[]
+ forinnerinsimplify_gen(form):
+ ifinner==Mark:
+ returnVoid# Discard any other inner forms, form is Void.
+ result.append(inner)
+ result=Form(result)
+
+ # Check for ((a)) and return just a.
+ # If there is more than one item in the inner container ((a b..))
+ # then we must keep the outer containers.
+ iflen(result)==1:
+ inner,=result# inner = (a)
+ ifisinstance(inner,Form):
+ iflen(inner)==1:
+ a,=inner
+ returna
+
+ returnresult
+
+
+if__name__=='__main__':
+ unittest.main(argv=['ignored','MarkTest0'],exit=False)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
...
+----------------------------------------------------------------------
+Ran 3 tests in 0.004s
+
+OK
+
So we have (()) = -- and ()A = () what about A(AB) = A(B)?
+
+
+
+
+
+
+
+
+
+
In [54]:
+
+
+
classPervadeTest0(unittest.TestCase):
+
+ deftestPervade0(self):
+ a='a'
+ f=F(a,(a,))
+ self.assertEqual(Void,simplify(f))
+
+ deftestPervade1(self):
+ a='a'
+ f=F(((a,),),(a,))
+ self.assertEqual(Void,simplify(f))
+
+ deftestPervade2(self):
+ a='a'
+ b='b'
+ f=F(a,(b,(a,)))
+ e=F(a)
+ self.assertEqual(e,simplify(f))
+
+
+defsimplify(form,exclude=None):
+
+ # Three easy cases, for strings, Mark, or Void, just return it.
+ ifisinstance(form,basestring)orforminBASE:
+ returnform
+
+ # We know it's a Form and it's not empty (else it would be the Mark and
+ # returned above.)
+
+ ifexcludeisNone:
+ exclude=set()
+
+ new_stuff=form-exclude
+ exclude=exclude|new_stuff
+
+ result=[]
+ forinnerinsimplify_gen(new_stuff,exclude):
+ ifinner==Mark:
+ returnVoid# Discard any other inner forms, form is Void.
+ result.append(inner)
+ result=Form(result)
+
+ # Check for ((a)) and return just a.
+ # If there is more than one item in the inner container ((a b..))
+ # then we must keep the outer containers.
+ iflen(result)==1:
+ inner,=result# inner = (a)
+ ifisinstance(inner,Form):
+ iflen(inner)==1:
+ a,=inner
+ returna
+
+ returnresult
+
+
+defsimplify_gen(form,exclude):
+
+ forinnerinform:
+
+ inner=simplify(inner,exclude)
+ # Now inner is simplified, except for ((a b...)) which simplify() can't handle.
+
+ # Three easy cases, strings, Mark, or Void.
+ ifisinstance(inner,basestring):
+ yieldinner
+ continue
+
+ ifinner==Mark:
+ yieldinner
+ assertFalse# The simplify() function will not keep iterating after this.
+ return# Partial implementation of ()A = ().
+
+ ifinner==Void:
+ continue# Omit Void. Implementation of (()) = .
+
+ # We know it's a Form and it's not empty (else it would be the Mark and
+ # yielded above.)
+
+ # Check for ((...)) and return just ... .
+ iflen(inner)>1:# (foo bar)
+ yieldinner
+ continue
+
+ assertlen(inner)==1,repr(inner)# Just in case...
+
+ inner_inner,=inner
+ ifisinstance(inner_inner,Form):# inner_inner = (...)
+ forinner_inner_innerininner_inner:
+ yieldinner_inner_inner
+ continue
+
+ #else: # inner_inner = foo ; inner = (foo)
+
+ yieldinner
+
+
+if__name__=='__main__':
+ unittest.main(argv=['ignored','PervadeTest0'],exit=False)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
...
+----------------------------------------------------------------------
+Ran 3 tests in 0.004s
+
+OK
+
In the second case (b)...b... = (b)...()... we can modify the simplify() function to accept a name that it should treat as Mark-valued.
+
+
+
+
+
+
+
+
+
+
In [59]:
+
+
+
classMarkitTest0(unittest.TestCase):
+
+ deftestMarkit0(self):
+ a,b,c='abc'
+ f=F(a,(b,(c,)))
+ e=F(a)
+ self.assertEqual(e,simplify(f,with_mark=b))
+
+
+defsimplify(form,exclude=None,with_mark=None):
+
+ # Three easy cases, for strings, Mark, or Void, just return it.
+ ifisinstance(form,basestring)orforminBASE:
+ returnform
+
+ # We know it's a Form and it's not empty (else it would be the Mark and
+ # returned above.)
+
+ ifexcludeisNone:
+ exclude=set()
+
+ new_stuff=form-exclude
+ exclude=exclude|new_stuff
+
+ result=[]
+ forinnerinsimplify_gen(new_stuff,exclude,with_mark):
+ ifinner==Markorinner==with_mark:
+ returnVoid# Discard any other inner forms, form is Void.
+ result.append(inner)
+ result=Form(result)
+
+ # Check for ((a)) and return just a.
+ # If there is more than one item in the inner container ((a b..))
+ # then we must keep the outer containers.
+ iflen(result)==1:
+ inner,=result# inner = (a)
+ ifisinstance(inner,Form):
+ iflen(inner)==1:
+ a,=inner
+ returna
+
+ returnresult
+
+
+defsimplify_gen(form,exclude,with_mark):
+
+ forinnerinform:
+
+ inner=simplify(inner,exclude,with_mark)
+ # Now inner is simplified, except for ((a b...)) which simplify() can't handle.
+
+ # Three easy cases, strings, Mark, or Void.
+ ifisinstance(inner,basestring):
+ yieldinner
+ continue
+
+ ifinner==Markorinner==with_mark:
+ yieldMark
+ assertFalse# The simplify() function will not keep iterating after this.
+ return# Partial implementation of ()A = ().
+
+ ifinner==Void:
+ continue# Omit Void. Implementation of (()) = .
+
+ # We know it's a Form and it's not empty (else it would be the Mark and
+ # yielded above.)
+
+ # Check for ((...)) and return just ... .
+ iflen(inner)>1:# (foo bar)
+ yieldinner
+ continue
+
+ assertlen(inner)==1,repr(inner)# Just in case...
+
+ inner_inner,=inner
+ ifisinstance(inner_inner,Form):# inner_inner = (...)
+ forinner_inner_innerininner_inner:
+ ifinner_inner_inner==with_mark:
+ yieldMark
+ assertFalse# The simplify() function will not keep iterating after this.
+ return# Never reached, could delete this line.
+ yieldinner_inner_inner
+ continue
+
+ #else: # inner_inner = foo ; inner = (foo)
+
+ yieldinner
+
+
+if__name__=='__main__':
+ unittest.main(argv=['ignored','MarkitTest0'],exit=False)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
.
+----------------------------------------------------------------------
+Ran 1 test in 0.001s
+
+OK
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In [60]:
+
+
+
simplify(A,with_mark=b)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Out[60]:
+
+
+
+
+
+
(a)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Now we can create a new form that is equivalent to A.
In this particular case the original form A was so simple that the new version Ab is actually a bit larger. With a large expression to start with the form after simplification would (usually) be smaller.
((((a) (b) (c)) ((a) (b) c) ((a) (c) b) ((b) (c) a)))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
And the expressions derived from the definitions on Wikipedia:
+
+
+
+
+
+
+
+
+
+
In [65]:
+
+
+
Sum,Carry=full_bit_adder(a,b,c)
+
+
+
+
+
+
+
+
+
+
+
+
+
In [66]:
+
+
+
Sum
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Out[66]:
+
+
+
+
+
+
((((((((a) b) ((b) a)))) c) (((((a) b) ((b) a))) (c))))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In [67]:
+
+
+
Carry
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Out[67]:
+
+
+
+
+
+
((((((((a) b) ((b) a)))) (c)) ((a) (b))))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
We can use the each_way() function to look for simpler equivalent forms by, for example, iterating though the names and trying it with each. Try the following cells with both versions of the Sum and Carry above.
((((((((a) b) ((b) a)))) c) (((((a) b) ((b) a))) (c))))
+((((b) (c)) (a) (b c)) (((b) c) ((c) b) a))
+(((((a) (c)) (a c)) b) ((((a) c) ((c) a)) (b)))
+(((((a) (b)) (a b)) c) ((((a) b) ((b) a)) (c)))
+(((((b) (c)) (b c)) a) ((((b) c) ((c) b)) (a)))
+(((((a) (c)) (a c)) b) ((((a) c) ((c) a)) (b)))
+(((((a) (b)) (a b)) c) ((((a) b) ((b) a)) (c)))
+
((((((((a) b) ((b) a)))) (c)) ((a) (b))))
+((((b) (c)) a) ((a) b c))
+(((((a) c) (a)) b) ((b) a c))
+(((((b) a) (b)) c) ((c) a b))
+(((((c) b) (c)) a) ((a) b c))
+(((((a) c) (a)) b) ((b) a c))
+(((((b) a) (b)) c) ((c) a b))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Let's redefine the full_bit_adder() function with the smallest version of each above.
This is something of an Interlude, we aren't going to use it below, but it's too cool to omit mention.
+
We can use the simplify() function to create a more efficient SAT solver along the lines of the DPLL algorithm.
+
It works by selecting a name from the form, and simplifying the form with that name first as Void then as Mark, then recursing with the new form and the next name. If the resulting simplified form becomes the Mark then our choices (of assigning Void or Mark to the names selected so far) constitute a "solution" to the original form. That is, if we reify() the form with the environment returned by the dpll() function the result will be Mark-valued.
+
+
+
+
+
+
+
+
+
+
In [75]:
+
+
+
defdpll(E,partial=None,unit=True):
+ ifpartialisNone:
+ partial={}
+ else:
+ partial=partial.copy()# so we can backtrack later..
+
+ ifisinstance(E,basestring):
+ partial[E]=Mark
+ returnpartial
+
+ ifunit:
+ E=assign_unit_clauses(E,partial)
+
+ ifnotE:
+ returnpartial
+
+ ifMarkinE:
+ return
+
+ v=next_symbol_of(E)
+
+ partial[v]=Void
+
+ res=dpll(simplify(E,{v}),partial,unit)
+ ifresisnotNone:
+ returnres
+
+ partial[v]=Mark
+
+ returndpll(simplify(E,with_mark=v),partial,unit)
+
+
+defassign_unit_clauses(E,partial):
+ '''
+ Find and assign values to an "unit clauses" in the form, simplifying as you go.
+ A unit clause is a bare name or a negated name: a or (a), for these clauses we
+ can set them to Void or Mark, respectively, to contibute to making their containing
+ Form the Mark.
+ '''
+ on,off,E=find_units(E)
+ whileonoroff:
+ whileon:
+ ifon&off:returnVoid
+ term=first_of(on)
+ partial[term]=Mark
+ ON,OFF,E=find_units(simplify(E,with_mark=term))
+ on|=ON
+ on.remove(term)
+ off|=OFF
+ whileoff:
+ ifon&off:returnVoid
+ term=first_of(off)
+ partial[term]=Void
+ ON,OFF,E=find_units(simplify(E,{term}))
+ off|=OFF
+ off.remove(term)
+ on|=ON
+ returnE
+
+
+defnext_symbol_of(E):
+ ifisinstance(E,basestring):
+ returnE
+ foritinE:
+ returnnext_symbol_of(it)
+ raiseException("no more symbols")
+
+
+deffind_units(E):
+ '''
+ Return two sets and a possibly-reduced E. The literals in the first
+ set must be Void and those in the second must be set Mark to have the
+ entire expression become Void.
+ '''
+ on,off,poly=set(),set(),set()
+ forclauseinE:
+ ifisinstance(clause,basestring):
+ off.add(clause)
+ continue
+ iflen(clause)!=1:
+ poly.add(clause)
+ continue
+ (n,)=clause# Unwrap one layer of containment.
+ ifisinstance(n,basestring):
+ on.add(n)
+ else:
+ poly.add(clause)
+ returnon,off,Form(poly)
+
+
+# Return any item from a form.
+first_of=lambdaform:next(iter(form))
+
Notice that the reified form still has c in it but that doesn't prevent the simplify() function from reducing the form to the Mark. This should be the case for all solutions generated by the dpll_iter() function.
Let's have a program of named expressions that give new values when evaluated in terms of the current values in R (this is just the same CIRCUITS, but feeding back the results into the "b" bits):
Let's make a nice display function to inspect our little adder computer.
+
+
+
+
+
+
+
+
+
+
In [91]:
+
+
+
defshow_as_int(*names):
+ '''
+ Return a function that converts a sequence of
+ named bits (as Void/Mark values) into a integer.
+ '''
+ definner(register):
+ i,n=0,1
+ fornameinnames:
+ ifnotregister[name]:
+ i+=n
+ n<<=1
+ returni
+ returninner
+
Let's set one bit to true (Mark-valued in the chosen convention. We could have Void be true but we would have to form the circuit expressions differently.)
You can see that the "b" bits are indeed counting by threes: 0, 3, 6, 9, 12, 15 & carry, 2, 5, 8, 11, 14 & carry, 1, 4, 7, 10, 13 & carry, 0, 3, 6, 9, ...
+
This is my basic model for computation: A register, a program, and a cycle function. Note that reducing the form on each cycle isn't necessary, we can run the cycles and just reify() without reducing and we get new circuits that define bits in terms of the register values N cycles in the past.
# Universe
+U='ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'
+
+
+# Register.
+R={name:VoidfornameinU}
+
+
+# A program to XOR each bit with its neighbor, wrapping at the edge.
+P={
+ name:xor(name,U[(U.index(name)+1)%len(U)])
+ fornameinU
+}
+
+
+defshow(reg):
+ '''Simple visualization of the register.'''
+ print''.join('.0'[notreg[name]]fornameinU)
+
+
+# Set one "bit" in the register.
+R[U[-1]]=Mark
+
+
+# Run through some cycles.
+for_inrange(100):
+ show(R)
+ R.update(cycle(P,R))
+
Before building larger "computers" I want to switch to a more efficient implementation based on a register as a set of names that are currently Mark-valued, and a set_solve() function that evaluates a form in terms of such a set, and assuming all other names are Void-valued.
+
+
+
+
+
+
+
+
+
+
In [98]:
+
+
+
defset_solve(form,marks):
+ '''
+ Given a form and a set of names that are Marks assume all other names
+ in the form are Void and reduce to basic value (Mark or Void.)
+ '''
+ return(
+ (Void,Mark)[forminmarks]
+ ifisinstance(form,basestring)
+ else_set_solve(form,marks)
+ )
+
+
+def_set_solve(form,marks):
+ forinnerinform:
+ ifisinstance(inner,basestring):
+ ifinnerinmarks:
+ returnVoid
+ continue
+ ifnot_set_solve(inner,marks):# Mark
+ returnVoid
+ returnMark
+
To calculate the new R first collect all the names in R that are not mentioned in P (and so cannot be
+set to Void by it) then add the names evaluated by solving P's expressions with the marks in R.
# Universe
+U='ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'
+
+
+# Register.
+R={U[-1]}
+
+
+# A program to XOR each bit with its neighbor, wrapping at the edge.
+P={
+ name:xor(name,U[(U.index(name)+1)%len(U)])
+ fornameinU
+}
+
+
+defshow(reg):
+ '''Simple visualization of the register.'''
+ print''.join('.0'[nameinreg]fornameinU)
+
+
+# Run through some cycles.
+for_inrange(100):
+ show(R)
+ R=set_cycle(R,P)
+
(((a) b) (a c))
+ a b c | Value
+---------+------
+ |
+ () | ()
+ () |
+ () () | ()
+() |
+() () |
+() () | ()
+() () () | ()
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
If a is Mark-valued the value of the whole form is that of b, but if a is Void-valued the value of the whole form is that of c.
+
w/ a = ()
+
+((( a) b) ( a c))
+(((()) b) (() c))
+(( b) (() ))
+(( b) )
+ b
+
+w/ a =
+
+(((a) b) (a c))
+((( ) b) ( c))
+((( ) ) ( c))
+( ( c))
+ c
+
If both are Void then the form is just q, if r is Mark then the form is Void, otherwise if s is Mark the form becomes Mark. This is called a "flip-flop" circuit, and it comprises a simple machine to remember one bit.
+
Consider a simple computer:
+
+
+
+
+
+
+
+
+
+
In [105]:
+
+
+
U=q,r,s='qrs'
+
+P={
+ q:flip_flop(q,r,s),
+ r:Void,
+ s:Void,
+}
+
+R=set()# Initially all signals are off, Void-valued.
+
# Data register.
+DATA=['a%i'%iforiinrange(WIDTH)]
+DATA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Out[114]:
+
+
+
+
+
+
['a0', 'a1']
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
We can recognize which RAM location we want to address by using the expressions for each row from above to create a predicate for each location that depends on the ADDR bits.
(A)(...(...(... A B)))
+(A)((A)(...(... A B)))
+(A)((A)((A)(... A B)))
+(A)((A)((A)((A) A B)))
+(A)((A)((A)(( ) A B)))
+(A)((A)(...(( ) )))
+(A)(...(... ))
+
+
+
Summarized:
+
(A)(...(...(... A )))
+(A)(...(...(... () )))
+(A)(...(... ))
+
+
+
+
+
+
+
+
+
+
+
+
+
Appendix: Reduce String Expressions by Substitution¶
Given a string form of an arithmetic expression (in other words a string that consists of only balanced pairs of parentheses) we can reduce it to its Mark/Void value by substitution to a fixed-point.
+
+
+
+
+
+
+
+
+
+
In [131]:
+
+
+
# Translate the LoF Arithmetic rules to string substitution rules.
+reduce_string=lambdas:(
+ s
+ .replace('()()','()')
+ .replace('(())','')
+)
+
+
+
+
+
+
+
+
+
+
+
+
+
In [132]:
+
+
+
defto_fixed_point(initial_value,F,limit=10000):
+ '''Do value = F(value) until value == F(value).'''
+
+ next_value=F(initial_value)
+
+ whilenext_value!=initial_value:
+
+ ifnotlimit:# A safety mechanism. Bail out after N iterations.
+ raiseRuntimeError('Reached limit of allowed iterations without finding fixed point.')
+ limit-=1
+
+ initial_value=next_value
+ next_value=F(initial_value)
+
+ returninitial_value
+
The void() and mark() functions can be defined recursively in terms of each other. Note that void() uses any() while mark() uses all(). These functions implement a depth-first search. If we used versions of any() and all() that evaluated their arguments in parallel void() could return after the True result while mark() depends on all terms's results so its runtime will be bound by term with the greatest runtime.
The Void and the Mark are not Boolean true and false. Rather they correspond to non-existance and existance. When translating a traditional logical statement into Laws of Form the first thing we must do is choose which mapping we would like to use: true = Mark or true = Void. The notation works the same way once the translation is made, so the only real criteria for choosing is which gives the smaller form.
+
If you examine the truth tables for the basic forms above in light of this, you can see that each defines two logical functions depending on whether you treat Void as true and Mark as false, or Void as false and Mark as true.
+
For example, the juxtaposition of two terms next to each other a b corresponds to OR if Mark is true, and to AND if Void is true. Likewise, the form ((a)(b)) is AND if Mark is true and OR if Void is true.
+
Consider:
+
(A ∧ ¬B) ∨ (C ∧ D)
+
+
+
(This reads "(A and not B) or (C and D)" in case you have a hard time remembering what the symbols mean like I do.)
+
If we choose Mark to be true then the form is:
+
((A) B) ((C)(D))
+
+
+
If we choose Void to be true then the form is:
+
((A (B)) (C D))
+
+
+
As I said above, the notation works the same way either way, so once the translation is made you can forget about the Boolean true/false and just work with the Laws of Form rules. Logic is containers.
Consider also the De Morgan dual of the original statement:
+
¬((¬A ∨ B) ∧ (¬C ∨ ¬D))
+
+
+
If we choose Mark to be true then the form is:
+
(( ((A) B) ((C)(D)) ))
+
+
+
The outer pair of containers can be deleted leaving the same form as above:
+
((A) B) ((C)(D))
+
+
+
Likewise, if we choose Void to be true then the form is:
+
((((A)) (B)) (((C)) ((D))))
+
+
+
Again, A((B)) => AB reduces this form to the same one above:
+
((A (B)) (C D))
+
+
+
In the Laws of Form there are no De Morgan Dual statements. If you translate a logic statement and its dual into Laws of Form notation they both reduce to the same form.
+
To me this is a clear indication that the Laws of Form are superior to the traditional notation involving ¬ ∨ ∧, etc. LoF replaces all the symbols with just names and boundaries. The Laws of Form are not dualistic, they work directly in terms of existance and non-existance. Duality only comes in when you interpret the forms as Boolean statements and have to pick a mapping.
#import pprint as pp
+
+
+#E = cout
+#for var, count in histo.most_common():
+# print 'stan', var, count
+# E = to_fixed_point(simplify(standardize(E, var)), simplify)
+# print len(str(E))
+# pp.pprint(dict(Counter(yield_variables_of(E))))
+# print '------'
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Rather than manually calling standard_form() let's define a function that reduces a form to a (hopefully) smaller equivalent form by going through all the variables in the form and using standard_form() with each. Along with clean and unwrap we can drive an expression to a fixed point.
+---------------------------------------------------------------------------
+NameError Traceback (most recent call last)
+<ipython-input-140-34665b9e1d61> in <module>()
+ 1 sum0, cout = full_bit_adder('a0','b0','Cin')
+----> 2sum0 = to_fixed_point(sum0, STAN)
+ 3 cout = to_fixed_point(cout, STAN)
+ 4
+ 5 sum1, cout = full_bit_adder('a1','b1', cout)
+
+<ipython-input-132-bf263ba512a2> in to_fixed_point(initial_value, F, limit)
+ 2'''Do value = F(value) until value == F(value).'''
+ 3
+----> 4next_value = F(initial_value)
+ 5
+ 6while next_value != initial_value:
+
+<ipython-input-138-99179e550c4a> in STAN(form)
+ 1def STAN(form):
+ 2for var, _ in Counter(yield_variables_of(form)).most_common():
+----> 3form = to_fixed_point(simplify(standardize(form, var)), simplify)
+ 4return form
+
+NameError: global name 'standardize' is not defined
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
It would be useful and fun to write a simple search algorithm that tried different ways to reduce a form to see if it could find particulaly compact versions.
+
Let's generate the expressions for the next two output bits, and the carry bit.
+
+
+
+
+
+
+
+
+
+
+
+
The sum3 bit expression is pretty big.
+
+
+
+
+
+
+
+
+
+
In [ ]:
+
+
+
sum3
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
But it's only about 1/9th of size of the previous version (which was 9261.)
+
+
+
+
+
+
+
+
+
+
In [ ]:
+
+
+
len(str(sum3))
+
+
+
+
+
+
+
+
+
+
+
+
+
In [ ]:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In [ ]:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In [ ]:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In [ ]:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In [ ]:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In [ ]:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Let's simplify the first one manually just for fun:
+
(((((())) (())) ((()))))
+ (( ) ) ( )
+ ( )
+
+
+
Sure enough, it reduces to Mark after just a few applications of the rule (()) = __ (the underscores indicates the absence of any value, aka Void.) We could also just delete variables that are Void in the original expression:
∧ intersection
+∨ union
+∘ concatenation (see below)
+¬ complement
+ϕ empty set (aka ∅)
+λ singleton set containing just the empty string
+I set of all letters in alphabet
+
I'm only going to use two symbols (at first) becaase this is enough to illustrate the algorithm and because you can represent any other alphabet with two symbols (if you had to.)
+
I chose the names O and l (uppercase "o" and lowercase "L") to look like 0 and 1 (zero and one) respectively.
# R ∧ I = I ∧ R = R
+# R ∧ ϕ = ϕ ∧ R = ϕ
+_and=curry(_compaction_rule,AND,I,phi)
+
+# R ∨ ϕ = ϕ ∨ R = R
+# R ∨ I = I ∨ R = I
+_or=curry(_compaction_rule,OR,phi,I)
+
+# R∘λ = λ∘R = R
+# R∘ϕ = ϕ∘R = ϕ
+_cons=curry(_compaction_rule,CONS,y,phi)
+
We can save re-processing by remembering results we have already computed. RE datastructures are immutable and the derv() functions are pure so this is fine.
We could parse larger alphabets by defining patterns for e.g. each byte of the ASCII code. Or we can generalize this code. If you study the code above you'll see that we never use the "set-ness" of the symbols O and l. The only time Python set operators (& and |) appear is in the nully() function, and there they operate on (recursively computed) outputs of that function, never O and l.
We can drive the regular expressions to flesh out the underlying state machine transition table.
+
.111. & (.01 + 11*)'
+
+
+
Says, "Three or more 1's and not ending in 01 nor composed of all 1's."
+
+
Start at a and follow the transition arrows according to their labels. Accepting states have a double outline. (Graphic generated with Dot from Graphviz.) You'll see that only paths that lead to one of the accepting states will match the regular expression. All other paths will terminate at one of the non-accepting states.
+
+
+
+
+
+
+
+
+
+
+
+
There's a happy path to g along 111:
+
a→c→e→g
+
+
+
After you reach g you're stuck there eating 1's until you see a 0, which takes you to the i→j→i|i→j→h→i "trap". You can't reach any other states from those two loops.
+
If you see a 0 before you see 111 you will reach b, which forms another "trap" with d and f. The only way out is another happy path along 111 to h:
+
b→d→f→h
+
+
+
Once you have reached h you can see as many 1's or as many 0' in a row and still be either still at h (for 1's) or move to i (for 0's). If you find yourself at i you can see as many 0's, or repetitions of 10, as there are, but if you see just a 1 you move to j.
You can see the one-way nature of the g state and the hij "trap" in the way that the .111. on the left-hand side of the & disappears once it has been matched.
There are lots of FSM libraries already. Once you have the state transition table they should all be straightforward to use. State Machine code is very simple. Just for fun, here is an implementation in Python that imitates what "compiled" FSM code might look like in an "unrolled" form. Most FSM code uses a little driver loop and a table datastructure, the code below instead acts like JMP instructions ("jump", or GOTO in higher-level-but-still-low-level languages) to hard-code the information in the table into a little patch of branches.
With those preliminaries out of the way, from the state table of .111. & (.01 + 11*)' we can immediately write down state machine code. (You have to imagine that these are GOTO statements in C or branches in assembly and that the state names are branch destination labels.)
Reversing the Derivatives to Generate Matching Strings¶
(UNFINISHED)
+Brzozowski also shewed how to go from the state machine to strings and expressions...
+
+
+
+
+
+
+
+
+
+
+
+
Each of these states is just a name for a Brzozowskian RE, and so, other than the initial state a, they can can be described in terms of the derivative-with-respect-to-N of some other state/RE:
Look at the treatment of the Project Euler Problem One in the "Developing a Program" notebook and you'll see that we might be interested in generating an endless cycle of:
+
3 2 1 3 1 2 3
+
+
+
To do this we want to encode the numbers as pairs of bits in a single int:
(It would be more efficient to reset the int every seven cycles but that's a little beyond the scope of this article. This solution does extra work, but not much, and we're not using it "in production" as they say.)
In the PE1 problem we are asked to sum all the multiples of three and five less than 1000. It's worked out that we need to use all seven numbers sixty-six times and then four more.
+
+
+
+
+
+
+
+
+
+
In [18]:
+
+
+
J('7 66 * 4 +')
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
466
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
If we drive our generator 466 times and sum the stack we get 999.
By considering the terms in the Fibonacci sequence whose values do not exceed four million, find the sum of the even-valued terms.
+
+
Now that we have a generator for the Fibonacci sequence, we need a function that adds a term in the sequence to a sum if it is even, and pops it otherwise.
+
+
+
+
+
+
+
+
+
+
In [26]:
+
+
+
define('PE2.1 == dup 2 % [+] [pop] branch')
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
And a predicate function that detects when the terms in the series "exceed four million".
+
+
+
+
+
+
+
+
+
+
In [27]:
+
+
+
define('>4M == 4000000 >')
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Now it's straightforward to define PE2 as a recursive function that generates terms in the Fibonacci sequence until they exceed four million and sums the even ones.
As a concrete example let's use a function that, given a positive integer, returns the sum of all positive integers less than that one. (In this case the types A and B are both int.)
If you were to run the above code in a debugger and check out the call stack you would find that the variable b in each call to H() is storing the intermediate values as H() recurses. This is what was meant by "call stack in the form of a cons list".
We can define a combinator hylomorphism that will make a hylomorphism combinator H from constituent parts.
+
H == c [F] [P] [G] hylomorphism
+
+
+
The function H is recursive, so we start with ifte and set the else-part to
+some function J that will contain a quoted copy of H. (The then-part just
+discards the leftover a and replaces it with the base case value c.)
+
H == [P] [pop c] [J] ifte
+
+
+
The else-part J gets just the argument a on the stack.
+
a J
+a G The first thing to do is use the generator G
+aa b which produces b and a new aa
+aa b [H] dip we recur with H on the new aa
+aa H b F and run F on the result.
+
+
The order of parameters is different than the one we started with but
+that hardly matters, you can rearrange them or just supply them in the
+expected order.
(We could also have just substituted for c and F in the definition of H.)
+
H == [P] [pop c ] [G] [dip F ] genrec
+A == [P] [pop []] [G] [dip swons] genrec
+
+
+
The partial evaluation is overkill in this case but it serves as a
+reminder that this sort of program specialization can, in many cases, be
+carried out automatically.)
+
Untangle [G] from [pop []] using swap.
+
[P] [G] [pop []] swap [dip swons] genrec
+
+
+
All of the arguments to anamorphism are to the left, so we have a definition for it.
Because the arguments to catamorphism have to be prepared (unlike the arguments
+to anamorphism, which only need to be rearranged slightly) there isn't much point
+to "pre-cooking" the definition.
I'm not sure exactly how to translate the "Fusion Law" for catamorphisms into Joy.
+
I know that a map composed with a cata can be expressed as a new cata:
+
[F] map b [B] cata == b [F B] cata
+
+
+
But this isn't the one described in "Bananas...". That's more like:
+
A cata composed with some function can be expressed as some other cata:
+
b [B] catamorphism F == c [C] catamorphism
+
+
+
Given:
+
b F == c
+
+...
+
+B F == [F] dip C
+
+...
+
+b[B]cata F == c[C]cata
+
+F(B(head, tail)) == C(head, F(tail))
+
+1 [2 3] B F 1 [2 3] F C
+
+
+b F == c
+B F == F C
+
+b [B] catamorphism F == c [C] catamorphism
+b [B] catamorphism F == b F [C] catamorphism
+
+...
+
+
+
Or maybe,
+
[F] map b [B] cata == c [C] cata ???
+
+[F] map b [B] cata == b [F B] cata I think this is generally true, unless F consumes stack items
+ instead of just transforming TOS. Of course, there's always [F] unary.
+b [F] unary [[F] unary B] cata
+
+[10 *] map 0 swap [+] step == 0 swap [10 * +] step
+
+
+
+
For example:
+
F == 10 *
+b == 0
+B == +
+c == 0
+C == F +
+
+b F == c
+0 10 * == 0
+
+B F == [F] dip C
++ 10 * == [10 *] dip F +
++ 10 * == [10 *] dip 10 * +
+
+n m + 10 * == 10(n+m)
+
+n m [10 *] dip 10 * +
+n 10 * m 10 * +
+10n m 10 * +
+10n 10m +
+10n+10m
+
+10n+10m = 10(n+m)
+
+
An anamorphism followed by (composed with) a
+catamorphism is a hylomorphism, with the advantage that the hylomorphism
+does not create the intermediate list structure. The values are stored in
+either the call stack, for those implementations that use one, or in the pending
+expression ("continuation") for the Joypy interpreter. They still have to
+be somewhere, converting from an anamorphism and catamorphism to a hylomorphism
+just prevents using additional storage and doing additional processing.
There's no way to do that with the paramorphism combinator as defined. We would have to write and use a slightly different recursion combinator that accepted an additional "preprocessor" function [H] and built:
+
n swap [P] [pop] [H [F] dupdip G] primrec
+
+
+
Or just write it out manually. This is yet another place where the sufficiently smart compiler will one day automatically refactor the code. We could write a paramorphism combinator that checked [F] and [G] for common prefix and extracted it.
There are at least four kinds of recursive combinator, depending on two choices. The first choice is whether the combiner function should be evaluated during the recursion or pushed into the pending expression to be "collapsed" at the end. The second choice is whether the combiner needs to operate on the current value of the datastructure or the generator's output.
... a [P] [pop c] [G] [dip F] genrec
+... a G [H] dip F
+... a' b [H] dip F
+... a' H b F
+... a' G [H] dip F b F
+... a'' b [H] dip F b F
+... a'' H b F b F
+... a'' G [H] dip F b F b F
+... a''' b [H] dip F b F b F
+... a''' H b F b F b F
+... a''' pop c b F b F b F
+... c b F b F b F
+
+
+
This form builds up a continuation that contains the intermediate results along with the pending combiner functions. When the base case is reached the last term is replaced by the identity value c and the continuation "collapses" into the final result.
When you can start with the identity value c on the stack and the combiner can operate as you go, using the intermediate results immediately rather than queuing them up, use this form. An important difference is that the generator function must return its results in the reverse order.
+
H == c swap [P] [pop] [G [F] dip] primrec
+
+... c a G [F] dip H
+... c b a' [F] dip H
+... c b F a' H
+... c b F a' G [F] dip H
+... c b F b a'' [F] dip H
+... c b F b F a'' H
+... c b F b F a'' G [F] dip H
+... c b F b F b a''' [F] dip H
+... c b F b F b F a''' H
+... c b F b F b F a''' pop
+... c b F b F b F
+
+
+
The end line here is the same as for above, but only because we didn't evaluate F when it normally would have been.
If the combiner and the generator both need to work on the current value then dup must be used at some point, and the generator must produce one item instead of two (the b is instead the duplicate of a.)
+
H == [P] [pop c] [[G] dupdip] [dip F] genrec
+
+... a [G] dupdip [H] dip F
+... a G a [H] dip F
+... a' a [H] dip F
+... a' H a F
+... a' [G] dupdip [H] dip F a F
+... a' G a' [H] dip F a F
+... a'' a' [H] dip F a F
+... a'' H a' F a F
+... a'' [G] dupdip [H] dip F a' F a F
+... a'' G a'' [H] dip F a' F a F
+... a''' a'' [H] dip F a' F a F
+... a''' H a'' F a' F a F
+... a''' pop c a'' F a' F a F
+... c a'' F a' F a F
+
And, last but not least, if you can combine as you go, starting with c, and the combiner needs to work on the current item, this is the form:
+
W == c swap [P] [pop] [[F] dupdip G] primrec
+
+... a c swap [P] [pop] [[F] dupdip G] primrec
+... c a [P] [pop] [[F] dupdip G] primrec
+... c a [F] dupdip G W
+... c a F a G W
+... c a F a' W
+... c a F a' [F] dupdip G W
+... c a F a' F a' G W
+... c a F a' F a'' W
+... c a F a' F a'' [F] dupdip G W
+... c a F a' F a'' F a'' G W
+... c a F a' F a'' F a''' W
+... c a F a' F a'' F a''' pop
+... c a F a' F a'' F
+
+
+
+
+
+
+
+
+
+
+
+
+
Each of the four variations above can be specialized to ana- and catamorphic forms.
!- != % & && * + ++ - -- / // /floor < << <<{} <= <> <{} = > >= >> ? ^ _Tree_add_Ee _Tree_delete_R0 _Tree_delete_clear_stuff _Tree_get_E _map0 _map1 _map2 _map? _mape _step0 _step1 _stept _times0 _times1 _timest abs add anamorphism and app1 app2 app3 appN at average b binary bool branch ccccons ccons choice clear cleave clop cmp codi codireco concat cond cons dinfrirst dip dipd dipdd disenstacken div divmod down_to_zero drop dup dupd dupdd dupdip dupdipd enstacken eq first first_two flatten floor floordiv fork fourth gcd gcd2 ge genrec getitem grabN grba gt help hypot i id ifte ii infra infrst inscribe le loop lshift lt make_generator map max min mod modulus mul ne neg not nulco nullary of or over pam pick pm pop popd popdd popop popopd popopdd popopop pow pred primrec product quoted range range_to_zero reco rem remainder remove rest reverse roll< roll> rolldown rollup round rrest rshift run second select sharing shift shunt size sort spiral_next split_at split_list sqr sqrt stack stackd step step_zero stuncons stununcons sub succ sum swaack swap swapd swoncat swons tailrec take ternary third times trace truthy tuck unary uncons unique unit unquoted unswons void warranty while words x xor zip || •
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
trace is only loaded in the pretty_printer.py module, so it's not automatically included in the dictionary in the kernel.
+
Stdout is also not captured and returned to the notebook. (So words doesn't work, for example, and neither would trace if it was available, I imagine.)
+
Also, exceptions (like trace not being found in the dictionary) lead to the kernal "hanging" in the sense that you just see the "pending computation" asterix in the notebook cell.
+
This would seem to indicate that I should polish the Joy kernel, eh?
Given the predicate function (and a filter function, to be defined later) a suitable program is:
+
1000 range [[3 % not] [5 % not] fork or] filter sum
+
+
+
+
+
+
+
+
+
+
+
+
+
This function generates a list of the integers from 0 to 999, filters that list by the predicate, and then sums the result.
+
Logically this is fine, but pragmatically we are doing more work than we should. We generate one thousand integers but actually use less than half of them. A better solution would be to generate just the multiples we want to sum, and to add them as we go rather than storing them and adding summing them at the end.
+
+
+
+
+
+
+
+
+
+
+
+
Consider the first few terms in the series:
+
3 5 6 9 10 12 15 18 20 21 ...
+
+
+
Subtract each number from the one after it (subtracting 0 from 3):
You get this lovely repeating palindromic sequence:
+
3 2 1 3 1 2 3
+
+
+
To make a counter that increments by factors of 3 and 5 you just add
+these differences to the counter one-by-one in a loop.
+
+
+
+
+
+
+
+
+
+
+
+
To make use of this sequence to increment a counter and sum terms as we go we need a function that will accept the sum, the counter, and the next term to add, and that adds the term to the counter and a copy of the counter to the running sum. This function will do that:
This form uses no extra storage and produces no unused summands. It's good but there's one more trick we can apply. The list of seven terms takes up at least seven bytes. But notice that all of the terms are less than four, and so each can fit in just two bits. We could store all seven terms in just fourteen bits and use masking and shifts to pick out each term as we go. This will use less space and save time loading whole integer terms from the list.
+
3 2 1 3 1 2 3
+0b 11 10 01 11 01 10 11 == 14811
+
+
+
+
+
+
+
+
+
+
+
In [28]:
+
+
+
clear 14811
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
14811
+
+
+
+
+
+
+
+
+
+
+
+
+
In [29]:
+
+
+
[3 &] [2 >>] cleave
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
3 3702
+
+
+
+
+
+
+
+
+
+
+
+
+
In [30]:
+
+
+
[3 &] [2 >>] cleave
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
3 2 925
+
+
+
+
+
+
+
+
+
+
+
+
+
In [31]:
+
+
+
[3 &] [2 >>] cleave
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
3 2 1 231
+
+
+
+
+
+
+
+
+
+
+
+
+
In [32]:
+
+
+
[3 &] [2 >>] cleave
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
3 2 1 3 57
+
+
+
+
+
+
+
+
+
+
+
+
+
In [33]:
+
+
+
[3 &] [2 >>] cleave
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
3 2 1 3 1 14
+
+
+
+
+
+
+
+
+
+
+
+
+
In [34]:
+
+
+
[3 &] [2 >>] cleave
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
3 2 1 3 1 2 3
+
+
+
+
+
+
+
+
+
+
+
+
+
In [35]:
+
+
+
[3 &] [2 >>] cleave
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
3 2 1 3 1 2 3 0
+
+
+
+
+
+
+
+
+
+
+
+
+
In [36]:
+
+
+
[3 &] [2 >>] cleave
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
3 2 1 3 1 2 3 0 0
+
+
+
+
+
+
+
+
+
+
+
+
+
In [37]:
+
+
+
[3 &] [2 >>] cleave
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
3 2 1 3 1 2 3 0 0 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
We can run it in a loop...
+
+
+
+
+
+
+
+
+
+
In [38]:
+
+
+
clear 14811
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
14811
+
+
+
+
+
+
+
+
+
+
+
+
+
In [39]:
+
+
+
? [[3 &] [2 >>] cleave ?] loop pop
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
3 2 1 3 1 2 3
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
?
+
+
+
+
+
+
+
+
+
+
In [40]:
+
+
+
clear 0 0 14811
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
0 0 14811
+
+
+
+
+
+
+
+
+
+
+
+
+
In [41]:
+
+
+
[3 &] [2 >>] cleave
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
0 0 3 3702
+
+
+
+
+
+
+
+
+
+
+
+
+
In [42]:
+
+
+
[+ [+] dupdip] dip
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
3 3 3702
+
+
+
+
+
+
+
+
+
+
+
+
+
In [43]:
+
+
+
[3 &] [2 >>] cleave
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
3 3 2 925
+
+
+
+
+
+
+
+
+
+
+
+
+
In [44]:
+
+
+
[+ [+] dupdip] dip
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
8 5 925
+
+
+
+
+
+
+
+
+
+
+
+
+
In [45]:
+
+
+
[3 &] [2 >>] cleave [+ [+] dupdip] dip
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
14 6 231
+
+
+
+
+
+
+
+
+
+
+
+
+
In [46]:
+
+
+
[3 &] [2 >>] cleave [+ [+] dupdip] dip
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
23 9 57
+
+
+
+
+
+
+
+
+
+
+
+
+
In [47]:
+
+
+
[3 &] [2 >>] cleave [+ [+] dupdip] dip
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
33 10 14
+
+
+
+
+
+
+
+
+
+
+
+
+
In [48]:
+
+
+
[3 &] [2 >>] cleave [+ [+] dupdip] dip
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
45 12 3
+
+
+
+
+
+
+
+
+
+
+
+
+
In [49]:
+
+
+
[3 &] [2 >>] cleave [+ [+] dupdip] dip
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
60 15 0
+
+
+
+
+
+
+
+
+
+
+
+
+
In [ ]:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In [50]:
+
+
+
clear 0 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
0 0
+
+
+
+
+
+
+
+
+
+
+
+
+
In [51]:
+
+
+
14811 7 [[3 &] [2 >>] cleave [+ [+] dupdip] dip] times pop
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
60 15
+
+
+
+
+
+
+
+
+
+
+
+
+
In [52]:
+
+
+
14811 7 [[3 &] [2 >>] cleave [+ [+] dupdip] dip] times pop
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
225 30
+
+
+
+
+
+
+
+
+
+
+
+
+
In [ ]:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In [53]:
+
+
+
clear 0 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
0 0
+
+
+
+
+
+
+
+
+
+
+
+
+
In [54]:
+
+
+
66 [14811 7 [[3 &] [2 >>] cleave [+ [+] dupdip] dip] times pop] times
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
229185 990
+
+
+
+
+
+
+
+
+
+
+
+
+
In [55]:
+
+
+
14811 4 [[3 &] [2 >>] cleave [+ [+] dupdip] dip] times pop
+
To make a generator that generates successive approximations let’s start by assuming an initial approximation and then derive the function that computes the next approximation:
This is the equation for computing the next approximate value of the square root:
+
$a_{i+1} = \frac{(a_i+\frac{n}{a_i})}{2}$
+
+
+
+
+
+
+
+
+
+
+
+
Starting with $\frac{(a_i+\frac{n}{a_i})}{2}$ we can derive the Joy expression to compute it using abstract dummy variables to stand in for actual values. First undivide by two:
+
$(a_i+\frac{n}{a_i})$ 2 /
+
+
+
+
+
+
+
+
+
+
+
+
Then unadd terms:
+
$a_i$ $\frac{n}{a_i}$ + 2 /
+
+
+
+
+
+
+
+
+
+
+
+
Undivide again:
+
$a_i$ $n$ $a_i$ / + 2 /
+
+
+
+
+
+
+
+
+
+
+
+
Finally deduplicate the $a_i$ term:
+
$a_i$ $n$ over / + 2 /
+
+
+
+
+
+
+
+
+
+
+
+
Let's try out this function over / + 2 / on an example:
+
F == over / + 2 /
+
+
+
+
+
+
+
+
+
+
+
In [1]:
+
+
+
[F over / + 2 /] inscribe
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In order to use this function F we have to provide an initial estimate for the value of the square root, and we want to keep the input value n handy for iterations (we don't want the user to have to keep reentering it.)
The remainder of a square root finder is a function within, which takes a tolerance and a list of approximations and looks down the list for two successive approximations that differ by no more than the given tolerance.
+
+
(And note that by “list” he means a lazily-evaluated list.)
+
Using the output[a G] of the above generator for square root approximations, and further assuming that the first term a has been generated already and epsilon ε is handy on the stack...
+
a [b G] ε within
+---------------------- a b - abs ε <=
+ b
+
+
+ a [b G] ε within
+---------------------- a b - abs ε >
+ b [c G] ε within
+
+
Although any expression in Joy can be considered to describe a tree with the quotes as compound nodes and the non-quote values as leaf nodes, in this page I want to talk about ordered binary trees and how to make and use them.
That says that a Tree is either the empty quote [] or a quote with four items: a key, a value, and two Trees representing the left and right branches of the tree.
+
+
+
+
+
+
+
+
+
+
+
+
We're going to derive some recursive functions to work with such datastructures:
Once these functions are defined we have a new "type" to work with, and the Sufficiently Smart Compiler can be modified to use an optimized implementation under the hood. (Where does the "type" come from? It has a contingent existence predicated on the disciplined use of these functions on otherwise undistinguished Joy datastructures.)
value key Tree-new
+------------------------
+ [key value [] []]
+
+
+
Example:
+
value key swap [[] []] cons cons
+key value [[] []] cons cons
+key [value [] []] cons
+ [key value [] []]
+
+
+
Definition:
+
Tree-new == swap [[] []] cons cons
+
+
+
+
+
+
+
+
+
+
+
In [2]:
+
+
+
define('Tree-new == swap [[] []] cons cons')
+
+
+
+
+
+
+
+
+
+
+
+
+
In [3]:
+
+
+
J('"v" "k" Tree-new')
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
['k' 'v' [] []]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
(As an implementation detail, the [[] []] literal used in the definition of Tree-new will be reused to supply the constant tail for all new nodes produced by it. This is one of those cases where you get amortized storage "for free" by using persistent datastructures. Because the tail, which is ((), ((), ())) in Python, is immutable and embedded in the definition body for Tree-new, all new nodes can reuse it as their own tail without fear that some other code somewhere will change it.)
[key_n value_n left right] value key R0 [Tree-add] R1
+
+
+
In this case, there are three possibilites: the key can be greater or less than or equal to the node's key. In two of those cases we will need to apply a copy of Tree-add, so R0 is pretty much out of the picture.
[key_n value_n left right] value key [BTree-add] R1
+
+
+
The first thing we need to do is compare the the key we're adding to the node key and branch accordingly:
+
[key_n value_n left right] value key [BTree-add] [P] [T] [E] ifte
+
+
+
That would suggest something like:
+
[key_n value_n left right] value key [BTree-add] P
+[key_n value_n left right] value key [BTree-add] pop roll> pop first >
+[key_n value_n left right] value key roll> pop first >
+key [key_n value_n left right] value roll> pop first >
+key key_n >
+Boolean
+
+
+
Let's abstract the predicate just a little to let us specify the comparison operator:
+
P > == pop roll> pop first >
+P < == pop roll> pop first <
+P == pop roll> pop first
+
If the key we're adding is greater than the node's key.¶
Here the parentheses are meant to signify that the expression is not literal, the code in the parentheses is meant to have been evaluated:
+
[key_n value_n left right] value key [Tree-add] T
+-------------------------------------------------------
+ [key_n value_n left (Tree-add key value right)]
+
+
+
+
+
+
+
+
+
+
+
+
+
So how do we do this? We're going to want to use infra on some function K that has the key and value to work with, as well as the quoted copy of Tree-add to apply somehow. Considering the node as a stack:
+
right left value_n key_n value key [Tree-add] K
+-----------------------------------------------------
+ right value key Tree-add left value_n key_n
+
+
+
Pretty easy:
+
right left value_n key_n value key [Tree-add] cons cons dipdd
+right left value_n key_n [value key Tree-add] dipdd
+right value key Tree-add left value_n key_n
+
+
+
So:
+
K == cons cons dipdd
+
+
+
Looking at it from the point-of-view of the node as node again:
+
[key_n value_n left right] [value key [Tree-add] K] infra
+
+
+
Expand K and evaluate a little:
+
[key_n value_n left right] [value key [Tree-add] K] infra
+[key_n value_n left right] [value key [Tree-add] cons cons dipdd] infra
+[key_n value_n left right] [[value key Tree-add] dipdd] infra
+
+
+
Then, working backwards:
+
[key_n value_n left right] [[value key Tree-add] dipdd] infra
+[key_n value_n left right] [value key Tree-add] [dipdd] cons infra
+[key_n value_n left right] value key [Tree-add] cons cons [dipdd] cons infra
+
If the key we're adding is less than the node's key.¶
This is very very similar to the above:
+
[key_n value_n left right] value key [Tree-add] E
+[key_n value_n left right] value key [Tree-add] [P <] [Te] [Ee] ifte
+
+
+
+
+
+
+
+
+
+
+
In [8]:
+
+
+
define('E == [P <] [Te] [Ee] ifte')
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In this case Te works that same as T but on the left child tree instead of the right, so the only difference is that it must use dipd instead of dipdd:
Instead of mucking about with nested ifte combinators let's use cmp which takes two values and three quoted programs on the stack and runs one of the three depending on the results of comparing the two values:
+
a b [G] [E] [L] cmp
+------------------------- a > b
+ G
+
+ a b [G] [E] [L] cmp
+------------------------- a = b
+ E
+
+ a b [G] [E] [L] cmp
+------------------------- a < b
+ L
+
[node_key node_value left right] value key [Tree-add] P
+------------------------------------------------------------------------
+ [node_key node_value left right] value key [Tree-add] key node_key
+
+
+
+
+
+
+
+
+
+
+
+
+
Let's start with over to get a copy of the key and then apply some function Q with the nullary combinator so it can dig out the node key (by throwing everything else away):
+
P == over [Q] nullary
+
+[node_key node_value left right] value key [Tree-add] over [Q] nullary
+[node_key node_value left right] value key [Tree-add] key [Q] nullary
+
+
+
+
+
+
+
+
+
+
+
+
+
And Q would be:
+
Q == popop popop first
+
+[node_key node_value left right] value key [Tree-add] key Q
+[node_key node_value left right] value key [Tree-add] key popop popop first
+[node_key node_value left right] value key popop first
+[node_key node_value left right] first
+ node_key
+
[node_key node_value left right] value key [Tree-add] R1
+[node_key node_value left right] value key [Tree-add] P [T] [E] [Te] cmp
+
+
+
+
+
+
+
+
+
+
+
+
+
The line above becomes one of the three lines below:
+
[node_key node_value left right] value key [Tree-add] T
+[node_key node_value left right] value key [Tree-add] E
+[node_key node_value left right] value key [Tree-add] Te
+
+
+
+
+
+
+
+
+
+
+
+
+
The definition is a little longer but, I think, more elegant and easier to understand:
R0 is almost certainly going to use dup to make a copy of the node and then dip on some function to process the copy with it:
+
[key value left right] [F] dupdip [Tree-iter] R1
+[key value left right] F [key value left right] [Tree-iter] R1
+
+
+
For example, if we're getting all the keys F would be first:
+
R0 == [first] dupdip
+
+[key value left right] [first] dupdip [Tree-iter] R1
+[key value left right] first [key value left right] [Tree-iter] R1
+key [key value left right] [Tree-iter] R1
+
Now R1 needs to apply [Tree-iter] to left and right. If we drop the key and value from the node using rest twice we are left with an interesting situation:
+
key [key value left right] [Tree-iter] R1
+key [key value left right] [Tree-iter] [rest rest] dip
+key [key value left right] rest rest [Tree-iter]
+key [left right] [Tree-iter]
+
+
We can use this to make a set-like datastructure by just setting values to e.g. 0 and ignoring them. It's set-like in that duplicate items added to it will only occur once within it, and we can query it in $O(\log_2 N)$ time.
A Version of Tree-iter that does In-Order Traversal¶
+
+
+
+
+
+
+
+
+
+
+
If you look back to the non-empty case of the Tree-iter function we can design a variant that first processes the left child, then the current node, then the right child. This will allow us to traverse the tree in sort order.
Staring at this for a bit suggests dup third to start:
+
[key value left right] R0 [Tree-iter-order] R1
+[key value left right] dup third [Tree-iter-order] R1
+[key value left right] left [Tree-iter-order] R1
+
+
+
+
+
+
+
+
+
+
+
+
+
Now maybe:
+
[key value left right] left [Tree-iter-order] [cons dip] dupdip
+[key value left right] left [Tree-iter-order] cons dip [Tree-iter-order]
+[key value left right] [left Tree-iter-order] dip [Tree-iter-order]
+left Tree-iter-order [key value left right] [Tree-iter-order]
+
So far, so good. Now we need to process the current node's values:
+
left Tree-iter-order [key value left right] [Tree-iter-order] [[F] dupdip] dip
+left Tree-iter-order [key value left right] [F] dupdip [Tree-iter-order]
+left Tree-iter-order [key value left right] F [key value left right] [Tree-iter-order]
+
+
+
If F needs items from the stack below the left stuff it should have cons'd them before beginning maybe? For functions like first it works fine as-is.
+
left Tree-iter-order [key value left right] first [key value left right] [Tree-iter-order]
+left Tree-iter-order key [key value left right] [Tree-iter-order]
+
Let's derive a function that accepts a tree and a key and returns the value associated with that key.
+
tree key Tree-get
+-----------------------
+ value
+
+
+
But what do we do if the key isn't in the tree? In Python we might raise a KeyError but I'd like to avoid exceptions in Joy if possible, and here I think it's possible. (Division by zero is an example of where I think it's probably better to let Python crash Joy. Sometimes the machinery fails and you have to "stop the line", I think.)
+
Let's pass the buck to the caller by making the base case a given, you have to decide for yourself what [E] should be.
+
tree key [E] Tree-get
+---------------------------- key in tree
+ value
+
+ tree key [E] Tree-get
+---------------------------- key not in tree
+ [] key E
+
As before, the stopping predicate just has to detect the empty list:
+
Tree-get == [pop not] [E] [R0] [R1] genrec
+
+
+
So we define:
+
Tree-get == [pop not] swap [R0] [R1] genrec
+
+
+
Note that this Tree-get creates a slightly different function than itself and that function does the actual recursion. This kind of higher-level programming is unusual in most languages but natural in Joy.
We want to compare the search key with the key in the node, and if they are the same return the value, otherwise recur on one of the child nodes. So it's very similar to the above funtion, with [R0] == [] and R1 == P [T>] [E] [T<] cmp:
+
[key value left right] key [BTree-get] P [T>] [E] [T<] cmp
+
The cases of T> and T< are similar to above but instead of using infra we have to discard the rest of the structure:
+
[key_n value_n left right] key [BTree-get] T>
+---------------------------------------------------
+ right key BTree-get
+
+
+
And:
+
[key_n value_n left right] key [BTree-get] T<
+---------------------------------------------------
+ left key BTree-get
+
+
+
So:
+
T> == [fourth] dipd i
+T< == [third] dipd i
+
+
+
E.g.:
+
[key_n value_n left right] key [BTree-get] [fourth] dipd i
+[key_n value_n left right] fourth key [BTree-get] i
+ right key [BTree-get] i
+ right key BTree-get
+
fourth == rest rest rest first
+get-node-key == pop popop first
+P == over [get-node-key] nullary
+T> == [fourth] dipd i
+T< == [third] dipd i
+E == popop second
+
+Tree-get == [pop not] swap [] [P [T>] [E] [T<] cmp] genrec
+
+
+
+
+
+
+
+
+
+
+
In [37]:
+
+
+
# I don't want to deal with name conflicts with the above so I'm inlining everything here.
+# The original Joy system has "hide" which is a meta-command which allows you to use named
+# definitions that are only in scope for a given definition. I don't want to implement
+# that (yet) so...
+
+
+define('''
+Tree-get == [pop not] swap [] [
+ over [pop popop first] nullary
+ [[fourth] dipd i]
+ [popop second]
+ [[third] dipd i]
+ cmp
+ ] genrec
+''')
+
+
+
+
+
+
+
+
+
+
+
+
+
In [38]:
+
+
+
J('["gary" 23 [] []] "mike" [popd " not in tree" +] Tree-get')
+
Now we get to figure out the recursive case. We need the node's key to compare and we need to carry the key into recursive branches. Let D be shorthand for Tree-Delete:
+
D == Tree-Delete == [pop not] [pop] [R0] [R1] genrec
+
+[node_key node_value left right] key R0 [D] R1
+[node_key node_value left right] key over first swap dup [D] cons R1′
+[node_key node_value left right] key [...] first swap dup [D] cons R1′
+[node_key node_value left right] key node_key swap dup [D] cons R1′
+[node_key node_value left right] node_key key dup [D] cons R1′
+[node_key node_value left right] node_key key key [D] cons R1′
+[node_key node_value left right] node_key key [key D] R1′
+
If both child nodes are non-empty, we find the highest node in our lower sub-tree, take its key and value to replace (delete) our own, then get rid of it by recursively calling delete() on our lower sub-node with our new key.
+
(We could also find the lowest node in our higher sub-tree and take its key and value and delete it. I only implemented one of these two symmetrical options. Over a lot of deletions this might make the tree more unbalanced. Oh well.)
+
+
+
+
+
+
+
+
+
+
+
+
The initial structure of the default function:
+
default == [E′] cons infra
+
+[node_key node_value left right] [key D] default
+[node_key node_value left right] [key D] [E′] cons infra
+[node_key node_value left right] [[key D] E′] infra
+
+right left node_value node_key [key D] E′
+
+
+
+
+
+
+
+
+
+
+
+
+
First things first, we no longer need this node's key and value:
+
right left node_value node_key [key D] roll> popop E″
+right left [key D] node_value node_key popop E″
+right left [key D] E″
+
+
+
+
+
+
+
+
+
+
+
+
+
We have to we find the highest (right-most) node in our lower (left) sub-tree:¶
right left [key D] E″
+
+
+
+
+
+
+
+
+
+
+
+
+
Ditch the key:
+
right left [key D] rest E‴
+right left [D] E‴
+
+
+
+
+
+
+
+
+
+
+
+
+
Find the right-most node:
+
right left [D] [dup W] dip E⁗
+right left dup W [D] E⁗
+right left left W [D] E⁗
+
+
+
+
+
+
+
+
+
+
+
+
+
Consider:
+
left W
+
+
+
+
+
+
+
+
+
+
+
+
+
We know left is not empty:
+
[L_key L_value L_left L_right] W
+
+
+
+
+
+
+
+
+
+
+
+
+
We want to keep extracting the right node as long as it is not empty:
+
W.rightmost == [P] [B] while
+
+left W.rightmost W′
+
-b ± sqrt(b^2 - 4 * a * c)
+--------------------------------
+ 2 * a
+
+
+
+
+
+
+
+
+
+
+
+
+
$\frac{-b \pm \sqrt{b^2 - 4ac}}{2a}$
+
+
+
+
+
+
+
+
+
+
+
+
Write a straightforward program with variable names.¶
This math translates to Joy code in a straightforward manner. We are going to use named variables to keep track of the arguments, then write a definition without them.
If you look at the Joy evaluation trace you can see that the first few lines are the dip and dipd combinators building the main program by incorporating the values on the stack. Then that program runs and you get the results. This is pretty typical of Joy code.
This article describes the genrec combinator and how to use it, and then gives several specializations.
+The genrec combinator isn't the only way to make recursive functions in Joy, you can also use the x combinator with a branch to create recursive functions. (Because definitions aren't checked for self-reference you can also define recursive functions directly in definitions, but this, I believe, should be considered bad form.)
In Joy recursive functions are defined by the genrec combinator which accepts four quoted programs:
+
F == [if] [then] [rec1] [rec2] genrec
+
+
+
This can be thought of as transforming into an "if..then..else" expression using the ifte combinator and containing a quoted copy of itself in the "else" branch:
"The genrec combinator takes four program parameters in addition to
+
+
whatever data parameters it needs. Fourth from the top is an if-part,
+followed by a then-part. If the if-part yields true, then the then-part
+is executed and the combinator terminates. The other two parameters are
+the rec1-part and the rec2-part. If the if-part yields false, the
+rec1-part is executed. Following that the four program parameters and
+the combinator are again pushed onto the stack bundled up in a quoted
+form. Then the rec2-part is executed, where it will find the bundled
+form. Typically it will then execute the bundled form, either with i or
+with app2, or some other combinator."
+
It's a fantastic paper and if you like this you should really go read that.
+This notebook is much lighter.
+We're going to look at things from the point-of-view of the "Bananas, Lenses, & Barbed Wire" paper, all about hylomorphisms, anamorphisms, catamorphisms, etc.
A hylomorphism is a recursive function H that converts a value of type 𝔸 into a value of type ℂ by means of:
+
+
A generator G from 𝔸 to (𝔹, 𝔸)
+
A combiner Q from (𝔹, ℂ) to ℂ
+
A predicate P from 𝔸 to Bool to detect the base case
+
A base case value c of type ℂ, and
+
Recursive calls (zero or more); it has a "call stack in the form of a cons list".
+
+
It may be helpful to see this function implemented in pseudocode (Python).
+
def hylomorphism(c, Q, P, G):
+ '''Return a hylomorphism function H.'''
+
+ def H(a):
+ if P(a):
+ return c
+ b, aa = G(a)
+ return Q(b, H(aa))
+
+ return H
+
+
+
Note that during evaluation of H() the intermediate b values are stored in the Python call stack. This is what is meant by "call stack in the form of a cons list".
We can define a combinator hylomorphism that will make a hylomorphism combinator H from constituent parts. (The reason for the order of the parameters will become clear below):
+
H == [P] c [G] [Q] hylomorphism
+
+
+
The function H is recursive, so we start with ifte and set the else-part to some function J that will contain a quoted copy of H.
+The then-part just discards the leftover a and replaces it with the base case value c:
+
H == [P] [pop c] [J] ifte
+
+
+
The else-part J gets just the argument a on the stack.
+
a J
+
+
+
The first thing to do is use the generator G which produces values b and a new a′:
+
a G
+----------
+ a′ b
+
+
+
So:
+
J == G J′
+
+
+
Then we recur with H on a′:
+
a′ b [H] dip
+------------------
+ a′ H b
+------------------
+ c′ b
+
+
Let's write a function that, given a positive integer, returns the sum of all positive integers less than that one. (In this case the types 𝔸, 𝔹 and ℂ are all int.)
a hylomorphism is a recursive function, corresponding to the composition of an anamorphism (which first builds a set of results; also known as 'unfolding') followed by a catamorphism (which then folds these results into a final return value).
A catamorphic function tears down a list term-by-term and makes some new value.
+It can be defined as a hylomorphism that uses [uncons swap] for [G]
+and [[] =] (or just [not]) for the predicate [P].
f ∘ ⦇b,⨁⦈ = ⦇c,⨂⦈ ⇐ f b = c ∧ f(a ⨁ as) = a ⨂ (f as)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
b [⨁] catamorphism f == c [⨂] catamorphism
+
+f == 10 *
+
+0 [+] catamorphism f
+
+0 f == 0
+
+as a + f == as f a ⨂
+
+⨂ = f +
+
+0 [+] catamorphism f = 0 [f +] catamorphism
+
The step combinator will often be easier to use than catamorphism.
+
+
+
+
+
+
+
+
+
+
In [21]:
+
+
+
[step] help
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+==== Help on step ====
+
+Run a quoted program on each item in a sequence.
+::
+
+ ... [] [Q] . step
+ -----------------------
+ ... .
+
+
+ ... [a] [Q] . step
+ ------------------------
+ ... a . Q
+
+
+ ... [a b c] [Q] . step
+ ----------------------------------------
+ ... a . Q [b c] [Q] step
+
+The step combinator executes the quotation on each member of the list
+on top of the stack.
+
+---- end (step)
+
+
+
Now let's try a version that doesn't do that. When you can start with the identity value c on the stack and the combiner Q can operate as you go using the intermediate results immediately rather than queuing them up, we can do this:
+
[P] c [G] [Q] H₂ == c [pop P] [popd] [[G] dip Q] tailrec
+
+
+
An important difference is that the combiner function Q must accept its arguments in the reverse order and take into account the presence of the a value:
+
... a c [G] dip Q H₂
+... a G c Q H₂
+... a′ b c Q H₂
+... a′ c′ H₂
+ <predicate omitted>
+... a′ c′ [G] dip Q H₂
+... a′ G c′ Q H₂
+... a″ b c′ Q H₂
+... a″ c″ H₂
+ <predicate omitted>
+... a″ c″ [G] dip Q H₂
+... a″ G c″ Q H₂
+... a‴ b c″ Q H₂
+... a‴ c‴ H₂
+ <predicate omitted>
+... a‴ c‴ popd
+... c‴
+
+
+
+
+
+
+
+
+
+
+
+
+
Note that the c values are processed by the Q combiner function in reverse order as compared to the original version.
Now let's try a version that doesn't do that. When you can start with the identity value c on the stack and the combiner Q can operate as you go using the intermediate results immediately rather than queuing them up, we can do this:
+
[P] c [G] [Q] H₂ == c swap [P] [pop] [G [Q] dip] tailrec
+
+
+
An important difference is that the generator function must return its results in the reverse order, and both Q and G have to take into account the presence of the c value:
+
... c a G [Q] dip H₂
+... c b a′ [Q] dip H₂
+... c b Q a′ H₂
+... c′ a′ H₂
+ <predicate omitted>
+... c′ a′ G [Q] dip H₂
+... c′ b′ a″ [Q] dip H₂
+... c′ b′ Q a″ H₂
+... c″ a″ H₂
+ <predicate omitted>
+... c″ a″ G [Q] dip H₂
+... c″ b″ a‴ [Q] dip H₂
+... c″ b″ Q a‴ H₂
+... c‴ a‴ H₂
+ <predicate omitted>
+... c‴ a‴ pop
+... c‴
+
There are (at least) four kinds of recursive combinator, depending on two choices. The first choice is whether the combiner function Q should be evaluated during the recursion or pushed into the pending expression to be "collapsed" at the end. The second choice is whether the combiner needs to operate on the current value of the datastructure or the generator's output, in other words, whether Q or G should run first in the recursive branch.
The working of the generator function G differs slightly for each. Consider the recursive branches:
+
... a G [H1] dip Q w/ a G == a′ b
+
+... c a G [Q] dip H2 a G == b a′
+
+... a [G] dupdip [H3] dip Q a G == a′
+
+... c a [Q] dupdip G H4 a G == a′
+
+
+
The following four sections illustrate how these work, omitting the predicate evaluation.
This form builds up a pending expression (continuation) that contains the intermediate results along with the pending combiner functions. When the base case is reached the last term is replaced by the identity value c and the continuation "collapses" into the final result using the combiner Q.
+
H1 == [P] [pop c] [G] [dip Q] genrec
+
+... a G [H1] dip Q
+... a′ b [H1] dip Q
+... a′ H1 b Q
+ <predicate omitted>
+... a′ G [H1] dip Q b Q
+... a″ b′ [H1] dip Q b Q
+... a″ H1 b′ Q b Q
+ <predicate omitted>
+... a″ G [H1] dip Q b′ Q b Q
+... a‴ b″ [H1] dip Q b′ Q b Q
+... a‴ H1 b″ Q b′ Q b Q
+ <predicate omitted>
+... a‴ pop c b″ Q b′ Q b Q
+... c b″ Q b′ Q b Q
+... c′ b′ Q b Q
+... c″ b Q
+... c‴
+
When you can start with the identity value c on the stack and the combiner Q can operate as you go using the intermediate results immediately rather than queuing them up, use this form.
+An important difference is that the generator function must return its results in the reverse order,
+and both Q and G have to take into account the presence of the c value:
+
H2 == c swap [P] [pop] [G [Q] dip] tailrec
+
+... c a G [Q] dip H2
+... c b a′ [Q] dip H2
+... c b Q a′ H2
+... c′ a′ H2
+ <predicate omitted>
+... c′ a′ G [Q] dip H2
+... c′ b′ a″ [Q] dip H2
+... c′ b′ Q a″ H2
+... c″ a″ H2
+ <predicate omitted>
+... c″ a″ G [Q] dip H2
+... c″ b″ a‴ [Q] dip H2
+... c″ b″ Q a‴ H2
+... c‴ a‴ H2
+ <predicate omitted>
+... c‴ a‴ pop
+... c‴
+
If you examine the traces above you'll see that the combiner Q only gets to operate on the results of G, it never "sees" the first value a. If the combiner and the generator both need to work on the current value then dup must be used, and the generator must produce one item instead of two (the b is instead the duplicate of a.)
+
H3 == [P] [pop c] [[G] dupdip] [dip Q] genrec
+
+... a [G] dupdip [H3] dip Q
+... a G a [H3] dip Q
+... a′ a [H3] dip Q
+... a′ H3 a Q
+ <predicate omitted>
+... a′ [G] dupdip [H3] dip Q a Q
+... a′ G a′ [H3] dip Q a Q
+... a″ a′ [H3] dip Q a Q
+... a″ H3 a′ Q a Q
+ <predicate omitted>
+... a″ [G] dupdip [H3] dip Q a′ Q a Q
+... a″ G a″ [H3] dip Q a′ Q a Q
+... a‴ a″ [H3] dip Q a′ Q a Q
+... a‴ H3 a″ Q a′ Q a Q
+ <predicate omitted>
+... a‴ pop c a″ Q a′ Q a Q
+... c a″ Q a′ Q a Q
+... c′ a′ Q a Q
+... c‴ a Q
+... c‴
+
An often-used function is filter which takes a list and a predicate and makes a new list with only those items from the input list that make the predicate true:
It would seem that all we need to do now is turn the swons into an expression that applies the input P predicate to the items and only puts them on the output list if they pass.
However, the input list will be on the stack just below the item, so W has to take account of that. If our predicate function doesn't use any values from below the item under consideration then we're okay, but if it does then we have to deal with the input list somehow.
+
We know W would be something like:
+
W == [...[P]...] [swons] [pop] ifte
+
+
+
Let's examine the situation:
+
... [...] item [...[P]...] [swons] [pop] ifte
+
+
+
Since the predicate of the ifte combinator is applied nullary we can just pop the output list:
This isn't completely satisfying. For one thing, it would be nice to apply the predicate as we go so we are not putting items (and W) onto the expression for items that will fail the predicate P.
For now, there is no way to define new functions from within the Joy language. All functions (and the interpreter) all accept and return a dictionary parameter (in addition to the stack and expression) so that we can implement e.g. a function that adds new functions to the dictionary. However, there's no function that does that. Adding a new function to the dictionary is a meta-interpreter action, you have to do it in Python, not Joy.
An efficient sum function is already in the library. But for size we can use a “compiled” version hand-written in Python to speed up evaluation and make the trace more readable.
+
+
+
+
+
+
+
+
+
+
In [3]:
+
+
+
fromjoy.libraryimportSimpleFunctionWrapper
+fromjoy.utils.stackimportiter_stack
+
+
+@SimpleFunctionWrapper
+defsize(stack):
+ '''Return the size of the sequence on the stack.'''
+ sequence,stack=stack
+ n=0
+ for_initer_stack(sequence):
+ n+=1
+ returnn,stack
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Now we replace the old version in the dictionary with the new version, and re-evaluate the expression.
This function accepts two integers on the stack and increments or
+decrements one of them such that the new pair of numbers is the next
+coordinate pair in a square spiral (like the kind used to construct an
+Ulam Spiral).
If all you're trying to do is generate the first N points in the spiral
+(without the original problem's constraint of masking to an N x M
+region), the code becomes very simple:
+
+
void spiral(const int N)
+{
+ int x = 0;
+ int y = 0;
+ for(int i = 0; i < N; ++i)
+ {
+ cout << x << '\t' << y << '\n';
+ if(abs(x) <= abs(y) && (x != y || x >= 0))
+ x += ((y >= 0) ? 1 : -1);
+ else
+ y += ((x >= 0) ? -1 : 1);
+ }
+}
+
I've defined two short-circuiting Boolean combinators && and || that
+each accept two quoted predicate programs, run the first, and
+conditionally run the second only if required (to compute the final
+Boolean value). They run their predicate arguments nullary.
We can assemble the three functions we just defined in quotes and give
+them them to the ifte combinator. With some arrangement to show off
+the symmetry of the two branches, we have:
As I was writing this up I realized that, since the && combinator
+doesn't consume the stack (below its quoted args), I can unquote the
+predicate, swap the branches, and use the branch combinator instead of
+ifte:
So that's an example of Joy code. It's a straightforward translation of
+the original. It's a little long for a single definition, you might
+break it up like so:
This way it's easy to see that the function is a branch with two
+quasi-symmetrical paths.
+
We then used this function to make a simple generator of coordinate
+pairs, where the next pair in the series can be generated at any time by
+using the x combinator on the generator (which is just a quoted
+expression containing a copy of the current pair and the "stepper
+function" to generate the next pair from that.)
Often it will be easier on the programmer to write branching code with the predicate specified in a quote. The ifte combinator provides this (T for "then" and E for "else"):
+
[P] [T] [E] ifte
+
+
+
Defined in terms of branch:
+
ifte == [nullary not] dip branch
+
+
+
+
In this case, P must be compatible with the stack and return a Boolean value, and T and E both must be compatible with the preceeding and following functions, as described above for F and T. (Note that in the current implementation we are depending on Python for the underlying semantics, so the Boolean value doesn't have to be Boolean because Python's rules for "truthiness" will be used to evaluate it. I reflect this in the structure of the stack effect comment of branch, it will only accept Boolean values, and in the definition of ifte above by including not in the quote, which also has the effect that the subject quotes are in the proper order for branch.)
The loop combinator generates a copy of itself in the true branch. This is the hallmark of recursive defintions. In Thun there is no equivalent to conventional loops. (There is, however, the x combinator, defined as x == dup i, which permits recursive constructs that do not need to be directly self-referential, unlike loop and genrec.)
Because loop expects and consumes a Boolean value, the Q function must be compatible with the previous stack and itself with a boolean flag for the next iteration:
+
Q == G b
+
+Q [Q] loop
+G b [Q] loop
+G Q [Q] loop
+G G b [Q] loop
+G G Q [Q] loop
+G G G b [Q] loop
+G G G
+
Keep doing Bwhile some predicate P is true. This is convenient as the predicate function is made nullary automatically and the body function can be designed without regard to leaving a Boolean flag for the next iteration:
The parallel operation indicates that two (or more) functions do not interfere with each other and so can run in parallel. The main difficulty in this sort of thing is orchestrating the recombining ("join" or "wait") of the results of the functions after they finish.
+
The current implementaions and the following definitions are not actually parallel (yet), but there is no reason they couldn't be reimplemented in terms of e.g. Python threads. I am not concerned with performance of the system just yet, only the elegance of the code it allows us to write.
Joy has a few parallel combinators, the main one being cleave:
+
... x [A] [B] cleave
+---------------------------------------------------------
+ ... [x ...] [A] infra first [x ...] [B] infra first
+---------------------------------------------------------
+ ... a b
+
+
+
The cleave combinator expects a value and two quotes and it executes each quote in "separate universes" such that neither can affect the other, then it takes the first item from the stack in each universe and replaces the value and quotes with their respective results.
+
(I think this corresponds to the "fork" operator, the little upward-pointed triangle, that takes two functions A :: x -> a and B :: x -> b and returns a function F :: x -> (a, b), in Conal Elliott's "Compiling to Categories" paper, et. al.)
+
Just a thought, if you cleave two jobs and one requires more time to finish than the other you'd like to be able to assign resources accordingly so that they both finish at the same time.
There are also app2 and app3 which run a single quote on more than one value:
+
... y x [Q] app2
+ ---------------------------------------------------------
+ ... [y ...] [Q] infra first [x ...] [Q] infra first
+
+
+ ... z y x [Q] app3
+ ---------------------------------
+ ... [z ...] [Q] infra first
+ [y ...] [Q] infra first
+ [x ...] [Q] infra first
+
+
+
Because the quoted program can be i we can define cleave in terms of app2:
+
cleave == [i] app2 [popd] dip
+
+
+
+
+
+
+
+
+
+
+
+
+
(I'm not sure why cleave was specified to take that value, I may make a combinator that does the same thing but without expecting a value.)
+
clv == [i] app2
+
+ [A] [B] clv
+------------------
+ a b
+
The cleave operators and others all have pretty brutal join semantics: everything works and we always wait for every sub-computation. We can imagine a few different potentially useful patterns of "joining" results from parallel combinators.
Thinking about variations of pam there could be one that only returns the first result of the first-to-finish sub-program, or the stack could be replaced by its output stack.
Also known as "Futures" or "Promises" (by everybody else. "Fulinators" is what I was going to call them when I was thinking about implementing them in Thun.)
+
The runtime could be amended to permit "thunks" representing the results of in-progress computations to be left on the stack and picked up by subsequent functions. These would themselves be able to leave behind more "thunks", the values of which depend on the eventual resolution of the values of the previous thunks.
+
In this way you can create "chains" (and more complex shapes) out of normal-looking code that consist of a kind of call-graph interspersed with "asyncronous" ... events?
+
In any case, until I can find a rigorous theory that shows that this sort of thing works perfectly in Joy code I'm not going to worry about it. (And I think the Categories can deal with it anyhow? Incremental evaluation, yeah?)
Although any expression in Joy can be considered to describe a tree with the quotes as compound nodes and the non-quote values as leaf nodes, in this page I want to talk about ordered binary trees and how to make and use them.
That says that a BTree is either the empty quote [] or a quote with four items: a key, a value, and two BTrees representing the left and right branches of the tree.
R0 is almost certainly going to use dup to make a copy of the node and then dip on some function to process the copy with it:
+
[key value left right] [F] dupdip [BTree-iter] R1
+[key value left right] F [key value left right] [BTree-iter] R1
+
+
+
For example, if we're getting all the keys F would be first:
+
R0 == [first] dupdip
+
+[key value left right] [first] dupdip [BTree-iter] R1
+[key value left right] first [key value left right] [BTree-iter] R1
+key [key value left right] [BTree-iter] R1
+
Now R1 needs to apply [BTree-iter] to left and right. If we drop the key and value from the node using rest twice we are left with an interesting situation:
+
key [key value left right] [BTree-iter] R1
+key [key value left right] [BTree-iter] [rest rest] dip
+key [key value left right] rest rest [BTree-iter]
+key [left right] [BTree-iter]
+
+
(As an implementation detail, the [[] []] literal used in the definition of BTree-new will be reused to supply the constant tail for all new nodes produced by it. This is one of those cases where you get amortized storage "for free" by using persistent datastructures. Because the tail, which is ((), ((), ())) in Python, is immutable and embedded in the definition body for BTree-new, all new nodes can reuse it as their own tail without fear that some other code somewhere will change it.)
[key_n value_n left right] value key R0 [BTree-add] R1
+
+
+
In this case, there are three possibilites: the key can be greater or less than or equal to the node's key. In two of those cases we will need to apply a copy of BTree-add, so R0 is pretty much out of the picture.
The first thing we need to do is compare the the key we're adding to see if it is greater than the node key and branch accordingly, although in this case it's easier to write a destructive predicate and then use ifte to apply it nullary:
+
[key_n value_n left right] value key [BTree-add] R1
+[key_n value_n left right] value key [BTree-add] [P >] [T] [E] ifte
+
+[key_n value_n left right] value key [BTree-add] P >
+[key_n value_n left right] value key [BTree-add] pop roll> pop first >
+[key_n value_n left right] value key roll> pop first >
+key [key_n value_n left right] value roll> pop first >
+key key_n >
+Boolean
+
+P > == pop roll> pop first >
+P < == pop roll> pop first <
+P == pop roll> pop first
+
+
+
+
+
+
+
+
+
+
+
In [9]:
+
+
+
define('P == pop roll> pop first')
+
+
+
+
+
+
+
+
+
+
+
+
+
In [10]:
+
+
+
V('["k" "v" [] []] "vv" "kk" [0] P >')
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
. ['k' 'v' [] []] 'vv' 'kk' [0] P >
+ ['k' 'v' [] []] . 'vv' 'kk' [0] P >
+ ['k' 'v' [] []] 'vv' . 'kk' [0] P >
+ ['k' 'v' [] []] 'vv' 'kk' . [0] P >
+['k' 'v' [] []] 'vv' 'kk' [0] . P >
+['k' 'v' [] []] 'vv' 'kk' [0] . pop roll> pop first >
+ ['k' 'v' [] []] 'vv' 'kk' . roll> pop first >
+ 'kk' ['k' 'v' [] []] 'vv' . pop first >
+ 'kk' ['k' 'v' [] []] . first >
+ 'kk' 'k' . >
+ True .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
If the key we're adding is greater than the node's key.¶
Here the parantheses are meant to signify that the right-hand side (RHS) is not literal, the code in the parentheses is meant to have been evaluated:
+
[key_n value_n left right] value key [BTree-add] T == [key_n value_n left (BTree-add key value right)]
+
So how do we do this? We know we're going to want to use infra on some function K that has the key and value to work with, as well as the quoted copy of BTree-add to apply somehow:
+
right left value_n key_n value key [BTree-add] K
+ ...
+right value key BTree-add left value_n key_n
+
+
+
Pretty easy:
+
right left value_n key_n value key [BTree-add] cons cons dipdd
+right left value_n key_n [value key BTree-add] dipdd
+right value key BTree-add left value_n key_n
+
+
+
So:
+
K == cons cons dipdd
+
+
+
And:
+
[key_n value_n left right] [value key [BTree-add] K] infra
+
+
If the key we're adding is less than the node's key.¶
This is very very similar to the above:
+
[key_n value_n left right] value key [BTree-add] E
+[key_n value_n left right] value key [BTree-add] [P <] [Te] [Ee] ifte
+
+
+
In this case Te works that same as T but on the left child tree instead of the right, so the only difference is that it must use dipd instead of dipdd:
+
Te == [cons cons dipd] cons cons cons infra
+
+
+
This suggests an alternate factorization:
+
ccons == cons cons
+T == [ccons dipdd] ccons cons infra
+Te == [ccons dipd] ccons cons infra
+
+
[key_n value_n left right] value key [BTree-add] Ee
+ ...
+[key value left right]
+
+
+
This is another easy one:
+
Ee == pop swap roll< rest rest cons cons
+
+[key_n value_n left right] value key [BTree-add] pop swap roll< rest rest cons cons
+[key_n value_n left right] value key swap roll< rest rest cons cons
+[key_n value_n left right] key value roll< rest rest cons cons
+key value [key_n value_n left right] rest rest cons cons
+key value [ left right] cons cons
+ [key value left right]
+
+
+
+
+
+
+
+
+
+
+
In [16]:
+
+
+
define('Ee == pop swap roll< rest rest cons cons')
+
We can use this to make a set-like datastructure by just setting values to e.g. 0 and ignoring them. It's set-like in that duplicate items added to it will only occur once within it, and we can query it in $O(\log_2 N)$ time.
Instead of all this mucking about with nested ifte let's just go whole hog and define cmp which takes two values and three quoted programs on the stack and runs one of the three depending on the results of comparing the two values:
+
a b [G] [E] [L] cmp
+------------------------- a > b
+ G
+
+ a b [G] [E] [L] cmp
+------------------------- a = b
+ E
+
+ a b [G] [E] [L] cmp
+------------------------- a < b
+ L
+
+
+
We need a new non-destructive predicate P:
+
[key_n value_n left right] value key [BTree-add] P
+[key_n value_n left right] value key [BTree-add] over [Q] nullary
+[key_n value_n left right] value key [BTree-add] key [Q] nullary
+[key_n value_n left right] value key [BTree-add] key Q
+[key_n value_n left right] value key [BTree-add] key popop popop first
+[key_n value_n left right] value key popop first
+[key_n value_n left right] first
+ key_n
+[key_n value_n left right] value key [BTree-add] key [Q] nullary
+[key_n value_n left right] value key [BTree-add] key key_n
+
+P == over [popop popop first] nullary
+
+
+
Here are the definitions again, pruned and renamed in some cases:
[key_n value_n left right] value key [BTree-add] R1
+[key_n value_n left right] value key [BTree-add] P [T>] [E] [T<] cmp
+
+
+
The line above becomes one of the three lines below:
+
[key_n value_n left right] value key [BTree-add] T>
+[key_n value_n left right] value key [BTree-add] E
+[key_n value_n left right] value key [BTree-add] T<
+
+
+
The definition is a little longer but, I think, more elegant and easier to understand:
fromjoy.libraryimportFunctionWrapper
+fromjoy.utils.stackimportconcat
+fromnotebook_preambleimportD
+
+
+@FunctionWrapper
+defcmp_(stack,expression,dictionary):
+ '''
+ cmp takes two values and three quoted programs on the stack and runs
+ one of the three depending on the results of comparing the two values:
+
+ a b [G] [E] [L] cmp
+ ------------------------- a > b
+ G
+
+ a b [G] [E] [L] cmp
+ ------------------------- a = b
+ E
+
+ a b [G] [E] [L] cmp
+ ------------------------- a < b
+ L
+ '''
+ L,(E,(G,(b,(a,stack))))=stack
+ expression=concat(Gifa>belseLifa<belseE,expression)
+ returnstack,expression,dictionary
+
+
+D['cmp']=cmp_
+
+
+
+
+
+
+
+
+
+
+
+
+
In [31]:
+
+
+
fromjoy.libraryimportFunctionWrapper,S_ifte
+
+
+@FunctionWrapper
+defcond(stack,expression,dictionary):
+ '''
+ like a case statement; works by rewriting into a chain of ifte.
+
+ [..[[Bi] Ti]..[D]] -> ...
+
+
+ [[[B0] T0] [[B1] T1] [D]] cond
+ -----------------------------------------
+ [B0] [T0] [[B1] [T1] [D] ifte] ifte
+
+ '''
+ conditions,stack=stack
+ ifconditions:
+ expression=_cond(conditions,expression)
+ try:
+ # Attempt to preload the args to first ifte.
+ (P,(T,(E,expression)))=expression
+ exceptValueError:
+ # If, for any reason, the argument to cond should happen to contain
+ # only the default clause then this optimization will fail.
+ pass
+ else:
+ stack=(E,(T,(P,stack)))
+ returnstack,expression,dictionary
+
+
+def_cond(conditions,expression):
+ (clause,rest)=conditions
+ ifnotrest:# clause is [D]
+ returnclause
+ P,T=clause
+ return(P,(T,(_cond(rest,()),(S_ifte,expression))))
+
+
+
+D['cond']=cond
+
It may seem silly, but a big part of programming in Forth (and therefore in Joy) is the idea of small, highly-factored definitions. If you choose names carefully the resulting definitions can take on a semantic role.
A Version of BTree-iter that does In-Order Traversal¶
+
+
+
+
+
+
+
+
+
+
+
If you look back to the non-empty case of the BTree-iter function we can design a varient that first processes the left child, then the current node, then the right child. This will allow us to traverse the tree in sort order.
Staring at this for a bit suggests dup third to start:
+
[key value left right] R0 [BTree-iter-order] R1
+[key value left right] dup third [BTree-iter-order] R1
+[key value left right] left [BTree-iter-order] R1
+
+
+
Now maybe:
+
[key value left right] left [BTree-iter-order] [cons dip] dupdip
+[key value left right] left [BTree-iter-order] cons dip [BTree-iter-order]
+[key value left right] [left BTree-iter-order] dip [BTree-iter-order]
+left BTree-iter-order [key value left right] [BTree-iter-order]
+
So far, so good. Now we need to process the current node's values:
+
left BTree-iter-order [key value left right] [BTree-iter-order] [[F] dupdip] dip
+left BTree-iter-order [key value left right] [F] dupdip [BTree-iter-order]
+left BTree-iter-order [key value left right] F [key value left right] [BTree-iter-order]
+
+
+
If F needs items from the stack below the left stuff it should have cons'd them before beginning maybe? For functions like first it works fine as-is.
+
left BTree-iter-order [key value left right] first [key value left right] [BTree-iter-order]
+left BTree-iter-order key [key value left right] [BTree-iter-order]
+
As before, the stopping predicate just has to detect the empty list:
+
BTree-get == [pop not] [E] [R0] [R1] genrec
+
+
+
But what do we do if the key isn't in the tree? In Python we might raise a KeyError but I'd like to avoid exceptions in Joy if possible, and here I think it's possible. (Division by zero is an example of where I think it's probably better to let Python crash Joy. Sometimes the machinery fails and you have to "stop the line", methinks.)
+
Let's pass the buck to the caller by making the base case a given, you have to decide for yourself what [E] should be.
+
tree key [E] BTree-get
+---------------------------- key in tree
+ value
+
+ tree key [E] BTree-get
+---------------------------- key not in tree
+ tree key E
+
+
+
Now we define:
+
BTree-get == [pop not] swap [R0] [R1] genrec
+
+
+
Note that this BTree-get creates a slightly different function than itself and that function does the actual recursion. This kind of higher-level programming is unusual in most languages but natural in Joy.
We want to compare the search key with the key in the node, and if they are the same return the value and if they differ then recurse on one of the child nodes. So it's very similar to the above funtion, with [R0] == [] and R1 == P [T>] [E] [T<] cmp:
+
[key value left right] key [BTree-get] P [T>] [E] [T<] cmp
+
+
+
So:
+
get-node-key == pop popop first
+P == over [get-node-key] nullary
+
+
+
The only difference is that get-node-key does one less pop because there's no value to discard. Now we have to derive the branches:
+
[key_n value_n left right] key [BTree-get] T>
+[key_n value_n left right] key [BTree-get] E
+[key_n value_n left right] key [BTree-get] T<
+
+
+
The cases of T> and T< are similar to above but instead of using infra we have to discard the rest of the structure:
+
[key_n value_n left right] key [BTree-get] T> == right key BTree-get
+[key_n value_n left right] key [BTree-get] T< == left key BTree-get
+
+
+
So:
+
T> == [fourth] dipd i
+T< == [third] dipd i
+
+
+
E.g.:
+
[key_n value_n left right] key [BTree-get] [fourth] dipd i
+[key_n value_n left right] fourth key [BTree-get] i
+ right key [BTree-get] i
+ right key BTree-get
+
+
+
And:
+
[key_n value_n left right] key [BTree-get] E == value_n
+
+E == popop second
+
+
+
So:
+
fourth == rest rest rest first
+get-node-key == pop popop first
+P == over [get-node-key] nullary
+T> == [fourth] dipd i
+T< == [third] dipd i
+E == popop second
+
+BTree-get == [pop not] swap [] [P [T>] [E] [T<] cmp] genrec
+
+
+
+
+
+
+
+
+
+
+
In [43]:
+
+
+
# I don't want to deal with name conflicts with the above so I'm inlining everything here.
+# The original Joy system has "hide" which is a meta-command which allows you to use named
+# definitions that are only in scope for a given definition. I don't want to implement
+# that (yet) so...
+
+
+define('''
+BTree-get == [pop not] swap [] [
+ over [pop popop first] nullary
+ [[rest rest rest first] dipd i]
+ [popop second]
+ [[third] dipd i]
+ cmp
+ ] genrec
+''')
+
The first two cases are symmetrical, if we only have one non-empty child node return it.
+
E == [
+ [[pop third not] pop fourth]
+ [[pop fourth not] pop third]
+ [default]
+] cond
+
+
+
+
+
+
+
+
+
+
+
+
+
(If both child nodes are empty return an empty node.)
+
+
+
+
+
+
+
+
+
+
+
+
The initial structure of the default function:
+
default == [E'] cons infra
+
+[node_key node_value left right] [key D] default
+[node_key node_value left right] [key D] [E'] cons infra
+[node_key node_value left right] [[key D] E'] infra
+
+right left node_value node_key [key D] E'
+
+
+
+
+
+
+
+
+
+
+
+
+
If both child nodes are non-empty, we find the highest node in our lower sub-tree, take its key and value to replace (delete) our own, then get rid of it by recursively calling delete() on our lower sub-node with our new key.
+
(We could also find the lowest node in our higher sub-tree and take its key and value and delete it. I only implemented one of these two symmetrical options. Over a lot of deletions this might make the tree more unbalanced. Oh well.)
+
+
+
+
+
+
+
+
+
+
+
+
First things first, we no longer need this node's key and value:
+
right left node_value node_key [key D] roll> popop E''
+right left [key D] node_value node_key popop E''
+right left [key D] E''
+
+
+
+
+
+
+
+
+
+
+
+
+
Then we have to we find the highest (right-most) node in our lower (left) sub-tree:
+
right left [key D] E''
+
+
+
+
+
+
+
+
+
+
+
+
+
Ditch the key:
+
right left [key D] rest E'''
+right left [D] E'''
+
+
+
+
+
+
+
+
+
+
+
+
+
Find the right-most node:
+
right left [D] [dup W] dip E''''
+right left dup W [D] E''''
+right left left W [D] E''''
+
+
+
+
+
+
+
+
+
+
+
+
+
Consider:
+
left W
+
+
+
+
+
+
+
+
+
+
+
+
+
We know left is not empty:
+
[L_key L_value L_left L_right] W
+
+
+
+
+
+
+
+
+
+
+
+
+
We want to keep extracting the right node as long as it is not empty:
One bug, I forgot to put not in the first two clauses of the cond.
+
The behavior of the [Er] function should maybe be different: either just silently fail, or maybe implement some sort of function that can grab the pending expression up to a sentinel value or something, allowing for a kind of "except"-ish control-flow?
+
+
+
+
+
+
+
+
+
+
+
+
Then, once we have add, get, and delete we can see about abstracting them.
In the spirit of step we are going to define a combinator treestep which expects a tree and three additional items: a base-case value z, and two quoted programs [C] and [N].
+
tree z [C] [N] treestep
+
+
+
If the current tree node is empty then just leave z on the stack in lieu:
+
[] z [C] [N] treestep
+---------------------------
+ z
+
+
+
Otherwise, evaluate N on the node value, map the whole function (abbreviated here as k) over the child trees recursively, and then combine the result with C.
+
[node [tree*]] z [C] [N] treestep
+--------------------------------------- w/ K == z [C] [N] treestep
+ node N [tree*] [K] map C
+
Since this is a recursive function, we can begin to derive it by finding the ifte stage that genrec will produce. The predicate and base-case functions are trivial, so we just have to derive J.
+
K == [not] [pop z] [J] ifte
+
+
+
The behavior of J is to accept a (non-empty) tree node and arrive at the desired outcome.
+
[node [tree*]] J
+------------------------------
+ node N [tree*] [K] map C
+
+
+
So J will have some form like:
+
J == .. [N] .. [K] .. [C] ..
+
+
+
Let's dive in. First, unquote the node and dipN.
+
[node [tree*]] i [N] dip
+ node [tree*] [N] dip
+node N [tree*]
+
+
+
Next, mapK over teh child trees and combine with C.
+
node N [tree*] [K] map C
+node N [tree*] [K] map C
+node N [K.tree*] C
+
+
Doesn't work because map extracts the first item of whatever its mapped function produces. We have to return a list, rather than depositing our results directly on the stack.
[key value left right] R0 [BTree-iter-order] R1
+ ...
+left BTree-iter-order key value F right BTree-iter-order
+
+
+[key value left right] unstack swap
+ key value left right swap
+ key value right left
+
+key value right left [BTree-iter-order] [cons dipdd] dupdip
+key value right left [BTree-iter-order] cons dipdd [BTree-iter-order]
+key value right [left BTree-iter-order] dipdd [BTree-iter-order]
+left BTree-iter-order key value right [BTree-iter-order]
+
+left BTree-iter-order key value right [F] dip [BTree-iter-order]
+left BTree-iter-order key value F right [BTree-iter-order] i
+left BTree-iter-order key value F right BTree-iter-order
+
+
+
So:
+
R0 == unstack swap
+R1 == [cons dipdd [F] dip] dupdip i
+
+[key value left right] R0 [BTree-iter-order] R1
+[key value left right] unstack swap [BTree-iter-order] [cons dipdd [F] dip] dupdip i
+ key value right left [BTree-iter-order] [cons dipdd [F] dip] dupdip i
+
+ key value right left [BTree-iter-order] cons dipdd [F] dip [BTree-iter-order] i
+ key value right [left BTree-iter-order] dipdd [F] dip [BTree-iter-order] i
+ left BTree-iter-order key value right [F] dip [BTree-iter-order] i
+ left BTree-iter-order key value F right [BTree-iter-order] i
+ left BTree-iter-order key value F right BTree-iter-order
+
+
+BTree-iter-order == [not] [pop] [unstack swap] [[cons dipdd [F] dip] dupdip i] genrec
+
BTree-new == swap [[] []] cons2
+T == [cons2 dipdd] cons2 cons infra
+Te == [cons2 dipd] cons2 cons infra
+Ee == pop swap roll< rest rest cons2
+
+
+
It's used a lot because it's tied to the fact that there are two "data items" in each node. This point to a more general factorization that would render a combinator that could work for other geometries of trees.
A general form for tree data with N children per node:
+
[[data] [child0] ... [childN-1]]
+
+
+
Suggests a general form of recursive iterator, but I have to go walk the dogs at the mo'.
+
For a given structure, you would have a structure of operator functions and sort of merge them and run them, possibly in a different order (pre- post- in- y'know). The Cn functions could all be the same and use the step trick if the children nodes are all of the right kind. If they are heterogeneous then we need a way to get the different Cn into the structure in the right order. If I understand correctly, the "Bananas..." paper shows how to do this automatically from a type description. They present, if I have it right, a tiny machine that accepts some sort of algebraic data type description and returns a function that can recusre over it, I think.
BTree-iter == unit [not] [pop] roll< [R1] genrec
+
+
+
So in the general case of non-empty nodes:
+
[key value left right] [F] [BTree-iter] R1
+
+
+
We just define R1 to do whatever it has to to process the node. For example:
+
[key value left right] [F] [BTree-iter] R1
+ ...
+key value F left BTree-iter right BTree-iter
+left BTree-iter key value F right BTree-iter
+left BTree-iter right BTree-iter key value F
+
+
+
Pre-, ??-, post-order traversals.
+
[key value left right] uncons uncons
+ key value [left right]
+
+
+
For pre- and post-order we can use the step trick:
We worked out one scheme for ?in-order? traversal above, but maybe we can do better?
+
[key value left right] [F] [BTree-iter] [unstack] dipd
+[key value left right] unstack [F] [BTree-iter]
+ key value left right [F] [BTree-iter]
+
+key value left right [F] [BTree-iter] R1.1
+
+
+
Hmm...
+
key value left right [F] [BTree-iter] tuck
+key value left right [BTree-iter] [F] [BTree-iter]
+
+
+[key value left right] [F] [BTree-iter] [unstack [roll>] dip] dipd
+[key value left right] unstack [roll>] dip [F] [BTree-iter]
+ key value left right [roll>] dip [F] [BTree-iter]
+ key value left roll> right [F] [BTree-iter]
+ left key value right [F] [BTree-iter]
+
+left key value right [F] [BTree-iter] tuck foo
+left key value right [BTree-iter] [F] [BTree-iter] foo
+ ...
+left BTree-iter key value F right BTree-iter
+
+
+
We could just let [R1] be a parameter too, for maximum flexibility.
+
Automatically deriving the recursion combinator for a data type?¶
If I understand it correctly, the "Bananas..." paper talks about a way to build the processor function automatically from the description of the type. I think if we came up with an elegant way for the Joy code to express that, it would be cool. In Joypy the definitions can be circular because lookup happens at evaluation, not parsing. E.g.:
+
A == ... B ...
+B == ... A ...
+
+
+
That's fine. Circular datastructures can't be made though.
In the spirit of step we are going to define a combinator treestep which expects a tree and three additional items: a base-case function [B], and two quoted programs [N] and [C].
+
tree [B] [N] [C] treestep
+
+
+
+
+
+
+
+
+
+
+
+
+
If the current tree node is empty then just execute B:
+
[] [B] [N] [C] treestep
+---------------------------
+ [] B
+
+
+
+
+
+
+
+
+
+
+
+
+
Otherwise, evaluate N on the node value, map the whole function (abbreviated here as K) over the child trees recursively, and then combine the result with C.
+
[node tree*] [B] [N] [C] treestep
+--------------------------------------- w/ K == [B] [N] [C] treestep
+ node N [tree*] [K] map C
+
+
+
(Later on we'll experiment with making map part of C so you can use other combinators.)
Doesn't work because map extracts the first item of whatever its mapped function produces. We have to return a list, rather than depositing our results directly on the stack.
The treegrind function doesn't include the map combinator, so the [C] function must arrange to use some combinator on the quoted recursive copy [K]. With this function, the pattern for processing a non-empty node is:
This notebook presents a simple type inferencer for Joy code. It can infer the stack effect of most Joy expressions. It's built largely by means of existing ideas and research. (A great overview of the existing knowledge is a talk "Type Inference in Stack-Based Programming Languages" given by Rob Kleffner on or about 2017-03-10 as part of a course on the history of programming languages.)
+
The notebook starts with a simple inferencer based on the work of Jaanus Pöial which we then progressively elaborate to cover more Joy semantics. Along the way we write a simple "compiler" that emits Python code for what I like to call Yin functions. (Yin functions are those that only rearrange values in stacks, as opposed to Yang functions that actually work on the values themselves.)
The third rule is actually two rules. These two rules deal with composing functions when the second one will consume one of items the first one produces. The two types must be unified or a type conflict declared.
+
(a -- b t[i])∘(c u[j] -- d) t <= u (t is subtype of u)
+-------------------------------
+ (a -- b )∘(c -- d) t[i] == t[k] == u[j]
+ ^
+
+ (a -- b t[i])∘(c u[j] -- d) u <= t (u is subtype of t)
+-------------------------------
+ (a -- b )∘(c -- d) t[i] == u[k] == u[j]
+
+
+
+
+
+
+
+
+
+
+
+
+
Let's work through some examples by hand to develop an intuition for the algorithm.
+
+
+
+
+
+
+
+
+
+
+
+
There's a function in one of the other notebooks.
+
F == pop swap roll< rest rest cons cons
+
+
+
It's all "stack chatter" and list manipulation so we should be able to deduce its type.
Joy function types will be represented by Forth-style stack effect comments. I'm going to use numbers instead of names to keep track of the stack arguments. (A little bit like De Bruijn index, at least it reminds me of them):
This eliminates the internal work of the first version. Because this function only rearranges the stack and doesn't do any actual processing on the stack items themselves all the information needed to implement it is in the stack effect comment.
How do we find .0.] in [4 .0.] and replace it with 5 .1.] getting the result [4 5 .1.]? This might seem hard, but because the underlying structure of the Joy list is a cons-list in Python it's actually pretty easy. I'll explain below.
+
+
+
+
+
+
+
+
+
+
+
+
Next we unify and find our two terms are the same already: [5 .1.]:
At last we put it all together in a function C() that accepts two stack effect comments and returns their composition (or raises and exception if they can't be composed due to type conflicts.)
Here's that trick to represent functions like rest and cons that manipulate stacks. We use a cons-list of tuples and give the tails their own numbers. Then everything above already works.
+
+
+
+
+
+
+
+
+
+
In [16]:
+
+
+
rest=((1,2),),(2,)
+
+cons=(1,2),((1,2),)
+
+
+
+
+
+
+
+
+
+
+
+
+
In [17]:
+
+
+
C(poswrd,rest)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Out[17]:
+
+
+
+
+
+
(((3, 4), 1, 2, 0), (2, 1, 4))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Compare this to the stack effect comment we wrote above:
The problem is that the unify() function as written doesn't handle the case when both terms are tuples. We just have to add a clause to deal with this recursively:
+
+
+
+
+
+
+
+
+
+
In [21]:
+
+
+
defunify(u,v,s=None):
+ ifsisNone:
+ s={}
+ elifs:
+ u=update(s,u)
+ v=update(s,v)
+
+ ifisinstance(u,int):
+ s[u]=v
+
+ elifisinstance(v,int):
+ s[v]=u
+
+ elifisinstance(u,tuple)andisinstance(v,tuple):
+
+ iflen(u)!=2orlen(v)!=2:
+ # Not a type error, caller passed in a bad value.
+ raiseValueError(repr((u,v)))# FIXME this message sucks.
+
+ (a,b),(c,d)=u,v
+ s=unify(a,c,s)
+ ifs!=False:
+ s=unify(b,d,s)
+ else:
+ s=False
+
+ returns
+
And compare it to the input stack effect comment tuple we just computed:
+
+
+
+
+
+
+
+
+
+
In [24]:
+
+
+
F[0]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Out[24]:
+
+
+
+
+
+
((3, (4, 5)), 1, 2, 0)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The stack-de-structuring tuple has nearly the same form as our input stack effect comment tuple, just in the reverse order:
+
(_, (d, (c, ((a, (b, S0)), stack))))
+
+
+
Remove the punctuation:
+
_ d c (a, (b, S0))
+
+
+
Reverse the order and compare:
+
(a, (b, S0)) c d _
+((3, (4, 5 )), 1, 2, 0)
+
+
+
Eh?
+
+
+
+
+
+
+
+
+
+
+
+
And the return tuple
+
+
+
+
+
+
+
+
+
+
In [25]:
+
+
+
F[1]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Out[25]:
+
+
+
+
+
+
((2, (1, 5)),)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
is similar to the output stack effect comment tuple:
+
((d, (c, S0)), stack)
+((2, (1, 5 )), )
+
+
+
This should make it pretty easy to write a Python function that accepts the stack effect comment tuples and returns a new Python function (either as a string of code or a function object ready to use) that performs the semantics of that Joy function (described by the stack effect.)
As a convenience I've implemented a function to convert the Python stack effect comment tuples to reasonable text format. There are some details in how this code works that related to stuff later in the notebook, so you should skip it for now and read it later if you're interested.
With this, we have a partial Joy compiler that works on the subset of Joy functions that manipulate stacks (both what I call "stack chatter" and the ones that manipulate stacks on the stack.)
+
I'm probably going to modify the definition wrapper code to detect definitions that can be compiled by this partial compiler and do it automatically. It might be a reasonable idea to detect sequences of compilable functions in definitions that have uncompilable functions in them and just compile those. However, if your library is well-factored this might be less helpful.
So far we have dealt with types of functions, those dealing with simple stack manipulation. Let's extend our machinery to deal with types of arguments.
This involves detecting that "Any type" arguments can accept "numbers". If we were composing these functions the other way round this is still the case:
+
(n n -- n)∘(1 -- 1 1)
+--------------------------- w/ {1: n}
+ (n n -- )∘( -- n n)
+
+
+
The important thing here is that the mapping is going the same way in both cases, from the "any" integer to the number
We should also mind that the number that mul produces is not (necessarily) the same as either of its inputs, which are not (necessarily) the same as each other:
So we need separate domains of "any" numbers and "number" numbers, and we need to be able to ask the order of these domains. Now the notes on the right side of rule three make more sense, eh?
+
(a -- b t[i])∘(c u[j] -- d) t <= u (t is subtype of u)
+-------------------------------
+ (a -- b )∘(c -- d) t[i] == t[k] == u[j]
+ ^
+
+ (a -- b t[i])∘(c u[j] -- d) u <= t (u is subtype of t)
+-------------------------------
+ (a -- b )∘(c -- d) t[i] == u[k] == u[j]
+
+
+
The indices i, k, and j are the number part of our labels and t and u are the domains.
+
By creative use of Python's "double underscore" methods we can define a Python class hierarchy of Joy types and use the issubclass() method to establish domain ordering, as well as other handy behaviour that will make it fairly easy to reuse most of the code above.
(Eventually I should come back around to this becuase it's not tooo difficult to exend this code to be able to compile e.g. n2 = mul(n1, n1) for mul with the right variable names and insert it in the right place. It requires a little more support from the library functions, in that we need to know to call mul() the Python function for mul the Joy function, but since most of the math functions (at least) are already wrappers it should be straightforward.)
The functions that can be compiled are the ones that have only AnyJoyType and StackJoyType labels in their stack effect comments. We can write a function to check that:
Instead of representing the stack effect comments as a single tuple (with N items in it) we use the same cons-list structure to hold the sequence and unify() the whole comments.
This function has to be modified to use the new datastructures and it is no longer recursive, instead recursion happens as part of unification. Further, the first and second of Pöial's rules are now handled automatically by the unification algorithm. (One easy way to see this is that now an empty stack effect comment is represented by a StackJoyType instance which is not "falsey" and so neither of the first two rules' if clauses will ever be True. Later on I change the "truthiness" of StackJoyType to false to let e.g. joy.utils.stack.concat work with our stack effect comment cons-list tuples.)
+
+
+
+
+
+
+
+
+
+
In [64]:
+
+
+
defcompose(f,g):
+ (f_in,f_out),(g_in,g_out)=f,g
+ s=unify(g_in,f_out)
+ ifs==False:# s can also be the empty dict, which is ok.
+ raiseTypeError('Cannot unify %r and %r.'%(f_out,g_in))
+ returnupdate(s,(f_in,g_out))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
I don't want to rewrite all the defs myself, so I'll write a little conversion function instead. This is programmer's laziness.
We can borrow a trick from Brzozowski's Derivatives of Regular Expressions to invent a new type of type variable, a "sequence type" (I think this is what they mean in the literature by that term...) or "Kleene Star" type. I'm going to represent it as a type letter and the asterix, so a sequence of zero or more AnyJoyType variables would be:
+
A*
+
+
+
+
+
+
+
+
+
+
+
+
+
The A* works by splitting the universe into two alternate histories:
+
A* -> 0 | A A*
+
+
+
The Kleene star variable disappears in one universe, and in the other it turns into an AnyJoyType variable followed by itself again. We have to return all universes (represented by their substitution dicts, the "unifiers") that don't lead to type conflicts.
+
+
+
+
+
+
+
+
+
+
+
+
Consider unifying two stacks (the lowercase letters are any type variables of the kinds we have defined so far):
+
[a A* b .0.] U [c d .1.]
+ w/ {c: a}
+[ A* b .0.] U [ d .1.]
+
+
+
+
+
+
+
+
+
+
+
+
+
Now we have to split universes to unify A*. In the first universe it disappears:
+
[b .0.] U [d .1.]
+ w/ {d: b, .1.: .0.}
+ [] U []
+
+
+
+
+
+
+
+
+
+
+
+
+
While in the second it spawns an A, which we will label e:
+
[e A* b .0.] U [d .1.]
+ w/ {d: e}
+[ A* b .0.] U [ .1.]
+ w/ {.1.: A* b .0.}
+[ A* b .0.] U [ A* b .0.]
+
+
+
+
+
+
+
+
+
+
+
+
+
Giving us two unifiers:
+
{c: a, d: b, .1.: .0.}
+{c: a, d: e, .1.: A* b .0.}
+
In order to compute the stack effect of combinators you kinda have to have the quoted programs they expect available. In the most general case, the i combinator, you can't say anything about its stack effect other than it expects one quote:
+
i (... [.1.] -- ... .1.)
+
+
+
Or
+
i (... [A* .1.] -- ... A*)
+
+
+
Consider the type of:
+
[cons] dip
+
+
+
Obviously it would be:
+
(a1 [..1] a2 -- [a1 ..1] a2)
+
+
+
dip itself could have:
+
(a1 [..1] -- ... then what?
+
+
+
+
Without any information about the contents of the quote we can't say much about the result.
I think there's a way forward. If we convert our list (of terms we are composing) into a stack structure we can use it as a Joy expression, then we can treat the output half of a function's stack effect comment as a Joy interpreter stack, and just execute combinators directly. We can hybridize the compostition function with an interpreter to evaluate combinators, compose non-combinator functions, and put type variables on the stack. For combinators like branch that can have more than one stack effect we have to "split universes" again and return both.
We need a type variable for Joy functions that can go in our expressions and be used by the hybrid inferencer/interpreter. They have to store a name and a list of stack effects.
You can also provide an optional stack effect, input-side only, that will then be used as an identity function (that accepts and returns stacks that match the "guard" stack effect) which will be used to guard against type mismatches going into the evaluation of the combinator.
With those in place, we can define a function that accepts a sequence of Joy type variables, including ones representing functions (not just values), and attempts to grind out all the possible stack effects of that expression.
+
One tricky thing is that type variables in the expression have to be updated along with the stack effects after doing unification or we risk losing useful information. This was a straightforward, if awkward, modification to the call structure of meta_compose() et. al.
And that brings us to current Work-In-Progress. The mixed-mode inferencer/interpreter infer() function seems to work well. There are details I should document, and the rest of the code in the types module (FIXME link to its docs here!) should be explained... There is cruft to convert the definitions in DEFS to the new SymbolJoyType objects, and some combinators. Here is an example of output from the current code :
+
+
+
+
+
+
+
+
+
+
In [1]:
+
+
+
1/0# (Don't try to run this cell! It's not going to work. This is "read only" code heh..)
+
+logging.basicConfig(format='%(message)s',stream=sys.stdout,level=logging.INFO)
+
+globals().update(FUNCTIONS)
+
+h=infer((pred,s2),(mul,s3),(div,s4),(nullary,(bool,s5)),dipd,branch)
+
+print'-'*40
+
+forfi,foinh:
+ printdoc_from_stack_effect(fi,fo)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+---------------------------------------------------------------------------
+ZeroDivisionError Traceback (most recent call last)
+<ipython-input-1-9a9d60354c35> in <module>()
+----> 11/0# (Don't try to run this cell! It's not going to work. This is "read only" code heh..)
+ 2
+ 3 logging.basicConfig(format='%(message)s', stream=sys.stdout, level=logging.INFO)
+ 4
+ 5 globals().update(FUNCTIONS)
+
+ZeroDivisionError: integer division or modulo by zero
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The numbers at the start of the lines are the current depth of the Python call stack. They're followed by the current computed stack effect (initialized to ID) then the pending expression (the inference of the stack effect of which is the whole object of the current example.)
+
In this example we are implementing (and inferring) ifte as [nullary bool] dipd branch which shows off a lot of the current implementation in action.
We built a simple type inferencer, and a kind of crude "compiler" for a subset of Joy functions. Then we built a more powerful inferencer that actually does some evaluation and explores branching code paths
+
+
+
+
+
+
+
+
+
+
+
+
Work remains to be done:
+
+
the rest of the library has to be covered
+
figure out how to deal with loop and genrec, etc..
+
extend the types to check values (see the appendix)
+
other kinds of "higher order" type variables, OR, AND, etc..
+
maybe rewrite in Prolog for great good?
+
definitions
+
don't permit composition of functions that don't compose
+
auto-compile compilable functions
+
+
+
Compiling more than just the Yin functions.
+
getting better visibility (than Python debugger.)
+
DOOOOCS!!!! Lots of docs!
+
docstrings all around
+
improve this notebook (it kinda falls apart at the end narratively. I went off and just started writing code to see if it would work. It does, but now I have to come back and describe here what I did.
For type checking to work the type label classes have to be modified to let T >= t succeed, where e.g. T is IntJoyType and t is int. If you do that you can take advantage of the logical relational nature of the stack effect comments to "compute in reverse" as it were. There's a working demo of this at the end of the types module. But if you're interested in all that you should just use Prolog!
In Joypy there aren't any complex datastructures, just ints, floats, strings, Symbols (strings that are names of functions) and sequences (aka lists, aka quoted literals, aka aggregates, etc...), but we can build trees out of sequences.
Zippers work by keeping track of the current item, the already-seen items, and the yet-to-be seen items as you traverse a datastructure (the datastructure used to keep track of these items is the zipper.)
Let's use them to change 25 into 625. The first time a word is used I show the trace so you can see how it works. If we were going to use these a lot it would make sense to write Python versions for efficiency, but see below.
In Joy we have the dip and infra combinators which can "target" or "address" any particular item in a Joy tree structure.
+
+
+
+
+
+
+
+
+
+
In [14]:
+
+
+
[[[[[[sqr] dipd] infra] dip] infra] dip] infra
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
[1 [2 [3 4 390625 6] 7] 8]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
If you were to trace the program you would see that about half of it is the dip and infra combinators de-quoting programs and "digging" into the subject datastructure. Instead of maintaining temporary results on the stack they are pushed into the pending expression (continuation). When sqr has run the rest of the pending expression rebuilds the datastructure.
Imagine a function Z that accepts a sequence of dip and infra combinators, a quoted program [Q], and a datastructure to work on. It would effectively execute the quoted program as if it had been embedded in a nested series of quoted programs, e.g.:
Problem I. The reduction operator / of APL takes some binary operator ⨁ on its left and a vector x of values on its right. The meaning of ⨁/x for x = [a b ... z] is the value a⨁b⨁...⨁z. For this to be well-defined in the absence of brackets, the operation ⨁ has to be associative. Now there is another operator \ of APL called scan. Its effect is closely related to reduction in that we have:
+
+
⨁\x = [a a⨁b a⨁b⨁c ... a⨁b⨁...⨁z]
+
+
+
+
The problem is to find some definition of scan as a reduction. In other words, we have to find some function f and an operator ⨂ so that
If the combiner and the generator both need to work on the current value then dup must be used, and the generator must produce one item instead of two (the b is instead the duplicate of a.)
+
H3 == [P] [pop c] [[G] dupdip] [dip F] genrec
+
+... a [G] dupdip [H3] dip F
+... a G a [H3] dip F
+... a′ a [H3] dip F
+... a′ H3 a F
+... a′ [G] dupdip [H3] dip F a F
+... a′ G a′ [H3] dip F a F
+... a″ a′ [H3] dip F a F
+... a″ H3 a′ F a F
+... a″ [G] dupdip [H3] dip F a′ F a F
+... a″ G a″ [H3] dip F a′ F a F
+... a‴ a″ [H3] dip F a′ F a F
+... a‴ H3 a″ F a′ F a F
+... a‴ pop c a″ F a′ F a F
+... c a″ F a′ F a F
+... d a′ F a F
+... d′ a F
+... d″
+
That leaves the last item in our list, then it puts an empty list on the stack and swons's the new terms onto that. If we leave out that empty list, they will be swons'd onto that list that already has the last item.
Define a line to be a sequence of characters not containing the newline character. It is easy to define a function Unlines that converts a non-empty sequence of lines into a sequence of characters by inserting newline characters between every two lines.
+
Since Unlines is injective, the function Lines, which converts a sequence of characters into a sequence of lines by splitting on newline characters, can be specified as the inverse of Unlines.
+
The problem, just as in Problem 1. is to find a definition by reduction of the function Lines.
The SymPy package provides a powerful and elegant "thunk" object that can take the place of a numeric value in calculations and "record" the operations performed on it.
+
We can create some of these objects and put them on the Joy stack:
The SypPy Symbols will become the symbolic expression of the math operations. Unfortunately, the library sqrt function doesn't work with the SymPy objects:
+$$\frac{1}{2 a} \left(- b - \sqrt{- 4 a c + b^{2}}\right)$$
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In [11]:
+
+
+
root2
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Out[11]:
+
+
+
+
+
+$$\frac{1}{2 a} \left(- b + \sqrt{- 4 a c + b^{2}}\right)$$
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
At some point I will probably make an optional library of Joy wrappers for SymPy functions, and either load it automatically if SymPy installation is available or have a CLI switch or something. There's a huge amount of incredibly useful stuff and I don't see why Joy shouldn't expose another interface for using it. (As an example, the symbolic expressions can be "lambdafied" into very fast versions, i.e. a function that takes a, b, and c and computes the value of the root using just low-level fast code, bypassing Joy and Python. Also, Numpy, &c.)
u k 1 # z = 1
+ [pop] [Fw] while # the while statement
+ popopd # discard u k, "return" z
+
+
+
+
+
+
+
+
+
+
+
+
+
What's Fw?
+
u k z [pop odd] [Ft] [] ifte # the if statement
+ [2 //] dip # k = k / 2 floordiv
+ [sqr] dipd # u = u * u
+
+ [[sqr] dip 2 //] dip # We can merge last two lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
Helper function Ft (to compute z = z * u).
+
u k z Ft
+---------------
+ u k u*z
+
+
+Ft == [over] dip *
+
+
+
+
+
+
+
+
+
+
+
+
+
Putting it together:
+
Ft == [over] dip *
+Fb == [[sqr] dip 2 //] dip
+Fw == [pop odd] [Ft] [] ifte Fb
+ F == 1 [pop] [Fw] while popopd
+
+
+
+
+
+
+
+
+
+
+
In [14]:
+
+
+
define('odd == 2 %')
+
+
+
+
+
+
+
+
+
+
+
+
+
In [15]:
+
+
+
define('Ft == [over] dip *')
+
+
+
+
+
+
+
+
+
+
+
+
+
In [16]:
+
+
+
define('Fb == [[sqr] dip 2 //] dip')
+
+
+
+
+
+
+
+
+
+
+
+
+
In [17]:
+
+
+
define('Fw == [pop odd] [Ft] [] ifte Fb')
+
+
+
+
+
+
+
+
+
+
+
+
+
In [18]:
+
+
+
define('F == 1 [pop] [Fw] while popopd')
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Try it out:
+
+
+
+
+
+
+
+
+
+
In [19]:
+
+
+
J('2 5 F')
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
32
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In order to elide the tests let's define special versions of while and ifte:
u 5 . F
+ u 5 . 1 [pop] [Fw] while popopd
+ u 5 1 . [pop] [Fw] while popopd
+ u 5 1 [pop] . [Fw] while popopd
+ u 5 1 [pop] [Fw] . while popopd
+ u 5 1 . Fw [pop] [Fw] while popopd
+ u 5 1 . [pop odd] [Ft] [] ifte Fb [pop] [Fw] while popopd
+ u 5 1 [pop odd] . [Ft] [] ifte Fb [pop] [Fw] while popopd
+ u 5 1 [pop odd] [Ft] . [] ifte Fb [pop] [Fw] while popopd
+ u 5 1 [pop odd] [Ft] [] . ifte Fb [pop] [Fw] while popopd
+ u 5 1 . Ft Fb [pop] [Fw] while popopd
+ u 5 1 . [over] dip * Fb [pop] [Fw] while popopd
+ u 5 1 [over] . dip * Fb [pop] [Fw] while popopd
+ u 5 . over 1 * Fb [pop] [Fw] while popopd
+ u 5 u . 1 * Fb [pop] [Fw] while popopd
+ u 5 u 1 . * Fb [pop] [Fw] while popopd
+ u 5 u . Fb [pop] [Fw] while popopd
+ u 5 u . [[sqr] dip 2 //] dip [pop] [Fw] while popopd
+ u 5 u [[sqr] dip 2 //] . dip [pop] [Fw] while popopd
+ u 5 . [sqr] dip 2 // u [pop] [Fw] while popopd
+ u 5 [sqr] . dip 2 // u [pop] [Fw] while popopd
+ u . sqr 5 2 // u [pop] [Fw] while popopd
+ u . dup mul 5 2 // u [pop] [Fw] while popopd
+ u u . mul 5 2 // u [pop] [Fw] while popopd
+ u**2 . 5 2 // u [pop] [Fw] while popopd
+ u**2 5 . 2 // u [pop] [Fw] while popopd
+ u**2 5 2 . // u [pop] [Fw] while popopd
+ u**2 2 . u [pop] [Fw] while popopd
+ u**2 2 u . [pop] [Fw] while popopd
+ u**2 2 u [pop] . [Fw] while popopd
+ u**2 2 u [pop] [Fw] . while popopd
+ u**2 2 u . Fw [pop] [Fw] while popopd
+ u**2 2 u . [pop odd] [Ft] [] ifte Fb [pop] [Fw] while popopd
+ u**2 2 u [pop odd] . [Ft] [] ifte Fb [pop] [Fw] while popopd
+ u**2 2 u [pop odd] [Ft] . [] ifte Fb [pop] [Fw] while popopd
+ u**2 2 u [pop odd] [Ft] [] . ifte Fb [pop] [Fw] while popopd
+ u**2 2 u . Fb [pop] [Fw] while popopd
+ u**2 2 u . [[sqr] dip 2 //] dip [pop] [Fw] while popopd
+ u**2 2 u [[sqr] dip 2 //] . dip [pop] [Fw] while popopd
+ u**2 2 . [sqr] dip 2 // u [pop] [Fw] while popopd
+ u**2 2 [sqr] . dip 2 // u [pop] [Fw] while popopd
+ u**2 . sqr 2 2 // u [pop] [Fw] while popopd
+ u**2 . dup mul 2 2 // u [pop] [Fw] while popopd
+ u**2 u**2 . mul 2 2 // u [pop] [Fw] while popopd
+ u**4 . 2 2 // u [pop] [Fw] while popopd
+ u**4 2 . 2 // u [pop] [Fw] while popopd
+ u**4 2 2 . // u [pop] [Fw] while popopd
+ u**4 1 . u [pop] [Fw] while popopd
+ u**4 1 u . [pop] [Fw] while popopd
+ u**4 1 u [pop] . [Fw] while popopd
+ u**4 1 u [pop] [Fw] . while popopd
+ u**4 1 u . Fw [pop] [Fw] while popopd
+ u**4 1 u . [pop odd] [Ft] [] ifte Fb [pop] [Fw] while popopd
+ u**4 1 u [pop odd] . [Ft] [] ifte Fb [pop] [Fw] while popopd
+ u**4 1 u [pop odd] [Ft] . [] ifte Fb [pop] [Fw] while popopd
+ u**4 1 u [pop odd] [Ft] [] . ifte Fb [pop] [Fw] while popopd
+ u**4 1 u . Ft Fb [pop] [Fw] while popopd
+ u**4 1 u . [over] dip * Fb [pop] [Fw] while popopd
+ u**4 1 u [over] . dip * Fb [pop] [Fw] while popopd
+ u**4 1 . over u * Fb [pop] [Fw] while popopd
+ u**4 1 u**4 . u * Fb [pop] [Fw] while popopd
+ u**4 1 u**4 u . * Fb [pop] [Fw] while popopd
+ u**4 1 u**5 . Fb [pop] [Fw] while popopd
+ u**4 1 u**5 . [[sqr] dip 2 //] dip [pop] [Fw] while popopd
+u**4 1 u**5 [[sqr] dip 2 //] . dip [pop] [Fw] while popopd
+ u**4 1 . [sqr] dip 2 // u**5 [pop] [Fw] while popopd
+ u**4 1 [sqr] . dip 2 // u**5 [pop] [Fw] while popopd
+ u**4 . sqr 1 2 // u**5 [pop] [Fw] while popopd
+ u**4 . dup mul 1 2 // u**5 [pop] [Fw] while popopd
+ u**4 u**4 . mul 1 2 // u**5 [pop] [Fw] while popopd
+ u**8 . 1 2 // u**5 [pop] [Fw] while popopd
+ u**8 1 . 2 // u**5 [pop] [Fw] while popopd
+ u**8 1 2 . // u**5 [pop] [Fw] while popopd
+ u**8 0 . u**5 [pop] [Fw] while popopd
+ u**8 0 u**5 . [pop] [Fw] while popopd
+ u**8 0 u**5 [pop] . [Fw] while popopd
+ u**8 0 u**5 [pop] [Fw] . while popopd
+ u**8 0 u**5 . popopd
+ u**5 .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
In [22]:
+
+
+
result
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Out[22]:
+
+
+
+
+
+$$u^{5}$$
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Let's try partial evaluation by hand and use a "stronger" thunk.
+
Caret underscoring indicates terms that form thunks. When an arg is unavailable for a computation we just postpone it until the arg becomes available and in the meantime treat the pending computation as one unit.
+
u 5 . F
+ u 5 . 1 [pop] [Fw] while popopd
+ u 5 1 . [pop] [Fw] while popopd
+ u 5 1 [pop] . [Fw] while popopd
+ u 5 1 [pop] [Fw] . while popopd
+ u 5 1 . Fw [pop] [Fw] while popopd
+ u 5 1 . [pop odd] [Ft] [] ifte Fb [pop] [Fw] while popopd
+ u 5 1 [pop odd] . [Ft] [] ifte Fb [pop] [Fw] while popopd
+ u 5 1 [pop odd] [Ft] . [] ifte Fb [pop] [Fw] while popopd
+ u 5 1 [pop odd] [Ft] [] . ifte Fb [pop] [Fw] while popopd
+ u 5 1 . Ft Fb [pop] [Fw] while popopd
+ u 5 1 . [over] dip * Fb [pop] [Fw] while popopd
+ u 5 1 [over] . dip * Fb [pop] [Fw] while popopd
+ u 5 . over 1 * Fb [pop] [Fw] while popopd
+ u 5 u . 1 * Fb [pop] [Fw] while popopd
+ u 5 u 1 . * Fb [pop] [Fw] while popopd
+ u 5 u . Fb [pop] [Fw] while popopd
+ u 5 u . [[sqr] dip 2 //] dip [pop] [Fw] while popopd
+ u 5 u [[sqr] dip 2 //] . dip [pop] [Fw] while popopd
+ u 5 . [sqr] dip 2 // u [pop] [Fw] while popopd
+ u 5 [sqr] . dip 2 // u [pop] [Fw] while popopd
+ u . sqr 5 2 // u [pop] [Fw] while popopd
+ u . dup mul 5 2 // u [pop] [Fw] while popopd
+ u dup * . 5 2 // u [pop] [Fw] while popopd
+ ^^^^^^^
+
+
+
+
+
+
+
+
+
+
+
+
+
u dup * 2 u [pop] [Fw] . while popopd
+ u dup * 2 u . Fw [pop] [Fw] while popopd
+ u dup * 2 u . [pop odd] [Ft] [] ifte Fb [pop] [Fw] while popopd
+ u dup * 2 u [pop odd] . [Ft] [] ifte Fb [pop] [Fw] while popopd
+ u dup * 2 u [pop odd] [Ft] . [] ifte Fb [pop] [Fw] while popopd
+ u dup * 2 u [pop odd] [Ft] [] . ifte Fb [pop] [Fw] while popopd
+ u dup * 2 u . Fb [pop] [Fw] while popopd
+ u dup * 2 u . [[sqr] dip 2 //] dip [pop] [Fw] while popopd
+ u dup * 2 u [[sqr] dip 2 //] . dip [pop] [Fw] while popopd
+ u dup * 2 . [sqr] dip 2 // u [pop] [Fw] while popopd
+ u dup * 2 [sqr] . dip 2 // u [pop] [Fw] while popopd
+ u dup * . sqr 2 2 // u [pop] [Fw] while popopd
+ u dup * . dup mul 2 2 // u [pop] [Fw] while popopd
+ u dup * dup * . 2 2 // u [pop] [Fw] while popopd
+ ^^^^^^^^^^^^^
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
w/ K == u dup * dup *
+
K 1 u [pop] [Fw] . while popopd
+ K 1 u . Fw [pop] [Fw] while popopd
+ K 1 u . [pop odd] [Ft] [] ifte Fb [pop] [Fw] while popopd
+ K 1 u [pop odd] . [Ft] [] ifte Fb [pop] [Fw] while popopd
+ K 1 u [pop odd] [Ft] . [] ifte Fb [pop] [Fw] while popopd
+ K 1 u [pop odd] [Ft] [] . ifte Fb [pop] [Fw] while popopd
+ K 1 u . Ft Fb [pop] [Fw] while popopd
+ K 1 u . [over] dip * Fb [pop] [Fw] while popopd
+ K 1 u [over] . dip * Fb [pop] [Fw] while popopd
+ K 1 . over u * Fb [pop] [Fw] while popopd
+ K 1 K . u * Fb [pop] [Fw] while popopd
+ K 1 K u . * Fb [pop] [Fw] while popopd
+ K 1 K u * . Fb [pop] [Fw] while popopd
+ ^^^^^
+
+
+
+
+
+
+
+
+
+
+
+
+
w/ L == K u *
+
K 1 L . Fb [pop] [Fw] while popopd
+ K 1 L . [[sqr] dip 2 //] dip [pop] [Fw] while popopd
+ K 1 L [[sqr] dip 2 //] . dip [pop] [Fw] while popopd
+ K 1 . [sqr] dip 2 // L [pop] [Fw] while popopd
+ K 1 [sqr] . dip 2 // L [pop] [Fw] while popopd
+ K . sqr 1 2 // L [pop] [Fw] while popopd
+ K . dup mul 1 2 // L [pop] [Fw] while popopd
+ K K . mul 1 2 // L [pop] [Fw] while popopd
+ K K * . 1 2 // L [pop] [Fw] while popopd
+ ^^^^^
+ K K * . 1 2 // L [pop] [Fw] while popopd
+ K K * 1 . 2 // L [pop] [Fw] while popopd
+ K K * 1 2 . // L [pop] [Fw] while popopd
+ K K * 0 . L [pop] [Fw] while popopd
+ K K * 0 L . [pop] [Fw] while popopd
+ K K * 0 L [pop] . [Fw] while popopd
+ K K * 0 L [pop] [Fw] . while popopd
+ ^^^^^
+ K K * 0 L . popopd
+ L .
+
u . dup dup * dup * *
+ u u . dup * dup * *
+ u u u . * dup * *
+ u u**2 . dup * *
+u u**2 u**2 . * *
+ u u**4 . *
+ u**5 .
+
+
+
+
+
+
Out[23]:
+
+
+
+
+
+$$u^{5}$$
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
I'm not sure how to implement these kinds of thunks. I think you have to have support in the interpreter, or you have to modify all of the functions like dup to check for thunks in their inputs.
p == [0 =] [popop 1] [-- over] [dip *] genrec
+
+b n p
+b n [0 =] [popop 1] [-- over [p] dip *]
+
+b n -- over [p] dip *
+b n-1 over [p] dip *
+b n-1 b [p] dip *
+b n-1 p b *
+
+
+
+
+
+
+
+
+
+
+
+
+
curried, quoted
+
n p
+---------------------------------------------
+ [[n 0 =] [pop 1] [dup n --] [*] genrec]
+
