[EMAIL PROTECTED] (Ludovic Courtès) writes:

> Hi,
>
> Let's not forget this thread (see <[EMAIL PROTECTED]>), it's soooo
> interesting!  Was my message so convincing that you don't know what to
> answer?  ;-)

I'll reply separately to some of the details in your other message,
but overall I don't feel convinced that we need to support #:reader as
a core module feature.

If I'm understanding correctly, your argument rests on wanting to
allow people to write a module like this:

  (define-module (shell utils)
    #:reader shell-reader
    #:use-module (shell reader)
    #:export (for))

  for () {
    beg=$1
    end=$2
    ...
  }

rather than like this (with the shell code in another file):

  (define-module (shell utils)
    #:use-module (shell reader)
    #:export (for))

  (load-using-reader "for.sh" shell-reader)

I admit that in the future something like this _could_ be a key part
of Guile's support for translators, but right now we don't have enough
translation experience to say that this will end up being the right
thing, and on its own merits the benefit of being able to write
foreign code with a Guile module header in the same file seems very
marginal to me.

And to get this marginal benefit we have to add a module option and
some code which will slow down normal operation.  Not noticeably
perhaps, but it all adds up.

Finally, wouldn't you be making more headache for yourself (in the
medium term) by relying on #:reader in the core rather than something
like load-using-reader in your library?  With #:reader in the core,
your package code would only work with Guile CVS and >=1.7 releases
after a certain date, whereas with load-using-reader your code will
work with 1.6, 1.7/1.8 and probably 1.4 as well.

Sorry to push back so much, but that's my view.

Regards,
      Neil



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

Reply via email to