Re: Reconsidering assignment

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 11 Jun 2007 14:12:09 -0700, Maciej Sobczak wrote:

> Still (heck, that doesn't seem to be the end of discussion :-) ), the
> earlier idea of expressing restrictions for subprogram parameters
> looks interesting to me. The point is that subprogram overloading
> operates on each parameter in isolation, whereas such restrictions
> could add the possibility of selecting more convoluted subsets of the
> whole relation.

(Note that by allowing this you allow multiple-dispatch, with its more than
linear number of alternatives)

> This is similar to treating the whole set of
> parameters as a single record type and then constraining this single
> record type for the purpose of overloading.
> If the restriction is based on run-time properties of parameters, then
> it doesn't provide anything that cannot be achieved with explicit if/
> else at the beginning of the subprogram.
> Consider:
> 
> procedure P(X, Y : Real) with X*X + Y*Y <= 1;
> procedure P(X, Y : Real);
>
> The idea was to have some assistance from the language for the proper
> selection of overloaded P (one is for arguments that fall withing the
> unit circle, and the other is for the rest).

This cannot work because overloading resolution happens at compile-time,
while the conditions of matching, in your case are general run-time
expressions.

BTW, a similar mechanism exists for entry point barriers:

   entry P (X, Y : Real) when <condition>;

Though, note that for very strong reasons <condition> may not depend on the
entry point arguments.

Another objection is that it is again preferences and it is undecidable.
Consider:

   procedure P(X, Y : Real) when Halt (X);
   procedure P(X, Y : Real);

and it is ambiguous:

   procedure P(X, Y : Real) when X in -1..10;;
   procedure P(X, Y : Real) when X in -10..1;

which one to choose when X is 0?

Yet another point: P is a polymorphic subprogram. Various overloading are
implementations of. The condition clause controls the choice. Does not it
remind you anything? Make Real a class!

A general software design objection is that this breaks encapsulation. The
idea of type is that constraints like X*X+Y*Y<1 should be property of a
type. When you move them to procedures, you loose OO/ADT decomposition.

> Here it doesn't give
> anything fundamentally new, this can be achieved with if/else in a
> single procedure.

IMO there is great need in a language support for compile-time user-defined
expressions and decomposition subprograms into compile- and run-time parts.
The most obvious case is dimensioned expressions.

> On the other hand, restrictions for compile-time properties might be
> more useful and can be for example an interesting optimization tool.

Well, Optimizations are optional, a proper choice of P is not.

If you wanted to have an optimization tool, you should make both Ps in your
example legal:

   procedure P(X, Y : Real) when Memory_Is_Low;
   procedure P(X, Y : Real) when A_CPU_Core_Is_Free;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de