Re: Normative types scalar_t is non-terminal right?

[Benjamin F. <ben...@he...>]

Marty

if you would consider to give your thoughts on the questions and
considerations below? I guess you would be the one who has the best idea
currently.

Am Samstag, 25. Februar 2012, 00:28:08 schrieb Benjamin Franksen:
> Am Freitag, 24. Februar 2012, 20:23:32 schrieb Marty Kraimer:
> > "PVData Meta Language" .
> It seems that in order to describe the 'normative types' in a way that is
> clear and unambiguous, it would need some extensions, though. But I could
> be wrong: maybe the problem lies deeper and in order to support the
> normative types pvData itself must be extended in non-trivial ways
> (support for either unions or type subsumption).

I remember that during the last EPICS meeting, there was some controversial
debate about globally fixed numbers (IDs) for the normative types.

Can someone summarize the current status?

I ask because having a fixed ID also fixes the question of type identity (for
the normative types, at least). If different types must have different IDs,
then something like NTArray that (with what pvData supports today) is not a
type, cannot have a fixed ID. Instead there must be

        NTBooleanArray, NTByteArray, ..., NTStringArray

each with a different type ID. This would settle Greg's question: writing

        structure NTArray
                scalar_t[] value

is just a scheme, it is not an actual type description. However, imagine some
more advanced type scheme that contains more than one field of type scalar_t,
like this (maybe a bit artificial) example:

        structure Converter
                scalar_t input
                scalar_t output

Here it is not a priori clear whether this a scheme with one parameter (so
that both input and output are supposed to be of the same scalar type) or
whether it is a scheme with two parameters (so that input and output may have
different type). The current notation cannot make the distinction clear
because it fails to designate the field type(s) as parameters to be passed to
the type scheme.

Apart from that, there is the issue of optional fields. Is

        NTBooleanArray1
                boolean[] value

actually the same type as

        NTBooleanArray2
                boolean[] value
                timestamp_t timestamp

? The introspection interface must say whether the timestamp field is present
or not, right? But if both get assigned the same type ID, then how can e.g. a
client implementation know which of those interfaces to return?

So, I think either pvData directly supports optionality of fields (support for
unions would subsume this, of course), or else we need different types for all
the variations (with or without timestamp, with or without status, severity,
etc. pp.) leading to a huge number of types.

I am certain these questions must have come up when trying to implement the
normative types as I gather already happened. Maybe the conclusions just need
to be written down and all becomes crystal clear?

Cheers
Ben

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführerin: Prof. Dr. Anke Rita Kaysser-Pyzalla

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de