[m-dev.] for review: Aditi [1]

Fergus Henderson fjh at cs.mu.OZ.AU
Tue Jul 7 18:09:10 AEST 1998


On 07-Jul-1998, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> Aditi compilation.

I haven't had a look at the changes themselves, but I do
have some comments after reading the log message.

The first one is that the new modules should all be
documented in notes/compiler_design.html.

Also the Aditi support should be documented in either
the WORK_IN_PROGRESS file or (when finished) the NEWS file.

> compiler/options.m:
> 	--aditi: enable Aditi compilation.
> 	--dump-rl: write the intermediate RL to `<module>.rl_dump'.
> 	--dump-rl-bytecode: write a text version of the bytecodes 
> 		to `<module>.rla'
> 	--aditi-only: don't produce a `.c' file.
> 	--filenames-from-stdin: accept a list of filenames to compile
> 		from stdin. This is used by the query shell.
> 	--rl-optimize, --rl-optimize-liveness, 
> 	--rl-optimize-cse, --rl-optimize-invariants,
> 	--detect-rl-streams:
> 		Options to control RL optimization passes which are not
> 		implemented or are not ready to commit yet.
> 	--aditi-user:
> 		Default owner of any Aditi procedures, defaults to $USER.
> 	--generate-schemas:
> 		write schemas for base relations to `<module>'.base_schema
> 		and schemas for derived relations to `<module>'.derived_schema.
> 		This is used by the query shell.

These new options should be documented somewhere, e.g. in doc/user_guide.texi.

For the ones which are not yet implemented, or not yet useful,
the documentation can be commented out, but it should be there.

> compiler/globals.m:
> 	Add a field to record whether there are any local Aditi procedures
> 	in the current module.

Shouldn't that be part of the module_info rather than the globals?

If you put it in the globals, then I think it may do the wrong
thing in the case of nested modules.

> compiler/hlds_pred.m:
> compiler/prog_data.m:
> compiler/prog_io_pragma.m:
> compiler/make_hlds.m:
> 	Add some Aditi pragma declarations - `aditi', `supp_magic', `naive',
> 	`psn' (predicate semi-naive), `base_relation' and `owner'.

These pragmas should be documented somewhere, e.g. in the
`implementation dependent pragmas' section of doc/reference_manual.texi.

Alternatively, the parts of the language reference manual and user guide
that describe the Aditi interface could be instead put in a separate
document, in which case the language reference manual and user guide
should contain just pointers to that document.

> compiler/mode_util.m:
> 	Added partition_args/5 which partitions a list of arguments
> 	into inputs and outputs.

What about partially instantiated insts and `any' insts?

> NEWS:
> library/eqvclass.m:
> 	Added eqvclass__same_eqvclass_list which tests whether a list
> 	of elements are in the same equivalence class.
> 
> library/io.nu.nl:
> library/sp_lib.nl:
> 	Add Prolog implementations of io__getenv, io__make_temp
> 	and io__make_err_msg.
> 
> library/map.m:
> 	Print out the key on a map__lookup failure if it is simple.

I think it would be best to commit these three changes separately.

> runtime/mercury_init.h:
> util/mkinit.c:
> scripts/c2init.in:
> 	Added a function `mercury__load_aditi_rl_code()' which
> 	throws all the RL code for the program at the database.

This confused me for a bit; I presume you mean that you
added code to *generate* code for that function?

-- 
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.



More information about the developers mailing list