Jonathan S. Shapiro wrote:
> 4. In the presence of a type variable in the last parameter, position,
> implicit pair-consing defeats the ability to check that the call
> site has the correct number of parameters. That is, given:
>
> (proclaim f: (fn (int 'a) 'b))
>
> we effectively get a compile-time varargs expansion:
>
> (f 1 #\c)
> (f 1 #\c #\d) 'a bound to (pair char char)
> Concerning arity checking, there is no "correct" solution. Any syntactic
> assist by the compiler is necessarily just that: an assist. Given:
>
> (proclaim f: (fn (int 'a) 'b))
>
> there isn't any semantic difference between:
>
> (f 1 #\c #\c)
> (f 1 (pair #\c #\c))
> (f (pair 1 (pair #\c #\c)))
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.
That is,
(define (f a b c) <body>) is the same as (define (f (a, (b, c)) <body>)
and
(f 1 2 3) is the same as (f (1, (2, 3)))
where the pattern matching is a=1 b=2, c=3
(f 1 2 3 4) is the same as (f (1, (2, (3, 4))))
where the pattern matching is a=1 b=2, c=(3, 4)
(f 1 (2, 3) 4) is the same as (f (1, (2, 3) 4))))
where the pattern matching is a=1 b=(2, 3) c=4
So, the arity of all functions is always one. I don't see the ambiguity
in the resolution of pattern matching here.
Further, this is not really varargs. For the function
(define (f x:int y) <body>)
f: (fn (int, 'a) 'b)
we can apply any number of arguments at the call site as in
(f 10 #t #f 'c "asdf") , which will be converted to
(f (10, (#t, (#f, ('c, "asdf")))))
However, the <body> of the function has no way to extract individual
"arguments" other than 10 and the pair (#t, (#f, ('c, "asdf"))).
That is, the <body> of function f cannot select the elements from
argument y. Otherwise, y would have received the corresponding pair
type, not the variable 'a type.
So, I think that this is different from the overloading in the number of
arguments as in C++, since in that case, all arguments are namable by
pattern matching, and therefore usable in the body of the function.
> But I am considering the following syntax modification:
>
> 1. In the lambda form, add the ability to write:
>
> (lambda (x y ...) body)
>
> with the intended meaning that there is no maximal
> expected arity for this procedure.
>
> 2. In the application:
>
> (f arg arg ... arg)
>
> we only pair-cons up to the expected arity. If additional
> parameters remain, it is a compile-time error.
>
> 3. Possibly add new syntax
>
> (apply-1 f arg)
>
> in which the underlying parameter pair type is merely checked
> for compatibility without checking for arity.
For the function
(define f (lambda (x y ...) body))
do we give f the type (fn ('a 'b `dyn) 'c)
where `dyn is similar to type dynamic, which will be resolved and
checked at runtime? (That is, extraction if elements from the `dyn pair
can result in a runtime error?)
If this is the case, is the difference between apply and apply-1 the
fact that apply requires `dyn to resolve to nothing, but apply-1 allows
`dyn to denote any pair-consed sequence of arguments?
> 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.
That is, writing
(define (f (x : (by-ref int) y:int)) <body>:int)
is legal, and f gets the type f:(((byref-int), int)) int)
Any uses of x within f are safe due to implicit value extraction for any
rvalue uses of x.
However, writing
(define (f (x:((by-ref int), int)) <body>:int)
is not permitted and therefore, the programmer cannot use x to name a
structure containing a by-reference value.
All applications of f must be written in the form
(f x_actual 25)
It cannot be written as
(f (x_actual, 25)) since the argument to pair constructor is an rvalue
usage and will extract the value stored in x_actual.
Swaroop.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
