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 generics

Question 30 (2011):

Submission reference: IN2061

Hello there, I am wondering; is it possible to use an id-like process to link two channels of the same protocol without having to read the data from the protocol by yourself and re-send it along?

Answer 30:

Connecting two (same-protocol) channels with an id-like process yields a buffered channel with capacity 1. The CSP library for Java (JCSP) provides for the construction of occam-like (i.e. unbuffered) channels by default, but also for buffered channels of any capacity (including infinite) and varying kinds of buffering (blocking, like Choices slide 105, overflowing, slide 107, or overwriting, slide 108). At some time, it would probably be good to introduce this into occam-pi – it would be more convenient, safer and more efficient for the compiler to construct such buffering than the programmer.

A second point raised by your question is that of generics. It would be nice to be able to parametrise the types of messages carried by channels plugged in to processes that don't care. For example:

    PROC id <TYPE P> (CHAN P in?, out!)
      WHILE TRUE
        P m:
        SEQ
          in ? m
          out ! m
    :

Instances of such a generic process would have the obvious form – e.g.

    id <REAL64> (a?, b!)

which would instance an id process for channels carrying double-precision floating-point numbers.

However, defining the above idea is complicated by the current concept of message PROTOCOLs in occam-pi (see the Protocol slides, not yet covered in the course). It should probably wait for a more powerful type system for occam-pi (that is planned).

You are also asking, I think, for a syntactic sugaring that saves "having to read the data from the protocol by yourself and re-send it along"? Perhaps, something like:

    PROC id <TYPE P> (CHAN P in?, out!)
      WHILE TRUE
        out ! (in ?)
    :

or maybe:

    PROC id <TYPE P> (CHAN P in?, out!)
      WHILE TRUE
        in? > out!
    :

It's a thought! See also Question 56 (2010).

However, for all forms of engineering (such as language design), always consider Occam's Razor: "Numquam ponenda est pluralitas sine necessitate", which roughly translates to "Don't invent things you don't need" or "keep it as simple as possible". For programming languages, this means only adding mechanisms that are really needed ... where real need covers new ideas (that let us do useful things we couldn't do before) and more powerful forms of expression (that let us do common things more easily than we did before). We have to work hard to honour this principle. Software engineering constructs virtual artifacts – unconstrained by limits imposed by the physical world. As such, it's only too easy to build something complex that doesn't quite do the job ... than something simple that does.

Keywords: generics , protocol , occam , razor