On Apr 23, 2010, at 7:07 PM, Nathan O'Treally wrote:
On 23 Apr., 11:10, Simon King <simon.k...@nuigalway.ie> wrote:
On Apr 22, 10:46 pm, "Georg S. Weber" <georgswe...@googlemail.com>
wrote:
I think I like "Wandlung" as the common umbrella term for both
"coercion" ("Umwandlung", I like that, too) and "conversion" (for
the
latter I'd propose: "Verwandlung" --- but "Konversion" might do as
well, and would be a good memory hook for what is what).
Yes, conversion<->Konversion and coercion<->Umwandlung sounds good to
me.
To get back to the topic... ;-)
Sorry, Simon, you misunderstood me; my enumeration of German terms
didn't mean they are synonyms, i.e.
(type) conversion == (Typ-)Umwandlung,
coercion == erzwungene Typumwandlung (oder implizite, automatische)
canonical coercion == kanonische (erzwungene/implizite/automatische)
Typumwandlung.
(And coercion model == Typumwandlungsmodell)
Unfortunately, conversion, casts and coercion are often used as [if
they were] synonyms, and the terms aren't really absolute.
Coercion is a kind of conversion, namely implicit or automatic
conversion.
(Other definitions state a coercion is simply a function taking the
value of some type and mapping it into another type/domain, so the
notion of coercion above here would be named coercion model; also the
*model* defines what's implicit)
http://trac.sagemath.org/sage_trac/ticket/1144#comment:2 gives another
nice description of what coercions are in the context of Sage... :D
Though e.g. C and C++ do have automatic (or implicit) conversion, it
is usually referred to as (different kinds of) type *casts*.
C++ does have additional explicitly stated kinds of conversions
("real" casts): <static_cast>, <dynamic_cast> and <reinterpret_cast>,
of which <dynamic_cast> though does some kind of automatic conversion.
I would say that the Sage <-> C analogy is:
conversion <-> type cast
coercion <-> type promotion
C++ is of course a bit messier, as there are so many ways to convert
from one type to another.
The same is true for constructors taking other types as arguments;
though they are explicit in the defining class, there application can
be implicit, i.e. automatically performed by the compiler, but this
mechanism is afaik not referred to as coercion (not because it wasn't
coercion). In Sage, coercions are explicitly defined in the class
definitions, too; the mechanism is somewhat different though, because
it uses its own "parent" model that doesn't necessarily reflect the
class hierarchy.
Btw, the Sage reference manual discusses Sage's coercion model (which
is *not* the same as Python's):
http://www.sagemath.org/doc/reference/coercion.html
http://www.sagemath.org/doc/reference/sage/structure/coerce.html
But I don't agree with it (I'd say it isn't sound or really
consistent). ;-)
E.g., for me it doesn't make sense to (allow to) compare reals to
complex numbers (other than [in]equality):
sage: a=3.5
sage: b=CC(5.5+I)
sage: a<b
True
sage: type(a); type(b)
<type 'sage.rings.real_mpfr.RealLiteral'>
<type 'sage.rings.complex_number.ComplexNumber'>
sage: a=7.5
sage: a<b
False
(I wonder why < etc. is defined on CC at all.)
The fact that we put an ordering on CC is orthogonal to coercion, and
has been discussed elsewhere (and may very well go away). If/when we
do away with an order on complex numbers, the ordering on real/complex
comparisons will go away as well.
The Tutorial (http://www.sagemath.org/doc/tutorial/
programming.html#loops-functions-control-statements-and-comparisons)
gives another example:
sage: GF(5)(1) == QQ(1); QQ(1) == GF(5)(1)
False
False
sage: GF(5)(1) == ZZ(1); ZZ(1) == GF(5)(1)
True
True
sage: ZZ(1) == QQ(1)
True
# This means a==b is False and a==c is True though c==b *is* True:
sage: a=GF(5)(1)
sage: b=QQ(1)
sage: c=ZZ(1)
# (scroll away these definitions to surprise somebody else)
sage: a==b , b==c , c==a
(False, True, True)
sage: b==a , c==b , a==c
(False, True, True)
# HELL! 8/
(The tutorial warns in contrast to Sage it *is* consistently defined
in Magma.)
> a := GF(5)!1;
> b := GF(7)!1;
> c := 1;
> a eq c;
true
> b eq c;
true
> a eq b;
>> a eq b;
^
Runtime error in 'eq': Arguments are not compatible
Argument types given: FldFinElt, FldFinElt
In Python, the convention is that == and != never raise an error, so
False is returned if coercion fails (the two domains are incompatible).
"[...] A coercion from one parent to another must be defined on the
whole domain, and always succeeds. As it may be invoked implicitly, it
should be obvious and natural (in both the mathematically rigorous and
colloquial sense of the word). [...]"
There are situations where I would relax that and raise an exception
e.g. if a specific value can't be implicitly converted because it has
no representation in the target domain.
This was decided on because it made arithmetic easier to reason with,
but if there's consensus it could be relaxed (though if it were,
preferably the values without images would be very rare).
For "conversions" in Sage it is said that success might depend on the
actual values (as opposed to their types).
"[...] The goal of the coercion system is to facilitate this
[transparently doing arithmetic, comparisons, etc. between elements of
distinct sets], and at the same time being strict enough to not
resolve ambiguity or accept nonsense.[...]"
(http://www.sagemath.org/doc/developer/coding_in_python.html)
While ambiguity could be rejected (by exceptions or a compiler error
message) or resolved *in a defined way*, obvious (detectable)
"nonsense" should be rejected in all cases.
This is exactly what type safety means.
The goal *is* to reject nonsense in all cases. I'm not claiming it's
bug-free.
(If the programmer
*explicitly* requests nonsense, the program's behavior will be
undefined [by the programming language].
There are situations where type punning, for example interpreting a C
double as an unsigned int or bitfield, does make sense and does have
well-defined behavoir, that's why C++ does have <reinterpret_cast>.)
I hesitate to continue the discussion of what strictly or strongly
typed languages are, but IMHO Python is weakly typed, because
functions do not have formal signatures at all, lists can have mixed-
type elements, ... (unless you consider "object" a "true" type, which
doesn't help much). Reflection is another source of trouble, because
it introduces mixing of object and meta level, which is hell not only
in logic.
I view strongly/weakly typed is more of a continuum than binary
categories, but it's clear they're not very well defined. Of course
most words in the English (or any other) language are quite fuzzy, but
that doesn't mean they're not useful :).
You bring up a very interesting point here--all the coercion happens
due to operator overloading. I've usually thought of type systems as
an inflexible part of a given language, but here we're talking about
the "type system" of the Sage system as a whole, which is very
different than that of Python.
- Robert
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
