Re: [PATCH] Per-module reader

[Neil Jerram <neil@ossau.uklinux.net>]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Hi,
>
> The patch below adds a `#:reader' keyword to `define-module' that allows
> modules to specify the reader that should be used to interpret them:
>
>   (define-module (the-module)
>     #:reader the-reader-for-my-favorite-syntax)

All looks good, except for concerns about (i) performance; (ii)
whether #:reader fits nicely in the big picture with the transformer
option; (iii) one possible bug.

> This way, module implementors can decide to use whatever syntax variant
> they prefer, while not having any side-effect on the code being read
> from other files or modules.  For illustration, here is an example that
> makes use of my `guile-reader' thing:
>
> --8<---------------cut here---------------start------------->8---
> (define-module (module-with-reader)
>   #:reader (let* ((elisp-char-tr
> 		   (make-token-reader #\?
> 				      (token-reader-procedure
> 				       (standard-token-reader 'character)))))
> 	     (make-reader (cons elisp-char-tr
> 				(map standard-token-reader
> 				     '(whitespace
> 				       sexp string number colon-keyword
> 				       semicolon-comment
> 				       symbol-upper-case symbol-lower-case
> 				       quote-quasiquote-unquote)))))
>   #:use-module (system reader))

This is nice; but concerns about whether it fits with transformer are:

- Transformer is specified with #:use-syntax followed by module name,
  which is a lot different from your syntax.  I prefer your syntax,
  because use-syntax requires the transformer procedure to have the
  same name as the module it's defined in, which seems rubbish.  But
  on the other hand perhaps there is a reason for forcing the
  reader/transformer to be defined in another module - are we missing
  some subtlety here?

- As well as the inline definition option shown here, does it also
  work if the #:reader arg is a proc defined in one of the used
  modules?  I guess it can't possibly work in the circular reference
  case -- i.e. where module A uses a reader defined in module B, but B
  also uses A and B was loaded first -- so this is probably deemed
  user error - but how is that error presented to the user?

- Does it make sense to have both #:reader and #:use-syntax?  Should
  we reimplement use-syntax as a special case of #:reader?  Does it
  make sense that the places where your reader affects libguile
  (i.e. primitive-load) are different from the places where the module
  transformer affects libguile (i.e. the various versions of eval)?

> Index: ice-9/boot-9.scm
> ===================================================================
> RCS file: /cvsroot/guile/guile/guile-core/ice-9/boot-9.scm,v
> retrieving revision 1.351
> diff -u -B -b -p -r1.351 boot-9.scm
> --- ice-9/boot-9.scm	31 Jul 2005 23:36:50 -0000	1.351
> +++ ice-9/boot-9.scm	13 Sep 2005 12:28:08 -0000
> @@ -1185,7 +1185,8 @@
>    (make-record-type 'module
>  		    '(obarray uses binder eval-closure transformer name kind
>  		      duplicates-handlers duplicates-interface
> -		      observers weak-observers observer-id)
> +		      observers weak-observers observer-id
> +		      reader)
>  		    %print-module))
>  
>  ;; make-module &opt size uses binder
> @@ -1221,7 +1222,8 @@
>  					  uses binder #f #f #f #f #f #f
>  					  '()
>  					  (make-weak-value-hash-table 31)
> -					  0)))
> +					  0
> +					  read)))

Init value "read" here prevents your optimization in load.c from
taking effect - so don't you want #f ?

> Index: libguile/load.c
> ===================================================================
> RCS file: /cvsroot/guile/guile/guile-core/libguile/load.c,v
> retrieving revision 1.86
> diff -u -B -b -p -r1.86 load.c
> --- libguile/load.c	23 May 2005 19:57:20 -0000	1.86
> +++ libguile/load.c	13 Sep 2005 12:28:08 -0000
> @@ -82,15 +82,29 @@ SCM_DEFINE (scm_primitive_load, "primiti
>      scm_call_1 (hook, filename);
>  
>    { /* scope */
> +    SCM module = SCM_BOOL_F, reader = SCM_BOOL_F;
>      SCM port = scm_open_file (filename, scm_from_locale_string ("r"));
>      scm_frame_begin (SCM_F_FRAME_REWINDABLE);
>      scm_i_frame_current_load_port (port);
>  
>      while (1)
>        {
> -	SCM form = scm_read (port);
> +	SCM form;
> +
> +	if (scm_current_module () != module)
> +	  {
> +	    module = scm_current_module ();
> +	    reader = SCM_MODULE_READER (module);
> +	  }

I'm worried that this could reduce performance noticeably, and it
seems unnecessarily inefficient.  So ... <pause> ...

Surely the low level concept here is that an alternative reader is a
property of a port?  In that case, I would expect that

- the switch to the alternative reader would be implemented inside
  scm_read, using a new field on scm_t_port which can be set/read
  using set-port-reader!/port-reader

- the module level #:reader option would be implemented by
  define-module calling set-port-reader! on current-load-port.  (Note
  BTW that define-module should also do this when called to switch
  context to an already existing module.)

Note that this also raises the question of what to do when someone
types (define-module (module-with-reader)) at the REPL ... perhaps
define-module should set the reader of the current input port also?

> Index: libguile/modules.h
> ===================================================================
> RCS file: /cvsroot/guile/guile/guile-core/libguile/modules.h,v
> retrieving revision 1.28
> diff -u -B -b -p -r1.28 modules.h
> --- libguile/modules.h	31 Jul 2005 23:36:14 -0000	1.28
> +++ libguile/modules.h	13 Sep 2005 12:28:08 -0000
> @@ -45,6 +45,7 @@ SCM_API scm_t_bits scm_module_tag;
>  #define scm_module_index_binder		2
>  #define scm_module_index_eval_closure	3
>  #define scm_module_index_transformer	4
> +#define scm_module_index_reader        12

Why 12?  From the context I'd expect 5.

Regards,
        Neil



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