ashinn / chibi-scheme

Official chibi-scheme repository
Other
1.22k stars 141 forks source link

Square brackets #883

Open mnieper opened 1 year ago

mnieper commented 1 year ago

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

lassik commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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