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

[Elf]

On Thu, 31 Jan 2008, John Cowan wrote:

> Elf scripsit:
>
> > > (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.
>
> Okay, make it (random 2) then, smartass.

sure, min 0, max 1.  however, youre forgetting to check that the element exists
before car'ing.  i may be under a mistaken impression, but when working with
rest lists, i thought that one should always check size before trying to grab
elements.  such restrictions are part of why i say its easy... if one 
omits this, its a bit harder, but will also crash in other ways from incorrect
code.

> > additionally, this is enough information, even unevaluated, to do
> > many checks at compiletime and leave only the relevant unresolved bits
> > (if any) runtime checked.
>
> By all means.  But you keep saying "It's easy", when what you mean is
> "Some subcases are easy."

fair enough, but i havent found a subclass that would remotely approach
the halting problem yet :)


> > so the multiple-argument procedure form generalises to a nested
> > single-argument procedure form.
>
> I understand currying; it's the reciprocal claim about multiple values
> I didn't and don't follow.
>
> > if values was the first-class dual of an argument list,
>
> [example snipped]
>
> > if it was a dual, that resolution and application should work, methinks.
>
> That disposes of the claim that multiple values is the dual of an argument
> list, but that's not my claim:  my claim is that multiple values is the
> dual of multiple arguments, and neither one needs a list to implement
> unless the number of arguments or values is indefinite.  You can pass
> arguments in registers (broadly construed), and you can pass back values
> in registers too.


sorry, clarify what you mean by 'multiple arguments' then?


> > values isnt a first-class object, its just a hack.
>
> Only in the sense that passing multiple arguments rather than allowing
> just one (a list, not a curried function) is a hack.  If it's a hack,
> it's pretty basic to Scheme and most other languages (excepting ML,
> Haskell, and Q).

its not basic to scheme, as it didnt exist pre-r5.  its also not first-class:
you need to wrap any values return in some variant of call-with-values to get
the data out again, it cant be used or passed directly.  theres a good post
on pobox.com/~oleg/ftp/ somewhere about the non-first-class nature of values.


> > its why the most common form of the consumer lambda-list in
> > call-with-values is just a rest arg. :)
>
> Really?  I'd expect that, since most multiple-value-returning procedures
> return a definite number of values, that a proper argument list would
> be the most common case.  It's certainly the case that CL provides the
> most support for.

the most common cases of call-with-values that i see are for wrapping 
macros and continuations where the return value(s) are not known beforehand,
and in most cases will not be multival, but safety and generality must 
prevail.


so i have a real question: can you give an instance of where multiple values
(in the call-with-values sense) is clearly a space/time/efficiency/sanity/
readability saver/improvement/benefit over some other means of return? 
im not trying to go nitpicking and ill try not to argue any point, its just
that while i said earlier that there were clear cases, i havent been able 
to think of one (except fork, but thats a different scenario altogether).
im honestly wondering where it would be used and more-or-less unambiguously
determined a good thing (apart from handling cases of wrapping continuations
only required because the values construct exists.  self-loops do not count.)


> (The below was randomly chosen without reference to the message I write
> or the one it's responding to.)

heh, im elf, not dwarf. :)  i always like your random quotes.

-elf