-
Notifications
You must be signed in to change notification settings - Fork 5
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
option to trim leading spaces #9
Comments
Thanks for the suggestion. Yes, it makes sense.This is especially useful for C++ codegeneration like let emptyTemplateTClass name =
[%string.padded
{|template <class T> class $name {
$name() {}
~$name() {}
};
|}]
let emptyTemplateTClass2 name =
[%string.padded
{|
template <class T> class $name {
$name() {}
~$name() {}
};
|}]
let emptyTemplateTClass3 name =
[%string.padded
{|
|template <class T> class $name {
| $name() {}
| ~$name() {}
|};
|}]
let emptyTemplateTClass4 name =
[%string.padded
{|
|template <class T> class $name {
$name() {}
~$name() {}
};
|}]
let emptyTemplateTClass5 name =
[%string.padded "
|template <class T> class $name {
$name() {}
~$name() {}
};
"]
let emptyTemplateTClass6 name =
[%string.padded
"
template <class T> class $name {
$name() {}
~$name() {}
};
"] producing template <class T> class $name {
$name() {}
~$name() {}
}; I am not sure though if .trimmed is a good suffix. May be '.indented'? Another question is how this would interact with ecosystem. Especially formatters. |
I agree. I didn't like it when I wrote it. Also, I haven't checked the implementation of the ppx to know if this could happen at compile time, but the scala version I mentioned is actually a runtime implementation: https://github.com/scala/scala/blob/v2.13.6/src/library/scala/collection/StringOps.scala#L765-L784. If these strings are created in a tight loop, maybe you would benefit from the compiler preprocessing them, but if they are created once at startup, then this can just be a library function instead and doesn't have to be in a ppx. |
I would prefer to use the name without verb, since it makes it lengthy and harder to type (people usually want to type less, if possible). So, If it is possible, i.e. there are no blockers, which I do not see right now, it should be compile-time implementation, since it is even easier to implement than run-time. I am mostly worried about the interaction with the ecosystem, especially formatters, which can rewrite many things and move the leading I will think about this sometime next week if you do not mind - we are quite busy now. |
No urgency on my end. It would be a convenient addition but not strictly necessary. |
We considered several variants of formatting with my colleague @gxmas , so I changed my comment above and included all of them. The ideal seems to be №2 (unfortunately it does not work with I have checked the behavior of Also, Ocaml lexer does not extract extension point as a whole - see https://github.com/ocaml/ocaml/blob/trunk/parsing/lexer.mll#L553 This means, that Ocaml parser takes the payload as a stream of tokens, so the number of spaces and newlines between these tokens can be arbitrary - https://github.com/ocaml/ocaml/blob/trunk/parsing/parser.mly#L3855 In other words, [%string
" Hello
wonderful
world!"] into [%string " Hello
wonderful
world!"] and back. This means that we are:
[%string.padded {|-----
Hello World! |}] == " Hello World! "
@joprice what do you think about these variants? I'll try to make a proof of concept of №4 within next couple weeks. |
Is your feature request related to a problem? Please describe.
When leading spaces are significant, the text must be fully justified to the left of the file to avoid including them:
Describe the solution you'd like
A separate extension or a special character (as the pipe character in multiline strings in scala) could be used to indicate the leading space should be removed
or
The text was updated successfully, but these errors were encountered: