Graham Klyne <[EMAIL PROTECTED]> writes:
> > isSubsumedByWith :: TBox c -> c -> c -> Bool
> > isSubsumedByWith [] c d = isALSubsumedBy c d
> > isSubsumedByWith _ _ _ = error "TBox reasoning not supported for AL"
>
> and immediately noticed that I might also write this:
>
> > isSubsumedByWith :: TBox c -> c -> c -> Bool
> > isSubsumedByWith [] = isALSubsumedBy
> > isSubsumedByWith _ = error "TBox reasoning not supported for AL"
A difference is that you can generally assume that:
let x = isSubsumedByWith [] 0 in
x 0 && x 1
will evaluate 'isALSubsumedBy 0' only once, so if it has some work to
do before waiting for the second argument, the work will be shared for
both arguments. They will give the same result anyway, but may need
different amounts of work to do.
OTOH if isALSubsumedBy does not have any shared the work to do, but is
itself defined with two arguments, then applying it to both arguments
at once is more efficient (has less overhead). Manually lifting a
partial application is valuable only when we expect that it shares
some real work.
An optimizing compiler can change the effect it in either direction.
The above is not a formal guarantee, only some expectation which might
be useful for tuning performance.
> I think it is this: Suppose I evaluate an expression:
>
> let s = isSubsumedByWith [foo] in seq s e
>
> then I think the first case will return a legitimate function, albeit
> one that returns error when it is applied, and the second will cause
> an error to be returned immediately. Am I right?
Yes. And this time an optimizing compiler can't exchange that. While
program termination is a part of the language semantics, the amount
of recomputation and sharing is not formally specified, and you can at
most hope that the compiler would do no worse than the obvious naive
implementation would do (i.e. that its optimizations will not become
pessimizations).
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
_______________________________________________
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
