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 _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
