`keyword-colon-position`, R7RS and some SRFIs

[jpellegrini]

STklos, by default, uses keyword-colon-position with the value both. There are two problems related to this:

1. It is not R7RS compliant, since the standard requires identifiers beginning with : to be read as symbols.
2. There are two SRFIs that use : in the beginning of exported identifiers (SRFI 42: Eager Comprehensions and now SRFI 276: Type-specific Flonum Libraries).

I was thinking of a way to get these SRFIs to work without changing the default behavior too much. The options I could think of are:

1. The SRFIs would have the directive keyword-colon-position-none in their source. However:
   • loading the SRFI code would leave keyword-colon-position-none as it was before, and the identifiers would not be very useful.
   • includeing it would leave the parameter changed. The exported identifiers would be easily used, but we'd have the reader changed (user will be surprised?)
   • If loading the SRFI changes the reader behavior after the load finishes, it may feel weird to the user
2. Refuse to load the SRFIs if the parameter is either before or both. But it could be changed later.
3. Do (2), but also implement the concept of immutability in parameters ( see issue Parameters cannot be immutable #900 ).
4. Have per-included-file directives? So both load and include would leave the reader intact? We'd have to warn the user that, well, the SRFI uses identifiers beginning with :, so set up keyword-colon-position accordingly...

"Remembering the previous value of the parameter" doesn't seem to work in all cases, since loading or including behave differently (but (4) would perhaps help?).

To illustrate, with option (1),

stklos> (import (srfi 276))
stklos> :round

would not result in the procedure :round, but in the keyword :round, because load did not change the parameter... Of course one can load with prefixing, but it shouldn't be required for the SRFI to be used.

stklos> (include srfi-276.stk)
stklos> :round

would nicely access the procedure. But it would perhaps change the behavior of the reader without the user expecting it (or not? it would be silly to do such a thing anyway)

[egallesio]

Hi @jpellegrini ,

I read last issues but i'm now in an hospital (nothing grave, but it takes time). Answering on a phone is defitively not possible. I hope to be more reactive soon.

[jpellegrini]

@egallesio no problem, of course!
I hope everything goes well, take your time!