git @ Cat's Eye Technologies Xoomonk / 27470ce
Final edits to README, ready for 1.0 release. catseye 11 years ago
2 changed file(s) with 34 addition(s) and 22 deletion(s). Raw diff Collapse all Expand all
00 The Xoomonk Programming Language
11 ================================
22
3 Language version 1.0-PRE
3 Language version 1.0
44
55 Abstract
66 --------
530530 may be updated at any point. And, of course, this property is exploited in
531531 the introduction of malingering stores.
532532
533 Xoomonk originally had an infix operator `&`, which takes two stores as its
534 arguments, at least one of which must be saturated, and evaluates to a third
535 store which is the result of merging the two argument stores. This result store
536 may be saturated even if only one of the argument stores was saturated, if
537 the saturated store gave all the values that the unsaturated store needed.
538 This operator was dropped because it is mostly syntactic sugar for assigning
539 each of the desired variables from one store to the other. However, it does
540 admittedly provide a very natural syntax, which orthogonally includes "named
541 arguments", when using unsaturated stores as procedures:
533 The original idea for Xoomonk had an infix operator `&`, which took two stores
534 as its arguments (at least one of which must be saturated) and evaluated to a
535 third store which was the result of merging the two argument stores. This
536 result store may be saturated even if only one of the argument stores was
537 saturated, if the saturated store gave all the values that the unsaturated
538 store needed. This operator was dropped because it is mostly just syntactic
539 sugar for assigning each of the desired variables from one store to the other.
540 However, it does admittedly provide a very natural syntax, which orthogonally
541 includes "named arguments", when using unsaturated stores as procedures:
542542
543543 perimeter = {
544544 # see example above
546546 g := perimeter* & { x := 13 y := 6 }
547547 print g.result
548548
549 Xoomonk 0.1 had slightly more sophisticated semantics for unsaturated stores.
550 (TODO: describe them here.) `$` was an prefix operator rather than a
551 Special Name, but having `$` refer to a global namespace was both simpler and
552 allowed the Special Name `^` for accessing the lexically enclosing store to be
553 removed.
554
555 Xoomonk, as a project, is also an experiment in _test-driven language
556 design_. As you can see, I've described the language with a series of
557 examples, written in (something close to) Falderal format, each of which
558 could be used as a test case. This should make implementing an interpreter
559 or compiler for the language much easier, when I get around to that.
549 Xoomonk 0.1 had slightly more sophisticated semantics for unsaturated stores
550 than Xoomonk 1.0 has. Specifically, there was a (fuzzy) idea that a variable
551 could be "unresolved", that is, assigned a value derived from variables which
552 were unassigned. Xoomonk 1.0 simplified this to assigned variables having
553 the value 0 until the store is saturated, and a store being saturated when
554 all of its unassigned variables have been given a value, even if some
555 assigned variables are used in the block before they have ever been assigned.
556 Xoomonk 1.0 also dropped the idea that the main program was a block.
557
558 In addition, in Xoomonk 0.1, `$` was an prefix operator rather than a
559 Special Name, and the Special Name `^` allowed access to the lexically
560 enclosing store of a block. While there is a certain elegance to this, it
561 was deemed overkill, and in Xoomonk 1.0, `$` was changed to a Special Name
562 which referred to a global store (which can be used to communicate values
563 between scopes without messing about with lexically enclosing "upvalues".)
564
565 Xoomonk, as a project, was also an early experiment in _test-driven language
566 design_. When Xoomonk 0.1 was released, the language was described only with
567 the set of examples (above) written in Falderal format, each of which both
568 illustrates some aspect of the language, and is used as a test case. When a
569 reference interpreter was implemented for Xoomonk 1.0, this made implementation
570 much easier. (Since Xoomonk 0.1 was released, I've used this technique
571 successfully for several other languages as well.)
560572
561573 Happy malingering!
562574
00 #!/usr/bin/env python
11
2 """An attempt to implement Xoomonk in Python.
2 """Reference interpreter for Xoomonk 1.0.
33
44 """
55