vector->range issues Wolfgang Corcoran-Mathe (01 Sep 2020 19:21 UTC)
Re: vector->range issues Marc Nieper-Wißkirchen (01 Sep 2020 19:28 UTC)
Re: vector->range issues Wolfgang Corcoran-Mathe (01 Sep 2020 20:52 UTC)
Re: vector->range issues Marc Nieper-Wißkirchen (02 Sep 2020 05:48 UTC)
Re: vector->range issues Marc Nieper-Wißkirchen (02 Sep 2020 07:57 UTC)
string-range Marc Nieper-Wißkirchen (02 Sep 2020 13:14 UTC)
Re: string-range Wolfgang Corcoran-Mathe (02 Sep 2020 14:50 UTC)
Re: string-range Marc Nieper-Wißkirchen (02 Sep 2020 15:01 UTC)
Re: string-range Wolfgang Corcoran-Mathe (02 Sep 2020 15:56 UTC)
Re: string-range Marc Nieper-Wißkirchen (02 Sep 2020 15:58 UTC)
Re: string-range John Cowan (02 Sep 2020 21:12 UTC)
Re: string-range Wolfgang Corcoran-Mathe (02 Sep 2020 21:16 UTC)
Re: string-range Wolfgang Corcoran-Mathe (02 Sep 2020 21:25 UTC)
Re: vector->range issues Wolfgang Corcoran-Mathe (02 Sep 2020 14:46 UTC)

Re: vector->range issues Wolfgang Corcoran-Mathe 01 Sep 2020 20:51 UTC

On 2020-09-01 21:28 +0200, Marc Nieper-Wißkirchen wrote:
> Am Di., 1. Sept. 2020 um 21:21 Uhr schrieb Wolfgang Corcoran-Mathe
> <xxxxxx@sigwinch.xyz>:
> >
> > I wonder if this
> > means that the only real use of vector->range will be as a sort of
> > shorthand for constructing a discrete range, by passing literal
> > vectors.  If so, perhaps it would be better to *remove* the
> > restriction on vector->range (i.e.  copy the vector argument), and
> > provide a discrete range constructor (conventionally, this would be
> > called `range'):
>
> I think there are many more uses. Like in
>
> (vector->range (vector-unfold <some-complicated-proc> n))

Yes, on second thought, we certainly wouldn't want it to copy there.
So I withdraw the suggestion.  I still think the restriction on
vector->range is a bit error-prone.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"Invent and fit; have fits and reinvent!" --Alan J. Perlis