Final edits to README, ready for 1.0 release.
catseye
11 years ago
0 | 0 | The Xoomonk Programming Language |
1 | 1 | ================================ |
2 | 2 | |
3 | Language version 1.0-PRE | |
3 | Language version 1.0 | |
4 | 4 | |
5 | 5 | Abstract |
6 | 6 | -------- |
530 | 530 | may be updated at any point. And, of course, this property is exploited in |
531 | 531 | the introduction of malingering stores. |
532 | 532 | |
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: | |
542 | 542 | |
543 | 543 | perimeter = { |
544 | 544 | # see example above |
546 | 546 | g := perimeter* & { x := 13 y := 6 } |
547 | 547 | print g.result |
548 | 548 | |
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.) | |
560 | 572 | |
561 | 573 | Happy malingering! |
562 | 574 |