Not only am I exactly aware of that, I am even advocating it.
OP wants to write a hobby language, not reimplement Common Lisp.
If OP wants sexprs, they can get quick-and-dirty sexprs by:
(1) substituting spaces around each paren in the input
(2) breaking input up into a list of whitespace separated words
(3) folding over the resulting list (by looking at its parens) into a tree
Sure, that's done poorly. However, it takes under 15 minutes (and under 15 lines?) to get them past their sticking point, and if the rest of their language (especially the part that differs from all other languages) actually turns out to be worth pursuing, they can always implement (or import) a real —or at least a better— reader later.
> If OP wants sexprs, they can get quick-and-dirty sexprs by:
You know what it takes to implement a parser for s expressions?
E := atom | '(' *E ')'
With atom expanding to all data types you wish to support.
Let's presume using a parser generator is an insurmountable task for someone developing a parser. In a hand-rolled packrat parser, this whole grammar is implemented with a couple of functions.
Is writing two functions too much work for someone wanting to write their own parser?
Your ad-hoc trick is much more work than actually implementing a proper, maintainable parser.
OP wants to write a hobby language, not reimplement Common Lisp.
If OP wants sexprs, they can get quick-and-dirty sexprs by:
Sure, that's done poorly. However, it takes under 15 minutes (and under 15 lines?) to get them past their sticking point, and if the rest of their language (especially the part that differs from all other languages) actually turns out to be worth pursuing, they can always implement (or import) a real —or at least a better— reader later.See https://news.ycombinator.com/item?id=36593060