[bitc-dev] Re-examining pair consing

Tue Jul 8 14:58:37 CDT 2008

On Tue, 2008-07-08 at 14:48 -0400, Swaroop Sridhar wrote:
> OK. I see the problem now. Stepping back, is it too much to ask that the
> programmer parenthesize the arguments appropriately?
> 
> That is, instead of writing
> 
> (define (f x y) <body>) and (f 10 15 25),
> 
> the programmer should write
> 
> (define (f (x, y)) <body>) and (f (10, (15, 25)))
> 
> In this view, actual arguments must match formal arguments exactly, and
> arity can be checked trivially.

Sanity test: if you had to use this syntax, how long would it take you
to switch to O'Caml?

> The number of arguments to a function need not be limited to one.
> If we require that all by-ref arguments be written at top-level of a
> function argument (that is, not inside a pair pattern), the safety
> problems with by-ref arguments does not arise.

Yes. That is what motivated my second proposal, in which functions
continue to have multiple arguments and pair-consing is only used to
handle the varargs-like case.

> Therefore, in this scheme, the only addition to existing BitC is pair
> patterns in function argument positions. Function overloading based on
> number of parameters can be simulated using pair patterns.

Yes, but this does not explain how to check argument arity at the same
time.

> > Contrast:
> > 
> >   (define (id-by-ref x (by-ref y) (pair x y))
> > 
> > with
> > 
> >   (define (id-by-ref arg:(pair x (by-ref y)) arg))
> > 
> > In the pair-consing view, these two ought to be the same, but they
> > aren't because by-ref is appearing inside a type constructor. What is
> > going to happen here is that the pair-consing implementation of the
> > compiler will, in effect, construct the second version from the first.
> 
> If we allow by-ref to be first class, I agree that we will have to do
> things like region analysis.

Yes. My point was that using pair-consing either means that we drop
BY-REF or that we admit it as first class.

>  At this point, we might as well consider
> including the  & operator instead of by-ref arguments.

Yes. Which is very scary. Which is why I identify this as a problem
rather than a feature.

> I was trying to limit the scope of by-ref types to top-level
> pattern-matchable formal arguments only, so that there is no way to name
> an aggregate value with an embedded by-ref pointer.

Yes. More precisely: so that the necessary region analysis was reduced
to a single trivial case that is syntactically ensured.

shap