Ralf Hemmecke wrote:
>
> My dream would actually be something like
>
> /: (%, NonZero %) -> %
>
> Which would mean that the zero test would be at the time when one has to
> coerce an element from % to NonZero(%). An implementation of / would be
> certain that it never gets 0 as its second argument.
>
This is fine if we can statically prove NonZero. But typically
this has to be done by runtime test. And then I prefer test
inside '/'. Namely, if test is done in other places then it
is erorr prone or at least leads to code bloat (if typesystem
automatically introduces checks). And if NonZero(%) is a
real type, then it may be quite hard to optimize space usage
by moving check into '/'. And at philosopical level, why
is x::NonZero(Integer) raising error better than '/' raising
error?
> > It seems that you want a category, say 'NoRuntimeErrorPossible'
> > meaning that no opeation will raise errors and you want that every
> > (or most) domains have this category.
>
> No, that's not my intent. All I want is that if the function raises an
> exception it should be clear statically (at compile time) under which
> conditions such an exception is raised (like DivisionByZero). And these
> conditions are part of the interface of the function, i.e. its API. And
> it would be clear which of the many exceptions is raised when.
>
Except for the last part you describe Java exceptions. The problem
is that in Java looking at API you can not say if exception is
really raised or that it is specified just to satisfy formal
rules. Consider:
y := x^2 + 1
z := x/y
in real domains exception is impossible, but normal typesystem
will force you to say that this snippet may raise DivisionByZero
exception.
> > BTW: Java tries to "control" exceptions via type system, and this is
> > widely regarded as a failure.
>
> What exactly is the failure? That there is a hierarchy of exceptions?
>
AFAIU:
1) To have sound specification you have to say that a function
may raise an exception if it calls anything which may raise
this exception and the exception is not caught. This leads
to long lists of possible exeptions that are of little
informative value and burden to maintain.
2) The formal rules are not smart enough to find out if some
expression is impossible (like in the x^2 + 1 example above).
3) Since exceptions are part of API there are serious limitations
which functions may be passed as arguments. Think about
functions like 'map': in 'map(f, l)' normally 'map' itself does
not raise any exceptions, but it calls 'f' and it is useful to
have 'f' which may raise exceptions. In Java there are no
parametric types so this is serious limitation. But even
with parametric types we have burden of adding extra exception
parameter to all types and properly propagating it.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
