Thanks, Mark. This all sounds very sensible to me, and I will continue working on the scmutils port while waiting for your patch.
On Fri, Feb 22, 2013 at 3:52 AM, Mark H Weaver <m...@netris.org> wrote: > Mikael Djurfeldt <mik...@djurfeldt.com> writes: >> The API you suggest would compose much easier, but to me it feels like >> just another specialized solution. What we would really need is >> something like Ludovic's guile-reader. > > I agree that we should ideally have a much more general way of defining > customized readers. In the meantime, my primary concern is to find a > solution to your problem without committing us to supporting an overly > general mechanism that fails to provide basic guarantees to other users > of 'read'. > > As you pointed out, the current code *almost* supports overriding > standard syntax for things like "#!". However, it has been broken for > a long time. The same bug is in Guile 1.8, and I haven't seen anyone > complaining about it. Therefore, I'm more inclined to remove this > broken functionality than to fix it. > > Mikael Djurfeldt <mik...@djurfeldt.com> writes: >> But I won't be stubborn regarding this. If someone else wants to >> implement another way of supporting #!optional and #!rest that is fine >> by me. > > Thanks. I hope to cook up a patch in the next few days. > > Ludovic Courtès <l...@gnu.org> writes: >> This is basically DSSSL keyword syntax. What about adding a new keyword >> style to read.c? Sounds like the easiest solution for this particular >> problem. > > This is a tempting solution, but I see a problem with this proposal: > We'd have to make exceptions for things like #!fold-case and > #!curly-infix, as well as for things like #!/usr/bin/guile. Also, it > could potentially turn existing scsh-style block comments into syntax > errors. > > Ludovic Courtès <l...@gnu.org> writes: >> In general, I think it should be easy to create new readers that derive >> from the standard syntax without having to write them from scratch. >> >> However, in hindsight, I’m not sure Guile-Reader’s API is the right >> approach. It’s an improvement, because it addresses this need; but its >> API is not ideal: “token readers” with different delimiter syntax don’t >> compose well, for instance. > > I'd be very interested to hear your current thoughts on what a better > API should look like. > > Regards, > Mark
