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

Interpolating expressions #73

Open
dloscutoff opened this issue Mar 19, 2024 · 0 comments
Open

Interpolating expressions #73

dloscutoff opened this issue Mar 19, 2024 · 0 comments
Labels
brainstorming Less of an issue, more of a place to kick around ideas. compatibility-breaking Making this change would break backward compatibility.
Milestone

Comments

@dloscutoff
Copy link
Owner

dloscutoff commented Mar 19, 2024

One potential approach for interpolating expressions in escaped strings:

  • If \ is followed by any name, interpolate that name. (Similar to the current situation, but could be updated to allow non-alphabetical names like $0 and to disallow things that look like names but are not--see Interpolating an operator should give a syntax error #72.)
  • If \ is followed by any open bracket ((, [, {), scan the string from that bracket on and parse one expression starting from that bracket. Interpolate that expression and continue processing the string from the point where the expression ends.
    • It's not clear to me how to tell exactly what character the expression ended at, especially if the expression may include comments. Maybe we'll need to add some more information to the Token class.
    • Any expression that doesn't include the sequence \" could be interpolated this way. That means no interpolated strings inside interpolated expressions, no regular strings that end with backslashes, and no '\ followed by a string (just add a space or a semicolon, in that case).
    • Should { interpolation eval the block and interpolate the result? That's probably more useful than interpolating the block itself.
  • Even crazier idea: If \ is followed by any unary operator, parse an expression starting from that operator. It wouldn't actually be that much harder, I think.
@dloscutoff dloscutoff added compatibility-breaking Making this change would break backward compatibility. brainstorming Less of an issue, more of a place to kick around ideas. labels Mar 19, 2024
@dloscutoff dloscutoff added this to the v2.0 milestone Mar 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
brainstorming Less of an issue, more of a place to kick around ideas. compatibility-breaking Making this change would break backward compatibility.
Projects
None yet
Development

No branches or pull requests

1 participant