I noticed that if I use inferred function types (at least with it blocks), that the described function type is not accurate. For example, if I call a function like list.find |Int v->Bool| {v.toStr == "3"}, the Func shows as being a |sys::Int->sys::Bool|, but if I say list.find{it.toStr == "3"}, it shows as |sys::Obj->sys::Void|.
I have some interest in using the parameter list to optimize handling in some cases. That is, if someone doesn't ask for one of the parameters, I don't want to bother calculating it for them. So, I'd prefer if the parameter types were accurately reported.
Alternatively, I could make a different versions that do or do not calculate the optional parameter values. Or perhaps not worry about it. (My current situation may or may not need to optimization, but I could imagine seeing similar cases or perhaps other use cases in the future.)
Just wondering if this is an option to consider.
brianThu 25 Jun 2009
Promoted to ticket #651 and assigned to brian
brianThu 25 Jun 2009
Ticket resolved in 1.0.45
Tom, try out this change set and see how that works for you
tompalmerThu 25 Jun 2009
Thanks for working on this. I haven't been working from hg (or been doing bootstrap builds for a long while), but maybe I should work that out.
tompalmer Thu 25 Jun 2009
I noticed that if I use inferred function types (at least with
it
blocks), that the described function type is not accurate. For example, if I call a function likelist.find |Int v->Bool| {v.toStr == "3"}
, theFunc
shows as being a|sys::Int->sys::Bool|
, but if I saylist.find{it.toStr == "3"}
, it shows as|sys::Obj->sys::Void|
.I have some interest in using the parameter list to optimize handling in some cases. That is, if someone doesn't ask for one of the parameters, I don't want to bother calculating it for them. So, I'd prefer if the parameter types were accurately reported.
Alternatively, I could make a different versions that do or do not calculate the optional parameter values. Or perhaps not worry about it. (My current situation may or may not need to optimization, but I could imagine seeing similar cases or perhaps other use cases in the future.)
Just wondering if this is an option to consider.
brian Thu 25 Jun 2009
Promoted to ticket #651 and assigned to brian
brian Thu 25 Jun 2009
Ticket resolved in 1.0.45
Tom, try out this change set and see how that works for you
tompalmer Thu 25 Jun 2009
Thanks for working on this. I haven't been working from hg (or been doing bootstrap builds for a long while), but maybe I should work that out.