search

parinfer / parinfer.js

Let's simplify the way we write Lisp
https://shaunlebron.github.io/parinfer
MIT License
1.75k stars 40 forks source link

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

Open gilch opened 7 years ago

gilch commented 7 years ago

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 commented 7 years ago

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.

gilch commented 7 years ago

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.