Files
mercury/samples
Julien Fischer e6e295a3cc Generalise the representation of integers in the term module.
In preparation for supporting uint literals and literals for the fixed size
integer types, generalise the representation of integers in the term module, so
that for every integer literal we record its base, value (as an arbitrary
precision integer), signedness and size (the latter two based on the literal's
suffix or lack thereof).

Have the lexer attach information about the integer base to machine sized ints;
we already did this for the 'big_integer' alternative but not the normal one.
In conjunction with the first change, this fixes a problem where the compiler
was accepting non-decimal integers in like arity specifications.  (The
resulting error messages could be improved, but that's a separate change.)

Support uints in more places; mark other places which require further work with
XXX UINT.

library/term.m:
     Generalise the representation of integer terms so that we can store
     the base, signedness and size of a integer along with its value.
     In the new design the value is always stored as an arbitrary precision
     integer so we no longer require the big_integer/2 alternative; delete it.

     Add some utility predicates that make it easier to work with integer terms.

library/term_conversion.m:
library/term_io.m:
     Conform to the above changes,

     Add missing handling for uints in some spots; add XXX UINT comments
     in others -- these will be addressed later.

library/lexer.m:
     Record the base of word sized integer literals.

library/parser.m:
compiler/analysis_file.m:
compiler/fact_table.m:
compiler/get_dependencies.m:
compiler/hlds_out_goal.m:
compiler/hlds_out_util.m:
compiler/intermod.m:
compiler/make.module_dep_file.m:
compiler/parse_class.m:
compiler/parse_inst_mode_name.m:
compiler/parse_item.m:
compiler/parse_pragma.m:
compiler/parse_sym_name.m:
compiler/parse_tree_out_term.m:
compiler/parse_tree_to_term.m:
compiler/parse_type_defn.m:
compiler/parse_util.m:
compiler/prog_ctgc.m:
compiler/prog_util.m:
compiler/recompilation.check.m:
compiler/recompilation.version.m:
compiler/superhomogeneous.m:
mdbcomp/trace_counts.m:
samples/calculator2.m:
extras/moose/moose.m:
    Conform to the above changes.

tests/hard_coded/impl_def_lex.exp:
tests/hard_coded/impl_def_lex_string.exp:
tests/hard_coded/lexer_bigint.exp*:
tests/hard_coded/lexer_zero.exp*:
tests/hard_coded/parse_number_from_string.exp*:
tests/hard_coded/term_to_unit_test.exp:
    Update these expected outputs.
2017-04-22 11:53:14 +10:00
..
2017-04-04 12:05:56 +10:00
2016-10-02 23:26:02 +11:00
2017-04-04 12:05:56 +10:00
2017-04-04 12:05:56 +10:00

This directory contains some example Mercury programs.

hello.m			"Hello World" in Mercury.

cat.m                   An implementation of a simple version of the
			standard UNIX filter `cat', which just copies
			its input files or the standard input stream to
			the standard output stream.

sort.m                  An implementation of a simple version of the
			standard UNIX filter `sort', which reads lines
			from its input files or the standard input
			stream, sorts them, and then writes the result
			to the standard output stream.

calculator.m            A simple four-function arithmetic calculator,
			with a parser written using the Definite Clause
			Grammar notation.

calculator2.m		A simple four-function arithmetic calculator,
			which uses the parser module in the standard
			library with a user-defined operator precedence
			table.

interpreter.m		An simple interpreter for definite logic programs.
			A demonstration of meta-programming in Mercury.

expand_terms.m		Another example meta-program, showing how to
			emulate Prolog's `expand_term' mechanism.

e.m			A small program which calculates the base of
			natural logarithms to however many digits you
			choose.  It illustrates one way to achieve
			lazy evaluation in Mercury.

Mmakefile		The file used by `mmake', the Mercury Make program,
			to build the programs in this directory.

The `solutions' sub-directory contains some examples of the use of
nondeterminism, showing how a Mercury program can compute 
	- one solution,
	- all solutions, or
	- some solutions (determined by a user-specified criteria)
for a query which has more than one logically correct answer.

The `concurrency' sub-directory contains examples of how to use Mercury's
concurrency interface, i.e. using threads in Mercury programs.

There are also some sub-directories which contain examples of multi-module
Mercury programs:

appengine               A simple Google App Engine servlet.

diff                    This directory contains an implementation of a
			simple version of the standard UNIX utility
			`diff', which prints the differences between
			two files.

c_interface		This directory contains some examples of mixed
			Mercury/C/C++/Fortran programs using the C interface.

java_interface		This directory contains some examples of mixed
			Mercury/Java programs using the foreign language
			interface.

rot13			This directory contains a few implementations of
			rot-13 encoding.

muz			This directory contains a syntax checker / type checker
			for the specification language Z.

solver_types		This directory contains an example solver type
			implementation and some sample applications.

lazy_list		This directory contains an example of the lazy module
			can be used to implement lazy data structures, in this
			case a lazy list.