Manipulating Particles of Type anytype

MLDesigner allows primitives to be written that will read and write particles of any type.

It is possible to declare inputs and outputs to be of type anytype. A primitive may need to do this, for example, if it simply copies its inputs without regard to type, as in the case of a Fork primitive, or if it calls a generic function that is overloaded by every data type, such as sink primitives which call the print method of the type.

The following is an example of a primitive that operates on anytype particles:

defprimitive
{
  name        { Fork }
  domain      { SDF }
  desc
  {
    Copies input to each output.
  }

  input
  {
    name { input }
    type { anytype }
  }

  outmulti
  {
    name { output }
    type { =input }
  }

  location { SDF main library }

  ccinclude {"kernel/Message.h","kernel/Type.h" }

  go
  {
    OutSDFMPHIter nextp(output);
    OutSDFPort* p;
    Particle& pp = input%0;
    Type *tType(0);
    if((pp.type() == DATASTRUCTTYPE) && (tType = (Type*)pp))
    {
      while ((p = (OutSDFPort*)nextp.next()) != 0)
        (*p)%0 << tType->clone();
    }
    else
    {
      while ((p = (OutSDFPort*)nextp.next()) != 0)
        (*p)%0 = pp;
    }
  }
}

It should be noticed that in the definition of the output port, the primitive simply says that its output type will be the same as the input type. Ptlang translates this definition into an ANYTYPE output porthole and a statement in the primitive constructor that reads

During module setup, the MLDesigner kernel assigns actual types to ANYTYPE ports, making use of the types of connected ports and inheritTypeFrom connections. For example, if a Fork input is connected to an output port of type INT, the Fork input’s type becomes INT, and, because of the inheritTypeFrom connection, the output will do, too. At runtime, there is no such thing as an ANYTYPE porthole. Every port has been resolved to some specific data type, which can be obtained from the porthole using the resolvedType() method. However, this mechanism does not differ among the various subclasses of Message, so if the programmer is using Message particles, he still needs to check the actual type of each Message received.

Porthole type assignment is really a fairly complex and subtle algorithm. The important properties for a primitive writer to know are these:

• If an input port has a specific declared type, it is guaranteed to receive particles of that type. For reasons mentioned in Reading Inputs and Writing Outputs, it should be preferred to explicitly cast input particles to the desired type, as in

go
{
  double value = double(in%0);
  ...
}

        but this is not strictly necessary in the current system.

• In simulation domains, an output port is NOT guaranteed to transmit particles of its declared type. The actual resolved type of the porthole will be determined by the connected input porthole. Therefore, the programmer should always allow type conversion of the value computed by the primitive into the actual type of the output particle. This happens implicitly when he writes something like

out%0 << t;

• because this expands into a call of the particle’s virtual method for loading a value of the given type. But assuming that the programmer knows the exact type of particle in the porthole, say by writing something like (FloatParticle&) (out%0), is very unsafe.
• In code generation domains, it is usually critical that the output porthole’s actual type to be what the primitive writer expected. Most codegen domains therefore splice type conversion primitives into the schematic when input and output ports of different declared types are connected. In this way, both connected primitives will see the data type they expect, and the necessary type conversion is handled transparently.
• The component portholes of a multiporthole are separately type-resolved. Thus, if an input multiporthole is declared ANYTYPE, its component portholes might have different types at runtime. The component portholes of an output multiporthole can have different resolved types in any case, because they might be connected to inputs of different types.
• It is rarely a good idea to declare a pure ANYTYPE output porthole. Its type should be equated to some input porthole using the ptlang = port notation instead or an explicit inheritTypeFrom call. This ensures that the type resolution algorithm can succeed. A ”pure ANYTYPE” output will work only while connected to an input of determinable type. If it’s connected to an ANYTYPE input, the kernel will be unable to resolve a type for the connection. By providing a = type declaration, the programmer allows the kernel to choose an appropriate particle type for an ANYTYPE-to-ANYTYPE connection.