Square brackets

[mnieper]

Would you accept a patch that enables using square brackets (as used in R6RS, for example) to improve portability?

[lassik]

How different is #!r6rs lexical syntax from R7RS-small syntax? If not much, the easiest way to do it might be to recognize #!r6rs.

[mnieper]

How different is #!r6rs lexical syntax from R7RS-small syntax? If not much, the easiest way to do it might be to recognize #!r6rs.

This is somewhat unrelated to the question. The usual meaning of #!r6rs is to force signaling errors for all lexical syntax that is not R6RS. This is only sensible for an R6RS implementation, not for Chibi.

The context of the question is different. R7RS is compatible with the lexical syntax extension I asked about.

[ashinn]

The meaning of square brackets should be configurable. I think a reasonable approach is to allow specifying the identifier to which they expand similar to Kawa:

#|kawa:1|# '[foo]
($bracket-list$ foo)

Here you can locally override the binding of $bracket-list$. This is insufficient for R6RS. As a special case, if the identifier is #f, then the expansion doesn't include the identifier.

[mnieper]

So, [...] would be a similar abbreviation as quote in the reader. (Only that quote is non-configurable.)

As it is a configuration of the reader, I wonder where the identifier (or #f) has to be set to make it as helpful as possible. It could be a command-line option for Chibi, which is better than a compile-time flag.

[ashinn]

Yes, runtime is preferable. We can consider:

1. global setting (configured via command-line option and/or code)
2. per-extension setting (e.g. by default .sls would follow R6RS and .scm would follow Kawa)
3. per-file setting (via #! pragmas and/or allowing the library declaration language to customize for include files)

1 is simplest for now so I recommend that unless you feel ambitious.

Beware: there are two implementations of read in Chibi.

[lassik]

IMHO read and write syntax settings should be bound to port objects. I did some sketching of this a while back but didn't manage to come up with an elegant API.

Gambit also supports something like Kawa's approach IIRC. You should ask Feeley about that. I don't like the approach, but he does.

[mnieper]

IMHO read and write syntax settings should be bound to port objects. I did some sketching of this a while back but didn't manage to come up with an elegant API.

Gambit also supports something like Kawa's approach IIRC. You should ask Feeley about that. I don't like the approach, but he does.

I agree with you that customizing the reader via port settings is the way to go, but this is orthogonal to the question of a global setting. We need a global setting because when Chibi is initially started, the ports have to default to some behavior. This must be customizable so Chibi can run programs containing square brackets correctly.

Implementing per-port settings is independent of it, but a port would take the global setting as its default.

[ashinn]

Yes, all of these are ultimately port-level settings (like case-insensitivity), it's just a question of where the defaults come from.

[aartaka]

Is there any plan for square brackets beyond (seemingly stalled) #1003? Maybe have them a separate feature, instead of omnibus PR like #1003? These are nice to have…

[ashinn]

#1003 is handling different things. It's still in draft but I think could be merged.

For square brackets, patches are welcome, all I ask is that it be configurable as discussed above.

[aartaka]

@ashinn I am ready to make such a patch, but I need some pointers:

What about making it a CLI option, like in CHICKEN?

-no-parentheses-synonyms  disables list delimiter synonyms

And where should I put the boolean representing whether to parse square brackets as parens?