[m-dev.] for review: --high-level-data

[Tyson Dowd]

On 31-May-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> Tyson, would you like to review this one?
> 
> ----------
> 
> Estimated hours taken: 20
> 
> Make a start towards implementing the `--high-level-data' option.
> 
> XXX There are still quite a few places in the MLDS code generator,
> specifically in ml_unify_gen.m, ml_call_gen.m, and ml_code_gen.m,
> that assume `--no-high-level-data'.  For example, we still use
> the MR_field() macro rather than using named fields.
> 
> XXX Equivalence types are not yet supported.
> 
> compiler/ml_type_gen.m:
> 	New module.  If --high-level-data is enabled, this module
> 	generates MLDS type definitions for HLDS types.
> 
> compiler/ml_code_gen.m:
> 	Import ml_type_gen.m, and delete the stub code for
> 	`ml_gen_types', since that is now defined in ml_type_gen.m.
> 
> compiler/mlds_to_c.m:
> 	- If --high-level-data is enabled, declare variables whose Mercury
> 	  types is user-defined using the MLDS types generated by
> 	  ml_type_gen.m, and declare closures with type `MR_ClosurePtr'
> 	  rather than `MR_Word'.
> 	- Output type definitions in the header file rather than
> 	  then `.c' file.
> 	- Add code to output `mlds__enum' classes as C enums,
> 	  and to handle static members and nested types in classes;
> 	  these changes are needed because ml_type_gen generates those
> 	  constructs.
> 	- Cast the argument of MR_tag() to `MR_Word'.
> 	- Cast the result of MR_new_object() to the appropriate type.
> 
> runtime/mercury.h:
> 	- Delete the cast to `MR_Word' in MR_new_object(), because it was
> 	  not right for the --high-level-data case; the necessary casts
> 	  are now generated by mlds_to_c.m.
> 	- Define the `MR_ClosurePtr' type.
> 
> compiler/mlds_to_c.m:
> compiler/ml_elim_nested.m:
> 	Fully qualify struct member names.  This is needed to avoid
> 	name clashes for the enumeration constants and nested types
> 	that ml_type_gen generates, in particular for the case where
> 	the same constructor name and arity occurs in two or more
> 	different types in a single module.  It's also more consistent
> 	with our general approach of fully qualifying all references.
> 
> compiler/mlds.m:
> 	- Add a new field of type builtin_type to the mercury_type/2
> 	  MLDS type; this holds the type category (enumeration, etc.).
> 	  This required adding a module_info parameter to the
> 	  mercury_type_to_mlds function.
> 	- Similarly, add a new field of type mlds__class_kind to the
> 	  class_type/2 MLDS type.
> 	- Add a function `mlds__append_class_qualifier', for use by mlds_to_c.m
> 	  and ml_elim_nested.m.
> 	- Add field names to the `mlds__class_defn' struct.
> 
> compiler/ml_code_util.m:
> 	Add a new routine ml_gen_type for converting Mercury types to MLDS.
> 	This just extracts the module_info from the ml_gen_info and then
> 	calls mercury_type_to_mlds.
> 
> compiler/*ml*.m:
> 	Change lots of places to use ml_gen_type and/or to pass the
> 	module_info down to mercury_type_to_mlds, and to handle the
> 	new field of mercury_type/3.  Similarly, change quite a few
> 	places to handle the new field of class_type/3.
> 
> 	In ml_code_util.m, passing the module_info down had the
> 	pleasant side-effect of enabling the elimination of an
> 	existing XXX: in ml_gen_proc_params_from_rtti,
> 	UseNestedFunctions was not being calculated correctly,
> 	because previously the globals where not easily available at
> 	that point.
> 

> +% File: ml_type_gen.m
> +% Main author: fjh
> +
> +% MLDS type generation -- convert HLDS types to MLDS.
> +
> +% For enumerations, we use a Java-style emulation: we conver them

s/conver/convert/


> +% Discriminated union types.
> +%
> +
> +	%
> +	% For each discriminated union type, we generate an MLDS type of the
> +	% following form:

I think it would also be good to add a flag or somesuch to the MLDS
class type to say it was originally a Mercury discriminated union, and
whether this class represents the type or a constructor.  (Well, the
type/constructor flag could be added when we flatten the class).

Otherwise the change looks fine (and of course this change can be added
later).

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------