4 ms·

Anybody that knows about the RFC and other implementations in C compilers, why are always "string literal parameters" (quoted strings) used? Wouldn't be nice t

Anybody that knows about the RFC and other implementations in C compilers, why are always "string literal parameters" (quoted strings) used? Wouldn't be nice to have a way to embed other languages without the need for those quotes everywhere? I guess it is meant to avoid complicating the syntax/grammar reusing the existing macro one?

Sharlin 6y ago
For maximum generality and compatibility, likely. Also note that this is ”just” a macro, not first-class language syntax, so any non-quoted arguments would have to be valid Rust token trees.
- est31 6y ago
  > any non-quoted arguments would have to be valid Rust token trees. Token trees allow a very wide set of syntaxes. rust-c for example allows you to embed inline C code as token tree via a macro: https://github.com/lemonrock/rust-c https://github.com/lemonrock/rust-c
deleted 6y ago
[deleted]
kevincox 6y ago
Yes, Rust macros have certain syntax requirements that allow the code to parse without knowing what a macro does (and to find out where a macro ends). Don't quote me but there are some token requirements as well as balanced parenthesis. If you allow another language to be inserted raw you risk that it requires syntax that would break these requirements. Buy using a raw string literal you have a well defined quoting syntax mediating the two languages.
deleted 6y ago
[deleted]
klyrs 6y ago
Zig has a nice solution for that: https://ziglang.org/documentation/master/#Global-Assembly https://ziglang.org/documentation/master/#Global-Assembly The "magic" being that lines beginning with double-backslashes are string literals.
- masklinn 6y ago
  That's a solution in none of the ways GP asks about. It's just a different syntax for a string literal, the entire point of the original comment is why string literals. > The "magic" being that lines beginning with double-backslashes are string literals. So… strictly worse than rust which allows linebreaks inside string literals, and thus only require a dquote before and one after the entire block instead of a two-char prefix before each line?
