[m-dev.] for review: Aditi updates[6]

[Fergus Henderson]

On 01-Jul-1999, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > 
> > > + at subsubheading Bulk insertion
> > 
> > There are sufficiently many @subsubheadings that I think there should be
> > separate @nodes for each @subsubheading here, with an @menu to select
> > between them.
> 
> See the comment above: "@c XXX texinfo doesn't have subsubsubsection."

Yes, but I think you can use @node even without @subsubsubsection,
can't you?

... looking at the TexInfo manual I see that you can:

 |   Usually, you write one of the chapter-structuring command lines
 | immediately after an `@node' line--for example, an `@section' or
 | `@subsection' line.  (*Note Types of Structuring Command: Structuring
 | Command Types.)

"Usually", but it is not required.
There is however a small caveat:

 |      *Please note:* The GNU Emacs Texinfo mode updating commands work
 |      only with Texinfo files in which `@node' lines are followed by
 |      chapter structuring lines.  *Note Updating Requirements::.

I don't think this would affect us, though, since we don't use
the GNU Emacs Texinfo mode updating commands (at least I don't).

> > > + at example
> > > +aditi_bulk_insert(@var{PredOrFunc} @var{Name}/@var{Arity}, @var{Closure}, @var{DB0}, @var{DB}).
> > > + at end example
> > > +
> > > +Insert all solutions of @samp{@var{Closure}} into the named relation.
> > > + at samp{@var{PredOrFunc}} must be either @samp{pred} or @samp{func}.
> > > +There must be a @w{@samp{:- pragma base_relation}} declaration for
> > > + at w{@samp{@var{Name}/@var{Arity}}}.
> > 
> > Can `Name' be module-qualified?
> > (Same question applies in a few places around here.)
> 
> Yes.

OK, please make the documentation about that clearer.

> > > --- ho_type_mode_bug.err_exp	1997/06/16 08:55:31	1.1
> > > +++ ho_type_mode_bug.err_exp	1999/05/21 09:43:11
> > > @@ -1,11 +1,9 @@
> > >  ho_type_mode_bug.m:025: In clause for `my_foldl2((pred(in, in, out) is det), in, in, out, in, out)':
> > > -ho_type_mode_bug.m:025:   in argument 1 of higher-order predicate call
> > > -ho_type_mode_bug.m:025:   (i.e. in the predicate term):
> > > +ho_type_mode_bug.m:025:   in argument 1 (i.e. the predicate term) of call to predicate `call/6':
> > 
> > Hmm, this seems like a small step backwards in terms of readability.
> > How hard would it be to keep the old message?
> 
> The error message now reads:
> 
> ho_type_mode_bug.m:025: In clause for `my_foldl2((pred(in, in, out) is det), in,
>  in, out, in, out)':
> ho_type_mode_bug.m:025:   in argument 1 (i.e. the predicate term) of higher-orde
> r predicate call:
> ho_type_mode_bug.m:025:   mode error: variable `P' has instantiatedness `(pred(i
> n, in, out) is det)',
> ho_type_mode_bug.m:025:   expecting higher-order pred inst (of arity 5).
> 
> Keeping the original line wrapping is difficult because
> hlds_out__write_call_arg_id does not have a context.
> Adding a context there is probably the wrong fix - we should
> eventually add better support for line wrapping in error messages
> throughout the compiler without having to bodge it in everywhere.

OK, that is fine.

> Does the "(i.e. the predicate term)" really add anything here?

Yes.  If I write `P(A, B)', and the compiler complains about a mode
error "in argument 1 of higher-order predicate call", then I will
probably think it means a mode error in `A', not a mode error in `P'.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------