J. B. Wordsworth
Each issue has a number, and the number appears as the first element of the title of each section of the issue list. Issues should be referred to in writing as I-n, where n is the issue number.
Each issue has a name, and the name appears as the second element of the title of each section in the issue list
Each issue might have a status as the third element of the title of each section of the issue list. The issue can be rejected, accepted, implemented, deleted, reopened, withdrawn, or superseded. Unresolved issues have no status recorded for them.
Each issue should have an explanation in informal terms of what it is about.
The References paragraph lists the documents (except the minutes of meetings) that contain information of use to those discussing the issue.
The Position paragraph describes the history of the issue, and refers to the minutes of meetings in which the issue was discussed.
Issues are raised by consultation between the person wishing to raise an issue and the keeper of the list.
The index at the end of this document indexes the subjects of the issues by issue number.
Some abbreviations:
SCS is Hayes's Specification Case Studies.
SDWZ is Wordsworth's Software Development with Z.
ZLP is the Z Log Proposals. I believe it is D-8 and D-17, but I haven't got copies of either of these documents, and so am unable to verify it.
ZRM is Spivey's Z Reference Manual.
ZRM2 is Spivey's Z Reference Manual, 2nd edition..
Extend free type syntax to support a curried style.
EXPR ::= ... | sum <<EXPR>> <<EXPR>>
equivalent to
... sum: EXPR >->EXPR>->EXPR
with disjoint ranges
disjoint ... ran(ran sum )
and induction principle
... &union. sum (|S|)(|S|)
Spivey ZRM 1st edition p. 81. ZLP (7, 14).
Raised 13.03.90 (S. Valentine).
As well as hiding a list of variables, one might wish to hide all but a list of variables. This is the way schema projection is defined in Hayes, whereas the definition in Spivey requires another schema.
Spivey ZRM 1st edition, p. 76. Hayes SCS 1st edition, p. 21. ZLP (8). D-108. D-122.
Raised 13.04.90 (S. Valentine). Accepted a SRC meeting 12. The symbol to be a downward half-arrow. Reopened at meeting 45, for Susan Stepney.
Introduce WHERE phrases. These have been in and out of various Z syntaxes for some time. They really do represent a significant contribution to clarity and introduce no syntactic or semantic complications. The proposed extra syntax is as follows:
Predicate = UnivQuant
| ExistsQuant
| UniqueQuant
| WherePhrase
| LogPred;
WherePhrase = 'SR', AxiomPart, 'ER', 'where', AxiomaticDef;
'SR' and 'ER' are use for a rule to delimit the predicate part of the phrase. This particular form is introduced to allow stacking of both predicates and declarations within the phrase. It also means that the WHERE phrase is enclosed and could be introduced at a very low level in the syntax as a basic predicate, but it seems to belong naturally here as it is basically another variant of existential quantification.
Base Standard Version 0.3. Spivey ZRM 1st edition p. 71. Hayes SCS 1st edition pp. 104, 212, 234, 244. ZLP (10). D-88 (5.5). D-112 p. 7. D-113 p. 17.
Raised 13.03.90 (S. Valentine). Revived with an extended proposal at SRC meeting of 04.03.92 (C. T. Sennett). Rejected at SRC meeting 12.
Introduce a notation for set complement, the difference of the set and its underlying type. This would be useful for defining the complement of a relation, and elsewhere. Its absence means that the set functions do not form a proper Boolean algebra, De Morgan's Laws cannot be stated, etc.
Spivey ZRM 1st edition p. 90. ZLP (12).
Raised 15.03.90 (S. Valentine). Discussed at the Toolkit subcommittee meeting, 8 Nov 1994, and abandoned in favour of symmetric difference. Withdrawn at meeting 45.
The definition of overriding in Spivey is not appropriate for curried functions.
Spivey ZRM 1st edition p. 108.
Raised 15.03.90 (S. Valentine). Withdrawn at meeting 45.
Filter laws can be made more elegant and symmetrical if an anti-filter is used. (cf. range restriction and anti-restriction.)
s anti-filter V = s filter ((ran s)\V)
with laws
( ran(s filter V), ran(s anti-filter V) ) partition (ran s)
#s = #(s filter V) + #(s anti-filter V)
...
Spivey ZRM 1st edition p. 122. ZLP (13).
Raised 15.03.90 (S. Valentine).
What is Z? Is it a given language that has to be used as-is, or is it expected that it will be customised and extended by users for their own applications? How does it fit in with other branched of mathematics used to build models?
State a philosophy for Z. For example, say that it is a framework for developing mathematical models, using (any?) soundly based mathematical techniques. Explicitly indicate that there is a "base language" plus structuring mechanism - it is only the schemas that make it Z, and not another way of writing sets. Provide a sufficiently powerful mechanism for extending it as required - how to introduce new maths, how to manipulate, extend or modify the structuring mechanism.
ZLP (15, 26).
Raised 22.03.90 (S. Stepney). Accepted SRC meeting 12.
Add real numbers, and complex numbers. Add common transcendental functions.
Hayes's paper in 1989 Z User Meeting. D-34. ZLP (16).
Raised 22.03.90 (S. Stepney). Rejected SRC meeting 12.
There is no mechanism for defining new schema operators. Since schemas are the raison d' être of Z, this is a major omission.
Add a mechanism for defining schema operators. Use it to define the current schema operators.
Spivey ZRM 1st edition p. 74. Gravell's paper in 1989 Z User Meeting. ZLP (17, 23).
Raised 22.03.90 (S. Stepney, T. Hoverd). Rejected SRC meeting 12. Revived at meeting 18. A proposal is required.
Z syntax is a real pig, especially for writing tools. Either
throw it away and start again, or
make the pragmas necessitated by the current syntax part of the language. If a tool needs them, so does the reader.
Spivey ZRM 1st edition p. 48. fuzz reference manual.
Raised 22.03.90 (S. Stepney, T. Hoverd). Superseded at SRC 12 by I-27.
Bags need a proper bag algebra with a rich set of operators. (Bag union is not idempotent, so it might be more appropriately called bag addition.)
Spivey ZRM 1st edition p. 127. Hayes's paper in 1989 Z User Meeting. ZLP (19, 36).
Raised 22.03.90 (S. Stepney, T. Hoverd). Rejected at meeting 45.
The author of an informal document will write separate sections as separate files for editing convenience. To format and print the whole document, some imbedding mechanism is needed. A similar requirement exists in a formal document.
Add a Z imbed mechanism.
Raised 14.06.90 (M. A. McMorran). Superseded at SRC 12 by I-61.
Amend the declaration of the override operator to apply to relations.
Spivey ZRM 1st edition p. 108. ZLP (39).
Raised 14.06.90 (M. A. McMorran). Accepted at meeting 45.
Add schema overriding to the schema operations,
ZLP (40).
Raised 14.06.90 (M. A. McMorran). Rejected at SRC meeting 12. Other notations are available.
Distributed concatenation is rarely or never used in practice. Remove it.
ZLP (41).
Raised 14.06.90 (M. A. McMorran). Rejected at SRC meeting 14.
Declaration before use often imposes a clumsiness on presentation of specifications and designs.
Remove or clarify definition before use.
Spivey ZRM 1st edition p. 49. ZLP (42).
Raised 14.06.90 (M. A. McMorran). That definition before use is a required was accepted at SRC meeting 12. Reopened at meeting 45 for Sam Valentine.
Make a toolkit part of standard Z, and decide about other toolkits.
ZLP (30, 43).
Raised 14.06.90 (M. A. McMorran). Superseded by I-61 at SRC meeting 12.
Add a mechanism to allow users to define their own decoration symbols. How are names decorated?
D-88 (3.2). ZLP (44, 46).
Raised 14.06.90 (M. A. McMorran).
Spivey allows hiding of a list of variables, but not hiding of a schema. This leads to cumbersome specifications when the list is long, and during development of a specification if the state being hidden changes, the list has to be separately maintained. It is also difficult for readers to understand why certain variables are being hidden, whereas if we could easily say "hiding the variables of &Delta.S, it would be much clearer.
Extend schema hiding to allow a schema as the second operand, with meaning "hide all the names in the signature of this schema".
ZLP (45).
Raised 14.06.90 (G. Normington). Accepted in principle at SRC meeting 12, but notation still to be decided.
Provide a distinction between the schema and predicate quantifiers \forall, \exists and \exists_1. They will need to be disambiguated at some stage if the rules on the use of schemas are to be slackened.
Base Standard Version 0.3.
Raised at SRC meeting of 04.03.92 (S. M. Brien). This requirement is dealt with in other ways. Rejected at SRC meeting 12.
Permit an underscore under a relation to denote its use in an infix manner.
Base Standard Version 0.3. Spivey ZRM 2nd edition.
Raised at SRC meeting of 04.03.92 (S. M. Brien) and discussed there: Does this mean that the only way to make an inrel is to underline a word? What about prerel and infun? What is the purpose of it if it does not indicate the fixity? (C.T. Sennett). Rejected at SRC meeting 12 in favour of I-27.
Permit generic instantiation of generic infix functions.
Base Standard Version 0.3. D-112 p. 15.
Raised at SRC meeting of 04.03.92 (S. M. Brien). Accepted at SRC meeting 12.
Change the tuple production rule so that there must be at least two Expression0s. This change necessitates an addition to the rules for expression to accommodate and expression in parentheses, i. e. '(', Expression0, ')'.
Base Standard Version 0.3. D-112 p. 15.
Raised at SRC meeting of 04.03.92 (S. M. Brien) and accepted.
Add explicit binding constructors using the syntax </ x ~> y, ... z ~> a />.
Base Standard Version 0.3. D-112 p. 15.
Raised at SRC meeting of 04.03.92 (S. M. Brien). Accepted at SRC meeting 12.
Introduce IF-THEN-ELSE clauses. The current feeling on undefinedness seems to be that predicates always denote. This approach would allow a conventional sort of if-then-else construct to be added to Z.
It could have one of two forms:
(1) Either, a new sort of PRED:
PRED = if PRED then PRED else PRED
where "if A then B else C" is a shorthand for "(A and B) or (not A and C)".
All the PREDs must be well-typed.
(2) Or, a new sort of EXP:
EXP = if PRED then EXP else EXP
where "if A then E else F" means the value of E in those environments in which A is true, and the value of F in those environments in which A is false.
The PRED must be well-typed. Both expressions must have the same type, which is the type of the whole expression.
The first form would allow things like
if (pred) then x = (an expr) else x = (another expr)
whereas the second would allow
x = if (pred) then (an expr) else (another expr)
Base Standard Version 0.3. D-112 p. 13.
Raised at SRC meeting of 04.03.92 (S. Stepney). Option (2) accepted at SRC meeting 12.
Introduce LET phrases. These have been in and out of various Z syntaxes for some time. They really do represent a significant contribution to clarity and introduce no syntactic or semantic complications. The proposed extra syntax is as follows:
Predicate = UnivQuant
| ExistsQuant
| UniqueQuant
| LetPhrase
| LogPred;
LetPhrase = 'Let', 'SR', AbbreviationDefs, 'ER', 'in',
'SR', AxiomPart, 'ER';
AbbreviationDefs = Abbreviation, { Sep, Abbreviation };
Abbreviation = VarName, '==', Expression;
The Abbreviations differ from the global ones in not allowing generic sets. The rule delimiters 'SR' and 'ER' allow the stacking of definitions and predicates, and delimit the entire phrase.
Base Standard Version 0.3. D-88 (5.5). D-112 p. 7. ZLP (21).
Raised at SRC meeting of 04.03.92 (C. T. Sennett). Rejected at SRC meeting 12 in favour of substitution.
Allow for the definition of fixity at declaration. The proposed extra syntax is as follows:
SimpleDecl = DeclNameList, ':', Expression
| DeclNameList, ':', Expression, '<->' Expression;
DeclNameList = DeclName, {',', DeclName};
DeclName = Ident
| '_', Ident, '_'
| '_', Ident
| Ident, '_'
| Ident, '_', Ident
| '_', Ident, '_', Ident
| Ident, '_', Ident, '_'
Abbrev = Ident, [GenFormals]
| Ident, Ident
| Ident, Ident, Ident
Branch = DeclName
Taking these rules in turn, the changes from the Version 0.3 syntax are as follows:
SimpleDecl--the additional alternative allows for the definition of infixed relations.
DeclNameList--equivalent to the original.
DeclName--after the declaration the identifiers
have the following syntactic status:
| Ident | Ident |
| '_', Ident, '_' | InFun or InRel according to SimpleDecl |
| '_', Ident | PostFun |
| Ident, '_' | PreRel |
| Ident, '_', Ident | First EncOp, second Eop |
| '_', Ident, '_', Ident | First PostOp, second Eop |
| Ident, '_', Ident, '_' | First PreOp, second Eop |
Abbrev--this is equivalent for the generic sets.
After the definition the identifiers have the following syntactic
status:
| Ident [GenFormals] | Ident |
| Ident, Ident | First PreGen, second Ident(generic type) |
| Ident, Ident, Ident | First PreGen, others Ident(generic types) |
Branch--equivalent to original, but data type constructors are not allowed to be generic sets.
For Abbrev and Branch, Ident is used instead of VarName (which is presumably a mistake, as VarName allows for instantiation). The syntax for expressions also needs changing to allow for the new forms of fixity and the deletion of superscript. (Note that there is no provision for relational image in the Version 0.3 syntax, and there is no production rule for GenFormals.)
Should there be brackets around DeclName (i.e. do we differentiate between DeclName and VarName.)
Base Standard Version 0.3. D-88 (3.3, 4.1). D-112 pp. 3 to 5. ZLP (51).
Raised at SRC meeting of 04.03.92 (C. T. Sennett). Discussed at SRC meeting 12, where a proposal was made to extend the notation to allow ellipsis (...) and an arbitrary number of components as in D-88 p 15, Fixity, point 4. Discussed at SRC meeting 14, when Rob Arthan was asked to arrange a meeting to discuss it further.
Make the spot mandatory in definite descriptions.
DefnDescr = '&mu.'. SchemaText, '*', Expression
Version 0.3 allows the * Expression to be optional. To make this unambiguous, definite descriptions can only be allowed in enclosed expressions (basically within set comprehensions and within brackets). This means that most uses of a definite description will involve brackets, and it would be better to write the spot.
Base Standard Version 0.3. D-88 (5.3). D-112 p. 15. ZLP (50).
Raised at SRC meeting of 04.03.92 (C. T. Sennett). Rejected at SRC meeting 12.
Remove the semicolon as an alternative for low-priority AND. Replace it with ampersand.
Sep = N1;
A predicate with semicolons would look unpleasant.
Base Standard Version 0.3. D-112 pp. 10, 16.
Raised at SRC meeting of 04.03.92 (C. T. Sennett). Removal rejected, replacement with ampersand under review. Superseded by I-42 at SRC meeting 12.
Change names of production rules as follows:
GenericDef UniqueDef SUniquequant SUniqueQuant Schema Predicate Uniquequant UniqueQuant
Presumably the third one is a mistake in Version 0.3. The only serious one is UniqueDef instead of GenericDef: they are not always generic, but they should always be unique.
Base Standard Version 0.3.
Raised at SRC meeting of 04.03.92 (C. T. Sennett). All except the first proposal accepted at SRC meeting 12.
ZLP (4, 6, 27, 28).
Raised 11.06.92 (J. E. Nicholls). Discussed at SRC meeting 14. As there are many possible ways of presenting a proof it was felt that the standard should limit itself to providing a form for conjectures, discussed at I-43. The idea that a proof notation should be prescribed was rejected.
Alphabets and free variables should be included in the standard.
Raised 11.06.92 (S. M. Brien). Accepted at SRC meeting 12.
It should be possible to use renaming notation on declarations and bindings as well as schemas.
Raised 11.06.92 (S. M. Brien). At SRC meeting 12, Stephen Brien was asked to provide a proposal or a reference to a proposal in an existing document. At meeting 18 it was accepted in line with a decision to put declarations and schema texts in the same syntactic category as schemas. A proposal for concrete syntax is required. It was suggested that ZRM2's version of renaming should be used.
Raised 11.06.92 (S. M. Brien). At SRC meeting 12, Stephen Brien was asked to provide a proposal or a reference to a proposal in an existing document.
Given sets should be called given types, since that is what they are. The difference between types and sets causes confusion to newcomers, and we should do what we can to ameliorate this.
Free types should not be called structured sets, but structured types.
Raised 11.06.92 (S. M. Brien). Discussed at SRC meeting 12, when I-44 was absorbed by this one. Discussed at SRC meeting 14, but not resolved.
D-88 (7, 5.4, 9.2).
Raised 11.06.92 (S. M. Brien). Discussed at SRC meeting 12. Withdrawn at SRC meeting 14.
Bags are second class citizens and should be removed.
Raised 22.03.90 (S. Stepney, T. Hoverd). Rejected at SRC meeting 12.
ZLP (20, 38).
Raised 11.06.92 (S. M. Brien). Superseded at SRC meeting 12 by a new issue I-61.
Generic axioms should be allowed.
D-88 (10.6).
Raised Feb 1992 (R. D. Arthan). Accepted at SRC meeting 12.
The standard should define the meaning of Delta and Xi.
D-88 (9.3). ZLP (25, 29).
Raised 11.06.92 (S. M. Brien). At SRC meeting 12 the following was decided: The symbols Delta and Xi are conventions, and their meaning is not to be defined by the standard.
In the event that a variable "x" is used (other than on the left hand side of a colon) in a declaration whose signature contains "x", either:
The ZRM takes position (a). The current draft of the standard takes position (d). There is disagreement between members of the panel about which of options (b), (c) ,(d) is the most congenial to reasoning in Z. (R. B. Jones says (b), J. C. P Woodcock and S. M. Brien say (d)).
Raised 16.06.92 (R. B. Jones). Discussed at SRC meeting 12. At SRC meeting 14 Stephen Brien described modifications to the standard that would make the answer (c), but a decision was deferred pending advice from Roger Jones. Considered at meeting 18, but deferred.
Some members of the panel take the view that the rules in the ZRM relating to the elision of conjunctions and semicolons are arbitrary and unsatisfactory, and would prefer elision to be prohibited (while retaining ";" as a low priority conjunction for use in predicates as well as declarations). Should elision be retained, and if so what should the rules be about where this is permitted?
Spivey ZRM 1st edition. D-110, pp16. 17. D-124.
Raised 16.06.92 (R. B. Jones). Discussed at SRC meeting 12, but not resolved. Discussed at SRC meeting 13, when D-124 was presented.
Should conjectures be predicates or sequents?
Should a turnstile (|-) or a question mark turnstile (?|-) be used to distinguish them?
D-88 (10.5).
Raised 16.06.92 (R. B. Jones). Discussed at SRC meeting 12, but not resolved.
Given sets should be called given types, since that is what they are. The difference between types and sets causes confusion to newcomers, and we should do what we can to ameliorate this.
Free types should not be called structured sets, but structured types.
Raised 23.06.92 (R. Barden). Superseded at SRC meeting 12 by I-35.
Use subscript for generic instantiation. This avoids ambiguity and is aesthetically pleasing.
ZLP (49).
Raised (C. T. Sennett). Accepted at SRC meeting 12.
Provide schema piping as follows. Suppose A and B are two schemas, then define the expression A >> B as follows. Let strip be a syntactic function that operates on names to remove a concluding ? or !. Let Ao be the set of output names of A, that is the names declared in A that end with !, and let Bi be the set of input names of B, that is the names declared in B that end with ?. Let C be the intersection of strip Ao and strip Bi, so C is the set of undecorated outputs of A and undecorated inputs of B that match for the purposes of piping. Let ren be an injection that relates names in C to names that do not occur in either A or B. Let Aren be A with every x! output such that x is in C renamed by ren x, so Aren is A with the matching outputs renamed. Let Bren be B with every x? input such that x is in C renamed by ren x, so Bren is B with the matching inputs renamed. Then A >> B is the conjunction of Aren and Bren with the names in C hidden.
ZLP (3). Wordsworth SDWZ p. 142.
Raised 26.03.90 (T. King). A proposal (above) provided by J. B. Wordsworth. Discussed at meeting 18, but nothing decided.
Allow schemas to be decorated throughout their use.
D-88 (3.1).
Raised 28.02.92 (R. D. Arthan). Accepted at SRC meeting 12.
Do not allow "&urbarb." and ";" to be used both for schemas and for the toolkit.
D-88 (3.4). D-112 p.16.
Raised 28.02.92 (R. D. Arthan).
Have separate symbols for infix minus (subtraction) and prefix minus (negative).
D-88 (5.1).
Raised 28.02.92 (R. D. Arthan). Accepted at SRC meeting 12, with a long - for subtraction and a short - for negative.
Make {S} a singleton set.
D-88 (5.2). D-112 p. 16.
Raised 28.02.92 (R. D. Arthan). Accepted 08.04.92.
Have X.i as a way of projecting the ith element of a tuple X in a similar manner to the use of the dot notation for projecting elements of bindings.
D-88 (6). D-112 p. 2.
Raised by S. M. Brien and accepted 08.04.92.
Use bindings as substitutions.
D-77. D-88 (6.1).
Raised Oct 91 (S. M. Brien). Discussed at SRC meeting 12. The symbol &cdot. was chosen for application of a binding to an expression but other notations were not finalised.
D-88 (8). ZLP (24, 53).
Raised 28.02.92 (R. D. Arthan). Rejected at SRC meeting 12.
Allow infix syntax.
D-88 (10.1).
Raised 28.02.92 (R. D. Arthan).
Allow full substitution of expressions for schemas by removing all the syntactic restrictions that prevent an expression of type 'set of bindings' being freely interchangeable with a provably equivalent schema expression.
D-112 p. 11.
Raised 28.02.92 (R. D. Arthan). Accepted at SRC meeting 12. Discussed at meeting 18, but not decided.
Use same syntax for generic and axiomatic boxes.
D-112 p. 14.
Raised 28.02.92 (R. D. Arthan). Rejected at SRC meeting 12.
Change the grammar so as to reduce the need for parentheses.
Spivey ZRM 1st edition p. 145. ZLP (2).
Raised 26.03.92 (T. King). Accepted at SRC meeting 12.
Define a new operator for renaming components of schemas.
ZLP (3, 9, 32).
Raised 26.03.92 (T. King). Accepted at SRC meeting 12.
Provide a means of defining generic free types.
ZLP (5).
Raised 26.03.92 (T. King). At SRC meeting 14 it was felt that a generic free type could not be translated easily into an axiomatic description, so the proposal was rejected.
Provide lists of symbols.
Raised 26.03.92 (S. M. Brien), and implemented by him.
Establish a scheme of modularity.
D-121, D-113, Hayes and Wildman's paper in D-135.
Raised 26.03.92 (S. M. Brien). At SRC meeting 12, I-17 was superseded by this issue. At SRC meeting 13, Colin Parker's document D-121 was discussed. The issue of whether importation was a syntactic or semantic notion was discussed.
Make unary and binary minus part of the toolkit, not the base language.
Raised (S. M. Brien) at SRC meeting 14, and accepted there.
Partition the character set into base and toolkit, and remove inconsistencies in the lists in the standard.
D-132.
Raised (S. M. Brien) at SRC meeting 14. The resolution of this issue depends on the resolution of I-47 on fixity. The needs of Japanese and Greek writers and readers of Z were raised.
Inequality and non-membership should transferred from the toolkit into the base language.
D-136, section 1
Raised (S. Valentine) at SRC meeting 14.
Null declarations should be allowed. True and false should be transferred from the base language into the toolkit.
D-136, section 2
Raised (S. Valentine) at SRC meeting 14.
Local declarations should be allowed using ==.
D-136, section 3
Raised (S. Valentine) at SRC meeting 14.
Allow the use of LET as a synonym for mu.
D-136, section 4
Raised (S. Valentine) at SRC meeting 14.
Allow the use of == instead of tadpole arrows in enumerated bindings.
D-136, section 5
Raised (S. Valentine) at SRC meeting 14.
A generalisation of the notion of relational image should be made part of the base language, and relational image could be deleted from the toolkit.
D-136, section 6
Raised (S. Valentine) at SRC meeting 14.
The definitions of the toolkit should be made much looser. They could still achieve their present effect, but would be usable in more general contexts.
D-136, section 7
Raised (S. Valentine) at SRC meeting 14.
Strings should be supported as sequences of characters, rather than atomic primitive objects.
Raised (R. D. Arthan) at SRC meeting 17, and discussed there. Strings were included in the standard to support existing use in specifications (error messages, etc.). Not all present were in favour of including strings in the language.
The standard should address issues concerned with context conditions, e.g. the amount of context that must be examined to decide whether values for omitted actual generic parameters can be uniquely inferred, and with context dependencies in the transformation from representation syntax to abstract syntax, e.g. to allow bound variable names and global variable names to be mapped into different parts of the abstract name space.
Raised (R. D. Arthan) at SRC meeting 17.
The standard must specify the representation of numeric literals, as this is significant for tuple selection.
Raised (R. D. Arthan) at SRC meeting 17.
The empty set should be an instance of a set extension, like the empty bag and empty sequence. If there is a requirement for instantiating such extensions, then there is a case for allowing generic instantiation of both empty and non-empty set extensions.
Raised (R. D. Arthan) at SRC meeting 17.
The standard should provide language features that would allow the special syntax used by bag extension and relational image (presently fixed in the base language) to be defined in the toolkit.
Raised (R. D. Arthan) at SRC meeting 17. No work has yet been done on integrating any of the proposed ways of doing this into the standard.
The restriction that disallows the use of an instance of a generic schema as the operand of theta should be removed.
Raised (R. D. Arthan) at SRC meeting 17.
Function application and definite description should use the same treatment of undefinedness. Both constructs can be viewed as depending on an operation that selects an element from a set. Both have to be well-defined when the set has exactly one element, and should be defined to treat the case when the set is not a singleton in the same (unspecified) way.
Raised (R. D. Arthan) at SRC meeting 17.
The sample toolkit (Annex C) should be upgraded to support (at least) Spivey 2, i.e. make functional overriding into relational overriding, and add bag toolkit operations.
Raised (S. Stepney) 11 October 1993.
The sample toolkit (Annex C) should be replaced by D-172, subject to minor technical corrections.
D-172
Raised (J. E. Nicholls) 23 May 1995. Meeting 28 approved a straw poll of the entire panel.