jcranmer 6y ago
In principle, you can embed languages without the need for strings. However, when you do so, you need to worry about the tokenization of languages to see that a) they combine in a sensible way and b) tools won't get confused if they don't understand the sub-language (this is a real issue that cropped with XHTML and JS). In practice, inline assembly has pretty much been seen as a "paste this text into the generated assembly of the program, after substituting some values determined by register allocation"--in other words, it's a pretty natural string formatting problem, and describing the language like you would a formatted string is a natural step to take. Another point to make is that assembly languages are wildly divergent in their actual syntax. ARM uses # to denote literals, x86 (Intel syntax) uses # to denote comments.
dathinab 6y ago
Yes it adds a lot of complexity on the tokenization level (and others), potentially requiring some form of contextual tokenization. Scala originally supported "inline" XML but moved it into some form of compiler plugin you can opt-in to as just having it enabled had drawbacks even if you don't use any XML... (I don't remember the exact drawbacks anymore).
geofft 6y ago
It means that a parser for Rust doesn't also have to be a parser for every embedded language - which is particularly important for things like syntax highlighters in text editors or HTML renderers or whatever. For example, in most languages including Rust, parentheses are balanced as a rule, but they might not be in some inner language. So if you want to define a syntax where you can say inner_language!( smiley = :-) ); while you can certainly write a parser that understands what's going on there, any existing Rust parser will get very confused. So, unless you're confident the inner language is syntactically compatible (even if it's meaningless) with the outer language, you'd need to protect it somehow. Making the inner language quoted means that existing parsers that already know how to handle the outer language's string syntax (where to find the close quote, how close quotes might be escape, etc.) work seamlessly. You could also define some other syntax for it, but it's fundamentally the same requirement - it's a well-defined open and close syntax - and most other syntaxes end up uglier (think of <script>//</script or <script>//<![CDATA[ ... //]]></script> in HTML/XHTML.) And there's nothing preventing a particularly clever parser from recognizing the asm! macro specifically and syntax-highlighting (or otherwise tokenizing/processing/etc.) the text inside, if it wants to.
mhh__ 6y ago
It saves time (there also isn't a single ground truth for parsing assembler) https://dlang.org/spec/iasm.html https://dlang.org/spec/iasm.html No quotes required

Sharlin 6y ago

For maximum generality and compatibility, likely. Also note that this is ”just” a macro, not first-class language syntax, so any non-quoted arguments would have to be valid Rust token trees.

est31 6y ago
> any non-quoted arguments would have to be valid Rust token trees. Token trees allow a very wide set of syntaxes. rust-c for example allows you to embed inline C code as token tree via a macro: https://github.com/lemonrock/rust-c https://github.com/lemonrock/rust-c

deleted 6y ago

[deleted]

kevincox 6y ago

Yes, Rust macros have certain syntax requirements that allow the code to parse without knowing what a macro does (and to find out where a macro ends). Don't quote me but there are some token requirements as well as balanced parenthesis. If you allow another language to be inserted raw you risk that it requires syntax that would break these requirements. Buy using a raw string literal you have a well defined quoting syntax mediating the two languages.

deleted 6y ago

[deleted]

klyrs 6y ago

Zig has a nice solution for that: https://ziglang.org/documentation/master/#Global-Assembly https://ziglang.org/documentation/master/#Global-Assembly The "magic" being that lines beginning with double-backslashes are string literals.

masklinn 6y ago
That's a solution in none of the ways GP asks about. It's just a different syntax for a string literal, the entire point of the original comment is why string literals. > The "magic" being that lines beginning with double-backslashes are string literals. So… strictly worse than rust which allows linebreaks inside string literals, and thus only require a dquote before and one after the entire block instead of a two-char prefix before each line?

jcranmer 6y ago

In principle, you can embed languages without the need for strings. However, when you do so, you need to worry about the tokenization of languages to see that a) they combine in a sensible way and b) tools won't get confused if they don't understand the sub-language (this is a real issue that cropped with XHTML and JS). In practice, inline assembly has pretty much been seen as a "paste this text into the generated assembly of the program, after substituting some values determined by register allocation"--in other words, it's a pretty natural string formatting problem, and describing the language like you would a formatted string is a natural step to take. Another point to make is that assembly languages are wildly divergent in their actual syntax. ARM uses # to denote literals, x86 (Intel syntax) uses # to denote comments.

dathinab 6y ago

Yes it adds a lot of complexity on the tokenization level (and others), potentially requiring some form of contextual tokenization. Scala originally supported "inline" XML but moved it into some form of compiler plugin you can opt-in to as just having it enabled had drawbacks even if you don't use any XML... (I don't remember the exact drawbacks anymore).

geofft 6y ago

It means that a parser for Rust doesn't also have to be a parser for every embedded language - which is particularly important for things like syntax highlighters in text editors or HTML renderers or whatever. For example, in most languages including Rust, parentheses are balanced as a rule, but they might not be in some inner language. So if you want to define a syntax where you can say inner_language!( smiley = :-) ); while you can certainly write a parser that understands what's going on there, any existing Rust parser will get very confused. So, unless you're confident the inner language is syntactically compatible (even if it's meaningless) with the outer language, you'd need to protect it somehow. Making the inner language quoted means that existing parsers that already know how to handle the outer language's string syntax (where to find the close quote, how close quotes might be escape, etc.) work seamlessly. You could also define some other syntax for it, but it's fundamentally the same requirement - it's a well-defined open and close syntax - and most other syntaxes end up uglier (think of <script>//</script or <script>//<![CDATA[ ... //]]></script> in HTML/XHTML.) And there's nothing preventing a particularly clever parser from recognizing the asm! macro specifically and syntax-highlighting (or otherwise tokenizing/processing/etc.) the text inside, if it wants to.

mhh__ 6y ago

It saves time (there also isn't a single ground truth for parsing assembler) https://dlang.org/spec/iasm.html https://dlang.org/spec/iasm.html No quotes required