Concerning the sample argument approach,
Marc van Dongen <[EMAIL PROTECTED]> writes on May 8 2000
> I am not sure if I understand this but I also used
> zero :: a -> a
> to create polynomials as opposed to a function
> zero :: a
> The application
> zero p
> created a zero polynomial with certain ``built-in''
> properties like a term-order it inherited from p.
Looks like it uses the sample argument. This p contains the
parameters that describe a polynomial domain P = c[x1..xn].
Different ways to order the monomial set, different lists of
"variables" may mean different domains inside the *same type*.
If p contains variables ["x"], p' contains ["x","y"],
then zero p and zero p'
have to be zeroes of very different domains corresponding to
p, p' :: a.
If you rely on the features like this, this is the very sample
argument approach.
Do you mean this?
Classic Haskell approach:
-------------------------
make the above ordering and variable list to be given as the
*instances* of some classes.
To present an ordering or a variable list would mean to define the
instance for some new type, so that the name of this type denotes
actually the ordering and variable list.
Besides several technical hindrances of mathematical nature, it
puts certain principal restriction.
It prohibits all the mathematical practice of dynamic change of
orderings, variable lists, residue domains for different base,
generally - dynamic change of computation domain given by
*parameter*.
In many tasks it is unknown statically, how many residue domains
Z/(2), Z/(3) ... will suffice to find some solution.
Therefore, the advancedAlgebra library should allow many domains
Z/(m) with different m to exist inside the same type T.
This is *partly* supported via the sample argument approach.
I think, the very language cannot support this as good as the
static types.
And after a snob user sets a couple of times `zero p',
after this, one just forgets of zero :: a, zero `asTypeOf` x.
This was the story with me, personally.
For 5 years I recalled the thought whether zero `asTypeOf` x
is more likely to be detected as a constant than `zero p'.
I argued about this, not mentioning the dynamic domains, though knew
well that the readers would still fix it.
I suggest now zero :: a -> a
only for -fadvancedAlgebra.
And note that there, the sample argument shows that the function
may occur not a constant on the *type*.
Instead, it is a constant on implicit domain.
Domains via dynamic loading
---------------------------
"I think, the very language cannot support this as good as the
static types".
Imagine the dynamic link of the objects modules, or generally, the
dynamic loading of some interpreted code.
This may do the dynamic creation of domains presented in old
system like static instances.
The questions are: (1) expenses, (2) does the functionality break?
(1) A domain is created only to be used many times. Still ...
(2) In what way f x = 1 may change to f x = 2
after loading some domain?
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
