Chip Salzenberg wrote:
Link link.
http://www.cs.washington.edu/research/projects/cecil/www/Papers/gud.html
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.
I never understood the difference. So if someone were so nice to
enlighten me...
(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.
Hmm, looks like we have very different views of how dispatch works
and what the acting entitys are. To me &is_equal is an object that
knows a set of targets basically indexed by their :() --- let's
call that the implementation signature. The call site knows the list
of parameters and &is_equal. From this information a set of applicable
targets is calculated. This is the first time that the where clause
comes into play. If it returns false, that target is not considered
any further. When it returns true the closure comes into play when
the most specific target is determined. The value and type of $a are
known and as such constrain the type of $b and produce a more specific
match then an unconstrained Integer. In other words the type of $b
is a parametric, single value subtype of Integer.
Are you suggesting that type equivalence tests include introspection
into the semantics of the closure?
No. I just think that the closure is called at dispatch time as discribed
above and that this is the very moment when the instanciation of the
parametric type of $b takes place.
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 }
It doesn't. The Code object stores the targets and the respective
closures.
? Down that path lay madness.[*]
MMD becomes MAD ;)
s/the compiler/Parrot/, since the specific multi implementation can be
introduced after the call is compiled.
Yep, but the type system is still there. And you are right, that there
is no chance in pre-calculating such dispatches. But that is the expected
price to pay for predicate dispatch. And the target selector living inside
the MMD object might actually be 'recompiled' during runtime when new
instances are added. That is similar to the automata behind regular
expressions.
Regards,
--
TSa (Thomas Sandlaß)
