Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Square brackets #883

Open
mnieper opened this issue Jan 29, 2023 · 8 comments
Open

Square brackets #883

mnieper opened this issue Jan 29, 2023 · 8 comments

Comments

@mnieper
Copy link
Collaborator

mnieper commented Jan 29, 2023

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

@lassik
Copy link
Contributor

lassik commented Jan 29, 2023

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
Copy link
Collaborator Author

mnieper commented Jan 29, 2023

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
Copy link
Owner

ashinn commented Jan 29, 2023

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
Copy link
Collaborator Author

mnieper commented Jan 29, 2023

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
Copy link
Owner

ashinn commented Jan 30, 2023

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
Copy link
Contributor

lassik commented Jan 30, 2023

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
Copy link
Collaborator Author

mnieper commented Jan 30, 2023

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
Copy link
Owner

ashinn commented Jan 30, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants