[mercury-users] Pred defns
bmd at cs.kuleuven.ac.be
Fri Apr 3 21:33:02 AEST 1998
> I don't think the cross-module threading problem is much of problem: just
> require declarations of the "global variables" that are needed/defined by
> exported predicates.
A declaration for global variables needed/defined by exported
predicates - very strange: it attaches the notion to a predicate,
which feels quite wrong to me; also, it appears to me that keeping
"global variables" local to a module (or compilation unit), is the
sensible thing to do: they are (backtrackable) state attached to a
module. Implement/specify them with threading variables >only< and be
prepared for cases you can't do in a satisfactory way without
introducing a whole lot of ballast (= more declarations).
> As to implementation approach, Fergus and I came up with a simple Mercury
> extension that would allow the two approaches to be equivalent. The basic
> idea is to allow users to declare a "register" name, and then to associate
> at most one register with each predicate argument. This is a suggestion to
> the compiler to pass that argument in some special location, rather than the
> usual argument registers. Of course, only one or two arguments to a given
> predicate can be assigned the same register, and two only if the two
> arguments have in and out (or di, uo, or mdi, muo) modes in all modes for
> that predicate. This avoids shuffling these things around in argument
> registers. It basically gives you the performance of the non-threading
> approach without the (unnecessary) impurity of imperative global variables.
> Much nicer.
So, after C compilers have improved up to the point that register
declarations are almost pointless, are we getting them back in the
high-level language Mercury ? And the user has to take into account of
the finesses of the (unique) modes etc ? Can't we count on a global
register allocation schema for doing all these nifty things ?
Much nicer ... good Lord ! If only that mail were written on 1 April,
but it was the day before ...
Apart from that: the recent flood of syntax proposals for something
that Peter Schachte can express concisely with only $ and := is really
amazing ... and scary !
More information about the users