On Mon, Feb 16, 2009 at 08:03:33PM -0500, Tom Lane wrote: > ITAGAKI Takahiro <itagaki.takah...@oss.ntt.co.jp> writes: > > I hope anyelement could be used in cast because casts are supported by > > almost programming languages where template or generics are available.
Programming languages with "generics" (aka, parametric polymorphism in literature) should mean that you need *less* casts because the type system is expressive enough that you don't need to "escape" through a cast. > I think what you're suggesting is that inside a polymorphic function, > anyelement would somehow be a macro for the type that the function's > current anyelement parameter(s) have. It's an interesting idea but > it's just fantasy at the moment; I don't even have an idea of how we > might implement that. A couple of solutions would immediately present themselves; making functions first class objects and introducing something called "type classes" (please note these bear little resemblance to "classes" in object orientated programming). If functions were first class objects; you could pass in the "input" function (i.e. boolin, or numeric_in) to the "array_find" function directly call it in place of the "magic" cast syntax (magic because it has to figure out the type of the LHS, whereas if it was a function with known type then it wouldn't need to infer the source type). Type classes[1][2] are a general mechanism for making the "magic" above tractable and sound. The cast above would be exactly analogous to the "read" function in Haskell, and is used very regularly in most code. > In the meantime I'm more convinced than ever that we should throw an > error for attempting such a cast. If people are imagining that it will > do something like that, we need to disillusion them. Yes, sounds sensible at the moment. -- Sam http://samason.me.uk/ [1] http://portal.acm.org/citation.cfm?id=75277.75283 is the original paper [2] http://portal.acm.org/citation.cfm?id=141536 extends them to have multiple type parameters, not for PG but nice to know it's been done before and isn't new ground -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
