Re: Questions about parsing boolean and casting to anyelement

On Mon, Feb 16, 2009 at 08:03:33PM -0500, Tom Lane wrote:
> ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)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