Bernd Brassel wrote:
> This is of course just a question of the viewpoint. The main point is
> though, that there are more possibilities for generic functions on
> types
> which you know all the constructors of. Do you agree with that?
I find it hard to either agree or disagree with your statement because
the term generic function is so, uhmm, generic. I can easily think of
a function for which it would be essential to know all constructors,
namely the function which simply counts the number of constructors.
However, I'm not sure whether this is what you meant.
> [...]
>
> Do not be surprised, but this is the very reason why I do not like the
> integer type also. Why restrict a functional-logic language in such a
> way that so many basic functions like (+),(-),take, drop, splitAt and
> anything employing the basic type Int are not usable in a logical way?
bbr_at_informatik.uni-kiel.de
IMHO this indicates that Curry's constraint solving capabilities are
too limited, but I wouldn't take it as an argument against the types
Int or Float themselves.
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?
> 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.
> [...]
>> Incidentally, the point that you need disequality constraints in
>> order to reasonably define (===) for numeric data types (and may
>> be for potentially infinite data types as well) makes me think
>> that defining (=:=) in terms of (===) is putting the cart in
>> front of the horse. I think, it should rather be done the other
>> way around:
>> x === y | x=:=y = True
>> x === y | x=/=y = False
>
> All very nice but I think you agree that this demands more of the
> implementations of Curry. 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?
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:56:47 CEST