Thinking about:
instance Ord int is
x < y = do
count <- count + 1
primative_int_less(x, y)
Its not nice that the instance is gobal, and that implies count is global.
I think it is interesting to examine how templates interact with classes,
especially if we disallow global variables and nested functions as in C++.
Given a template like
template <typename R>
requires RandomIterator<R>, Ord<typename R::value_type>
void sort(R first, R last) {...}
Which would internally use:
bool x = compare<typename R::value_type>(x, y)
The compare 'thing' would have to be a stateless function or use static or
global variables, which we don't like :-)
To do sort with a stateful comparator, we should definitely be passing in
an object, however we don't want two definitions. Something like this would
seem reasonable:
template <typename R, typename F>
requires RandomIterator<R>
, Ord<typename R::value_type>
, BinaryOperator<F>
, Argument<F, 1, typename R::value_type>
, Argument<F, 2, typename R::value_type>
, ResultType<F, bool>
void sort(R first
, R last
, F cmp =compare<typename R::value_type>) {...}
So this will use the default compare function for the value_type, unless a
function object is passed in.
The sensible distinction is functions are stateless (but can modify local
state and arguments passed by reference). Anything with state should be a
function-object.
Keean.
On 8 Jan 2015 04:19, "Jonathan S. Shapiro" <[email protected]> wrote:
I've been pondering this over dinner. It's a rough thought, but I want to
put it out for consideration.
Type inference is a form of constrained proof discharge. In the examples
that concern us, inference is decidable. It is decidable because (a) the
constructors are statically resolvable [non abstract], (b) there is a
certain property of inductive decomposition due to the nature of type
construction providing structural induction, and (c) there are no points of
non-deterministic choice.
I have spoken of statically resolved constant terms. Others here have
spoken of "lifting" certain kinds of constants to types. I think both of
these views are valid, but I want to suggest an alternative way to think
about this: it's all about the "laws of inference".
Seen in a certain light, HM-style inference has very little to do with
types. The basic requirements are (1) there exists some set of ground
(atomic) entities, and (2) there exists some form of structural composition
over these, leading to a structural induction, and (3) the names of the
atomic entities and the constructors are statically resolvable. There is
nothing magical in saying that [1] is ground types and [2] is type
constructors. If it were somehow useful we could do HM-style inference on
literals and construction over literals (composite literals).
So one view is that we are "lifting" some things into higher-order types.
But another view is that we are expanding the domain over which inference
can sensibly operate in such a way that the enabling laws of inference are
preserved. The two views are clearly inter-convertible. Conceptually, we
could replace the domain of "types" in a programming language with the
domain of "inductibles" without fundamentally altering anything.
Up to a point.
Consider a perverse, hypothetical instantiation of Ord 'a over int:
instance Ord int is
(<) = fn x y is
count := count +1
primative_int_less(x, y)
Note the update to "count", with the intent being that we will count the
number of invocations of integer-<. Note further that the presence or
absence of this count does not alter the fact that this "binding" for "Ord
int" is sufficiently constant to be treated as something that is (a)
structurally inductable, and (b) compile-time specializable.
What this seems to suggest is that the test of "can it be
structurally-inductively inferred and specialized" is more subtle than I
suggested above. I'm not exactly sure how to state the requirement for this
form of specialization to be legal. In the end, I suspect it has a lot to
do with static resolvability.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
