This is a bit weird:
open module Darray
{
private struct darray_ctl[T]
{
a: varray[T];
resize: ulong * ulong --> ulong;
}
// I need to figure out how to hide this representation
typedef darray[T] = &darray_ctl[T];
fun len[t] (a:darray[t])=> Varray::len a.a;
proc pluseq[t] (a:&darray[t],v:t) {
newsize := a.resize (maxlen a.a, Varray::len a.a + 1ul);
if newsize != maxlen a.a do do_resize(*a,newsize); done
var z = a.a; z += v; // hack to workaround compiler error Address non
variable
}
}
I vaguely understand why the Varray:: prefix is required in function len,
but I don't understand why it is required in pluseq. The argument type
is varray[T], which doesn't match Darray::len[T]. I actually get a weirdo
error if I write just "len a.a" saying vs/ts mismatch, "len" is not a type
variable.
Note "maxlen" just works because there's no maxlen in Darray.
Well, if it doesn't match due to vs/ts mismatch, why doesn't the overload
resolution engine just discard that candidate and keep going?
It is a bit of a problem: if we discard on any error, then find no match,
the best we can say is "cant' find a match", we can't show any kind
of error message. That would be a bit nasty.. unless we keep track
of how each candidate is rejected.. ugg..
*** ts/vs mistach means: if you have a polymorphic function with
type variables vs and you call it with type arguments ts, then
the two lists have to be the same length.
Above the call to Varray::len, which is polymorphic and has vs=t,
doesn't supply any bindings for that t, but overload resolution
can do type deduction on the argument a.a and discover that
we should set t-->T (the type parameter of Darray::len).
That is, ts=T. Then vs = list(t) and ts=list(T) are the same length
and can be zipped together to form the type instantiation.
If overload resolution tries Darray::len first, it should get a
type mismatch: a darray isn't a varray, so the Darray case should
be rejected. But it gets an error trying to discover this, a vs/ts
mismatch, and fails the whole compilation instead.
So I can trap that, but how do I trap it carefully so "real" client
errors don't just lead to a "no match" error?
YOU WILL HAVE THIS PROBLEM WITH FELIX in many
different forms. It is one of the downsides of the sophisticated lookup
system, that Felix can only be sure what you meant if you get it right.
Leave out just one semi-colon and all hell breaks loose.
--
john skaller
skal...@users.sourceforge.net
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
