Bernd Brassel wrote:
> Wolfgang Lux wrote:
>> Incidentally, what about other (abstract) types representing entities
>> not defined by the user, e.g., file handless, port numbers, etc. Do
>> you dislike them as well because they cannot be used in a logical
>> way?
>
> What I dislike about them is that you get run-time errors if you
> try to
> use them in a logical way. As there are no type classes or equivalent
> method in Curry, nothing in the type system prevents you from creating
> (unknown::FileHandle). And if we had a possibility to express a type
> constraint, e.g., (unknown :: Narrowable a => a) would you still
> insist
> on making (=:=) work on file handles?
Probably not. However, I would question why unknown (or a free variable
declared with a let/where free declaration for that matter) should have
a Narrowable constraint right from the start. Also note that even with
a Narrowable constraint, it would be possible to apply primitive
functions
to a free variable causing suspension of those functions.
>>> I would much prefer a standard Int which is fully narrowable and
>>> maybe
>>> provide the primitive type in a library if anyone really needs it.
>>> But I
>>> would not care nuch if that primitive type is not in the supposed
>>> class
>>> of types for which (=:=) is defined.
>>
>> I would care. Agreed that the ways how you can use values of
>> primitives
>> types in a logical way are limited. But why restrict them further?
>> This
>> looks like throwing out the baby with the bathwater.
>
> This notion you cite means that we loose a very good thing just
> because
> we want to get rid of another very unimportant thing. So what could be
> the "very good thing" in this case? It must be the restricted use of
> logical primitives like (=:=) and unknown on primitive types.
Huh? In what sense are (=:=) and unknown restricted for primitive types?
I would (also?) like to see Curry implementations to solve equations
like
x + 1 =:= 4
by binding x to 3. However, if they do not at present, this is not the
fault of (=:=) but of (+) which requires ground arguments. And in fact
if Curry implementations in the future will solve that equation, I hope
that they will not do it by narrowing, but by using the algebraic laws
of integer arithmetic (i.e., using a constraint solver).
> This "very
> good" seems to be very arguable to me. What is the "very unimportant
> thing" we could get rid of? Suspension also known as "run-time error"
> thereby reestablishing the completeness of the logical search which
> was
> lost to flaundering. Does not seem like a "baby-case" to me at all.
I don't buy this statement. As you well know, talking about completeness
of logical search is void without reference to the search strategy
employed (unless you restrict yourself to finite domains of course).
IMHO, the presence of rigid functions is one of the advantages of Curry
as it gives the programmer better control over when search should take
place and when not. By a judicious use of rigid functions one can
improve
performance (and in some cases ensure termination at all). On the other
hand, the price to pay is that there are cases where goals may flounder.
And, yes, removing a useful language feature just because it may cause
programming errors in other cases, is what I call throwing out the baby
with the bath water.
>>> So why put it into the basic definition
>>> of the
>>> language, as long as simpler approaches might work just as well (or
>>> better)?
>>
>> Because the simpler approach does work only for algebraic data
>> types and not for other types?
>
> Therefore it really works in contrast to "working only if the order of
> evaluation is favourable".
Maybe we have lost context here. The above statements were coming
from a discussion on whether (===) should be defined in terms of
equality and disequality constraints, namely
x === y | x=:=y = True
x === y | x=/=y = False
I read your first answer as being opposed to that definitions because
it requires disequality constraints. And my answer to this was that
you need disequality constraints anyway for a definition of (===)
unless you (arbitrarily!) restrict (===) to algebraic data types. I
do not see the relation of this to evaluation order.
Incidentally, I have another argument in favor of (=:=) and (=/=) as
primitives instead of (===). x=:=y can be solved even if both arguments
are unbound variables. For (===) you can do this only by either
introducing disequality constraints again or by instantiating both
arguments non-deterministically leading to possibly excessive and
unnecessary search.
Regards
Wolfgang
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mi Apr 11 2007 - 11:57:06 CEST