Re: [Chicken-users] Re: A few questions

[Elf]

On Thu, 31 Jan 2008, John Cowan wrote:

> Elf scripsit:
>
> > unless the procedure accepts unlimited arguments (explicitly or implicitly),
> > it should be possible to trace how many args are absorbed.
>
> Consider this:
>
> (define (foo . rest) (if (= 1 (random 1)) (car rest) #f)

in this case, 0.  this entire expression should have been removed by the
compiler and replaced by #f, though.

> How many arguments does it consume?
>
> > any compiler should know the argcount and retval of any procs
> > its handling.  it would mean adding a single field to the AST.
> > not exactly difficult.
>
> Again, you are misunderestimating the scope of the problem.  Consider this:
>
> (define (bar lst)
>     blah blah ...
>     (apply values lst))
>
> How many values does it return?

i didnt underestimate the scope.   values from a runtime argument is clearly
only computable at runtime.  this is part of the problem with values :) 
the number of args generated is any, ie, perfect rest list :) adding a 
field to the AST does not necessarily mean that its a final integer (or 
set)... lets see, if we had (baz x y z (bar lst)), we know that the argcount
for baz is (+ 3 (ret-arity-bar : min 0 max -1)) (where max -1 means no limit).
we know that ret-arity-bar is length lst.
so we can do all the resolutions and checks immediately upon calling bar with
some lst, without even running the procedure body itself. 
additionally, this is enough information, even unevaluated, to do many checks
at compiletime and leave only the relevant unresolved bits (if any) runtime
checked.

> > there are (at minimum) an extra 3 apply/continuations, if i just
> > calculated it correctly, because of the call-with-values itself,
> > the additional apply, and the thunk wrapper for the values generator.
> > procedure calls arent free.   this is also neglecting the extra layer
> > of arity checks.
>
> Fair enough, though Chicken can inline simple cases like this.
>
> > multiple values are not the dual of multiple arguments.  lists are
> > the dual of multiple arguments.
>
> True in another sense.
>
> > the simplest theoretical construction for multiple args is currying, and
> > at least in my current thinkings, the dual of currying is nested lists.
>
> I don't follow that.

a lambda abstraction (procedure) is simply a scoped variable-substitution 
operator.  the application of (lambda var . term) val  replaces all occurences
of var in term with val. 
term may itself be a lambda, ie :
(lambda var1 . (lambda var2 . term2))
and applied thus:
((lambda var1 . (lambda var2 . term2)) val1) val2
or in more convenient form :
(lambda var1 . (lambda var2 . term2)) val1 val2
as val1 and val2 are (or can be made) independent of one another and in the 
same pre-application scope, the ordering is irrelevant, ie
(lambda var1 . (lambda var2 . term2)) == (lambda var2 . (lambda var1 . term2))

so the multiple-argument procedure form generalises to a nested single-argument
procedure form.

the application of this form looks like a nested apply with a nested list arg.

at least to me, right now.

apologies if im being unclear, im not at my sharpest atm. :(

> > if they WERE duals as you claim, the point you made above regarding
> > (bar (foo x)) would not hold.
>
> Or that.

if values was the first-class dual of an argument list, the resolution of
(define (foo a) (values a a)) 
(define (bar b c) (+ b c))

(bar (foo x)) 
resolve operator:
((lambda (b c) (+ b c)) (foo x))
resolve operand:
(foo x) => values x x
substitute in first-class values :
((lambda (b c) (+ b c)) x x)

if it was a dual, that resolution and application should work, methinks.

to make values into the dual of an arglist, it has to be listified first.
be listified first, hence the need for the lambda (lambda list) in 
call-with-values as the consumer.

values isnt a first-class object, its just a hack.  its why the most common
form of the consumer lambda-list in call-with-values is just a rest arg. :)


-elf


>