Email list hosting service & mailing list manager

superfluous functions? Jamison Hope (29 Sep 2015 16:57 UTC)
Re: superfluous functions? Bradley Lucier (29 Sep 2015 17:08 UTC)
Re: superfluous functions? Jamison Hope (29 Sep 2015 17:48 UTC)
Re: superfluous functions? Bradley Lucier (07 Oct 2015 01:15 UTC)
Re: superfluous functions? Jamison Hope (11 Oct 2015 14:45 UTC)
Re: superfluous functions? Bradley Lucier (16 Oct 2015 17:44 UTC)

Re: superfluous functions? Bradley Lucier 29 Sep 2015 17:08 UTC

> On Sep 29, 2015, at 12:57 PM, Jamison Hope <xxxxxx@alum.mit.edu> wrote:
>
> These functions don't seem necessary as part of the public API:
>
> - mutable-array-curry
> - mutable-array-distinguish-one-axis.
> - specialized-array-curry
> - specialized-array-distinguish-one-axis
>
> They (probably) have utility within the implementation, but if the idea
> of SRFI-122 is to present a general array library, then users of the
> library should only have to use the general array functions, in this
> case array-curry and array-distinguish-one-axis.

I’ve discussed these functions in previous emails; with the goal of not sounding like a broken record, I suggest you search for these names in the mail list archive.  (Short version—they have more than just “utility within the implementation”.)

That being said, I’m trying to come up with just the two functions array-curry and array-distinguish-one-axis that could take optional arguments to give all the utility of the current six procedures.

>
> Also, this distinguish-one-axis family just sounds like more currying.

It’s something more, see below.

> Do we need both *-curry and *-distinguish-one-axis?  Can the latter be
> implemented in terms of the former (regardless of efficiency), or are
> they fundamentally distinct operations?

It could be implemented by permuting the dimensions of an array and then currying, but I don’t think by currying alone.

After seeing how one might implement some of John Cowan’s examples in this SRFI, I’ve been thinking of adding permutation functions to intervals and arrays.  The API would be very simple (especially after all the API design advice I’ve been given on this mail list ;-), but it would require some work behind the scenes for an efficient implementation.

>  I'm having trouble following
> all of the big long (values ...) expressions in the text.

I presume you mean the text of the SRFI, and not the text of the implementation?

> Can there be
> more descriptions in words explaining what those expressions are doing?

I’ll work on it.  Can you point me to the precise language you’re having difficulty with?

Brad