Language peer sets for Juno: United States↑ United States/1985↑ Designed 1985 ↑ 1980s languages ↑ Fifth generation↑ Late Cold War↑
Juno(ID:1153/jun001)
alternate simple view
Country: United States
Designed 1985 Numerical constraint-oriented language for graphics applications. Solves its constraints using Newton-Raphson relaxation.
Inspired by writing figures for his thesis using Metafont and DRAW, the language itself is based on Dijkstra's calculus of guarded commands
this GREY PAINT BUTT ENDS 8 WIDTH STROKE (a, b), (b, c); STROKE (d, e); STROKE (e, f); ROUND ENDS STROKE (g, h); BUTT ENDS STROKE (i, j); SQUARE ENDS STROKE (k, i); FILL (n, m, o, p). (p, n); BLACK PAINT 3 WIDTH STROKE (n, m, o, p), (p, n); o, q WIDTH ROUND ENDS STROKE (q. q) draws this:
A submarine on a radar screen!
As an example, let us translate Euclid's proposition 1.1 into guarded e commands: "On a given line to construct an equilateral triangle. Let ab be the given line; thus it is required to describe on the line ab an equilateral triangle. With center a and distance ab let the circle c be described; and with center b and distance ba let the circle 4 be described; and let the circles c and d cut one another at e. Now I say that the triangle abe is equilateral. For, since b and e both lie on the circle c, ab is equal to ae ..." [4]. Euclid went on to prove what would today be called the partial correctness of his construction. Here is the construction expressed using guarded commands: LET c, d I Circle(c) AND Center(c) = a AND 0n(b, c) AND Circle(d) AND Center(d) = b AND 0n(a. d) IN LET e I Point(e) AND 0n(e. c) AND 0n(e. d) IN Draw (a, b), (b. e), (e, a) END END which not only constructs the point e, but also draws the sides of the triangle. The predicates Circle, Point, and On are used with their obvious meanings.
The construction above is not a legal Juno program, since firstly, variables in Juno range only over points, and secondly, the only four constraint types allowed in Juno are the following: (x, y) CONG (u, v): the distance from x to y equals the distance from u to v. (x. y) PARA (u, v): the direction from x to y parallels the direction from u to v. HOR(x, y): the direction from x to y is horizontal VER(x, y): the direction from x to y is vertical Note that any constraint expressible in the Euclidean theory of geometry can be expressed in terms of CONG and PARA. In particular, the collinearity of a, b, and c can be expressed (a, b) PARA (b, c). At least one additional constraint type is needed to orient images on the output pages, since these are not circular. Both H0R and VER were added, since to choose one of them would be asymmetric. Euclid's construction can still be succinctly expressed with the limited predicates available in Juno: LET e [ (a, e) CONG (a. b) AND (b. e) CONG (a, b) IN DRAW (a, b), (b. e). (e, a) END But we still don't have a legal Juno program, since we still have to settle the important issue: which of the two solutions for e will be introduced? The semantics of guarded commands say that either may be introduced; this is unacceptable, since the programmer must be given control over which triangle is to be drawn. One solution to this problem (the first that I tried) is to allow a fifth predicate, CO(x, y, z), which asserts that points x, y, and z are counter-clockwise. Then the constraints on e in the last command could be extended with cO(a, b, e) (to get the triangle shown in the illustration of Euclid's construction), or with CO(a, e, b) (to get the other triangle). Unfortunately, while the predicates C0NG, PARA: HOR and VER translate into polynomial equality constraints on the coordinates of the points, the predicate cc translates into a polynomial inequality constraint. [ tried to use a hybrid of the simplex and Newton-Raphson methods to handle these inequalities, but it didn't work very well. Here is a better solution: since the behavior of a numerical solver depends on the initial trial solution, Juno allows the program to give the solver a hint about where to look for the solution. The syntax LET x == u I P IN h END means the same thing,as LET x I P IN A END~ but it hints to the solver that the solution for x is likely to be in the vicinity of u. The "==" may be read "approximately equal to". No formal semantics can be given without describing the detailed behavior of the constraint solver, but from an operational point of view this is an obvious interface to a numerical solver. The notation (x, y) can be used to specify an absolute position in the Cartesian plane, but it is almost always better to specify a position relative to a coordinate system determined by given image points. So, the notation (m. y) REL (p. q) denotes the point whose coordinates are the real numbers x and y in the coordinate system determined by the points p and q as follows: p is the origin of the coordinate system and q is the point ( t . 0), that is, the tip of the unit x-vector. The rest of the coordinate system is determined by the condition that it be orthonormal and right-handed. Using complex arithmetic, (x. y) REL (p, q) can be defined to bep + (x + iy)(q - p). Putting this all together, we finally obtain the following Juno program for drawing an equilateral triangle on the segment ab, such that the new vertex e will make abe counterclockwise: Hint for E LET e == (1, 1) REL (a, b) Actual E + I (a, e) CONG (a. b) AND (b e) CONG (a, b) @ - ~ IN DRAW (a, b), (b, e), (e, a) END a b If " ( i , 1)" were changed to "(1, -t)" (or to any point in the bottom half-plane), then the triangle abe would come out clockwise.