[bitc-dev] Resolution on tuples
Jonathan S. Shapiro
shap at eros-os.org
Wed Aug 11 17:03:39 PDT 2010
On Wed, Aug 11, 2010 at 7:23 AM, Christopher Gilbreth
<cngilbreth at gmail.com>wrote:
> On Tue, Aug 10, 2010 at 6:30 PM, Jonathan S. Shapiro <shap at eros-os.org>wrote:
>> I don't quite understand everything going on here, but since it's an
>> important design decision for the language, I hope you won't mind
>> elaborating a bit --
>> You're envisioning a future version of BitC which does have currying, and
>> also has a currying-style function application syntax "f a b" for f(a,b).
>> Presumably any issues with whitespace, semicolons or layout rules would have
>> been resolved in some manner or another.
> The "no allocation in call" requirement can then be guaranteed by
>> programmers if they pack their function arguments into a tuple; and the
>> design decisions you've made above were chosen to provide a smooth
>> transition to this scenario in the future.
Not the future, but otherwise yes. A more precise way to state the
requirement is that functions of one argument (which may be a tuple) are
guaranteed not to allocate.
> The question which comes to mind is: couldn't a programmer also
>> guarantee that his function calls don't do implicit allocations by just not
>> doing any partial applications? Would such fully-saturated function calls
>> use native calling conventions?
Unfortunately that isn't simple to do. Given a module that supplies:
add: 'a -> 'a -> 'a
what is the proper saturation? We can't even just arity-lift aggressively,
TakesTwo: 'a -> 'b -> 'c -> 'd
may only take two arguments, and we don't have anything in the signature
that tells us this. Arity lifting this to three arguments would pessimize
The end result is that cross-module calls are difficult to optimize in the
presence of separate compilation.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev