nagler@seismo.CSS.GOV@olsen.UUCP (02/14/87)
Does anyone know if the BSI or other standards bodies are considering
the following Modula-2 issues?
1. What about TEENYWEENYINT and REALLYBIGREAL?
After using various implementations of LONGREAL and REAL, I have found a
great need for the standardization of the following types: ITTYBITTYREAL,
SMALLREAL, SHORTREAL, NOTSOBIGREAL, AVERAGEREAL, etc... Basically, I
would like to know if the standards people are going to fall into the
same trap into which C has fallen. Or, are they planning a standard,
extensible naming mechanism such as: CARDINAL32, CARDINAL16, REAL32,
REAL64, INTEGER36, CARDINAL60? It would be ashame to let history
repeat itself.
2. Type compatibility of Opaques, POINTER, and SYSTEM.ADDRESS.
It has been my experience that the following procedure and type should
be assignment compatible:
PROCEDURE UserSupplied( userObject : MyPrivatePtrOrOpaque;
dataFound : SomeService.Something );
DEFINITION MODULE SomeService;
TYPE
ToBeCalledOnMatch = PROCEDURE ( SYSTEM.ADDRESS, (* importer supplied *)
Something ); (* what was found *)
In implementing the impossibile, ADTs, I have found that the above
feature is very powerful when implementing generics, but at present
I have to force a type coercion of the procedure type in my UserSupplied
module. This may seem like a hack, but it is very useful when managing
a system of ``upcalls'' (call-backs, reverse importation, ...). The
unnecessary importation of SYSTEM into the User module is dissatisfying.
A type coercion of UserSupplied into ToBeCalledOnMatch is not really a
good idea. This idea is merely an extension of the automatic coercion
of SYSTEM.ADDRESS into POINTER (and vice-versa).
If anyone knows if these issues are being addressed (I haven't seen them
in the minutes of the BSI), please let me know. The points are trivial
to implement, but they could have a significant impact on the flexibility
and usefulness of the language.
Rob Nagler