keyword cleanup patch

keyword cleanup patch

[Richard Todd]

[-- Attachment #1.1.1: Type: text/plain, Size: 1138 bytes --]

Something about my state of mind made me unhappy with the way one can
use either #:xxx or :xxxx in for modules, so (I'll probably regret
this later!) I dropped that feature in my local copy of guile.

Why are both syntaxes allowed in this one area, anyway?  I assume it's
a historical reason?  It's inconsistent with the rest of guile (AFAIK)
where you have to set a reader option for this behavior.

Anyway, while I doubt you'd be interested in _that_ patch, there are
two options that I thought I'd mention:

A.)  As a result of the change, (you can imagine), I had to
standardize all the guile-core code on #: in my local tree.  Having
all the code match is kind of nice, even if you allow both syntaxes.

....and/or....

B) I did stumble across a bug-fix and a cleanup that I thought you
might want to apply.  They are in the attached patch, and are:

1) ice-9/mapping.scm needed changes, since it has several keywords of
the form :xxx in it.  Maybe everyone that uses it also uses the reader
'prefix option.

2) A goops error message about missing keywords writes them as :xxx
instead of #:xxx.  Not a big deal, but...

Richard Todd

[-- Attachment #1.1.2: small.patch --]
[-- Type: text/plain, Size: 2156 bytes --]

Index: ice-9/mapping.scm
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/ice-9/mapping.scm,v
retrieving revision 1.7
diff -u -r1.7 mapping.scm
--- ice-9/mapping.scm	5 Apr 2003 19:04:27 -0000	1.7
+++ ice-9/mapping.scm	8 Jan 2004 11:30:41 -0000
@@ -102,8 +102,8 @@
 (define (hash-table-mapping . options)
   (let* ((size (or (and options (number? (car options)) (car options))
 		   71))
-	 (hash-proc (or (kw-arg-ref options :hash-proc) hash))
-	 (assoc-proc (or (kw-arg-ref options :assoc-proc)
+	 (hash-proc (or (kw-arg-ref options #:hash-proc) hash))
+	 (assoc-proc (or (kw-arg-ref options #:assoc-proc)
 			 (cond
 			  ((eq? hash-proc hash) assoc)
 			  ((eq? hash-proc hashv) assv)
@@ -111,7 +111,7 @@
 			  (else (error 'hash-table-mapping
 				       "Hash-procedure specified with no known assoc function."
 				       hash-proc)))))
-	 (delete-proc (or (kw-arg-ref options :delete-proc)
+	 (delete-proc (or (kw-arg-ref options #:delete-proc)
 			  (cond
 			   ((eq? hash-proc hash) delete!)
 			   ((eq? hash-proc hashv) delv!)
@@ -119,7 +119,7 @@
 			   (else (error 'hash-table-mapping
 					"Hash-procedure specified with no known delete function."
 					hash-proc)))))
-	 (table-constructor (or (kw-arg-ref options :table-constructor)
+	 (table-constructor (or (kw-arg-ref options #:table-constructor)
 				(lambda (len) (make-vector len '())))))
     (make-hash-table-mapping (table-constructor size)
 			     hash-proc
Index: oop/goops.scm
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/oop/goops.scm,v
retrieving revision 1.36
diff -u -r1.36 goops.scm
--- oop/goops.scm	20 Apr 2003 17:35:41 -0000	1.36
+++ oop/goops.scm	8 Jan 2004 11:30:42 -0000
@@ -1431,7 +1431,7 @@
 	   (set (get-keyword #:slot-set! (slot-definition-options s) #f))
 	   (env (class-environment class)))
        (if (not (and get set))
-	   (goops-error "You must supply a :slot-ref and a :slot-set! in ~S"
+	   (goops-error "You must supply a #:slot-ref and a #:slot-set! in ~S"
 			s))
        (list get set)))
     (else    (next-method))))

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: keyword cleanup patch

[Neil Jerram]

>>>>> "Richard" == Richard Todd <richardt@vzavenue.net> writes:

    Richard> Anyway, while I doubt you'd be interested in _that_ patch, there are
    Richard> two options that I thought I'd mention:

IMO both are these are good for applying to CVS, but personally (since
the Savannah crack) I don't have CVS access again yet ....

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: keyword cleanup patch

[Stephen Compall]

Richard Todd <richardt@vzavenue.net> writes:

> Why are both syntaxes allowed in this one area, anyway?  I assume
> it's a historical reason?  It's inconsistent with the rest of guile
> (AFAIK) where you have to set a reader option for this behavior.

On the syntax: Emacs Lisp uses plain `:' for keywords; other lisps may
do so as well.  Incidentally, `#:' in front of a symbol in elisp will
prevent its interning. :)

If you're asking why the reader option is on by default ....

--
Stephen Compall or s11 or sirian

Your wise men don't know how it feels
To be thick as a brick.
		-- Jethro Tull, "Thick As A Brick"

S Key offensive information warfare mailbomb NWO bluebird MILSATCOM
asset BLU-114/B cypherpunk PGP Agfa bemd radar Project Monarch
Perl-RSA


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: keyword cleanup patch

[Richard Todd]

[-- Attachment #1.1.1: Type: text/plain, Size: 2377 bytes --]

On Sat, Jan 10, 2004 at 10:18:22AM -0600, Stephen Compall wrote:
> Richard Todd <richardt@vzavenue.net> writes:
> 
> > Why are both syntaxes allowed in this one area, anyway?  I assume
> > it's a historical reason?  It's inconsistent with the rest of guile
> > (AFAIK) where you have to set a reader option for this behavior.
> 
> On the syntax: Emacs Lisp uses plain `:' for keywords; other lisps may
> do so as well.  Incidentally, `#:' in front of a symbol in elisp will
> prevent its interning. :)

That doesn't explain why special code in boot-9 allows #: or : in
specific statements like (define-module), does it?  I may not be fully
grasping what you are getting at.

I've searched with google, and the only explanation I can find is that
several guile developers prefer :.  I'm fine with that sentiment, but
guile's current state doesn't actually help these people, IMO.

The main problem, as I see it, is that people can't use : in code they
would release, because they can't assume that users are using the
optional reader setting.  Setting the option for the users would be
disgusting, and potentially break their code.

In my fledgling library of modules, I added a module which lets you do:

(define-module (xxx) :use-syntax (guile-syntax colon-keyword))

...and for this module you can code to your preference.  Users need
not even know about a reader extension (in fact, I took the extension
itself out of my local guile tree, on principle!).

To me, this is a sane answer.  Plus, this approach can be extended to
support 'keyword:' (as in DSSSL), or '&keyword', etc, without changing
the scheme reader.  Of course you take a speed hit compared to the
reader option, but there are ways to help with that if it became an
issue.

(And though I may be alone, and have not done any research on this
issue, I don't see why an elisp reader has to be grafted on to the
scheme reader.  Aside from the oh-so-close-to-scheme elisp case, if
guile really wants to seamlessly support other languages, it needs a
way to load a module with a different reader entirely, anyway.  A
separate elisp reader could still share code with the scheme reader, I
would think, and would be a cleaner answer).

The proof-of-concept (read: room for improvement!) module I described
is attached, for any who might be interested.

Richard Todd

[-- Attachment #1.1.2: colon-keyword.scm --]
[-- Type: text/plain, Size: 802 bytes --]

(define-module (guile-syntax colon-keyword) #:export (colon-keyword))

(define (colon-keyword exp)
  (let lp ((lst exp))
    (cond 
     ((null? lst) exp)
     ((pair? lst)
      (set-car! lst (colon-keyword (car lst)))
      (if (pair? (cdr lst))
          (lp (cdr lst))
          (begin (set-cdr! lst (colon-keyword (cdr lst)))
                 (lp '()))))
     ((symbol? lst)
      (let ((str (symbol->string lst)))
        (if (char=? (string-ref str 0) #\:)
            (symbol->keyword (string->symbol (substring str 1)))
            lst)))
     ((vector? lst)
      (let lp2 ((i 0))
        (if (>= i (vector-length lst))
            lst
            (begin (vector-set! lst i (colon-keyword (vector-ref lst i)))
                   (lp2 (+ i 1))))))
     (else lst))))


[-- Attachment #1.2: Type: application/pgp-signature, Size: 186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: keyword cleanup patch

[Marius Vollmer]

Richard Todd <richardt@vzavenue.net> writes:

> Why are both syntaxes allowed in this one area, anyway?  I assume it's
> a historical reason?

For convenience only, I think.

What we _should_ have (if we don't already) is a way to change the
reader options per file or per module.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: keyword cleanup patch

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

> IMO both are these are good for applying to CVS, but personally (since
> the Savannah crack) I don't have CVS access again yet ....

I have applied them.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel