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 type-mismatch

Question 22 (2003):

Can you tell me why I get the following error message ?

    black.hole(interrupt) -- type mismatch for parameter 1 in call of black.hole

Answer 22:

The PROC header for `black.hole' is:

    PROC black.hole (CHAN OF BYTE in)

The only reasonable explanation is that you're trying to pass a channel parameter that's not a `CHAN OF BYTE'. If you need an INT `black.hole', this can be easily created by modifying the existing `black.hole', but make sure you call yours something different (like `int.black.hole', for example). The source for the existing `black.hole' can be found on raptor in:

    /usr/local/courses/co516/libsrc/utils.occ

(or, from windows, `\\raptor\files\courses\...').

Keywords: type-mismatch

Question 20 (2001):

What does this error mean?

  Type mismatch for parameter 1 in call of equal.string ...

Answer 20:

It means what it says: you have supplied, as the first argument to a call of equal.string, something whose type does not match the type declared for its first parameter! Now, equal.string takes two []BYTE (i.e. BYTE array) parameters. So, that's what you must supply ...

Keywords: type-mismatch

Question 73 (2000):

I have the following code:

    VAL INT i.mod.n IS i\n:
    in[i.mod.n] ? CASE
      thinking
        SEQ
          cursor.x.y (1, (i.mod.n * 4) + 5, screen)

which generates an error saying that the operator * has operand of different types. Is 4 not an INT as I assumed it would be? Or is it because i.mod.n is a VAL INT and 4 is a plain INT?

If it is the latter, surely not allowing a VAL INT to be muliplied together by an INT is being rather pedantic - seeing as they are obviously both INTs.

Anyway, as to a solution, is there any reason why i.mod.n is a VAL INT rather than just a plain INT which would allow me to mutiply with it without having to define all my other values as VAL INTs?

Answer 73:

The first two parameters for cursor.x.y are screen coordinates and they are of type BYTE - so BYTEs must be supplied.

The compiler looks for a BYTE as the first parameter and finds a 1 - that'll do! When it looks at the second argument, it finds an expression - an addition of two operands. The result has to be a BYTE which implies that both those operands must be BYTEs. The right operand is 5 - which is fine. The left operand is another expression - a multiplication of two operands. That result must be a BYTE and so, therefore, must be its two operands. Now, the right operand is 4 - which is fine. But the left operand is i.mod.n, which is an INT - not a BYTE. Error!

occam has a very simple rule about binary operators in expressions: both operands must have the same type and the same precision and the result has that same type and precision. There is no automatic casting between types - all casts, if needed, must be explicitly programmed. What-you-see-is-what-you-get.

Your other points about VAL are not relevant. VALs have no impact on types. A named VAL INT has INT type and may be freely added/multiplied/etc. with other INTs (whether VAL INTs or variable INTs). We want i.mod.n to ba a VAL because we don't ever need to change it - declaring it as a VAL will get the compiler to reject any code we might mistakenly write that tries to change its value.

To correct your code, you can't just declare i.mod.n to be a VAL BYTE. This is because it is used to index an array and array indices are always INTs. Instead, cast it at the point in your code where it needs to be a BYTE:

          cursor.x.y (1, ((BYTE i.mod.n) * 4) + 5, screen)

Of course, you have to be sure that evaluation of the above expression will always remain within the legal bounds of a BYTE (which are 0 through 255 inclusive). Hopefully, this will be the case.

Note: the above expression will cause the arithmetic to be performed using BYTE arithmetic. The following code causes INT arithmetic to be used (which on a SPARC or Pentium etc. will be more efficient - although that would not be not the case if we were compiling directly into silicon) and only casts the result into the needed BYTE:

          cursor.x.y (1, BYTE ((i.mod.n * 4) + 5), screen)

Keywords: type-mismatch , cast

Referrers: Question 32 (2012) , Question 89 (2003) , Question 74 (2000)

Question 66 (2000):

For question 7, I am trying to draw a boarder for the dining philosophers room. I can do it with lots of cursor.x.y and out.string procedures but this seems time consuming. I thought of doing it in a replicated PAR or replicated SEQ and I wrote this code:

  #INCLUDE "consts.inc"
  #USE "course.lib"

  PROC a (CHAN OF BYTE out)
    PAR i = 1 FOR 26
      SEQ
        cursor.x.y (4, i, out)
        out.string ("#", 0, out)
  :

  PROC test (CHAN OF BYTE keyboard, screen, error)
    PAR
      a (screen)
      ...  other things
  :

But when I compile it, it says there is a type mismatch in parameter 2 of cursor.x.y. This is the y coordinate that I am changing so that the character gets printed on the line below the first one to create a column like this:

      #
      #
      #
      #
      #
      #

Why does the compiler not like the second parameter of the cursor.x.y proceedure? Doesen't it just need to be a number?

Answer 66:

The second parameter of cursor.x.y needs to be a BYTE. Replicator control variables (e.g. your i) are INTs. You need to cast it into a BYTE:

        cursor.x.y (4, BYTE i, out)

See the answer to Question 7 (2000) for information on casting between occam types.

Your PAR replicator also won't work because it implies parallel outputs to the out channel - illegal! So it has to be a SEQ replicator. In any case, unless the occam kernel supports, and is running on a multiprocessor machine, the SEQ replicator for code like this will be faster than a PAR (which will have to startup and shutdown 25 software processes).

Your code would also be slightly snappier with:

  PROC a (CHAN OF BYTE out)
    SEQ
      cursor.x.y (4, 1, out)
      SEQ i = 1 FOR 26            -- the "2" could be anything though
        SEQ
          out ! '#'               -- don't need out.string for a single char
          cursor.down (1, out)
          cursor.left (1, out)
      out ! FLUSH

Keywords: q7 , type-mismatch , cast , cursor

Referrers: Question 32 (2012) , Question 21 (2001) , Question 74 (2000)

Question 43 (2000):

What's the problem here?

  PROC invert (CHAN OF INT a, c, CHAN OF BYTE b)
    INT factor:
    SEQ
      ...  stuff
      c ! (a * factor)      -- compiler gives error here
      ...  more stuff
  :

The error message is:

  Operands have different types for operator "*".

As far as I can see they are not different types. Any ideas?

Answer 43:

But they are different types. Your a is a channel (that happens to carry integers) and your factor is a variable (that happens to hold integers). Multiplication operates over numeric data (such as may be held in variables). Multiplication is not defined on channels - you can only input/output from/to them! You probably need to input an integer from channel a into another variable first.

Keywords: compiling , type-mismatch