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

[Elf]

On Thu, 31 Jan 2008, John Cowan wrote:

> Elf scripsit:
>
> > i was bringing up the case-lambda and parameters as being special cases
> > of forms with the number of required args not necessarily the same as
> > the maximum number of args, ie its  'rest?' but its not a true rest,
> > in that only certain values are valid arities.
>
> Well, sure.  But there are lots of Scheme procedures written like that: it's
> by no means always the case that a procedure with a rest parameter accepts
> an arbitrary number of arguments.  Case-lambda is just a way of formalizing
> that with a little error checking.
>
> 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.


> > im fundamentally opposed to returning with call-with-values any more than
> > absolutely required.
>
> It's never *absolutely* required; one can always return a list.  So I
> don't know what you mean here.

there exists problems where returning multiple values is a natural and
effective tool.  there exists a far larger set of problems where returning
multiple values just means several extra unnecessary procedure calls.  and
there exists problems where its kinda a grey area.  im still unsure whether
i like tcp sending back a multival for ports, for example.  i think i/o
ports would be a cleaner solution in some ways.  multival returns make me
nervous when dealing with potentially time-sensitive i/o.... what happens
if theres an interrupt between the creation of the first and the second?
what happens if the connect fails when one is created and the other hasnt 
been yet?  it just seems strange.  otoh, if we ignore these problems, having
the two separate ports is nice in terms of multithreaded readers/writers.
i think my biggest problem with the whole multival issue is twofold:
1) its several extra evaluations and calls, with theoretically complex
   semantics.
2) the r5rs and srfi support procedures for multival support seem very
   unnatural and contrived.  the procedure arg ordering(s), binding order,
   syntax, calling conventions, and fall-through cases are not consistent
   between procedures, not obvious to follow (is it binder then generator, or
   generator then binder?  and where does body go?), and the functionality
   seems very weak.  as you previously mentioned, one can always return a list.
   it does not seem to add any generality nor does it cleanly sugarcoat
   a pattern.  perhaps if there was no requirement to wrap it in
   call-with-values, it would be more palatable.

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.  thats just my feeling on the
matter.   the extra syntax requirements and cpu time i think are what annoys me.

sorry for the long aside.

-elf



>