Chronological Thread 

< Chronological >      < Thread >

---

Hi all,

In response to a request by Poul Nielsen, I have produced a model
demonstrating how this functionality might be used.

type_library.cellml is the beginnings of a type library, which provides
a complex number type and some other types needed to support it. The
complex number type is actually a function which takes a 'base type' and
returns a type. For example, if you wanted to represent a 'vector' in a
plane in metres as a complex number, you can call the function which
returns a type with real_metres as the argument to get a type for
storing a number of metres. This form implicitly requires that both
cartesian co-ordinates have the same type.

Also included is a library of utilities for working with these complex
numbers to get the cartesian and polar co-ordinates.

Writing this up has identified several places where there is room for
improvement:
=> We require that the type attribute is present on variables in every
component it is used (not just one of them), and these types are also
variables which must be present everywhere. If types are all of type
type, this isn't as bad, because it means that we only require one extra
variable. However, if we only required that the type attribute was
present in one of the connected network of variables (but allowed it to
be present in more as long as the types match) we would reduce the
burden on model authors.
=> Wildcard types, or even some sort of type inheritance scheme once
more looks quite helpful. For example, we have a function called 'sign'
which returns 1, 0, or -1 depending on the sign of the input. But we
have to explicitly say what the type of the input is (not just 'any kind
of real number' for instance). There will be many similar cases.
Sometimes this is a good thing as it provides additional type safety,
but in other cases, it is bad. We could have a unidirectional concept of
compatibility as used in inheritance hierarchies (so for example,
real_metre matches real_anything, but real_anything doesn't match
real_metre, since real_metre inherits from real_anything). This can be
worked around by using functions which return types, or by using the
trick we used in type_utilities of having a variable you connect up to
correct type, but the cost of having one import or defining a type just
to call a basic function puts a lot of burden on model authors and makes
models rather verbose.

Best wishes,
Andrew

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: type_library.cellml
URL:
<http://www.cellml.org/pipermail/cellml-discussion/attachments/20090218/b18103c8/attachment.diff>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: type_utilities.cellml
URL:
<http://www.cellml.org/pipermail/cellml-discussion/attachments/20090218/b18103c8/attachment-0001.diff>

---

• [cellml-discussion] Example models using possible CellML 1.2 lambda calculus type system notation, Andrew Miller, 02/18/2009

---

Archive powered by MHonArc 2.6.18.