[bitc-dev] Resolution on tuples

[Christopher Gilbreth]

On Tue, Aug 10, 2010 at 6:30 PM, Jonathan S. Shapiro <shap at eros-os.org>wrote:

>
> Given all of this, it would not be unreasonable to say to systems coders:
> if you want a guarantee of non-allocating application on multi-argument
> procedures, you need to convert the procedure to take a single argument of
> tuple type. This rule is easily checked by a design rule checker, and fairly
> easy to explain.
>
> And if we do this, then I don't see why the curried form of application
> needs to be removed from the language for application use. The "no
> allocation in call" requirement is not intended as a general restriction on
> application structure. A more precise statement would be "we need the
> ability to write *certain* applications that obtain this guarantee as a
> consequence of their implementation".
>
>
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.

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?

Thanks,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20100811/269d5ad8/attachment.html