Settle on a convention to refer to targets as language dialects?

[oowekyala]

Sometimes when writing documentation I get tired of writing "the Rust target" or "the X target" and would like to use a sort of shortcut. Usually I write eg "LF-Rust" or "LF-Python". I think it's compact, memorable, and has the added benefit that a target can be understood as a language, and not just a setting of our compiler or something.

I guess though, we can understand "LF-Rust" as either being a dialect of Rust, or a dialect of LF. It should be understood as a dialect of LF, and a framework in Rust though. But we already play with that ambiguity in other places, for instance, runtime crates are named reactor-rust or reactor-cpp, which can be understood as "the reactor flavor of C++", just like "reactive C++" or "objective C" and the like.

One weird thing is that LF-C sounds like lfc...

Questions:

• What do you think about making such mnemonics canon?
• Would you prefer typesetting it another way, like LF/Rust? or another order, like Rust-LF?

Cheers

[lhstrh]

Interesting suggestion! I'm not entirely sure about this. Another possible way to go about this would be to refer to a "Rust reactor" or a "C reactor" when describing a LF code with the Rust or C target, respectively.

If think I like LF/X better than LF-X, in part because the / is commonly used as a syntax for substitutions. I think that in the not-to-distant future, however, we might have cross-language LF programs, in which case your proposed mnemonic scheme will no longer work so well...

[petervdonovan]

Maybe we should come to a final decision on this so we can apply it uniformly. Even outside of human-readable documentation, we are already forced to adopt conventions on how we refer to the different targets.

• In the benchmarks repo, the target argument of the benchmark runner accepts the terms lf-c and lf-cpp
• @edwardalee pointed out that we should have a consistent convention in the Markdown files for our website, where we need to mark the target language of our code blocks.

I like Clément's original suggestion, and I do not think that the problems with it are very serious.

• The hyphen in lf-c works tolerably well (at least in writing) at distinguishing it from lfc.
• In multilingual programs, we could just adopt another label, like lf-multilingual or lf-mixed, or we could simply use lf without specifying their target.

[edwardalee]

Let's go with lf-c and lf-cpp. I'll update the branch I'm working on when I get a chance...

[lhstrh]

More specifically, I'd propose we use lf-<language file extension> i.e., lf-c, lf-cpp, lf-py, lf-ts, and lf-rs. That makes it nice and short (and absent of weird symbols like + that filesystems generally don't like).

[petervdonovan]

Oh, that makes sense. I can do that from now on for anything machine-readable.

[edwardalee]

I agree. That looks right to me. However, TypeScript files seem to be given a .js extension by the code generator. ???

[lhstrh]

I agree. That looks right to me. However, TypeScript files seem to be given a .js extension by the code generator. ???

That's not really what happens. The TypeScript code generator generates a .ts file that subsequently gets compiled down to a .js file that is executable in Node.

[edwardalee]

OK, I've changed these in the conditional-targets branch. I think this branch is ready to start developing the docs for real. Basic syntax highlighting is working and so is target language selection. Your selected language is remembered in local storage, so you select it once and all the pages you look at will show you the target language you are interested in.

[edwardalee]

Sounds good to me! Edward

…

------------ Edward A Lee Professor UC Berkeley On Mar 13, 2022, at 8:19 PM, Marten Lohstroh ***@***.***> wrote:  More specifically, I'd propose we use lf-<language file extension> i.e., lf-c, lf-cpp, lf-py, lf-ts, and lf-rs. That makes it nice and short (and absent of weird symbols like + that filesystems generally don't like). — Reply to this email directly, view it on GitHub <#576 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACA6ONRGK4GDBFFDVQEYZYTU7243LANCNFSM5FOTAFJA> . You are receiving this because you were mentioned.Message ID: ***@***.***>