_B_u_g_ _R_e_p_o_r_t_s

If you find a bug, please report it to mira-bugs at the doman
	miranda.org.uk
First check the list below, however, in case it is already  known.   All
bug  reports  will be gratefully received.  Suggestions for improvements
to the language or system, or their  documentation,  are  also  welcome.
When  sending  a bug report, please remember to state the version number
of your Miranda system and the type of machine that it is running on.

Note on error messages:-
 The error messages from the Miranda system are mostly self explanatory.
Note  however  that  any  message  of  the  form  "impossible event ..."
indicates that a serious, and unexpected, internal error  has  occurred.
Messages   of  this  form  should  always  be  reported  as  bugs.   Any
segmentation faults or core dumps should also be reported, as these  too
should not occur.

_L_i_s_t_ _o_f_ _k_n_o_w_n_ _b_u_g_s_,_ _d_e_f_i_c_i_e_n_c_i_e_s_,_ _a_n_d_ _u_n_i_m_p_l_e_m_e_n_t_e_d_ _f_e_a_t_u_r_e_s

There ought to be a directive  which  can  be  placed  in  a  script  to
suppress or modify the automatic inclusion of the standard environment -
this will be attended to in the next release.

It is not currently permitted  to  give  a  type  specification  for  an
identifier  defined  locally,  as  part of a _w_h_e_r_e clause.  That is (see
formal syntax) `spec' is not allowed after _w_h_e_r_e.  There  is  no  strong
reason for this restriction and it will be lifted in later releases.

When abstract objects are tested for equality or order (under <, <= etc)
the  result is that obtained by applying the operation to the underlying
representation type.  In some cases this will be what you want,  but  in
others it will be wrong - there ought to be a way of controlling this.

The standard input cannot be accessed both as a list of characters (with
$-)  and  as  a  list of values (with $+) at the same time.  If $+ is in
use, an occurrence of $- will evaluate to [], and vice versa.   This  is
not referentially transparent - uses of $+ and $- ought to share data.

Scripts with multiple occurrences of $+  also  behave  opaquely  -  each
occurrence  of $+ reads from the terminal independently, and they do not
share data with each other.  (Multiple occurrences of  $+  in  a  single
command-level expression behave transparently, however.)

There is a subtle issue concerning `show' and %export.  If you define  a
function  which, internally, uses `show' on an object of algebraic type,
and then %export that function to another scope, the format used by  the
`show'  depends  on  the  status of the algebraic type in the NEW scope.
Thus if the type has been aliased the  new  constructor  names  will  be
used,  and  if the algebraic type is no longer in scope, it will show as
"<unprintable>" (this latter case can arise if an abstract type based on
the  algebraic  type  is  exported, and one of the signature identifiers
invokes  `show'  on  the  base  type).   Although  this   behaviour   is
defensible,  it might be better for each use of `show' at algebraic type
to be frozen to use the constructor names in the scope where it  occurs.
This  will  probably  be  fixed in a later release.  [An analogous issue
arises with `readvals'.]

Implementation restrictions not mentioned elsewhere in  the  manual:-  A
shell  command  called from mira using `!' is limited to 1024 characters
in length after any implied expansions (eg of `%') have been  performed.
The  same  restriction  applies  to  the  result of expanding out a `/e'
command.  The pathnames of Miranda scripts are limited to 200 characters
in  length,  including  the  `.m'  extension.   The  name  of the editor
supplied for the `/e' command, and the absolute pathnames of the miralib
directory,  and  of  the user's home directory, are also each limited to
200 characters in length.

