[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] Inconsistency of sequence copying procedures



Marc Feeley scripsit:

> Vectors and bytevectors have a similar external representation, yet
> bytevectors are self evaluating (page 46) and vectors are not self
> evaluating.  I do not care very much if they are, or if they are not
> self-evaluating, but it should be the same for vectors and
> bytevectors.

Both are now self-evaluating.

> 2) sequence copying procedures inconsistencies

Things have changed in this area since draft 6 due to the fifth ballot;
in addition, there is an outstanding ticket for the sixth ballot.  So I'll
summarize the current situation.

Subsequence extractors:

  (list-copy list) ; WG rejected adding further arguments
  (string-copy string [start [end]]) ; per SRFI 13; WG rejected fill
  (substring string start end) ; backwards compatibility with R5RS
  (vector-copy string [start [end [fill]]]) ; per SRFI 43
  (bytevector-copy bytevector)
  (bytevector-copy-partial bytevector start end)

  ;; Ticket #384 merges the last two as:
  (bytevector-copy bytevector [start [end]])

Mutating copiers:

  ;; WG rejected list-copy! as insufficiently useful
  (string-copy! to at from [start [end]])
  (vector-copy! to at from [start [end]])
  (bytevector-copy! to at from [start [end]])

> I do not see a good reason for having different APIs (mix of required
> and optional parameters) and naming conventions for similar operations.

The WG voted for consistency with SRFI 1, SRFI 13, and SRFI 43 rather than
complete self-consistency.  However, things are much more consistent now,
especially if #384 passes.

> The naming convention could be based on the one which has been in
> place for strings for a long time, i.e. substring, subvector, and
> subbytevector for extracting subsequences.

"Subblob" was informally rejected by WG as too ugly, and the
"subvector" and "subbytevector" were never suggested.

> Finally, I think the handling of the fill parameter is questionable.
> It is a bad idea for the fill parameter to have a default.

This comes from SRFI 43, but your argument is reasonable and does not
break backward compatibility.  Ballot ticket #450 filed.

-- 
John Cowan    cowan@x    http://ccil.org/~cowan
Nobody expects the RESTifarian Inquisition!  Our chief weapon is
surprise ... surprise and tedium  ... tedium and surprise ....
Our two weapons are tedium and surprise ... and ruthless disregard
for unpleasant facts....  Our three weapons are tedium, surprise, and
ruthless disregard ... and an almost fanatical devotion to Roy Fielding....

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports