Truely annoying regular expressions.

Harvey J. Stein (hjstein@bfr.co.il)
15 Aug 1998 11:45:20 +0300

guile> (define parser (make-regexp "^[ \t]*([^ \t:]*):[ \t]*(.*[^ \t])[ \t]*$"))
guile> (define m (regexp-exec parser "Concept: Joe learns guile"))
guile> (define (capitalize! s)
(do ((i 1 (1+ i))
(l (string-length s)))
((>= i l)
(if (>= l 1)
(string-set! s 0 (char-upcase (string-ref s 0))))
s)
(string-set! s i (char-downcase (string-ref s i)))))
guile> (capitalize! (match:substring m 1))
ERROR: In procedure string-ref in expression (string-ref s i):
ERROR: Bad memory access (Segmentation violation)
ABORT: (signal)

Nice. It's rare to see a scheme interpreter seg fault.

- procedure: match:substring MATCH [N]
Return the portion of TARGET matched by subexpression number N.
Submatch 0 (the default) represents the entire regexp match. If
the regular expression as a whole matched, but the subexpression
number N did not match, return `#f'.

(define-public (match:substring match . args)
(let* ((matchnum (if (pair? args)
(car args)
0))
(start (match:start match matchnum))
(end (match:end match matchnum)))
(and start end (make-shared-substring (match:string match)
start
end))))

Cool. Docs don't mention that the returned string shouldn't be
modified & guile doesn't tell me "Error: Attempt to modify read/only
object", it tells me "Segmentation violation".

1. Why the call to make-shared-substring?
2. If I try to modify a "shared" string, shouldn't I get an error
message that's a little more illuminating than a seg fault?
3. Between the lack of documentation, the *misleading* documentation,
the *unusual* interfaces (i.e. - match:substring returning an
immutable string), and the cryptic error messages, I find guile
scheme *extremely* annoying & difficult to program with, compared,
say to STk & Bigloo. STk is better documented & more uniform,
reliable & schemish, & Bigloo has a compiler and an extremely
useful & efficient lexer & parser. Before the existence of
apropos, guile was almost impossible, so it's better than it used
to be, but it's prety weak for version # > 1.0.

-- 
Harvey J. Stein
BFM Financial Research
hjstein@bfr.co.il