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

Racket: support here-strings and reading-comments #172

Open
gilch opened this issue Aug 14, 2017 · 2 comments
Open

Racket: support here-strings and reading-comments #172

gilch opened this issue Aug 14, 2017 · 2 comments

Comments

@gilch
Copy link

gilch commented Aug 14, 2017

Racket has here strings which don't use double quotes. And actually the delimiter can be customized, but any here string as a whole should be recognizable with a simple regex. Parinfer should not be messing up brackets or indents inside of string literals, but it doesn't appear to have a way to recognize this kind of thing.

Is there some configuration option I missed for this? Like a custom regex to find string literals? Lisp is a big family of languages, and other Lisps might need this kind of feature too.

@shaunlebron
Copy link
Collaborator

Sorry! I'm not a Racket user, and I missed this.

looks like the reading comments will also be a problem. will need to support #|, #; and #!

I'll start thinking about how to handle dialect-specific things, but more than likely it will just be a dialect: 'racket' option.

@shaunlebron shaunlebron changed the title This doesn't seem to handle Racket's "here strings" Racket: support here-strings and reading-comments Aug 14, 2017
@gilch
Copy link
Author

gilch commented Aug 14, 2017

Common Lisp also does the #| |# block comments, by the way. And unlike here strings (or C /* */ comments) these can nest in Common Lisp. I think several other Lisps use these too. One exception is PicoLisp, which I think uses #{ }# instead. I don't know if they nest in PicoLisp though.

A normal finite state machine regex engine can't match nested delimiters properly. We'd need an enhanced regex engine with the equivalent power of a pushdown automaton, like (?R) from PCRE. Javascript regexes can't do this, last I checked, and neither do the regex engines from Vimscript, Emacs Lisp, or Python. So asking for a callback matching function would work better than my earlier idea of asking for a regex string in the custom configuration.

And Hy will probably be implementing a Lua-like string syntax soon. hylang/hy#1379. Hy also ignores the shebang on the first line, but treats it as a tag macro elsewhere.

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

No branches or pull requests

2 participants