Re: [PATCH] In string-split, add support for character sets and predicates.

[Daniel Hartwig]

Patch with .texi updated also.


0001-In-string-split-add-support-for-character-sets-and-p.patch
Description: Binary data

Re: [PATCH] In string-split, add support for character sets and predicates.

[Mark H Weaver]

Daniel Hartwig mand...@gmail.com writes:
 Patch with .texi updated also.

Applied, thanks! :)

 Mark

Re: [PATCH] Implement ‘hash’ for structs

[Ludovic Courtès]

Mark H Weaver m...@netris.org skribis:

 l...@gnu.org (Ludovic Courtès) writes:

 Mark H Weaver m...@netris.org skribis:

 I guess this 'if' is to avoid an infinite loop if the struct points back
 to itself.  However, it apparently fails to detect cycles in the general
 case.

 Yes, indeed.

 Here’s an updated patch that uses the ‘depth’ argument of ‘scm_hasher’
 for that, as is done for pairs.

 I don't think 'depth' is an appropriate name for that argument.

I’ve finally pushed it (keeping that variable name).

Thanks for the review!

Ludo’.

Re: regexp-split for Guile

[Mark H Weaver]

Daniel Hartwig mand...@gmail.com writes:
 On 19 September 2012 03:59, Chris K. Jester-Young cky...@gmail.com wrote:
 (define* (regexp-split pat str #:optional (limit 0))
 […]
 (reverse (if (zero? limit)
  (drop-while string-null? final)
  final


 Please simplify this limit arg, removing the maybe-drop-empty-strings
 behaviour.  Either positive limit or #f for all matches.  It is
 trivial for the caller to remove the empty strings if desired, and
 simplifies the docs for regexp-split.  Matching perl semantics is not
 necessarily desirable.

FWIW, I agree with Daniel.  I dislike the complicated semantics of this
'limit' argument, which combines into a single number two different
concepts:

* What limiting mode to use:

   [A] return 'limit' many fields at most
   [B] return all fields
   [C] return all fields except trailing blank fields

* How many fields, if using limiting mode [A].

Beyond matters of taste, I don't like this because it makes bugs less
likely to be caught.  Suppose 'limit' is a computed value, normally
expected to be positive.  Code that follows may implicitly assume that
the returned list has no more than 'limit' elements.  Now suppose that
due to a bug or exceptional circumstance, the computed 'limit' ends up
being less than 1.  Now 'regexp-split' switches to a qualitatively
different mode of behavior.

I'd prefer for a numeric limit to be interpreted in a uniform way.  That
suggests that a non-positive 'limit' should raise an exception.

Limiting modes [B] and [C] could be indicated in a few different ways.
One possibility would be to pass special symbol values for the 'limit'
argument to indicate these two other modes.

Another possibility is to add a 'drop-right-while' procedure (analogous
to SRFI-1's 'drop-while'), and then users who want this could do:

  (drop-right-while string-null?
(regexp-split ...))

Regards,
  Mark