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

[Elf]

On Thu, 31 Jan 2008, John Cowan wrote:

> Elf scripsit:
>
> > > In any case, figuring out how many of its arguments a procedure
> > > examines is equivalent to solving the halting problem, alas.
> >
> > um, how do you figure its the same as the halting problem?  to me it
> > clearly isnt.  min arg counts are trivial, max arg counts are slightly
> > harder but clearly feasible, and determining the number of args for
> > something like case-lambda... well, go look at the svn logs at my insane
> > (reverted) case-lambda.  its a fairly trivial problem.
>
> Yes, if you get control at the macro level.  But the rest list is a list;
> the procedure can pass it, or parts of it, to arbitrary other procedures
> that act in arbitrary ways on it, so you can't be sure exactly which
> parts eventually get looked at and which don't.
>
> You can handle stereotyped cases like case-lambda and the DSSSL functions,
> but when people use a rest argument and then pick optional arguments out
> of it with explicit cars and cadrs and all, you aren't going to be able
> to return something that encodes "accepts two, three, or five arguments".

unless the procedure accepts unlimited arguments (explicitly or implicitly),
it should be possible to trace how many args are absorbed.  it would be 
seminightmarish but definitely possible.  trivial case is if theres one or
more conditional tests on the length of the rest param.  it gets ugly when 
you write a grammar just to trace c*r and their ilk, and to trace procedure
calls.  see the misc/inline.scm file... with a bit of modification that 
could do it, just very slowly.


> > perhaps if there was no requirement to wrap [multiple values] in
> > call-with-values, it would be more palatable.
>
> See SRFI 8, which Chicken implements and which is designed to make
> receiving multiple values very easy.
>
> > example of the last bit: (define (foo x)
> >     (values x x))
> >
> > (define (bar x y)
> >     (+ x y))
> >
> > (bar (foo x)) would be a valid call, with bar-x bound to foo-x and
> > bar-y bound to foo-x, if multivals were handled better.
>
> I can't find the paper that explains why this superficially attractive
> idea (which has been reinvented over and over) is actually a nightmare
> of pessimization.  But just consider the problem of the flow analysis you
> need to do in order to figure out at compile time whether bar is being
> called with the right number of arguments or not.

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.

> > the extra syntax requirements and cpu time i think are what annoys me.
>
> In fact the CPU cost is nil on Chicken (or any CPS-based compiler):
> all that's happening is that the multiple-valued procedure is calling
> its continuation with two or more arguments -- or zero arguments, if
> it returns (values).  Multiple values are just the dual of multiple
> arguments, and CPS makes them perfectly equivalent.

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.
even if we pretend that procedure calls are free, theres at least 1 extra 
step for the apply/continuation between the consumer and the thunk.

multiple values are not the dual of multiple arguments.  lists are the 
dual of multiple arguments.  the simplest theoretical construction for
multiple args is currying, and at least in my current thinkings, the dual
of currying is nested lists.

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

-elf

>