On 5/27/2020 1:50 PM, Jens Axel Søgaard wrote:
Den ons. 27. maj 2020 kl. 19.27 skrev George Neuner
<gneun...@comcast.net <mailto:gneun...@comcast.net>>:
On 5/27/2020 6:34 AM, Jens Axel Søgaard wrote:
>
> In standard Racket an application doesn't communicate how many
values
> a function is expected to produce.
You can ask: see procedure-result-arity
https://docs.racket-lang.org/reference/procedures.html
I think procedure-result-arity answers the question "how many
values could this procedure return?" and not "how many values
is the procedure expected to return in this context?".
Oh, I get it ... it's not that you "don't know" what's expected, it's
that you've got something that returns N values on some path and M
values on some other path, etc. and you can't predict which path will
be followed.
Yeah, that is a problem: e.g., I don't think procedure-result-arity
works for case-lambda where different invocations can return different
numbers of results.
In that case, better to return a container: a list, vector, hash, etc.
rather than a bunch of individual values. Or, if the function is canned
[e..g, in a library] to put them into a container for your code to work
with.
> I have written a small proof-of-concept of an assignment operator :=
> that communicates to a function how many extra values it is expected
> to produce (and still works with standard functions).
>
> Are there alternative solutions that are better than the "use a
> keyword" approach?
You can use call-with-values which connects the function that
produces
with the one that consumes, but they have to agree on the number of
values being passed or it won't work.
My problem is that the producer still needs to be told how many values
to produce.
Sorry, I missed that - I thought you needed to know how many were
produced by something.
The only way to call attention - particularly compiler attention - to a
particular argument is to make it a keyword with no default value.
If your function has default behavior that the keyword(s) would only
modify, then you can make keyword(s) optional using default values or by
defining the function with make-keyword-procedure.
George
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/5bea165b-3357-7236-173c-934ca3a0ab58%40comcast.net.
