chibi-scheme icon indicating copy to clipboard operation
chibi-scheme copied to clipboard

Square brackets

Open mnieper opened this issue 2 years ago • 8 comments

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

mnieper avatar Jan 29 '23 12:01 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.

lassik avatar Jan 29 '23 14:01 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.

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.

mnieper avatar Jan 29 '23 15:01 mnieper

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.

ashinn avatar Jan 29 '23 21:01 ashinn

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.

mnieper avatar Jan 29 '23 21:01 mnieper

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.

ashinn avatar Jan 30 '23 00:01 ashinn

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.

lassik avatar Jan 30 '23 08:01 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.

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.

mnieper avatar Jan 30 '23 09:01 mnieper

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

ashinn avatar Jan 30 '23 16:01 ashinn