@Section
    @Title { Unresolved issues }
    @Tag { unresolved }
@Begin
@LP
The following language and implementation issues were unresolved at the
time of release of Version 1.02 of the Nonpareil compiler.
@PP
@I { Redefinition of creation features from optional to compulsory. }
It may be safe to allow the redefinition of a creation feature if
it is converted from optional to compulsory by the redefinition.
Is this safe?  Is it useful?  Should it be allowed?
@PP
@I { Redefinition of noncreation features into creation features. }  Eiffel
allows a noncreation feature to be redefined as a creation feature.  It
is easy to see that this is a kind of shorthand for introducing a new
creation feature and redefining the noncreation feature to just return
the new creation feature.  Presumably this proves that it is safe.
Is it useful?  Should it be allowed?
@PP
@I { Standard library. }  Version 1.02 does not come with a standard
library.  Various classes that would be part of such a library have
been implemented, but only in so far as they make useful tests.  I
need to review various standard libraries (Haskell, OCaml, Java etc.)
and take the time to carefully design a Nonpareil standard library.
@PP
@I { Range types and coercion. }  When the compiler matches a call against
a signature, it checks that each actual parameter's type is a subtype of
its formal parameter's type.  This subtype test simultaneously updates
constraints on unification variables, and returns a coercion indicating
how the actual parameter needs to be coerced.  The unresolved question
is whether this coercion is calculated too soon.  Should we wait until
after the whole call is matched and unification variables are converted
into range variables?
@PP
@I { Superfluous casts. }  Type casts can often be omitted in C, when
they are the `usual arithmetic conversions.'  But the compiler tediously
inserts them all.  They look silly on constants such as
@ID @CP { (int) (short) 0 }
which records the chain of coercions that the compiler used to convince
itself that the @Nonpareil { byte } constant 0 could be used in an
@Nonpareil { int } context.  Since these coercions are builtins anyway,
these useless coercions can probably be avoided by implementing them as
identity functions rather than as casts.
@PP
@I { Unnecessary C variables. }  The generated code has some unnecessary
C variables.  These arise when an expression is large-scale only because
of a single point buried within it.  Every subexpression on the way to
that point gets a variable, but in fact only one variable is needed,
for the point itself; calculating that subexpression and storing it in
a variable should make everything above it small-scale.
@PP
@I { Copying of shared bodies. }  When two features share a body, at
present that body is being copied, leading to duplication of C code.
It is hard to see how to do it any other way, if the features are to
be treated as independent, at least for noncreation features, and it is
probably not a significant issue in the overall system, since sharing
is not very frequent anyway.  But still it would be better avoided.
@End @Section
