XML CO538 Anonymous Questions and Answers Keyword Index

This page provides a keyword index to questions and answers. Clicking on a keyword will take you to a page containing all questions and answers for that keyword, grouped by year.

To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.

Keyword reference for long-lines

Question 104 (2004):

I have a quick question relating to my 'animation' - could you give any tips/ideas for nice(r) way of making the philosophers move about the screen without hard coding in the locations of every movement?

In my more 'advanced' animation (which has been a challenge to say the least) I have had a lot of hassle using a hard coded method. The code just to move a philosopher to the table (and it's currently not very smooth) is around 300 lines. Ouch.

I am sure there is a better way of doing things but I have racked my brains and I can't think of anything :(. The only other idea was to create a "large" VAL [][5][2]BYTE array that stored all the locations, and for each movement the required value is pulled out the array. That doesn't seem much nicer though; occam doesn't seem to allow you to span this sort of thing over multiple lines either.

Any sort of help would be greatly appreciated, however small!

Answer 104:

If ever you find yourself writing long sequences of repetitive code, where the differences are primarily in number values, you are doing something wrong, ugly and inefficient! So, your 300 lines of code is not a good idea.

Your 'better way' is much better, although it can be improved (see towards the end of this answer). Your VAL [][5][2]BYTE is, presumably, a 2-dimensional array of coordinates (i.e. [2]BYTEs), with the [5] index being for the philosophers and the unsized outermost dimension (i.e. []) being for the number of coordinates (i.e. the length of the path). That might make slightly more sense (and convenience for programming) with the two outer dimensions swapped around -- i.e. VAL [5][][2]BYTE.

occam does allow long lines to be broken across multiple lines ... but maybe I never told you! You can break a long line after commas, operators and the keyword IS. For example, the very long one-line declaration:

  VAL [n.phils][][2]BYTE path IS [[[13, 12], [14, 12], [14, 13], [14, 14], [14, 15]], [[23, 12], [24, 12], [24, 13], [24, 14], [24, 15]], [[33, 22], [34, 22], [34, 23], [34, 24], [34, 25]], [[83, 82], [84, 82], [84, 83], [84, 84], [84, 85]], [[93, 92], [94, 92], [94, 93], [94, 94], [94, 95]]]:

can be much more readibly laid out:

  VAL [n.phils][][2]BYTE path IS
    [[[13, 12], [14, 12], [14, 13], [14, 14], [14, 15]],
     [[23, 12], [24, 12], [24, 13], [24, 14], [24, 15]],
     [[33, 22], [34, 22], [34, 23], [34, 24], [34, 25]],
     [[83, 82], [84, 82], [84, 83], [84, 84], [84, 85]],
     [[93, 92], [94, 92], [94, 93], [94, 94], [94, 95]]]:

The rule about indentation for continuation lines is that any indentation at least as great as the initial line is allowed. So, the following, rather stupid, layout is also possible:

  VAL [n.phils][][2]BYTE path IS
    [[[13, 12], [14, 12], [14, 13], [14, 14], [14, 15]],
           [[23, 12], [24, 12], [24, 13], [24, 14], [24, 15]],
  [[33, 22], [34, 22], [34, 23], [34, 24], [34, 25]],
   [[83, 82], [84, 82], [84, 83], [84, 84], [84, 85]],
         [[93, 92], [94, 92], [94, 93], [94, 94], [94, 95]]]:

but we wouldn't, of course, ever do that! Another use of breaking lines after commas we have seen lots of times -- in PROC headers with long parameter lists:

  PROC thing (CHAN OF INT in0, in1,
	      CHAN OF BYTE keyboard, screen, error,
	      VAL INT id, interval,
	      [][]REAL64 data)

instead of:

  PROC thing (CHAN OF INT in0, in1, CHAN OF BYTE keyboard, screen, error, VAL INT id, interval, [][]REAL64 data)

Breaking lines after operators helps keep large expressions neat -- for example:

    first := (first - second) + ( ((-first) + (third - second)) * (rotational.torque - (ratio/2)) )

could be written:

    first := (first - second) +
	       ( ((-first) + (third - second)) *
		 (rotational.torque - (ratio/2)) )

which might help a little.

Getting back to improving your path description for a wandering philosopher ... rather than declare a table of absolute coordinates for each path position, consider a table of relative movements. For example:

  VAL [n.phils][][2]BYTE path IS
    [[[left, 3], [up, 5], [right, 2], [up, 4], [left, 1], [down, 2]],
     [[down, 8], [up, 3], [left, 6], [down, 1], [left, 6], [down, 3]],
     [[right, 3], [down, 2], [right, 8], [down, 9], [right, 1], [down, 5]],
     [[up, 5], [left, 5], [down, 2], [up, 2], [down, 1], [up, 3]],
     [[up, 9], [right, 9], [up, 2], [left, 2], [up, 3], [left, 6]]]:

where your movement code interprets [left, 3] as "move left 3 places" etc. Predeclared, of course, would need to be something like:

  VAL BYTE left IS 0:
  VAL BYTE right IS 1:
  VAL BYTE up IS 2:
  VAL BYTE down IS 3:

Elsewhere would be needed a table of absolute start coordinates for each path movement.

That just leaves the problem that all the above path lengths have to be the same length? With the modern occam-pi language, that's not a problem ... we can use dynamically sized mobile arrays. For classical occam, you could pad out short paths with some dummy movement elements - e.g. STAY where:

  VAL BYTE stay IS 255:

  VAL [2]BYTE STAY IS [stay, 0]:

  VAL [n.phils][][2]BYTE path IS
    [[[left, 3], [up, 5], [right, 2], [up, 4], STAY, STAY],
     [[down, 8], [up, 3], [left, 6], [down, 1], [left, 6], STAY],
     [[right, 3], [down, 2], [right, 8], [down, 9], [right, 1], [down, 5]],
     [[up, 5], [left, 5], STAY, STAY, STAY, STAY],
     [[up, 9], [right, 9], [up, 2], [left, 2], [up, 3], STAY]]:

Keywords: q7 , animation , long-lines

Referrers: Question 43 (2009) , Question 30 (2008)