Jonathan S. Shapiro wrote: > On Tue, 2008-07-08 at 12:39 -0400, Swaroop Sridhar wrote: >> I actually don't understand this problem correctly. My understanding was >> that both the actual and formal arguments are converted into pairs the >> same way. > > Yes. > >> So, the arity of all functions is always one. > > Yes. That is the problem that we are trying to solve. > >> I don't see the ambiguity >> in the resolution of pattern matching here. > > There is no ambiguity in the formal sense. There is no ambiguity in the > behavioral sense. > > But the absence of ambiguity is not the same as the absence of surprise. > A C programmer who writes: > > (define (f x y) (pair x y)) > > expects that the invocation > > (f 1:int32 #\c "abc") > > will generate a compile-time error. That is: programmers coming from > conventional languages expect that agreement between the number of > expected arguments and the number of arguments actually presented will > be checked by the compiler.
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. 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. 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. >>> 5. In the presence of pair-consing, the presence of by-reference >>> types becomes problematic. At the moment, by-ref is restricted to >>> appear only in procedure argument types, and it is only safe there >>> because we can presume a form of region-based safety that is >>> guaranteed by the nature of the calling convention. >>> >> I think that the ref problem can be solved by requiring that the by-ref >> arguments can only be implicitly pair-consed, not explicitly. > > I think this is wrong. 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. At this point, we might as well consider including the & operator instead of by-ref arguments. 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. Swaroop. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
