On Tue, Jun 14, 2005 at 03:43:42PM +0200, "TSa (Thomas Sandlaß)" wrote:
> Chip Salzenberg wrote:
> >This:
> > multi sub is_equal(Integer $a, Integer where { $_ == $a } $b: ) { 1 }
> >hurts. At least as I've been given to understand it[*], is impossible
> >to implement, because the second parameter's type can't be precalculated
> >in order to prepare for MMD dispatching.
>
> Quite interesting that Cecil already has it. The thing is called
> Predicate Dispatch and there exist efficient implementation strategies.
Link link.
In case it matters, we're trying to support the Perl 6 semantics of
both ($a:$b:) and ($a,$b:). The former looks like something that
could be implemented with something called "predicate dispatch", but
the latter I'm not so sure of.
> >(This also means that the type of &is_equal:(...) is impossible to
> >express, unless I greatly misunderstand the &foo:() syntax. But
> >it doesn't matter what you call it if you can't call it.)
>
> The syntax might just be:
>
> &is_equal:(Integer $a, Integer where { $_ == $a } :)
>
It's a new type object every time, so every time you run that code you
get a new type object to describe $b, and therefore the type object of
the expression will never match up with the one used in the function
definition.
Are you suggesting that type equivalence tests include introspection
into the semantics of the closure? If so, what is "close enough"? If
not, how can Parrot ever know that
Integer where { $_ == $a }
is the same as
Integer where { $^foo == $a }
but different from
Integer where { $_ != $a }
? Down that path lay madness.[*]
> The only point is that I see no way for the compiler to optimize to
> anything but a dynamic dispatch.
s/the compiler/Parrot/, since the specific multi implementation can be
introduced after the call is compiled.
[*] There is another theory which states this has already occurred.
--
Chip Salzenberg <[EMAIL PROTECTED]>
