mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-13 04:44:39 +00:00
3acbf03059
These allow types to be defined in the following manner:
:- type job ---> job(pred(int::out, io::di, io::uo) is det).
For any construction unification using this functor the argument must
have the required higher-order inst; it is a mode error if it does not.
When terms of type job with inst ground are deconstructed, the argument
is inferred to have the given inst, allowing a higher-order call in that
mode.
The new type syntax is currently only permitted as the direct argument of
a functor in a du type definition. In future it would be meaningful to
support this syntax in other locations, but that is left for a separate
change.
In order to correctly implement the construct/3 library predicate, we
need to be able to dynamically check that arguments do not violate
any constraints on the argument insts. At the moment, we conservatively
abort if any such constraints are present irrespective of whether they
are satisfied or not. Since these constraints are a new feature, no
existing code will abort in this way.
The implementation refers to the inst information associated with types
as "subtype information". This is because, generally, we think of the
combination of a type with a fully bound inst (i.e., one that describes
terms that contain no unbound variables) describes a subtype of that type.
compiler/inst_util.m:
Ensure that arguments have the necessary insts in construction
unifications.
Where available, propagate the insts into arguments rather than
using ground(shared, none).
compiler/prog_io_type_name.m:
Parse the new form of types.
compiler/unparse.m:
Unparse the new form of types.
compiler/prog_io_type_defn.m:
Allow the new form of types in functor arguments.
compiler/prog_ctgc.m:
compiler/prog_io_item.m:
compiler/prog_io_mutable.m:
compiler/prog_io_pragma.m:
compiler/prog_io_typeclass.m:
compiler/superhomogeneous.m:
Disallow the new form of types in places other than functor
arguments.
compiler/prog_data.m:
Go back to representing function types with result type appended
to the arguments. In most case this now results in simpler code.
compiler/prog_type.m:
Abstract away the representation of predicate vs function arguments
by using a predicate to construct these types.
compiler/rtti.m:
compiler/type_ctor_info.m:
Include subtype information about the arguments of a du functor
and about the argument of a notag functor. Generate this
information from the argument types.
Currently, the information is one bit which says whether or not
any subtypes exist in the arguments.
Bump the RTTI version number from the compiler side.
compiler/rtti_out.m:
Output functor subtype information for the low-level C backend.
compiler/rtti_to_mlds.m:
Include functor subtype information in the MLDS.
compiler/mlds_to_cs.m:
Add the new runtime type to the special cases.
compiler/erl_rtti.m:
compiler/erlang_rtti.m:
library/erlang_rtti_implementation.m:
Include functor subtype info in the erlang RTTI.
java/runtime/DuFunctorDesc.java:
java/runtime/FunctorSubtypeInfo.java:
Include functor subtype information in the Java runtime.
runtime/mercury_dotnet.cs.in:
Include functor subtype information in the C# runtime.
runtime/mercury_type_info.h:
Include functor subtype information in the C runtime.
Bump the RTTI version number in the runtime.
Define macros to access the new field. These macros can correctly
handle the previous RTTI version, therefore we do not need to
change the minimum version at this time.
library/private_builtin.m:
Define constants for use by the Java backend.
library/construct.m:
library/rtti_implementation.m:
Use the new RTTI to ensure we don't attempt to construct terms
that violate the new insts.
compiler/prog_rep_tables.m:
Ignore the new inst info for now.
compiler/*.m:
Changes to conform to above.
doc/reference_manual.texi:
Document the new feature.
tests/hard_coded/functor_ho_inst.{m,exp}:
tests/hard_coded/functor_ho_inst_2.{m,exp}:
tests/hard_coded/functor_ho_inst_excp.{m,exp}:
tests/hard_coded/functor_ho_inst_excp_2.{m,exp}:
Test the new functionality.
tests/invalid/combined_ho_type_inst.{m,err_exp}:
tests/invalid/combined_ho_type_inst_2.{m,err_exp}:
Test that we don't allow the new types where they are not permitted,
or are incomplete.
tests/invalid/functor_ho_inst_bad.{m,err_exp}:
tests/invalid/functor_ho_inst_bad_2.{m,err_exp}:
tests/invalid/functor_ho_inst_bad_3.{m,err_exp}:
Test that the argument inst information is enforced as required.
tests/hard_coded/Mmakefile:
tests/invalid/Mmakefile:
Run the new test cases.
181 lines
6.1 KiB
Mathematica
181 lines
6.1 KiB
Mathematica
%-----------------------------------------------------------------------------%
|
|
% vim: ft=mercury ts=4 sw=4 et
|
|
%-----------------------------------------------------------------------------%
|
|
% Copyright (C) 2007, 2011 The University of Melbourne.
|
|
% This file may only be copied under the terms of the GNU General
|
|
% Public License - see the file COPYING in the Mercury distribution.
|
|
%-----------------------------------------------------------------------------%
|
|
%
|
|
% File: erlang_rtti.m.
|
|
% Authors: petdr, zs.
|
|
%
|
|
% Definitions of data structures for representing run-time type information
|
|
% in the Erlang backend.
|
|
%
|
|
% Note we only define new types for from where the RTTI differs
|
|
% from what is defined in rtti.m.
|
|
%
|
|
% In the context of the MLDS backend erlang_rtti.m is the equivalent of
|
|
% rtti.m, while erl_rtti.m is the equivalent to rtti_to_mlds.m
|
|
%
|
|
% These types have to be kept in sync with the corresponding types in
|
|
% library/erlang_rtti_implementation.m
|
|
%
|
|
%-----------------------------------------------------------------------------%
|
|
|
|
:- module backend_libs.erlang_rtti.
|
|
:- interface.
|
|
|
|
:- import_module backend_libs.rtti.
|
|
:- import_module hlds.
|
|
:- import_module hlds.hlds_rtti.
|
|
:- import_module mdbcomp.
|
|
:- import_module mdbcomp.sym_name.
|
|
|
|
:- import_module list.
|
|
:- import_module maybe.
|
|
|
|
%-----------------------------------------------------------------------------%
|
|
%
|
|
% The data structures representing type constructors
|
|
%
|
|
|
|
% A type_ctor_data structure contains all the information that the
|
|
% runtime system needs to know about a type constructor.
|
|
%
|
|
:- type erlang_type_ctor_data
|
|
---> erlang_type_ctor_data(
|
|
etcr_version :: int,
|
|
etcr_module_name :: module_name,
|
|
etcr_type_name :: string,
|
|
etcr_arity :: int,
|
|
|
|
%
|
|
% It is possible that the type doesn't have
|
|
% a unify or compare predicate.
|
|
% eg one cannot unify higher-order types.
|
|
%
|
|
etcr_unify :: maybe(rtti_proc_label),
|
|
etcr_compare :: maybe(rtti_proc_label),
|
|
etcr_rep_details :: erlang_type_ctor_details
|
|
).
|
|
|
|
% A erlang_type_ctor_details structure contains all the information that
|
|
% the runtime system needs to know about the data representation scheme
|
|
% used by a type constructor.
|
|
%
|
|
% XXX Later on we may want to handle the enum and notag du types
|
|
% specially.
|
|
% Enum is for types that define only constants.
|
|
% Notag is for types that define only one unary functor.
|
|
%
|
|
:- type erlang_type_ctor_details
|
|
|
|
---> erlang_du(
|
|
% The function symbols are listed in declaration order.
|
|
edu_functors :: list(erlang_du_functor)
|
|
)
|
|
|
|
; erlang_dummy(
|
|
edummy_name :: string
|
|
)
|
|
|
|
% Mercury lists are represented as erlang lists
|
|
; erlang_list
|
|
|
|
%
|
|
; erlang_array
|
|
|
|
; erlang_eqv(
|
|
% XXX why is it a pseudo type info
|
|
eeqv_type :: rtti_maybe_pseudo_type_info
|
|
)
|
|
|
|
% Builtin Mercury types
|
|
; erlang_builtin(
|
|
ebuiltin_ctor :: builtin_ctor
|
|
)
|
|
|
|
|
|
% Types used just in the implementation.
|
|
; erlang_impl_artifact(
|
|
eimpl_ctor :: erlang_impl_ctor
|
|
)
|
|
|
|
; erlang_foreign
|
|
.
|
|
|
|
:- type erlang_du_functor
|
|
---> erlang_du_functor(
|
|
edu_name :: string,
|
|
edu_orig_arity :: int,
|
|
|
|
% The declaration order of the functor.
|
|
edu_ordinal :: int,
|
|
|
|
% The lexicographic order of the functor.
|
|
edu_lex :: int,
|
|
|
|
% erlang atom which represents the functor
|
|
% currently encoded version of name
|
|
% in the future maybe name_arity
|
|
edu_rep :: erlang_atom_raw,
|
|
edu_arg_infos :: list(du_arg_info),
|
|
edu_exist_info :: maybe(exist_info),
|
|
edu_subtype_info :: functor_subtype_info
|
|
).
|
|
|
|
:- type erlang_atom_raw
|
|
---> erlang_atom_raw(string).
|
|
|
|
% The list of type constructors that are used behind the scenes by
|
|
% the Mercury implementation.
|
|
%
|
|
:- type erlang_impl_ctor
|
|
---> erlang_impl_ctor_type_info
|
|
; erlang_impl_ctor_type_ctor_info
|
|
; erlang_impl_ctor_typeclass_info
|
|
; erlang_impl_ctor_base_typeclass_info
|
|
|
|
% The following are introduced in
|
|
% private_builtin and table_builtin
|
|
% but should never be used.
|
|
%
|
|
; erlang_impl_ctor_hp
|
|
; erlang_impl_ctor_subgoal
|
|
; erlang_impl_ctor_ticket
|
|
.
|
|
|
|
%-----------------------------------------------------------------------------%
|
|
%
|
|
% The data structures representing the top-level global data structures
|
|
% generated by the Mercury compiler. These are all generated read-only.
|
|
|
|
:- type erlang_rtti_data
|
|
---> erlang_rtti_data_type_ctor_info(
|
|
erlang_type_ctor_data
|
|
)
|
|
; erlang_rtti_data_type_info(
|
|
rtti_type_info
|
|
)
|
|
; erlang_rtti_data_pseudo_type_info(
|
|
rtti_pseudo_type_info
|
|
)
|
|
; erlang_rtti_data_base_typeclass_info(
|
|
tc_name, % identifies the type class
|
|
module_name, % module containing instance decl.
|
|
string, % encodes the names and arities of the
|
|
% types in the instance declaration
|
|
base_typeclass_info
|
|
)
|
|
; erlang_rtti_data_type_class_decl(
|
|
tc_decl
|
|
)
|
|
; erlang_rtti_data_type_class_instance(
|
|
tc_instance
|
|
).
|
|
|
|
%-----------------------------------------------------------------------------%
|
|
:- end_module backend_libs.erlang_rtti.
|
|
%-----------------------------------------------------------------------------%
|