Email list hosting service & mailing list manager

Unicode lambda Lassi Kortela (12 May 2019 10:19 UTC)
Re: Unicode lambda Shiro Kawai (12 May 2019 11:18 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 11:40 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 11:50 UTC)
Re: Unicode lambda Shiro Kawai (12 May 2019 12:06 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (12 May 2019 12:11 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 12:23 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 13:23 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 13:46 UTC)
Re: Unicode lambda John Cowan (12 May 2019 14:20 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 14:38 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 14:55 UTC)
Re: Unicode lambda John Cowan (12 May 2019 15:00 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 15:20 UTC)
Re: Unicode lambda Shiro Kawai (12 May 2019 18:42 UTC)
Re: Unicode lambda Lassi Kortela (12 May 2019 19:43 UTC)
Re: Unicode lambda John Cowan (12 May 2019 22:29 UTC)
Re: Unicode lambda Shiro Kawai (13 May 2019 10:48 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 08:25 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (14 May 2019 08:50 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 10:10 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 10:59 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 12:35 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 13:09 UTC)
Re: Unicode lambda Lassi Kortela (14 May 2019 14:04 UTC)
Re: Unicode lambda Shiro Kawai (14 May 2019 19:18 UTC)
Re: Unicode lambda Vincent Manis (14 May 2019 22:01 UTC)
Re: Unicode lambda Lassi Kortela (20 May 2019 09:21 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (21 Oct 2019 14:20 UTC)
Re: Unicode lambda Shiro Kawai (21 Oct 2019 17:19 UTC)
Re: Unicode lambda John Cowan (21 Oct 2019 17:39 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (21 Oct 2019 18:43 UTC)
Re: Unicode lambda John Cowan (21 Oct 2019 23:27 UTC)
Encoding declarations Lassi Kortela (22 Oct 2019 08:39 UTC)
Re: Encoding declarations John Cowan (22 Oct 2019 20:52 UTC)
#! directives, general and specific Lassi Kortela (22 Oct 2019 09:11 UTC)
Re: #! directives, general and specific John Cowan (22 Oct 2019 20:27 UTC)
Re: #! directives, general and specific Lassi Kortela (22 Oct 2019 20:43 UTC)
Re: Unicode lambda Marc Nieper-Wißkirchen (13 May 2019 08:50 UTC)
Re: Unicode lambda Lassi Kortela (13 May 2019 10:27 UTC)
Re: Unicode lambda Per Bothner (12 May 2019 14:17 UTC)
Re: Unicode lambda Peter (12 May 2019 15:06 UTC)

Re: Unicode lambda Lassi Kortela 14 May 2019 10:10 UTC

> I like the idea of allowing arbitrary s-exps following "#!" (i.e.
> "#!(precision 25)" instead of "#!precision=25") so that "#!" can be
> parsed as datum comments "#;".

Glad to hear that :)

> Note that Scheme ports are stateful. Directives like "#!fold-case"
> change the port's state for subsequent read (and principally also for
> write) operations. If something like "#!(encoding ...)" is ever
> standardized it should change the state of the port as well and should
> affect not only "read" but also "read-char", "write-char", etc.

True. Most likely an #!(encoding ...) would be too clever for our own
good :) The purpose of any in-file encoding tag is to give the encoding
for the whole file so the file can then be re-read from the start with
that encoding. That's conceptually different from "read after this point
using encoding X". In particular, mixing #!(encoding ...) with
ASCII-incompatible encodings like UTF-16 would have weird semantics.

> Independently of the encoding question, we should have another SRFI
> that specifies how the Scheme reader handles "#!" directives.

Agreed.

> I am thinking of a parameter object bound to a procedure that is called
> with the port and the s-exp following the "#!" directive whenever the
> reader encounters a "#!" directive. The procedure should be able to
> tail-call a success or a failure procedure. On such a SRFI, we can
> portably build many reader extensions.

That would be simple and generic, but we should probably also have a
standard way to dispatch on the symbol in the #!(symbol ...) form. It
could be some kind of symbol->procedure mapping, or we could have a
chain of #! handler procedures and a handler could defer to the next
handler in case it doesn't recognize the form.

If it ever makes sense to have more than one directive combined into one
#!(...) form then we will need a syntax like this:

     #!((thing1 value1) (thing2 value2) (thing3 value3))

Or something like this:

     #!(many-things (thing1 value1) (thing2 value2) (thing3 value3))

It seems weird and excessive now, but maybe not in the future.

> This SRFI should also expose a
> way to inspect and modify the state of ports (in particular whether
> case-folding is enabled, but also being able to access column and row
> counters makes sense).

No opinion on this one. It sounds reasonable.

Based on this whole discussion, we could have all of these SRFIs:

- Extensible #!(list ...) read syntax
- Float precision as #!(precision ...)
- Extensible (declare-file ...) and/or #!(declare-file ...) form
- In-file encoding tag (no unproblematic approach found so far)
- Unicode lambda

Quite a lot for one thread :D