Re: [PATCH] Per-module reader

[Ludovic Courtès]

Neil Jerram <address@hidden> writes:

> 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)

That could be one possibility.

The other issue is providing a basic mechanism to help fixing the
current single-instance `read' issue.  Again, there's only one instance
of `read', and `read-enable', `read-hash-extend' and the likes modify
that very single instance.  This means that they have side-effects
/across/ modules.  This also means that it may turn out that two modules
cannot be used together because they rely on incompatible reader
settings.

Maybe you do not consider this to be an issue in practice, but at least,
I think we'd agree that this approach is flawed.  Assuming that this
/is/ an issue in practice, I can think of only two ways to fix this:

  1.  Remove all the `read' configuration tricks;
  2.  Allow for per-module readers.

Obviously, (1) is not acceptable to me, and I guess, for most people.
Part of (2) also means being able to instantiate and tweak readers,
which is what `guile-reader' is about.

> 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.

I was not thinking about such extreme uses of the system.  And honestly,
I doubt Guile will ever be able to run foreign code.  It might have been
able to achieve this in its glory days back in 1999-2000, but I don't
think it should be a goal now.  This is sad, especially since you
apparently did a great job with Elisp translation.

> 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.

Not noticeably, indeed.  And modules are read only once.  And Guile is
an interpreter anyway.  ;-)  However, in my previous post, I noted:

  The two main sources of inefficiency are (i) the use of `scm_call'
  instead of a direct call to the reader subr, and (ii) the successive
  calls to `scm_current_module ()'.

  In the simple case, (i) can be avoided by having modules' reader default
  to `#f' as you noted earlier.  As for (ii), we would greatly benefit
  from having an inlined version of `scm_current_module ()'.

Both optimizations seem feasible.

> 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.

Of course I can do without it.

The point is that I considered this to be an elegant solution to allow
coexistence within a program of different syntax *variants* (personally,
I don't care about writing Guile modules in Python or Sh, etc.).

Thanks,
Ludovic.